Fred, I am not suggesting that the requirement that a device support 64-bit prefixes be relaxed. I am suggesting that the requirement that prefixes only be 64-bit be relaxed.
Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -----Original Message----- From: Templin, Fred L [mailto:fred.l.temp...@boeing.com] Sent: Monday, December 15, 2008 10:02 AM To: Dunn, Jeffrey H.; The IESG; IETF-Announce Cc: 6man chair; 6man mailing list; steve_eiser...@ao.uscourts.gov; Internet Architecture Board; RFC Editor Subject: RE: Protocol Action: 'Reserved IPv6 Interface Identifiers' toProposed Standard >-----Original Message----- >From: Dunn, Jeffrey H. [mailto:jd...@mitre.org] >Sent: Friday, December 12, 2008 6:18 PM >To: The IESG; IETF-Announce >Cc: 6man chair; 6man mailing list; steve_eiser...@ao.uscourts.gov; Internet Architecture Board; RFC >Editor >Subject: RE: Protocol Action: 'Reserved IPv6 Interface Identifiers' toProposed Standard > >Colleagues, > >I have a question about the following language in section 2.0: > >"For all unicast addresses, except those that start with the binary >value 000, Interface IDs are required to be 64 bits long and to be >constructed in Modified EUI-64 format. " > >Although I do not see a MUST in this sentence, it appears that the >proposed standard is mandating that all interface IDs be 64-bits long. >This is not a requirement in several RFCs listed below. As a result, I >believe that this requirement should be stricken from the document. I respectfully disagree. Without a well-known 64-bit ID requirement, there would be no way to prepare a prepare a well-formed subnet router anycast address, for example. Fred fred.l.temp...@boeing.com >RFC 2460, 5095 >RFC 2463, 4443, 4884 >RFC 2461, 3971, 4861 >RFC 2462, 4862, 4941 >RFC 3315, 3633, 3736, 4361 >RFC 1981 >RFC 2526, 3879, 4007, 4291 >RFC 2671, 3596, 3986 >RFC 3493, 3542, 3678, 4584, 5014 >RFC 2740, 4552 >RFC 1772, 2545, 4271, 4760 >RFC 3948, 4301, 4302, 4303, 4308, 4809 >RFC 4306, 4307, 4945 >RFC 4213 >RFC 2573, 2784, 4891 >RFC 4798 >RFC 3411, 3412, 3413, 3414 >RFC 3289, 4022, 4087, 4113, 4292, 4293, 4295, 4807 >RFC 3810, 4604 >RFC 4601, 4609 >RFC 2474, 2475, 2597, 2983, 3086, 3140, 3168, 3246, 3247, 3260, 3494 >RFC 5072 > >Best Regards, > >Jeffrey Dunn >Info Systems Eng., Lead >MITRE Corporation. >(301) 448-6965 (mobile) > >-----Original Message----- >From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of >The IESG >Sent: Friday, December 12, 2008 12:54 PM >To: IETF-Announce >Cc: 6man chair; Internet Architecture Board; 6man mailing list; RFC >Editor >Subject: Protocol Action: 'Reserved IPv6 Interface Identifiers' to >Proposed Standard > >The IESG has approved the following document: > >- 'Reserved IPv6 Interface Identifiers ' > <draft-ietf-6man-reserved-iids-03.txt> as a Proposed Standard > >This document is the product of the IPv6 Maintenance Working Group. > >The IESG contact persons are Jari Arkko and Mark Townsley. > >A URL of this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-6man-reserved-iids-03.t x >t > >Technical Summary > > Interface Identifiers in IPv6 unicast addresses are used > to identify interfaces on a link. They are required to be > unique within a subnet. Several RFCs have specified > interface identifiers or identifier ranges that have a > special meaning attached to them. An IPv6 node > autoconfiguring an interface identifier in these ranges > will encounter unexpected consequences. Since there is no > centralized repository for such reserved identifiers, this > document aims to create one. > >Working Group Summary > > The 6MAN working group has done extensive reviews of this > document and it reflects the consensus of the working group. > >Document Quality > > This document has been reviewed by numerous members of the > ipv6@ietf.org mailing list and by the 6MAN WG chairs. > >Personnel > > Brian Haberman is the Document Shepherd, and Jari Arkko is > the responsible Area Director. > >RFC Editor Note > > Make this change in Appendix A: > > OLD: > The following RFCs that generate interface identifiers need to be > updated if they wish to avoid conflicts with the reserved interface > identifier ranges. > NEW: > Implementations of the following RFCs need to be aware of the > reserved interface identifier ranges when they allocate new > addresses. Future revisions of these RFCs should ensure that > this is either already sufficiently clear or that the text > is amended to take this into account. > >-------------------------------------------------------------------- >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------