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 <[email protected]> wrote:
From: Ole Trøan <[email protected]>
Subject: Re: IPv6 address assignment for strictly point-to-point links and
Device Loopbacks
To: "Usman Latif" <[email protected]>
Cc: "Randy Bush" <[email protected]>, "[email protected]" <[email protected]>
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
