Subject: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 6 Jan 2014 07:59:39 +0000

Hi Dear All,

In ietf88 meeting, we discussed draft-liu-bonica-dhcpv6-slaac-problem which indicated the hosts' behavior might varied on DHCPv6/SLAAC interaction caused by ambiguous standard definition. (The draft was adopted as ietf-v6ops-dhcpv6-slaac-problem after the meeting.)

Since the above draft is only filed as a Problem Statement document, as discussed in the meeting, the WG decided to initiate another draft to provide some operational guidance of what the administrators should do given the fact that the host behavior might varied in some situations. 

So this is the 00 version. Hope you can read it and comment.
Your review and comments would be appreciated very much.

And a late happy new year to you all.

Best regards
Bing

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, December 25, 2013 9:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] new draft: draft-liu-v6ops-dhcpv6-slaac-guidance
> 
> 
> A new draft has been posted, at
> http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance. Please
> take a look at it and comment.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Karsten Thomann <[email-masked]>
Date: Tue, 07 Jan 2014 14:49:25 +0100

Hi,

I think the draft is useful for everyone who is starting an ipv6 deployment and doesn't know how 
to handle the flags in the right way.

Notes:
Section 3.1
In my opinion there should be an addional note that DHCPv6 is not anymore a requirement for 
hosts (RFC6434).
I know it is covered in section 3.2, to make sure all hosts support DHCPv6 but should be also 
covered as a note at the SLAAC section.

Section 3.3
s/Window 8/ Windows 8/

Best regards
Karsten

Am Montag, 6. Januar 2014, 07:59:39 schrieb Liubing:
> Hi Dear All,
> 
> In ietf88 meeting, we discussed draft-liu-bonica-dhcpv6-slaac-problem which
> indicated the hosts' behavior might varied on DHCPv6/SLAAC interaction
> caused by ambiguous standard definition. (The draft was adopted as
> ietf-v6ops-dhcpv6-slaac-problem after the meeting.)
> 
> Since the above draft is only filed as a Problem Statement document, as
> discussed in the meeting, the WG decided to initiate another draft to
> provide some operational guidance of what the administrators should do
> given the fact that the host behavior might varied in some situations.
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 8 Jan 2014 01:40:13 +0000

Hi Karsten,

Thanks a lot for your review and comment.
I think your suggestion is good, we'll revise accordingly in the next version.

Best regards,
Bing

From: v6ops [mailto:[email-masked]] On Behalf Of Karsten Thomann
Sent: Tuesday, January 07, 2014 9:49 PM
To: [email-masked]
Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance

Hi,

I think the draft is useful for everyone who is starting an ipv6 deployment and doesn't know how to handle the flags in the right way.

Notes:

Section 3.1

In my opinion there should be an addional note that DHCPv6 is not anymore a requirement for hosts (RFC6434).

I know it is covered in section 3.2, to make sure all hosts support DHCPv6 but should be also covered as a note at the SLAAC section.

Section 3.3

s/Window 8/ Windows 8/

Best regards

Karsten

> > From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>

> > To: [email-masked]<mailto:[email-masked]>

> > Cc: [email-masked]<mailto:[email-masked]>

> > [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Jan 2014 16:05:31 +0900

Authors,

I see this document has a "Guidance for DHCPv6-only Deployment" section
which mentions "DHCPv6-only configuration without RAs". Three points on
that:

1. We had a discussion on this topic when discussing the problem statement
draft a couple of weeks ago, and I thought we had agreed that a DHCPv6-only
configuration without RAs doesn't do anything useful at all, and since it
doesn't do anything useful at all, it should not be documented. See for
example at http://www.ietf.org/mail-archive/web/v6ops/current/msg18231.html

If it's not documented in the problem statement document because it doesn't
do anything useful, then it certainly should not be documented in the
guidance to operators document. And in fact, the draft already states that
"this is an invalid use case".

Can you remove it, then? As an operational group we don't want to provide
guidance on invalid use cases. :-)

2. That section should also make it clear that in a DHCPv6-only deployment:

   - If there is no RA, the addresses assigned by DHCPv6 cannot be used for
   anything at all.
   - If there is an RA that specifies a default router but does not specify
   the on-link prefix, then all traffic, even between hosts on the same link,
   is routed at layer 3 by the default gateway.

3. Please do not cite [DHCPv6-ROUTE]. That document was so controversial
that it was removed from the WG's charter and is no longer a WG item, so it
is inappropriate to cite it in an operational guidance document.

Cheers,
Lorenzo

On Mon, Jan 6, 2014 at 4:59 PM, Liubing (Leo) <[email-masked]>wrote:

> Hi Dear All,
>
> In ietf88 meeting, we discussed draft-liu-bonica-dhcpv6-slaac-problem
> which indicated the hosts' behavior might varied on DHCPv6/SLAAC
> interaction caused by ambiguous standard definition. (The draft was adopted
> as ietf-v6ops-dhcpv6-slaac-problem after the meeting.)
>

---

From: [email-masked]
Date: Wed, 08 Jan 2014 10:40:16 +0100 (CET)

> "this is an invalid use case".

The authors may well agree that this a DHCPv6-only configuration without
RAs doesn't do anything useful. I'd be inclined to agree *today* - but I
certainly wouldn't want to rule out DHCPv6-only configuration without
RAs in the future.

> guidance on invalid use cases. :-)

Removing it is not going to make the demand for DHCPv6-only configuration
without RAs magically disapppear.

Steinar Haug, AS 2116

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Jan 2014 18:51:07 +0900

> certainly wouldn't want to rule out DHCPv6-only configuration without

It's not the role of an operational group to surmise on what future
standards might exist, or to make future standards. So I agree this
document shouldn't rule out DHCPv6-only configuration. But for precisely
the same reason, it should also not imply that it may exist in the future.

So the correct course of action is to remove it, because it is
inappropriate to cite something that's not a standard (and, given *years*
of lack of consensus, is unlikely to become a standard anytime soon) in an
operational guidance document.

> without RAs magically disapppear.

Sure, but v6ops doesn't do protocol work. That discussion belongs in 6man.
And until 6man has that discussion and changes the standards, then
DHCPv6-only configuration is not a standard and it's inappropriate to cite
it in an operational guidance document.

---

From: Ole Troan <[email-masked]>
Date: Wed, 8 Jan 2014 11:54:03 +0100

> It's not the role of an operational group to surmise on what future standards might exist, or to make future standards. So I agree this document shouldn't rule out DHCPv6-only configuration. But for precisely the same reason, it should also not imply that it may exist in the future.
> 
> So the correct course of action is to remove it, because it is inappropriate to cite something that's not a standard (and, given *years* of lack of consensus, is unlikely to become a standard anytime soon) in an operational guidance document.
> 
> Sure, but v6ops doesn't do protocol work. That discussion belongs in 6man. And until 6man has that discussion and changes the standards, then DHCPv6-only configuration is not a standard and it's inappropriate to cite it in an operational guidance document.

I would expect the operational working group to come up with the problem statement / use cases.

those I have not seen yet, at least no in a language I can understand.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Jan 2014 13:46:20 +0100

Le 08/01/2014 08:05, Lorenzo Colitti a écrit :
> 1. We had a discussion on this topic when discussing the problem
> statement draft a couple of weeks ago, and I thought we had agreed that
> a DHCPv6-only configuration without RAs doesn't do anything useful at
> all, and since it doesn't do anything useful at all, it should not be
> documented. See for example at
> http://www.ietf.org/mail-archive/web/v6ops/current/msg18231.html
>
> If it's not documented in the problem statement document because it
> doesn't do anything useful, then it certainly should not be documented
> in the guidance to operators document. And in fact, the draft already
> states that "this is an invalid use case".
>
> Can you remove it, then? As an operational group we don't want to
> provide guidance on invalid use cases. :-)
>
>
>   * If there is no RA, the addresses assigned by DHCPv6 cannot be used
>     for anything at all.

Lorenzo - you keep saying that but does it have any practical basis? 
Have you tried it?

Alex

>   * If there is an RA that specifies a default router but does not
>     specify the on-link prefix, then all traffic, even between hosts on
>     the same link, is routed at layer 3 by the default gateway.
>
>
> that it was removed from the WG's charter and is no longer a WG item, so
> it is inappropriate to cite it in an operational guidance document.
>
> Cheers,
> Lorenzo
>
>
> On Mon, Jan 6, 2014 at 4:59 PM, Liubing (Leo) <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Dear All,
>
>     In ietf88 meeting, we discussed
>     draft-liu-bonica-dhcpv6-slaac-problem which indicated the hosts'
>     behavior might varied on DHCPv6/SLAAC interaction caused by
>     ambiguous standard definition. (The draft was adopted as
>     Since the above draft is only filed as a Problem Statement document,
>     as discussed in the meeting, the WG decided to initiate another
>     draft to provide some operational guidance of what the
>     administrators should do given the fact that the host behavior might
>     varied in some situations.
>
>      > From: v6ops [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of [email-masked]
>     <mailto:[email-masked]>
>      > To: [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Wed, 08 Jan 2014 14:02:14 +0100 (CET)

> Lorenzo - you keep saying that but does it have any practical basis? 

I believe the idea here is that without RA:

- you don't have a default gateway
- you cannot determine what prefixes are on-link/off-link

Steinar Haug, AS2116

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Jan 2014 22:32:44 +0900

On Wed, Jan 8, 2014 at 9:46 PM, Alexandru Petrescu <
[email-masked]> wrote:

> Lorenzo - you keep saying that but does it have any practical basis? Have
> you tried it?
>

 http://tools.ietf.org/html/rfc4943#section-4 :

   The result of these changes is that destinations are considered
   unreachable when there is no routing information for that destination
   (through a default router or otherwise)."

Since DHCPv6 does not configure routing, if all you have is addresses from
DHCPv6 and no RA, then all destinations are unreachable.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 8 Jan 2014 13:39:34 +0000

Hi Lorenzo,

Thanks much for your review and comments.
Please see replies inline.

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Wednesday, January 08, 2014 3:06 PM
To: Liubing (Leo)
Cc: [email-masked]
Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance

Authors,

I see this document has a "Guidance for DHCPv6-only Deployment" section which mentions "DHCPv6-only configuration without RAs". Three points on that:

1. We had a discussion on this topic when discussing the problem statement draft a couple of weeks ago, and I thought we had agreed that a DHCPv6-only configuration without RAs doesn't do anything useful at all, and since it doesn't do anything useful at all, it should not be documented. See for example at http://www.ietf.org/mail-archive/web/v6ops/current/msg18231.html
[Bing] Yes I remember the discussion a couple of weeks ago. And the above sentence “this is an invalid use case” is just to reflect the discussion result.

If it's not documented in the problem statement document because it doesn't do anything useful, then it certainly should not be documented in the guidance to operators document. And in fact, the draft already states that "this is an invalid use case".

Can you remove it, then? As an operational group we don't want to provide guidance on invalid use cases. :-)
[Bing] I agree with you that “DHCPv6-only without RA” should not be identified as a valid use case. But in the document, what we want to caution the reader is that some operating systems would rely RAs to trigger DHCPv6. I think “RAs are necessary for IPv6 configuration”  and “RAs are necessary to trigger DHCPv6” are two different things in concept. We just want to emphasize the latter one. Maybe it is a little redundant in wording, but at least it is not harmful? Especially considering that in real practice, admins could enable routing configuration in DHCPv6 by private/customized extension (ISC dhcpd & dibbler both provide the capability) . I think maybe the redundancy wording could be useful for the situations.

Best Regards,
Bing

  *   If there is no RA, the addresses assigned by DHCPv6 cannot be used for anything at all.
  *   If there is an RA that specifies a default router but does not specify the on-link prefix, then all traffic, even between hosts on the same link, is routed at layer 3 by the default gateway.

3. Please do not cite [DHCPv6-ROUTE]. That document was so controversial that it was removed from the WG's charter and is no longer a WG item, so it is inappropriate to cite it in an operational guidance document.

Cheers,
Lorenzo

On Mon, Jan 6, 2014 at 4:59 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dear All,

Best regards
Bing

> From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Jan 2014 16:02:26 +0100

Le 08/01/2014 14:32, Lorenzo Colitti a écrit :
> On Wed, Jan 8, 2014 at 9:46 PM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> unreachable when there is no routing information for that
> destination (through a default router or otherwise)."
>
> Since DHCPv6 does not configure routing, if all you have is addresses
>  from DHCPv6 and no RA, then all destinations are unreachable.

Yes and no.

Yes in that DHCPv6 would not configure routing as we speak.

No, in that not only DHCPv6 configures routing these days.  It may very
well be that that routing be configured at link setup time by
RFC-unspecified means (PPP negotiation, USB if-up, more), or by use of
ICMP Redirect.  Neither of these is RA.  In this sense, it would be
sufficient for DHCP to give an address, Client not read any RA, and
still reach out.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Jan 2014 16:04:59 +0100

> - you cannot determine what prefixes are on-link/off-link

Thanks for the clarification.  The idea makes sense in a certain way in 
which only RA provides the default route, and only NS/NA provide the 
on-link determination.

In some other way one could still get a default gateway without DHCP and 
without RA, and could determine on/off link by other existing means.

Alex

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 8 Jan 2014 15:10:42 +0000

> without RA, and could determine on/off link by other existing means.

I am curious to know more about "other way" and "other existing means".

ND (including RA) is there for a reason, so, what benefits are we trying
to attain by replacing them with something else?

IMHO, we should strive to limit our protocol choices, not increase them.
This doesn't bode well for implementations.

-- 
Cheers,
Rajiv

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Jan 2014 16:44:23 +0100

Le 08/01/2014 16:10, Rajiv Asati (rajiva) a écrit :
>> In some other way one could still get a default gateway without
>> DHCP and without RA, and could determine on/off link by other
>> existing means.
>

In that special case I meant ppp.  When one sets up a ppp connection
often the default route may come from something else than RA/DHCP.

I also meant ICMP Redirect, whose cases are also implemented.

I also meant Transition methods: when one sets up a 6to4 tunnel the
default route is to that tunnel, it doesnt need RA.

There are many of those special cases out there.  They dont need neither
DHCP nor RA.

> ND (including RA) is there for a reason, so, what benefits are we
> trying to attain by replacing them with something else?

I will not suggest here and now to replace RA with DHCP.

I just mean that already RA's role is already substituted by something
else in many settings.

> IMHO, we should strive to limit our protocol choices, not increase
> them. This doesn't bode well for implementations.

In a sense yes, it's good to have just one standard.

In another sense the more standards are out there the more useful SDN is.

Alex

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 8 Jan 2014 16:05:02 +0000

Hi Alex,

Pls see inline,

> often the default route may come from something else than RA/DHCP.

I presume that you didn't mean the default route coming from PPP (IPv6CP
to be specific). RFC5072 has no provision for that.

FWIW, RA must not have to carry default route (by encoding as 0.0.0.0/0 in
RIO) per RFC4191. RA itself can be good enough to provide the default
router. 

> I also meant ICMP Redirect, whose cases are also implemented.

Is that related to default routing?

> default route is to that tunnel, it doesnt need RA.

Agreed.

-- 
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Jan 2014 17:30:04 +0100

> to be specific). RFC5072 has no provision for that.

Right.  No, I was wrong.  IPv6 PPP on somme cellular entities is default 
route with RA.

How about the other non-cellular PPPs putting up an interface first IPv4 
and second IPv6?

How about cellular PPP on 2G systems (or even 1G 9600kbit) which uses 
IPv4 tunnelling to realize IPv6?

> Is that related to default routing?

No, not to default routing.  But to reach out.

ICMP Redirect gives a specific route to a specific destination.  It does 
not give a default route because a dst address in a packet can not be ::/0.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 8 Jan 2014 17:34:21 +0100 (CET)

> How about the other non-cellular PPPs putting up an interface first IPv4 

There is no real PPP in cellular system, it's just between the mobile 
device and the host system for historic reasons (it's emulated). When 
you're actually in the air, there is no PPP.

> How about cellular PPP on 2G systems (or even 1G 9600kbit) which uses IPv4 
> tunnelling to realize IPv6?

2G supports IPv6 just exactly the same way as 3G and 4G. There is no 3GPP 
standard for IPv6oIPv4 tunneling.

In PPP you only negotiate Link local addresses, the rest is done through 
RA and DHCPv6 afaik.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Jan 2014 17:38:00 +0100

Le 08/01/2014 17:34, Mikael Abrahamsson a écrit :
>> How about the other non-cellular PPPs putting up an interface first
>> IPv4 and second IPv6?
>

Right, our old discussion.  I agree with you.

> 2G supports IPv6 just exactly the same way as 3G and 4G. There is no
> 3GPP standard for IPv6oIPv4 tunneling.

Well, have you tried IPv6 on a 1G system?  I did and there is no RA, yet 
I set the default route to the tunnel I put in place.

> In PPP you only negotiate Link local addresses, the rest is done through

YEs, with the IPv6 version of PPP when the other end of the PPP 
connection is an IPv6-enabled entity.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jan 2014 12:10:41 -0500

> 3. Please do not cite [DHCPv6-ROUTE]. That document was so controversial that it was removed from the WG's charter and is no longer a WG item, so it is inappropriate to cite it in an operational gu…

I don't think this is a reasonable request.   Yes, the document was controversial.   But also, it indisputably does solve the stated problem.   I am deeply uncomfortable with the "process" that resulted in this document being killed.   I asked the MIF working group to drop it from their charter because it was preventing useful work from being done in MIF and didn't really make sense as a MIF working group item.

The fact that it was removed from the MIF charter should not be taken as any kind of agreement that the question of whether to publish the document *somewhere* in the IETF has been conclusively resolved.   I don't see any strong need to revive it, but that is not the same thing as saying that we have consensus that it's a bad idea.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jan 2014 12:11:41 -0500

> those I have not seen yet, at least no in a language I can understand.

Exactly right.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 8 Jan 2014 18:16:21 +0100 (CET)

> I set the default route to the tunnel I put in place.

What do you mean by 1G? No, I haven't used 1G systems, as GSM is 2G and 
this was launched in 1991 or so. We don't have any active 1G systems left 
in my country, they were turned off long ago. I am not aware that they had 
data capability anyway.

---

From: Karsten Thomann <[email-masked]>
Date: Wed, 08 Jan 2014 20:07:24 +0100

Am Mittwoch, 8. Januar 2014, 12:10:41 schrieb Ted Lemon:
> I don't think this is a reasonable request.   Yes, the document was
> controversial.   But also, it indisputably does solve the stated problem.  
> I am deeply uncomfortable with the "process" that resulted in this document
> being killed.   I asked the MIF working group to drop it from their charter
> because it was preventing useful work from being done in MIF and didn't
> really make sense as a MIF working group item.
> 
> The fact that it was removed from the MIF charter should not be taken as any
> kind of agreement that the question of whether to publish the document
> *somewhere* in the IETF has been conclusively resolved.   I don't see any
> strong need to revive it, but that is not the same thing as saying that we
> have consensus that it's a bad idea.

I support Lorenzo, it should only contain information which is really standardized today, or at least 
something which is expected to be standardized in the next months...

It should changed to something which simply clarifies that DHCPv6 without any RAs are not 
working as there is no on-link and gateway information available to the hosts, without any further 
sentence about DHCPv6-Route.

Also I would like to add the information from Lorenzo about DHCPv6 with RAs without on-link 
prefix information to document the expected behaviour.

In my opinion it should document the behaviour which can be expected with different 
configurations. 

Best regards
Karsten

---

From: Owen DeLong <[email-masked]>
Date: Wed, 8 Jan 2014 11:03:55 -0800

> FWIW, RA must not have to carry default route (by encoding as 0.0.0.0/0 in

Why would an RA attempt to encode an IPv4 address in an RIO?

Did you mean ::ffff:0:0/96 or did you mean ::/0?

---

From: Owen DeLong <[email-masked]>
Date: Wed, 8 Jan 2014 11:17:09 -0800

This probably goes without saying, but for the record: +1

Owen

On Jan 8, 2014, at 11:07 , Karsten Thomann <[email-masked]> wrote:

> I support Lorenzo, it should only contain information which is really standardized today, or at least something which is expected to be standardized in the next months...
>  
> It should changed to something which simply clarifies that DHCPv6 without any RAs are not working as there is no on-link and gateway information available to the hosts, without any further sentence about DHCPv6-Route.
>  
> Also I would like to add the information from Lorenzo about DHCPv6 with RAs without on-link prefix information to document the expected behaviour.
>  
> In my opinion it should document the behaviour which can be expected with different configurations. 
>  
> Best regards
> Karsten

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 8 Jan 2014 19:40:42 +0000

Sorry, I did mean ::0. :=)

-----Original Message-----
From: Owen DeLong <[email-masked]>
Date: Wednesday, January 8, 2014 2:03 PM
To: Rajiv Asati <[email-masked]>
Cc: Alexandru Petrescu <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE:
new draft: draft-liu-v6ops-dhcpv6-slaac-guidance

---

From: [email-masked]
Date: Wed, 08 Jan 2014 21:29:45 +0100 (CET)

> which only RA provides the default route, and only NS/NA provide the 

You probably mean "only the Prefix Information Option in RA provides
the on-link determination".

If I read the on-link determination part of RFC 4861, together with
RFC 5942, I could easily be left with the impression that a static
IPv6 route with global next hop pointing to a statically defined
default gateway is not *meant* to work without RA. Fortunately, it
works in the operating systes where I've tried it.

(And there are routers where the ND/NS functionality is separated
from the RA functionality such that ND/NS works by default as soon
as an IPv6 interface is configured, while RA needs to be explicitly
turned on. To me, this is a good thing.)

> without RA, and could determine on/off link by other existing means.

Yes, for instance static configuration.

Steinar Haug, AS2116

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 09:33:46 +0900

> controversial.   But also, it indisputably does solve the stated problem.

So would HTTP requests to a well-known link-local address, or sniffing
VRRPv3 requests. But those aren't IETF standards either.

>   I am deeply uncomfortable with the "process" that resulted in this
> document being killed.   I asked the MIF working group to drop it from
> their charter because it was preventing useful work from being done in MIF
> and didn't really make sense as a MIF working group item.
>

And I am deeply uncomfortable with the "process" that resulted in a
solution document that had failed to reach consensus for adoption in two
arguably more appropriate WGs (dhc and 6man) being made a charter item for
a new WG, and then that WG claiming that it had to be published "because it
was a charter item". But let's not talk about here.

> The fact that it was removed from the MIF charter should not be taken as
> any kind of agreement that the question of whether to publish the document

But the fact that it was removed from the MIF charter recently is a clear
signal that it is not an IETF standard, and that it is controversial, and
thus, given that the IETF processes are based on rough consensus, that it
is likely not to become a standard in the near future. Hence, recommending
its use in an operational guidance document is inappropriate. An
operational guidance document should not cite or recommend solutions that
are not standards.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 10:01:34 +0900

On Wed, Jan 8, 2014 at 10:39 PM, Liubing (Leo) <[email-masked]>wrote:

> [Bing] I agree with you that “DHCPv6-only without RA” should not be
> identified as a valid use case. But in the document, what we want to
> caution the reader is that some operating systems would rely RAs to trigger
> DHCPv6. I think “RAs are necessary for IPv6 configuration”  and “RAs are
> necessary to trigger DHCPv6” are two different things in concept. We just
> want to emphasize the latter one. Maybe it is a little redundant in
> wording, but at least it is not harmful? Especially considering that in
> real practice, admins could enable routing configuration in DHCPv6 by
> private/customized extension (ISC dhcpd & dibbler both provide the
> capability) . I think maybe the redundancy wording could be useful for the
> situations.
>

Ok, so if that's what you want to say, how about replacing section 3.2 with
something like this:

===

3.2. Guidance for DHCPv6-only Deployment

Some networks prefer central management of all IP addressing. These
networks may want to assign addresses only via DHCPv6.

This can be accomplished by sending an RA that indicates that DHCPv6
address assignment is available (i.e., M=1), installing DHCPv6 servers or
DHCPv6 relays on all links, and setting A=0 in the Prefix Information
Options of all prefixes in the RA.

Note that an RA is still necessary in order for hosts to be able to use
these addresses. This is for two reasons:

   1. Per problem #1, if there is no RA, some hosts will not attempt to
   obtain address configuration via DHCPv6 at all.
   2. If there is no RA, or if the RA does not include a Prefix Information
   Option covering the addresses assigned via DHCPv6, then those addresses
   cannot be used for any communication, even on-link communication. This is
   because DHCPv6 does not provide a way to configure routing, and unless
   routing is configured by some other means, hosts will consider all
   destinations to be unreachable [RFC4943]. Thus, using DHCPv6 without an RA
   does not currently provide any functionality.

Also note that unlike SLAAC, DHCPv6 is not a strict requirement for IPv6
hosts [RFC6434], and some nodes do not support DHCPv6. Thus, this model can
only be used if all the hosts that need IPv6 connectivity support DHCPv6.

Per problem #2, if the administrators want to switch the DHCPv6-only
configured hosts to SLAAC-only, this is not possible on some hosts without
manually changing the hosts' configuration or using additional management
tools.

Per problem #4, for some platforms, the A flag and O flag might not be
independent, when SLAAC is off, a stand-alone stateless DHCPv6 session
would not be applicable. However, this might not be a common use case.

===

(Note: I don't understand what you meant by the last paragraph about
problem #4, so I just repeated it as is in the suggestion above. But it
should be clarified)

Cheers,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 10:02:39 +0900

On Thu, Jan 9, 2014 at 4:07 AM, Karsten Thomann
<[email-masked]>wrote:

>  I support Lorenzo, it should only contain information which is really
> standardized today, or at least something which is expected to be
> standardized in the next months...
>
>
>
> It should changed to something which simply clarifies that DHCPv6 without
> any RAs are not working as there is no on-link and gateway information
> available to the hosts, without any further sentence about DHCPv6-Route.
>
>
>
> Also I would like to add the information from Lorenzo about DHCPv6 with
> RAs without on-link prefix information to document the expected behaviour.
>
>
>

Does the text I just suggested work for you?

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 9 Jan 2014 03:51:04 +0000

Hi Lorenzo,

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, January 09, 2014 9:02 AM
To: Liubing (Leo)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] DHCPv6/SLAAC Interaction Operational Guidance-//RE: new draft: draft-liu-v6ops-dhcpv6-slaac-guidance

On Wed, Jan 8, 2014 at 10:39 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
Can you remove it, then? As an operational group we don't want to provide guidance on invalid use cases. :-)
[Bing] I agree with you that “DHCPv6-only without RA” should not be identified as a valid use case. But in the document, what we want to caution the reader is that some operating systems would rely RAs to trigger DHCPv6. I think “RAs are necessary for IPv6 configuration”  and “RAs are necessary to trigger DHCPv6” are two different things in concept. We just want to emphasize the latter one. Maybe it is a little redundant in wording, but at least it is not harmful? Especially considering that in real practice, admins could enable routing configuration in DHCPv6 by private/customized extension (ISC dhcpd & dibbler both provide the capability) . I think maybe the redundancy wording could be useful for the situations.

Ok, so if that's what you want to say, how about replacing section 3.2 with something like this:

===

Some networks prefer central management of all IP addressing. These networks may want to assign addresses only via DHCPv6.

This can be accomplished by sending an RA that indicates that DHCPv6 address assignment is available (i.e., M=1), installing DHCPv6 servers or DHCPv6 relays on all links, and setting A=0 in the Prefix Information Options of all prefixes in the RA.

Note that an RA is still necessary in order for hosts to be able to use these addresses. This is for two reasons:

  1.  Per problem #1, if there is no RA, some hosts will not attempt to obtain address configuration via DHCPv6 at all.
  2.  If there is no RA, or if the RA does not include a Prefix Information Option covering the addresses assigned via DHCPv6, then those addresses cannot be used for any communication, even on-link communication. This is because DHCPv6 does not provide a way to configure routing, and unless routing is configured by some other means, hosts will consider all destinations to be unreachable [RFC4943]. Thus, using DHCPv6 without an RA does not currently provide any functionality.
[Bing] I think this is a good way to clarify the problem. Thanks much for contributing the texts, we’ll consider to incorporate them into the next version.
Also note that unlike SLAAC, DHCPv6 is not a strict requirement for IPv6 hosts [RFC6434], and some nodes do not support DHCPv6. Thus, this model can only be used if all the hosts that need IPv6 connectivity support DHCPv6.

Per problem #2, if the administrators want to switch the DHCPv6-only configured hosts to SLAAC-only, this is not possible on some hosts without manually changing the hosts' configuration or using additional management tools.

Per problem #4, for some platforms, the A flag and O flag might not be independent, when SLAAC is off, a stand-alone stateless DHCPv6 session would not be applicable. However, this might not be a common use case.

===

(Note: I don't understand what you meant by the last paragraph about problem #4, so I just repeated it as is in the suggestion above. But it should be clarified)
[Bing] Problem #4 indicates some implicit relationship between the flags. For example, when A=0, M=0, O=1, some operating systems would start a stand-alone stateless DHCPv6 session, but some just would not. For those who would not, it is just an implication that when A is off, the stand-alone stateless DHCPv6 is also off. This is the problem #4 “Dependencies between flags”.
We need to make it clearer in the next version.

Best Regards,
Bing

Cheers,
Lorenzo

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 07:05:38 +0100 (CET)

>   cannot be used for any communication, even on-link communication. This is

The above text doesn't make sense to me. It's perfectly legal to have an 
RA without on-link prefix, meaning host has only a default-route, and then 
give this host a /128 via DHCPv6 IA_NA. The host routing table will then 
see its own /128 and a default-route. Perfectly usable deployment 
scenario.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 15:17:02 +0900

On Thu, Jan 9, 2014 at 3:05 PM, Mikael Abrahamsson <[email-masked]> wrote:
> see its own /128 and a default-route. Perfectly usable deployment scenario.

You're right, that text is incorrect. How about:

"2. Addresses assigned by DHCPv6 can only reach destinations specified by a
received Router Advertisement (either via default route, a Prefix
Information Option with O=1, or a Route Information Option). If there is no
RA, or the RA does not specify any routes, then those addresses cannot be
used ..."

---

From: [email-masked]
Date: Thu, 09 Jan 2014 07:44:11 +0100 (CET)

> RA, or the RA does not specify any routes, then those addresses cannot be

Which I read as an address assigned by DHCPv6 cannot use a statically
configured default route. Are you sure this is what you intend to say?

Steinar Haug, AS2116

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 15:54:16 +0900

> configured default route. Are you sure this is what you intend to say?

Oh, it can. I didn't mention manual configuration because I think it's a
bad idea to do so in an operational guidance document. It will work, but it
doesn't seem like something to recommend. I mean - what if you renumber the
link, or you change the router IP, or...?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 08:01:52 +0100 (CET)

> RA, or the RA does not specify any routes, then those addresses cannot be

or something like this:

2. DHCPv6 can assign addresses but not routing. Routing can be implemented 
on hosts by means of accepting and implementing information from RA 
messages containing default-route, Prefix Information Option with O=1, or 
Route Information Option, or by configuring manual routing. Without 
routing, IPv6 addresses won't be used for commmunication outside the host.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 16:12:52 +0900

> routing, IPv6 addresses won't be used for commmunication outside the host.

That's better, but people might not grasp the implication that if you
assign addresses using DHCPv6, and have no RA and no static routing, you
can't even use the addresses to communicate on-link. You do say "outside
the host", but I think people might miss that.

Consider: people used to DHCPv4 might naturally think that you can use
DHCPv6 to assign address 2001:db8::1/64, and that this will allow on-link
communication even in the absence of a default route, PIO, or RIO. But in
DHCPv6 you can't do that, you can only assign address 2001:db8::1/128, and
that can't talk to *anything at all* without routing. Technically, even in
DHCPv4 you can assign addresses without a subnet mask, but since that's not
very useful, people don't tend to do it. :-)

What about adding the following? "Thus, for example, if there is no RA and
no static routing, then addresses assigned by DHCPv6 cannot be used even
for communication between hosts on the same link."

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 08:16:31 +0100 (CET)

On Thu, 9 Jan 2014, Lorenzo Colitti wrote:

> What about adding the following? "Thus, for example, if there is no RA 
> and no static routing, then addresses assigned by DHCPv6 cannot be used 
> even for communication between hosts on the same link."

Fine by me!

---

From: [email-masked]
Date: Thu, 09 Jan 2014 08:19:11 +0100 (CET)

> > even for communication between hosts on the same link."

Agree, this sounds good.

Steinar Haug, AS2116

---

From: Tore Anderson <[email-masked]>
Date: Thu, 09 Jan 2014 09:10:31 +0100

* Mikael Abrahamsson

> Prefix Information Option with O=1

This should be L=1 (cf. RFC 4861 section 4.6.2).

The O flag means something completely different, and is in any case not
part of the Prefix Information (definition in RFC 4861 section 4.2).

Other than that I agree with your text. Perhaps the "containing
default-route" could be elaborated on a little bit, though. It might not
be obvious to everyone that an RA doesn't "contain" a default route
option in the same way it does Prefix/Route Information Option.

For example: «Routing can be implemented on hosts by means of accepting
and implementing information from RA messages containing default-route
(i.e., RAs whose Router Lifetime field is nonzero), [...]»

Tore

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 09:25:25 +0100

> I would expect the operational working group to come up with the problem statement / use cases.

Maybe someone get together and draft text?

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 18:32:04 +0900

> part of the Prefix Information (definition in RFC 4861 section 4.2).

Yep, my mistake. I thought "onlink" and wrote "O". But as you point out, O
= "Other config", and "L" = "onLink".

> (i.e., RAs whose Router Lifetime field is nonzero), [...]»

"Hosts can acquire routing information by accepting RA messages with a
nonzero Default Lifetime, Prefix Information Options with O=1, or Route
Information Options"?

---

From: Tore Anderson <[email-masked]>
Date: Thu, 09 Jan 2014 10:37:42 +0100

* Lorenzo Colitti

> nonzero Default Lifetime, Prefix Information Options with O=1, or Route

s/Default Lifetime/Router Lifetime/ (at least I don't think the term
«Default Lifetime» is defined anywhere; RFC4861 uses «Router Lifetime»).

Other than that, +1

Tore

---

From: Tore Anderson <[email-masked]>
Date: Thu, 09 Jan 2014 10:45:42 +0100

* Tore Anderson

> «Default Lifetime» is defined anywhere; RFC4861 uses «Router Lifetime»).

Scratch that, as I still insist on s/O=1/L=1/ :-D (and after that, +1)

Tore

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 18:50:18 +0900

> Scratch that, as I still insist on s/O=1/L=1/ :-D (and after that, +1)

Send the final text? :)

