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

[<[e-mail]>]

Hi Woj,

Thanks for the review. Inline are some comments specifically related to your points on the new text that's been added since WGLC.

Cheers,
Ian

Detailed comments:

* Section 5.1 WAN prefix selection and address forming - as per Ole's comment. This is indeed hand wavy in the current draft (how to select the WAN?)

[ian] I've updated with the wording that I proposed to Ole.
The CPE WAN interface is a fairly well used term in a number of other RFCs. Both RFC6333 and RFC7084 use the term (and have implementations based on them) without defining how the CPE has identified it. Why does that need to be specifically defined here?

* Processing of IPv4 fragments Section 5.2. Text " The lwB4 MAY require that the UDP, TCP, or ICMP header be completely contained within the fragment that contains fragment offset equal to zero."
What does that mean? Is it trying to say that the IPv4 MTU > 40?

[ian] The text is taken directly from RFC6146. I guess that doesn't specify is as a defined MTU size of > 40 bytes (or anything else) as the IPv4 header could feasibly be longer than 20 bytes if options were included in it, so the fragmented L4 header problem could still exist.

Section 5.2: "

For incoming packets carrying TCP or UDP IPv4 fragments with a non-

   zero checksum, after de-capsulation, the lwB4 MAY elect to queue the

   fragments as they arrive and perform NAPT44 on all fragments at the

   same time"

?? Queue based on what? Presumably the fragment identifier field, and if so then that is no different to 2473.


[ian] Updated the text to note that.


* Section 5.2: Text:

For incoming de-capsulated IPv4 packets carrying UDP packets with a

   zero checksum, if the lwB4 has enough resources, the lwB4 MUST

   reassemble the packets and MUST calculate the checksum.  If the lwB4

   does not have enough resources, then it MUST silently discard the

   packets.
Wouldn't it be easier to say that the lwb4 MAY reassemble the packet and recalculate the checksum? It's clearly not a MUST...

[ian] Why is it not a MUST? If one condition is met you MUST do this, if a different condition is met, you MUST do that. A MAY would make re-assembly of the packets optional, meaning that an implementation could not implement support for fragment reassembly at all and still say that it is compliant with the spec.

Cheers,
Wojciech



On 14 February 2014 10:18,  <[e-mail]<mailto:[e-mail]>> wrote:
> Hi Ole,
>
>
> Thanks for the review. Please see inline.
>
> Cheers,
> Ian
>
> On 11/02/2014 11:28, "Ole Troan" <[e-mail]<mailto:[e-mail]>> wrote:
>
>>a few initial comments:
>>
>>s/connectivity services/connectivity/
>>s/OPTION_SW46_LW/OPTION_S46_CONT_LW/
>
> [ian] OK
>
>>
>>section 5.1
>>   An IPv6 address from an assigned prefix is also required for the lwB4
>>   to use as the encapsulation source address for the softwire.  In
>>   order to enable end-to-end provisioning, the IPv6 address is
>>   constructed by taking a /64 prefix assigned to the WAN interface and
>>   suffixing 64-bits for the interface identifier.  As there may be
>>   multiple WAN prefixes, of which only one can be used for lw4o6, the
>>   CPE is provisioned with the logic to select the correct one.  The /
>>   128 prefix is then constructed as follows:
>>
>>that seems awfully hand-wavy?
>>how is the CPE supposed to pick which prefix to use? does it have to be
>>from the WAN interface?
>
> [ian]Yes, it¹s built on the WAN interface. The intention is that the CPE
> builds the tunnel from the prefix which it has just created. I guess it¹s
> the following line that causes the hand waving:
>
> As there may be multiple WAN prefixes, of which only one can be used for
> lw4o6, the CPE is provisioned with the logic to select the correct one.
>
> What about?:
>
> As there may be multiple WAN prefixes, of which only one can be used for
> lw4o6, the CPE creates a new WAN prefix specifically for use as the tunnel
> source address.
>
>
>
>>could it be from the PD block as well?
>
> [ian] It could be from the PD block if it¹s using the PD_EXCLUDE¹d prefix,
> but there¹s no requirement / necessity for the device with the lwB4
> function to support PD to build a tunnel. The lwB4 function could be
> implemented in an end host which wouldn¹t support PD.
>
>>
>>reference MAP for the interface-id? (or perhaps just state that it is the
>>same)
>
> [ian] I¹ll update to say that it¹s the same.
>
>>define PSID somewhere? (reference MAP document)?
>
> [ian] Currently, sect 5.1 says: An lwB4 MUST support dynamic
> port-restricted IPv4 address
>         provisioning.  The port set algorithm for provisioning this is
>         described in Section 5.1 of [I-D.ietf-softwire-map].
>
>>
>>why SHOULD the a-bits be 0? isn't that an operational choice?
>
> [ian]Because there¹s no reason to use non-0 if you¹re not algorithmically
> mapping, it just increases the complexity.
>
>>
>>I really don't think overriding the ICMP type 1 code 5 is appropriate to
>>signal "no binding".
>
> [ian] Do you think a different error ICMP error should be sent, or that
> should be silently dropped?
>
>>do you think the BR reachability check from RFC5969 could be adopted
>>instead?
>
> [ian] Possibly, although this would mandate that your lwAFTRs always had
> traffic hair pinning enabled so the check could succeed.
>
> This is a common softwire problem, though. From what I can see, if there
> were inconsistencies in the MAP provisioning domain between CEs and BRs,
> for any reason then it would fail with no errors being sent (although
> there would be counters on the problem devices).
>
>>
>>should you say something about using anycast addresses for the AFTR?
>>
>>a general comment. we're going to have quite a bit of redundant text
>>between the MAP documents and the LW46 document, e.g. ICMP handling,
>>fragmentation. I don't have a big problem with that as such, but should
>>ensure that the text isn't conflicting at least.
>
> [ian] Some redundancy is inevitable. I _hope_ that by now we¹ve ironed out
> any conflicts - I¹m certainly not aware of any.
>
>>
>>cheers,
>>Ole
>>
>>On 11 Feb 2014, at 8:54 , [e-mail]<mailto:[e-mail]> wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>directories.
>>> This draft is a work item of the Softwires Working Group of the IETF.
>>>
>>>        Title           : Lightweight 4over6: An Extension to the
>>>DS-Lite Architecture
>>>        Authors         : Yong Cui
>>>                          Qiong Sun
>>>                          Mohamed Boucadair
>>>                          Tina Tsou
>>>                          Yiu L. Lee
>>>                          Ian Farrer
>>>      Filename        : draft-ietf-softwire-lw4over6-06.txt
>>>      Pages           : 22
>>>      Date            : 2014-02-10
>>>
>>> Abstract:
>>>   Dual-Stack Lite (RFC 6333) describes an architecture for transporting
>>>   IPv4 packets over an IPv6 network.  This document specifies an
>>>   extension to DS-Lite called Lightweight 4over6 which moves the
>>>   Network Address and Port Translation (NAPT) function from the
>>>   centralized DS-Lite tunnel concentrator to the tunnel client located
>>>   in the Customer Premises Equipment (CPE).  This removes the
>>>   requirement for a Carrier Grade NAT function in the tunnel
>>>   concentrator and reduces the amount of centralized state that must be
>>>   held to a per-subscriber level.  In order to delegate the NAPT
>>>   function and make IPv4 Address sharing possible, port-restricted IPv4
>>>   addresses are allocated to the CPEs.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-06
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-lw4over6-06
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>>submission
>>> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/softwires
>>
>
> _______________________________________________
> Softwires mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/softwires