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

From: Usman Latif <[email-masked]>
Date: Tue, 25 Sep 2012 21:00:32 -0700 (PDT)

Hi,

Based on the response i have received so far it appears that there are still gaps in our approach towards IPv6 addressing (maybe the original way the stack was written also is not ideal - but lets not go there and try to find the best way out with what we've got)

IMO RFC 6164 although being very authoritative and direct about use of /127 (from the same /64) on each p2p link is not giving us any insight into other current (or future) reserved addresses that were explained in more detail in RFC 5375 so in doing that RFC 6164 is raising doubts in our minds about using /127 (from the same /64) for p2p router links and also there is no talk in RFC 6164 about use of /128 loopbacks and what cautions are needed there - whereas we saw that in RFC 5375 (although informational only) there was a more comprehensive discussion around use of shorter length prefixes for p2p links and loopbacks

The motivations for RFC 6164 can also be debated here e.g:

Ping-Pong issue is dealt with RFC 4443

Neighbor Cache exhaustion on p2p links can be controlled if we use filters to restrict a router to perform ND for only the known IP on the far-end of the p2p link or a similar mechanism that provides control over creating neighbor cache only for the known IP on the farend (although this would require some additional config overhead but is worth considering)

Also there are so many other scenarios where this would still pose an issue wherever we have /64 assigned so better to provide a more holistic solution than to only consider router p2p links only.

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).

Pls let me know if there is work being done in this space...

Regards
Usman

On 26/09/2012, at 2:52 AM, Randy Bush <[email-masked]> wrote:

perhaps we learned some things over time?

randy

From: Usman Latif <[email-masked]>
Date: 25 September 2012 11:30:09 AM AEST
To: [email-masked]
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks

To summarize the whole discussion and clarify the last points:

RFC 3627 discouraged use of /127 and most RFCs up until RFC 5375 recommended using /64 even on p2p inter-router links.

RFC 6164 recommends using /127 on p2p links - however there is no explicit recommendation for /128 on device Loopbacks (e.g. for peering establishment etc)

The specific statement in RFC 6164 states that while using /127, care should be taken not to use following reserved address:

(a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be assigned 
as unicast addresses, to avoid colliding with the Subnet-Router anycast address 
(b) Addresses in which the rightmost 64 bits are assigned the highest 128 values 
(i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: ffff) SHOULD NOT be used as unicast addresses, 
to avoid colliding with reserved subnet anycast addresses

Whereas the RFC 5375 recommended not to use the following:

it is recommended to take the 'u' and 'g' bits into consideration and to make sure that there is no overlap with any of the following well-known addresses:
   o  Subnet Router Anycast Address
   o  Reserved Subnet Anycast Address
   o  Addresses used by Embedded-RP
   o  ISATAP Addresses
 
So the questions that come out of the above discussion are:

- What are the recommendations for device Loopbacks and what reserved address ranges need to be considered by network operators while using /128s for Loopbacks (should these be followed based on RFC 5357?)

- Which recommendations out of RFC 5375 and RFC 6164 should be followed by network operators while using /127s for inter-router point-to-point links

I (like many other engineers) would be looking for some feedback on the above two points to get a clear guideline for p2p and loopback addressing

Regards
Usman

--- On Sat, 22/9/12, Usman Latif <[email-masked]> wrote:

From: Usman Latif <[email-masked]>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
To: "[email-masked]" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>
Received: Saturday, 22 September, 2012, 6:07 PM

Forgot to include IPv6 group email in my last email (below)
Further to that, RFC 6164 states in the same statement that:

"When assigning and using any /127 prefixes, the following considerations 
apply. Some addresses have special meanings, in particular addresses 
corresponding to reserved anycast addresses. When assigning prefixes 
(and addresses) to links, care should be taken to ensure that addresses 
reserved for such purposes aren't inadvertently assigned and used as 
unicast addresses. Otherwise, nodes may receive packets that they are 
not intended to receive. Specifically, assuming that a number of point-to-point 
links will be numbered out of a single /64 prefix: 
 (a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be assigned 
as unicast addresses, to avoid colliding with the Subnet-Router anycast address 
(b) Addresses in which the rightmost 64 bits are assigned the highest 128 values 
(i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: ffff) SHOULD NOT be used as unicast addresses, 
to avoid colliding with reserved subnet anycast addresses"

One question that comes up here is that why did RFC 6164 exclude
additional recommendations that were stated in RFC 5375 which stated:

"it is recommended to take the 'u' and 'g' bits into consideration and to make sure that there is no overlap with any of the following well-known addresses:
   o  Subnet Router Anycast Address
   o  Reserved Subnet Anycast Address
   o  Addresses used by Embedded-RP
   o  ISATAP Addresses"

So should one only care about excluding reserved addresses as per RFC 6164 or should we also care about reserving addresses as per RFC 5375?

5375 seems to have more special addresses covered and is also a hint that in the hindsight there could be more special addresses in future using bits in lower 64-bit portion of v6 address(?)

I wonder if it's possible to leave portions of lower 64 bits in v6 address for special purposes (both EUI-64 and non EUI-64) so that we get best of both worlds i.e. leave room open for future development and assignment of special addresses using portions in lower 64 bits reserved for this purpose and at the same time allowing users to tap into the lower 64 bit address space for general address assignment purposes using portions that are not reserved for this purposes...

Regards,
Usman

Sent from my iPhone

On 22/09/2012, at 12:35 PM, Usman Latif <[email-masked]> wrote:

On 22/09/2012, at 9:06 AM, Brian E Carpenter <[email-masked]> wrote:

On 21/09/2012 22:35, Usman Latif wrote:

Thanks Wes for the feedback.

...

Without this stated clearly there is likely to be some instances where readers interpret it the wrong way and end up assigning multiple p2p links with /127 subnets from a single given /64 and end up having to re-address their network in future when/if future standards use lower order 64 bits for special purposes.

[WEG] Given the fact that there is a standard that documents the use of a /127 for P2P links (6164), 

Wes, I think that statement is even a bit weak, since 6164 actually says:

"assuming that a number of point-to-point links will be numbered out of a single /64 prefix:"

so it is very clear: it is allowed by the standard to share a /64 among

however many pt2pt links the operator cares to. This is *not* a wrong

interpretation.

As you say, any future work will need to take account of this.

Brian

---

From: [email-masked]
Date: Wed, 26 Sep 2012 06:40:26 +0200 (CEST)

> IMO RFC 6164 although being very authoritative and direct about use of /127 (from the same /64) on each p2p link is not giving us any insight into other current (or future) reserved addresses that…

*You* may feel that RFC 6164 is raising doubt. I don't. I'm glad to see
an RFC that fills a needed hole, and clearly describes something which
is already used by service providers (including my employer).

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Ole Trøan <[email-masked]>
Date: Wed, 26 Sep 2012 10:36:11 +0200

> 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 wo…

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

---

From: Jon Steen <[email-masked]>
Date: Wed, 26 Sep 2012 10:44:13 -0400

Some vendors are permitting the use of the link local interface address to be used in next hop routing there for negating the need to us additional unicast addresses on P2P links. When using routing protocols of OSPFv3 and BGP, I have used /128 loopback global unicast and configured advertisements for aggregated prefixes between a /32 and /64 with policy based routing. This has minimized the potential for overlap and has also allowed the routing tables to be much smaller.  Has anyone else tried this approach?

V/R

Jon Steen

On Sep 26, 2012, at 4:36 AM, Ole Trøan <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Usman Latif <[email-masked]>
Date: Wed, 26 Sep 2012 17:08:06 -0700 (PDT)

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-masked]> wrote:

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

a few general points:

cheers,
Ole

---

From: SM <[email-masked]>
Date: Wed, 26 Sep 2012 17:22:38 -0700

Hi Usman,
At 17:08 26-09-2012, Usman Latif wrote:
>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 ?

See http://www.ietf.org/mail-archive/web/v6ops/current/msg13685.html

Regards,
-sm

---

From: Usman Latif <[email-masked]>
Date: Wed, 26 Sep 2012 18:03:19 -0700 (PDT)

Hi,
 
I am still confused - And I'll try to explain my confusion.

While we can still go ahead and say recommendations on /127 that exist in section B.2.2 of RFC 5375 no longer hold true and the recommendations on /127 that exist in RFC 6164 prevail over 5375

The above is fine - but if you read RFC 5375 section B.2 in detail, it talks about all prefix lengths above /64 and encompasses /128 for loopbacks in its recommendations as well (section B.2.3) - whereas RFC 6164 does NOT talk about addressing for loopback interfaces at all

What is even more confusing is that if you consider the recommendations for /128 as per RFC 5375 as TRUE, then you go back into a loop thinking that there should be no discrimination between /127 or /128 because RFC 5375 talks about "overlap" and restricts / cautions us about reserved bits that should not be used for /128 assignments and uses the same recommendation for /127

Question: How can those reserved bits NOT be a problem for /127 assignments but a problem for /128 assignments?

This is why I think if (for whatever reason which I am still trying to digest) we have decided to use /127 without considering reserved bits for IEEE or other protocols, we need to provide similar or atleast some recommendations for /128 on loopbacks that sit inline with what we have recommended in RFC 6164 - otherwise the confusion still exists !!
 
I hope I am able to convey my confusion correctly... and this is shared by many peers in the industry that I have spoken to... hence the reason in practice although they are assigning /127 on p2p links, they are still reserving the whole parent /64 for each p2p link seperately......

Regards
Usman

--- On Thu, 27/9/12, SM <[email-masked]> wrote:

From: SM <[email-masked]>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
To: "Usman Latif" <[email-masked]>
Cc: [email-masked]
Received: Thursday, 27 September, 2012, 4:52 AM

Hi Usman,

Regards,
-sm

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Sep 2012 06:47:42 +0200

> scenario which I am only trying to clarify with the IETF community.

no.  but please go do whatever you want in your network and stop trying
to stir a long cold pot

randy

---

From: joel jaeggli <[email-masked]>
Date: Wed, 26 Sep 2012 22:10:25 -0700

>> scenario which I am only trying to clarify with the IETF community.
There aren't really. The world moved on from 3627 and the scenario 
described in 6164 represents both observed reality and expectations.

---

From: Usman Latif <[email-masked]>
Date: Wed, 26 Sep 2012 22:51:39 -0700 (PDT)

--- On Thu, 27/9/12, Randy Bush <[email-masked]> wrote:

From: Randy Bush <[email-masked]>
Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks
To: "Usman Latif" <[email-masked]>
Cc: "Ole Trøan" <[email-masked]>, "[email-masked]" <[email-masked]>
Received: Thursday, 27 September, 2012, 9:17 AM

randy

I would only if I owned the whole internet :)

