Subject: Re: [dhcwg] IMPORTANT - Re: Question on 6204bis

From: Ole Troan <[email-masked]>
Date: Mon, 5 Dec 2011 21:21:40 +0100

Barbara,

[please move this to the DHC working group (cc'ed)]

>> 1) Scoping of the NoAddrsAvail in the IA_* options. Dealt with in the
>> existing errata
>> 2) Change of SOLICIT timer (Dealt with in Ralph's draft)
>> 3) The other unclear problem area is around how to deal with IA_PD and
>> IA_NA:
>>   * Client requests both IA_NA and IA_PD in the same session, gets
>> only IA_PD.
>>      - Does it fork off a separate session for IA_NA and continues
>> sending SOLICITs for only the IA_NA?
>>      - Reset the DHCP client, and tries again?
>>      - Keeps single session, and continues to ask for IA_NA on next
>> RENEW?
> 
> I agree with the statement made in 1. I agree that 2 is not a part of
> 6204bis and hope that Ralph's draft is successful.
> 
> As for 3, I'm confused as to the problem.

CPE requests both IA_NA, IA_PD. the DHCP server has a policy to only give out e.g. IA_PD.
this also applies in the case where a client requests both IA_NA and IA_TA...
the DHCP specifications do not describe how a client should behave in this case.

cheers,
Ole

> We have an unnumbered model that is defined that describes the desired
> behavior for a device that gets only IA_PD (WAA-7, not to be confused
> with WPD-7). The device takes an address for itself from the delegated
> prefix, and puts it on some non-WAN interface (internal or LAN). It's
> happy. I would not expect it to continue sending SOLICITs or to reset
> the DHCPv6 client. I don't care if it asks for IA_NA on RENEW. The
> server should be able to handle it either way. As should the client. No
> need to specify "don't cares".
> 
> We also have an exclusion to the unnumbered model, that requires devices
> to support the unnumbered model unless they are configured to require a
> global IPv6 address on the WAN (also in WAA-7). I've argued against
> providing more detail about this configured mode, and will continue to
> do so. It is up to the organizations (e.g., CableLabs) defining such a
> configured mode, to also define the desired behavior for what the CE
> router does when it doesn't get a global IPv6 address on the WAN
> interface. I don't see that 6204bis needs to address this. 6204bis can
> acknowledge the existence of configured modes, without needing to
> specify them. Implementing special configured modes is not a requirement
> of 6204 or 6204bis, which means the doc doesn't need to say how to do
> them.
> 
> Note that a DHCPv6 server and the access network have to be able to
> handle devices that support the unnumbered model, if the provider
> intends to allow any non-SP-procured devices on that access network. I
> consider that reasonable. If the access network / DHCPv6 server hands
> out IA_PD but not IA_NA, I don't see why it should somehow not allow
> traffic from the delegated prefix to be properly routed. If it routes
> traffic from/to that prefix, then I don't see what the problem is. If it
> won't be routing that traffic to/from that prefix, then it shouldn't be
> handing out the prefix. 
> 
> The "unnumbered model" CE router will think it's up and running, per
> 6204 and 6204bis, and it's a naughty access network that lets it believe
> this, if this isn't true. The "configured" CE router will do whatever
> the configuration specifiers tell it to do. This "configured mode" isn't
> something dhc wg or 6204bis needs to deal with. There's nothing in any
> of the dhc RFCs or errata that prohibits existence of such a configured
> mode. Which means it's allowed, and other orgs are free to specify it
> and specify how it works in their devices.
> Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 5 Dec 2011 16:04:19 -0500

> the DHCP specifications do not describe how a client should behave in

Which, per 6204 and 6204bis results in the unnumbered model being
utilized. Unless (per 6204bis) the device is configured to require a
global address on its WAN. Then the device does whatever the specifiers
of that configuration tell it to do.

I don't see a problem. And I don't see a need for dhc wg to specify
additional client behavior. Per the lack of current guidance in dhc RFCs
and errata, device designers/profile specifiers/etc. are free to specify
how they want their devices to behave when they get one IA and not
another. They are free to design devices that don't do SLAAC and request
IA_NA and go belly-up if no IA_NA, if that's consistent with the
environment where the devices will operate. Or not. Or requests IA_NA
and IA_TA and are happy with either, but not both. Or are only happy
with both. Or really don't care if they get either one (maybe because
they tried SLAAC, too, and got something there). They can design devices
that can tolerate getting an address by SLAAC and/or IA_NA or
unnumbered. Or that require IA_NA. Or that require SLAAC and ignore all
M bits and never to DHCPv6 (and I think there's quite a few of those).
And that's exactly what 6204(bis) is doing. It's taking a particular
environment and defining device behavior that will work in that
environment, and consistent with protocol standards. It is as it should
be. The protocol standards do not need to be over-specified. 

But the errata are needed. A NoAddrsAvail needs to be specific to an IA,
and not preclude the sending of one IA but not another.
Barbara