Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks

[Usman Latif <[e-mail]>]

I am not trying to stir up a debate over something that only "I" feel
 
There is clearly two set of recommendations over the same addressing scenario which I am only trying to clarify with the IETF community.

RFC 6164 has recommendations that do not encompass all the recommendations that were put forward in RFC 5375

So although when RFC 6547 moved the RFC 3627 to historical status, it completely ignored that RFC 5375 has additional recommendations for the same /127 and /128 addressing scenarios.

What I am now trying to clarify is - should we consider recommendations in RFC 5375 (section B.2) as obsolete ? 

When the two set of recommendations for /127 assignment i.e. one coming from RFC 6164 and the other coming from RFC 5375 are competing with each other, should we ignore those in 5375 and only comply with 6164

For those who feel that manual (and consecutive) assignment of /127 for p2p links from the same /64 or /128 for loopbacks from the same /64 subnet is not going to cause any overlap - I would recommend to read section B.2 of RFC 5375 and then provide some comments afterwards.
 
 
Regards,
Usman


--- On Wed, 26/9/12, Ole Trøan <[e-mail]> wrote:


From: Ole Trøan <[e-mail]>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
To: "Usman Latif" <[e-mail]>
Cc: "Randy Bush" <[e-mail]>, "[e-mail]" <[e-mail]>
Received: Wednesday, 26 September, 2012, 1:06 PM


> Also its a good idea to encompass recommendations for p2p and loopbacks (and for that matter any assignment where prefix length is going beyond /64 into smaller subnets) into one standard track because the cautions and potential overlap issues that may exist for a /127 would pretty much be similar for /128 or any prefix that goes into the lower-64 bit territory...

> One major concern I have with using /127 and /128 on p2p and loopbacks respectively is that we need to be careful that there are existing (ISATAP etc) and potentially future implementations that would use/reserve bits in the lower 64 bits -so unless we set aside bit boundaries in the lower 64 bits, we are likely to overlap with these... which is why if we use /127 with a whole /64 reserved for the p2p subnet, then it should be okay but if /127 or /128s are numbered from the same /64 consecutively, then obviously its likely that the reserved bits used by other implementations would overlap. When this happens, any scenario where the router (which has this overlap) is SRC/DST of packets would be confused whether to interpret those lower-64 bits as simple global unicast prefix or try to treat the lower-64 bits in a different way (according to the protocol implementation which is using that bit pattern).

a few general points:
- the 64 bit boundary is a "policy". implementations should handle any prefix length.
   implementations should, and as far as I know do, consider all bits in the address as transparent.
- a loopback interface using a /128 cannot by definition overlap with anything else. 
- for a point to point link the operator should know if there applications at either of two end points requiring the use of
   reserved addresses, if so the link must use a /64 otherwise /127 is fine.

these are operational choices, and I don't see a need to change IPv6 addressing architecture or protocol specifications.

cheers,
Ole