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

From: [email-masked]
Date: Sun, 19 Oct 2014 11:00:02 -0700

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.  
Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the
list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 20 Oct 2014 11:12:58 -0700

> believe it to be of operational utility, that is also an important

I have a mixed feeling about the importance of the document.  I
personally don't think it worth publishing in its current form,
although I wouldn't be opposed to it if the wg thinks it's useful.

Vagueness and ambiguity regarding M, O, and A flags (especially the
first two) are well known, and it's not surprising that different
implementations behave differently.  Since such a divergence can cause
a critical operational issue, I see a value in documenting these.

On the other hand, the specific issues described in Section 3.2 don't
seem to be very critical to me.

In the case described in Section 3.2.1, the host would only have
link-local addresses.  Such a host wouldn't be able to do many useful
things anyway (potentially, there may be some interesting scenarios
for a completely isolated, single-link, autonomous network with only
link-local addresses, but I suspect there are many other fundamental
issues to solve for such environments before we even worry about the
M/O/A flags).

The issues described in Section 3.2 seem to be caused largely because
they switch the address configuration mechanism (SLAAC to DHCPv6 or
vice versa) in addition to renumbering.  While that could happen in
theory, it seems to be a quite artificial discussion.

Actually, I guess there should be more pragmatic examples of
operational issues because of the described divergence and I wonder
whether these minor cases are really the only things we can imagine
(although I don't have a specific idea right now).  If these sections
can be revised with more convincing examples, I would be more
supportive about publishing it.

Some specific comments (mostly editorial and nits) on the draft text:

- Section 1:

   The M, O and A
   flags are advisory, not prescriptive.

  In my understanding, the A flag is quite prescriptive.  If a host
  implementation doesn't perform SLAAC for a prefix information option
  with A flag on, that implementation would be considered
  non-compliant.  At the very least, the level of "advisory" vs
  "prescriptive" is much different between M,O and A, so listing all
  of them in this sentence seems to be misleading, if not simply
  incorrect.

- Section 2.1: s/setting/settings/

   [...]  The following setting are all allowed:

- Section 2.2: s/setting/settings/

   [...]  The following setting are all
   allowed:

--
JINMEI, Tatuya

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 21 Oct 2014 03:25:27 +0000

Hi Jinmei,

Thanks for your comments. Please see replies inline.

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of 神明達哉
> Sent: Tuesday, October 21, 2014 2:13 AM
> To: Fred Baker (fred)
> Cc: [email-masked]
> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
> 
> I have a mixed feeling about the importance of the document.  I personally
> don't think it worth publishing in its current form, although I wouldn't be
> opposed to it if the wg thinks it's useful.
> 
> Vagueness and ambiguity regarding M, O, and A flags (especially the first two)
> are well known, and it's not surprising that different implementations behave
> differently.  Since such a divergence can cause a critical operational issue, I
> see a value in documenting these.
[Bing] I believe it is well known among standard developers, participants and implementers who had paid attention on it. However, since the ambiguity problem is not so explicit in current standard, the vast administrators/operators out IETF might not quite familiar with it. I once talked with some operator people, they were quite confused about the situation when they met the problem in their IPv6 testbed networks. 
So, if there is an RFC explicitly stating the problems, I think it would be good for administrators/operators to learn the fact before they actually deploying the networks. Also, the document could be a formal reference for potential standard work in the future to clear the ambiguity in current standards.

> On the other hand, the specific issues described in Section 3.2 don't seem to
> be very critical to me.
[Bing] I agree the issues might not be critical for some people. But maybe they are important concerns in other situations. Considering we are just at the beginning stage of deploying IPv6, It might be hard for us to judge the importance, but we could document the issues, at least it is not harmful. 

> In the case described in Section 3.2.1, the host would only have link-local
> addresses. 
[Bing] Or maybe self-generated ULAs. (But of course, it is not the point of this document.)

> Such a host wouldn't be able to do many useful things anyway
> (potentially, there may be some interesting scenarios for a completely
> isolated, single-link, autonomous network with only link-local addresses, but
> I suspect there are many other fundamental issues to solve for such
> environments before we even worry about the M/O/A flags).
[Bing] I agree there would be other fundamental issues, but the O flag behavior would also exist anyway.

> The issues described in Section 3.2 seem to be caused largely because they
> switch the address configuration mechanism (SLAAC to DHCPv6 or vice versa)
> in addition to renumbering.  While that could happen in theory, it seems to
> be a quite artificial discussion.
[Bing] The address configuration mechanism switching is a specific case of renumbering; another one is to add a new address by DHCPv6 for the already SLAAC-configured hosts or vice versa. These use cases might happen in enterprise networks when companies split, merge, grow, relocate, or reorganize. 

> Actually, I guess there should be more pragmatic examples of operational
> issues because of the described divergence and I wonder whether these
> minor cases are really the only things we can imagine (although I don't have
> a specific idea right now).  If these sections can be revised with more
> convincing examples, I would be more supportive about publishing it.
[Bing] Current draft only documents the operational issues caused by divergent behaviors identified in the tests. In Appendix B, it documents a comprehensive analysis of the ambiguity. If we made a permutation and combination of the divergence derived from the ambiguity analysis, there would be other divergence that did not covered in our limited tests (focusing on current mainstream desktop/phone OSes). But since it is only in theory, we just left it in the appendix as a hint to the administrators.

>   of them in this sentence seems to be misleading, if not simply
[Bing] A flag in definition is not prescriptive, RFC4862 only explicitly defined " If the Autonomous flag is not set, silently ignore the Prefix Information option." 
However, A flag in implementations (as we tested) is prescriptive, and I also agree it should be. We might need to be distinguish the description between the A/M/O flags.
Thanks for the good point.

>    [...]  The following setting are all
[Bing] We'll revise accordingly. Thank you.

Best regards,
Bing

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 21 Oct 2014 20:42:06 +0900

> although I wouldn't be opposed to it if the wg thinks it's useful.

+1. The operational problems section boils down to one statement: "if you
flash renumber, the results differ between operating systems" (i.e.,
section 3.2.2). That's a true statement, but pretty obvious from the
preceding text.

The only other operational problems statement, in section 3.2.1, is not
very useful: if you don't have addresses via DHCPv6 or SLAAC, then there's
little point getting other information from DHCP. For this to work at all,
IP addresses must be configured manually, and if you're using manual
configuration, you might as well configure other information manually as
well.

The rest of the draft before the appendix is a rehash of RFC 4862, which
doesn't really add anything new.

On the other hand, the appendix, which documents the behaviour of various
OSes under different conditions, is useful.

Given that, it would seem to make more sense for this document to focus
only on the results of the investigation (i.e., only the appendix), and a
concluding statement that notes that implementations differ in their
behaviour, and that renumbering behaviour is substantially different.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 21 Oct 2014 11:09:13 -0700

At Tue, 21 Oct 2014 03:25:27 +0000,

> So, if there is an RFC explicitly stating the problems, I think it would be good for administrators/operators to learn the fact before they actually deploying the networks. Also, the document could…

There are many ambiguous things (and possible behavior divergence as a
result) in this world in general.  Just because we have something
ambiguous is not critical enough to me for the cost of publishing
something formal such as an RFC; IMO we should have specific problems
that the ambiguity and divergence can cause, and the problems should
be critical enough.

In its current form, the described problems seem to be too artificial,
hypothetical, or minor to be important to me.  And that's why I didn't
regard this draft as that important.  Overall, your response to this
point doesn't change my impression.

I understand different people can have different views on the
importance, so I didn't intend to insist mine is the only correct
view.  I expressed it as the chairs explicitly asked for it, but if
many others think it important enough, that's fine to me.

--
JINMEI, Tatuya

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 22 Oct 2014 02:12:48 +0000

Hi Jinmei,

> result) in this world in general.  Just because we have something ambiguous
> is not critical enough to me for the cost of publishing something formal such
> as an RFC; IMO we should have specific problems that the ambiguity and
> divergence can cause, and the problems should be critical enough.

[Bing] I also agree not any ambiguous things are worth to be documented.
But the DHCPv6/SLAAC address configuration issue is quite fundamental and critical in my point of view.

> In its current form, the described problems seem to be too artificial, hypothetical or minor to be important to me.  
> And that's why I didn't regard this draft as that important.  
> Overall, your response to this point doesn't change my impression.
> I understand different people can have different views on the importance, so
> I didn't intend to insist mine is the only correct view.  I expressed it as the
> chairs explicitly asked for it, but if many others think it important enough,
> that's fine to me.

[Bing] I can't agree the problems are artificial or hypothetical. If you're in the cases the document describes, you'll face the problems, it's real.
However, if you argue you'll never meet the situations or it's not a big deal even if you meet the situations, that's another thing. Opinions may vary.

Anyway, thanks for expressing your opinions on it. I also hope there could be more feedbacks from the WG. 

Best regards,
Bing

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 22 Oct 2014 02:33:58 +0000

Hi Lorenzo,

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Tuesday, October 21, 2014 7:42 PM
To: 神明達哉
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

On the other hand, the appendix, which documents the behaviour of various OSes under different conditions, is useful.

Given that, it would seem to make more sense for this document to focus only on the results of the investigation (i.e., only the appendix), and a concluding statement that notes that implementations differ in their behaviour, and that renumbering behaviour is substantially different.

[Bing] I’ll consider this suggestion. But if this document follows the approach, it needs another significant revision. I’d like to hear others’ opinions and discussion in the upcoming meeting.

Best regards,
Bing

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 22 Oct 2014 13:22:48 +0000

> > > implementations behave differently.  Since such a divergence can
> > > cause a critical operational issue, I see a value in documenting these.
> > [Bing] I believe it is well known among standard developers, participants
> and implementers who had paid attention on it. However, since the
> ambiguity problem is not so explicit in current standard, the vast
> administrators/operators out IETF might not quite familiar with it. I once
> talked with some operator people, they were quite confused about the
> situation when they met the problem in their IPv6 testbed networks.
> > So, if there is an RFC explicitly stating the problems, I think it would be good
> for administrators/operators to learn the fact before they actually deploying
> the networks. Also, the document could be a formal reference for potential
> standard work in the future to clear the ambiguity in current standards.

> hypothetical, or minor to be important to me.  And that's why I didn't regard
> this draft as that important.  Overall, your response to this point doesn't
> change my impression.

+1 I agree with what Jinmei said.
Barbara

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Wed, 22 Oct 2014 15:56:31 +0200

Below goes my review of this document.

General impressions:

The information about the differences in the behavior of the OSes is
operationally useful and is worth publishing.  Some of the questions
that this document raises do look like valid concerns to me, and
should be brought further (i.e. the DHCPv6 address behavior on flag
change), some of them (A=0,O=1,M=0), in the absence of supporting
reasons "why", look more like a curiosity - interesting to point out
in case this corner case happens as a transient, but not worth
spending the cycles trying to agree what the implementations should be
doing in that case.

More specific comments:

2.1.  M (Managed) Flag

"The M flag indicates that addresses are available from IPv6."

s/IPv6/DHCPv6/ ?

"the O flag is redundant and can be ignored"

Could be good to have an explicit reference to
section

"4.2.Router Advertisement Message Format" of RFC4861 where this text
is coming from.

2.3.  A (Autonomous) Flag

"The A flag indicates that the prefix that is also carried by the PI
   option can be used for SLAAC.  A flag semantics are independent of M
   and O flag semantics.  The A flag indicates that the prefix can be
   used by SLAAC, regardless of the M and O flag settings."

What about rephrasing this as:

"The A flag, carried within the Prefix Information option, indicates
that the prefix in this option can be used for stateless
autoconfiguration. Flag semantics are independent of M and O flags,
and their values do not affect whether this prefix can be used or
not."

"3.2.1.  Inappropriate Sources"

interesting finding. Why is it a problem worth solving ?

"3.2.2.  Renumbering"

The three steps described read as a sequence, whereas they are
alternative renumbering strategies. This should be rephrased to make
it clearer.

Also, the renumbering discusses flash renumbering process. Should it
also make a reference to rfc4192 which is aiming to perform a
renumbering without a flag day, and look at the issues accordingly ?

Appendix A:

A.1:

"Host 1: Window 7 / Window 8.1 Virtual Host" - Windows should be in plural.
"Host 2: Ubuntu 14.04" - is it Ubuntu Desktop in default configuration
? I presume so, but it should be mentioned explicitly.

A.3:

"reveiving A transitiong" => needs spellcheck and potentially rephrase
for the sentence.

Appendix B:

"More specifically, is RA (with M=1) required to trigger DHCPv6?  If
there are no RAs at all, should hosts initiate DHCPv6 by themselves?"

RFC4862, 5.5.2.  Absence of Router Advertisements mentions:
   Even if a link has no routers, the DHCPv6 service to obtain addresses
   may still be available, and hosts may want to use the service.  From
   the perspective of autoconfiguration, a link has no routers if no
   Router Advertisements are received after having sent a small number
   of Router Solicitations as described in [RFC4861].

   Note that it is possible that there is no router on the link in this
   sense, but there is a node that has the ability to forward packets.
   In this case, the forwarding node's address must be manually
   configured in hosts to be able to send packets off-link, since the
   only mechanism to configure the default router's address
   automatically is the one using Router Advertisements.

Does this wording answer the question ?

"it is not
      clear whether the host should start DHCPv6 or not; or vise versa,
      the host is already both SLAAC/DHCPv6 configured, then M flag
      change from TRUE to FALSE, it is also not clear whether the host
      should turn DHCPv6 off or not."

What is desired from the operational standpoint and why ? (Also,
taking into the account the effects on the DHCPv6 server caused by a
crowd of hosts receiving an RA and simultaneously (re)starting up the
DHCPv6 process).

"For example, when both M and
      O flags are TRUE, it is not clear whether the host should initiate
      one stateful DHCPv6 session to get both address and info-
      configuration or initiate two independent sessions of which one is
      dedicated for address provisioning and the other is for
      information provision. "

The end result of doing either of the two behaviors should be the
same, shouldn’t it ?
If so - then why going through the effort of specifying one or another
behavior ?

" When A and M flags are FALSE and O flag is
      TRUE, it is not clear whether the host should initiate a stand-
      alone stateless DHCPv6 session."

Again, same question as in 3.2.1: what is the practical use case
scenario for this ? i.e. is this problem worth solving and why ?

--a

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 23 Oct 2014 11:51:24 +0000

Hi Andrew,

Really appreciate your careful review and the comments.
Please find replies inline.

> From: v6ops [mailto:[email-masked]] On Behalf Of Andrew ??
> Yourtchenko
> Sent: Wednesday, October 22, 2014 9:57 PM
> To: [email-masked]
> Cc: [email-masked]
> operationally useful and is worth publishing.  Some of the questions that
> this document raises do look like valid concerns to me, and should be
> brought further (i.e. the DHCPv6 address behavior on flag change), some of
> them (A=0,O=1,M=0), in the absence of supporting reasons "why", look
> more like a curiosity - interesting to point out in case this corner case
> happens as a transient, but not worth spending the cycles trying to agree
> what the implementations should be doing in that case.

[Bing] I'll consider this together with Lorenzo's comment. Maybe another big revision is needed. 

> "The M flag indicates that addresses are available from IPv6."
[Bing] My fault. Sorry.
 
> Could be good to have an explicit reference to section
> 
> "4.2.Router Advertisement Message Format" of RFC4861 where this text is
> coming from.
[Bing] Ok, will do.

> "The A flag, carried within the Prefix Information option, indicates that the
> prefix in this option can be used for stateless autoconfiguration. Flag
> semantics are independent of M and O flags, and their values do not affect
> whether this prefix can be used or not."
[Bing] It's better, thank you.

> interesting finding. Why is it a problem worth solving ?
[Bing] A host who self-configuring the IP address will not be able to do a stateless configuration. 
Say, a sensor self-configures ULA address and needs to get other information from DHCPv6 server. In this scenario, stateful DHCPv6 might be too heavy for the system.

> "3.2.2.  Renumbering"
> 
> The three steps described read as a sequence, whereas they are alternative
> renumbering strategies. This should be rephrased to make it clearer.
> 
> Also, the renumbering discusses flash renumbering process. Should it also
> make a reference to rfc4192 which is aiming to perform a renumbering
> without a flag day, and look at the issues accordingly ?
[Bing] The intended meaning is actually to caution that a flash renumbering might happen on some operating systems when the M flag is turned off. 
The wording needs to be revised.

> "Host 2: Ubuntu 14.04" - is it Ubuntu Desktop in default configuration ? I
> presume so, but it should be mentioned explicitly.
[Bing] Yes, they're all in default configuration. Will revise accordingly.
 
> A.3:
> 
> "reveiving A transitiong" => needs spellcheck and potentially rephrase for the
> sentence.
[Bing] Will do.

> Appendix B:
[Bing] This appendix is an analysis in theory that what ambiguities are existing in current standards. It is a hint, might not necessarily means operational problems.
I think your following questions are useful for the DHCPv6/SLAAC Interaction Guidance draft. I'll consider them in that draft.

Many thanks.

Best regards,
Bing

> "More specifically, is RA (with M=1) required to trigger DHCPv6?  If there
> are no RAs at all, should hosts initiate DHCPv6 by themselves?"
> 
> What is desired from the operational standpoint and why ? (Also, taking into
> the account the effects on the DHCPv6 server caused by a crowd of hosts
> receiving an RA and simultaneously (re)starting up the
> DHCPv6 process).
> 
> The end result of doing either of the two behaviors should be the same,
> shouldn’t it ?
> Again, same question as in 3.2.1: what is the practical use case scenario for
> this ? i.e. is this problem worth solving and why ?
> 
> --a
>

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Thu, 23 Oct 2014 19:17:05 +0200

Hi Bing,

thanks for the comments! my replies inline...

> [Bing] I'll consider this together with Lorenzo's comment. Maybe another big

This looks like good idea to me.

> Say, a sensor self-configures ULA address and needs to get other information
> from DHCPv6 server. In this scenario, stateful DHCPv6 might be too heavy for
> the system.

To clarify - you mean link-local addresses, rather than ULAs, right ?
(since to configure ULAs, the host would somehow need to know the
prefix being serviced by the router, which sounds awfully close to
autoconf to me)

If we speak about a specialized environments like sensors, they
probably will try the stateless DHCPv6 regardless of the flags in RA,
since that will be their only way to configure themselves, what do you
think ?

The use-case I was after was something involving the common off the
shelf OSes, i.e. the part of the "every day network administration"
theme of the document.

>> alternative
> [Bing] The intended meaning is actually to caution that a flash renumbering
> might happen on some operating systems when the M flag is turned off.

Ahh, then - while the flash-renumbering-with-M-flag is a very worthy
problem to mention, it is not clear that this is the "takeaway" from
this part of the document.

> [Bing] This appendix is an analysis in theory that what ambiguities are
> existing in current standards. It is a hint, might not necessarily means
> operational problems.

ah okay, thanks for clarifying!

--a

> I think your following questions are useful for the DHCPv6/SLAAC Interaction
> Guidance draft. I'll consider them in that draft.
>
> Many thanks.
>
> Best regards,
> Bing
>
>> there

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 28 Oct 2014 04:01:13 +0000

Hi Andrew,

Sorry for the late reply.

> > Say, a sensor self-configures ULA address and needs to get other
> > information from DHCPv6 server. In this scenario, stateful DHCPv6
> > might be too heavy for the system.
> 
> (since to configure ULAs, the host would somehow need to know the prefix
> being serviced by the router, which sounds awfully close to autoconf to me)
[Bing] Link-local is also a use case, but I also meant ULA case, since offline communication might also needed.
And the ULAs could be self-generated instantly or burnt in the device in advance.

> If we speak about a specialized environments like sensors, they probably will
> try the stateless DHCPv6 regardless of the flags in RA, since that will be their
> only way to configure themselves, what do you think ?
[Bing] I'm not sure whether always trying stateless DHCPv6 is a good behavior or not. Maybe they don't need extra information from DHCPv6, or maybe RAs are enough.
The point here is, if I got an address without SLAAC/DHCPv6, can I still decide whether to initial stateless DHCPv6 according to the only O flag?

Best regards,
Bing
 
> The use-case I was after was something involving the common off the shelf
> OSes, i.e. the part of the "every day network administration"
> theme of the document.
> 
> >

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Wed, 29 Oct 2014 13:24:55 +0100

Hi Bing,

> And the ULAs could be self-generated instantly or burnt in the device in

Sure, a self-generated ULA implies that there is only that host on
that prefix. Who is it communicating with and how ? How does the
router know it has to service those ULA prefixes ? How does the host
that a peer's ULA prefix is on-link so it could talk directly without
a router ?

What am I misunderstanding in the above ?

> [Bing] I'm not sure whether always trying stateless DHCPv6 is a good
> behavior or not. Maybe they don't need extra information from DHCPv6, or
> maybe RAs are enough.
> The point here is, if I got an address without SLAAC/DHCPv6, can I still
> decide whether to initial stateless DHCPv6 according to the only O flag?

Yeah, from the completeness standpoint, sure.

By the way, this triggers a suggestion for one more general comment:
RFC6106 interaction is completely out of coverage in the draft, but
would be very useful from the practical standpoint, also to see what
happens if the information in RDNSS and DHCPv6 is in conflict.

--a

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Oct 2014 08:29:24 +1300

On 30/10/2014 01:24, Andrew 👽 Yourtchenko wrote:
...
> How does the host [know]

Why is this different from the question:

How does the host know that a peer's GUA prefix is on-link so it
could talk directly without a router ?

  Brian

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Thu, 30 Oct 2014 10:11:26 +0100

> could talk directly without a router ?

It's not. And my "without a router" wording was clumsy - it was
supposed to emphasize the way two  on-link hosts communicate
(directly, without the involvement of the router), not the absence of
the router altogether. I am sorry for confusing the language.

In both ULA and GUA cases there would need to be a router would need
to have the prefix(es) in the RA, wouldn't it ?

But, on the origin of the "ULA" and this sub-thread:

<quote>
> In the case described in Section 3.2.1, the host would only have link-local
[Bing] Or maybe self-generated ULAs. (But of course, it is not the
point of this document.)
</quote>

I was trying to understand how that straw man was supposed to work.

A possibility of statically assigned GUAs in the first place somehow
escaped me - while, in fact, a server admin that manages the addresses
but does not control where is the today's DNS server is a much more
plausible case. Thus that comment to which Bing replied with "ULA"
straw man should not have been there in the first place. Thanks for
triggering me to realize that.

Bing,

please disregard the part of my previous mail related to ULAs.

Would be still interesting to hear your opinion about rfc6106.

--a

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 31 Oct 2014 03:56:08 +0000

Hi Andrew,

Please see inline.

> From: Andrew 👽 Yourtchenko [mailto:[email-masked]]
> Sent: Thursday, October 30, 2014 5:11 PM
> To: Brian E Carpenter
> Cc: Liubing (Leo); [email-masked]
> > How does the host know that a peer's GUA prefix is on-link so it could
> > talk directly without a router ?
> 
> It's not. And my "without a router" wording was clumsy - it was supposed to
> emphasize the way two  on-link hosts communicate (directly, without the
> involvement of the router), not the absence of the router altogether. I am
> sorry for confusing the language.
> 
> In both ULA and GUA cases there would need to be a router would need to
> have the prefix(es) in the RA, wouldn't it ?
> 
> > link-local addresses.
> [Bing] Or maybe self-generated ULAs. (But of course, it is not the point of
> this document.) </quote>
> 
> A possibility of statically assigned GUAs in the first place somehow escaped
> me - while, in fact, a server admin that manages the addresses but does not
> control where is the today's DNS server is a much more plausible case. Thus
> that comment to which Bing replied with "ULA"
[Bing] Thanks for the discussion and clarification.

> Would be still interesting to hear your opinion about rfc6106.
[Bing] This is indeed an issue. There were some people also raised this problem before. We've captured the problem in the Guidance draft (see https://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-03#section-2.2.3, the last bullet).
For the PS draft, it is mostly regarding to the interaction between two protocols (DHCPv6/SLAAC). Although the two protocols both have the DNS option, they are separate in protocol level. So we only include this issue in the Guidance draft. 
That's my consideration, but I'd like to hear yours.

Best regards,
Bing

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Fri, 31 Oct 2014 11:38:11 +0100

Hi Bing,

On 10/31/14, Liubing (Leo) <[email-masked]> wrote:
[snip]

> [Bing] This is indeed an issue. There were some people also raised this
> problem before. We've captured the problem in the Guidance draft (see
> https://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-03#section-2.2.3,
> the last bullet).

ok, thanks for the link! on that one, might be useful to add an
explicit reference to RFC6106 as a normative reference.

> For the PS draft, it is mostly regarding to the interaction between two
> protocols (DHCPv6/SLAAC). Although the two protocols both have the DNS
> option, they are separate in protocol level. So we only include this issue
> in the Guidance draft.

The draft highlights the less common scenarios with various values of
flags in the RA and their transitions - and the behavior of hosts
during these scenarios.

To me, the RFC6106/DHCPv6 interaction would fall into the same bucket,
from the practical administration perspective.

The questions that pop up are like: What do the hosts do if RDNSS is
within the RA but the "O" flag is set ? Do the hosts keep their DNS
information if we switch the stateless DHCPv6 off,  use only the RDNSS
? If I want to maximize the chances of devices working, do I use
RDNSS, or stateless DHCPv6, or both ? The mention in SLAAC guidance
document just says that the host would get confused if different
information gets sent, is that the only scenario ? (I did not test
extensively myself, so asking if you have more info).

There is draft-gont-6man-slaac-dns-config-issues that talks about the
RDNSS specific issues, and I do not know whether RDNSS+DHCPv6
interaction has just not been tested or does not have any issues.

Now, of course it is a lot of additional testing work, so adding
anything like that into the document would be contingent on more
participants of WG saying it is a useful idea vs. shipping the
document as is.

--a

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 31 Oct 2014 21:57:35 +0900

> participants of WG saying it is a useful idea vs. shipping the

The way I see it, the value of the document is in the testing, not in the
operational guidance (of which there is very little). Thus, more testing
would increase the value of the document.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 Oct 2014 08:28:43 -0700

> On Oct 31, 2014, at 5:57 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Fri, Oct 31, 2014 at 7:38 PM, Andrew 👽 Yourtchenko <[email-masked] <mailto:[email-masked]>> wrote:
> The way I see it, the value of the document is in the testing, not in the operational guidance (of which there is very little). Thus, more testing would increase the value of the document.

+1

Owen