Gentlemen,

I am one of the many Network Engineers/architects that are today on the verge of assigning IPv6 addressing in their core networks.
I initiated a discussion on the use of /64 and /48 addresses in IPv6 and after some debate was convinced or atleast satisfied that for the near/distant future, using /48s and /64s isnt going to cause address depletion.

However, there is one point that I would like to open a debate on and really looking for some substantial reasoning and logic on.

And this point is: "What is the IETF / IANA / APNIC 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"

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 /126 addressing on strictly point to point links - but after discussion with peers in the industry have learnt that the recommendations are to use /64

I want to know rationale behind using a /64 on strictly point-to-point links where we know there will never be more than one device on each end of the link?

To me using something like a /126 saves and eases the management / support of the p2p links and gives it more predictability and control.

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

I guess what I am looking for is some guidelines on why using subnet length greater than /64 is discouraged and whether there is likelihood that any future implementation (of protocol stacks) of IPv6 could create problems for deployments where engineers/architects have chosen to implement /126 on strictly p2p links

Regards

Usman

--- On Sun, 18/9/11, Usman Latif <osmankh@yahoo.com> wrote:

From: Usman Latif <osmankh@yahoo.com>
Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
To: "Alastair Johnson" <aj@sneep.net>, "sig-policy@lists.apnic.net" <sig-policy@lists.apnic.net>
Received: Sunday, 18 September, 2011, 5:57 PM

Fair enough. I think given the magnitude of address space, wastage becomes a secondary concern.

I guess when you have 281,474,976,710,656 number of /48 subnets available, you can probably afford to not care too much about being wasteful....

This may be a correct assumption so long as the current architectures of subnets residing behind a physical router device continue to hold - because the real surge would occur if virtualized hosts themselves become router devices and further require subnets to reside behind them.

If the above becomes the case, we could have problems...

From: Alastair Johnson <aj@sneep.net>
To: sig-policy@lists.apnic.net
Sent: Sunday, 18 September 2011 9:51 PM
Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses

On 9/18/2011 4:25 AM, Usman Latif wrote:
> So when folks say that "we need atleast /64 subnets for all sites
> (including residential single-user customers) because SLAAC would fail"
> then we should ask ourselves the question:
>
> - Do we have alternatives to SLAAC?
> I'd say yes we do (DHCPv6 and ND)...
>
> - Is SLAAC the reason we are wasting 18446744073709551616 worth of
> address space for residential sites?
> I'd say this is not a good enough reason...

In turn these questions have to be reframed as 'But can we afford to be
prescriptive about how our customers want to address their networks, and
what IPv6 stacks they will have to have in their home?'

While the /64 approach is driven by SLAAC, it's driven because of
established devices and stacks, and that SLAAC was seen as a good
approach for simple home networking.

By removing the ability for your customers to deploy their internal
networks in a way that allows SLAAC to function, you are likely going to
annoy them.

"Why does my gaming device not work when I use ISP-A but does when I
take it to my friend who uses ISP-B?"

> But without going into an endless debate on this subject, I think we all
> have our own perspectives of looking at things and when I initially
> started my query "Need to understand logic behind /64 IPv6 addresses" -
> I can only say that I am only partially convinced and cannot convince
> myself with the reasoning provided so far that its worth wasting that
> much address space using a one-size-fit-all approach of /64 - especially
> as I said in the case of home-user CPEs etc.

I think you will find many people are only partially convinced by /64s
(and SLAAC), however it's not really practical to change things. It's
been a long and hard road to get DHCPv6 operationally deployable.

aj
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy