Re: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-04.txt

[Alexandre Petrescu <[e-mail]>]

sidenote...

Le 05/01/2016 16:21, Lorenzo Colitti a écrit :
> On Tue, Jan 5, 2016 at 10:08 PM, Philip Homburg
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     - there are essentially no hosts requesting DHCPv6-PD
>        (I wonder if there are any hosts requesting multiple addresses using
>        DHCPv6 IA_NA).
>     - we know that in the CPE world there are at least two different
>     approaches of
>        doing DHCPv6-PD which does affect how the network provides those
>        addresses. (And also affects client implementations)
>
>     So in short, there simply is no real practice when it comes to a
>     large part
>     of this document.
>
>
> But it's not a "large part of the document" at all. It's not even a
> large part of the requirements section. I think what you are disagreeing
> with is only one of the recommendations, which is "if your network will
> only allow hosts to connect if they do DHCPv6, then don't hand out an
> addres via IA_NA, but hand out a prefix via DHCPv6 PD".
>
>     And we also have to curious word play where a host that uses a prefix
>     obtained through DHCPv6-PD has to be a router from the point of view
>     of ND,
>
>
> No, that's not true. A router is "a node that forwards packets not
> explicitly addressed to itself" [RFC2460]. A host that uses a prefix
> obtained using DHCPv6 PD does not need to do that.

If one reads the Note attached to the router definition in 2460, then 
one understands that a host that uses a prefix obtained with DHCP-PD 
does need to forward, and maybe its apps to explicitate the source address.

>     and is actually a router in one of the use cases (tethering). And
>     will be a router
>
>     in many implementations (AREO seems an exception in assigning
>     adresses to
>     the upstream interface), but we insist in calling it a host.
>
>
> Looks like you're assuming that a node needs to be a router in order to
> send a packet on one interface with a source address assigned to another
> interface. That's not true at all. In fact, to give you an idea on how
> this works I just ran a DHCPv6 PD client on my linux laptop to get a
> prefix from my home router, picked an address out of the prefix,
> assigned it to lo, and used it:
>
>  1. dhclient -d -6 -D LL -P eth0   # Run PD and note the prefix you get.
>     I got 2400:2410:20c0:4450::/60
>  2. ip -6 addr add dev lo 2400:2410:20c0:4450::1/128    # Pick an
>     address out of the prefix, assign to lo
>  3. ping6 -I 2400:2410:20c0:4450::1 www.google.com
>     <http://www.google.com>   # Use that address to talk to the Internet
>     via eth0
 >
> This all works as expected (and as predicted by the specifications). My

This is not as expected.  It is the "unusual" word of 2460.

It is unusual in that you had to argument "-I" to that ping6.

The usual way is to be able to say just "ping6 google.com" without 
arguments.

Alex

> laptop sends the packets on eth0 because it's the interface with the
> default route, both my laptop and my home router do NUD for the
> link-local address of the other device, and packets flow. My laptop is
> most certainly a host, and IPv6 forwarding is off.
>
> As for tethering - sure, a device with tethering enabled is a router.
> But that's a minor point. If you were to pick only one of the two, would
> you say that your phone and your laptop are "hosts" or "routers"? I
> think it's appropriate to call them "hosts", even though they
> occasionally act as routers. I suppose the word "node" would be more
> correct, but it would be much less readable.
>
>     So, publish as informational. Actually get some experience deploying
>     exactly what is proposed here. And then write a BCP on what is actually
>     deployed and how that works.
>
>
> Again, I think you're not seeing the forest for the (DHCPv6 PD) tree.
> The point of this document is not "networks should use DHCPv6 PD". The
> point of this document is "networks that provide service to general
> purpose devices should provide those devices with multiple addresses at
> connection time". As the draft says, that statement is true of the
> networks used by tens of millions of devices every day: pretty much
> every home network, all 3GPP networks, and so on.
>
> DHCPv6 PD is cited simply because if a network has decided "we will use
> DHCPv6 and nothing else", then the only possible way to assign enough
> addresses is to use DHCPv6 PD. But that's a tiny minority of the
> networks out there, and it's only a small part of the draft.
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>