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

[Ole Troan <[e-mail]>]

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