Re: [dhcwg] Fwd: New Version Notification for draft-troan-dhc-dhcpv4osw-00.txt

[<[e-mail]>]

Hi Ole,

I'm just doing an update to draft-ietf-dhc-v4configuration. Could you have
a look through the DHCPv4oSW relevant sections and see if you think that
any changes need to be made based on your draft / this discussion?

Cheers,
Ian




On 13/06/2013 11:29, "Ole Troan" <[e-mail]> wrote:

>Ian,
>
>> Thinking a little further on this, there's a bigger problem here. The
>>DHCP
>> relay in the BR can catch the broadcast DHCP messages for address
>> allocations and create MAPping rules accordingly. However, the DHCP
>> release mechanism is unicast based, so how does remove the MAPping rules
>> once the DHCPv4 lease is no longer valid? Also, what about addresses
>>that
>> don't get cleanly released and expire in the DHCPv4 server?
>> 
>> To fix this, either the DHCPv4 server has to be co-located in the BR, or
>> there's going to need to be a lot of DPI on DHCP unicast messages
>>passing
>> through the BR, with corresponding lifetimes attached to the MAP rules.
>
>the DHCPv4 relay _could_ force all DHCP traffic to go through itself, by
>rewriting the server id.
>that's apparently quite common, see RFC5107.
>
>you do bring up a good point though; a stateful relay is really at odds
>with the MAP architecture of stateless BRs
>where CEs use anycast to get to them.
>any time you want redundancy you'd have a problem.
>
>(to others following the discussion, we're now discussing the case of
>LW46 with complete indepdence
>between IPv6 and IPv4 address, and where there is also no dependency
>between IPv6 provisioning
>and IPv4 provisioning. none of this matter of course, if you just use
>DHCPv4 to get other configuration
>information)
>
>an out of band mechanism to populate per subscriber LW46/MAP state, would
>allow for stateless DHCP relays.

[ian] I think that the problem here is because successful softwire
provisioning in the BR is fundamental to how this works, then it's not
enough to say that an out of band mechanism will take care of this. It
needs to be covered

It does also mean that DHCPv4 over softwire is linked to having a
softwire. If another (non-softwire) reason for needing to provision IPv4
over and IPv6 native network appears in the future, then it's going to
need a softwire deployment.

>
>btw: force renew, that's not something generally used is it? cause
>supporting that I think would require the server to
>include the client's UDP port in the binding, while otherwise it would
>not be required.

[ian] I don¹t have any plans for using force renew. You can generally get
enough control with lease lengths.

>
>cheers,
>Ole
>