On Sun, 22 Aug 2010 12:30:25 -0400 Christopher Morrow <christopher.mor...@gmail.com> wrote:
> On Sun, Aug 22, 2010 at 12:09 PM, Miya Kohno <mko...@juniper.net> wrote: > > Hi Mark, > > > >> > *Except /127*, we support rfc3627 and the appendix B.2 of rfc5375. > > They > >> > have properly addressed the implication for using longer prefix than > >> > /64. > >> > > >> > >> So where is there reference to Appendix B.2 of RFC5375 in the /127 > >> draft? The draft does not mention anything about the 70/71 bit issue, > > mark, > what is that issue? that addrarch asks that 70/71 essentially both be > 0? What's the harm in them being 1? Taking the pragmatic approach that > 'bits are bits' in these cases they are not part of the host-address > so they shouldn't matter, I think. > I think people are missing the point. I'm only using the 70/71 issue as an example of something that is discussed in RFC3627, but not discussed or referenced in the /127 draft. If the /127 draft is a rebuttal of RFC3627, and that's how I think it is presented, then I think it needs to at least rebut ever issue relevant to /127s identified in RFC3627. It doesn't do that, with an example of something missing being the discussion or reference to what to do about the 70/71 bits. Other examples - there are probably more - of things I think that should be discussed, beyond what is in RFC3627 - o what is the prefix length of link locals - should it also be /127? o do the links need link locals (I'm partly asking because I've seen some P2P link implementations (tunnels specifically) not have link locals)? o in the ethernet example, is ND NS/NA enabled (the current /127 generally says no)? If not, now is the remote end going to learn the link layer address of the peer? o if /127s mitigate the ND cache exhaustion problem, then why not have ND NS/NA enabled, making them compliant with the ND RFC, where p2p links aren't treated as anything special? This rectifies the ethernet issue too. o The anycast router address isn't the only anycast address that /127s would disable - there are 128 reserved anycast addresses in a subnet. Another one impacted is the Mobile IPv6 Home-Agents anycast. So there are 126 left for future possible use. The existing uses may not be that valuable in point-to-point link scenarios today, but what are the /127s proponent's advice on what to do of another anycast address is assigned that is useful on p2p links? There are potentially others I think. > Curious though, since lots of things seem to be encoded for mysterious > reasons in the 128 bits of an ipv6 address. > It's certainly not unique to IPv6. IPv4 did it of course, with Classes, including Class E where the forwarding mechanism is different, or 0 network meaning this network, and other protocols like Appletalk and IPX have done it too. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
