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

[Usman Latif <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
> 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: [e-mail]
>  
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
>