Re: [dhcwg] WGLC on draft-ietf-dhc-v4configuration-04 - respond by Jan. 31

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

I support this document moving forward.

I do have some issues that should be addressed before advancing though. (Sorry if this may duplicate already reported issues.)

The Abstract says "recommends a single approach", but aren't we technically recommending two (i.e., DHCPv4 'as is' and DHCPv4-over-DHCPv6 when IPv4 packets are not possible). It isn't clear to me that the initial part of the abstract limits the 'single approach' to the case where IPv4 communication is not possible? Perhaps just change "a single approach" to "approaches"?

Also, the Introduction (last paragraph) says "compares four different", but the document has 5 approaches in section 3 (Comparison of Five Approaches). Section 1.1 discusses 4 approaches - it seems that "DHCPv4oSW" (see 3.4) is missing? And, these is no 1.x section for this either (should be inserted as new section 1.4 to match order in Section 3). Note also that section 1.1 "At time of this writing" paragraph mentions two + two = 4, so that text will have to be updated as well to include all 5 approaches?

Section 3 is titled "Comparison of the Five Approaches" but Table 1 has only 4.

I guess I will just recommend that you go through the draft carefully to make sure that the text is aligned with the actual number of approaches presented (or clarify when / why you eliminate an approach from further analysis).

Please also clean up the Table of contents for section 5 as there are extra spaces between DHCPv4 and Messages (this is probably because of how the text appears in the <section title=...> in the xml document).

Minor nit may be to add something to section 7. (Security Considerations) that this document just analyzes the various solutions and doesn't introduce any new capabilities that have additional security considerations (or something like that)? Might avoid an IESG comment about clarifying that?


I still have more of the document to review ... sending this off now as I need to step away for a bit. Hopefully more later today or tomorrow (also what remains requires a more technical review/thought).

---

One other point regarding Ole's comments below - Ole, I don't think it would be possible to handle IPv4 configuration by just adding a DHCPv6 DHCPv4 container option to encode the various v4 options as some of the information is conveyed in non-option fields in the DHCPv4 (BOOTP) packet. Yes, you could have an option that has those fixed fields followed by a variable length option encoding area, but that seems much more complex than just encoding the DHCPv4 packet (as we are proposing to do with the new DHCPv6 messages). Also, encoding as an option of options would also require piggybacking the request with DHCPv6 requests themselves which has other implications -- so I think that design, while possible, is much less optimum (though we can certainly disagree on this point).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[e-mail]] On Behalf Of Ole Troan
Sent: Tuesday, January 28, 2014 8:01 AM
To: <[e-mail]>
Cc: DHC WG
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-v4configuration-04 - respond by Jan. 31

Ian,

>> with regards to protocol stack. UDPv6 is not a protocol. just use UDP.
>> and I think you can remove the tunnel encapsulation from your 
>> protocol stack, especially since some of the softwire mechanisms use 
>> translation.
>> just like you don't have the L2 header on the native packets either.
> 
> [ian] I think it¹s more meaningful to go the other way and extended 
> the stack diagrams to show where there are differences between tunnel 
> and translation to try and give a more complete picture with all of 
> the L3,4,5 headers. These vary between the solutions and between 
> tunnel/translation. The L2 headers don¹t.

the tunnel is a L2. I don't think you need to include that virtual L2 in the stack diagrams.

>> in section 1.4:
>> Broadcast based DHCPv4
>> DHCPDISCOVER messages (necessary for IPv4 address assignment) can not 
>> be transported as they are not compatible with the existing, unicast 
>> based softwire architecture.
>> 
>> I don't think this claim is correct. I don't see good reasons why 
>> DS-lite couldn't (or doesn't already) support broadcast.
> 
> 
> [ian] A DS-Lite may have a relay, or could be extended to be a relay, 
> but there is nothing in the existing RFC that states that an AFTR has 
> this function, so it can¹t be expected.

that's a deployment choice, and nothing that's required to be in an RFC.
ds-lite is an 'normal' point to point tunnel as far as IPv4 forwarding is concerned.

> What about changing the wording to:
> 
> Existing softwire architectures do not define how broadcast based 
> DHCPv4 DHCPDISCOVER messages (necessary for IPv4 address assignment) 
> should be handled.

