Colleagues, On reviewing the sections of the document pertaining to prefix lengths longer to 64 bits, I found the following issue:
Section 3.1 of draft-ietf-v6ops-addcon-10 states: " Note that RFC3177 strongly prescribes 64 bit subnets for general usage, and that stateless autoconfiguration option is only defined for 64 bit subnets." RFC 4862 states: " It is the responsibility of the system administrator to ensure that the lengths of prefixes contained in Router Advertisements are consistent with the length of interface identifiers for that link type. It should be noted, however, that this does not mean the advertised prefix length is meaningless. In fact, the advertised length has non-trivial meaning for on-link determination in [RFC4861] where the sum of the prefix length and the interface identifier length may not be equal to 128. Thus, it should be safe to validate the advertised prefix length here, in order to detect and avoid a configuration error specifying an invalid prefix length in the context of address autoconfiguration. Note that a future revision of the address architecture [RFC4291] and a future link-type-specific document, which will still be consistent with each other, could potentially allow for an interface identifier of length other than the value defined in the current documents. Thus, an implementation should not assume a particular constant. Rather, it should expect any lengths of interface identifiers." As a result, RFC 4862 specifically prescribes that prefix lengths other than 64 bits should be supported and does not state that stateless autoconfiguration is defined only for 64 bit prefixes.. FYI, a quick survey of several IPv6 RFC yields the following results: Extended address prefixes are supported, meaning either explicitly prescribed or not proscribed by the following RFCs: Protocol/Technology RFC IPv6 Packet Format 2460, 5095 ICMPv6 2463, 4443, 4884 Neighbor Discovery 2461, 3971, 4861 Stateless Auto-configuration 2462, 4862, 4941 DHCPv6 3315, 3633, 3736, 4361 Path MTU Discovery 1981 Address Architecture 2526, 3879, 4007, 4291 DNS 2671, 3596, 3986 Application Programming Interface 3493, 3542, 3678, 4584, 5014 Interior Gateway Protocols 2740, 4552 Exterior Gateway Protocols 1772, 2545, 4271, 4760 IPsec 3948, 4301, 4302, 4303, 4308, 4809 IKE 4306, 4307, 4945 Architecture 4213 Tunneling 2573, 2784, 4891 MPLS 4798 SNMP 3411, 3412, 3413, 3414 MIB 3289, 4022, 4087, 4113, 4292, 4293, 4295, 4807 MLD 3810, 4604 PIM 4601, 4609 DiffServ 2474, 2475, 2597, 2983, 3086, 3140, 3168, 3246, 3247, 3260, 3494 PPP 5072 Extended address prefixes are proscribed by the following RFCs: Protocol/Technology RFC Addressing Architecture 4291 Stateless Auto-configuration 2460 Cryptographically Generated Addresses 3973, 4581, 4982 Unique Local Addresses 4193 Source-Specific Multicast 3306, 3956, 4607 IPv6 over Link Layers 2464, 2590 My basic question is: What basic engineering problem is solved by proscribing non-64 bit prefixes? Clearly, there are some IPv6 protocols that require a 64 bit prefix; however, the question of whether to deploy these protocols is of an operational rather than an engineering nature. I do not see an overwhelming engineering need to proscribe non-64 bit prefixes. As a result, I suggest that we follow Jon Postel's robustness principle: be conservative in what you do, be liberal in what you accept from others. Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jari Arkko Sent: Thursday, September 25, 2008 3:02 AM To: IETF IPv6 Mailing List Cc: [EMAIL PROTECTED]; V6ops Chairs; Pasi Eronen; Ron Bonica Subject: v6ops-addcon and longer than 64 bit prefixes Folks, Draft-ietf-v6ops-addcon was in IESG review and there was a lot of discussion about the recommendations an earlier version of the draft had about prefix lengths longer than 64 bits. The draft has now been revised to what we believe is reasonably consistent with reality and existing IPv6 address architecture RFCs. However, it would be good to give the 6MAN WG a chance to review the text. Please take a look at the document and the given two sections in particular: http://tools.ietf.org/html/draft-ietf-v6ops-addcon-10 http://tools.ietf.org/html/draft-ietf-v6ops-addcon-10#section-3.1 http://tools.ietf.org/html/draft-ietf-v6ops-addcon-10#appendix-B If there is no objection the draft will be approved. Please comment by September 30th. Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
