Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt

From: [email-masked]
Date: Mon, 26 Jun 2017 06:34:30 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations of the IETF.

        Title           : Unique IPv6 Prefix Per Host
        Authors         : John Jason Brzozowski
                          Gunter Van De Velde
	Filename        : draft-ietf-v6ops-unique-ipv6-prefix-per-host-05.txt
	Pages           : 8
	Date            : 2017-06-26

Abstract:
   In some IPv6 environments, the need has arisen for hosts to be able
   to utilize a unique IPv6 prefix, even though the link or media may be
   shared.  Typically hosts (subscribers) on a shared network, either
   wired or wireless, such as Ethernet, WiFi, etc., will acquire unique
   IPv6 addresses from a common IPv6 prefix that is allocated or
   assigned for use on a specific link.

   In most deployments today, IPv6 address assignment from a single IPv6
   prefix on a shared network is done by either using IPv6 stateless
   address auto-configuration (SLAAC) and/or stateful DHCPv6.  While
   this is still viable and operates as designed, there are some large
   scale environments where this concept introduces significant
   performance challenges and implications, specifically related to IPv6
   router and neighbor discovery.

   This document outlines an approach utilising existing IPv6 protocols
   to allow hosts to be assigned a unique IPv6 prefix (instead of a
   unique IPv6 address from a shared IPv6 prefix).  Benefits of unique
   IPv6 prefix over a unique IPv6 address from the service provider
   include improved subscriber isolation and enhanced subscriber
   management.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-05
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 26 Jun 2017 23:04:55 +0900

>         Filename        : draft-ietf-v6ops-unique-ipv6-p

Authors,

here are some comments that I think should be addressed before publication:

   1. The document text says it's a best current practice. ("The Best
   Current Practice documented in this note..."), but the header says the
   intended status is informational.
   2. The suggested router advertisement interval of 300s causes almost
   double the number of RA recommendations for battery-powered hosts laid down
   in RFC 7772. This should be explained somehow (one example way be to say
   that the draft is not primarily intended to recommend practices for
   battery-powered hosts; another would be to say that it's a trade-off
   between battery life and some other desirable property).
   3. The text "(1) a Unique IPv6 prefix (most likely a /64 prefix
   consistent with RFC7608 [RFC7608])" is a non-sequitur. RFC 7608 specifies
   the behaviour of forwarding equipment, and this draft is about prefixes
   assigned to hosts. I'd just say "/64 prefix". If you need a justification
   for /64 (even though the document doesn't justify the other parameters
   either, such as 3600 for the prefix lifetime or 300 for the RA interval),
   then you can say that SLAAC is not defined for any other size, and per RFC
   7421, prefixes longer than 64 bits are outside the current IPv6
   specifications.
   4. In section 4, the draft should say that the prefix should be global,
   since the document uses the terms "UE" "subscriber" and "WiFi hotspot"
   which strongly imply Internet access.
   5. In section 4, the text should not use the terms "/128 unique address"
   or "assign itself a 128 bit IPv6 address". The whole point of assigning a
   /64 to a host is so that it can use as many addresses as it wants/needs
   without impacting the network. This is confusing because just a few lines
   down the draft says that the host needs to do DAD "for each address".

Also a minor suggestion: in section 5, when discussing the inactivity
timer, the draft could say that the inactivity timer is one approach, but
the network could also use other signals to detect that a host has gone
away, for example cues from link-layers such as 802.11 that have clear
disconnection signals.

Cheers,
Lorenzo

---

From: Richard Hartmann <[email-masked]>
Date: Mon, 26 Jun 2017 17:01:19 +0200

On Mon, Jun 26, 2017 at 4:04 PM, Lorenzo Colitti <[email-masked]> wrote:
> The text "(1) a Unique IPv6 prefix (most likely a /64 prefix consistent with
> RFC7608 [RFC7608])" is a non-sequitur. RFC 7608 specifies the behaviour of
> forwarding equipment, and this draft is about prefixes assigned to hosts.
> I'd just say "/64 prefix". If you need a justification for /64 (even though
> the document doesn't justify the other parameters either, such as 3600 for
> the prefix lifetime or 300 for the RA interval), then you can say that SLAAC
> is not defined for any other size, and per RFC 7421, prefixes longer than 64
> bits are outside the current IPv6 specifications.

The text as-is anticipates possible future change without changing
anything, preventing possibly perpetuating the /64 for cyclic reasons.

Richard

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 27 Jun 2017 00:18:26 +0900

> anything, preventing possibly perpetuating the /64 for cyclic reasons.

