Subject: comments on draft-daniel-ipv6-ra-mo-flags-00.txt

From: Pekka Savola <[email-masked]>
Date: Mon, 9 Aug 2004 15:40:00 +0300 (EEST)

Hi,

A could of quick comments on draft-daniel-ipv6-ra-mo-flags-00.txt.

Editorial suggestion: please switch to use XML2RFC.  Pretty please!

Two bigger issues:

1) This document doesn't seem to take a stance what happens when/if the host
has multiple routers (whether on the same or different interfaces), and some
of them have O/M bits set and some others not.  Would that lead to a
set-unset-set-unset loop, with triggering?  If heard on another interface,
should that affect how DHCPv6 is run?

2) The treatment of M/O flag "transitions" and the initial state after a
reboot is not 100% unambiguous.

In section 6.0 you said:

                          The host should reset these flags depending
       on the information received in RAs when the host is rebooting.

...

       Policy 2: The host SHOULD invoke Stateful DHCPv6 for address 
       autoconfiguration (along with other configuration information)
       if and only if it sees an RA changing the M bit from unset to set.

==> but in previous sections, you used the wording "from unset to set";
this requires that there is, in fact a transition -- that these are always
initialized to zero.  

The latter wording ("RA changing the M bit") is also confusing because
"M bit" has typically been considered as a property of the routing
advertisement, not a global variable of the node.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 10 Aug 2004 20:28:53 +0900

Thanks for the comments.

>>>>> On Mon, 9 Aug 2004 15:40:00 +0300 (EEST), 
>>>>> Pekka Savola <[email-masked]> said:

> Editorial suggestion: please switch to use XML2RFC.  Pretty please!

<co-author hat off>
I tend to agree.  At least I-D editors should use a tool that can
produce text that conforms to the I-D nits...

<co-author hat on>

> should that affect how DHCPv6 is run?

Regarding multi-interface hosts, the base documents (RFC2461/2462 and
their bis-versions) only provide incomplete considerations.  I don't
see any strong reason for describing these cases in this derivative
work.

Then, now concentrating on the case of a single link (interface), I
also do not think inconsistency among multiple routers is a big issue.
If I understand the sense of RFC2462 correctly, it is administrator's
responsibility to provide the consistency, and inconsistent
configuration is basically an admin error.

As described in Section 5.6 of RFC2462, a host will simply regard the
inconsistent flag values as changes of the bits.  So, basically, the
behavior on the flag change should simply apply here.

One point that may require consideration is that the "change" might be
so frequent and so rapid.  And we may need a separate consideration
for such an erroneous case, depending on the behavior on the flag
change.  At this moment, I don't have a clear idea on this point.

> reboot is not 100% unambiguous.

I admit the terminology and/or description are not fully clarified on
this point.  Perhaps we need something similar to the host-internal
variables defined in RFC2462 (ManagedFlag and OtherConfigFlag) to
describe the behavior for the transition.

Also, I agree that the usage of "on", "off", "reset", "set", "clear"
is not very clear.  We'll need to clarify this in future versions of
the document.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Syam Madanapalli <[email-masked]>
Date: Tue, 10 Aug 2004 18:27:51 +0530

----- Original Message ----- 
From: <JINMEI Tatuya / $B?@L@C#:H (B <[email-masked]>)>
To: "Pekka Savola" <[email-masked]>
Cc: <[email-masked]>; "Soohong Daniel Park" <[email-masked]>
Sent: Tuesday, August 10, 2004 4:58 PM
Subject: Re: comments on draft-daniel-ipv6-ra-mo-flags-00.txt

> change.  At this moment, I don't have a clear idea on this point.

M/O flags indicate the avaialbility of the respective service, so if a
router advertises
the M/O flags bits ON, I think we should OFF them if and only if the same
router
advertises again to OFF. It is administartor problem if one advertises with
bits ON,
and other router with bits OFF.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 10 Aug 2004 23:50:13 +0300 (EEST)

On Tue, 10 Aug 2004, Syam Madanapalli wrote:
> M/O flags indicate the avaialbility of the respective service, so if
> a router advertises the M/O flags bits ON, I think we should OFF
> them if and only if the same router advertises again to OFF. It is
> administartor problem if one advertises with bits ON, and other
> router with bits OFF.

How do you propose the host keeps track of which router advertised 
which bits?  This kind of tracking is not done at the moment.

---

From: "S. Daniel Park" <[email-masked]>
Date: Wed, 11 Aug 2004 09:58:51 +0900

> Editorial suggestion: please switch to use XML2RFC.  Pretty please!

As coauthor of this draft, I am so sorry to bother readers. It will be
done during our revision...:-)
 
> should that affect how DHCPv6 is run?

Interesting, however I don't think it's a big issue at this stage. Also
2461 says router should verify that RAs from other routers are consistent

Regards.

- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.

---

From: Syam Madanapalli <[email-masked]>
Date: Wed, 11 Aug 2004 19:59:43 +0530

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "Syam Madanapalli" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Soohong Daniel Park"
<[email-masked]>
Sent: Wednesday, August 11, 2004 2:20 AM
Subject: Re: comments on draft-daniel-ipv6-ra-mo-flags-00.txt

> which bits?  This kind of tracking is not done at the moment.

True, this requires one needs maintain the M/O flags information per router
basis. And this leads to implementation complexity. But I think this method
provides robust implemention. I am not sure how people are managing if
two different routers on same link advertises two different Link MTU. I
think the problem could be similar in both the cases.

---

From: Greg Daley <[email-masked]>
Date: Thu, 12 Aug 2004 12:49:49 +1000

Hi Syam,

> think the problem could be similar in both the cases.

Indeed it is similar.

When you have trusted routers with differing configurations,
you have to make a decision what configuration to undertake.

For MTU, it's clear that you need to take the smallest
(most restrictive) value advertised.  This is because
choice of a higher MTU is likely to have worse effects
than

For DHC it's not the same choice, although it requires similar
decision path.  In DHC, any M or O flag set indicates that
there is a DHC server available (albeit it may provide
only limited function).

In this case, the host can use a DHC server if any of the trusted
routers advertises this capability.  In this case,
the scenario is least restrictive, rather than most restrictive.

Certainly the routers should advertise consistent values,
but the hosts should make reasonable decisions even if
the routers disagree.

Greg

---

From: Syam Madanapalli <[email-masked]>
Date: Thu, 12 Aug 2004 16:09:51 +0530

Hi Greg,

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "Syam Madanapalli" <[email-masked]>
Cc: "Pekka Savola" <[email-masked]>; <[email-masked]>; "Soohong Daniel
Park" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 12, 2004 8:19 AM
Subject: Re: comments on draft-daniel-ipv6-ra-mo-flags-00.txt

> choice of a higher MTU is likely to have worse effects

Yep, I agree. Using the smaller MTU one will be more safer.
But  it may be efficient to use the advertised MTU
when the packet is destined for that particualr router because
these two routers might have connected to different networks
and the these routers may support different MTUs based on
their hardware capabilities.

> but the hosts should make reasonable decisions even if

So you agree to maintain M/O flags per router basis and
R1:M | R2:M|...|Rn:M = 1 means DHCPv6 Server available
on the network?
Similarly for O flag.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Aug 2004 08:54:14 -0400

Comments in line...

- Ralph

>their hardware capabilities.

And, in general, the cross-product of possible decision scenarios against
possible advertised values (MTU, M/O flags, etc.) from routers is, I think,
too large and not sufficiently well-defined to be enumerated in the protocol
specification.  Guidance to implementors is a good thing, but it seems
unlikely that we can correctly specify the required behavior for all hosts
in all cases.

>R1:M | R2:M|...|Rn:M = 1 means DHCPv6 Server available

I agree.

---

From: Fred Templin <[email-masked]>
Date: Thu, 12 Aug 2004 09:36:03 -0700

> choice of a higher MTU is likely to have worse effects

I think this needs a bit of refinement. For multicast RAs (both unsolicited
and solicited), the MTU option gives an indication of how much the router
itself can accept - presumably as a reflection of the router's attached link
MTU, router buffer restrictions, etc. For unicast, solicited RAs, however,
the MTU option gives an indication of how much the forward path from
the soliciter to the router can accept.

Since the L2 switches/bridges/etc. on the paths between a soliciter and
its candidate routers may be quite different, it seems reasonable that
the soliciter might want to store different MTUs reported by different
routers in solicited unicast RAs.

Fred
[email-masked]

---

From: Greg Daley <[email-masked]>
Date: Fri, 13 Aug 2004 10:47:08 +1000

Hi Syam,

Syam Madanapalli wrote:
[cut]
> their hardware capabilities.

Certainly, but the packets may be lost if the router is
misconfigured (which is a general statement...).

> R1:M | R2:M|...|Rn:M = 1 means DHCPv6 Server available

If you don't want to keep all the state for all routers,
you could just listen to the router you have configured.
If you believe its advertisements and it indicates O=1,
then I guess that's sufficient to invoke Information-Request.

It's not necessary then to ask for other opinions, or track state
on all routers (it's what C calls short-circuit evaluation).

If your host really desires to do DHC, and do not have an indication
that it's available, some hosts will wish to do it anyway (Policy=1),
but generally, you'd wish to see some indication that the service
is available before resorting to it (especially for constrained hosts
and links).

Greg

---

From: Greg Daley <[email-masked]>
Date: Fri, 13 Aug 2004 11:03:03 +1000

Hi Fred,

> routers in solicited unicast RAs.

Indeed, when you're commuicating off-link, this may be correct.
When communicating within the link (link-local or to neighbours)
you can't be guaranteed where the packets will go within the domain.

The smallest option is the safest in this case,
since no specific information about the path taken is available.

Path MTU is always based on the narrowest MTU on a path.
Within a link, the same applies (narrowest MTU on path within the link),
regardless of what the attached interface on a router believes.

Greg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 13 Aug 2004 12:57:03 +0900

>>>>> On Wed, 11 Aug 2004 19:59:43 +0530, 
>>>>> Syam Madanapalli <[email-masked]> said:

> think the problem could be similar in both the cases.

(I'm responding to this message after reading all the other messages
in this thread)

I'm afraid people may forget that it is administrator's responsibility
to ensure the consistency among RA parameters from multiple routers
in the same single link (see Section 5.6 of RFC2462 - while the RFC
does not explicitly say it's admin's responsibility, but I strongly
believe it's the background intent).  Section 5.6 of RFC2462 also
clearly specifies the behavior when a host happens to receive
inconsistent parameters:

   If inconsistent information is learned different
   sources, the most recently obtained values always have precedence
   over information learned earlier.

An implementation might explore an implementation dependent trick like
combining routers and parameters to mitigate the bad effect of the
admin error.  However, I'd really want to make it outside the scope of
the M/O document.

					JINMEI, Tatuya

---

From: Greg Daley <[email-masked]>
Date: Fri, 13 Aug 2004 14:57:13 +1000

Hi Jinmei,

> admin error.  However, I'd really want to make it outside the scope of

I agree with this,

In this case, we need to ensure that the router advertisement which
we're basing the decision on has the flags set.

It may even be worthwhile explicitly stating that management of
flags from multiple routers is not in scope.

Greg

---

From: Radhakrishnan Suryanarayanan <[email-masked]>
Date: Fri, 13 Aug 2004 10:46:22 +0530

Hi greg & Jinmei,
  Please find the comments inline.

> flags from multiple routers is not in scope.

Since the idea of the draft is for BCP/Informational on M&O, we shall as
well add an
appendix section to describe handling of the flags from multiple routers.

Regards
Radhakrishnan & OLN Rao

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 13 Aug 2004 14:34:31 +0900

>>>>> On Fri, 13 Aug 2004 10:46:22 +0530, 
>>>>> Radhakrishnan Suryanarayanan <[email-masked]> said:

> appendix section to describe handling of the flags from multiple routers.

I don't mind adding the appendix as long we just describe possible
issues (if any) and do NOT try to provide workaround like combining
router/parameters.

					JINMEI, Tatuya

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 13 Aug 2004 16:54:40 +0530

Hi Jinmei,

<cut>
> issues (if any) and do NOT try to provide workaround like combining

That looks fine, we will just describe the issues and leave the
implementation
details to the developers.

---

From: "S. Daniel Park" <[email-masked]>
Date: Mon, 23 Aug 2004 14:04:24 +0900

Sorry for being too late response.

> should that affect how DHCPv6 is run?

Suggestion: 

It seems a rather general issue on the inconsistent RA parameters
from multiple routers, thus I wrote simple text as Appendix section.

Appendix A: Handling of M/O flags from multiple routers

This document does not take a hard stance what happens when a host
has multiple routers, and inconsistent information (different M/O
flags configuration) is learned from different routers.  Originally,
the basic documents [RFC2461]/[RFC2462] already described
"Configuration Consistency" described in Section 5.6 of [RFC2462] and
a host will simply handle the inconsistent M/O flags of RA in the
same manner.  if the inconsistent M/O flags of RA is reached to a
host frequently (e.g., mobile environment for supporting fast
movement detection when attaching a new network) it can occurs
complex consideration as an erroneous case, however this case is not
closely related to this document (rather general issue on the
inconsistent RA parameters from multiple routers) since other
configuration parameters such as MTU size and hope lime is also
possible to be learned from this inconsistency, and besides, it is
administrator's responsibility to ensure the consistency among RA
parameters from multiple routers in the same single link as described
in Section 5.6 of [RFC2462].  So authors remain "Handling of M/O
flags from multiple routers" as out of scope of this document.
Hopefully, it will be more clarified in the basic documents (or seperate
one) as well than now.

> this requires that there is, in fact a transition -- that these are always

Suggestion:

The host SHOULD *update* these flags depending on the information
received in RAs when the host is rebooting.

IMO, it does not mean *initialized status is always zero*. 

> advertisement, not a global variable of the node.

Suggestion:

Policy 2: The host SHOULD invoke Stateful DHCPv6 for address
autoconfiguration (along with other configuration information) if and only 
if it receives an RA containing the M bit ON.

Let me know your view on this.

Thanks