---

From: Tore Anderson <[email-masked]>
Date: Thu, 09 Jan 2014 10:52:45 +0100

* Lorenzo Colitti

> Send the final text? :)

Certainly:

«Hosts can acquire routing information by accepting RA messages with a
nonzero Router Lifetime, Prefix Information Options with L=1, or Route
Information Options»

Tore

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 14:11:00 +0100

Le 08/01/2014 18:16, Mikael Abrahamsson a écrit :
>> Well, have you tried IPv6 on a 1G system?  I did and there is no
>> RA, yet I set the default route to the tunnel I put in place.
>
> What do you mean by 1G? No, I haven't used 1G systems, as GSM is 2G
> and this was launched in 1991 or so. We don't have any active 1G
> systems left in my country, they were turned off long ago. I am not
> aware that they had data capability anyway.

Sorry, you are right.

Yes, 1G analog is prior to 2G digital GSM.

But, in some more detail, some mode of operation of 2G phones dates back
to being used in 1G system.  For example, the 'CSD' way of opening a
connection amounts to having a data connection of a pure circuit switch.
(prior to running IP on it).

The CSD mode of connection of earliest GSM phones have ppp setup times
in the order of minutes, as opposed to tens of seconds of GPRS.  It's
same mechanism as a modem of a 2400baud land copper phone line, if you
see what I mean.

