Subject: [Resolving Issues]IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt

From: "Soohong Daniel [email-masked]" <[email-masked]>
Date: Tue, 03 May 2005 12:29:10 +0900

Hi all

I've tried to note down several considerable points.
Let me know your view on them if I am missing anything.
If acceptable, I will make a revision once more.

============================================

+ means Concern
- means Considerable mentions from ML
$ means trial efforts on resolving them

[Issue 1]
"Client operation which is set to M-Policy 1 along with 3736 DHCPv6 server"
+ if a full DHCPv6 client is initiated and server is only 3736, the client
get back the 
   Information Configuration Behaviour ? or sending the Solicit to server
forever ?
   - Just indicating that it's host/network admin misconfiguration
   - Fall-back behaviour to Information Configuration Behaviour (see Issue
2)
   - Updating original DHCPv6 specifications (3315, 3736)

$ Trial: just saying this issue as an admin misconfiguration including
Trial 
           text of Issue 2.

[Issue 2]
"Parallel operation of HCB and ICB with DHCPv6 specification"
RFC3315 does not preclude a client from initiating an Information-request
/Reply message exchange in parallel with or subsequent to a Solicit
/Advertise/Request/Reply message exchange
+ Breaking the sense of RFC2462 (Section 5.5.3)
   - Remaining it as a general issue and simple mention in this document

$ Trial: if a client does not receive any response from DHCPv6 server while 
           performing Host Configuration Behaviour, the client then begins 
           Information Configuration Behaviour in parallel with Host
Configuration 
           Behaviour. It causes a considerable case as non-addresses 
           configuration since Information Configuration Behaviour does not 
           include addresses information. The authors remain this issue to
be 
           resolved in the related working group (probably DHC WG).

[Issue 3]
"Inconsistent M and O flags of RA"
+ Inconsistent RA is a in-scope problem of this document ?
   - More describing of why M/O transitions are a bigger problem than 
      other inconsistent information

$Trial: In the end, it is administrator's responsibility to ensure the
consistency 
          among Router Advertisement parameters from multiple routers in
the 
          same single link as described in Section 5.6 of [RFC2462].  The
authors
          thus remain "Handling of M and O flags from multiple routers" out
of 
          scope of this document.

[Issue 4]
"Default policy on M/O flags"
HCB using RFC3315 - M-Policy 2, otherwise M-Policy 3 (HCB is not
implemented)
ICB using RFC3736 - O-Policy 1 or 2  
+ Is it fully acceptable ?

$Trial: If not acceptable, please make more comments. !

[Editorial]
+ In the last sentence of Section 12
   - s/is different form/is different from/
$Trial: done

+ SEND is now published as an RFC (RFC3971)
$Trial: done

+ if we need an update version of this document (I believe we do),
   - we'll need to use the new IPR boilerplate (e.g., with version 1.29 of
xml2rfc)
$Trial: will be done by next version

============================================

Thanks.

---------------------------------------------
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 16 May 2005 13:49:42 -0400

Exactly! 

> -----Original Message-----
> From: Stig Venaas [mailto:[email-masked]] 
> Sent: Monday, May 16, 2005 1:21 PM
> To: Bernie Volz (volz)
> Cc: JINMEI Tatuya / ????; Pekka Savola; [email-masked]; IPv6 
> WG; Ralph Droms (rdroms)
> Subject: Re: [dhcwg] Re: IPv6 WG Last 
> Call:draft-ietf-ipv6-ra-mo-flags-01.txt
> 
> Another reason they need to be only hints to the clients, is 
> that there
> might be many different types of clients on the same link. I 
> think there
> are many cases where you don't want to force all the clients to do the
> same. One thing is what information a client wants to obtain, 
> another is
> what it supports. Does the client do DHCP at all, does it 
> just do state-
> less, or does it do the full 3315.
> 
> Stig
>

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 17 May 2005 16:30:04 -0400

Pekka suggested you might have been referring to stateless DHCPv6 - ie,
when does a DHCPv6 client doing stateful DHCPv6 switch to doing
stateless DHCPv6?

I don't believe we had any specific text in this regard in 3315 or 3736
and is thus likely an issue for 3315-bis.

I assume you're asking this in the case where both the M and O flags are
set? And, I can see three techniques:
1. If the client supports stateful always use stateful and never switch
to stateless.

2. Try stateful for a few (perhaps only 1 Solicit / Advertise) cycles
and if there are no responses or only "error" responses, continue
stateful but also initiate stateless. The start of stateless could be
controlled by the O flag.

2. Always start both.

Personally, I like the first best as I would expect that if the M flag
is set and no DHCPv6 server responds, sending Information-Request
messages will also not yield anything useful. But, this does not work if
the default were to always set the M and O bits in RAs but only have a
stateless server.

That's why I think we've made mistakes in the DHCPv6 specifications:
1. For 3315, we should have had a status return code for an Advertise
that says "no stateful service available." Note that this is different
than the NoAddrsAvail status we presently have. 
2. For 3736, we should have required Solicit and Advertise to be
supported by the stateless DHCPv6 server such that it could return just
the "no stateful service available" status for any Solicits it receives.

That way, if the only servers to respond to Solicits all return "no
stateful service available", the client knows what to do.

- Bernie

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bernie Volz (volz)
> Sent: Tuesday, May 17, 2005 3:41 PM
> To: timothy enos; Pekka Savola
> Cc: [email-masked]; JINMEI Tatuya / ????; IPv6 WG; Ralph 
> Droms (rdroms)
> Subject: RE: [dhcwg] Re: IPv6 WG Last 
> Tim:
> I'm not sure what you mean by your question ... SLAC (stateless
> auto-configuration) is independent of stateful. There may be some
> prefixes on a link that are stateful (0 or more) and others that are
> stateless (0 or more - excluding the link-local which is always
> stateless).
> 
> So, SLAC is independent of stateful (DHCPv6).
> 
> - Bernie
> 
> > From: timothy enos [mailto:[email-masked]] 
> > Sent: Monday, May 16, 2005 10:00 PM
> > To: Bernie Volz (volz); 'Pekka Savola'
> > Cc: [email-masked]; Ralph Droms (rdroms); 'IPv6 WG'; 'JINMEI 
> > Tatuya / ????'
> > Subject: RE: [dhcwg] Re: IPv6 WG Last 
> > Bernie,
> > Your points are well taken, and I agree. Making these flags 'hints'
> > makes sense. Also, it seems that if a client does not know 
> what to do
> > (forgive the anthropomorphism) in response to having received 
> > an RA with
> > the M (and O) bit(s) set (because it is not a DHCPv6 
> client), it would
> > just ignore it/them. 
> > 
> > Also wondering if there are any RFC 3315-capable clients that, after
> > failing to get config info from a DHCPv6 server 'x' times, 
> > would revert
> > to SLAC?
> > 
> > Tim Enos
> > 1Sam16:7
> > 
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of
> > Bernie Volz (volz)
> > Sent: Monday, May 16, 2005 5:20 PM
> > To: Pekka Savola
> > Cc: [email-masked]; Ralph Droms (rdroms); IPv6 WG; JINMEI 
> > Tatuya / ????
> > Subject: RE: [dhcwg] Re: IPv6 WG Last
> > Hey, if they don't know what they're doing then set the bits 
> > and be done
> > with it. If there's no DHCP server, the clients will try to get
> > configuration information and fail and continuously try in the
> > background. That's the safest fallback and the recommended default,
> > IMHO.
> > 
> > If they do set them wrong, it won't take long for users to complain.
> > Just as they do now if the DHCP server or routing infrastructure is
> > down.
> > 
> > Trying to design for stupidity only produces the same.
> > 
> > - Bernie 
> > 
> > > From: Pekka Savola [mailto:[email-masked]] 
> > > Sent: Monday, May 16, 2005 5:09 PM
> > > To: Bernie Volz (volz)
> > > Cc: JINMEI Tatuya / ????; [email-masked]; IPv6 WG; Ralph 
> > > Droms (rdroms)
> > > Subject: RE: [dhcwg] Re: IPv6 WG Last 
> > > On Mon, 16 May 2005, Bernie Volz (volz) wrote:
> > > > BTW, if you want to look at this from the router administrator's
> > > > perspective:
> > > >
> > > > Configure the router to send the M flag set in routing 
> > > advertisements
> > > > for a Link IF:
> > > > 1. A stateful DHCP server is deployed for that link 
> > (either on it or
> > > > reachable via a relay agent) AND
> > > 
> > > IMHO, you're making a significant leap of faith in assuming that 
> > > whoever configures the router's M-flag advertisements has 
> > sufficient 
> > > clue to grasp the different semantics that arise with:
> > > 
> > >   - M-flag and/or O-flag
> > >   - stateless and stateful clients
> > >   - stateless and stateful servers
> > >   - stateless and stateful relay agents
> > > 
> > > Hence, if we want to build a robust system, we need to 
> > design it with 
> > > care.
> > > 
> > > 
> > > 
> > > -- 
> > > Pekka Savola                 "You each name yourselves 
> king, yet the
> > > Netcore Oy                    kingdom bleeds."
> > > Systems. Networks. Security. -- George R.R. Martin: A 
> Clash of Kings
> > > 
> >

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 20 May 2005 14:43:14 -0400

Excellent points Thomas. 

> > 5. what if the M flag is set but the host does not get any DHCPv6
> >    Advertise in the initial exchange?  Is it okay to fall 
> back to the
> >    RFC3736 subset?  Or is it even okay to run both full RFC3315 and
> >    the RFC3736 subset concurrently from the beginning?
> 
> Should be legal, but this is an unfortunate situation, since we're not
> trying getting into how to deal with misconfigurations...
> 

Probably the correct behavior for a client is to fallback to 3736 but
periodically try 3315.

This is similar to what Microsoft clients have been doing for a long
time ... If configured for DHCPv4, they'll attempt it for a while and if
it fails, they autoconfigure an address. But, that doesn't mean they
stop doing DHCPv4. In fact, the host continues to do so (albeit at a
less aggressive rate).

So, for a *full* featured DHCPv6 client, if it is told to run (either
because of local policy or because M bit set), if SHOULD attempt
stateful address configuration. After some number of attempts (perhaps
only 1), it may attempt stateless (3736). If it gets stuff, great.
However, in any case it should continue to send Solicit's periodically.

Isn't it the case that for Stateless Autoconfiguration a host that never
receives an RA for its RS will periodically send RSs? Though perhaps
that's not correct because a router will periodically send RAs.
Regardless of which way it works, the point is still the same ... There
are periodic attempts to communicate and that should be no different for
DHCPv6. 

- Bernie

---

From: [email-masked]
Date: Mon, 23 May 2005 12:24:02 +0300

Pekka and Bob,

> On Fri, 20 May 2005, Bob Hinden wrote:
> > Also, I am not sure I understand what the problem is regarding knowing when 
> > to try using DHCPv6.  For practical purposes, if there isn't a router present 
> > (indicated by the RAs it sends) is very unlikely that there will be a DHCPv6 
> > server either (or it won't be reachable because the router is down).  If the 
> > "m" and/or "o" bits are set in a RA, it is a pretty good hint that a host 
> > might try to use DHCPv6 and see what it gets.  If the "m" or "o" bits are not 
> > set, then it's a pretty good hint that there isn't much sense in trying to 
> > use DHCPv6.
> 
> Actually, the lack of M or O bits is not as good a hint as their 
> existence.  If we wanted a _good_ hint about non-existence of DHCPv6 
> (for addresses or config information), we'd have to have different 
> flag(s) like "Yes, I'm aware of what DHCPv6 is, but we don't use it in 
> this network".  That allows disambiguation from "Yes, we do have a 
> couple of DHCPv6 servers, but we weren't aware you should configure 
> this stuff in the RAs, because with v4 you don't".
> 
> But I'm not sure that disambiguation is worth the effort.
> 
> That said, I support the clarification.  In a sense I agree with 
> Thomas et al that the ra-mo-flags spec goes beyond the bare minimum 
> what the IETF specifications must specify -- it documents the policies 
> and behaviours which most vendors would implement in any case, but 
> these kind of knobs have often been left out of our specs.  However, 
> as there has been so much confusion and discussion of M/O flags, I 
> think this specification is useful, and also allows vendors (who want 
> to) to implement the knobs in a uniform manner.

I'll have to re-read the draft, but I think that documenting the M/O bits
sufficiently so that nodes and networks will be able to interoperate
in a reasonable way.  Documenting the basic policies and rules, IMO,
are a good thing.  Would a BCP-type document be a reasonable way to 
achieve this?

John

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 23 May 2005 14:53:46 -0400

Make that 200 %.

Hesham

 > From: [email-masked] [mailto:[email-masked]]On 
 > Behalf Of
 > Ralph Droms
 > Sent: Monday, May 23, 2005 2:47 PM
 > To: [email-masked]
 > Cc: [email-masked]; Bob Hinden; [email-masked]
 > Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt
 > 
 > 
 > Tim - I agree 100% with your message.
 > 
 > - Ralph
 > 
 > On Mon, 2005-05-23 at 10:09 -0700, Tim Hartrick wrote:
 > > 
 > > Bob,
 > > 
 > > On Mon, 2005-05-23 at 09:48, Bob Hinden wrote:
 > > > 
 > > > Part of me is starting to think that we might be better 
 > off waiting for 
 > > > there to be more operational experience with deployments 
 > of DHCPv6 to see 
 > > > how much confusion there really is.  I agree it is good 
 > for vendors to 
 > > > implement similar knobs, but I wonder how much of a 
 > problem there really is.
 > > > 
 > > 
 > > More than part of me is thinking this.  It seems to me 
 > that there is a
 > > continuing confusion about how these bits interact with 
 > local decisions
 > > by the administrator of a specific machine or network.  People are
 > > asking questions like "What happens if the M and/or O bits 
 > are clear but
 > > there is a DHCP server?" or "What happens if the M and/or 
 > O bits are
 > > clear but the client wants to use DHCP anyway" or "What 
 > happens if the M
 > > and/or O bits are set and the client doesn't want to run 
 > DHCP".  None of
 > > these questions are in the realm of protocol design.  
 > Clearly, local
 > > administrators will do as they please with their machines.  In this
 > > respect the M and O bits have never been anything but 
 > strong hints as to
 > > what the client should do.  The client is always free to ignore the
 > > hints.  Further network administrators are free to 
 > misconfigure their
 > > networks as they please.  The current text describing these bits is
 > > clear almost to the point of being infantile.  This isn't 
 > an indictment
 > > of the authors.  Rather it is an indictment of attempts to enforce
 > > system configuration and management rules via protocol 
 > specifications. 
 > > This is impossible.  We should stop trying.
 > > 
 > > 
 > > 
 > > 
 > > tim
 > > 
 > > 
 > > 
 > > Administrative Requests: 
https://www1.ietf.org/mailman/listinfo/ipv6

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 23 May 2005 15:16:03 -0400

Bob,

THere is no problem.  The site owns the router configuration and the
network admins are gods of rules.  If the site sets the m bit the client
is told go look for dhcpv6. if not set don't bother.  If o set go look
for configs.  Pretty simple and I suspect people are looking for  away
to avoid clients obeying the mandate from the router and the site. We
should not support that at all or work on it.  The rules are clear.

thanks
/jim 

> Behalf Of Bob Hinden
> Sent: Monday, May 23, 2005 12:49 PM
> To: Pekka Savola
> Cc: [email-masked]; [email-masked]
> Pekka,
> >existence.  If we wanted a _good_ hint about non-existence 
> of DHCPv6 (for 
> >addresses or config information), we'd have to have 
> different flag(s) like 
> >"Yes, I'm aware of what DHCPv6 is, but we don't use it in this 
> >network".  That allows disambiguation from "Yes, we do have 
> a couple of 
> >DHCPv6 servers, but we weren't aware you should configure 
> this stuff in 
> This still seems to be to be fairly equivalent.  I think the 
> important 
> function is if there is a DHCPv6 server and the site want the 
> clients to 
> use it, then they should set the "m" and "o" bits.  I don't 
> see very much 
> value in conveying the negatives (e.g., we have a DHCPv6 
> server, but we 
> don't want the clients to use it, we don't have a DHCPv6 
> server so don't 
> try looking for one, we didn't set up a relay, etc., etc.).
> 
> Agreed.
> >That said, I support the clarification.  In a sense I agree 
> with Thomas et 
> >al that the ra-mo-flags spec goes beyond the bare minimum 
> what the IETF 
> >specifications must specify -- it documents the policies and 
> behaviours 
> >which most vendors would implement in any case, but these 
> kind of knobs 
> >have often been left out of our specs.  However, as there 
> has been so much 
> >confusion and discussion of M/O flags, I think this specification is 
> >useful, and also allows vendors (who want to) to implement 
> the knobs in a 
> >uniform manner.
> 
> Part of me is starting to think that we might be better off 
> waiting for 
> there to be more operational experience with deployments of 
> DHCPv6 to see 
> how much confusion there really is.  I agree it is good for 
> vendors to 
> implement similar knobs, but I wonder how much of a problem 
> there really is.
> 
> Bob
> 
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 23 May 2005 15:18:05 -0400

Well stated and with this can we please stop there is no other point to
discuss. For those that don't like stateful don't use it.  For those
that don't like stateless your stuck with it by default set the m and/or
o bits.  

thanks
/jim 

> Behalf Of Tim Hartrick
> Sent: Monday, May 23, 2005 1:09 PM
> To: Bob Hinden
> More than part of me is thinking this.  It seems to me that there is a
> continuing confusion about how these bits interact with local 
> decisions
> there is a DHCP server?" or "What happens if the M and/or O bits are
> these questions are in the realm of protocol design.  Clearly, local
> respect the M and O bits have never been anything but strong 
> hints as to
> hints.  Further network administrators are free to misconfigure their
> clear almost to the point of being infantile.  This isn't an 
> indictment