Subject: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem

From: <[email-masked]>
Date: Wed, 4 Dec 2013 05:45:01 -0800 (PST)

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 Dec 2013 10:34:46 -0600

Hi authors,

I think this draft is requirements draft while
draft-yourtchenko-ra-dhcpv6-comparison-00.txt
is problem statement draft for the same issue.

My suggestion is requirements on delivering routes to the hosts also should
be added to this draft.

Regards,

Behcet

On Wed, Dec 4, 2013 at 7:45 AM, <[email-masked]> wrote:

>
> A new draft has been posted, at
> http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. Please
> take a look at it and comment.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 10 Dec 2013 07:13:23 +0000

Hi Behcet,

Thanks for your comment. Please see replies inline.

From: v6ops [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Tuesday, December 10, 2013 12:35 AM
To: Fred Baker
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem

Hi authors,
I think this draft is requirements draft while draft-yourtchenko-ra-dhcpv6-comparison-00.txt is problem statement draft for the same issue.
[Bing] I think draft-yourtchenko-ra-dhcpv6-comparison is sort of guidance for the people who want to select between RA and DHCPv6 for designing mechanisms, or operating the networks. Different scenarios might have different considerations as analyzed in the draft.
But draft-ietf-v6ops-dhcpv6-slaac-problem reports currently existing issues (mostly regarding with address configuration) that caused by either bad implementation or ambiguous standard definition. It should be a problem statement to warn people there might be issues if both SLAAC and DHCPv6 are available in one network, and also could be a trigger to revise current ambiguous definition in relevant standard (mostly regarding with RFC4861/RFC4862).
My suggestion is requirements on delivering routes to the hosts also should be added to this draft.
[Bing] I'm not sure, because there hasn't been DHCP-based routes delivering mechanism, so there hasn't been interaction problems so far. Maybe we could consider this issue in the future.
Best regards,
Bing
Regards,
Behcet

On Wed, Dec 4, 2013 at 7:45 AM, <[email-masked]<mailto:[email-masked]>> wrote:

A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem. Please take a look at it and comment.
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Dec 2013 14:03:03 -0600

Hi Bing,

 My suggestion is requirements on delivering routes to the hosts also
> should be added to this draft.
>
> [Bing] I’m not sure, because there hasn’t been DHCP-based routes
> delivering mechanism, so there hasn’t been interaction problems so far.
>

Yes, it did, it happened in mif WG, maybe that's why you are not familiar.
You can check mif mailing list archive and minutes, please check IETF 83
minutes here:

http://tools.ietf.org/wg/mif/minutes?item=minutes-83-mif.html

Regards,

Behcet

> Maybe we could consider this issue in the future.
>
> Best regards,
>
> Bing
>
> Regards,
>
> Behcet
>
>
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 11 Dec 2013 02:11:30 +0000

Hi Behcet

From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Wednesday, December 11, 2013 4:03 AM
To: Liubing (Leo)
Cc: [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem

Hi Bing,

My suggestion is requirements on delivering routes to the hosts also should be added to this draft.
[Bing] I'm not sure, because there hasn't been DHCP-based routes delivering mechanism, so there hasn't been interaction problems so far.

Yes, it did, it happened in mif WG, maybe that's why you are not familiar.
[Bing] Yes, I noticed your mentioning about the draft-ietf-mif-dhcpv6-route-option-05 in a previous mail to Andrew Yourtchenko.
I do agree this point is regarding with RA/DHCP comparison/overlapping. But for draft-ietf-v6ops-dhcpv6-slaac-problem, I have two considerations:

1.      I guess there hasn't been implementation for the DHCP-based routes mechanism yet? So it's hard to say whether there would be problems.

2.      It might not be really essential to the draft. The DHCPv6 routes option could be considered as one instance of "Otherconfig" as hinted by the O flag in RA. The draft focuses on whether the hosts would do "Otherconf" or not when they interpreting the O flag in various conditions. For what the "otherconfig" might be, DNS or routes, it should not be the scope of the draft as I understand.

You can check mif mailing list archive and minutes, please check IETF 83 minutes here:

http://tools.ietf.org/wg/mif/minutes?item=minutes-83-mif.html
[Bing] I was a really long discussion :)  But interesting and valuable, thanks for sharing.
Best regards,
Bing

Regards,
Behcet

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 16 Dec 2013 16:55:00 +0900

A few comments:

1. The draft should note that per RFC 6434 (IPv6 node requirements), hosts
MUST support SLAAC, but are not required to support DHCPv6, since it's a
SHOULD (and note that until relatively recently - December 2011 - it was a
MAY). So while a network administrator can reasonably assume that SLAAC
will be supported by hosts, he cannot assume that DHCPv6 will be supported.

2. The statement in Section 2.1.1 that "when A flag is set, the SLAAC
protocol didn't provide a prescriptive definition" is incorrect.

RFC 4862 says that if A=0 the host should "silently ignore the Prefix
Information option", and if A=1 "form an address" (bullet point d) or "the
preferred lifetime of the address is reset [...]" (bullet point e). Both
rules MUST be enabled by default, as clearly stated in RFC 4862 section 5.5.

3. In section 3.3 it's not clear why "the administrator wants the hosts to
do DHCPv6-only configuration". All hosts that support DHCPv6 will do
DHCPv6-only if A=0 and M=1. Hosts that don't support DHCPv6... won't be
able to do DHCPv6-only regardless of what the administrator wants them to
do.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 17 Dec 2013 03:03:36 +0000

Hi Lorenzo,

Thanks for the comments. Please see inline.

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, December 16, 2013 3:55 PM
To: [email-masked]
Cc: [email-masked] WG
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem

A few comments:

1. The draft should note that per RFC 6434 (IPv6 node requirements), hosts MUST support SLAAC, but are not required to support DHCPv6, since it's a SHOULD (and note that until relatively recently - December 2011 - it was a MAY). So while a network administrator can reasonably assume that SLAAC will be supported by hosts, he cannot assume that DHCPv6 will be supported.
[Bing] Good suggestion. Thank you.

2. The statement in Section 2.1.1 that "when A flag is set, the SLAAC protocol didn't provide a prescriptive definition" is incorrect.

RFC 4862 says that if A=0 the host should "silently ignore the Prefix Information option", and if A=1 "form an address" (bullet point d) or "the preferred lifetime of the address is reset [...]" (bullet point e). Both rules MUST be enabled by default, as clearly stated in RFC 4862 section 5.5.
[Bing] The texts in section 2.1.1 means there is no explicit definition of A=1. But there might be implication as you mentioned above. And the tests in our draft also identified there's no problem of A=1. I'll revise the texts accordingly to eliminate the confusion.

3. In section 3.3 it's not clear why "the administrator wants the hosts to do DHCPv6-only configuration". All hosts that support DHCPv6 will do DHCPv6-only if A=0 and M=1. Hosts that don't support DHCPv6... won't be able to do DHCPv6-only regardless of what the administrator wants them to do.
[Bing] It is true when there's RAs in the link. In section 5.5.2 of [RFC4862], it mentioned the situation of non-RAs. But non-RA only means "no router" as described in the standard, it is not clear whether the hosts should initiate DHCPv6 or not. And as we tested,  some hosts just do nothing if no RAs present.
So there's an implication that it requires RA to indicate the hosts to do DHCPv6 (unless the hosts are switched to DHCPv6-only mode manually or through some management tools, but this might involve management burden and non-standard mechanisms). And this is just one of the issues we'd like to point out in this draft.

Best Regards,
Bing

On Wed, Dec 4, 2013 at 10:45 PM, <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Dec 2013 12:11:27 +0900

On Tue, Dec 17, 2013 at 12:03 PM, Liubing (Leo) <[email-masked]>wrote:

>  3. In section 3.3 it's not clear why "the administrator wants the hosts
> to do DHCPv6-only configuration". All hosts that support DHCPv6 will do
> [Bing] It is true when there’s RAs in the link. In section 5.5.2 of
> [RFC4862], it mentioned the situation of non-RAs. But non-RA only means “no
> router” as described in the standard, it is not clear whether the hosts
> should initiate DHCPv6 or not. And as we tested,  some hosts just do
> nothing if no RAs present.
>
> So there’s an implication that it requires RA to indicate the hosts to do
> DHCPv6 (unless the hosts are switched to DHCPv6-only mode manually or
> through some management tools, but this might involve management burden and
> non-standard mechanisms). And this is just one of the issues we’d like to
> point out in this draft.
>

But why would you do this? If there's no RA, then the hosts won't be able
to communicate off-link. If all you can do is link-local communication,
then what's the point of numbering the hosts via DHCPv6 instead of just
using link-local?

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 17 Dec 2013 03:47:02 +0000

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, December 17, 2013 11:11 AM
To: Liubing (Leo)
Cc: [email-masked]; [email-masked] WG
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem

On Tue, Dec 17, 2013 at 12:03 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
3. In section 3.3 it's not clear why "the administrator wants the hosts to do DHCPv6-only configuration". All hosts that support DHCPv6 will do DHCPv6-only if A=0 and M=1. Hosts that don't support DHCPv6... won't be able to do DHCPv6-only regardless of what the administrator wants them to do.
[Bing] It is true when there’s RAs in the link. In section 5.5.2 of [RFC4862], it mentioned the situation of non-RAs. But non-RA only means “no router” as described in the standard, it is not clear whether the hosts should initiate DHCPv6 or not. And as we tested,  some hosts just do nothing if no RAs present.
So there’s an implication that it requires RA to indicate the hosts to do DHCPv6 (unless the hosts are switched to DHCPv6-only mode manually or through some management tools, but this might involve management burden and non-standard mechanisms). And this is just one of the issues we’d like to point out in this draft.

But why would you do this? If there's no RA, then the hosts won't be able to communicate off-link. If all you can do is link-local communication, then what's the point of numbering the hosts via DHCPv6 instead of just using link-local?
[Bing] With draft-ietf-mif-dhcpv6-route-option, the hosts would be able to communicate off-link without RA. I think this scenario is quite reasonable especially for the operators.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Dec 2013 12:52:09 +0900

On Tue, Dec 17, 2013 at 12:47 PM, Liubing (Leo) <[email-masked]>wrote:

>    But why would you do this? If there's no RA, then the hosts won't be
> able to communicate off-link. If all you can do is link-local
> communication, then what's the point of numbering the hosts via DHCPv6
> instead of just using link-local?
>
> [Bing] With draft-ietf-mif-dhcpv6-route-option, the hosts would be able to
> communicate off-link without RA. I think this scenario is quite reasonable
> especially for the operators.
>

But that draft did not reach consensus and is no longer an active working
group item, so it's unlikely to happen any time soon. If this use case only
makes sense if routing is configured with DHCPv6, then the use case should
be removed.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Dec 2013 23:04:59 -0500

On Dec 16, 2013, at 10:52 PM, Lorenzo Colitti <[email-masked]> wrote:
> But that draft did not reach consensus and is no longer an active working group item, so it's unlikely to happen any time soon. If this use case only makes sense if routing is configured with DHCPv6, then the use case should be removed.

I think the use case makes sense in an isolated network.   RA might be a better choice, and indeed without RA I think it probably doesn't work, but I don't see why this document shouldn't mention this use case.   The reason you've given here certainly doesn't seem convincing.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Dec 2013 13:08:34 +0900

On Tue, Dec 17, 2013 at 1:04 PM, Ted Lemon <[email-masked]> wrote:

> > But that draft did not reach consensus and is no longer an active
> working group item, so it's unlikely to happen any time soon. If this use
> case only makes sense if routing is configured with DHCPv6, then the use
> case should be removed.
>
> I think the use case makes sense in an isolated network.   RA might be a
> better choice, and indeed without RA I think it probably doesn't work, but
> I don't see why this document shouldn't mention this use case.   The reason
> you've given here certainly doesn't seem convincing.
>

If a DHCPv6-only scenario is presented, then it needs to be stated that the
nodes will not have any off-link connectivity, and thus that this scenario
is possibly of limited use.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 17 Dec 2013 07:57:28 +0000

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, December 17, 2013 12:09 PM
To: Ted Lemon
Cc: Liubing (Leo); [email-masked]; [email-masked] WG
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem

If a DHCPv6-only scenario is presented, then it needs to be stated that the nodes will not have any off-link connectivity, and thus that this scenario is possibly of limited use.
[Bing] Isolated network is indeed a valid use case, thanks Ted for mentioning this.
Regardless of specific use cases, for the behavior “RA is required for initialing DHCPv6”, I think:
1. The dependency is not quite reasonable;
2. Whether there should be dependency is ambiguous in standard, and it is why current implementations have varied on this issue (some will initiate DHCPv6 if no RA; some just do nothing).

Best Regards,
Bing

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Dec 2013 17:27:48 +0900

On Tue, Dec 17, 2013 at 4:57 PM, Liubing (Leo) <[email-masked]>wrote:

>    If a DHCPv6-only scenario is presented, then it needs to be stated
> that the nodes will not have any off-link connectivity, and thus that this
> scenario is possibly of limited use.
>

Do you really want to mention this as a use case? What's the point of
setting up a DHCPv6 server if the addresses it assigns can't talk to
anything off-link anyway?

If you do insist on mentioning it, please make it very clear that such a
use case does not permit any sort of communication outside the link (not
"outside the network" - "outside the link"), and that the you don't need to
configure a DHCPv6 server to do that - you can just use link-local
addresses, which are created automatically.

> 1. The dependency is not quite reasonable;

I don't think it's unreasonable, because an RA is needed for connectivity
anyway. Also, if there is no IPv6 off-link connectivity but there is IPv4
off-link connectivity, then it's better for hosts *not* to have an IPv6
address. This is because if they do have an IPv6 address, then they will
waste their time doing AAAA lookups for off-link destinations which they
can't reach.

>   2. Whether there should be dependency is ambiguous in standard, and it
> is why current implementations have varied on this issue (some will
> initiate DHCPv6 if no RA; some just do nothing).
>

I don't think this is a big problem, since if there is no router there's no
off-link connectivity, and a network without off-link connectivity is not
very useful.

---

From: Tore Anderson <[email-masked]>
Date: Tue, 17 Dec 2013 10:52:51 +0100

* Lorenzo Colitti

> anything off-link anyway?

It's not only off-link communication that won't work in a RA-less
network. Two nodes on the same link cannot even communicate
bidirectionally with each other using their DHCPv6-asssigned addresses.
For that to work a RA carrying a PIO with L=1 needs to be present.

Tore

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 17 Dec 2013 10:03:24 +0000

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, December 17, 2013 4:28 PM
To: Liubing (Leo)
Cc: Ted Lemon; [email-masked] WG
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem

On Tue, Dec 17, 2013 at 4:57 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
If a DHCPv6-only scenario is presented, then it needs to be stated that the nodes will not have any off-link connectivity, and thus that this scenario is possibly of limited use.
[Bing] Isolated network is indeed a valid use case, thanks Ted for mentioning this.

Do you really want to mention this as a use case?
[Bing] Yes.

What's the point of setting up a DHCPv6 server if the addresses it assigns can't talk to anything off-link anyway?
[Bing] It might be nonsense for you, but you never know who might need this use case. And for this document, it is not a goal to judge the use case valid or not, but to provide cautions that there might be problem in these or those cases.

If you do insist on mentioning it, please make it very clear that such a use case does not permit any sort of communication outside the link (not "outside the network" - "outside the link"), and that the you don't need to configure a DHCPv6 server to do that - you can just use link-local addresses, which are created automatically.

I don't think it's unreasonable, because an RA is needed for connectivity anyway.
[Bing] First, you can never totally deny the cases that there’s no RA but DHCPv6 is needed, especially in the future. Second, even assuming RA is needed for connectivity, still doesn’t mean RA SHOULD be needed for triggering DHCPv6. I think it would reduce the robust of DHCP service, e.g. what if the M flag was misconfigured.

Best Regards,
Bing

Also, if there is no IPv6 off-link connectivity but there is IPv4 off-link connectivity, then it's better for hosts *not* to have an IPv6 address. This is because if they do have an IPv6 address, then they will waste their time doing AAAA lookups for off-link destinations which they can't reach.

I don't think this is a big problem, since if there is no router there's no off-link connectivity, and a network without off-link connectivity is not very useful.

---

From: Andrew Yourtchenko <[email-masked]>
Date: Tue, 17 Dec 2013 10:16:53 +0000 (WET)

> For that to work a RA carrying a PIO with L=1 needs to be present.

Curiously, RFC 2461 had it completely the other way: section 6.3.6 
"Default Router Selection", in the every end, says if there is no default router 
assume all the destinations are on-link.

It was the RFC 4861 which has removed this paragraph.

--a

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Dec 2013 19:25:59 +0900

On Tue, Dec 17, 2013 at 7:16 PM, Andrew Yourtchenko <[email-masked]>wrote:

> "Default Router Selection", in the every end, says if there is no default
> router assume all the destinations are on-link.
>

Hmm. http://tools.ietf.org/html/rfc4943 , "IPv6 Neighbor Discovery On-Link
Assumption Considered Harmful"

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Dec 2013 19:28:59 +0900

On Tue, Dec 17, 2013 at 7:03 PM, Liubing (Leo) <[email-masked]>wrote:

> [Bing] It might be nonsense for you, but you never know who might need
> this use case. And for this document, it is not a goal to judge the use
> case valid or not, but to provide cautions that there might be problem in
> these or those cases.
>

I think Tore's comment makes it clear that those addresses won't work *at
all*, not even for on-link communication. I strongly object to listing a
use case that assigns addresses that don't work.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Dec 2013 08:36:38 +1300

>> [Bing] Isolated network is indeed a valid use case, thanks Ted for

However, the whole motivation for inventing the SLAAC and RA mechanism
was for zeroconf networks (which we often called "Dentist's Office networks"
to suggest the use case). I can't prove it with archived email, but
I'm pretty sure that somebody said "and then we certainly won't need
DHCP for IPv6".

So I can equally well argue that an isolated network is the perfect
use case for SLAAC/RA.

> anything off-link anyway?

Exactly. It is a solution searching for a problem.

   Brian

> ------------------------------------------------------------------------
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 17 Dec 2013 12:23:22 -0800 (PST)

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: Lorenzo Colitti <[email-masked]>
> Cc: "[email-masked] WG" <[email-masked]>
> Sent: Wednesday, 18 December 2013 6:36 AM

So I recently remembered reading something about IPv4 ICMP based default gateway discovery a long time ago and decided to look up more details.

IPv4 RAs are actually older than DHCPv4 as we know it by two years (the RFC editor explains why it is in IPv6)

RFC1256, "ICMP Router Discovery Messages." S. Deering, Ed.. September 1991.

RFC1531, "Dynamic Host Configuration Protocol." R. Droms. October 1993.

I also found that my Fedora 19 host had the client installed by default (rdisc), and also found that both Cisco and Juniper have implementations of the server available on their router platforms.

IPv4 RAs don't have a prefix information option so hosts had to acquire prefix/host address information some other way. If hosts were able to dynamically acquire that information, then Appletalk has demonstrated that it isn't necessary to have large host address space to be able to have hosts dynamically generate their own addresses and check them for validity.

> Exactly. It is a solution searching for a problem.

That specific scenario is my understanding of the reason for the existence of link-local addressing, and why they are candidate addresses for use by applications in the address selection RFC and instructions on how they work with/are to be used by applications are provided in RFC4007.

Ubiquitous "link-local" addressing ensures that you don't need an external source of layer 3 addressing information for the nodes to locally communicate. It also isn't a new idea, IPv4 originally had 'this network' - the network portion of the address of all zeros (which subsequently might have been reinvented as 169.254/16 for the same purpose), IPX had network 0x000000, and Appletalk had cable range 0xff00 through 0xfffe.

Regards,
Mark.

>>>    Regardless of specific use cases, for the behavior “RA is required 
> for
>>>  initialing DHCPv6”, I think:
>>>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 18 Dec 2013 02:06:01 +0000

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, December 17, 2013 6:29 PM
To: Liubing (Leo)
Cc: Ted Lemon; [email-masked] WG
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-dhcpv6-slaac-problem

On Tue, Dec 17, 2013 at 7:03 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
Do you really want to mention this as a use case?
[Bing] Yes.

I think Tore's comment makes it clear that those addresses won't work *at all*, not even for on-link communication. I strongly object to listing a use case that assigns addresses that don't work.
[Bing] My previous argument above was assuming the use case works, but someone might don’t prefer to use it. Then it is not our goal to judge the case good or not.
But if it doesn’t work at all, then I agree with you it should not be listed, or make a clear statement the case is not applicable.

Thank you.

Best regards,
Bing

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Dec 2013 08:13:25 -0500

> But if it doesn’t work at all, then I agree with you it should not be listed, or make a clear statement the case is not applicable.

Does IPv6 bonjour not work on a local wire without router advertisements?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 Dec 2013 22:43:32 +0900

On Wed, Dec 18, 2013 at 10:13 PM, Ted Lemon <[email-masked]> wrote:

> > [Bing] My previous argument above was assuming the use case works, but
> someone might don’t prefer to use it. Then it is not our goal to judge the
> case good or not.
> > But if it doesn’t work at all, then I agree with you it should not be
> listed, or make a clear statement the case is not applicable.
>

Yes, but it works with link-local addresses, so it doesn't need DHCPv6
either.

As Tore notes, per spec getting an IPv6 address via DHCPv6 is not
sufficient to talk to anyone at all, period. This is because there's no way
to guess the prefix size assigned to the link, and so no way to create a
routing table entry that allows you to send packets. Stacks used to assume
that everything is on link, but that was reversed by RFC 4943.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Dec 2013 17:46:12 +0100

Le 18/12/2013 14:43, Lorenzo Colitti a écrit :
> On Wed, Dec 18, 2013 at 10:13 PM, Ted Lemon <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> [Bing] My previous argument above was assuming the use case
> works, but someone might don’t prefer to use it. Then it is not our
> goal to judge the case good or not.
>> But if it doesn’t work at all, then I agree with you it should
> not be listed, or make a clear statement the case is not applicable.
>
> Yes, but it works with link-local addresses, so it doesn't need
> DHCPv6 either.
>
> sufficient to talk to anyone at all, period. This is because there's
> no way to guess the prefix size assigned to the link,

And that is a problem.

To solve it one may need the value of the prefix assigned on the link,

> and so no way to create a routing table entry that allows you to send
> packets.

or may need the address of a default router containing the link-layer 
address, (to avoid needing NS/NA), and then get ICMP Redirect.

> Stacks used to assume that everything is on link, but that
> was reversed by RFC 4943.

Informationally reversed, yes.

Not all stacks assume everything is on link.

Alex

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