RE: [dhcwg] Re: IPv6 WG Last Call:draft-ietf-ipv6-ra-mo-flags-01.txt

["Bernie Volz \(volz\)" <[e-mail]>]

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


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Bernie Volz (volz)
> Sent: Tuesday, May 17, 2005 3:41 PM
> To: timothy enos; Pekka Savola
> Cc: [e-mail]; JINMEI Tatuya / ????; IPv6 WG; Ralph 
> Droms (rdroms)
> Subject: RE: [dhcwg] Re: IPv6 WG Last 
> Call:draft-ietf-ipv6-ra-mo-flags-01.txt
> 
> 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
> 
> > -----Original Message-----
> > From: timothy enos [mailto:[e-mail]] 
> > Sent: Monday, May 16, 2005 10:00 PM
> > To: Bernie Volz (volz); 'Pekka Savola'
> > Cc: [e-mail]; Ralph Droms (rdroms); 'IPv6 WG'; 'JINMEI 
> > Tatuya / ????'
> > Subject: RE: [dhcwg] Re: IPv6 WG Last 
> > Call:draft-ietf-ipv6-ra-mo-flags-01.txt
> > 
> > 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
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On 
> > Behalf Of
> > Bernie Volz (volz)
> > Sent: Monday, May 16, 2005 5:20 PM
> > To: Pekka Savola
> > Cc: [e-mail]; Ralph Droms (rdroms); IPv6 WG; JINMEI 
> > Tatuya / ????
> > Subject: RE: [dhcwg] Re: IPv6 WG Last
> > Call:draft-ietf-ipv6-ra-mo-flags-01.txt
> > 
> > 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 
> > 
> > > -----Original Message-----
> > > From: Pekka Savola [mailto:[e-mail]] 
> > > Sent: Monday, May 16, 2005 5:09 PM
> > > To: Bernie Volz (volz)
> > > Cc: JINMEI Tatuya / ????; [e-mail]; IPv6 WG; Ralph 
> > > Droms (rdroms)
> > > Subject: RE: [dhcwg] Re: IPv6 WG Last 
> > > Call:draft-ietf-ipv6-ra-mo-flags-01.txt
> > > 
> > > 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
> > > 
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg