RE: v6ops-addcon and longer than 64 bit prefixes

["Dunn, Jeffrey H." <jdunn at mitre.org>]

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: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On Behalf Of
Jari Arkko
Sent: Thursday, September 25, 2008 3:02 AM
To: IETF IPv6 Mailing List
Cc: draft-ietf-v6ops-addcon at tools.ietf.org; 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 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------