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

["ian Farrer" <[e-mail]>]

Hi Ole,

OK, hopefully a final cut of the wording.

Cheers,
Ian

-----
In lw4o6, a number of lw4o6 specific configuration parameters must be
provisioned to the lwB4. These are:

 o IPv6 Address for the lwAFTR

 o IPv4 External (Public) Address for NAPT44

 o Restricted port-set to use for NAPT44

 o IPv6 Binding Prefix

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 the necessary configuration parameters, the lwB4 performs a
longest prefix match between the IPv6 binding prefix 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].
---
----- Original Message -----
From: Ole Troan
Sent: 03/06/14 04:34 PM
To: Ian Farrer
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

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 ma
 tch > 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 >>