Second, the earliest phones deployed in commercial aircraft carrying
passengers have exclusively analog connections to the Earth (not GSM).
That too support a speed of around 2400 to 9600baud.

I'd call these two examples of '1G'. I may be wrong though, because
nobody else talks '1G'.

And one can run IPv6 on these '1G', by using IPv6 in IPv4 tunnels, and
without RA.

This is just to clarify what I meant, and to ack your correction.

Alex
PS: about 1G left in your country, I would double check...  And I
suppose if they exist they do support data connections with a simple modem.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 14:21:33 +0100 (CET)

> suppose if they exist they do support data connections with a simple modem.

The only 1G network in Sweden that I am aware of is 
<https://en.wikipedia.org/wiki/Nordic_Mobile_Telephone>, and it was shut 
down 2007 according to that article.

For me 1G is out of scope as there is extremly little use, and the only 
volume of usage is on GSM, UMTS and LTE. All these support "native" IPv6 
just fine.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 15:01:14 +0100

>>> even for communication between hosts on the same link."

It sounds reasonable, but not as close as it could get.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 15:20:12 +0100

Le 09/01/2014 14:21, Mikael Abrahamsson a écrit :
>> Alex PS: about 1G left in your country, I would double check...
>> And I suppose if they exist they do support data connections with a
>> simple modem.
>
> <https://en.wikipedia.org/wiki/Nordic_Mobile_Telephone>, and it was
> shut down 2007 according to that article.

