Subject: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

From: <[email-masked]>
Date: Mon, 21 Oct 2013 05:45:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem. Please take a look at it and comment.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 21 Oct 2013 15:01:28 +0200 (CEST)

> A new draft has been posted, at http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem. Please take a look at it and comment.

I like the fact that this work is being done. It seems to me the current 
standards leave too much room for interpretation.

I would like to see the following deployment scenarios being possible, and 
all hosts should support them.

1. No Prefix information, M=1, Host gets /128 IPv6 address for own use and 
a default route (RA), possibly other information. All traffic to other 
hosts that is not LL goes via router.

2. PIO /64, A=0, M=1, host gets /128 out of on-link /64, can communicate 
with other hosts on-link directly.

3. PIO /64, A=1, M=1. Host gets /128 from DHCP plus can do SLAAC, 
otherwise same as above.

4. PIO /64, A=1, M=1. Host gets /128 from outside /64 via DHCP, plus can 
do SLAAC within the /64.

Also it's quite worrying about the state changes when A/M/O changes. I 
believe that it might be time to re-rev our standards documents to specify 
exactly what should happen for each case.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 22 Oct 2013 06:49:21 +0000

Hi, Chairs & All

The draft (http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem) is about the SLAAC/DHCPv6 interaction problems might cause hosts un-consistent behaviors, which might harmful for management.

The content of the draft has been discussed a couple of times in 6man WG, most of the feedbacks are positive. Some people have showed their willing to fix the problems by revising the standard.
But considering this is a historic problem which was used to be discussed a lot before, we think it might be necessary to identify the problems clearly and solidly before revising the standard. 

So we made a Problem Statement document in v6ops, and hope the OPS people could provide opinions on this topic, e.g. 
- do you agree the problems in the draft;
- have you considered/suffered the impacts to the real IPv6 deployment by this issue; 
- do you think we must have to fix the problems .etc.

Your review and comments would be appreciated very much.

For those who are not familiar with the draft, please see the introduction as the following (also as the replies to the Chairs' questions)
> 1) Please provide a succinct problem statement for your draft. What
> problem/issue is this draft discussing? What operational problems does the
> proposal address in real life networks?
[Bing] As we know there are several flags in RA messages regarding with the host configuration behavior, which are A (Autonomous) flag, M (Managed) flag, and O (Otherconfig) flag.
For some reason, the host behavior of interpreting the flags is ambiguous in the standard (mainly RFC4862). This draft analyzed all the three flags, and provided test result of current implementations, it showed the behavior of different mainstream desktop/mobile OSes have varied. The ambiguous and variation might cause operational problems, such as renumbering, cold start problem, and management gaps .etc.

> 2) Where does this draft or presentation fits into v6ops' current charter
> (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing specific a section(s)
> of the charter is preferable.
[Bing] 1. Solicit input from network operators and users to identify
operational issues with the IPv4/IPv6 Internet, and
determine solutions or workarounds to those issues. These issues
will be documented in Informational or BCP RFCs, or in
Internet-Drafts.

> 3) Who is this draft's audience?
[Bing] Administrators/Operators.

> 4) Have any operators expressed interest in this draft or its problem space,
> either via review or other discussion?
[Bing] Yes, China Telecom had expressed the problem when they deployed IPv6 networks. Their scenario was the CPE doing SLAAC while getting information through stateless DHCPv6. And the found the flags definition is ambiguous in current standard, so they had to directly specify the behavior of interpreting the flags to the CPE vendors.

> 5) Is this draft pursuing discussion in any other WGs? If so, please list them
> here, along with rationale for the interaction with multiple WGs in parallel.
[Bing] In 6man, as described in the main body.

> 6) Is any protocol work being recommended in the draft?
[Bing] Not yet. This draft was intend to be a pure Problem Statement draft.

Many thanks.

Best regards,
Bing

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 21, 2013 8:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
> 
> 
> A new draft has been posted, at
> http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem.
> Please take a look at it and comment.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 22 Oct 2013 07:21:26 +0000

Hi, Mikael

Thanks for your comments. (I change the mail title to help identify the traffic to this specific draft/problem).
Please see replies inline.

> standards leave too much room for interpretation.
[Bing] Agreed. Ambiguity is usually a bad thing.

> with other hosts on-link directly.
[Bing] I'm a little confused about the scenario. A=0 switch SLAAC off, and host would initial DHCP according M=1, do you mean the DHCP Server need to be aware of the PIO /64, so that the /128 from dhcp in accordance with the PIO /64?
 
> exactly what should happen for each case.
[Bing] Agreed. 

Best regards,
Bing

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 22 Oct 2013 15:13:07 +0200 (CEST)

> [Bing] I'm a little confused about the scenario. A=0 switch SLAAC off, 
> and host would initial DHCP according M=1, do you mean the DHCP Server 
> need to be aware of the PIO /64, so that the /128 from dhcp in 
> accordance with the PIO /64?

Yes. I already do this at home with a Cisco router with built-in DHCPv6 
IA_NA (and IA_PD) server.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 22 Oct 2013 12:16:45 -0700 (PDT)

>________________________________
> From: Mikael Abrahamsson <[email-masked]>
>To: Liubing (Leo) <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Wednesday, 23 October 2013 12:13 AM
>Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
> 
>

Is this saying that the prefix length of the address on host is /128?

If that is the case, as the prefix length in doesn't indicate on-link or off-link status (as RA PIOs do), is there any specific reason for the prefix length the DHCPv6 server hands out to be /128 instead of the subnet's prefix length of /64? 

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 23 Oct 2013 05:40:14 +0200 (CEST)

> Is this saying that the prefix length of the address on host is /128?

A single address is always a /128. This /128 can be part of an on-link 
other network, or it isn't.

> If that is the case, as the prefix length in doesn't indicate on-link or 
> off-link status (as RA PIOs do), is there any specific reason for the 
> prefix length the DHCPv6 server hands out to be /128 instead of the 
> subnet's prefix length of /64? 

The DHCPv6 server always hands out /128. This /128 can be within a subnet 
advertised in RA, or it can be outside of it. The host doesn't care. When 
a subnet is being advertised in RA you get a network route pointing to the 
interface without an IPv6 address as next-hop.

So it's perfectly achievable today (and it works) to have the following:

Host gets 2001:db8:fff::1/128 from dhcp
host gets on-link 2001:db8:1::/64 from RA and creates a route towards the 
interface for this, but doesn't do SLAAC because A=0.
Host gets default route from router and installs it.

Now, the *router* needs to understand that 2001:db8:fff::1/128 is on-link, 
but no other hosts on the network does not.

So what networks are being announced in RA is completely decoupled from 
addresses handed out by DHCPv6 IA_NA. It's perfectly valid to hand out a 
/128 and then have no on-link prefixes at all, or have some with A=0.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 23 Oct 2013 02:11:49 -0700 (PDT)

Hi,

----- Original Message -----
> To: Mark ZZZ Smith <[email-masked]>
> Cc: Liubing (Leo) <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Wednesday, 23 October 2013 2:40 PM

My question was more specificaly about you using "/128", rather than "an address" or "a single address", because I wondered if the DHCPv6 server supplies a /128 prefix length and the host configures a /128 prefix length on the address.

As you say below, address prefix length doesn't indicate on-link or off-link presence. So I'd expect a DHCPv6 server to hand out single IPv6 addresses with a /64 prefix length, as I think that would be more consistent and more expected when the subnet's prefix length is /64.

For somebody with a IPv4 experience, who wasn't aware an IPv6 prefix length doesn't indicate on-link presence, I think the use of a /128 prefix length in this scenario would imply that prefix length does indicate on-link presence. Somewhat pedantic perhaps, however I think anything that may give false indications of IPv6's behaviour, when it is different to IPv4's, is better to avoid.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 23 Oct 2013 11:21:05 +0200 (CEST)

On Wed, 23 Oct 2013, Mark ZZZ Smith wrote:

> My question was more specificaly about you using "/128", rather than "an 
> address" or "a single address", because I wondered if the DHCPv6 server 
> supplies a /128 prefix length and the host configures a /128 prefix 
> length on the address.

I am not aware of DHCP being able to hand out IA_NA ranges to hosts. I 
only thought it could hand out single IA_NA.

> As you say below, address prefix length doesn't indicate on-link or 
> off-link presence. So I'd expect a DHCPv6 server to hand out single IPv6 
> addresses with a /64 prefix length, as I think that would be more 
> consistent and more expected when the subnet's prefix length is /64.

You're missing the point. There doesn't have to be a /64. DHCPv6 hands out 
IA_NA which is a single address, which might or might not be covered by an 
on-link prefix.

> For somebody with a IPv4 experience, who wasn't aware an IPv6 prefix 
> length doesn't indicate on-link presence, I think the use of a /128 
> prefix length in this scenario would imply that prefix length does 
> indicate on-link presence. Somewhat pedantic perhaps, however I think 
> anything that may give false indications of IPv6's behaviour, when it is 
> different to IPv4's, is better to avoid.

The /128 is on-link (it's bound to that interface), just that most likely 
nobody else knows about it apart from the router (unless it's covered by a 
prefix being announced as on-link).

---

From: "Ole Troan (otroan)" <[email-masked]>
Date: Wed, 23 Oct 2013 09:21:21 +0000

A single address does not have a mask. 
DHCP gives out addresses, not prefixes that can be used for onlink determination. 

Cheers,
Ole

> On 23 Oct 2013, at 11:11, Mark ZZZ Smith <[email-masked]> wrote:
> 
> Hi,
> 
>

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 23 Oct 2013 18:06:23 +0800

> DHCP gives out addresses, not prefixes that can be used for onlink determination. 

and if dhcpv6 gave out netmasks and default gateways, we could finally
ditch RA.  I look forward to the day when I can finally expunge RA from my
networks.

Nick

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 23 Oct 2013 12:12:36 +0200

To be honest, I haven't kept up with the full exchange on this topic, so please disregard my question if it is not relative to this discussion.

I read below that, if netmask and def gw would be added on handing out dhcpv6, "I can finally get rid of RA messages".
But what with hosts NOT supporting dhcpv6 client in this case ?  I might be fully wrong, but I cannot imagine it can be 100% enforced upon each host vendor to include dhcpv6 client support?

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nick Hilliard
Sent: woensdag 23 oktober 2013 12:06
To: Ole Troan (otroan); Mark ZZZ Smith
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

> DHCP gives out addresses, not prefixes that can be used for onlink determination. 

and if dhcpv6 gave out netmasks and default gateways, we could finally ditch RA.  I look forward to the day when I can finally expunge RA from my networks.

Nick

---

From: [email-masked]
Date: Wed, 23 Oct 2013 12:20:08 +0200 (CEST)

> ditch RA.  I look forward to the day when I can finally expunge RA from my

Amen. But it doesn't look like this is going to happen any time soon...

Steinar Haug, AS 2116

---

From: [email-masked]
Date: Wed, 23 Oct 2013 12:25:07 +0200 (CEST)

> But what with hosts NOT supporting dhcpv6 client in this case ?  I might be fully wrong, but I cannot imagine it can be 100% enforced upon each host vendor to include dhcpv6 client support?

It worked for IPv4. Yes, I realize IPv6 is different, and the target
market is different (e.g. light bulbs).

Nevertheless - as an ISP, I am going to require DHCPv6 for dynamic
address customers. I would be very happy if I only needed DHCPv6 and
could do without RA. (Note RA != ND/NS)

Steinar Haug, AS 2116

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 23 Oct 2013 13:05:02 +0200

Well, "it worked in IPv4" might not be the correct approach :-).  From time to time I hear: let's do clamping again for v6, it works on v4 too ....  anyway, out of scope in this discussion.

Nevertheless, I can imagine you prefer the dhcpv6 over RA, but I doubt, looking at the big number of devices taking part in this these days (sensors, bulbs, etc) that they will all start supporting dhcpv6 client, not a chance I'm afraid.

Thx for feedback

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 23 oktober 2013 12:25
To: Wuyts Carl
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

> But what with hosts NOT supporting dhcpv6 client in this case ?  I might be fully wrong, but I cannot imagine it can be 100% enforced upon each host vendor to include dhcpv6 client support?

It worked for IPv4. Yes, I realize IPv6 is different, and the target market is different (e.g. light bulbs).

Nevertheless - as an ISP, I am going to require DHCPv6 for dynamic address customers. I would be very happy if I only needed DHCPv6 and could do without RA. (Note RA != ND/NS)

Steinar Haug, AS 2116

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 23 Oct 2013 11:19:42 +0000

> From: Wuyts Carl [mailto:[email-masked]]
...
> Nevertheless, I can imagine you prefer the dhcpv6 over RA, but I doubt,
> looking at the big number of devices taking part in this these days (sensors,
> bulbs, etc) that they will all start supporting dhcpv6 client, not a chance I'm
> afraid.
[Bing] Agreed. These lightweight/embed systems might become an important part of the IPv6 net. ND allows minimal management burden for them.
Beyond address space, in my mind SLAAC is the most obvious advantage comparing to IPv4.

Regards,
Bing

> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked];
> [email-masked]
> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft:
> draft-liu-bonica-v6ops-dhcpv6-slaac-problem
> 
> > To be honest, I haven't kept up with the full exchange on this topic, so
> please disregard my question if it is not relative to this discussion.
> >
> > I read below that, if netmask and def gw would be added on handing out
> dhcpv6, "I can finally get rid of RA messages".
> > But what with hosts NOT supporting dhcpv6 client in this case ?  I might
> be fully wrong, but I cannot imagine it can be 100% enforced upon each host
> vendor to include dhcpv6 client support?
> 
> Nevertheless - as an ISP, I am going to require DHCPv6 for dynamic address
> customers. I would be very happy if I only needed DHCPv6 and could do
> without RA. (Note RA != ND/NS)
> 
> Steinar Haug, AS 2116

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 23 Oct 2013 19:29:10 +0800

On 23/10/2013 19:05, Wuyts Carl wrote:
> looking at the big number of devices taking part in this these days
> (sensors, bulbs, etc) that they will all start supporting dhcpv6 client,
> not a chance I'm afraid.

All I'm asking is that people stop blocking attempts to add prefixlen and
defgw to DHCPv6.  That's all, nothing more.

Everyone is welcome to do what they want on their networks and if they're
happy to run RA, I'm happy too.

Nick

---

From: 神明達哉 <[email-masked]>
Date: Wed, 23 Oct 2013 11:15:46 -0700

At Wed, 23 Oct 2013 09:21:21 +0000,

> DHCP gives out addresses, not prefixes that can be used for onlink determination.

True, and this would mean that a /128 prefix is implicitly assumed for
a host implementation that manages addresses with a corresponding
netmask/prefix length, such as BSD variants.  But that can be
implementation dependent, and IIRC the ISC DHCPv6 client
unconditionally uses a /64 prefix when it configures a host's
interface with the address assigned via DHCPv6.

> > For somebody with a IPv4 experience, who wasn't aware an IPv6 prefix length doesn't indicate on-link presence, I think the use of a /128 prefix length in this scenario would imply that prefix len…

I guess this point is related to this change in RFC 4861:

   o Removed the on-link assumption in Section 5.2 based on RFC 4942,
     "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful".

In RFC 2461, if no router (in this context, a node that sends out RAs)
is available, all addresses should be considered on-link.  So it
didn't matter whether a DHCPv6 client chose a /64 or /128 or whatever
prefix.  With the change of RFC 4861, however, there can be a real
interoperability issue if it's a router-less network.  Again, IIRC,
that was the main reason why the ISC implementation used a /64 prefix.

Maybe we should also clarify these points as we want to clarify other
matters regarding RA/DHCPv6 interactions such as A/M/O flags.

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Oct 2013 03:21:34 +0900

> Amen. But it doesn't look like this is going to happen any time soon...

And then what? Rely on client polling to before you can change any network
parameter, ever? Be forced to run things like VRRP because you can never
change anything on the hosts?

Sure that's the way we do it today in IPv4. But is it the best way? Maybe
in an enterprise, but in a home? What happens when your precious "DHCPv6
server" (home router) gets unplugged by the user and all the hosts are dead
in the water until they decide to send another DHCPv6 request, even though
there are 3 other routers and DHCPv6 servers on the same link?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 23 Oct 2013 20:50:43 +0200 (CEST)

> interface with the address assigned via DHCPv6.

Are you sure? I don't know what Ubuntu uses, but I have successfully 
gotten it to just get a single IA_NA + default gw, no /64 on the 
interface.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 23 Oct 2013 12:09:41 -0700 (PDT)

----- Original Message -----
> From: Ole Troan (otroan) <[email-masked]>
> Cc: Mikael Abrahamsson <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Wednesday, 23 October 2013 8:21 PM

That makes it clearer. There was no need for Mikael to use "/128", which to me implied that the DHCPv6 server conveyed a prefix length when handing out addresses, and that a specific /128 prefix length mattered to Mikael, which is why I asked the question.

Thanks,
Mark.

>>>  Cc: Liubing (Leo) <[email-masked]>; 
> "[email-masked]" <[email-masked]>; 
> "[email-masked]" 
> <[email-masked]>
>>  My question was more specificaly about you using "/128", rather 
> than "an address" or "a single address", because I wondered 
> if the DHCPv6 server supplies a /128 prefix length and the host configures a 
> /128 prefix length on the address.
>> 
> addresses with a /64 prefix length, as I think that would be more consistent and 
> more expected when the subnet's prefix length is /64.
>> 
> length doesn't indicate on-link presence, I think the use of a /128 prefix 
> length in this scenario would imply that prefix length does indicate on-link 
> presence. Somewhat pedantic perhaps, however I think anything that may give 
> false indications of IPv6's behaviour, when it is different to IPv4's, 
> is better to avoid.
>> 
>> 
>>  Regards,
>>  Mark.
>> 
>>>>    If that is the case, as the prefix length in doesn't indicate 
> on-link
>>>  or

---

From: 神明達哉 <[email-masked]>
Date: Wed, 23 Oct 2013 12:12:29 -0700

At Wed, 23 Oct 2013 20:50:43 +0200 (CEST),

> gotten it to just get a single IA_NA + default gw, no /64 on the

I'm pretty sure at least it behaved that way before.  I don't know what
the very latest implementation does in this regard, but at least
according to the source code it doesn't seem to change.  This is a
snippet of ISC DHCP 4.2.5:

    /* addr fields. */
    if (addr != NULL) {
        if ((ia != NULL) && (ia->ia_type == D6O_IA_PD)) {
[...]
        } else {
            /* Current practice is that all subnets are /64's, but
             * some suspect this may not be permanent.
             */
            client_envadd(client, prefix, "ip6_prefixlen",
                      "%d", 64);
            client_envadd(client, prefix, "ip6_address",
                      "%s", piaddr(addr->address));
        }

and, e.g., in scripts/linux:

  ${ip} -f inet6 addr add ${new_ip6_address}/${new_ip6_prefixlen} \
    dev ${interface} scope global

But a specific installation of ISC DHCP could use its own client
script, and it's possible that one such custom implementation just
ignores (new_)ip6_prefixlen given by dhclient.  (And, of course, I
don't even know whether your Ubuntu client uses the ISC implementation
in the first place).

--
JINMEI, Tatuya

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 23 Oct 2013 12:20:56 -0700 (PDT)

----- Original Message -----
> From: Nick Hilliard <[email-masked]>
> To: Ole Troan (otroan) <[email-masked]>; Mark ZZZ Smith <[email-masked]>
> Sent: Wednesday, 23 October 2013 9:06 PM

RAs are prehaps misnamed. They're not really router advertisements, they're advertisements (typically) sent from routers. View them as layer 3 configuration protocol packets, because they do far more than advertise a default router, and don't even need to advertise a default router to be useful.

They can be use for:

- changing host MTUs, instead of individual manual configuration on each host
- announce on-link presence of prefixes, exclusive of whether hosts have addresses within the prefix, instead of individual manual configuration on each host
- adjust neighbor discovery parameters (e.g., timers), instead of individual manual configuration on each host
- announce prefix(es) to be used to generate SLAAC addresses, instead of individual manual configuration on each host
- indicate to hosts whether to use DHCPv6 or SLAAC or both (during a transition between SLAAC/DHCPv6 or vice-versa), instead of individual manual configuration on each host
- advertise a default router, and an associated lifetime, instead of individual manual configuration on each host

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 23 Oct 2013 13:01:06 -0700 (PDT)

> From: Lorenzo Colitti <[email-masked]>
>To: [email-masked] 
>Cc: "[email-masked] WG" <[email-masked]>; Ole Troan (otroan) <[email-masked]>; [email-masked] 
>Sent: Thursday, 24 October 2013 5:21 AM
>And then what? Rely on client polling to before you can change any network parameter, ever? Be forced to run things like VRRP because you can never change anything on the hosts?
>
>
>Sure that's the way we do it today in IPv4. But is it the best way? Maybe in an enterprise, but in a home?

Having learned about Novell's IPX before I learnt IPv4, I've since had a bit of an interest in the different ways different protocols do things, with addressing being one of the more interesting areas. Of all the protocols I've since looked at or learned over the years (which I think would count to be around or at least 1/2 a dozen), only IPv4 with DHCPv4 has used a centralised, database and quite stateful address allocation and configuration method. As DHCPv4 was developed quite a number of years after IPv4 addressing had originally been defined and then evolved through the addition of classes and subnets, it would seem that the model used by DHCPv4 is likely to have been chosen to solve needs or a situation that doesn't normally exist when developing a protocol from scratch. If you go back far enough with IPv4, similar to Novell IPX and Xerox XNS, it also used the link-layer addresses as host addresses:

https://www.rfc-editor.org/ien/ien91.txt

So in the history of protocol development and addressing, the DHCPv4 model is quite an anomaly.

> What happens when your precious "DHCPv6 server" (home router) gets unplugged by the user and all the hosts are dead in the water until they decide to send another DHCPv6 request, even though there are 3 other routers and DHCPv6 servers on the same link?

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 24 Oct 2013 12:15:28 +0800

On 24/10/2013 03:20, Mark ZZZ Smith wrote:
> RAs are prehaps misnamed. They're not really router advertisements,
> they're advertisements (typically) sent from routers. View them as layer
> 3 configuration protocol packets, because they do far more than
> advertise a default router, and don't even need to advertise a default
> router to be useful.

I know what RAs are.  Both protocols provide info to network hosts
necessary for functional ipv6 connectivity.  They have different
approaches, but they are both lan configuration protocols.

If you feel that SLAAC+DHCPv6 or SLAAC only is the right thing for you,
then that's great and I'm really happy for you.

There is a tiny amount of protocol glue missing which would allow dhcpv6 to
act as a fully functional standalone protocol, and the various attempts to
introduce this glue have been shot down repeatedly, mostly on the basis of
arguments like "how do you expect your network to work when critical
components of your network are broken?", "we don't like duplication of
functionality at the IETF (but we'll ignore all the other duplicated
functionality in other ietf protocols)" or "polling sucks".

None of these points address the core issue which is that there are a lot
of operators who have a strong preference to use a single lan configuration
protocol instead of two protocols with strongly overlapping functionality
and an ambiguous and poorly defined interaction model.

There is no reason for DHCP not to to be standalone-capable, so that
operators can make up their own minds about what to use on their networks.

I completely understand that you want to use SLAAC on your networks: please
stop insisting that I run it on mine.

Incidentally a couple of minutes ago, Andrew Sullivan just spoke these
words about the IETF at IGF2013 in Bali:

"We're not in the business of telling people how to run their networks".

Nick

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 24 Oct 2013 01:56:58 -0400

>then that's great and I'm really happy for you.

There seems to be folks talking about very different environments, and in
some cases attempting to make arguments which don't address the comments
of the other side.

I understand Nick's point.  Coming freshly off a long sting at an ISP, I
see the value (if it can be done in a sound technical manner), of having
the * option * of a clean deployment for addressing and supplying IP
related configuration information to the end host/router.

This is not saying that it applies everywhere.  It's quite obvious that in
environments like sensor nets, home nets and other places, SLACC/RAs
supply significant value.  In other areas, like an operator access network
(edge element addressing), it's a different case.  Operators, such as the
one I worked or, would never (rarely?) let an element auto-configure
itself onto the network.

I think there may be valid uses cases where, if feasible, there is
perceived value is operating in DHCPv6 only mode.  Of course, in many
environments, DHCPv6 alone is not a good idea (example, my IPv6 light bulb)

In the case of client functionality, in those highly controlled access
network attachment areas, it is expected that the client (router or host)
has a certain level of functionality (and often times this can be
enforced).  So it's reasonable to expect DHCPv6 client functionality in
some use cases. 

>act as a fully functional standalone protocol, and the various attempts to

If this can be done, without harm to other environments, and achieve it's
goals for those who want it (I.e operators who see a need and can
articulate the benefits it will supply in network management and
operation), I don't see why we are unwilling to discuss it's technical
merits.

>and an ambiguous and poorly defined interaction model.

I do wonder how many operators will ask for this?  My concern is that if
there are not too many raising their hands now, it may be that they either
don't care, or if they are way behind in IPv6 deployment, they may not
know that they care yet.

Regards,

Victor K

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 24 Oct 2013 08:40:19 +0200 (CEST)

> related configuration information to the end host/router.

When I first started working with IPv6 I didn't understand the separation. 
But then again, now that I have gotten used to it, I don't really see the 
reason to avoid RAs either.

On IPv4, the router person has to configure an IPv4 address and netmask, 
this then has to be mirrored by the DHCPv4 configuration.

On IPv6 you can do exactly the same, just set the A-bit off. As stated 
before, you even don't need an on-link prefix to be sent to clients, so 
this is actually *better* than IPv4, because if there is a 
forced-forwarding configuration on L2 the configuration can now be 
mirrored at the client so no "local-proxy-arp" is needed (which is an ugly 
hack).

So if one really wants to, one can exactly mirror the workflow of IPv4 
into IPv6.

If I was going to change anything, I wouldn't focus on RA/DHCPv6, but 
instead on ND. The whole "discovery" part is a mess, and it would be 
better if the router just could keep state with hosts what IPv6 addresses 
were in use and never sent out an discovery message. If it wasn't already 
in the Neighbor table then the packet would just be dropped.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Oct 2013 15:41:54 +0900

On Thu, Oct 24, 2013 at 2:56 PM, Victor Kuarsingh <[email-masked]> wrote:

> It's quite obvious that in environments like sensor nets, home nets and
> other places, SLACC/RAs supply significant value.  In other areas, like
> an operator access network (edge element addressing), it's a different
> case.  Operators, such as the one I worked or, would never (rarely?) let
> an element auto-configure itself onto the network.
>

Right - and there's the rub.

It seems to me that we have two different ways of configuring things (RA
and DHCPv6) that don't differ in functionality but differ in how suitable
they are for different environments. One mechanism (RA) is dynamic,
self-configuring, serverless and fate-sharing, and the other is static,
operator-controlled, and centralized.

Operators and enterprises want the one they feel gives them more control
and are willing to provision the infrastructure to make it reliable (e.g.,
centralized configuration repositories; DHCPv6 servers and relays; VRRP so
they don't need fate-sharing, etc.). But the one that offers more control
falls over in home networks, because the infrastructure to run it is either
not available or unreliable: there's nothing anyone can do to make the
DHCPv6 server (or the DHCPv6-provided router or DNS server) keep working if
the user has unplugged it or tripped over the power cord, and there's
nothing that can withdraw a stateful DHCPv6 lease if the original server
has been unplugged, because nobody knows the nonce any more.

I think we need to accept that neither protocol is sufficient in all
environments. We have to realize that DHCPv6 just isn't suited to dynamic,
self-organizing environments like home networks. We can keep hacking it
with more semantics like unsolicited updates, but at the end of the day
we'll simply end up with something that looks like RAs - multicast updates
to everyone on the link (equivalent to multicast RAs), configuration
requests/replies (equivalent to RS/RA), and so on. Then we'll have to
implement DHCPv6 guard to stop rogue servers, and even then there will be
no fate-sharing with routing. On the other hand, RA doesn't offer the
wealth of different option types that DHCPv6 has, and while it's possible
to do fine-grained configuration with unicast RAs, today most RA
implementations don't support fine-grained per-client configuration via
unicast RA or "RS relaying" to a central server to fetch per-client RA
information.

I see two possible ways out of this:

1. Decide a clear split between what goes into RA and what goes into
DHCPv6, and then stick to it. For example, we could say that configuration
information that is required to obtain basic connectivity on a network must
be available in RA so it can be dynamically updated and shares fate with
routing, and that everything that's not strictly required for the host's
connectivity can go into DHCPv6. I don't know if it will be possible to
draw a line here. If operators insist that DHCPv6 by itself must be
sufficient, then we have no choice but to duplicate information.

2. Attempt to say that RAs and DHCPv6 are simply containers and propose a
unified option format so we can have the same options in both of them. I
know this was already proposed once and was shot down, but I wasn't around,
so I don't know why. (CCing a few people who might know).

Cheers,
Lorenzo

---

From: Sander Steffann <[email-masked]>
Date: Thu, 24 Oct 2013 10:36:56 +0200

Hi,

> 2. Attempt to say that RAs and DHCPv6 are simply containers and propose a unified option format so we can have the same options in both of them. I know this was already proposed once and was shot down, but I wasn't around, so I don't know why. (CCing a few people who might know).

I don't know why it was shot down, but this seems the least bad option to me. At least there will be a uniform set of options. Having almost-the-same-but-not-quite duplication between RA and DHCP will be the worst possible outcome...

Met vriendelijke groet,
Sander Steffann

---

From: Tore Anderson <[email-masked]>
Date: Thu, 24 Oct 2013 11:02:17 +0200

* Mikael Abrahamsson

> gotten it to just get a single IA_NA + default gw, no /64 on the interface.

I added a workaround for the ISC bug in GNOME NetworkManager one and
ahalf year ago, basically we ignore whatever the DHCPv6 client tells us
and go with a prefix length of 128 always:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=eb460b70dad82d366d35fa5703c0e79a1389e4d1

I reported the bug to ISC too, but I have heard exactly nothing back
from them.

Tore

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 24 Oct 2013 08:55:38 -0400

>>1. Decide a clear split between what goes into RA and what goes into DHCPv6,
and then stick to it. For example, we >>could say that configuration information
that is required to obtain basic connectivity on a network must be available in
>>RA so it can be dynamically updated and shares fate with routing, and that
everything that's not strictly required for >>the host's connectivity can go
into DHCPv6. I don't know if it will be possible to draw a line here. If
operators insist that >>DHCPv6 by itself must be sufficient, then we have no
choice but to duplicate information.

[VK] Although this is theoretically possible, I am not if we can actually
orchestrate this and keep it split indefinitely.  I think we will see
requests/requirements on both sides which may drive (I.e. Like operators)
functions into either protocol.

>>2. Attempt to say that RAs and DHCPv6 are simply containers and propose a
unified option format so we can have the >>same options in both of them. I know
this was already proposed once and was shot down, but I wasn't around, so I
>>don't know why. (CCing a few people who might know).

[VK] This seems like an intriguing idea. Would this mean that every option
must go into each container, or that there will be a common set of options
which go into both, and perhaps exceptions go into one or the other? (On
that latter part, I guess that line of thinking gets us back to where we
are).

Regards,

Victor K

---

From: Arturo Servin <[email-masked]>
Date: Thu, 24 Oct 2013 12:56:29 -0200

I think that neither RA or DHCP can serve as the only-solution to provide
dynamic configuration information in IPv6. There are use cases where one is
suitable and the other is not as some have point out.

What I think we need is a clear strategy of what we need to do regarding
those mechanisms and accept that we will need to support them both in the
stack.

Lorenzo's proposals seems to be a good start.

/as

On Thu, Oct 24, 2013 at 10:55 AM, Victor Kuarsingh <[email-masked]>wrote:

> DHCPv6, and then stick to it. For example, we >>could say that
> configuration information that is required to obtain basic connectivity on
> a network must be available in >>RA so it can be dynamically updated and
> shares fate with routing, and that everything that's not strictly required
> for >>the host's connectivity can go into DHCPv6. I don't know if it will
> be possible to draw a line here. If operators insist that >>DHCPv6 by
> itself must be sufficient, then we have no choice but to duplicate
> information.
>
> >>2. Attempt to say that RAs and DHCPv6 are simply containers and propose
> a unified option format so we can have the >>same options in both of them.
> I know this was already proposed once and was shot down, but I wasn't
> around, so I >>don't know why. (CCing a few people who might know).
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 24 Oct 2013 12:44:18 -0700 (PDT)

----- Original Message -----
> To: Mark ZZZ Smith <[email-masked]>; Ole Troan (otroan) <[email-masked]>
> Sent: Thursday, 24 October 2013 3:15 PM
> act as a fully functional standalone protocol

No, there is lots of glue missing. You'd have to define DHCPv6 options for all of the functions I listed. You'd also have to define an option conflict resolution method or methods for those options, when they happen to be supplied by both RAs and DHCPv6. It may be argued that an network operator shouldn't be doing this, but it might happen accidentally, because your mother is not a network operator, and in the interests of robustness, and more importantly Internet user satisfaction (also your mother), the IETF must not ignore those consequences.

By leaving these RA options out of DHCPv6, the IETF is doing better - it is preventing this problem ever occurring, rather than having to then solve it after having then just creating it. I don't think this problem has been solved for DNS options in RAs (duplication in the other direction), so I won't be confident people would get around to solving it if RA options are put in DHCPv6.

>, and the various attempts to

> functionality in other ietf protocols)"

So you solve the problem of excess duplication by creating more? 

> or "polling sucks".

> protocol instead of two protocols with strongly overlapping functionality

If you take address configuration out of DHCPv6, there is no overlapping functionality. Address configuration in DHCPv6 is the thing that is not correctly placed in my opinion, not the existence RAs. 

RAs should be limited to configuring layer 3 IPv6 parameters only, solving the network layer configuration problem, on a per link/subnet basis. Different links can have different layer 3 parameters, so the place to provide those parameters is on a per-link basis, using a link-local protocol.

DHCPv6 should be limited to providing primarily application parameters (and perhaps layer 4 parameters) to hosts, solving the end-to-end configuration problem. This problem exists regardless of the network layer parameters, and the parameters for applications are not restricted to being subnet specific, they're more likely to be global across the network, so a solution needs to be subnet/link-local protocol independent.

http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

If you shove everything into DHCPv6, you now start having a circular dependency problem - DHCPv6 requires UDP to work, which requires IPv6 to work, which requires DHCPv6 to work, which requires UDP to work etc., etc.,

> stop insisting that I run it on mine.

I'm not thinking of you, you're capable of running a network and fixing complicated problems with it. I'm thinking of my mother. How can she build a working IPv6 network without bothering me. Appletalk and IPX achieved this 20 years ago, it is time the Internet protocols met their standards of user friendliness. Avoiding duplication and function conflict visible to end-users is one of the best ways to achieve that.

> "We're not in the business of telling people how to run their 

That's true if you don't have to care about interoperability and ease of use.

Less is more. Complex equals more things that can break.

>>  - announce on-link presence of prefixes, exclusive of whether hosts have 
> addresses within the prefix, instead of individual manual configuration on each 
> host
>>  - adjust neighbor discovery parameters (e.g., timers), instead of 
> individual manual configuration on each host
>>  - announce prefix(es) to be used to generate SLAAC addresses, instead of 
> individual manual configuration on each host
>>  - indicate to hosts whether to use DHCPv6 or SLAAC or both (during a 
> transition between SLAAC/DHCPv6 or vice-versa), instead of individual manual 
> configuration on each host
>>  - advertise a default router, and an associated lifetime, instead of 
> individual manual configuration on each host
>> 
>> 
>> 
>> 
>>>  networks.
>>> 
>>>  Nick
>>> 
>> 
>

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 24 Oct 2013 16:45:15 -0400

Mark,

On 2013-10-24 3:44 PM, "Mark ZZZ Smith" <[email-masked]> wrote:

>
>RAs should be limited to configuring layer 3 IPv6 parameters only,
>solving the network layer configuration problem, on a per link/subnet
>basis. Different links can have different layer 3 parameters, so the
>place to provide those parameters is on a per-link basis, using a
>link-local protocol.
>
>DHCPv6 should be limited to providing primarily application parameters
>(and perhaps layer 4 parameters) to hosts, solving the end-to-end
>configuration problem. This problem exists regardless of the network
>layer parameters, and the parameters for applications are not restricted
>to being subnet specific, they're more likely to be global across the
>network, so a solution needs to be subnet/link-local protocol independent.
>

I am not arguing against these points, but have a few questions and
comments to this approach.  Based on the approach above, it appears that
in the model you describe, DHCPv6 would not provide layer 3 addresses to
end hosts (from the position of many operators, that's the first router or
host behind their access facility).

It this in fact what you are thinking, I believe there are a number of
issues that should be considered to that approach (if this is not what you
are describing, then ignore my next few statements).

Pushing addressing to the operators edge would effectively decentralize
addressing in large operator networks.   This may introduce significant
challenges for those operators (often managing millions of endpoints).
Also, pushing more work the the edge routers should be done with caution.
Edge routers are already becoming bogged down with code, and adding more
state and/or work for that device can exasperate this issue (sometimes it
takes months to over a year to get a code drop which can actually be put
into production).

Pushing the configuration to a centralized function like DHCP has definite
advantages in larger operators environments, providing the ability to
manage very large infrastructures.  It also provides them an ability to
standardize addressing across many different access types and/or platform
versions.  If we push this function to the edge, then we will need to
chase many vendors constantly, to keep up with the needs of this function.

Keeping the edge simple, and allowing the centralized functions to take on
the task of addressing and administering many of these configuration
functions makes the infrastructure much more manageable (and in my
experience, more stable which translates into a better user experience).

Of course, I am only talking about one (significant) use case, and any
changes and/or agreement on what to do with DHCPv6 and/or RAs needs to
take in to account all the use cases.

Regards,

Victor K

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Oct 2013 09:44:43 -0400

On Oct 24, 2013, at 8:55 AM, Victor Kuarsingh <[email-masked]> wrote:
>> 2. Attempt to say that RAs and DHCPv6 are simply containers and propose a unified option format so we can have the >>same options in both of them. I know this was already proposed once and was shot down, but I wasn't around, so I >>don't know why. (CCing a few people who might know).
> 
> [VK] This seems like an intriguing idea. Would this mean that every option must go into each container, or that there will be a common set of options which go into both, and perhaps exceptions go into one or the other? (On that latter part, I guess that line of thinking gets us back to where we are).

I think the main reason we didn't do this is that it seems like a mistake to have two mechanisms for delivering the same information.   If we really think RA is the right way to do all host configuration, why not just add a stateful mode?   If we really think DHCP is the right way to do all host configuration, why not just add support for configuring routes?   Stateful RA could actually be piggybacked onto DHCP, so that the router just creates a DHCP message and forwards it upstream, or answers it locally, depending on the circumstances.

Doing what's proposed here means that code on clients needs to be four times more complicated than it would be otherwise.   Putting DNS server options in RAs was a bad idea.   Continuing down that path is a worse idea, particularly since this proposal would mean there'd be two ways of representing DNS server information in RAs.

If we really got this wrong, we should fix it, not make it worse.

Anyway, that's the rhetorical position I'm going to stake out for now.   I'm curious to see if anybody can come up with a reason to disagree that doesn't simplify to either "I hate RA" or "I hate DHCP."

---

From: Xing Li <[email-masked]>
Date: Sun, 27 Oct 2013 21:39:49 +0800

> I think the main reason we didn't do this is that it seems like a mistake to have two mechanisms for delivering the same information.   If we really think RA is the right way to do all host configu…

Based on CERNET2's IPv6 experience, I fully support Ted's proposal. xing

---

From: Xing Li <[email-masked]>
Date: Sun, 27 Oct 2013 21:45:22 +0800

Ted Lemon 写道:
> On Oct 27, 2013, at 9:39 AM, Xing Li <[email-masked]> wrote:
>   
> I do not think that I made an actual proposal here.
>   
I mean "Stateful RA could actually be piggybacked onto DHCP, so that the 
router just creates a DHCP message and forwards it upstream, or answers 
it locally, depending on the circumstances." xing

---

From: Gert Doering <[email-masked]>
Date: Sun, 27 Oct 2013 15:52:24 +0100

Hi,

> it locally, depending on the circumstances." xing

This is called "DHCP relay or DHCP server on the router".  I can't see
what this has to do with RA ("periodically multicasted to everyone who
wants to receive it").

This idea is... completely lacking the understanding of the difference
between solicited and unsolicited information, and also of the existing
possibilities of just having a DHCPv6 server (or relay) on the router 
itself.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 27 Oct 2013 23:58:33 +0900

> possibilities of just having a DHCPv6 server (or relay) on the router

The way I read that was:

1. Host sends RS.
2. Router gets RS, encapsulates it in DHCPv6 option to DHCPv6 server.
3. Server replies with RA parameters.
4. Router sends unicast RA to host.

The unicast RA would have more information than the multicast RA (e.g.,
more specific routes). The idea being that you if you do this you can send
different clients different information (which is one of the things that
DHCPv6 offers but RAs typically do not).

So it's basically a RA-to-DHCPv6 translator in the router.

If you want to do it this way, I don't see why you would use DHCPv6 and not
something like radius, but I suppose you might want to do that if you need
to keep state on the server (radius is stateless).

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 27 Oct 2013 13:20:07 -0700 (PDT)

So what I really want to see is an actual and specific definition of the problem with RAs for conveying layer 3 protocol parameters, not the assertion that there are problems, and then time spent speculating on ways of achieving it.

It seems to me that the things people complain or might complain about RAs are :

(1) it is different to how it is done in IPv4, which is therefore asserting that IPv4 DHCP is the best way to solve the address configuration problem (which is different to the way the problem has been previously solved in every other protocol, including original IPv4, and needs to be considered in the context of when it was developed (IIRC, the primary thing DHCPv4 solved at the time, over bootp from which it is derived, was the ability to have more physical hosts than addresses, as long as the number of active hosts was less than or equal to the number of addresses. )

(2) it is database driven, so there are records of active addresses in use (which isn't actually the case, because DHCPv6 won't capture link-local addresses in use, or statically configured addresses)

(3) periodic unsolicited multicasts

So I think (2) is invalid, as it won't record link-local or static addresses in use. A better method would be to have the routers on the link monitor DADs, and them via some other method.

I think (3) is invalid, as by default RAs are announced once every 10 minutes, which means is RA multicasts are likely to be lesser of multicast traffic on the network. That timer can be changed to up to once very 30 minutes.

Which leaves (1). I don't think just because something is different is a reason to change it, when it has been shown to work.

The costs of providing two different methods for layer 3 network to host configuration would now be huge. It isn't just a matter of defining the methods in the IETF, which is cheap. For it to be useful and effective, it needs to be developed, debugged, deployed and supported/troubleshooted on hosts. Specifically, *all* possible hosts that might be exposed to the new method, which includes the billion+ IPv6 capable smartphones and tablets that are already deployed. Any IPv6 segment that a host might attach to might be using one or the other of these methods. To facilitate a smooth transition to DHCPv6 for everything, RAs will have to be enabled anyway ...

I don't think the argument that this decision is isolated to a network is valid. I'm guessing the example people are thinking of is the IS-IS vs OSPF vs other IGPs choice inside a network. However, that is nicely partitioned and isolated to a network using BGP (a single protocol between two different parties), and the only people who are impacted by the choice are the same people who choose, deploy and operate the devices in question, and their vendors (and the vendors won't provide that choice unless their are enough paying customers). A host to network interaction is very different when hosts are commonly owned, operated and developed by parties that are both exposed to the choice of the protocol between the host and the network but have no or very little say in it.

So provide evidence that RAs are inadequate, and that the huge time, effort and cost involved in moving to a dual RA and DHCPv6 method is worth while. Justify why creating more reasons not to deploy IPv6, by creating more choice and therefore more uncertainty, are worthwhile.

Create a problem statement before working on a solution to it.

Regards,
Mark.

>To: Gert Doering <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]>; Ted Lemon <[email-masked]>; Ole Troan (otroan) <[email-masked]>; Dave Thaler <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Monday, 28 October 2013 1:58 AM
>The unicast RA would have more information than the multicast RA (e.g., more specific routes). The idea being that you if you do this you can send different clients different information (which is one of the things that DHCPv6 offers but RAs typically do not).
>
>
>If you want to do it this way, I don't see why you would use DHCPv6 and not something like radius, but I suppose you might want to do that if you need to keep state on the server (radius is stateless).
>

---

From: Xing Li <[email-masked]>
Date: Mon, 28 Oct 2013 07:21:32 +0800

Lorenzo Colitti 写道:
> On Sun, Oct 27, 2013 at 11:52 PM, Gert Doering <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> The unicast RA would have more information than the multicast RA 
> (e.g., more specific routes). The idea being that you if you do this 
> you can send different clients different information (which is one of 
> the things that DHCPv6 offers but RAs typically do not).
>
> If you want to do it this way, I don't see why you would use DHCPv6 
> and not something like radius, but I suppose you might want to do that 
> if you need to keep state on the server (radius is stateless).
+1. The stateful configuration is required in CERNET2 case. xing

---

From: [email-masked]
Date: Mon, 28 Oct 2013 10:48:58 +0800

Hi authors,

    Sharing global IP address is a interesting topic of pool management. 
The pool 
management will be migrated to centralized mode to avoid complex 
configurations in
NAT44/NAT64, even in DHCP pools. 

    I reviewed this draft. I'm not sure whether we should define more 
detail in
request-ack between client and server? Or we should defined a specific 
protocol?
Or we should define some parameters ,such as priority/threshold...

Cheers,

Wei Meng
ZTE
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: Qiong <[email-masked]>
Date: Mon, 28 Oct 2013 13:16:47 +0800

Hi Wei,

Thanks for your review and comments.

Yes, we are trying to solve the problem of the scattered address pool
management. Currently, there are many transition devices deployed in our
network (even multiple transition instances will be needed for different
purpose or redundancy). However, different transition instance needs to be
configured with separated address pools. That will bring a great burden for
operators to manage rather scattered address pools.

More detailed protocol and parameters definitions are needed and will be
included in the next version. Here we would like to get
suggestions/comments from v6ops about this framework/solution.

Your further comments/suggestion/input are highly appreciated.

Best wishes
Qiong

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 28 Oct 2013 16:16:26 +0100

> +1. The stateful configuration is required in CERNET2 case. xing

This was proposed in the past and it has advantages to which I could agree.

I thought the goal was to not modify RA, whereas the above does modify 
the RA to include a DNS resolver.

If yes, would it be ok to include a Prefix Delegation option as well in 
the RA? (not an RFC4191 option, but a new Prefix Delegation option 
pasted from DHCPv6 Prefix Delegation).

Alex

---

From: james woodyatt <[email-masked]>
Date: Mon, 28 Oct 2013 08:50:14 -0700

On Oct 23, 2013, at 23:41 , Lorenzo Colitti <[email-masked]> wrote:

> 1. Decide a clear split between what goes into RA and what goes into DHCPv6, and then stick to it. For example, we could say that configuration information that is required to obtain basic connectivity on a network must be available in RA so it can be dynamically updated and shares fate with routing, and that everything that's not strictly required for the host's connectivity can go into DHCPv6. I don't know if it will be possible to draw a line here. If operators insist that DHCPv6 by itself must be sufficient, then we have no choice but to duplicate information.

I prefer this way out.  I've said this before, but now seems like a good time to say it again: stateless DHCPv6 has a lifetime of information problem, and I think RFC 3736 should be sent to pasture.

p1. If there are information objects that must be individually and separately configured at each host by the network, then stateful DHCPv6 [RFC 3315] is the protocol for doing that.

p2. The only information objects that deserve to be in RA messages are those that facilitate discovering routers and domain name resolving servers. (If pressed, I can come up with a couple of very minor exceptions, but I'm saving that for another discussion.)

p3. If there are information objects that do not strictly need to be individually and separately configured at each host by the network, and they are also not strictly required to facilitate routing and domain service discovery, then there are two viable options available: A) use stateful DHCPv6 despite not requiring state, or B) use DNS-SD, which is stateless.  If both are available on the same network, then DHCPv6 information should override DNS-SD information, because— well— sometimes the network decides that hosts need state. There is no good reason to lard up RA messages with this stuff too.

If operators insist that DHCPv6 by itself MUST be sufficient, then the only information that requires duplication is the minimal set that is currently defined in RA messages. Everything else

--james woodyatt <[email-masked]>

---

From: Gert Doering <[email-masked]>
Date: Mon, 28 Oct 2013 17:12:19 +0100

Hi,

> the RA to include a DNS resolver.

Uh.  *That* train has sailed 6 years ago with RFC5006...

> pasted from DHCPv6 Prefix Delegation).

What use would that be?  The benefit of RA is that "everyone can see them
and the information contained applies to *all* consumers, and is periodically
refreshed without having to poll".  PD is, by definition, very specific to
the device where you delegate to...

This thread is full of weirdness.

Gert Doering
        -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Oct 2013 17:39:59 +0000

> p1. If there are information objects that must be individually and separately configured at each host by the network, then stateful DHCPv6 [RFC 3315] is the protocol for doing that.

It sounds like you are saying that devices that need per-device configuration must use stateful address allocation.   That's an odd position to take, so I just want to make sure: is that what you intended to say?

FWIW, RFC 3736 was updated eight years ago with RFC 4242, which provides an information refresh timer.   If you aren't currently implementing that, you should.   Unfortunately the working group didn't think to actually say that 4242 updates 3736, so I'm not surprised if it's not on peoples' radar.

---

From: james woodyatt <[email-masked]>
Date: Mon, 28 Oct 2013 10:45:05 -0700

> It sounds like you are saying that devices that need per-device configuration must use stateful address allocation.   That's an odd position to take, so I just want to make sure: is that what you i…

Is stateful address allocation required?  I didn't think that was the case.  It seems perfectly reasonable to me that routers can advertise M=0 and O=1, and hosts can then proceed to use RFC 3315 stateful DHCPv6 to obtain things like their OpenDirectory service parameters.  Isn't that what the DUID mechanism is supposed to be about?  Decoupling the address allocation from the host identifier?

> FWIW, RFC 3736 was updated eight years ago with RFC 4242, which provides an information refresh timer.   If you aren't currently implementing that, you should.   Unfortunately the working group did…

That's a problem. I'm not sure how much uptake RFC 4242 has gotten.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 29 Oct 2013 02:45:45 +0900

On Tue, Oct 29, 2013 at 2:39 AM, Ted Lemon <[email-masked]> wrote:

> FWIW, RFC 3736 was updated eight years ago with RFC 4242, which provides
> an information refresh timer.   If you aren't currently implementing that,
> you should.   Unfortunately the working group didn't think to actually say
> that 4242 updates 3736, so I'm not surprised if it's not on peoples' radar.
>

 With a minimum of 10 minutes, unfortunately.

---

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 28 Oct 2013 20:17:12 +0100

On Thu, 24 Oct 2013, Ted Lemon wrote:

> Anyway, that's the rhetorical position I'm going to stake out for now. 
> I'm curious to see if anybody can come up with a reason to disagree that 
> doesn't simplify to either "I hate RA" or "I hate DHCP."

I'll take a shot at outlining the differences as I see them between the 
two, and the factors that may influence the "I hate RA" or "I hate DHCP" 
reply in each particular case...

1) Interworking with different L2 topologies