If you have links to any previous discussions / blogs on this long cold pot, pls point me to them so I can convince myself that both 5375 and 6164 have same recommendations for /127 (and /128)
 
Usman

---

From: George Xu <[email-masked]>
Date: Thu, 27 Sep 2012 16:48:22 +1000

> described in 6164 represents both observed reality and expectations.
The confusion aired from Usman is also with me.

The potential address overlap in lower-64 bit space while assigning prefix
longer than /64 (in RFC5375) seems to me a valid concern.I am wondering if
the community regarded these potential address overlaps are no longer of
concerns at all while RFC 6164 was published.

George

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Sep 2012 09:10:32 +0200

> If you have links to any previous discussions / blogs on this long
> cold pot, pls point me to them so I can convince myself that both 5375
> and 6164 have same recommendations for /127 (and /128)

go read the discussion on 6164

we do not care what you do in your network.  we do care that you blabber
on the list while there is work to be done.

randy

---

From: Usman Latif <[email-masked]>
Date: Thu, 27 Sep 2012 17:56:19 +1000

Sorry i didn't realize that you own this list - my apologies
If you really have work to do pls disregard my emails instead of responding with meaningless emails that are not helping either of us...

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Sep 2012 09:57:32 +0200

> If you really have work to do pls disregard my emails instead of
> responding with meaningless emails that are not helping either of
> us...

<plonk!>

---

From: Usman Latif <[email-masked]>
Date: Thu, 27 Sep 2012 21:43:52 +1000

Hi Joel,

RFC 6164 overriding 3627 seems logical
However, I am looking more from perspective of 5375

Also If one has to "go read the discussion on 6164" to understand it - this is itself an indication that 6164 has not done a good job of providing a conclusive recommendation on use of prefixes with subnet lengths longer than /64

If 6164 was going to override recommendations of 5375, the least one would expect is the RFC 6164 to document the reasons why it felt that the additional considerations provided in section B.2.4  B.2.6 and B.2.7 of RFC5375 are to be ignored or don't hold true anymore- this reasoning should have been made part of the RFC6164...

Instead the 6164 provided reasons around ping-pong issue and neighbor cache issue - both of which appear weak as one is resolved thru 4443 and the other can be resolved thru feature enhancements in the neighbor caching process...

Usman

On 27/09/2012, at 3:10 PM, joel jaeggli <[email-masked]> wrote:

> There aren't really. The world moved on from 3627 and the scenario described in 6164 represents both observed reality and expectations.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Sep 2012 14:12:10 +0100

Usman,

> However, I am looking more from perspective of 5375

RFC 5375 is an Informational document. You are at liberty to read it or not,
and to make use of it or not.

RFC 6164 is a Standards track document. It is of course a voluntary standard
like all IETF standards, but if you claim to implement it, it clearly preempts
an older Informational document such as RFC 5375.

As SM reminded us, it was probably a mistake that RFC 6164 didn't formally
update RFC 5375, but so what? There are many minor inconsistencies between
RFCs. Please don't lose any sleep over it. As long as you aren't accidentally
running SLAAC on a pt2pt link, none of this matters, as far as I can see.

   Brian

P.S. I am now adding this thread to my "ietf-silly-subj" filter.

---

From: Usman Latif <[email-masked]>
Date: Fri, 28 Sep 2012 03:38:00 +1000

I'll conclude on the following points:

i. The only guidance that's out there today for device loopbacks (whether informational or standards track) is 5375 -because 6164 (whether voluntarily or involuntarily) chose not to provide any considerations for /128 loopbacks

ii. A reader following considerations of /128 from 5375 is led to also consider B.2.4  B.2.6 and B.2.7 for any prefixes where the subnet length is longer than /64

iii. If 6164 overrides any previous RFCs, IMO it should provide some reasoning of why it no longer felt that the sections B.2.4. B.2.6 and B.2.7 of 5375 should be considered

Sent from my iPhone

---

From: Usman Latif <[email-masked]>
Date: Fri, 28 Sep 2012 07:39:00 +1000

(Hopefully) my last email on this topic:

- Not only has RFC 6164 failed to properly update RFC 5375 with any reasoning provided for 5375 section(s) B.2.xx

- It has also defied and failed to update RFC 4291 which says (section 2.5.1) - "For all unicast addresses, except those that start with binary value 000, interface IDs are required to be 64 bits long"

- IMO 6164 seems to be justifying actions of those deployments where ppl have simply gone ahead and deployed /127s without properly doing their homework on v6 addressing

- This has put a constraint on greenfield deployments where we are in a position to implement /64s but are now having to deal with a compromise for existing deployments

- We are fine to follow 6164, but since RFCs come and go, if tomorrow the applications demand specific use of interface identifiers in the lower 64-bit space, and you folks send out a new RFC to override 6164, then we'll be required to re-address our network - then "I Will Come Back To Haunt You Guys - if I am alive" :)

Pls don't take me the wrong way, I have read many RFCs and think you have done a great job buy I was never confused the way I am now after successively going through 3627, 4291, 5375 and now 6164....

Regards,
Usman

Sent from my iPhone

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 29 Sep 2012 09:26:25 +0000

See also: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-01 which has been discussed today at the Large Interim Meeting

-éric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jon
> Steen
> Sent: mercredi 26 septembre 2012 16:44
> To: Ole Trøan
> Cc: Usman Latif; [email-masked]
> Some vendors are permitting the use of the link local interface address to be
> used in next hop routing there for negating the need to us additional unicast
> addresses on P2P links. When using routing protocols of OSPFv3 and BGP, I
> have used /128 loopback global unicast and configured advertisements for
> aggregated prefixes between a /32 and /64 with policy based routing. This has
> minimized the potential for overlap and has also allowed the routing tables
> to be much smaller.  Has anyone else tried this approach?
> 
> V/R
> 
> Jon Steen
> 
> >> 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:
> > - for a point to point link the operator should know if there applications
> at either of two end points requiring the use of
> > these are operational choices, and I don't see a need to change IPv6
> addressing architecture or protocol specifications.
> >
> > cheers,
> > Ole

---

From: [email-masked]
Date: Sat, 29 Sep 2012 12:09:04 +0200 (CEST)

> See also: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-01 which has been discussed today at the Large Interim Meeting

Minor point about this draft: To me there's a contradiction between

2.1 "These link-local addresses SHOULD be hard-coded to prevent
the change of EUI-64 addresses when changing of MAC address"

and

2.2 "Lower configuration complexity: LLAs require no specific
configuration"