Subject: Re: purpose of m/o bit

From: "da Silva, Ron" <[email-masked]>
Date: Thu, 26 May 2005 16:24:31 -0400

There are nine scenarios, right?

1) RA w/auto-conf, M off, O off
2) RA w/auto-conf, M on, O off
3) RA w/auto-conf, M off, O on
4) RA w/auto-conf, M on, O on
5) RA w/o auto-conf, M off, O off
6) RA w/o auto-conf, M on, O off
7) RA w/o auto-conf, M off, O on
8) RA w/o auto-conf, M on, O on
9) No RA

>From a cable deployment perspective, I would expect...

1) CM stateless auto-conf from advertised route(s)
2) CM stateless auto-conf from advertised route(s) plus DHCPv6 for
additional address(es)
3) CM stateless auto-conf from advertised route(s) plus DHCPv6 for
addition info
4) CM stateless auto-conf from advertised route(s) plus DHCPv6 for
additional address(es) and additional info
5) same behavior as #9 below ?
6) DHCPv6 for address(es) only
7) DHCPv6 for additional info only
8) DHCPv6 for address(es) and additional info
9) CM stateless auto-conf link local address followed by DHCPv6 for
additional address(es) and/or other info (same behavior as #5)

This seems way to complicated though, and it would be much more
deterministic for a CM to simply do #4 in all cases which would make the
M/O bits useless.

-ron

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 26 May 2005 23:34:04 +0200

> deterministic for a CM to simply do #4 in all cases which would  

You know what's really deterministic? Manual configuration.

There is a baby in this bath water...

The problem with having different bits indicate different  
capabilities is that you get lots of permutations. So when a  
significant number of those don't make sense, having individual bits  
probably isn't the right choice.

To me, assuming the current specs, the following would make sense:

Configured for always-full-DHCPv6 on this interface? -> yes -> do  
full DHCPv6
   |
  no
   |
Timeout waiting for RAs? -> yes -> do full DHCPv6
   |
  no
   |
M bit set or no prefixes with AAC set? -> yes -> do full DHCPv6
   |
  no
   |
O bit set or always-stateless-DHCPv6 on this if? -> yes -> stateless  
DHCPv6

A stateless DHCPv6-only client would probably just look at the O bit  
and not do stateless DHCPv6 if just the M bit is set.

Anyone believe that, with current knowledge and experience,  
implementing the above would be a bad idea?

Please realize that even if something isn't useful in _your_ use  
case, that doesn't mean it's never useful. It's very important that  
people can open up their laptops, PDAs, smartphones and whathever,  
and it can talk to the local network _without_ _special_  
_configuration_. I.e., I want to be able to bring my laptop to work  
where DHCPv6 is the only game in town, check my mail using a public  
hotspot over coffee with just stateless autoconfig and then go home  
and connect to my broadband connection using whatever comes out of  
the wall. And all this without having to change any settings.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 26 May 2005 19:05:29 -0400

Seems to me I'm hearing two requirements out of this thread:

1) Ability to indicate to a host "DHCP is not available on this link",
   with the expectation that the host won't send any DHCP messages

2) Ability for a host to get all desired and available DHCP
   configuration with a single DHCP message exchange
   - if a host wants HCB, it sends an HCB request (Solicit) and receives
     HCB and/or ICB replies
   - if a host wants ICB, it sends an ICB request (Information-request) 
     and receives ICB replies

1 is a requirement in scenarios with limited resources (e.g., wireless),
where polling for DHCP is unacceptable.  2 is a requirement to avoid
timeout delays or other complexity in getting ICB reply when host would
prefer HCB reply.

If I've got that right, we can meet the two requirements with a couple
of small updates to existing specs:

1) If an RA is received with the M and/or the O bit is set, DHCP
   service is available over the link through which the RA was received
   (no differentiation between HCB and ICB DHCP)

2) If a DHCP server receives an HCB request (Solicit) but can only
   supply an ICB, the server can respond with the ICB reply (note that
   according RFC 3115, the server would respond with an "HCB-nak"
   [Advertise containing only an error code])

In addition to meeting the requirements, these updates are mostly (if
not entirely) operationally compatible with existing clients and
servers.

- Ralph

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 May 2005 10:30:32 -0700

>    - if a host wants ICB, it sends an ICB request (Information-request) 

I the case where the network admin wants to do stateless address 
autoconfiguration and has DHCP available for ICB, how inefficient will 
the above be?

Wouldn't this mean that the hosts which are implemented to handle HCB as 
well as ICB, would always try with a Solicit i.e. they would end up 
doing a 4 packet DHCP exchange. Had the host known that HCB was not 
available, a 2 packet exchange would have been sufficient.

Thinking about hosts moving between different links, the difference 
between 4 and 2 packets for DHCP ICB might matter.

Hence my question how useful it would be to have
3) Ability for the host to find out from the RA that it doesn't need to 
bother with HCB since only ICB is available on the network.

    Erik

---

From: Ralph Droms <[email-masked]>
Date: Fri, 27 May 2005 14:10:24 -0400

Erik - the idea is to allow a client to initiate either HCB or ICB with
the same message, which turns into a 4 message exchange for HCB (2
messages w/ "rapid commit") or 2 message exchange for ICB.

- Ralph