RA is "server-initiated, send once, receive many, no confirmation" 
abstraction - something that works well on the 10base2-type shared bus 
and even the today's wired ethernet, but looks quite miserable on the 
WiFi media without the ugly special tricks (802.11 provides reliable 
delivery for unicast frames, and does not provide one for multicast 
frames, also the physical speeds are different and even the contention 
management and the speed/modulation can be different as well).

DHCPv6 is "client-initiated, send once, receive once, confirmation" 
abstraction. This may be wasteful on the low-bandwidth links that provide 
bus topology, but maps extremely well onto scenarios like WiFi - as it 
allows to maintain somewhat familiar mode of operation to wired ethernet.

This is where the p2p, acknowledged nature of DHCPv6 may be beneficial - 
on a crowded large-scale WiFi, without dirty tricks, you simply will not 
get the SLAAC working because the multicast RAs will get crunched by the 
interference.

Alternatively, in a very mobile environment and the RFC-compliant router, 
multicast solicited RAs might make a significant portion of your traffic - 
which, due to a difference in modulation, etc. may eat way more bandwidth 
than if they were sent unicast.

2) Acknowledged vs. unacknowledged

DHCPv6 needs at least 2 packets. RA is just one packet.

RA Plus: RA is quicker

RA Minus: you have to take care that it is legitimate router and not your 
evil neighbor sending you the RAs you take the configuration from.

DHCPv6 Plus: works well in the noisy/lossy environments

DHCPv6 minus: takes at least 1 RTT to the server.

3) Client initiated vs. server initiated

Despite of the division above, RA can be client-initiated, to some extent, 
with RS, and DHCPv6 can be server-initiated, to some extent, with 
"Reconfigure" messages.

If we treat these as "nudge" messages, the behavior of the sending 
and receiving parties is similar - the "nudge" message 
causes the orderly protocol exchange to occur before the due time.

The part that is different, though, is that RA, due to its "send once, 
receive many" nature, can aggregate the "nudge" messages, so intuitively 
seems best for a scenario with a very large number of the hosts, as it 
should have self-stabilizing properties, compared to DHCPv6.

This "self-stabilizing" property intuitively seems to make RA safer to 
use, IFF it is used in purely "multicast" fashion.
However, refer to (1) for the interaction with the underlying media.

4) Centralized coordination vs. distributed coordination

RA, due to its "send once, receive many" nature, in its pure 
form necessarily can not dictate a per-client settings, but rather 
can only advise the domain the client would pick from (SLAAC).

DHCPv6 on the other hand, due to its p2p nature is by default well suited 
for the individual per-client tweaking.

The distributed nature can be a blessing if you do not care about who gets 
which address and a curse if you need to account everyone strictly.

NB: address assignment does not mean that the hosts will always use those 
addresses - e.g. it's perfectly possible to statically configure a 
different address, but we talk just homogenous standards-compliant 
well-behaved hosts for simplicity sake).

That's why I do not use the word "control" but use the word 
"coordination".

5) Involvement or not into routing

RAs are a mechanism to provide some form of reliability for the routing in 
an independent fashion to the reasonably unsophisticated hosts. DHCPv6 was 
specifically denied any involvement in the routing.

While architecturally "pure", the reliability and timing of the routing 
resiliency provided by the RAs is far below those achieved by FHRP 
protocols which are used in today's networks predominantly.

This might create a dissonance between those who want to ensure RAs are 
used for routing, and those who do not see any use of them in that regard - 
with the corresponding contention of adding anything routing-related into 
DHCPv6.

6) Server locality

Both DHCPv6 and RA are inherently link-local mechanisms, however DHCPv6 
has a means to "jump" over multiple hops by use of the relays. This means 
RA *has* to be distributed, while DHCPv6 can be both centralized and 
distributed. Frequently it is made centralized because of other benefits 
that centralized administration brings, but almost any router today can 
run a DHCPv6 server on the box with no problem.

7) Programming: UDP vs. ICMP

For a random programmer today, coding a server to receive the data on a 
UDP socket is a more familiar exercise than working with ICMP. 
Disclaimer: the value of "random" was chosen to be "me" for arbitrary 
reasons. This point is more of a rathole and a personal preference, 
probably. I think I remember Dave Thaler saying one of the mechanisms in 
Windows was way easier to extend than the other, but I do not remember 
which.

8) Separate vs. unified management

If DHCPv4 and routing is managed by the different groups in the 
organization, then conceivably the "server" people will not like to have 
their work go away and similarly "router" guys are happy to get rid of yet 
another point of coordination and argument. This is where the "I hate 
$protocol" should definitely pop up. Add here the concerns from the 
previous 7 points.

HTH.

--a

---

From: Tim Chown <[email-masked]>
Date: Mon, 28 Oct 2013 19:50:59 +0000

> That's a problem. I'm not sure how much uptake RFC 4242 has gotten.

As the person who pushed for this option as a result of experiments ten years ago, it’s disappointing.

Can we at least fix that now?

Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 28 Oct 2013 20:04:13 +0000

>  With a minimum of 10 minutes, unfortunately.

At the time, 10 minutes was significantly better than infinity.  It was somewhat arbitraily picked.

The concern was a very low value could cause significant load on the stateless dhc server.

The use case that drove RFC4242 was renumbering; we went through the RFC4192 process, and this was a glaring gap.

Tim

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Oct 2013 22:21:45 +0000

Andrew, this is a really great analysis.  It would be nice if it could be turned into a draft.

Andrew Yourtchenko <[email-masked]> wrote:

RA Plus: RA is quicker

6) Server locality

HTH.

--a

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 29 Oct 2013 13:53:11 +0900

Andrew, those are good points, though from the perspective of protocol
design I think semantics and functionality are a bit more important than
performance. Once you have the semantics right you can look at improving
performance (e.g., via QoS, prioritization, queue isolation, etc. etc.),
but if the semantics are wrong it's hard to fix that.

So, semantics I think you forgot:

1. DHCPv6 makes it very hard to update client information from the network
side.

You can use reconfigure, but that requires authentication (clients MUST
discard reconfigure messages that aren't authenticated). I don't know if
anyone actually implements authentication. Also, it requires that the
server know the DUID of the client. How do you do this if the client has
never talked to you before, (e.g., if you booted after the client)? You'd
have to have all the DHCPv6 servers on link communicate with each other.

Also, it's not clear to me how you would implement reconfigure in a
stateless environment, since the server doesn't know which clients are
still there and not all clients (none?) implement RFC 4242.

For an example of why this is useful, consider a homenet. You have two
routers on the same link that share state via a routing protocol. Router A
is unplugged. Router B knows this and wants to tell the client "don't use
router A as DNS server any more". How do you do this? Using an RA you can
just send out a message with a lifetime of zero. How do you do it with
DHCPv6?

2. DHCPv6 doesn't support multiple sources of information.

In particular, stateful DHCPv6 requires that the client choose one of the
advertise messages it receives. The spec doesn't prevent it from starting a
new transaction with a transaction ID, but I don't know what the original
server would do if it received such a message. The RFC doesn't seem to
specify this very well, if at all.

3. You can do per-client configuration using RA as well.

There's nothing preventing routers from replying to RS packets with unicast
RAs, so per-client configuration is possible. There's also nothing stopping
you from causing an RS to trigger a provisioning (e.g., radius) request to
a server asking for configuration parameters for that client - for example,
giving it its own VLAN and its own /64. (I've built networks that do this,
so I know it works). So your "it's not possible to jump" assertion is not
entirely true. It's true that RAs can't jump by themselves, but the
information requests can.

I'm also don't think the "multicast doesn't work in congested networks"
argument is valid. In a network where multicast is so overloaded that it's
completely broken, it's not just RAs that will fail. NSes will get dropped
too; MDNS won't work; basically, the network is broken. That said, unicast
RAs don't have this problem.

I'd be happy to contribute to a draft documenting these issues. Andrew,
were you going to start one?

On Tue, Oct 29, 2013 at 4:17 AM, Andrew Yourtchenko <[email-masked]>wrote:

> abstraction - something that works well on the 10base2-type shared bus and
> even the today's wired ethernet, but looks quite miserable on the WiFi
> media without the ugly special tricks (802.11 provides reliable delivery
> for unicast frames, and does not provide one for multicast frames, also the
> physical speeds are different and even the contention management and the
> speed/modulation can be different as well).
>
> If we treat these as "nudge" messages, the behavior of the sending and
> receiving parties is similar - the "nudge" message causes the orderly
> protocol exchange to occur before the due time.
>
> RA, due to its "send once, receive many" nature, in its pure form
> necessarily can not dictate a per-client settings, but rather can only
> advise the domain the client would pick from (SLAAC).
>
> That's why I do not use the word "control" but use the word "coordination".
>
> that centralized administration brings, but almost any router today can run
> a DHCPv6 server on the box with no problem.
>
> UDP socket is a more familiar exercise than working with ICMP. Disclaimer:
> the value of "random" was chosen to be "me" for arbitrary reasons. This
> point is more of a rathole and a personal preference, probably. I think I
> remember Dave Thaler saying one of the mechanisms in Windows was way easier
> to extend than the other, but I do not remember which.
>
> ______________________________**_________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/v6ops<https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 29 Oct 2013 14:13:39 +0900

Comments inline.

> get the SLAAC working because the multicast RAs will get crunched by the

Well, but multicast NS won't work either, so the network is pretty broken
at this point. You can also send solicited RAs unicast, of course.

> evil neighbor sending you the RAs you take the configuration from.

But you can't authenticate in DHCPv6 either, right? Whether you get an
unsolicited "here's some config parameters" RA or a unicast "thank you for
your request, here's some config parameters" DHCPv6 reply, the problem is
the same: is the source trustworthy? AIUI we don't have any solution for
this except DHCPv6 guard and RA guard, which are effectively the same
solution. I mean - we do have SEND and DHCPv6 authentication, but does
anyone implement those?

> should have self-stabilizing properties, compared to DHCPv6.

RAs also allow someone who's not the original server to send you a nudge.
In DHCPv6 you need to know the client's DUID to send a nudge, which is hard
(impossible?) to do unless the client has talked to you before, or you've
at least seen a multicast solicit from it.

> advise the domain the client would pick from (SLAAC).

You can dictate per-client settings via unicast RA. But it's true that you
can't dictate per-client addressing, because RAs don't support that.

> for the individual per-client tweaking.

I agree that it's more suited. A lot of this is not due to the protocol
itself, but due to the fact that we have a lot of infrastructure (protocol
and implementation) built around this: we have relays, relay-inserted
options, sophisticated DHCPv6 servers with per-client configuration, etc.

> protocols which are used in today's networks predominantly.

This is a fairly complex issue. It very much depends on what network you're
building.

If you're in a wired environment, it doesn't matter - send RAs every 3
seconds with lifetimes of 6 seconds and you're doing roughly as well as
VRRP. (Yes, you can crank VRRP timers down lower than that, but in a large
network with lots of VLANs, that will cause too much control plane load).
All else being equal, I think multicast RA should be more scalable because
it just requires the router to periodically spit out identical packets,
whereas VRRP requires group coordination and state machines. But that might
be in the noise.

If you're in a home environment, the coordination required to use VRRP
might not be available, but having multiple routers send RAs is quite easy.

In a battery-constrained setting, sending frequent RAs is expensive. You
can use NUD with low timers to do failover, but that can get expensive if
you have many clients. So there are lots of tradeoffs here.

> a DHCPv6 server on the box with no problem.

I've built networks that send radius requests on receipt of RSes and then
send unicast RAs to the client. So it's possible to do this via RA as well.
It's true that we have a lot more infrastructure to do this in DHCPv6 as
well.

> to extend than the other, but I do not remember which.

ICMP is harder than UDP to implement; it often requires raw sockets or
kernel collaboration (e.g., on Linux RDNSS information can be read using
netlink. UDP is much simpler). On the other hand, I think stateful DHCPv6
is a more complicated protocol to implement than RAs, with more message
types and so on.

> $protocol" should definitely pop up. Add here the concerns from the

Agreed. This is mostly true in an enterprise environment though. You don't
get turf wars at home. :-) On the other hand, in some enterprises, it's
possible that the "server" people might relish the chance of not having to
support DHCPv6 at all. If everything the client needs can be done via RA -
they might just say "great, one less thing we have to do to move to IPv6".

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 29 Oct 2013 01:47:23 -0700 (PDT)

Hi,

A few other points:

- Rogue DHCPv6 servers are also a potential issue, so this sort of problem isn't exclusive to RAs. 

- DHCPv6 uses multicast for Information-Request messages for stateless DHCPv6 service and Solicit messages for stateful DHCPv6 service, so a link suffering from excessive multicast traffic drops may also prevent DHCPv6 working reliably or quickly.

I'm a bit confused by "something that works well on the 10base2-type shared bus and even the today's wired ethernet, but looks quite miserable on the WiFi media without the ugly special tricks". My understanding is that Internet protocols of all types are to be designed with the assumption of the possibility of a low level of packet loss. If the packet loss is too high, then link-layer designers are advised to use link-layer reliability mechanisms, as per advised in RFC3819. I'm interested in details of the "ugly special tricks" if they're more than proprietary wifi link-layer multicast reliability mechanisms. 

General lack of Wifi multicast performance is the motive behind the following draft - replication and link-layer unicasting of unsolicited RAs could be used on Wifi to make them more reliable.

MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6
http://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00

- "While architecturally "pure", the reliability and timing of the routing resiliency provided by the RAs is far below those achieved by FHRP protocols which are used in today's networks predominantly." This seems to suggest that you can't run VRRP/HSRP if you're using RAs. I don't think they're mutually exclusive, as long as the RAs come from the virtual router link-local address, rather than the routers' physical interface link-local addresses.

Regards,
Mark.

