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

[Wojciech Dec <[e-mail]>]

Hi Ian, All,

I read the latest draft and have a number of comments.

High level:
Based on my understanding the lwB4 architecture now has the following
ingredients:
- The PSID and the port range are algorithmically derived & related as per
the MAP algorithm (covered in Section 5.1)
- The assigned IPv4 address and port-set form part of the IPv6 address of a
lwB4, and are included in the interface-identifier in the same place and
format as MAP (Section 5.1)
- The lw46 CPE should be provisioned using the MAP DHCP (also Section 5.1).

This indicates that lw46 actually share pretty much everything with MAP-E
bar the N:1 mode and text on this "specialization" would appear to be
warranted and much more appropriate than the current text that refers to it
being a ds-lite extension, with which both solutions simply share
IPv4inIPv6 tunnelling. It would be good to have text in Section 1 stating
this specialization, e.g. in terms of lw46 realizing the MAP-E 1:1 (EA-bit
= 0) case.

In general it would appear to be really useful to make extra sure that
there are no data-plane (as per Ole's comment, and some added ones below)
between lw46 and MAP-E, or at least arrive at some justification what that
is the case, as it's quite clear that a common implementation can cover
both drafts rather easily. A reference would actually make things much
easier.

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?)
* Section 5.1* and *6.2 has text about ICMPv6 message processing/generation
based on incorrect IPv4+port usage, using existing ICMPv6 code type 1 code
5. This appears not in line with at least the IPv6 interpretation of that
message (the source address that failed was the IPv4 source, not IPv6, and
actually it was a lack of binding rule that failed).
* Section 6.2: Text: "If no match is found (e.g., no matching IPv4 address
entry, port out of range, etc.), the lwAFTR MUST discard or implement ..."
This would suggests that the behaviour is not a MUST, but having said that,
the "or implement a redirect..." case makes no sense. If the AFTR has no
binding, there is no way that some other node would be able to correspond
with the sender, etc.
* 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?
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.

* 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...

Cheers,
Wojciech



On 14 February 2014 10:18,  <[e-mail]> wrote:
> Hi Ole,
>
>
> Thanks for the review. Please see inline.
>
> Cheers,
> Ian
>
> On 11/02/2014 11:28, "Ole Troan" <[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] 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.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires