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

From: Usman Latif <[email-masked]>
Date: Fri, 21 Sep 2012 00:03:53 -0700 (PDT)

Hi,
 
I am one of the many Network Engineers/architects that are today on the verge of assigning IPv6 addressing in their core networks.

There are two points that I would like to open a debate on and really looking for some substantial reasoning and logic on.
 
And the points are: 
 
Q1: "What is the IETF best-practice / recommendation for assigning IPv6 addressing to strictly point-to-point links where we know there will never be more than one device on each end of the link for the foreseeable future"
 
Q2: "What is the IETF best practice / recommendation for assigning IPv6 addressing for Loopback interfaces on routers"

I have gone through some RFCs (RFC 4291, RFC 5375, RFC 3627, RFC 3177 / 6177 and RFC 6164)
 
As a network engineer with IPv4 and some IPv6 background, I am inclined to use /127 addressing on strictly point to point links and /128 for Loopbacks - but after discussion with peers in the industry have learnt that although the recommendations are to use /127 for p2p and /128 for Loopbacks, its better to reserve the whole /64 for each p2p inter-router link.
 
There are conflicting recommendations and are not giving me the right direction e.g.:
RFC 4291 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."
 
RFC 5375 states: "126-bit subnet prefixes are typically used for point-to-point links similar to a the IPv4 address-conservative /30 allocation for point-to-point links.  The usage of this subnet address length does not lead to any considerations beyond those discussed earlier in this section, particularly those related to the 'u' and 'g' bits (see B.2.4.)
For /128 assignment..... 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"
 
My main concern is the following:
 
Some standards "assume" that the lower-order 64-bits of an IPv6 address are reserved for host addresses (following from an EUI-64 format) and you see some specific addresses in those lower order 64 bits reserved for specific purposes (router anycast, embedded IPv6 RP, ISATAP etc). This gives indication that in future if vendors continue on with this assumption of 64 bits host space and dont take into account that there may be deployments out there where operators / carriers have chosen to use /126 or /127s on their p2p inter-router links from the same /64 subnets - this could lead to major issues for both the operators and their end-customers.
 
I suppose bodies like IETF all need to ensure that there are definitive guidelines around addressing architectures so that future implementations of procotol stacks and features donot overlap with bits in the IPv6 address space that could potentially be used on p2p inter-router links (i.e. there could be address assignments done based on subnet prefixes longer than /64 on p2p links) and obviously if some implementation in future uses the bits from that space, it would become a big challenge for operators and their customers to re-address their p2p inter-router links.
 
In summary we need clear guidelines on the following:

- For IPv6 implementation on strictly p2p (inter-router links) and for device Loopbacks, we can use /127 and /128 respectively but are required to reserve the whole corresponding /64 for each of the p2p links (and loopbacks) i.e. a seperate /64 needs to be reserved for each p2p and loopback.

OR

- For IPv6 implementation on strictly p2p (inter-router links) and for device Loopbacks, we can use /127 and /128 respectively and are NOT reuqired to reserve the whole corresponding /64 for each of the p2p links (and loopbacks) i.e. for example multiple p2p links can be assigned /127 from the same /64 - this has implication that any future implementation of protocol/stack needs to be careful not to "assume" and reserve some or all of the lower-64 bits in IPv6 address for its implementation.

Thanks
Usman

Email: [email-masked]

---

From: Usman Latif <[email-masked]>
Date: Sat, 22 Sep 2012 00:16:04 +1000

Thanks for the feedback.
I just want to confirm something.

You wrote: 
"If you choose to do this, it is further recommended that you reserve the entire /64 so that - if needed in the future - you can expand this configuration _without_ a major renumbering event."

This is the essence of what I want the IETF to put in one of its address recommendation RFCs because I have yet to see an RFC that says when you assign a /127 to a p2p link, you should/must reserve the whole parent /64 for that p2p link also.

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.

Also you didn't talk about loopbacks at all.

IMO any single loopback although a /128 should also have the whole parent /64 assigned to it because the issues with not doing that are pretty much the same as for p2p links

What do you think?

Regards,
Usman

Sent from my iPhone

On 21/09/2012, at 10:02 PM, TJ <[email-masked]> wrote:

> Right - effectively, the standard says the best answer is to use /64s everywhere.  FWLIW, I agree :).
> 
> WRT Point-to-point links (only, any multi-access link REALLY should be a /64): For those that insist on using something else, it is loosely accepted that a /127 can work (as long as the platform doesn't do the Subnet Router Anycast ridiculousness).  This has the benefit of leaving no unused addresses on link and avoiding a potential ping-pong attack.  If you choose to do this, it is further recommended that you reserve the entire /64 so that - if needed in the future - you can expand this configuration _without_ a major renumbering event.
> 
> 
> HTH!
> /TJ
> 
> 
> On Fri, Sep 21, 2012 at 3:03 AM, Usman Latif <[email-masked]> wrote:
> Hi,
>  
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
>

---

From: TJ <[email-masked]>
Date: Fri, 21 Sep 2012 10:29:44 -0400

On Fri, Sep 21, 2012 at 10:16 AM, Usman Latif <[email-masked]> wrote:

> "If you choose to do this, it is further recommended that you reserve the
> entire /64 so that - if needed in the future - you can expand this
> configuration _without_ a major renumbering event."
>
> This is the essence of what I want the IETF to put in one of its address
> recommendation RFCs because I have yet to see an RFC that says when you
> assign a /127 to a p2p link, you should/must reserve the whole parent /64
> for that p2p link also.
>
> 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.
>

Right, each PtP link should have it's own /64 assigned.
It should also be so-configured, but if you choose to alter that something
else (e.g. - a /127) may be configured.
But with that specific /64 still reserved per PtP link!

> IMO any single loopback although a /128 should also have the whole parent
> /64 assigned to it because the issues with not doing that are pretty much
> the same as for p2p links
>

Correct, in fact - I intentionally excluded them :).
I would say a single /64 per site (or whatever demarcation / term you
choose to use) should be reserved for the purpose of assigning /128s to
loopbacks.  Not a /64 per loopback, a /64 per ~site to cover all of the
loopbacks within that ~site.
*I presume 18BB loopback addresses per ~site is sufficient? ;)*

/TJ

---

From: "George, Wes" <[email-masked]>
Date: Fri, 21 Sep 2012 15:23:18 -0400

Responding to  a couple of different things below inline with [WEG]

From: [email-masked] [mailto:[email-masked]] On Behalf Of Usman Latif
>>"If you choose to do this, it is further recommended that you reserve the entire /64 so that - if needed in the future - you can expand this configuration _without_ a major renumbering event."

[WEG] I’m not sure that renumbering P2P links is comparatively harder than changing the subnet mask, nor would I characterize one as a major renumbering event and the other not. You still have to touch all links, all devices, the only difference would be for things that are configured to use the link IP to communicate with the router, and a lot of those can be managed using make before break provisioning.  There are several IETF documents (and a whole WG) covering how to manage renumbering in a more painless fashion, and this is one that is pretty straightforward.

>>This is the essence of what I want the IETF to put in one of its address recommendation RFCs because I have yet to see an RFC that says when you assign a /127 to a p2p link, you should/must reserve…

[WEG] I think that part of the reason you haven’t seen that RFC is that there’s an argument to be made to the contrary as well – there’s some value from a configuration management and operational perspective in being able to use one line of config to manage things like route aggregation, filtration, management tools access, access lists, etc.  Yes, you can do that with a larger block (e.g. allocate the top /48 of your /32 for infrastructure) but that adds a lot of addresses to be permitted through the filters that simply aren’t necessary nor will ever be used, and exposes you to other attack vectors in a way that isn’t necessarily justifiable, at least IMO. This is very much a case of YMMV, so I’m not sure that “reserve the whole /64 for each /127” is universally something we could or should recommend, especially if it’s mainly a “just in case, you never know what craziness those protocol wonks in IETF might come up with that would break it in the future...mumble mumble…” kind of reason.

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

[WEG] Given the fact that there is a standard that documents the use of a /127 for P2P links (6164), future standards can’t use lower order 64 bits for special purposes without considering the potential impact to this standard, and even if the standard didn’t exist, the existing installed base cannot be ignored in good conscience. The question to ask here is what problem we’d be trying to solve with “future standards that use lower-order 64 bits for special purposes” that would make supporting it necessary on P2P links where the IP address assigned often doesn’t even matter except for diagnostics? In many cases, the P2P link neither sources nor receives traffic except the odd ICMP response, and even that type of traffic could be configured to use the loopback (see also ip unnumbered). Some carriers don’t even put those links in their IGP for security reasons. To underscore the relative unimportance of the P2P link address, there are even discussions happening within IETF right now about using ULA space for P2P internal links. (Note: I’m just noting that the discussion is happening, not endorsing it). Not all implementations fit this model, but I think the risk of the need for a renumber in this case is being oversold somewhat. The reality is that few of us are going to get the numbering plan 100% right the first time, no matter how smart we try to be in the way that we future-proof our allocation plan, because there’s no one size fits all solution. We can talk about best practice based on what we know today, but anything more is just educated guessing, and my 8 ball is no better than anyone else’s.