Well, thank you for the info, that is good to know.

I guess though older links are still in use there.

> For me 1G is out of scope as there is extremly little use, and the
> only volume of usage is on GSM, UMTS and LTE. All these support
> "native" IPv6 just fine.

YEs.

New IoT operators may run on IPv6 on CSD lines of GSM (w/o native IPv6
on the other side).  Or may not.

Alex

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 09 Jan 2014 16:01:40 +0000

> for communication between hosts on the same link."

Lorenzo,

Can you provide a reference for the assumption that the host will define
the netmask to be /128 if it receives an address assignment from DHCPv6
without a specific subnet mask assignment via RA?

Nick

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Jan 2014 19:44:38 +0100 (CET)

> without a specific subnet mask assignment via RA?

what else would it do?

I get zero hits on the word "netmask" in RFC3315. DHCPv6 will hand out 
addresses, which in IPv6 implicitly is a /128?

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 09 Jan 2014 19:11:04 +0000

> addresses, which in IPv6 implicitly is a /128?

It's context / configuration dependent.  If the interface already has an
address+netmask configured which contains the address received from DHCP,
then local connectivity will work just fine.

This necessarily will lead to either mealy-mouthed expressions like "may
work, or may not", or else further qualification of when and how it may or
may not work, maybe, depending on what the implementer did.

I'd suggest it might be better not to have the phrase at all.

Nick

---

From: Tore Anderson <[email-masked]>
Date: Thu, 09 Jan 2014 20:36:31 +0100

* Nick Hilliard

> without a specific subnet mask assignment via RA?

http://tools.ietf.org/search/rfc5942#section-5

Tore

---

From: Gert Doering <[email-masked]>
Date: Thu, 9 Jan 2014 22:35:08 +0100

Hi,

> then local connectivity will work just fine.

"If I add routing using some other way it does not matter that DHCPv6
will not add it".  True.  And, how exactly is this relevant to the 
fact that DHCPv6 *alone* will not get you anywhere today?

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: Fri, 10 Jan 2014 12:17:57 +0900

> then local connectivity will work just fine.

Correct, but that's already covered in the proposed text, which is as
follows. The text basically says "to use addresses to talk to anything
that's not yourself, you need routing; you can't get configure via DHCPv6;
you can configure routing by doing X, Y, and Z)". X, Y and Z does not
include manual configuration, because people seemed to feel that manual
configuration is not recommended and thus should not be included in an
operational guidance document, but we could certainly add it if there's
consensus to do so.

====

1. Per problem #1, if there is no RA, some hosts will not attempt to obtain
address configuration via DHCPv6.

2. DHCPv6 can assign addresses but not routing. Hosts can acquire routing
information by accepting RA messages with a nonzero Router Lifetime, Prefix
Information Options with L=1, or Route Information Options. Without
routing, IPv6 addresses won't be used for commmunication outside the host.
Thus, for example, if there is no RA and no static routing, then addresses
assigned by DHCPv6 cannot be used even for communication between hosts on
the same link.

