Subject: Re: [Softwires] [softwire] #28: Dealing with DHCPv4-over-DHCPv6

From: Cong Liu <[email-masked]>
Date: Fri, 1 Nov 2013 17:11:41 +0800

Dear Ole,

2013/10/30 Ole Troan <[email-masked]>

> MAP is incompatible with dynamic IPv4 address assignment using DHCPv4.
>

Yes, dynamic IPv4 address assignment is only used by lw4o6. But
OPTION_S46_IPV4ADDRESS
in map-dhcp-05 is also proposed for only lw4o6,
so I think it's not a problem to have a discussion of dynamic IPv4
provisioning.

> either you can consider MAP DHCP as the building block used by a separate
> document describing the
> DHCPv4 address assignment case. or we can split out LW46 provisioning from
> MAP DHCP altogether.
>

I think the key problem here is the scope of the document: whether
"softwire-dhcp" discussing both static and dynamic IPv4 provisioning,
or "stateless-softwire-dhcp" discussing only static provisioning. I'm just
suggesting "softwire-dhcp" solution.

Best Regards,
Cong

---

From: Ole Troan <[email-masked]>
Date: Fri, 1 Nov 2013 12:27:44 +0100

> Yes, dynamic IPv4 address assignment is only used by lw4o6. But OPTION_S46_IPV4ADDRESS in map-dhcp-05 is also proposed for only lw4o6,
> so I think it's not a problem to have a discussion of dynamic IPv4 provisioning.
>  
> either you can consider MAP DHCP as the building block used by a separate document describing the
> DHCPv4 address assignment case. or we can split out LW46 provisioning from MAP DHCP altogether.
> 
> I think the key problem here is the scope of the document: whether "softwire-dhcp" discussing both static and dynamic IPv4 provisioning,

to nitpick, MAP DHCP is also dynamic by the way, just that the IPv4 address lifetime is equal to the IPv6 prefix lifetime.

> or "stateless-softwire-dhcp" discussing only static provisioning. I'm just suggesting "softwire-dhcp" solution.

I would be in favour of having separate drafts, that can be combined to create more complex solutions.

if you want the LW46 mechanism to be fully described in one provisioning document, then I would be in favour of doing that in a separate document, and remove the existing LW46 text from MAP DHCP.

cheers,
Ole

(and please don't read from this that I support doing DHCPv4 address assignment for these mechanisms, I am far from convinced that it is needed).

---

From: Qi Sun <[email-masked]>
Date: Fri, 1 Nov 2013 21:11:40 +0800

Dear Ole,

Please see inline.

> to nitpick, MAP DHCP is also dynamic by the way, just that the IPv4 address lifetime is equal to the IPv6 prefix lifetime.

[Qi] IMO, map-dhcp has an assumption that the mapping between IPv4 address and IPv6 prefix is pre-determined, which is a static mapping. But that assumption is not always true. We should allow flexibility for the users to use a dynamic mapping.

> I would be in favour of having separate drafts, that can be combined to create more complex solutions.

[Qi] If one draft can make it clear, I don't think we need a combination.

> (and please don't read from this that I support doing DHCPv4 address assignment for these mechanisms, I am far from convinced that it is needed).

[Qi] There are requirements for it. And it follows DHC's consensus. 

Thanks,
Qi

> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Ole Troan <[email-masked]>
Date: Fri, 1 Nov 2013 14:51:49 +0100

Qi,

> [Qi] IMO, map-dhcp has an assumption that the mapping between IPv4 address and IPv6 prefix is pre-determined, which is a static mapping. But that assumption is not always true. We should allow flex…

yes, MAP has that assumption.

> [Qi] If one draft can make it clear, I don't think we need a combination.

I think the difference is that MAP-DHCP is really there to provision the link-layer (tunnel).
if we follow the principle (that I also stated to Ted), that DHCPv6 is used to provision the link-layer,
and DHCPv4 is used to provision the IPv4 layer. then I think the "fallout" of that should be
that we'd remove the OPTION_S46_IPV4ADDRESS from the MAP DHCP draft.
are you fine with that approach?

> [Qi] There are requirements for it. And it follows DHC's consensus. 

I don't think it is appropriate for you to declare DHC WG consensus. in any case this would have to be consensus in softwires, wouldn't it?

cheers,
Ole