Le 2013-11-15 09:01, Ole Troan a écrit :
if optional, we have to think through the corner cases:
  - how does a CPE know when to initiate DHCPv4 (or PCP)?

I would propose: when OPTION_S46_IPV4ADDRESS is absent.

DHCPv4 or PCP? Whichever one the CPE wants to try, or even both. We don't need 
to signal this.

  - can a CPE end up with an IPv4 address provisioned both with 
OPTION_S46_IPV4ADDRESS
    and DHCPv4 (and PCP)?

Proposal: no. When OPTION_S46_IPV4ADDRESS is present, you shall not do DHCPv4. 
PCP is still OK, since it doesn't technically assign an address to the 
interface, it merely informs the CPE of an existing stateless mapping (which 
may be the same as the one provisioned with OPTION_S46_IPV4ADDRESS).

  - what does the CPE do with IPv4 addresses with longer lifetimes than the 
softwire?

Shouldn't happen with my proposal above.

yes, I think this makes a lot of sense.
paraphrasing:

- one of the containers are _always_ used to provision the softwire
- the absence of IPv4 address option in the LW46 container triggers DHCPv4
- we can ignore PCP for now

Nah, PCP is too easy to ignore. :) PCP can always be tried on any interface. Doesn't matter if this is LW4o6 or whatever else. PCP is PCP, just try it and see if you get anything back.

if the client requires other configuration information it can do DHCPv4 as it 
wish.

Right.

If I was implementing a CPE I would unconditionally do DHCPv4oDHCPv6. If I have to implement the code anyway, why not always exercise it? Thus my question: do we really need OPTION_S46_IPV4ADDRESS? If CPEs do DHCPv4oDHCPv6 all the time anyway, we don't really need it.

the only change required is to make the IPv4 address option in MAP-DHCP 
optional.
(assuming there isn't consensus to drop it altogether.)

Yup.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to