====

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Jan 2014 12:18:52 +0900

On Fri, Jan 10, 2014 at 12:17 PM, Lorenzo Colitti <[email-masked]>wrote:

> you can't get configure via DHCPv6
>

Er, that should be "you can't configure routing via DHCPv6".

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 10:27:36 +0100

Le 09/01/2014 19:44, Mikael Abrahamsson a écrit :
>> Can you provide a reference for the assumption that the host will
>> define the netmask to be /128 if it receives an address assignment
>>  from DHCPv6 without a specific subnet mask assignment via RA?
>
> what else would it do?
>
> I get zero hits on the word "netmask" in RFC3315. DHCPv6 will hand
> out addresses, which in IPv6 implicitly is a /128?

Right, good assumption...  but please allow me another interpretation.

It's interesting to note that that RFC3315 does define the term 'prefix
length' although it does not employ it.  This as such may make wonder
why is that term there, and what are the implications to the ongoing
editing of that document.

'Prefix length' is IPv6 language for 'subnet mask' or 'netmask'.

Moreover, if one searches for 'prefix' in that RFC, one may find
occurences which may be hard to implement, RFC3315:
> Each IA_TA option contains at most one temporary address for each of
> the prefixes on the link to which the client is attached.

Would Server know each of the prefixes on the link on which the client 
is attached?  I suppose yes, by pre-configuration.  If it knows it, then 
why not delivering it to the client.

RFC3315:
> 18.1.2. Creation and Transmission of Confirm Messages
>
>    Whenever a client may have moved to a new link, the prefixes from the
>    addresses assigned to the interfaces on that link may no longer be
>    appropriate for the link to which the client is attached.  Examples
>    of times when a client may have moved to a new link include:
[...]
> Any responding servers will indicate whether those
>    addresses are appropriate for the link to which the client is
>    attached with the status in the Reply message it returns to the
>    client.

RFC3315:
>    If the relay agent received the message to be relayed from a client,
>    the relay agent places a global or site-scoped address with a prefix
>    assigned to the link on which the client should be assigned an
>    address in the link-address field.

RFC3315:
>    NotOnLink       4 The prefix for the address is not appropriate for
>                      the link to which the client is attached.

Each of these suggest that the Server does know the prefixes on the link 
on which the client is attached.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 10 Jan 2014 10:35:10 +0100 (CET)

> on which the client is attached.

I thought this was included by the DHCPv6 forwarding agent? So yes, it 
does.

However, if you change the address of the default gateway then you need to 
reconfigure the DHCPv6 server. With RAs, you don't need to do that, this 
is now purely router configuration.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 10:58:22 +0100

> http://tools.ietf.org/search/rfc5942#section-5

That to me reads that some wrong implementations wrongly assume the 
prefix length of a link when RA doesnt tell it.

And the solution to that to be to put the prefix length in the RA and 
use it.

I agree with the first part and partially with the second part.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 11:06:21 +0100

Le 10/01/2014 10:35, Mikael Abrahamsson a écrit :
>> Each of these suggest that the Server does know the prefixes on
>> the link on which the client is attached.
>
> I thought this was included by the DHCPv6 forwarding agent?

One of them yes (the last cited paragraph).  But the other paragraphs no.

For example it is the Server which assigns the address (not the Relay)
and it is the server which must decide whether or not the temporary, or
the already existing, are relevant within a subnet ('prefix length') or not.

It can only do that if it compares the prefix length of the address with
a prefix length pre-stored in a configuration file.

> So yes, it does.
>
> However, if you change the address of the default gateway then you
> need to reconfigure the DHCPv6 server. With RAs, you don't need to
> do that, this is now purely router configuration.

I agree with this point.  If one changes the Router, or its interface,
one is forced to update the conf file of the DHCP server.  Compared to
RA mechanism this change necessity is an inconvenient (RA allows to
change routers and a bit automatically get that new IP address to the
client).

Alex

---

From: t.petch <[email-masked]>
Date: Fri, 10 Jan 2014 15:22:20 +0000

Lorenzo

At some point, when this text has stabilized, I think that you must
change the word 'routing'.  I appreciate that this word is being used
extensively in these threads and we all know that it does not mean
routing; but for the world at large, this will be just another source of
confusion around IPv6.

Partly it is that in many if not most I-D, routing is distinguished from
forwarding and it is forwarding that is being discussed here.

More importantly, both routing and forwarding are functions of routers.
If you have no routing, then you have no routers and no network and we
can end this discussion!  Rather it is the inability of DHCP to provide
a forwarding (routing:-( table entry, or a default route or a route for
any other prefix,  that is being discussed.

Tom Petch

----- Original Message -----
From: "Lorenzo Colitti" <[email-masked]>
To: "Nick Hilliard" <[email-masked]>
Cc: <[email-masked]>;
<[email-masked]>
Sent: Friday, January 10, 2014 3:17 AM

> > > I get zero hits on the word "netmask" in RFC3315. DHCPv6 will hand
out
> 1. Per problem #1, if there is no RA, some hosts will not attempt to
obtain
> would not be applicable. However, this might not be a common use case.

------------------------------------------------------------------------
--------