Subject: [v6ops] DHCPv6 subscriber learning default gateway

From: Naveen Kottapalli <[email-masked]>
Date: Fri, 10 Mar 2017 11:36:04 +0530

Hello,

Can anyone tell how will a DHCPv6 subscriber learn about the default
gateway it has to contact for the subscriber traffic?

Yours,
Naveen.

---

From: [email-masked]
Date: Fri, 10 Mar 2017 08:03:31 +0100 (CET)

> gateway it has to contact for the subscriber traffic?

A DHCPv6 subscriber is supposed to learn about default gateway from
Router Advertisement.

Steinar Haug, AS2116

---

From: Naveen Kottapalli <[email-masked]>
Date: Fri, 10 Mar 2017 13:13:06 +0530

+v6ops, 6man

Yours,
Naveen.

On 10 March 2017 at 12:41, Naveen Kottapalli <[email-masked]> wrote:

> Okay.  Can you tell which parameters of RA will convey the default gateway
> address?  Also, can you point me to the document where it is mentioned that
> a DHCPv6 subscriber has to use RS-RA for resolving gateway address?
>
> Yours,
> Naveen.
>
> On 10 March 2017 at 12:33, <[email-masked]> wrote:
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Mar 2017 10:03:12 +0100

> A DHCPv6 subscriber is supposed to learn about default gateway from

Or from DHCPv6 as proposed in these Internet Drafts that have not 
reached an RFC status and have been abandoned because see below:

draft-mouton-mif-dhcpv6-drlo-01.txt
draft-ietf-mif-dhcpv6-route-option-05

Code:
https://www.isc.org/blogs/routing-configuration-over-dhcpv6-2/
http://askubuntu.com/questions/649547/how-to-set-default-gateway-in-dhcpd6-conf

At IETF some very vocal people are _against_ it, for reasons that are 
important to them.

Good reasons also exist _in favor_ of these proposals.

If you like it - try it.  Does it work?

Alex

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

---

From: Mark Smith <[email-masked]>
Date: Fri, 10 Mar 2017 20:29:43 +1100

On 10 Mar. 2017 8:03 pm, "Alexandre Petrescu" <[email-masked]>
wrote:

> A DHCPv6 subscriber is supposed to learn about default gateway from

Or from DHCPv6 as proposed in these Internet Drafts that have not reached
an RFC status and have been abandoned because see below:

Code:
https://www.isc.org/blogs/routing-configuration-over-dhcpv6-2/
http://askubuntu.com/questions/649547/how-to-set-default-
gateway-in-dhcpd6-conf

Have you read RFC1958?

"3.2 If there are several ways of doing the same thing, choose one."

Now you're just confusing Naveen.

One problem, one solution, no confusion, no conflicts and no risks of
picking the option opposite to what everybody else picks.

Complexity and having to make choice are neither cheap nor risk free.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Mar 2017 12:20:27 +0100

Le 10/03/2017 à 10:29, Mark Smith a écrit :
>
>
> On 10 Mar. 2017 8:03 pm, "Alexandre Petrescu"
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Le 10/03/2017 à 08:03, [email-masked] <mailto:[email-masked]>
>     a écrit :
>
>     <https://www.isc.org/blogs/routing-configuration-over-dhcpv6-2/>
>     <http://askubuntu.com/questions/649547/how-to-set-default-gateway-in-dhcpd6-conf>
>
>     At IETF some very vocal people are _against_ it, for reasons that
>     are important to them.
>
>
> Have you read RFC1958?

I only started at RFC2000, sorry :-)

> "3.2 If there are several ways of doing the same thing, choose one."

But even then,

There are two distinct ways to get into someone's NC: with an NA or with 
an RA.  Why are there two?

> picking the option opposite to what everybody else picks.

Except when "consenting adults" like and End User and her operator agree 
on doing so.

DHCPv6 does some things that SLAAC can not do, and vice-versa.

If one needs _both_ a delegated prefix _and_ a default route:  why 
should one use two distinct protocol software and 6 messages, when less 
could do? (just DHCP software, or just ND software, and just 2 messages).

> Complexity and having to make choice are neither cheap nor risk free.

Yes, I propose to reduce complexity: use just ND, or just DHCP.

Which less complex solution do you recommend to someone in need of both 
a delegated prefix and a default route?

Alex

>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/v6ops>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/v6ops>
>
>

---

From: Erik Kline <[email-masked]>
Date: Fri, 10 Mar 2017 20:26:38 +0900

The RA + DHCPv6-PD mode of deployment is well-understood and actively
tested every day by literally tens of millions (or more) of IPv6-enabled
residential subscribers around the world.

---

From: Naveen Kottapalli <[email-masked]>
Date: Fri, 10 Mar 2017 17:04:43 +0530

Even am not sure why two protocols are required for a client to work.
It'll be good if a subscriber uses one protocol to get all the information
that it needs to work.

This is all triggered by the following problem.

1. Subscriber gets SLAAC prefix from gateway
2. Subscriber got the gateway address and other information as well.
3. Flush the addresses of the interface using command *'ip addr flush dev
p34p1.106'*
4. Now run dhclient to get the address using DHCPv6.
5. Subscriber gets the prefix and is assigned to the interface but the
gateway information isn't there.

Due to this the subscriber will not be able to browse.

Yours,
Naveen.

---

From: [email-masked]
Date: Fri, 10 Mar 2017 13:24:38 +0100 (CET)

> It'll be good if a subscriber uses one protocol to get all the information

Long discussion, lots of it in the archives already. You're not alone
feeling that way.

> Due to this the subscriber will not be able to browse.

"Doctor, it hurts when I do this!" - "Then don't do that!"

Why is the subscriber explicitly flushing the interface address
(presumably also getting rid of the default route) and then expecting
DHCPv6 to work?

Steinar Haug, AS2116

---

From: Naveen Kottapalli <[email-masked]>
Date: Fri, 10 Mar 2017 18:04:46 +0530

Accidentally we flushed the addresses to test something else.  But it
exposed a different thing for us.

Yours,
Naveen.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Mar 2017 13:40:08 +0100

Le 10/03/2017 à 12:26, Erik Kline a écrit :
> The RA + DHCPv6-PD mode of deployment is well-understood and
> actively tested every day by literally tens of millions (or more) of
> IPv6-enabled residential subscribers around the world.

Yes, the RA+DHCP model can be also tried in practice immediately,
although there may be some quirks with the M/O bits in RA.

It is also good to know that a certain manufacturer considers making
billions of M2M devices that are cheaper, less powerful, less bandwidth
links, than typical cable modems or set-top boxes.  These units would
need less protocol software and less messages.

The exponential forecasts range between a pessimistic 20 billion to an
overly-optimistic 80 billion in 2020.  On the longer term a more complex
curve is suggested by Gartner in a Hype Cycle.

These are not Human subscribers but Machines programmed by Humans.

I think the three models should co-exist (DHCP+RA, RA-only, DHCP-only) - 
they satisfy different needs.

Alex

---

From: Tim Chown <[email-masked]>
Date: Fri, 10 Mar 2017 14:45:27 +0000

> On 10 Mar 2017, at 11:26, Erik Kline <[email-masked]> wrote:
> 
> The RA + DHCPv6-PD mode of deployment is well-understood and actively tested every day by literally tens of millions (or more) of IPv6-enabled residential subscribers around the world.

Somewhat propped up by those deployments being dual-stack, to be fair.

Tim

---

From: Mark Smith <[email-masked]>
Date: Sat, 11 Mar 2017 05:12:57 +1100

> Long discussion, lots of it in the archives already. You're not alone

So why haven't we haven't we replaced literally every protocol (e.g.,
BGP, OSPF, IPv6, HTTP, SMTP, SNMP, GRE, PPP etc.) with a single
protocol, consisting of just TLVs. I'd say 128 bit type and 128 bit
length fields could probably accommodate all needs, although that
would be a constraint too. That would be simpler wouldn't it?

I consider the problem of configuring link-layer specific layer 3
parameters (e.g., link prefix, MTU, ND timers) to be a separate and
different problem from configuring application layer parameters that
are or can be host specific (e.g., DNS, NTP, timezone, geolocation
etc.), and independent of a specific link-layer's layer 3 parameters.
RAs are solving a problem that is local to a specific link, DHCPv6 is
solving a problem that is not coupled to a link or its layer 3
parameters.

These two problems were addressed by a single solution in IPv4. Host
parameter configuration might appear to be a single problem, however
we have different sets of parameters at different layers ("different
sets" is another give away that you may be dealing with different
problems.).

When you start with a clean slate, you get the opportunity to say,
"we're really dealing with two separate problems here, so two separate
solutions are better", instead of saying "this is how we've always
done it, lets also continue to also preserve the drawbacks of the
existing solution."

<snip>

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Mar 2017 08:31:11 +1300

On 10/03/2017 20:43, Naveen Kottapalli wrote:
>> address?  

You need to read RFC4861 to understand the relevant details of RA.

>> Also, can you point me to the document where it is mentioned that

Section 7.2.2 of RFC6434 explains this (but the wording could be clearer, perhaps).
The basic point is that RFC4861 is effectively mandatory and DHCPv6 is optional.

You are not the only person who thinks this is a gap in DHCPv6.

   Brian

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 10 Mar 2017 19:48:02 +0000

>    You are not the only person who thinks this is a gap in DHCPv6.

As a DHC WG co-chair, if v6ops and 6man believe this IS something that should be addressed in the DHCPv6 protocol, we can certain discuss with our AD to take it on. In the past, it seemed the view from these WGs (perhaps mostly 6man) was to leave it for RA to convey the default gateway.

- Bernie

On 3/10/17, 2:31 PM, "Brian E Carpenter" <[email-masked]> wrote:

    

    
       Brian

---

From: [email-masked]
Date: Fri, 10 Mar 2017 22:11:27 +0100

> As a DHC WG co-chair, if v6ops and 6man believe this IS something that should be addressed in the DHCPv6 protocol, we can certain discuss with our AD to take it on. In the past, it seemed the view…

if the only tool you have is a hammer...
stop beating a dead horse. it hurts.

Ole