> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Ole > Troan > Sent: Wednesday, July 28, 2010 10:40 AM > To: Hemant Singh > Cc: [email protected]; Dave Thaler > Subject: Re: 6man discussion on /127 document @ IETF78 > > > I agree with Dave Thaler from yesterday's discussion in 6man related to the > /127 draft. In the two router scenario for /127, each router is off-link to > the > other and then one has nothing to bother about for anycast address. Folks are > also encouraged to read the IPv6 Subnet Model RFC where off-link has been > clarified - RFC 5942. > > > > So now is there anything left to specify for this /127 issue that needs to > > be > described in draft-kohno-ipv6-prefixlen-p2p? > > my view is entirely different. > the 64 bit boundary is a suggested policy and not normative.
That's not true. RFC 4291 is the addressing architecture and normatively states: 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. Furthermore 129 addresses in every subnet are reserved. See RFC 2526. Within each subnet, the highest 128 interface identifier values are reserved for assignment as subnet anycast addresses. These are assigned by IANA (http://www.iana.org/assignments/ipv6-anycast-addresses) So you cannot have any unicast addresses in any subnet with a prefix longer than /120. However, the point is, you don't need to. You just use the off-link model. > IPv6 is not classful. > two routers on a /127 are on-link to each other. two /128s would make them > off-link. Be careful not to confuse the terminology. The definition of "on-link" is in RFC 4861. > > a off-link node cannot make any assumption on the use of subnet-router > anycast addresses, reserved anycast space or the validity of u/g bits. That's not true either. The RFCs quoted above have no such restriction on what off-link nodes can assume. -Dave > > I support adopting the draft as a working group item now. > > cheers, > Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