>To: Andrew Yourtchenko <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; Ted Lemon <[email-masked]>; Ole Troan (otroan) <[email-masked]>; Dave Thaler <[email-masked]> 
>Sent: Tuesday, 29 October 2013 3:53 PM
>Andrew, those are good points, though from the perspective of protocol design I think semantics and functionality are a bit more important than performance. Once you have the semantics right you can look at improving performance (e.g., via QoS, prioritization, queue isolation, etc. etc.), but if the semantics are wrong it's hard to fix that.
>
>
>1. DHCPv6 makes it very hard to update client information from the network side.
>
>
>You can use reconfigure, but that requires authentication (clients MUST discard reconfigure messages that aren't authenticated). I don't know if anyone actually implements authentication. Also, it requires that the server know the DUID of the client. How do you do this if the client has never talked to you before, (e.g., if you booted after the client)? You'd have to have all the DHCPv6 servers on link communicate with each other.
>
>Also, it's not clear to me how you would implement reconfigure in a stateless environment, since the server doesn't know which clients are still there and not all clients (none?) implement RFC 4242.
>
>
>For an example of why this is useful, consider a homenet. You have two routers on the same link that share state via a routing protocol. Router A is unplugged. Router B knows this and wants to tell the client "don't use router A as DNS server any more". How do you do this? Using an RA you can just send out a message with a lifetime of zero. How do you do it with DHCPv6?
>
>
>
>
>In particular, stateful DHCPv6 requires that the client choose one of the advertise messages it receives. The spec doesn't prevent it from starting a new transaction with a transaction ID, but I don't know what the original server would do if it received such a message. The RFC doesn't seem to specify this very well, if at all.
>
>
>
>
>There's nothing preventing routers from replying to RS packets with unicast RAs, so per-client configuration is possible. There's also nothing stopping you from causing an RS to trigger a provisioning (e.g., radius) request to a server asking for configuration parameters for that client - for example, giving it its own VLAN and its own /64. (I've built networks that do this, so I know it works). So your "it's not possible to jump" assertion is not entirely true. It's true that RAs can't jump by themselves, but the information requests can.
>
>
>
>
>I'm also don't think the "multicast doesn't work in congested networks" argument is valid. In a network where multicast is so overloaded that it's completely broken, it's not just RAs that will fail. NSes will get dropped too; MDNS won't work; basically, the network is broken. That said, unicast RAs don't have this problem.
>
>
>I'd be happy to contribute to a draft documenting these issues. Andrew, were you going to start one?
>
>
>
>On Tue, Oct 29, 2013 at 4:17 AM, Andrew Yourtchenko <[email-masked]> wrote:
>
I'll take a shot at outlining the differences as I see them between the two, and the factors that may influence the "I hate RA" or "I hate DHCP" reply in each particular case...
>>RA is "server-initiated, send once, receive many, no confirmation" abstraction - something that works well on the 10base2-type shared bus and even the today's wired ethernet, but looks quite miserable on the WiFi media without the ugly special tricks (802.11 provides reliable delivery for unicast frames, and does not provide one for multicast frames, also the physical speeds are different and even the contention management and the speed/modulation can be different as well).
>>
>>DHCPv6 is "client-initiated, send once, receive once, confirmation" abstraction. This may be wasteful on the low-bandwidth links that provide bus topology, but maps extremely well onto scenarios like WiFi - as it allows to maintain somewhat familiar mode of operation to wired ethernet.
>>
>>This is where the p2p, acknowledged nature of DHCPv6 may be beneficial - on a crowded large-scale WiFi, without dirty tricks, you simply will not get the SLAAC working because the multicast RAs will get crunched by the interference.
>>
>>Alternatively, in a very mobile environment and the RFC-compliant router, multicast solicited RAs might make a significant portion of your traffic - which, due to a difference in modulation, etc. may eat way more bandwidth than if they were sent unicast.
>>
>>RA Minus: you have to take care that it is legitimate router and not your evil neighbor sending you the RAs you take the configuration from.
>>
>>Despite of the division above, RA can be client-initiated, to some extent, with RS, and DHCPv6 can be server-initiated, to some extent, with "Reconfigure" messages.
>>
>>If we treat these as "nudge" messages, the behavior of the sending and receiving parties is similar - the "nudge" message causes the orderly protocol exchange to occur before the due time.
>>
>>The part that is different, though, is that RA, due to its "send once, receive many" nature, can aggregate the "nudge" messages, so intuitively seems best for a scenario with a very large number of the hosts, as it should have self-stabilizing properties, compared to DHCPv6.
>>
>>This "self-stabilizing" property intuitively seems to make RA safer to use, IFF it is used in purely "multicast" fashion.
>>RA, due to its "send once, receive many" nature, in its pure form necessarily can not dictate a per-client settings, but rather can only advise the domain the client would pick from (SLAAC).
>>
>>DHCPv6 on the other hand, due to its p2p nature is by default well suited for the individual per-client tweaking.
>>
>>The distributed nature can be a blessing if you do not care about who gets which address and a curse if you need to account everyone strictly.
>>
>>NB: address assignment does not mean that the hosts will always use those addresses - e.g. it's perfectly possible to statically configure a different address, but we talk just homogenous standards-compliant well-behaved hosts for simplicity sake).
>>
>>RAs are a mechanism to provide some form of reliability for the routing in an independent fashion to the reasonably unsophisticated hosts. DHCPv6 was specifically denied any involvement in the routing.
>>
>>While architecturally "pure", the reliability and timing of the routing resiliency provided by the RAs is far below those achieved by FHRP protocols which are used in today's networks predominantly.
>>
>>This might create a dissonance between those who want to ensure RAs are used for routing, and those who do not see any use of them in that regard - with the corresponding contention of adding anything routing-related into DHCPv6.
>>
>>
>>6) Server locality
>>
>>Both DHCPv6 and RA are inherently link-local mechanisms, however DHCPv6 has a means to "jump" over multiple hops by use of the relays. This means RA *has* to be distributed, while DHCPv6 can be both centralized and distributed. Frequently it is made centralized because of other benefits that centralized administration brings, but almost any router today can run a DHCPv6 server on the box with no problem.
>>
>>For a random programmer today, coding a server to receive the data on a UDP socket is a more familiar exercise than working with ICMP. Disclaimer: the value of "random" was chosen to be "me" for arbitrary reasons. This point is more of a rathole and a personal preference, probably. I think I remember Dave Thaler saying one of the mechanisms in Windows was way easier to extend than the other, but I do not remember which.
>>
>>If DHCPv4 and routing is managed by the different groups in the organization, then conceivably the "server" people will not like to have their work go away and similarly "router" guys are happy to get rid of yet another point of coordination and argument. This is where the "I hate $protocol" should definitely pop up. Add here the concerns from the previous 7 points.
>>
>>HTH.
>>
>>
>>--a
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 29 Oct 2013 14:03:50 +0100

Le 28/10/2013 17:12, Gert Doering a écrit :
>> I thought the goal was to not modify RA, whereas the above does
>> modify the RA to include a DNS resolver.
>

Right.

But in this thread some say we should no longer do DHCP-typical-info in
the RA, and at the same time they propose to do it, provided the backend
info comes from a DHCP server.  Hence my question about whether a
delegated prefix (another DHCP-typical-info) would be ok for this
concept. (I author an earlier draft in this space).

>> If yes, would it be ok to include a Prefix Delegation option as
>> well in the RA? (not an RFC4191 option, but a new Prefix Delegation
>> option pasted from DHCPv6 Prefix Delegation).
>
> What use would that be?  The benefit of RA is that "everyone can see
> them and the information contained applies to *all* consumers, and is
> periodically refreshed without having to poll".  PD is, by
> definition, very specific to the device where you delegate to...

I tend to agree that RA's content is generally valid for everyone
receiving that RA, and that typically RAs are multicasted to all nodes
on a link.

However, there are some specific cases where the RA is unicast to
particular nodes and contain information specific to that node.  For
example in Proxy Mobile IPv6 RFC5213 an access router sends an RA to a
particular mobile host attaching to it, and it puts inside a prefix to
make believe that particular node to be at its home.  Each node has a
different home prefix.  Another example is in Fast Mobile IPv6 protocol
RFC4068 where a Proxy RA contains an address specific to a mobile.  A
more remote example is that of RPL RFC6550 which uses a new ICMP message
'RPL Control Message' remotely similar to RA, and whose destination is
unicast.

Apart from that, the use case I am considering is fast exchanges of IP
messages to establish quickly short-lived communications (10ms IP
establishment address/defroute, and app-layer communications during a
few minutes).  Used in vehicular communications.  A vehicle containing a
cellular link (SIM subscription) may offer Internet connectivity to a
SIM-less vehicle nearby - mobile billboard vehicle, like in this figure
http://en.wikipedia.org/wiki/File:MSNBC_mobile_billboard_at_Union_Station.jpg
(check the "Free WiFi" banner).

Alex

> Gert Doering -- NetMaster
>

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 29 Oct 2013 14:36:43 +0100

Ted, Lorenzo,

Given the submission tool is for now closed, I've whipped up the 
xml+txt and a git repo and put it onto https://github.com/ayourtch/ra-dhcpv6/
I also tried to express/generalize Lorenzo's points below and put them 
into a separate new sections.

More inline..

On Tue, 29 Oct 2013, Lorenzo Colitti wrote:

> Andrew, those are good points, though from the perspective of protocol design I think semantics and functionality are a bit more important than performance. Once you have the semantics
> right you can look at improving performance (e.g., via QoS, prioritization, queue isolation, etc. etc.), but if the semantics are wrong it's hard to fix that.
> You can use reconfigure, but that requires authentication (clients MUST discard reconfigure messages that aren't authenticated). I don't know if anyone actually implements
> authentication.

Agreed. This is something that needs testing.

> Also, it requires that the server know the DUID of the client. How do you 
> do this if the client has never talked to you before, (e.g., if you 
> booted after the client)?
> You'd have to have all the DHCPv6 servers on link communicate with each other.

Yes, you will need some form of redundancy, and means you can not be fully 
"stateless".

But if we are going the road of extending things, we might come up with a 
multicast RECONFIGURE message, which would specify the time interval 
within which the clients should come back and report their DUID.

I can't argue too hard on this one because I never tested this in real 
life.

> For an example of why this is useful, consider a homenet. You have two routers on the same link that share state via a routing protocol. Router A is unplugged. Router B knows this and
> wants to tell the client "don't use router A as DNS server any more". How do you do this? Using an RA you can just send out a message with a lifetime of zero. How do you do it with
> DHCPv6?

I agree this is definitely a useful scenario. I've added it under a new 
section "Single Source of Truth vs. Multiple sources".

> In particular, stateful DHCPv6 requires that the client choose one of the advertise messages it receives. The spec doesn't prevent it from starting a new transaction with a transaction
> ID, but I don't know what the original server would do if it received such a message. The RFC doesn't seem to specify this very well, if at all.
>

I think this is conceptually, again, "single source of truth" problem.

> There's nothing preventing routers from replying to RS packets with unicast RAs, so per-client configuration is possible. There's also nothing stopping you from causing an RS to trigger
> a provisioning (e.g., radius) request to a server asking for configuration parameters for that client - for example, giving it its own VLAN and its own /64. (I've built networks that do
> this, so I know it works). So your "it's not possible to jump" assertion is not entirely true. It's true that RAs can't jump by themselves, but the information requests can.
>

yeah. I did not go into this in my write-up, but it is entirely possible 
to morph RA so it becomes some kind of DHCPv6, and it is likewise possible 
to morph DHCPv6 so it becomes some kind of RA. To some extent, you can do 
it without the host modifications. Full conversion of either would require 
host mods. This was beyond what I aimed for - merely a comparison of the 
protocols 'as is'.

> 
> I'm also don't think the "multicast doesn't work in congested networks" argument is valid. In a network where multicast is so overloaded that it's completely broken, it's not just RAs
> that will fail. NSes will get dropped too; MDNS won't work; basically, the network is broken. That said, unicast RAs don't have this problem.

IPv4 does not have this problem. your DHCPv4 will complete. After a 
minute, but it will complete. Your client has only one ARP entry (default 
gateway). The connectivity sucks big time, but it survives.

Contrary to that, in IPv6 the very first RS is lost and if the client is 
not persistent enough, this is where it ends (Hoping the hosts get 
draft-ietf-6man-resilient-rs implemented so it is less of a problem)

> I'd be happy to contribute to a draft documenting these issues. Andrew, were you going to start one?

Sure, github above. feel free to clone/edit/send pull requests :)

--a

> RA is "server-initiated, send once, receive many, no confirmation" abstraction - something that works well on the 10base2-type shared bus and even the today's wired ethernet, but
> looks quite miserable on the WiFi media without the ugly special tricks (802.11 provides reliable delivery for unicast frames, and does not provide one for multicast frames, also
> the physical speeds are different and even the contention management and the speed/modulation can be different as well).
> 
> DHCPv6 is "client-initiated, send once, receive once, confirmation" abstraction. This may be wasteful on the low-bandwidth links that provide bus topology, but maps extremely well
> onto scenarios like WiFi - as it allows to maintain somewhat familiar mode of operation to wired ethernet.
> 
> This is where the p2p, acknowledged nature of DHCPv6 may be beneficial - on a crowded large-scale WiFi, without dirty tricks, you simply will not get the SLAAC working because the
> multicast RAs will get crunched by the interference.
> 
> Alternatively, in a very mobile environment and the RFC-compliant router, multicast solicited RAs might make a significant portion of your traffic - which, due to a difference in
> modulation, etc. may eat way more bandwidth than if they were sent unicast.
> 
> The part that is different, though, is that RA, due to its "send once, receive many" nature, can aggregate the "nudge" messages, so intuitively seems best for a scenario with a
> very large number of the hosts, as it should have self-stabilizing properties, compared to DHCPv6.
> 
> NB: address assignment does not mean that the hosts will always use those addresses - e.g. it's perfectly possible to statically configure a different address, but we talk just
> homogenous standards-compliant well-behaved hosts for simplicity sake).
> 
> This might create a dissonance between those who want to ensure RAs are used for routing, and those who do not see any use of them in that regard - with the corresponding
> contention of adding anything routing-related into DHCPv6.
> 
> 
> 6) Server locality
> 
> Both DHCPv6 and RA are inherently link-local mechanisms, however DHCPv6 has a means to "jump" over multiple hops by use of the relays. This means RA *has* to be distributed, while
> DHCPv6 can be both centralized and distributed. Frequently it is made centralized because of other benefits that centralized administration brings, but almost any router today can
> For a random programmer today, coding a server to receive the data on a UDP socket is a more familiar exercise than working with ICMP. Disclaimer: the value of "random" was chosen
> to be "me" for arbitrary reasons. This point is more of a rathole and a personal preference, probably. I think I remember Dave Thaler saying one of the mechanisms in Windows was
> way easier to extend than the other, but I do not remember which.
> 
> If DHCPv4 and routing is managed by the different groups in the organization, then conceivably the "server" people will not like to have their work go away and similarly "router"
> guys are happy to get rid of yet another point of coordination and argument. This is where the "I hate $protocol" should definitely pop up. Add here the concerns from the previous
> 7 points.
> 
> HTH.
> 
> 
> --a

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 29 Oct 2013 15:05:19 +0100

Hi,

> - Rogue DHCPv6 servers are also a potential issue, so this sort of problem isn't exclusive to RAs.

Good point, agree.

> I'm a bit confused by "something that works well on the 10base2-type 
>shared bus and even the today's wired ethernet, but looks quite miserable 
>on the WiFi media without the ugly special tricks". My understanding is 
>that Internet protocols of all types are to be designed with the 
>assumption of the possibility of a low level of packet loss. If the 
>packet loss is too high, then link-layer designers are advised to use 
>link-layer reliability mechanisms, as per advised in RFC3819. I'm 
>interested in details of the "ugly special tricks" if they're more than 
>proprietary wifi link-layer multicast reliability mechanisms.

I removed the word "ugly", it should not have been there, my apologies.

"advised" != "real life". 802.11-2002, page 842, which discusses the 
individual and group-addressed MPDU transfer procedure. So, yes, the loss 
for mcast can be significantly higher than for unicast, which means loss 
of the periodic RAs and unreliable and hard to troubleshoot sporadic 
failures on the clients.

The ugly^H^H^H^H tricks indeed involve unicasting the multicast traffic at 
link layer.

>
> General lack of Wifi multicast performance is the motive behind the 
>following draft - replication and link-layer unicasting of unsolicited 
>RAs could be used on Wifi to make them more reliable.
>

hm.  Interesting idea. Although it adds a new (and big) requirement into 
the First Hop Security - to track and enforce the behavior of hosts to 
this regard. Tricky.

>
>
> - "While architecturally "pure", the reliability and timing of the 
>routing resiliency provided by the RAs is far below those achieved by 
>FHRP protocols which are used in today's networks predominantly." This 
>seems to suggest that you can't run VRRP/HSRP if you're using RAs. I 
>don't think they're mutually exclusive, as long as the RAs come from the 
>virtual router link-local address, rather than the routers' physical 
>interface link-local addresses.

No, this is a long-winded way to say that RA as a routing 
mechanism is useless a lot of today's networks' requirements, not that it 
is incompatible. :-)