The reference to 7608 is incorrect regardless. RFC 7608 is only about
routers forwarding packets. It says so not just in the title ("IPv6 prefix
length recommendation *for Forwarding*"), but also in the text: "it is
fundamental not to link routing and forwarding to the IPv6 prefix/address
semantics". On the other hand, this document is only about IPv6 addresses
assigned to hosts. So it's just inappropriate to cite RFC 7608 here, period.

As for why 64 bits: a document making operational recommendations should
make recommendations that work. SLAAC with non-64-bit prefix lengths is not
only disallowed by RFC 4291, it also won't work on any currently-defined
link type.

---

From: Richard Hartmann <[email-masked]>
Date: Mon, 26 Jun 2017 17:26:26 +0200

On Mon, Jun 26, 2017 at 5:18 PM, Lorenzo Colitti <[email-masked]> wrote:

> length recommendation for Forwarding"), but also in the text: "it is

If your point is that RFC 7608 should not be mentioned while
maintaining the rest of the text, we agree.

> only disallowed by RFC 4291, it also won't work on any currently-defined

There's no use in rehashing the arguments in recent threads. Everyone
on this list is well aware of the current state, but anticipating
possible change without enforcing it seems to be a prudent way to
write IDs going forward.

Richard

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 26 Jun 2017 17:28:07 +0200

Le 26/06/2017 à 17:18, Lorenzo Colitti a écrit :
> On Tue, Jun 27, 2017 at 12:01 AM, Richard Hartmann 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> routers forwarding packets. It says so not just in the title ("IPv6 
> prefix length recommendation *for Forwarding*"), but also in the text: 
> "it is fundamental not to link routing and forwarding to the IPv6 
> prefix/address semantics".

Put that way it is out of context.

In practice if one forwards a /65 to a SLAAC-/64 one obviously makes a 
misconfiguration.

> On the other hand, this document is only 
> about IPv6 addresses assigned to hosts. So it's just inappropriate to 
> cite RFC 7608 here, period.

If so, then one has to make it such 64 is actually a variable plen in 
Host Addressing.

> make recommendations that work. SLAAC with non-64-bit prefix lengths is 
> not only disallowed by RFC 4291, it also won't work on any 
> currently-defined link type.

I think we should update RFC 4291 to allow it.

Alex

> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 27 Jun 2017 00:36:44 +0900

> maintaining the rest of the text, we agree.

Almost. There's still the problem that the words "likely a /64" are
misleading. "Likely" is not the right word to use since currently anything
other than 64 is not just disallowed but won't work at all. "(currently, a
/64 prefix)" is more correct.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jun 2017 08:44:25 +1200

Hi,

>    o  A-flag = 1 (The UE/subscriber can configure itself using SLAAC)
> 
>    o  L-flag = 0 (the prefix is not an on-link prefix, which means that
>       the UE/subscriber will NEVER assume destination addresses that
>       match the prefix are on-link and will ALWAYS send packets to those
>       addresses to its default gateway.)

Hmm. Please check this assertion for a host that implements RFC8028
if the LAN is multihomed. At the very least, such a host has more
than one "default" gateway - it has one per prefix.

Regards
   Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 27 Jun 2017 10:12:27 +1000

> possible change without enforcing it seems to be a prudent way to

Possible change is anything possible. With enough changes, IPv6 could
support 129 bit addresses, so they're possible too.

I don't think consensus has been reached on relaxing /64, so it
shouldn't be assumed to be probable.

---

From: Simon Hobson <[email-masked]>
Date: Tue, 27 Jun 2017 20:53:57 +0100

> than one "default" gateway - it has one per prefix.

In a multi-homed host, all this is done per-link. An address may well be on-link for one link, and off-link for another.
So a host may well have the option of sending a packet to another host either directly via one link, or via a default router on another link. I don't think that invalidates any of the previous discussions - provided you consider each link in it's own right.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jun 2017 12:44:13 +1200

> In a multi-homed host, all this is done per-link. An address may well be on-link for one link, and off-link for another.

Yes. But the RFC8028 case is where the *LAN* is multihomed, so the host has
a choice of first-hop routers on the same link. It does not have a unique
default router.

   Brian

---

From: Simon Hobson <[email-masked]>
Date: Wed, 28 Jun 2017 09:56:57 +0100

> a choice of first-hop routers on the same link. It does not have a unique

Ah, OK - that working works for a single router/advertised set of prefixes, but could be argued to be incorrectly worked where multiple routers/prefix sets are involved.

I assume that where two routers advertise non-overlapping prefix sets, the node is supposed to combine the lists of on-link prefixes - so as long as one router has advertised a prefix as on-link then the node can use that. I vaguely recall having read that's how it's supposed to work.

So the bit you are picking on is "to it's default gateway" whereas is should really be "to the appropriate gateway according to route selection rules ..." (or something like that) ?

---

From: Richard Hartmann <[email-masked]>
Date: Wed, 28 Jun 2017 11:28:33 +0200

> support 129 bit addresses, so they're possible too.

That statement seems to be deliberate hyperbole, and factually impossible.

> shouldn't be assumed to be probable.

Shifting by a few orders of magnitude in likelihood, assuming things
to be probable is different from writing new documents in a flexible
manner.

Richard

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jun 2017 13:46:42 +1200

> So the bit you are picking on is "to it's default gateway" whereas is should really be "to the appropriate gateway according to route selection rules ..." (or something like that) ?

Yes. I also had a passing concern that the recommendation
in RFC8028 might break something in this draft, but I think it's
only a minor wording issue.

    Brian