I wouldn't state it so broadly.
I would say that not some of the softwire mechanisms implement NBMA links, where broadcast isn't supported, and A+P in general have open issues with regards to using fixed ports, when the IP address is shared among multiple users.

>> 
>> section 2:
>> I don't understand bullet 7. more detail?
> 
> [ian] From your earlier suggestion, I¹ve updated a paragraph in the 
> intro to read:
> 
> "Although IPv4-in-IPv6 softwire tunnel and translation clients are
>      currently the only use-case for DHCP based configuration of IPv4
>      parameters in IPv6 only networks, a suitable IPv4 provisioning 
> solution
>      should not be limited to only supporting the configuration of 
> softwires,
>      or be bound to specific IPv4 over IPv6 architectures or mechanisms.
> The
>      solution needs to be flexible enough to support new IPv4 over IPv6
>      technologies as they are developed."
> 
> 
> Between this and the existing wording of requirement 7 -
> 
> "Not restricted to specific IPv4 over IPv6 transport mechanisms or
>       Architectures"
> 
> I think the intension behind the requirement is pretty clear. Does 
> that work?

OK, perhaps I disagree with the intention of this then.
we're creating this whole thing, just because we want the flexibility for something that may be invented in the future?
given that it is for IPv4, that seems a little unnecessary.
no-one has a single example where this requirement actually matters now?

> ----------------------------
> 
>> 
>> 3.2.1 (4) I don't think existing implementations of carrying DHCPv4 
>> options exist.
>>            if anyone really really wanted to go down this route, you 
>> could just create an DHCPv6 encapsulation option
>>            for all DHCPv4 options. that way you don't need to port 
>> all options.
> 
> [ian] Creating a DHCPv6 encapsulation (message type & option) for 
> transporting DHCPv4 is what DHCPv4oDHCPv6 is.

you encapsulate the "messages", I said you could encapsulate the "options".

>> 3.2.2     it doesn't have to be tied to the DHCPv6 leasetimes (whatever
>> is meant by that).
>>           IPv4 addresses could have its own IA, or be treated as such.
>> anyway, I'm not suggesting this route.
> 
> [ian] This is the point (and what the text says). To decouple DHCPv6 
> prefix and IPv4 lease lifetimes, you would need to add a new, 
> dedicated
> IPv4 lease lifetime mechanism to DHCPv6 (such as a v4 IA with it¹s own 
> timers).

OK, you may want to make that text clearer then.

>> 
>> 3.3.2: I suggest you remove the unproven bullet 9. isn't that just a 
>> matter of testing it out with an existing implementation?
>>        with regards to bullet 8. I suggest a separate section where 
>> you describe softwire behaviour.
>>        _all_ proposed softwire mechanisms are hub and spoke, with 
>> regards to traffic outside of the softwire domain.
>>        which makes bullet 8 read a little strangely, given that no 
>> mechanism is restricted by it.
> 
> [ian] The draft not linked exclusively to softwires. A pure mesh is a 
> possible architecture, even if no examples are currently standardised.

what's a pure mesh?

>> shouldn't section 3.4 be removed? given that that method is described 
>> in section 5.
>> 
>> section 3.5.2:
>> add a cons about communication between the DHCPv6 and DHCPv4 server, 
>> presumably these need to be directly connected? or there must be an
>> DHCPv4 relay directly connected to the DHCPv6 server. _or_ is the 
>> expectation here that the DHCPv4 and DHCPv6 servers must be 
>> co-located on the same host? if so, state that.
>> 
>> section 5:
>> the title is wrong. I suggest: Transporting DHCPv4 messages over an 
>> IPv4 capable softwire"
>> the tunnel is the link-layer. a link-layer that offers IPv4 transport.
> 
> [ian] The rest of the doc tries not to link the v4 provisioning 
> recommendation to only softwires, and the recommendation in the intro 
> is not limited to using unmodified DHCPv4 only for softwires. To keep 
> it aligned, either the intro recommendation should be changed, or the 
> title of section 5 shouldn¹t limit it.

I don't think there is anything in my proposal that links v4 provisioning to a particular L2 either.
it does set some requirements on the behaviour on that L2 though.

again, without some real examples I think it is quite meaningless to talk about v4 provisioning outside the context of a IPv4 capable link-layer.

cheers,
Ole