On 21/09/2012, at 10:02 PM, TJ <[email-masked]> wrote:
>>WRT Point-to-point links (only, any multi-access link REALLY should be a /64): For those that insist on using something else, it is loosely accepted that a /127 can work

[WEG] Let’s be clear. RFC 6164 is a product of IETF consensus and a proposed standard, and the reason that it was pushed forward and the previous guidance was amended was that multiple large operators came forward and said “this is what we’re *already* doing, you’re welcome to be wrong, or you can update your guidance.” That’s not “loosely accepted”. I’m not saying that it’s universally supported by all IPv6 stacks, nor that consensus = unanimous agreement, but it’s not a corner-case hack either.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: TJ <[email-masked]>
Date: Fri, 21 Sep 2012 15:44:46 -0400

On Fri, Sep 21, 2012 at 3:23 PM, George, Wes <[email-masked]>wrote:

> >>"If you choose to do this, it is further recommended that you reserve
> the entire /64 so that - if needed in the future - you can expand this
> [WEG] I’m not sure that renumbering P2P links is comparatively harder than
> changing the subnet mask, nor would I characterize one as a major
> renumbering event and the other not. You still have to touch all links, all
> devices, the only difference would be for things that are configured to use
> the link IP to communicate with the router, and a lot of those can be
> managed using make before break provisioning.  There are several IETF
> documents (and a whole WG) covering how to manage renumbering in a more
> painless fashion, and this is one that is pretty straightforward.
>

Indeed; however - if your addressing plan needs to be redone
to accommodate the renumbering there may be no small amount of pain
involved.

> [WEG] I think that part of the reason you haven’t seen that RFC is that
> there’s an argument to be made to the contrary as well – there’s some value
> from a configuration management and operational perspective in being able
> to use one line of config to manage things like route aggregation,
> filtration, management tools access, access lists, etc.  Yes, you can do
> that with a larger block (e.g. allocate the top /48 of your /32 for
> infrastructure) but that adds a lot of addresses to be permitted through
> the filters that simply aren’t necessary nor will ever be used, and exposes
> you to other attack vectors in a way that isn’t necessarily justifiable, at
> least IMO. This is very much a case of YMMV, so I’m not sure that “reserve
> the whole /64 for each /127” is universally something we could or should
> recommend, especially if it’s mainly a “just in case, you never know what
> craziness those protocol wonks in IETF might come up with that would break
> it in the future...mumble mumble…” kind of reason.
>

While I do not set out to tell anyone how they must run their network, I do
embrace the idea of minimizing future problems / rework ... :)

> [WEG] Given the fact that there is a standard that documents the use of a
> /127 for P2P links (6164), future standards can’t use lower order 64 bits
> for special purposes without considering the potential impact to this
> standard, and even if the standard didn’t exist, the existing installed
> base cannot be ignored in good conscience. The question to ask here is what
> problem we’d be trying to solve with “future standards that use lower-order
> 64 bits for special purposes” that would make supporting it necessary on
> P2P links where the IP address assigned often doesn’t even matter except
> for diagnostics? In many cases, the P2P link neither sources nor receives
> traffic except the odd ICMP response, and even that type of traffic could
> be configured to use the loopback (see also ip unnumbered). Some carriers
> don’t even put those links in their IGP for security reasons. To underscore
> the relative unimportance of the P2P link address, there are even
> discussions happening within IETF right now about using ULA space for P2P
> internal links. (Note: I’m just noting that the discussion is happening,
> not endorsing it). Not all implementations fit this model, but I think the
> risk of the need for a renumber in this case is being oversold somewhat.
> The reality is that few of us are going to get the numbering plan 100%
> right the first time, no matter how smart we try to be in the way that we
> future-proof our allocation plan, because there’s no one size fits all
> solution. We can talk about best practice based on what we know today, but
> anything more is just educated guessing, and my 8 ball is no better than
> anyone else’s.
>

Again, agreed - but if I can, with relative ease, mitigate a potential
source of that problem I'll take it :).

> >>WRT Point-to-point links (only, any multi-access link REALLY should be a
> /64): For those that insist on using something else, it is loosely accepted
> that a /127 can work
>
> [WEG] Let’s be clear. RFC 6164 is a product of IETF consensus and a
> proposed standard, and the reason that it was pushed forward and the
> previous guidance was amended was that multiple large operators came
> forward and said “this is what we’re *already* doing, you’re welcome to be
> wrong, or you can update your guidance.” That’s not “loosely accepted”. I’m
> not saying that it’s universally supported by all IPv6 stacks, nor that
> consensus = unanimous agreement, but it’s not a corner-case hack either.
>

Fair point - other values for PrefLen have been proposed/mentioned over the
years  (/112 and /126 come to mind).
Just that, IMHO, if you aren't using a /64 a /127 is the next best thing
... I'm always interested in hearing additional justifications / deployment
drivers :).

/TJ

---

From: Usman Latif <[email-masked]>
Date: Sat, 22 Sep 2012 07:35:26 +1000

Thanks Wes for the feedback.
Some points I'd like to further comment on:

i. You mentioned that a re-address event is no different from re-masking the links- 
this is true to an extent but I think changing subnet mask would still be relatively easier to manage than having to re-address all links and loopback interfaces. If we can think of an alternative to re-masking, I am open to consider and talk about it.
I think the impact is considerable and obviously different people may have different views on the extent of impact.
Note: having to renumber loopbacks that have been assigned /128 from the same /64 e.g. is an even bigger risk because protocol adjacencies and a lot of control plane peering relationships are bound to it
Also as a service provider, the impact may not just be limited to the SP backbone but also the SP's end-customers which which means there will be political and legal issues arising out of SP wanting its customers to renumber e.g PE-CE links where the SP may have used /127s from the same /64 block
So IMO the impact is significant!

ii. You also mentioned that IP address on p2p links don't matter and that the risk is being oversold.
I think not all implementations have p2p links with local significance only and also a router may not need to advertise the p2p link to its routing peers but it would still pose a problem if the router is in the forwarding path of packets destined to/from addresses that conflict with specially assigned addresses (current/future) using lower-64 bits of the v6 address space. Again the loopbacks need to be considered here too for the same reason mentioned above.

iii. You raised a point around RFC 6164 that future implementations would need to take it into consideration and in good conscience existing implementations that have used /127 or similar on p2p links from the same /64 block cannot be ignored.
I agree to this point but I think if a new RRC or even the existing RFC 6164 mentions this explicitly that a carrier may or may not have /127 from the same /64 block, it would cover all bases and ensure that we don't end up in any controversy in future.

Regards,
Usman

Sent from my iPhone

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Sep 2012 00:06:04 +0100

> Thanks Wes for the feedback.

...
>> [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: joel jaeggli <[email-masked]>
Date: Fri, 21 Sep 2012 17:28:44 -0700

On 9/21/12 12:03 AM, Usman Latif wrote:
>
>
>
> I suppose bodies like IETF all need to ensure that there are 
> definitive guidelines around addressing architectures so that future 
> implementations of procotol stacks and features donot overlap with 
> bits in the IPv6 address space that could potentially be used on p2p 
> inter-router links (i.e. there could be address assignments done based 
> on subnet prefixes longer than /64 on p2p links) and obviously if some 
> implementation in future uses the bits from that space, it would 
> become a big challenge for operators and their customers to re-address 
> their p2p inter-router links.
>
As an implementer you have to assume the existence of prefixes longer 
than /64 if not, loopback addresses which are /128s would not exist.

in point of fact regarding /127s we have.

http://tools.ietf.org/html/rfc6164

which is about as authoritative as anything gets.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 22 Sep 2012 00:28:46 +0000

Indeed, and I see a sheer wastage in blocking the entire /64 whose one /127 is used on p2p links. 

There are many deployments that already assign bunch of /64 (or lower) prefixes per hierarchy and encode bunch of useful info in 72-96 and then assign thousands of /127s out of each /96 (or encode ipv4 loopbak address in it to get /128 loopback)  to thousand of network infrastructure devices. 

This has pros and cons, but the point is that this should be a deployment choice, not a standard mandate.

Cheers,
Rajiv

Sent from my Phone

---

From: Usman Latif <[email-masked]>
Date: Sat, 22 Sep 2012 23:37:29 +1000

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:

> Thanks Brian, your email clears a lot of ambiguity.
> So I presume it's safe to use /127s on different p2p links from the same /64 subnet. (as per 6164)
> This pretty much means that the second statement in my first email would be the final outcome - i.e.
> 
> Pls note that there is still a mindset out there (call it being apprehensive or being overly cautious) - after speaking with peers in the telco carrier space, they are still assigning /127s and reserving whole /64s for each p2p link separately - this was the basis of my original discussion that we need to "break this myth and be clear and conclusive that operators/carriers etc or for that matter whoever is implementing v6 addressing on p2p links or loopbacks is not required to reserve a whole /64 for each of them separately and its completely a matter of choice whether they choose to assign /127 from the same /64 or keep separate /64 for each instance of p2p link or loopbacks etc"
> 
> Regards,
> Usman
> 
> Sent from my iPhone
> 
> On 22/09/2012, at 9:06 AM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 25 Sep 2012 18:52:50 +0200

perhaps we learned some things over time?

randy