Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

[Ole Troan <[e-mail]>]

Ian,

> OK, so what about the following text?

yes, that seems along the right lines.
you may want to create some indirection between the main protocol specification and the DHCP provisioning document, like we talked about (and did for MAP) back in Berlin.

cheers,
Ole

> 
> For DHCPv6 based configuration of these parameters, the lwB4 SHOULD
> implement OPTION_S46_CONT_LW as described in section 6.3 of
> [I-D.ietf-softwire-map-dhcp].  This means that the lifetime of the
> softwire and the derived configuration information (e.g. IPv4 shared
> address, IPv4 address) is bound to the lifetime of the DHCPv6 lease.
> If stateful IPv4 configuration or additional IPv4 configuration
> information is required, DHCPv4 [RFC2131] must be used.
> 
> Although it would be possible to extend lw4o6 to have more than one active  
> lw4o6 tunnel configured simultaneously, this document is only concerned with 
> the use of a single tunnel.
> 
> On receipt of OPTION_S46_CONT_LW, the lwB4 performs a longest prefix match 
> between the IPv6 prefix contained in OPTION_S46_IPV4ADDRESS and its currently 
> active IPv6 prefixes. The result forms the subnet to be used for sourcing the 
> lw4o6 tunnel. The full /128 prefix is then constructed in the same manner as 
> [I-D.ietf-softwire-map].
> 
> If the longest prefix match returns more than one matching prefix, then an
> implementation specific tie-breaker MUST be performed to return a single prefix.
> If no matching prefix of the same IPv6 scope (as described by [RFC4007]), then
> the lwB4 MUST NOT attempt to configure the softwire tunnel interface.
> 
> ———————————
> Obviously, there would need to be the relevant changes to the map-dhpc draft in line with the above.
> 
> Cheers,
> Ian
> 
> On 6 Mar 2014, at 13:37, Ole Troan <[e-mail]> wrote:
> 
>> Ian,
>> 
>>> It really depends on what you mean by 'the wheel' in this context…
>>> 
>>> But, as a proposal, if we extend (and maybe rename) OPTION_L46_IPV4ADDRESS with new fields for prefix6-len and ipv6-prefixes to be used for a LPM, would this meet your definition of a wheel?
>> 
>> pretty much. my point was that we use the same wheel if we can.
>> if you have invented a better wheel, then I would like to use it in MAP-E as well.
>> 
>> cheers,
>> Ole
>>