draft-ietf-6man-why64-00.txt   draft-ietf-6man-why64-01.txt 
6MAN B. Carpenter, Ed. 6MAN B. Carpenter, Ed.
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Intended status: Informational T. Chown Intended status: Informational T. Chown
Expires: October 13, 2014 Univ. of Southampton Expires: November 8, 2014 Univ. of Southampton
F. Gont F. Gont
SI6 Networks / UTN-FRH SI6 Networks / UTN-FRH
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
A. Petrescu A. Petrescu
CEA, LIST CEA, LIST
A. Yourtchenko A. Yourtchenko
cisco cisco
April 11, 2014 May 7, 2014
Analysis of the 64-bit Boundary in IPv6 Addressing Analysis of the 64-bit Boundary in IPv6 Addressing
draft-ietf-6man-why64-00 draft-ietf-6man-why64-01
Abstract Abstract
The IPv6 unicast addressing format includes a separation between the The IPv6 unicast addressing format includes a separation between the
prefix used to route packets to a subnet and the interface identifier prefix used to route packets to a subnet and the interface identifier
used to specify a given interface connected to that subnet. used to specify a given interface connected to that subnet.
Currently the interface identifier is defined as 64 bits long for Currently the interface identifier is defined as 64 bits long for
almost every case, leaving 64 bits for the routing prefix. This almost every case, leaving 64 bits for the subnet prefix. This
document describes the advantages of this fixed boundary and analyses document describes the advantages of this fixed boundary and analyses
the issues that would be involved in treating it as a variable the issues that would be involved in treating it as a variable
boundary. boundary.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 13, 2014. This Internet-Draft will expire on November 8, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3.3. Audit requirement . . . . . . . . . . . . . . . . . . . . 6 3.3. Audit requirement . . . . . . . . . . . . . . . . . . . . 6
3.4. Concerns over ND cache exhaustion . . . . . . . . . . . . 6 3.4. Concerns over ND cache exhaustion . . . . . . . . . . . . 6
4. Effects of varying the interface identifier length . . . . . 7 4. Effects of varying the interface identifier length . . . . . 7
4.1. Interaction with IPv6 specifications . . . . . . . . . . 7 4.1. Interaction with IPv6 specifications . . . . . . . . . . 7
4.2. Possible areas of breakage . . . . . . . . . . . . . . . 9 4.2. Possible areas of breakage . . . . . . . . . . . . . . . 9
4.3. Experimental observations . . . . . . . . . . . . . . . . 11 4.3. Experimental observations . . . . . . . . . . . . . . . . 11
4.3.1. Survey of the processing of Neighbor Discovery 4.3.1. Survey of the processing of Neighbor Discovery
options with prefixes other than /64 . . . . . . . . 11 options with prefixes other than /64 . . . . . . . . 11
4.3.2. Other Observations . . . . . . . . . . . . . . . . . 13 4.3.2. Other Observations . . . . . . . . . . . . . . . . . 13
4.4. Implementation and deployment issues . . . . . . . . . . 13 4.4. Implementation and deployment issues . . . . . . . . . . 13
4.5. Privacy issues . . . . . . . . . . . . . . . . . . . . . 14 4.5. Privacy issues . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 16 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
skipping to change at page 3, line 11 skipping to change at page 3, line 11
flexibility and new possibilities, rather than simply relieving the flexibility and new possibilities, rather than simply relieving the
IPv4 address shortage by doubling the address size to 64 bits. In IPv4 address shortage by doubling the address size to 64 bits. In
particular, the notion of a well-defined interface identifier was particular, the notion of a well-defined interface identifier was
added to the IP addressing model. The IPv6 addressing architecture added to the IP addressing model. The IPv6 addressing architecture
[RFC4291] specifies that a unicast address is divided into n bits of [RFC4291] specifies that a unicast address is divided into n bits of
subnet prefix followed by (128-n) bits of interface identifier (IID). subnet prefix followed by (128-n) bits of interface identifier (IID).
The bits in the IID have no meaning and the entire identifier should The bits in the IID have no meaning and the entire identifier should
be treated as an opaque value [RFC7136]. Also, since IPv6 routing is be treated as an opaque value [RFC7136]. Also, since IPv6 routing is
entirely based on variable length subnet masks, there is no basic entirely based on variable length subnet masks, there is no basic
architectural assumption that n has any particular fixed value. All architectural assumption that n has any particular fixed value. All
IPv6 routing protocols support subnet masks of any length up to /128. IPv6 routing protocols support prefixes of any length up to /128.
The IID is of basic importance in the IPv6 stateless address The IID is of basic importance in the IPv6 stateless address
autoconfiguration (SLAAC) process [RFC4862]. However, it is autoconfiguration (SLAAC) process [RFC4862]. However, it is
important to understand that its length is a parameter in the SLAAC important to understand that its length is a parameter in the SLAAC
process, and it is determined in a separate link-type specific process, and it is determined in a separate link-type specific
document (see Section 2 of RFC 4862). The SLAAC protocol does not document (see Section 2 of RFC 4862). The SLAAC protocol does not
define its length or assume any particular length. define its length or assume any particular length.
The notion of a /64 boundary in the address was introduced after the The notion of a /64 boundary in the address was introduced after the
initial design of IPv6 was done, following a period when it was initial design of IPv6 was done, following a period when it was
skipping to change at page 4, line 10 skipping to change at page 4, line 10
IPv6 specifications, so results may vary. IPv6 specifications, so results may vary.
The question is often asked why the subnet prefix boundary is set The question is often asked why the subnet prefix boundary is set
rigidly at /64. The first purpose of this document is to explain the rigidly at /64. The first purpose of this document is to explain the
advantages of the fixed IID length. Its second purpose is to analyse advantages of the fixed IID length. Its second purpose is to analyse
in some detail the effects of hypothetically varying the IID length. in some detail the effects of hypothetically varying the IID length.
The fixed length limits the practical length of a routing prefix to The fixed length limits the practical length of a routing prefix to
64 bits, whereas architecturally, and from the point of view of 64 bits, whereas architecturally, and from the point of view of
routing protocols, it could be anything (in theory) between /1 and / routing protocols, it could be anything (in theory) between /1 and /
128 inclusive. Here, we mainly discuss the question of a shorter 128 inclusive. Here, we mainly discuss the question of a shorter
IID, which would allow a longer routing prefix. The document makes IID, which would allow a longer subnet prefix. The document makes no
no proposal for a change to the IID length. proposal for a change to the IID length.
The following three sections describe in turn the advantages of the The following three sections describe in turn the advantages of the
fixed length IID, some arguments for shorter lengths, and the fixed length IID, some arguments for shorter lengths, and the
expected effects of varying the length. expected effects of varying the length.
2. Advantages of a fixed identifier length 2. Advantages of a fixed identifier length
As mentioned in Section 1, the existence of an IID of a given length As mentioned in Section 1, the existence of an IID of a given length
is a necessary part of IPv6 stateless address autoconfiguration is a necessary part of IPv6 stateless address autoconfiguration
(SLAAC) [RFC4862]. This length is normally the same for all nodes on (SLAAC) [RFC4862]. This length is normally the same for all nodes on
a given link that is running SLAAC. Even though this length is a a given link that is running SLAAC. Even though this length is a
parameter for SLAAC, determined separately for each interface, a parameter for SLAAC, determined separately for each interface, a
globally fixed IID length for all link layer media is the simplest globally fixed IID length for all link layer media is the simplest
solution, and is consistent with the principles of Internet host solution, and is consistent with the principles of Internet host
configuration described in [RFC5505]. configuration described in [RFC5505].
An interface identifier of significant length, clearly separated from An interface identifier of significant length, clearly separated from
the routing prefix, makes it possible to limit the traceability of a the subnet prefix, makes it possible to limit the traceability of a
host computer by varying the identifier. This is discussed further host computer by varying the identifier. This is discussed further
in Section 4.5. in Section 4.5.
An interface identifier of significant length guarantees that there An interface identifier of significant length guarantees that there
are always enough addresses in any subnet to add one or more real or are always enough addresses in any subnet to add one or more real or
virtual interfaces. There might be other limits, but IP addressing virtual interfaces. There might be other limits, but IP addressing
will never get in the way. will never get in the way.
The addressing architecture [RFC4291] [RFC7136] sets the IID length The addressing architecture [RFC4291] [RFC7136] sets the IID length
at 64 bits for all unicast addresses, and therefore for all media at 64 bits for all unicast addresses, and therefore for all media
skipping to change at page 5, line 26 skipping to change at page 5, line 26
benefits of keeping the length fixed at 64 bits, and the practical benefits of keeping the length fixed at 64 bits, and the practical
difficulties of changing it, outweigh the arguments for change. difficulties of changing it, outweigh the arguments for change.
3. Arguments for shorter identifier lengths 3. Arguments for shorter identifier lengths
In this section we describe arguments for scenarios where shorter In this section we describe arguments for scenarios where shorter
IIDs, implying prefixes longer than /64, have been used or proposed. IIDs, implying prefixes longer than /64, have been used or proposed.
3.1. Insufficient address space delegated 3.1. Insufficient address space delegated
A site may not be delegated a sufficiently large prefix from which to A site may not be delegated a sufficiently generous prefix from which
allocate a /64 prefix to all of its internal subnets. In this case to allocate a /64 prefix to all of its internal subnets. In this
the site may either determine that it does not have enough address case the site may either determine that it does not have enough
space to number all its network elements and thus, at the very best, address space to number all its network elements and thus, at the
be only partially operational, or it may choose to use internal very best, be only partially operational, or it may choose to use
prefixes longer than /64 to allow multiple subnets and the hosts internal prefixes longer than /64 to allow multiple subnets and the
within them to be configured with addresses. hosts within them to be configured with addresses.
In this case, the site might choose, for example, to use a /80 per In this case, the site might choose, for example, to use a /80 per
subnet, in combination with hosts using either manually configured subnet, in combination with hosts using either manually configured
addressing or DHCPv6. addressing or DHCPv6.
Scenarios that have been suggested where an insufficient prefix might Scenarios that have been suggested where an insufficient prefix might
be delegated include home or small office networks, vehicles, be delegated include home or small office networks, vehicles,
building services and transportation services (road signs, etc.). It building services and transportation services (road signs, etc.). It
should be noted that the homenet architecture text should be noted that the homenet architecture text
[I-D.ietf-homenet-arch] states that a CPE should consider the lack of [I-D.ietf-homenet-arch] states that a CPE should consider the lack of
skipping to change at page 9, line 24 skipping to change at page 9, line 24
be considered "magic" in some RFCs, e.g., 64k limits in DNS and be considered "magic" in some RFCs, e.g., 64k limits in DNS and
Base64 encodings in MIME. None of this has any influence on the Base64 encodings in MIME. None of this has any influence on the
length of the IID, but might confuse a careless reader. length of the IID, but might confuse a careless reader.
4.2. Possible areas of breakage 4.2. Possible areas of breakage
This section discusses several specific aspects of IPv6 where we can This section discusses several specific aspects of IPv6 where we can
expect operational breakage with subnet prefixes other than /64. expect operational breakage with subnet prefixes other than /64.
o Router implementations: Router implementors might interpret IETF o Router implementations: Router implementors might interpret IETF
standards such as [RFC6164] and [RFC7136] to indicate that routing standards such as [RFC6164] and [RFC7136] to indicate that
prefixes between /65 and /126 inclusive for unicast packets on- prefixes between /65 and /126 inclusive for unicast packets on-
the-wire are invalid, and operational practices that utilize the-wire are invalid, and operational practices that utilize
prefix lengths in this range may break on some devices, as prefix lengths in this range may break on some devices, as
discussed in Section 4.3.2. discussed in Section 4.3.2.
o Multicast: [RFC3306] defines a method for generating IPv6 o Multicast: [RFC3306] defines a method for generating IPv6
multicast group addresses based on unicast prefixes. This method multicast group addresses based on unicast prefixes. This method
assumes a longest network prefix of 64 bits. If a longer prefix assumes a longest prefix of 64 bits. If a longer prefix is used,
is used, there is no way to generate a specific multicast group there is no way to generate a specific multicast group address
address using this method. In such cases the administrator would using this method. In such cases the administrator would need to
need to use an "artificial" prefix from within their allocation (a use an "artificial" prefix from within their allocation (a /64 or
/64 or shorter) from which to generate the group address. This shorter) from which to generate the group address. This prefix
prefix would not correspond to a real subnet. would not correspond to a real subnet.
Similarly [RFC3956], which specifies Embedded-RP, allowing IPv6 Similarly [RFC3956], which specifies Embedded-RP, allowing IPv6
multicast rendezvous point addresses to be embedded in the multicast rendezvous point addresses to be embedded in the
multicast group address, would also fail, as the scheme assumes a multicast group address, would also fail, as the scheme assumes a
maximum prefix length of 64 bits. maximum prefix length of 64 bits.
o CGA: The Cryptographically Generated Address format (CGA, o CGA: The Cryptographically Generated Address format (CGA,
[RFC3972]) is heavily based on a /64 interface identifier. [RFC3972]) is heavily based on a /64 interface identifier.
[RFC3972] has defined a detailed algorithm how to generate 64-bit [RFC3972] has defined a detailed algorithm how to generate 64-bit
interface identifier from a public key and a 64-bit subnet prefix. interface identifier from a public key and a 64-bit subnet prefix.
skipping to change at page 10, line 15 skipping to change at page 10, line 15
Conversely, longer prefixes would weaken CGA. Conversely, longer prefixes would weaken CGA.
o NAT64: Both stateless [RFC6052] NAT64 and stateful NAT64 [RFC6146] o NAT64: Both stateless [RFC6052] NAT64 and stateful NAT64 [RFC6146]
are flexible for the prefix length. [RFC6052] has defined are flexible for the prefix length. [RFC6052] has defined
multiple address formats for NAT64. In Section 2 "IPv4-Embedded multiple address formats for NAT64. In Section 2 "IPv4-Embedded
IPv6 Prefix and Format" of [RFC6052], the network-specific prefix IPv6 Prefix and Format" of [RFC6052], the network-specific prefix
could be one of /32, /40, /48, /56, /64 and /96. The remaining could be one of /32, /40, /48, /56, /64 and /96. The remaining
part of the IPv6 address is constructed by a 32-bit IPv4 address, part of the IPv6 address is constructed by a 32-bit IPv4 address,
a 8-bit u byte and a variable length suffix (there is no u byte a 8-bit u byte and a variable length suffix (there is no u byte
and suffix in the case of 96-bit Well-Known Prefix). NAT64 is and suffix in the case of 96-bit Well-Known Prefix). NAT64 is
therefore OK with a boundary out to /96, but not longer. therefore OK with a subnet boundary out to /96, but not longer.
o NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296] is also o NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296] is also
bound to /64 boundary. NPTv6 maps a /64 prefix with other /64 bound to /64 boundary. NPTv6 maps a /64 prefix to another /64
prefix. When the NPTv6 Translator is configured with a /48 or prefix. When the NPTv6 Translator is configured with a /48 or
shorter prefix, the 64-bit interface identifier is kept unmodified shorter prefix, the 64-bit interface identifier is kept unmodified
during translation. However, the /64 boundary might be broken as during translation. However, the /64 boundary might be changed as
long as the "inside" and "outside" prefix has the same length. long as the "inside" and "outside" prefixes have the same length.
o ILNP: Identifier-Locator Network Protocol (ILNP) [RFC6741] is o ILNP: Identifier-Locator Network Protocol (ILNP) [RFC6741] is
designed around the /64 boundary, since it relies on locally designed around the /64 boundary, since it relies on locally
unique 64-bit interface identifiers. While a re-design to use unique 64-bit interface identifiers. While a re-design to use
longer prefixes is not inconceivable, this would need major longer prefixes is not inconceivable, this would need major
changes to the existing specification for the IPv6 version of changes to the existing specification for the IPv6 version of
ILNP. ILNP.
o shim6: The Multihoming Shim Protocol for IPv6 (shim6) [RFC5533] in o shim6: The Multihoming Shim Protocol for IPv6 (shim6) [RFC5533] in
its insecure form treats IPv6 address as opaque 128-bit objects. its insecure form treats IPv6 address as opaque 128-bit objects.
skipping to change at page 12, line 48 skipping to change at page 12, line 48
| Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE | | Win XP SP2 | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+ +--------------------+--------+-------+--------+---------+
| Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE | | Win 7 Home Premium | IGNORE | LOCAL | LOCAL | ROUTE |
+--------------------+--------+-------+--------+---------+ +--------------------+--------+-------+--------+---------+
Table 2: Processing of ND options with prefixes shorter than /64 Table 2: Processing of ND options with prefixes shorter than /64
The results obtained can be summarized as follows: The results obtained can be summarized as follows:
o the "A" bit in the Prefix Information Options is honored only if o the "A" bit in the Prefix Information Options is honored only if
the prefix length is 64. At least for the case of a prefix longer the prefix length is 64. At least for the case where the IID
than /64, this is consistent with [RFC4862], which defines the length is defined to be 64 bits in the corresponding link-type-
case where the sum of the link-local prefix length and the IID specific document, which is the case for all currently published
length is larger than 128 as an error consition. such documents, this is consistent with [RFC4862], which defines
the case where the sum of the advertised prefix length and the IID
length does not equal 128 as an error condition.
o the "L bit in the Prefix Information Options is honored for any o the "L bit in the Prefix Information Options is honored for any
arbitrary prefix length (whether shorter or longer than /64). arbitrary prefix length (whether shorter or longer than /64).
o nodes that support the Route Information Option, allow such routes o nodes that support the Route Information Option, allow such routes
to be specified with prefixes of any arbitrary length (whether to be specified with prefixes of any arbitrary length (whether
shorter or longer than /64) shorter or longer than /64)
4.3.2. Other Observations 4.3.2. Other Observations
Participants in the V6OPS working group have indicated that some Participants in the V6OPS working group have indicated that some
forwarding devices have been shown to work correctly with long prefix forwarding devices have been shown to work correctly with long
masks such as /80 or /96. Indeed, it is to be expected that longest prefixes such as /80 or /96. Indeed, it is to be expected that
prefix match based forwarding will work for any prefix length, and no longest prefix match based forwarding will work for any prefix
reports of this completely failing have been noted. Also, DHCPv6 is length, and no reports of this completely failing have been noted.
in widespread use without any dependency on the /64 boundary. Also, DHCPv6 is in widespread use without any dependency on the /64
Reportedly, there are deployments of /120 subnets configured using boundary. Reportedly, there are deployments of /120 subnets
DHCPv6. configured using DHCPv6.
It has been reported that at least one type of switch has a content- It has been reported that at least one type of switch has a content-
addressable memory limited to 144 bits. This means that filters addressable memory limited to 144 bits, which is indeed a typical
value for commodity components [TCAM]. This means that filters
cannot be defined based on 128-bit addresses and two 16-bit port cannot be defined based on 128-bit addresses and two 16-bit port
numbers; the longest prefix that could be used in such a filter is / numbers; the longest prefix that could be used in such a filter is a
112. /112.
There have been definite reports that some routers have a performance There have been definite reports that some routers have a performance
drop-off or even resource exhaustion for prefixes longer than /64, drop-off or even resource exhaustion for prefixes longer than /64,
due to design issues. In particular, some routing chip designs due to design issues. In particular, some routing chip designs
allocate much less space for longer prefixes than for prefixes up to allocate much less space for longer prefixes than for prefixes up to
/64, for the sake of savings in memory, power and lookup latency. /64, for the sake of savings in memory, power and lookup latency.
Some devices need special-case code to handle point-to-point links Some devices need special-case code to handle point-to-point links
according to [RFC6164]. according to [RFC6164].
4.4. Implementation and deployment issues 4.4. Implementation and deployment issues
From an early stage, implementations and deployments of IPv6 assumed From an early stage, implementations and deployments of IPv6 assumed
the /64 subnet length, even though routing was based on variable- the /64 subnet length, even though routing was based on prefixes of
length subnet masks of any length. As shown above, this became any length. As shown above, this became anchored in many
anchored in many specifications (Section 4.1) and in important specifications (Section 4.1) and in important aspects of
aspects of implementations commonly used in local area networks implementations commonly used in local area networks (Section 4.3).
(Section 4.3). In fact, a programmer might be lulled into assuming a In fact, a programmer might be lulled into assuming a comfortable
comfortable rule of thumb that subnet prefixes are always /64 and an rule of thumb that subnet prefixes are always /64 and an IID is
IID is always of length 64. Apart from the limited evidence in always of length 64. Apart from the limited evidence in
Section 4.3.1, we cannot tell without code inspections or tests Section 4.3.1, we cannot tell without code inspections or tests
whether existing stacks are able to handle a flexible IID length, or whether existing stacks are able to handle a flexible IID length, or
whether they would require modification to do so. A conforming whether they would require modification to do so. A conforming
implementation of an IPv6-over-foo that specifies a 64 bit IID for implementation of an IPv6-over-foo that specifies a 64 bit IID for
foo links will of course only support 64. But in a well designed foo links will of course only support 64. But in a well designed
stack, the IP layer itself will treat that 64 as a parameter, so stack, the IP layer itself will treat that 64 as a parameter, so
changing the IID length in the IPv6-over-foo code should be all that changing the IID length in the IPv6-over-foo code should be all that
is necessary. is necessary.
The main practical consequence of the existing specifications is that The main practical consequence of the existing specifications is that
deployments in which longer subnet prefixes are used cannot make use deployments in which longer subnet prefixes are used cannot make use
of SLAAC-configured addresses, and require either statically of SLAAC-configured addresses, and require either manually configured
configured addresses or DHCPv6. To reverse this argument, if it was addresses or DHCPv6. To reverse this argument, if it was considered
considered desirable to allow auto-configured addresses with subnet desirable to allow auto-configured addresses with subnet prefixes
prefixes longer than /64, all of the specifications identified above longer than /64, all of the specifications identified above as
as depending on /64 would have to be modified, with due regard to depending on /64 would have to be modified, with due regard to
interoperability with unmodified stacks. In fact interoperability with unmodified stacks. In fact
[I-D.ietf-6man-stable-privacy-addresses] allows for this possibility. [I-D.ietf-6man-stable-privacy-addresses] allows for this possibility.
Then modified stacks would have to be developed and deployed. It Then modified stacks would have to be developed and deployed. It
might be the case that some stacks contain dependencies on the /64 might be the case that some stacks contain dependencies on the /64
boundary which are not directly implied by the specifications, and boundary which are not directly implied by the specifications, and
any such hidden dependencies would also need to be found and removed. any such hidden dependencies would also need to be found and removed.
At least one DHCPv6 client unconditionally installs a /64 prefix as At least one DHCPv6 client unconditionally installs a /64 prefix as
on-link when it configures an interface with an address, although on-link when it configures an interface with an address, although
some specific operating system vendors seem to change this default some specific operating system vendors seem to change this default
skipping to change at page 16, line 39 skipping to change at page 16, line 44
valuable comments were received from Ran Atkinson, Fred Baker, Steven valuable comments were received from Ran Atkinson, Fred Baker, Steven
Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter, Jen Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter, Jen
Linkova, Philip Matthews, Mark Smith, Tatuya Jinmei, Fred Templin, Linkova, Philip Matthews, Mark Smith, Tatuya Jinmei, Fred Templin,
Stig Venaas, and numerous other participants in the 6MAN working Stig Venaas, and numerous other participants in the 6MAN working
group. group.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
8. Change log [RFC Editor: Please remove] 8. Change log [RFC Editor: Please remove]
draft-ietf-6man-why64-01: language improvements, added TCAM
reference, 2014-05-07.
draft-ietf-6man-why64-00: WG adoption, WG comments, including major draft-ietf-6man-why64-00: WG adoption, WG comments, including major
text reorganisation: 3 main sections describe advantages of fixed text reorganisation: 3 main sections describe advantages of fixed
length IID, arguments for shorter lengths, and expected effects of length IID, arguments for shorter lengths, and expected effects of
varying the length, 2014-04-11. varying the length, 2014-04-11.
draft-carpenter-6man-why64-01: WG comments, added experimental draft-carpenter-6man-why64-01: WG comments, added experimental
results, implementation/deployment text, 2014-02-06. results, implementation/deployment text, 2014-02-06.
draft-carpenter-6man-why64-00: original version, 2014-01-06. draft-carpenter-6man-why64-00: original version, 2014-01-06.
skipping to change at page 21, line 23 skipping to change at page 21, line 23
"IPv6 Home Networking Architecture Principles", draft- "IPv6 Home Networking Architecture Principles", draft-
ietf-homenet-arch-13 (work in progress), March 2014. ietf-homenet-arch-13 (work in progress), March 2014.
[I-D.ietf-v6ops-64share] [I-D.ietf-v6ops-64share]
Byrne, C., Drown, D., and V. Ales, "Extending an IPv6 /64 Byrne, C., Drown, D., and V. Ales, "Extending an IPv6 /64
Prefix from a 3GPP Mobile Interface to a LAN link", draft- Prefix from a 3GPP Mobile Interface to a LAN link", draft-
ietf-v6ops-64share-10 (work in progress), April 2014. ietf-v6ops-64share-10 (work in progress), April 2014.
[I-D.templin-aerolink] [I-D.templin-aerolink]
Templin, F., "Transmission of IPv6 Packets over AERO Templin, F., "Transmission of IPv6 Packets over AERO
Links", draft-templin-aerolink-13 (work in progress), Links", draft-templin-aerolink-18 (work in progress), May
April 2014. 2014.
[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", IEEE Std 802-2001 Networks: Overview and Architecture", IEEE Std 802-2001
(R2007), 2007. (R2007), 2007.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC4887] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network [RFC4887] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network
Mobility Home Network Models", RFC 4887, July 2007. Mobility Home Network Models", RFC 4887, July 2007.
skipping to change at page 22, line 5 skipping to change at page 22, line 5
Neighbor Discovery Problems", RFC 6583, March 2012. Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol [RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol
(ILNP) Engineering Considerations", RFC 6741, November (ILNP) Engineering Considerations", RFC 6741, November
2012. 2012.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC Combination of Stateful and Stateless Translation", RFC
6877, April 2013. 6877, April 2013.
[TCAM] Meiners, C., Liu, A., and E. Torng, "Algorithmic
Approaches to Redesigning TCAM-Based Systems", ACM
SIGMETRICS'08 467-468, 2008.
Authors' Addresses Authors' Addresses
Brian Carpenter (editor) Brian Carpenter (editor)
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland 1142 Auckland 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com Email: brian.e.carpenter@gmail.com
 End of changes. 24 change blocks. 
56 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/