--a

---

From: "Weil, Jason" <[email-masked]>
Date: Tue, 29 Oct 2013 10:44:14 -0400

Leo,

First I wanted to say this is useful work and I support it.

This topic in this email reminds me of an issue that we have run across
that might be relevant to your draft:

The use case involves a home network whose gateway router sets M=1 and A=1
in order to provide DHC and and SLAAC for hosts that do not implement a
DHC client. If the DHCPv6 Server is implementing IP assignment using
interface-identifier and using the same prefix as advertised in the PIO
(assuming the server resides on the router advertising the PIO) with the A
bit set, hosts that support SLAAC and a DHCPv6 client could construct the
same address using DHC as the one they construct using SLAAC. What is not
clear is what hosts should do in this situation. IMO, there is a benefit
if hosts that support both SLAAC and DHCPv6 construct the address and
prefer the DHC address over the SLAAC address. The benefit is that you
reduce the number of active addresses and all hosts end up with a single
address per prefix administered in this fashion.

Of course if your DHC Server implements another assignment algorithm (e.g.
Random) then your hosts that support both may end up with 2 addresses out
of the same prefix.

Thanks,

Jason

On 10/23/13 7:19 AM, "Liubing (Leo)" <[email-masked]> wrote:

>>(sensors,
>[Bing] Agreed. These lightweight/embed systems might become an important
>part of the IPv6 net. ND allows minimal management burden for them.
>>address

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 27 Oct 2013 09:42:30 -0400

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 29 Oct 2013 12:16:48 -0700 (PDT)

----- Original Message -----
> From: Andrew Yourtchenko <[email-masked]>
> Cc: Lorenzo Colitti <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; Ted Lemon <[email-masked]>; Ole Troan (otroan) <[email-masked]>; Dave Thaler <[email-masked]>
> Sent: Wednesday, 30 October 2013 1:05 AM

<snip>

> mechanism is useless a lot of today's networks' requirements, not that 

So I'm afraid I'm still confused by this.

The reason why you need VRRP/HSRP etc. is because ND NUD isn't acceptably fast enough to detect that a default gateway has gone away. It might be possible to lower the NUD timers such that they detect default gateway death much quicker, however you then have all of the hosts actively probing the default gateway very quickly, creating load on its control plane.

VRRP/HSRP avoids this control plane load by making the the switch between routers transparent or nearly transparent to the hosts, without the need to lower NUD timers. It could be viewed as a NUD special case and optimisation.

This all has nothing to do with RAs or DHCPv6 - the need for VRRP is to overcome a performance limit in ND NUD, and that limitation would still exist in a DHCPv6 only model without VRRP/HSRP. So I don't understand why DHCPv6 is or woud be "better" and RAs are "worse" in this scenario.

Regards,
Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 29 Oct 2013 12:28:12 -0700 (PDT)

----- Original Message -----
> From: "Weil, Jason" <[email-masked]>
> To: Liubing (Leo) <[email-masked]>; Wuyts Carl <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Wednesday, 30 October 2013 1:44 AM

Another way to describe your scenario is that it is a transition scenario between SLAAC and stateful DHCPv6, since some of your hosts don't support stateful DHCPv6.

In your scenario, I don't think it is a big problem that some of your hosts will have two addresses within the same prefix - IPv6 hosts are designed to cope with many addresses, and a /64 has plenty of addresses to go around.

If you do want to be specifically selective about which hosts use SLAAC and which hosts use stateful DHCPv6 for addressing, use host specific RAs which set the M and the PIO A bits on a selected host basis.

Regards,
Mark.

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 29 Oct 2013 20:33:30 +0100

> This all has nothing to do with RAs or DHCPv6 - the need for VRRP is to overcome a performance limit in ND NUD, and that limitation would still exist in a DHCPv6 only model without VRRP/HSRP. So I…

Essence of that section: RA deals with routing [not always very 
efficently]. DHCPv6 does not do it at all.

--a

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 30 Oct 2013 04:38:07 +0900

> efficently]. DHCPv6 does not do it at all.

I think the words you want are that RA "shares fate" with routing, right?

---

From: "Weil, Jason" <[email-masked]>
Date: Tue, 29 Oct 2013 15:59:40 -0400

I wasn't claiming it was a problem that a host has two addresses. I was
just saying it might be beneficial in certain scenarios for all hosts on a
network segment (SLAAC-only, SLAAC+DHC, DHC-only) to have a single address
created using the same algorithm.

Jason

On 10/29/13 3:28 PM, "Mark ZZZ Smith" <[email-masked]> wrote:

>> To: Liubing (Leo) <[email-masked]>; Wuyts Carl
>><[email-masked]>; "[email-masked]" <[email-masked]>
>> Cc: "[email-masked]" <[email-masked]>; "[email-masked]"
>><[email-masked]>;
>Another way to describe your scenario is that it is a transition scenario
>between SLAAC and stateful DHCPv6, since some of your hosts don't support
>stateful DHCPv6.
>
>In your scenario, I don't think it is a big problem that some of your
>hosts will have two addresses within the same prefix - IPv6 hosts are
>designed to cope with many addresses, and a /64 has plenty of addresses
>to go around.
>
>If you do want to be specifically selective about which hosts use SLAAC
>and which hosts use stateful DHCPv6 for addressing, use host specific RAs
>which set the M and the PIO A bits on a selected host basis.
>
>Regards,
>Mark.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 29 Oct 2013 12:59:54 -0700

At Tue, 29 Oct 2013 14:13:39 +0900,

> is a more complicated protocol to implement than RAs, with more message

I don't know why Linux uses a non portable API, but I believe
writing programs handling RA options like RDNSS is no harder than
writing DHCPv6 client in terms of socket API.  As long as the system
supports RFC3542 you should be able to write a portable RA "client"
pretty easily (meaning as easy/hard as writing some UDP client
program).  For example, FreeBSD's rtsold supports RDNSS and (AFAIK)
only relies on the RFC3542 APIs.  Also, since DHCP is trickier than
other UDP applications in some points (it's more sensitive to which
interface to use, and in some cases you need to make sure the source
address is link-local, etc), it's quite likely that you'll need
something like unusual APIs like RFC3542 or some non-portable system
dependent interface to write a standard-compliant DHCP(v6) client.

So, overall, I'd say the programming difficulty regarding UDP (DHCP)
vs ICMP (RS/RA) is marginal.

As I'm writing a response, I'll also make a comment on another, more
minor point:

At Tue, 29 Oct 2013 14:13:39 +0900,

> solution. I mean - we do have SEND and DHCPv6 authentication, but does

If you mean the Delayed Authentication Protocol by DHCPv6
authentication, the WIDE DHCPv6 supports it:
http://sourceforge.net/projects/wide-dhcpv6/
although I myself have only used it in testing.  I heard some other
vendors implemented it, too.

(And, for that matter, it also supports the Information Refresh Time
option (RFC4242)).

--
jinmei

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 29 Oct 2013 21:20:37 +0100

On Wed, 30 Oct 2013, Lorenzo Colitti wrote:

> On Wed, Oct 30, 2013 at 4:33 AM, Andrew Yourtchenko <[email-masked]> wrote:
>       Essence of that section: RA deals with routing [not always very efficently]. DHCPv6 does not do it at all.
> 
> 

I don't think "shares fate" is the correct wording for it - but maybe I 
misunderstand what you meant. Please expand.

Meantime I tried to reword that section: 
https://github.com/ayourtch/ra-dhcpv6/blob/0bfbfd0f3c69de9b0c208aa1b7933ab6cc71be30/draft-yourtchenko-ra-dhcpv6-comparison-00.txt#L230

Take a look and see if this captures the things any better.

It's a very tricky section. There's an intertwine of "DHCPv6 was not 
allowed to do any routing" + the implicit "I got an RA therefore that 
router exists" (though "I got a DHCP offer from that router therefore that 
router exists" is also can be argued for) + the "multiple sources of 
truths"...  I feel it turns into a micro-version of the "RA vs. DHCP" 
debate - maybe worth just folding it back into a pure factual "It was 
decided that RA does routing, DHCPv6 does not, by the way RA does a slow 
redundancy, which people do not like, therefore they think DHCPv6 should 
do routing".

--a

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 29 Oct 2013 13:23:40 -0700 (PDT)

----- Original Message -----
> To: Mark ZZZ Smith <[email-masked]>; Liubing (Leo) <[email-masked]>; Wuyts Carl <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Wednesday, 30 October 2013 6:59 AM

Once you have a host using two different address configuration methods at the same time (SLAAC+DHC), then I don't think it is possible to avoid having a host have two addresses. 

Regarding the using the same algorithm, that is the reason why I asked for the text in the opaque stable IID draft to not specifically limit the address generation algorithm specified in it to be limited to SLAAC. There is no reason why a stateful DHCPv6 server couldn't use the algorithm to generate IPv6 addresses/IIDs before handing them to clients.

Regards,
Mark.

> This E-mail and any of its attachments may contain Time Warner Cable proprietary 
> information, which is privileged, confidential, or subject to copyright 
> belonging to Time Warner Cable. This E-mail is intended solely for the use of 
> the individual or entity to which it is addressed. If you are not the intended 
> recipient of this E-mail, you are hereby notified that any dissemination, 
> distribution, copying, or action taken in relation to the contents of and 
> attachments to this E-mail is strictly prohibited and may be unlawful. If you 
> have received this E-mail in error, please notify the sender immediately and 
> permanently delete the original and any copy of this E-mail and any printout.
>

---

From: Brian Haberman <[email-masked]>
Date: Tue, 29 Oct 2013 16:26:20 -0400

Hi Andrew,

On 10/29/13 4:20 PM, Andrew Yourtchenko wrote:
> allowed to do any routing" + the implicit "I got an RA therefore
> that router exists" (though "I got a DHCP offer from that router
> therefore that router exists" is also can be argued for) + the

But you do not know that the DHCPv6 message you received came from a
router or a server.

Regards,
Brian

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 29 Oct 2013 21:52:40 +0100

> But you do not know that the DHCPv6 message you received came from a

Thanks. Not sure whether it should actually be another section or not - 
"Control plane and data plane" - RAs are sent by an entity that is in the 
path, whereas the DHCPv6 may be sent by an off-path entity...

--a

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Oct 2013 10:28:00 +1300

On 29/10/2013 21:47, Mark ZZZ Smith wrote:

> If the packet loss is too high, then link-layer designers are advised to use link-layer reliability mechanisms, as per advised in RFC3819.

That may in fact be exactly the wrong advice. At least, the results
I've seen on Coded TCP suggest that retransmission managed by the link
layer can do more harm than good, compared to a smart transport layer
designed for uncongested lossy paths.

(Conventional TCP is a different matter, which is why RFC 3819
says what it says.)

  Brian

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 29 Oct 2013 21:50:58 +0000

On 29/10/2013 20:20, Andrew Yourtchenko wrote:
> redundancy, which people do not like, therefore they think DHCPv6 should do
> routing".

WFM, and I very much like your draft so far, btw.

Later on in the text, it says:

>    However, the "single source of truth" nature of DHCPv6 prevents the
>    successful operation in case of multiple servers on the segment
>    supplying different information. RAs in this case may still work.
> 
>    Some consider the inability to support this scenario crucial, and
>    some think it is not useful. This creates contention between the
>    proponents of those who want DHCPv6 deal with routing, and those who
>    think RA is the single possible candidate for that.
> 
>    The other aspect is that because RA ties in the routing and
>    addressing information, one can say "RA shares the fate with
>    routing". However, this distinction is merely because of the
>    decision to explicitly keep DHCPv6 away from routing - so can not be
>    considered a true property of the protocol.

The premise that many people in the IETF seem to be working on is that the
typical - or even a common - deployment case of ipv6 will involve multiple
routers per lan segment.  I say this because every time the issue of DHCP
providing a defgw comes up, one of the main arguments that's trotted out is
that it will break the multiple-routers-per-lan-segment scenario.  The
above 3 paragraphs also strongly hint at this as being the target deployment.

Well maybe dhcpv6 doesn't do that, but the operational reality is that
multiple gateways on the same lan is going to be the rare exception rather
than the rule. The reason why I think this is because:

1. enterprises have an obtuse obsession for L2.  They'd pave the world with
L2 and extend L2 from one end of the universe to the other if they could.
Just look at the horror of vxlan (who are they kidding?  themselves?) as a
perfect example of this insanity.  I don't know why this is but it's the
way that lots of enterprise rolls, ranging from SME to largish networks.
Outside truly large operations (i.e. 10s of thousands of users), I have
never got the impression that enterprises got L3 routing.

2. homenet: I don't understand the target audience for the entire homenet
multiple network movement. Putting this another way: who is going to debug
homenet multiple network stuff when it breaks, because as far as I can
tell, that belongs in the realm of level 2 engineering escalation (i.e.
$120/hr sort of thing).  It's a little far-fetched to expect gramps and
grandma to set up and maintain and debug multiple networking segments.  A
good chunk of the stuff going on in homenet is vastly more complicated than
pretty much any home network is ever going to need.  Architecturally
interesting, but srsly not realistic as a viable approach to home networking.

3. service providers - the single operational group on the internet that
actually understands L3 / network segmentation and why it's important -
will attempt avoid multiple gateways per network like the plague because it
makes their deployment scenarios more complicated and provides no extra
value.  For server / host farms, service providers like FHRP with tight
timers because it gives control of onward connectivity.

All of which doesn't leave very many more user-market segments.

Regarding RA for routing and DHCP for addressing, what people care about is
connectivity.  What I need as an operator is a protocol (preferably a
single protocol because that is simpler) which will enable my boxes to gain
the connectivity they need.  Whether you call this routing or providing a
default gateway, I don't much mind.

Look, there's too much ideology going on here.  The IETF is being dazzled
by the sight of multiple lan segments and multiple egress gateways without
realising that these are the minority configuration.  All this effort is
going into optimising ipv6 address / lan autoconfiguration for these
unusual scenarios without heeding the sober reality that most people,
service providers and enterprises are only ever going to want to have a
single defgw per lan segment, and that by far the most common deployment
scenario will be a single lan segment per organisation.

I'm aware that this viewpoint will be regarded as retrograde, and that a
bunch of people on this list will probably sit there, rolling their eyes
and thinking: "yeah, and 640k was enough for everyone".

Just bear in mind that added complexity is not necessarily a good thing.
The support costs are high and the return on effort is dubious at best.
IOW, the IETF is optimising a corner case.  This is not smart.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 29 Oct 2013 22:03:35 +0000

> path, whereas the DHCPv6 may be sent by an off-path entity...

this brings up another important issue, namely source address validation.

I'm not sure if it's relevant to bring this up in your draft, but the
requirement to handle snooping two new protocols for effective lan source
address validation seems to be more than most vendors can handle at the
moment, which means that as operators we are very exposed to rogue RAs and
rogue DHCPv6 packets flying around networks.

[Once upon a time, all we needed was vendor support for dhcp snooping and
ARP inspection.  Now we need an entire IETF working group to handle the
complication that the IETF has brought upon itself by overthinking ipv6 lan
requirements.  Is this progress?]

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 29 Oct 2013 22:05:15 +0000

> designed for uncongested lossy paths.

if you could explain it to my GPRS cellular provider that doing 40 second
RTT isn't actually helpful, I'd really appreciate it.  Particularly when
all the retransmissions count towards my monthly data budget.

Nick

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 29 Oct 2013 23:38:44 +0100

> requirements.  Is this progress?]

[ It creates the jobs lost due to simplicity gained by the absence of 
NATs. :-) ]

I've captured the non-bracketed part of your comment into a
separate section, even if it is not really a comparison.

Maybe given that all the rest of the bullet points is implicitly "Reasons 
for keeping both of the protocols implemented in the nodes - they are useful 
in different circumstances",  I should create a part "Reasons 
for having only one of the protocols running in a particular network" ?

--a

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 29 Oct 2013 22:47:13 +0000

On 29/10/2013 22:38, Andrew Yourtchenko wrote:
> for keeping both of the protocols implemented in the nodes - they are
> useful in different circumstances",  I should create a part "Reasons for
> having only one of the protocols running in a particular network" ?

i think this would be useful, yes.

Nick

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 29 Oct 2013 23:55:24 +0100

> i think this would be useful, yes.

Done.

--a

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 30 Oct 2013 01:22:48 -0700 (PDT)

----- Original Message -----
> To: Lorenzo Colitti <[email-masked]>
> Cc: Mark ZZZ Smith <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; Ted Lemon <[email-masked]>; Ole Troan (otroan) <[email-masked]>; Dave Thaler <[email-masked]>
> Sent: Wednesday, 30 October 2013 7:20 AM

(Disclaimer: Haven't had a chance to read the text yet)

I would generalise the description of RAs. 

They're not "Router Advertisments", they're Advertisements (typically) from Routers, and they propagate per-subnet IPv6 parameters to hosts - per-link MTU, per-link ND timers, per-link address configuration method, per-link on-link prefix status, default router lifetime (if not announced as zero). The can be used to propagate per-client per-link IPv6 parameters if necessary using unicasts.

I think DHCPv6 is really solving the application layer configuration problem, which is independent of and not specific to the underlying links and network layer parameters. I think IPv6 per-link parameter setting and application layer parameter setting are conceptually quite different problems (I think the sets of layer parameters they provide values for is one of the give aways.)

Regards,
Mark.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 30 Oct 2013 10:38:12 +0100

inline

> never got the impression that enterprises got L3 routing.

I think you do Enterprise engineers a serious dis-service. Many
consciously choose for L2 interfaces (with HSRP/ VRRP) isolation LANs
between service providers precisely because L3 is more complex to debug
and engineer across an administrative boundary. Even agreeing on an IGP
can be tricky, never mind worrying about route flapping or
redistribution loops. Experience has shown that HSRP/VRRP + static
routes in a simple active/standby construction can deliver extremely
robust SLA KPI's.

Secondly, practical deployment of L3 routing protocols on end hosts was
a no-go in IPv4.

> interesting, but srsly not realistic as a viable approach to home networking.

I think Homenet WG well-understands the challenges with deployment and
little-conf..

> All of which doesn't leave very many more user-market segments.

I disagree entirely, and would characterise this as a rather
network-operator-centric view, rather than a host-centric view.

> scenario will be a single lan segment per organisation.

Erm. Have you missed the move to wireless?

My smartphone already has two radios and a physical interface, connected
to multiple providers.

How exactly do you then configure a "single defgw per lan segment"
(without draft-troan-homenet-sadr-01)

-- 
Regards,
RayH

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 30 Oct 2013 22:07:52 +0900

On Wed, Oct 30, 2013 at 6:50 AM, Nick Hilliard <[email-masked]> wrote:

> The premise that many people in the IETF seem to be working on is that the typical
> - or even a common - deployment case of ipv6 will involve multiple routers
> per lan segment.  I say this because every time the issue of DHCP providing
> a defgw comes up, one of the main arguments that's trotted out is that it
> will break the multiple-routers-per-lan-segment scenario.  The above 3
> paragraphs also strongly hint at this as being the target deployment.
>

Find me an medium or large enterprise deployment that doesn't have two
routers on every LAN segment. I'll bet almost all of them do, because they
know that if one crashes or they want to take it down for maintenance, they
have an outage, and nobody likes outages.

Now, the way - the *only* way - you do this in IPv4 is to run some failover
protocol like VRRP between the routers. In IPv6 you can do that, but you
don't have to, because all the RA protocol was designed to support multiple
sources of information and multiple routers.

There are situations in which that capability is useful, and I don't think
we should take it away.

---

From: "Weil, Jason" <[email-masked]>
Date: Wed, 30 Oct 2013 10:27:56 -0400

Silly Nick!

Operational reality never factored into this equation. It is a thought
project.

Jason

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 30 Oct 2013 18:14:58 +0000

> have an outage, and nobody likes outages.

no need to bet - using multiple routers on a LAN is standard procedure
where uptime matters.

The question is why would someone use RA for multiple gateway announcement
when you'll get much better operational performance from a FHRP + single
gateway address?  And why use RA for addressing when you'll get finer
grained operational host control using dhcp?  Or when you need to use dhcp
anyway in order to make your hosts do what they need to do?  Or on server
farms when most of your hosts are statically addressed and it doesn't make
sense to have multiple gateways with different addresses - and you'll get
better uptime by not using RA?

I'm not proposing to take away the option of using RAs if that's what you
want to do.  I'm only suggesting that for many situations, it makes more
sense to have a single static gateway address (optionally with multiple
routers using a FHRP if you need reliability) and that consequently the
idea of periodically announcing a selection of arbitrary gateways via RA is
operationally second rate.

Nick

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 30 Oct 2013 12:39:50 -0700 (PDT)

----- Original Message -----
> Cc: "[email-masked] WG" <[email-masked]>
> Sent: Thursday, 31 October 2013 5:14 AM
> grained operational host control using dhcp?

It's been said a number of times in this thread. You can have client specific RAs that solve that problem. This is not a missing capability that duplicating RA functionality in DHCPv6 would then provide.

> Or when you need to use dhcp

I'd really like to know specific details of these many situations, and what specific benefits switching off RAs would have. I've been in many situations in many networks, and when I consider my IPv4 experience (and also compare it to my Novell IPX and Appletalk experiences), I see a lot of value in having RAs provide default gateway(s) (VRRP/HSRP or not) information and other layer 3 parameters to directly attached hosts from the directly attached router(s). This is in comparison with the IPv4 alternative effort of enabling and configuring a heavier and more resource consuming stateful DHCP server on either the first hop routers, or enabling DHCP relays and then having to have a redundant DHCP infrastructure somewhere else in the network.

It could be argued that DHCP could be enabled and configured by default, but that is also obviously the case with RAs, and they've been enabled by default since day one. The ability to automate the configuration of DHCP doesn't inherently make DHCP better than RAs.

Regards,
Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 30 Oct 2013 13:06:04 -0700 (PDT)

----- Original Message -----
> From: Ted Lemon <[email-masked]>
> Cc: Andrew Yourtchenko <[email-masked]>; Lorenzo Colitti <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; Ole Troan (otroan) <[email-masked]>; Dave Thaler <[email-masked]>
> Sent: Wednesday, 30 October 2013 11:07 PM
> On Oct 30, 2013, at 4:22 AM, Mark ZZZ Smith <[email-masked]> 
> wrote:
> 
>>  I think DHCPv6 is really solving the application layer configuration 
> problem, which is independent of and not specific to the underlying links and 
> network layer parameters.
> 
> Actually DHCPv6 is a poor solution to that problem, because application 
> configuration is not typically network-specific.  This has been discussed at 
> some length recently on the IETF mailing list.
> 

I'll have to look that up. Thanks for letting me know.

I have recently been thinking a bit more about that in the context of the DHCPv6 option transparency draft I posted, and have started to wonder if LDAP or SLP style directories would be better, with a special well known directory branch to represent network or subnet local application parameters.

Thanks,
Mark.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 30 Oct 2013 21:56:40 +0000

On 30/10/2013 20:06, Mark ZZZ Smith wrote:
> I have recently been thinking a bit more about that in the context of
> the DHCPv6 option transparency draft I posted, and have started to
> wonder if LDAP or SLP style directories would be better, with a special
> well known directory branch to represent network or subnet local
> application parameters.

rfc2244?

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 30 Oct 2013 22:14:49 +0000

On 30/10/2013 19:39, Mark ZZZ Smith wrote:
> It's been said a number of times in this thread. You can have client
> specific RAs that solve that problem. This is not a missing capability
> that duplicating RA functionality in DHCPv6 would then provide.

You don't have address assignment with RA: you have prefix assignment and
host address selection.  I'm sure this is great for other people, but I do
not want this behaviour on my networks, ever.  I want address assignment
via stateful dhcp.  This is a missing capability of RA.

> I'd really like to know specific details of these many situations, and
> what specific benefits switching off RAs would have.

Please see my earlier email:

http://www.ietf.org/mail-archive/web/v6ops/current/msg17769.html

The standard argument of having multiple routers on a network announcing
different prefixes and allowing host self-selection is a red herring. This
is going to be an edge case because most networks are not multihomed.  A
small number are; let them use whatever they want.

The standard argument of having multiple routers on a network announcing
multiple gateways for the same prefix value is a red herring because the
failover time for RA gateway address selection cannot match that of a FHRP
based mechanism.  No doubt some people will want to use multiple gateways
addresses.  If they do, I wish them well.

If you want to run with RAs, then go for it.  I don't because they add
nothing to my production configurations except unnecessary complication.
All my networks are mtu 1500 and I don't need to tweak ND timers and all
that.  Other than assigning a defgw, the only thing that RA does on my dhcp
enabled networks is to point everything towards dhcp.  From my point of
view this is entirely pointless and if dhcpv6 had defgw assignment, I could
ditch an entire protocol.  This would be good (simpler configuration,
easier to protect at L2, etc).

For service provider and enterprise purposes, it is more sensible to
centralise configuration and have a single protocol for assigning all
network parameters than having two auto-configuration protocols doing
slightly different things in slightly different ways with poorly defined
interactions and several pitfalls if you don't know what you're doing.

> I've been in many
> situations in many networks, and when I consider my IPv4 experience (and
> also compare it to my Novell IPX and Appletalk experiences), I see a lot
> of value in having RAs provide default gateway(s) (VRRP/HSRP or not)
> information and other layer 3 parameters to directly attached hosts from
> the directly attached router(s).

Glad it works for you.  I see it as being utterly pointless, because it's
an entire protocol just to provide a single network parameter which could
just as easily be provided by another protocol which I need to run anyway
because stateless dhcpv6 has stuff that I need to provide on production
networks that RA doesn't provide.  Does this work for you as a problem
statement?  What about any of the other reasons I've provided?

> This is in comparison with the IPv4
> alternative effort of enabling and configuring a heavier and more
> resource consuming stateful DHCP server on either the first hop routers,
> or enabling DHCP relays and then having to have a redundant DHCP
> infrastructure somewhere else in the network.

stateful dhcpv4 works incredibly well in production.

> It could be argued that DHCP could be enabled and configured by default,

This is a straw man.  Straw men don't help.

Nick

---

From: Andrew Yourtchenko <[email-masked]>
Date: Wed, 30 Oct 2013 19:41:17 -0400

On Wed, 30 Oct 2013, Mark ZZZ Smith wrote:

> They're not "Router Advertisments", they're Advertisements (typically) 
>from Routers, and they propagate per-subnet IPv6 parameters to hosts - 
>per-link MTU, per-link ND timers, per-link address configuration method, 
>per-link on-link prefix status, default router lifetime (if not announced 
>as zero). The can be used to propagate per-client per-link IPv6 
>parameters if necessary using unicasts.
>
>
>problem, which is independent of and not specific to the underlying links 
>and network layer parameters. I think IPv6 per-link parameter setting and 
>application layer parameter setting are conceptually quite different 
>problems (I think the sets of layer parameters they provide values for is 
>one of the give aways.)

I will try to rephrase this into another section:

-- cut --
Link-centric vs. client-centric

RA traditionally provide the information pertaining to the link and its 
parameters, whereas DHCPv6 typically provides the information specific to 
the client configuration.

However, this distinction is mostly a semantic one "by convention" - 
because technically nothing prevents to put a per-client configuration 
into an RA that would be sent unicast (at this point however the periodic 
multicast RA mechanism will break), as well as use the scopes in Stateless 
DHCPv6 with appropriate blobs of data to communicate the per-link 
parameter.

-- cut --

Is this an adequate representation ?

--a