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

From: [email-masked]
Date: Mon, 10 Feb 2014 23:54:45 -0800

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/

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Feb 2014 11:28:18 +0100

a few initial comments:

s/connectivity services/connectivity/
s/OPTION_SW46_LW/OPTION_S46_CONT_LW/

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?
could it be from the PD block as well?

reference MAP for the interface-id? (or perhaps just state that it is the same)
define PSID somewhere? (reference MAP document)?

why SHOULD the a-bits be 0? isn't that an operational choice?

I really don't think overriding the ICMP type 1 code 5 is appropriate to signal "no binding".
do you think the BR reachability check from RFC5969 could be adopted instead?

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.

cheers,
Ole

On 11 Feb 2014, at 8:54 , [email-masked] wrote:

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: <[email-masked]>
Date: Fri, 14 Feb 2014 10:18:07 +0100

Hi Ole,

Thanks for the review. Please see inline.

Cheers,
Ian

>s/OPTION_SW46_LW/OPTION_S46_CONT_LW/

[ian] OK

>how is the CPE supposed to pick which prefix to use? does it have to be

[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

[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

[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

[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).

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

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 14 Feb 2014 15:18:41 +0100

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

---

From: <[email-masked]>
Date: Fri, 14 Feb 2014 20:24:48 +0100

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: "

   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:

   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,  <[email-masked]<mailto:[email-masked]>> wrote:
> On 11/02/2014 11:28, "Ole Troan" <[email-masked]<mailto:[email-masked]>> wrote:
>
>>a few initial comments:
>>
>>On 11 Feb 2014, at 8:54 , [email-masked]<mailto:[email-masked]> wrote:
>>
>>>
>>> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>>>
>>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Wojciech Dec <[email-masked]>
Date: Sun, 16 Feb 2014 17:32:14 +0100

Hi Ian,

you haven't replied on my high level comment - would appreciate if you
introduced changes to that effect in the draft.

Continued inline...

On 14 February 2014 20:24, <[email-masked]> wrote:

> 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:
>
> 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?
>

Woj>  What is the WAN interface is, and how should the CPE "find it" not
said. That other drafts fail to clarify that doesn't make it quite right...

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

Here we're talking about tunneling, and I cannot see a case whereby the
IPv4 TCP/UDP header would get fragmented, unless the MTU of the IPv6 tunnel
was <40. rfc6146 is about translation where other effects come to apply.

> [ian] Updated the text to note that.

Ok, but in essence, it would be actually better removing the text since it
adds nothing above 2473.

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

If it were a MUST then something would horribly break if it were not done.
The above clearly says that this reassembly operation is at the discretion
of the device,  subject to an arbitrary "enough resources" condition. If
you'd like it to be a MUST then the condition should be removed.

Cheers,
Wojciech.

---

From: Ian Farrer <[email-masked]>
Date: Mon, 17 Feb 2014 17:15:59 +0100

Hi Woj,

Please see inline.

Cheers,
Ian

On 16 Feb 2014, at 17:32, Wojciech Dec <[email-masked]> wrote:

> Hi Ian,
> 
> you haven't replied on my high level comment - would appreciate if you introduced changes to that effect in the draft.
> 
> Continued inline…

[ian] The draft already contains the following text (and has for some time):
   Lightweight 4over6 provides a solution for a hub-and-spoke softwire
   architecture only.  It does not offer direct, meshed IPv4
   connectivity between subscribers without packets traversing the AFTR.
   If this type of meshed interconnectivity is required,
   [I-D.ietf-softwire-map] provides a suitable solution.
So, are you not happy with the wording of the current reference, or are you requesting that the draft is rewritten to be cast as a ‘specialised' case of MAP?
Either way, I don’t really agree with your justification points for a change:
- The PSID and the port range are algorithmically derived & related as per the MAP algorithm (covered in Section 5.1)
 [ian] The PSID usage in lw4o6 is written so that you don’t have to implement the MAP algorithm to use it (hence the should requirement for a=0). This makes it functionally identical to the PSID originally described in draft-bajko-pripaddrassign. So lw4o6 does not require you to implement the MAP algorithm, but it doesn’t prevent you from using MAP to implement it (which was the reason for the agreement on using the MAP PSID DHCP format).
- 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)
[ian] This is noted and already referenced in the lw4o6 draft.
- The lw46 CPE should be provisioned using the MAP DHCP (also Section 5.1).
[ian] The draft which is called map-dhcp has been re-written extensively with input from people across the WG to be a DHCP option for provisioning map & lw4o6. It is now map-dhcp by filename alone and once it progresses, won’t even be called that anymore. How does this make lw4o6 a ‘specialisation' of MAP?
As it’s potentially a significant change that you are requesting here, I’d appreciate the opinions of other members of the WG on this.

> [ian] I’ve updated with the wording that I proposed to Ole.
> 
> Woj>  What is the WAN interface is, and how should the CPE "find it" not said. That other drafts fail to clarify that doesn't make it quite right…

[ian] This is entirely implementation specific and something that hasn’t stopped millions of CPEs being built and deployed that support both RFC6333 and RFC7084 (né RFC6204). What’s the problem that you are trying to solve?

> [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.
> 
> 
> Here we're talking about tunneling, and I cannot see a case whereby the IPv4 TCP/UDP header would get fragmented, unless the MTU of the IPv6 tunnel was <40. rfc6146 is about translation where other effects come to apply.

[ian] No, this is related to fragmentation in respect to the RFC1858 'Tiny Fragment attack' which affects  the IPv4 payload. The same problems exist for the lwB4s NAT44 function as exist for a NAT64 in this respect, which is why it was included.
> Ok, but in essence, it would be actually better removing the text since it adds nothing above 2473. 

[ian] The text in the current version reads:

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.  In this case, the incoming 5-tuple is determined by
   extracting the appropriate fields from the received packet, as
   described in [RFC2473].  Alternatively, a lwB4 MAY translate the de-
   capsulated fragments as they arrive, by storing information that
   allows it to compute the 5-tuple for fragments other than the first.
In the context of the above, is this a problem?

> If it were a MUST then something would horribly break if it were not done. The above clearly says that this reassembly operation is at the discretion of the device,  subject to an arbitrary "enough resources" condition. If you'd like it to be a MUST then the condition should be removed.

[ian] Then surely re-assembly is a SHOULD requirement, with a a MUST to discard if cannot be re-assembled. As I said, if it was a MAY requirement, then implementation would be completely optional.

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 19 Feb 2014 09:34:02 +0100

Hi Ian,

Just to be clear: I'm ok with lw46 defining a specific functional mode as I
believe it does in this draft, also leaving "as-is" the DHCP part of it
(i.e. it's a capability that can be signalled using the lw46 container,
etc).
General items remain open (as commented):
- Cleanup text that does not belong to lw46 (eg 2473 fixes, or NAT44 best
practice).
- Clarification of WAN selection or assumptions

That said, abundant technical evidence (summarized in previous mail)
indicates that this mode is in near total overlap with MAP 1:1, certainly
much more than at the outset of this work. Given this, why not align the
text and actually make MAP 1:1 and lw46 be the same? On all of the data
plane IPv6, IPv4, NAT44, tunneling and ICMP handling parts I see there no
reason for there being a difference...

continued inline...

On 17 February 2014 17:15, Ian Farrer <[email-masked]> wrote:

> So, are you not happy with the wording of the current reference, or are
> you requesting that the draft is rewritten to be cast as a 'specialised'
> case of MAP?
>
What I pointed out is that the Lw46 draft has major if near total overlap
with MAP-E 1:1 mode. Stating that lw46 realizes this mode, in a standalone
way from the N:1 mesh mode, is what I propose. This would greatly help in
implementing it and "digesting" the array of solutions.
Additional comment Now that you mention it, the stated characterisation of
map isn't quite right; MAP does not force the use of mesh mode, nor is mesh
mode its defining characteristic. The characterisation should be restated
as " lw46 does not seek to offer the optimization of AFTR subscriber state
and the AFTR is expected to have configuration state for each lwB4 node. If
optimization of this state is required, [id-ietf-softwire-map] provides a
suitable solution ".
Alternatively, state that "lw46 describes a deployment/implementation of
MAP 1:1"

> Either way, I don't really agree with your justification points for a
> change:
>  [ian] The PSID usage in lw4o6 is written so that you don't have to
> implement the MAP algorithm to use it (hence the should requirement for
> a=0). This makes it functionally identical to the PSID originally described
> in draft-bajko-pripaddrassign. So lw4o6 does not require you to implement
> the MAP algorithm, but it doesn't prevent you from using MAP to implement
> it (which was the reason for the agreement on using the MAP PSID DHCP
> format).
>
I'm actually fine with the current lw46 text in section 5.1, but your
response seems to conflict with that. I'll start another thread on this
topic.

>  - 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)
> [ian] The draft which is called map-dhcp has been re-written extensively
> with input from people across the WG to be a DHCP option for provisioning
> map & lw4o6. It is now map-dhcp by filename alone and once it progresses,
> won't even be called that anymore. How does this make lw4o6
> a 'specialisation' of MAP?
> As it's potentially a significant change that you are requesting here, I'd
> appreciate the opinions of other members of the WG on this.
>

>> comment. This is indeed hand wavy in the current draft (how to select
>> the WAN?)
>>
> [ian] This is entirely implementation specific and something that hasn't
> stopped millions of CPEs being built and deployed that support both RFC6333
> and RFC7084 (né RFC6204). What's the problem that you are trying to solve?
>

Woj> None of those texts attempt to create a deterministic ip interface,
and in case of 6333 that is a known operational issue. So, in terms of the
lw46 draft specifying how a CPE is to get to the IP prefix of  "the WAN
interface" is an important aspect, or at least stating the assumptions
about this WAN interface. Some obvious questions apply here:
is the WAN the interface which has the default route? Is it the interface
that has a DHCPv6 client? What if there are multiple such "WAN" interfaces?
What if a single "WAN" has multiple IPv6 prefixes? What if it has NO global
IPv6 prefix? What if it doesn't have a /64 prefix. etc.

Coincidentally, all of the latter are options allowed for by RFC7084.

> [ian] No, this is related to fragmentation in respect to the RFC1858 'Tiny
> Fragment attack' which affects  the IPv4 payload. The same problems exist
> for the lwB4s NAT44 function as exist for a NAT64 in this respect, which is
> why it was included.
>

Woj> Ok, but what does "MAY require" mean, and how should a device go about
requiring it?

> In the context of the above, is this a problem?

Woj> Well, what strikes me is that the above text does not bring in
anything other than what's already in 2473 for IPinIP fragementation and
[RFC5508], and  [RFC5382] for NAT. The text should refer to those
documents, or file errata. In other words, IPv4inIPv6 fragments and
handling of IPv4 fragments with NAT44 is not a lwB4 specific function, and
is already well documented.

>> [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.
>>
>
> [ian] Then surely re-assembly is a SHOULD requirement, with a a MUST to
> discard if cannot be re-assembled. As I said, if it was a MAY requirement,
> then implementation would be completely optional.
>

Woj> Yes, and that's what the above text reads from a test perspective,
i.e. since one has no way of determining whether there are "enough
resources", a lwB4 that discards all such packets would comply. As I said,
if one would like to tighten the spec; a) the un-testable "enough
resources" condition should be removed b) with that either a MUST used, if
this is something super important, or a SHOULD (as it seems to me).
Alternatively a MAY as "nice to have" may also do.

Cheers,
Wojciech.

---

From: Qi Sun <[email-masked]>
Date: Fri, 21 Feb 2014 17:25:39 +0800

Hi Woj,

On 2014-2-19, at 下午4:34, Wojciech Dec wrote:
> 
> Just to be clear: I'm ok with lw46 defining a specific functional mode as I believe it does in this draft,

[Qi] The outcome of ietf88 was lw4o6 and map are two mechanisms, but both use the Softwire DHCP for provisioning (at least according to my memory). That is why the WG decided to remove the statement of "lw4o6 is a subset of MAP-E" is from the Softwire DHCP Option draft.

And lw4o6 can use DHCPv4 over DHCPv6 and PCP for provisioning. This is documented in the current lw4o6 draft, and some teams are doing the documentation work. (We have demoed in IETF85 that lw4o6 can work with DHCPv4 over IPv6 and PCP). The point is, lw4o6 architecture is quite flexible. 

> also leaving "as-is" the DHCP part of it (i.e. it's a capability that can be signalled using the lw46 container, etc). 

> - Cleanup text that does not belong to lw46 (eg 2473 fixes, or NAT44 best practice). 

[Qi] IMO, that text guarantees the interoperation between lwAFTRs and lwB4s from different vendors, which bothered us a little when carrying out the interop test. I think it doesn't hurt to make it specific.

> - Clarification of WAN selection or assumptions

[Qi] I think Ian has expressed cleared in previous mails.

> 
> That said, abundant technical evidence (summarized in previous mail) indicates that this mode is in near total overlap with MAP 1:1, certainly much more than at the outset of this work. Given this, why not align the text and actually make MAP 1:1 and lw46 be the same? On all of the data plane IPv6, IPv4, NAT44, tunneling and ICMP handling parts I see there no reason for there being a difference...

[Qi] I think lw4o6 is clean and simple, and flexible to work with different provisioning mechanisms (signaling through the Softwire DHCP as is agreed by the WG). 

> What I pointed out is that the Lw46 draft has major if near total overlap with MAP-E 1:1 mode. Stating that lw46 realizes this mode, in a standalone way from the N:1 mesh mode, is what I propose. This would greatly help in implementing it and "digesting" the array of solutions. 

[Qi] I don't see any "help" here...

> Additional comment Now that you mention it, the stated characterisation of map isn't quite right; MAP does not force the use of mesh mode, nor is mesh mode its defining characteristic.

[Qi] From my reading, the text doesn't characterize what MAP is. It just says "if you want to use meshed IPv4 connectivity, then use MAP". It doesn't prevent you from using MAP to do anything else. So I think the text is OK.

> The characterisation should be restated as " lw46 does not seek to offer the optimization of AFTR subscriber state and the AFTR is expected to have configuration state for each lwB4 node. If optimization of this state is required, [id-ietf-softwire-map] provides a suitable solution ". 
> Alternatively, state that "lw46 describes a deployment/implementation of MAP 1:1"

[Qi] In my opinion, the current wording is clear and enough. 

> I'm actually fine with the current lw46 text in section 5.1, but your response seems to conflict with that. I'll start another thread on this topic.
> 
>  

[Qi] I think the current lw4o6 draft is good to read and it reflects the outcome of the last Vancouver meeting.

> Woj> None of those texts attempt to create a deterministic ip interface, and in case of 6333 that is a known operational issue. So, in terms of the lw46 draft specifying how a CPE is to get to the IP prefix of  "the WAN interface" is an important aspect, or at least stating the assumptions about this WAN interface. Some obvious questions apply here:
> is the WAN the interface which has the default route? Is it the interface that has a DHCPv6 client? What if there are multiple such "WAN" interfaces? What if a single "WAN" has multiple IPv6 prefixes? What if it has NO global IPv6 prefix? What if it doesn't have a /64 prefix. etc.
> 
> Woj> Ok, but what does "MAY require" mean, and how should a device go about requiring it? 

[Qi] Please see page 18 of RFC6146:

      *  The NAT64 MAY require that the UDP, TCP, or ICMP header be
         completely contained within the fragment that contains fragment
         offset equal to zero.

> Woj> Well, what strikes me is that the above text does not bring in anything other than what's already in 2473 for IPinIP fragementation and  [RFC5508], and  [RFC5382] for NAT. The text should refer to those documents, or file errata. In other words, IPv4inIPv6 fragments and handling of IPv4 fragments with NAT44 is not a lwB4 specific function, and is already well documented.
> 
> 
>  
> 
>>  
>> * Section 5.2: Text:
>> 
> Woj> Yes, and that's what the above text reads from a test perspective, i.e. since one has no way of determining whether there are "enough resources", a lwB4 that discards all such packets would comply. As I said, if one would like to tighten the spec; a) the un-testable "enough resources" condition should be removed b) with that either a MUST used, if this is something super important, or a SHOULD (as it seems to me). Alternatively a MAY as "nice to have" may also do.

[Qi] I prefer to use a SHOULD for re-asembly and a MUST for discarding the packet if it cannot be reassembled.

Thanks,
Qi

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 25 Feb 2014 11:12:01 +0100

Hi Qi,

your answers didn't answer the majority of the concerns raised. And some of
those raised by Ole still also stand:
- Clean-up text that does not belong to lw46 (eg 2473 fixes, NAT44 best
practice).
- Clarification of WAN selection or assumptions
- Clarify questionable use of ICMPv6 error code (to report lack of v4
binding)
- Text clarifying relation to MAP-E (both use MAP PSID algo, address
embedding, IPv4inIPv6 and NAT44 w/ address sharing. MAP allows state to be
ranged from N to 1 per CPE. lw46 focuses on the 1:1 case)

I still see no reason why they cannot be addressed by edits to the draft
that don't change the matter that lw46 is a standalone draft.

Snipped text Inline... Woj>

On 21 February 2014 10:25, Qi Sun <[email-masked]> wrote:

> [Qi] The outcome of ietf88 was lw4o6 and map are two mechanisms, but both
> use the Softwire DHCP for provisioning (at least according to my memory).
> That is why the WG decided to remove the statement of "lw4o6 is a subset of
> MAP-E" is from the Softwire DHCP Option draft.
>
> And lw4o6 can use DHCPv4 over DHCPv6 and PCP for provisioning. This is
> documented in the current lw4o6 draft, and some teams are doing the
> documentation work. (We have demoed in IETF85 that lw4o6 can work with
> DHCPv4 over IPv6 and PCP). The point is, lw4o6 architecture is quite
> flexible.
>

Woj>I didn't quite comment on the DHCP draft, nor on how flexible and clear
*you think* the lw46 draft is, etc. I commented on the fact that that lw46
shares a lot with MAP-E and the fact that it is built on the same
technology blocks as MAP-E, but realizes solely the 1:1 part should be
clarified.

Irrespective of this, there is overall no reason for having text in the
lw46 draft that fixes 2473 or NAT44 best practices, etc.

> also leaving "as-is" the DHCP part of it (i.e. it's a capability that can
> be signalled using the lw46 container, etc).
>
>
> [Qi] IMO, that text guarantees the interoperation between lwAFTRs and
> lwB4s from different vendors, which bothered us a little when carrying out
> the interop test. I think it doesn't hurt to make it specific.
>

Woj>A couple of points:  Firstly: Given that the lwB4 CPE uses the MAP
algorithm for the PSID and embeds the IPv4+PSID in its IPv6 address, the
text is now in shape that a lwB4 would be interoperable with a MAP-E BR.
This is actually good convergence/progress. What remains open in that
happening is actually weeding out the possible source of differences, which
appear to be in the nuances of ICMP handling.

Secondly: It claims to be a standards track document (currently), and it
carries text that selectively duplicates text in other standard rfcs
without deferring to those RFCs. If there are any reasons why this "cherry
picking" was made, while other recommendations (say re NAT44) were not
adopted, they should be clarified. In general for rfc2473, there I see so
far no zero reason to have some other text here, as opposed to errata. Same
for NAT44 really.

Then again, perhaps the draft should be interpreted as an RFP of some kind,
which it actually reads a lot like. In which case it should not be a
standard track document.

> [Qi] I think Ian has expressed cleared in previous mails.

Woj>Please see my reply to Ian - looking forward to an answer in the draft:
--snip--
So, in terms of the lw46 draft specifying how a CPE is to get to the IP
prefix of  "the WAN interface" is an important aspect, or at least stating
the assumptions about this WAN interface. Some obvious questions apply here:
is the WAN the interface which has the default route? Is it the interface
that has a DHCPv6 client? What if there are multiple such "WAN" interfaces?
What if a single "WAN" has multiple IPv6 prefixes? What if it has NO global
IPv6 prefix? What if it doesn't have a /64 prefix. etc.
--snip--
One doesn't see the draft answering any of these at the moment.

> [Qi] I think lw4o6 is clean and simple, and flexible to work with
> different provisioning mechanisms (signaling through the Softwire DHCP as
> is agreed by the WG).
>
>
>
> continued inline...
>
>
>
>
>> you requesting that the draft is rewritten to be cast as a ‘specialised'
>> case of MAP?
>>

Woj>To an operator and implementer, it would be very advantageous that all
of IPv4 in IPv6 and NAT44 data plane aspects, as specified by Softwire
drafts are the same, unless it is made clear as to why they should be
different, and what does it bring. This applies especially to lw46 and MAP,
since there is so much overlap between the solutions.

> mode its defining characteristic.
>
>
> [Qi] From my reading, the text doesn't characterize what MAP is. It just
> says "if you want to use meshed IPv4 connectivity, then use MAP". It
> doesn't prevent you from using MAP to do anything else. So I think the text
> is OK.
>

Woj> Well, that is "characterisation". From dictionary: "The act of
describing the character or qualities of someone or something"
And as stated, it is not quite correct, i.e. mesh-mode is not the defining
feature of MAP. The state optimization (stateless) is, of which mesh mode
is a by product (optional actually in the spec). The text needs to be
changed.

>
> The characterisation should be restated as " lw46 does not seek to offer
> the optimization of AFTR subscriber state and the AFTR is expected to have
> configuration state for each lwB4 node. If optimization of this state is
> required, [id-ietf-softwire-map] provides a suitable solution ".
>> said. That other drafts fail to clarify that doesn't make it quite right…
>>
>>
>>
>> [ian] No, this is related to fragmentation in respect to the RFC1858
>> 'Tiny Fragment attack' which affects  the IPv4 payload. The same problems
>> exist for the lwB4s NAT44 function as exist for a NAT64 in this respect,
>> which is why it was included.
>>
>

Woj> Well, that text as you point comes from NAT64, and concerns IPv6
header chain to IPv4 header "fitting". In lwB4, unless I misunderstand, the
only fragmentation there may be is that of IPv4 that would be driven by an
IPv4 MTU < 40 (violation of IPv4 min MTU 68). So what exactly the draft is
requiring here isn't clear.
In any case the fragmentation behaviour is not something specific to lw46,
so it would be best if you pointed the draft at the source.

>> If it were a MUST then something would horribly break if it were not
>> done. The above clearly says that this reassembly operation is at the
>> discretion of the device,  subject to an arbitrary "enough resources"
>> condition. If you'd like it to be a MUST then the condition should be
>> removed.
>>
>>

Woj> Well, so it's a SHOULD then. Please note: the "enough resources"
condition as is, is un-testable across implementations, so adding such
"dead" text is rather pointless.

Cheers,
Wojciech.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Feb 2014 07:43:09 -0500

On Feb 25, 2014, at 5:12 AM, Wojciech Dec <[email-masked]> wrote:
> I still see no reason why they cannot be addressed by edits to the draft that don't change the matter that lw46 is a standalone draft.

Woj, please propose text if you want changes.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 25 Feb 2014 13:21:49 -0500

I think you're being unfair on one point. 1:1 mode was an afterthought 
in MAP, appearing after LW4o6 had been published. It is not reasonable 
to say now that LW4o6 is just a subset of MAP because 1:1 mode is 
possible in the latter. 1:1 is certainly not MAP's main thrust.

I know this is a political rather than a technical point, but one could 
sort of reverse the claim and suggest that if 1:1 mode is desired, LW4o6 
is the better way to go.

Tom Taylor

On 25/02/2014 5:12 AM, Wojciech Dec wrote:
> Hi Qi,
>
> your answers didn't answer the majority of the concerns raised. And some
> of those raised by Ole still also stand:
> embedding, IPv4inIPv6 and NAT44 w/ address sharing. MAP allows state to
> be ranged from N to 1 per CPE. lw46 focuses on the 1:1 case)
>
> On 21 February 2014 10:25, Qi Sun <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     Hi Woj,
>
>
>     [Qi] The outcome of ietf88 was lw4o6 and map are two mechanisms, but
>     both use the Softwire DHCP for provisioning (at least according to
>     my memory). That is why the WG decided to remove the statement of
>     "lw4o6 is a subset of MAP-E" is from the Softwire DHCP Option draft.
>
>     And lw4o6 can use DHCPv4 over DHCPv6 and PCP for provisioning. This
>     is documented in the current lw4o6 draft, and some teams are doing
>     the documentation work. (We have demoed in IETF85 that lw4o6 can
>     work with DHCPv4 over IPv6 and PCP). The point is, lw4o6
>     architecture is quite flexible.
>
>
>
> Woj>I didn't quite comment on the DHCP draft, nor on how flexible and
> clear *you think* the lw46 draft is, etc. I commented on the fact that
> that lw46 shares a lot with MAP-E and the fact that it is built on the
> same technology blocks as MAP-E, but realizes solely the 1:1 part should
> be clarified.
>
>>     also leaving "as-is" the DHCP part of it (i.e. it's a capability
>>     that can be signalled using the lw46 container, etc).
>
>     [Qi] IMO, that text guarantees the interoperation between lwAFTRs
>     and lwB4s from different vendors, which bothered us a little when
>     carrying out the interop test. I think it doesn't hurt to make it
>     specific.
>
>
> happening is actually weeding out the possible source of differences,
> which appear to be in the nuances of ICMP handling.
>
> without deferring to those RFCs. If there are any reasons why this
> "cherry picking" was made, while other recommendations (say re NAT44)
> were not adopted, they should be clarified. In general for rfc2473,
> there I see so far no zero reason to have some other text here, as
> opposed to errata. Same for NAT44 really.
>
> Then again, perhaps the draft should be interpreted as an RFP of some
> kind, which it actually reads a lot like. In which case it should not be
> a standard track document.
>
>
> prefix of  "the WAN interface" is an important aspect, or at least
> stating the assumptions about this WAN interface. Some obvious questions
> apply here:
> is the WAN the interface which has the default route? Is it the
> interface that has a DHCPv6 client? What if there are multiple such
> "WAN" interfaces? What if a single "WAN" has multiple IPv6 prefixes?
> What if it has NO global IPv6 prefix? What if it doesn't have a /64
> prefix. etc.
> --snip--
>>     That said, abundant technical evidence (summarized in previous
>>     mail) indicates that this mode is in near total overlap with MAP
>>     1:1, certainly much more than at the outset of this work. Given
>>     this, why not align the text and actually make MAP 1:1 and lw46 be
>>     the same? On all of the data plane IPv6, IPv4, NAT44, tunneling
>>     and ICMP handling parts I see there no reason for there being a
>>     difference...
>
>     different provisioning mechanisms (signaling through the Softwire
>     DHCP as is agreed by the WG).
>
>
>>
>>     continued inline...
>>
>>
>>
>>
>>         So, are you not happy with the wording of the current
>>         reference, or are you requesting that the draft is rewritten
>>         to be cast as a ‘specialised' case of MAP?
>>
>>     What I pointed out is that the Lw46 draft has major if near total
>>     overlap with MAP-E 1:1 mode. Stating that lw46 realizes this mode,
>>     in a standalone way from the N:1 mesh mode, is what I propose.
>>     This would greatly help in implementing it and "digesting" the
>>     array of solutions.
>
> Woj>To an operator and implementer, it would be very advantageous that
> all of IPv4 in IPv6 and NAT44 data plane aspects, as specified by
> Softwire drafts are the same, unless it is made clear as to why they
> should be different, and what does it bring. This applies especially to
> lw46 and MAP, since there is so much overlap between the solutions.
>
>
>>     Additional comment Now that you mention it, the stated
>>     characterisation of map isn't quite right; MAP does not force the
>>     use of mesh mode, nor is mesh mode its defining characteristic.
>
>     [Qi] From my reading, the text doesn't characterize what MAP is. It
>     just says "if you want to use meshed IPv4 connectivity, then use
>     MAP". It doesn't prevent you from using MAP to do anything else. So
>     I think the text is OK.
>
>
> And as stated, it is not quite correct, i.e. mesh-mode is not the
> defining feature of MAP. The state optimization (stateless) is, of which
> mesh mode is a by product (optional actually in the spec). The text
> needs to be changed.
>
>
>>     The characterisation should be restated as " lw46 does not seek to
>>     offer the optimization of AFTR subscriber state and the AFTR is
>>     expected to have configuration state for each lwB4 node. If
>>     optimization of this state is required, [id-ietf-softwire-map]
>>     provides a suitable solution ".
>>>>             * 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?)
>>>>
>>>>             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?
>>>>
>>>>
>>>>         Woj>  What is the WAN interface is, and how should the CPE
>>>>         "find it" not said. That other drafts fail to clarify that
>>>>         doesn't make it quite right…
>>>
>>>
>>>         [ian] No, this is related to fragmentation in respect to the
>>>         RFC1858 'Tiny Fragment attack' which affects  the IPv4
>>>         payload. The same problems exist for the lwB4s NAT44 function
>>>         as exist for a NAT64 in this respect, which is why it was
>>>         included.
>>>
>>>
> header chain to IPv4 header "fitting". In lwB4, unless I misunderstand,
> the only fragmentation there may be is that of IPv4 that would be driven
> by an IPv4 MTU < 40 (violation of IPv4 min MTU 68). So what exactly the
> draft is requiring here isn't clear.
> In any case the fragmentation behaviour is not something specific to
> lw46, so it would be best if you pointed the draft at the source.
>
>
>>>
>>>
>>>             * Section 5.2: Text:
>>>
>>>             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.
>>>
>>>
>>>         If it were a MUST then something would horribly break if it
>>>         were not done. The above clearly says that this reassembly
>>>         operation is at the discretion of the device,  subject to an
>>>         arbitrary "enough resources" condition. If you'd like it to
>>>         be a MUST then the condition should be removed.
>>
>>         [ian] Then surely re-assembly is a SHOULD requirement, with a
>>         a MUST to discard if cannot be re-assembled. As I said, if it
>>         was a MAY requirement, then implementation would be completely
>>         optional.
>>
>>
>>     Woj> Yes, and that's what the above text reads from a test
>>     perspective, i.e. since one has no way of determining whether
>>     there are "enough resources", a lwB4 that discards all such
>>     packets would comply. As I said, if one would like to tighten the
>>     spec; a) the un-testable "enough resources" condition should be
>>     removed b) with that either a MUST used, if this is something
>>     super important, or a SHOULD (as it seems to me). Alternatively a
>>     MAY as "nice to have" may also do.
>
>     [Qi] I prefer to use a SHOULD for re-asembly and a MUST for
>     discarding the packet if it cannot be reassembled.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Feb 2014 13:29:39 -0500

On Feb 25, 2014, at 1:21 PM, Tom Taylor <[email-masked]> wrote:
> I know this is a political rather than a technical point, but one could sort of reverse the claim and suggest that if 1:1 mode is desired, LW4o6 is the better way to go.

Indeed, if all one needs is 1:1, one might prefer lw4over6 since it only has the one mode.

---

From: Ole Troan <[email-masked]>
Date: Wed, 26 Feb 2014 00:11:06 +0100

> Indeed, if all one needs is 1:1, one might prefer lw4over6 since it only has the one mode.

I think the point he was trying to make was that it isn't optimal to have two standards documents, specifying mechanisms where one is almost completely encompassed by the other. I say almost, because there might be some divergence in how tunnel endpoint addresses are used, and how fragmentation and ICMP is dealt with.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Feb 2014 18:55:41 -0500

> I think the point he was trying to make was that it isn't optimal to have two standards documents, specifying mechanisms where one is almost completely encompassed by the other. I say almost, becau…

If this is indeed his point, I'm sure we're all sympathetic (I know I am) but it's not actionable, so we should move on.

---

From: Ole Troan <[email-masked]>
Date: Wed, 26 Feb 2014 00:07:27 +0000

> If this is indeed his point, I'm sure we're all sympathetic (I know I am) but it's not actionable, so we should move on.

au contrarie, it is clearly actionable, but I think the working group has done the best it can, so if there are actions, those should be elsewhere.

cheers,
Ole

---

From: Wojciech Dec <[email-masked]>
Date: Sat, 22 Feb 2014 11:59:44 +0100

Hi Qi,

afraid that your answers didn't answer the majority of the concerns raised.
I still see no reason why they cannot be addressed by edits to the draft
that don't change the matter that lw46 is a standalone draft.

Inline...

> DHCPv4 over IPv6 and PCP). The point is, lw4o6 architecture is quite

I didn't quite comment on the DHCP part, nor on how flexible and clear you
think lw46 is is, etc...  Will refrain from making replies to such points
as they're not constructive.

> the interop test. I think it doesn't hurt to make it specific.

It is a standards track document (currently), and it carries text that
selectively duplicates text in other standard rfcs without deferring to
those RFCs. If there are any reasons why this "cherry picking" was made,
and other recommendations (say re NAT44) not, they should be clarified. In
general for rfc2473, there I see so far no zero reason to have some other
text here, as opposed to errata.
Then again, perhaps the draft should be interpreted as an RFP of some kind,
which it actually reads a lot like being. In which case it should not be a
standard track document.

> [Qi] I think Ian has expressed cleared in previous mails.

Please see my reply to Ian.
--snip--
So, in terms of the lw46 draft specifying how a CPE is to get to the IP
prefix of  "the WAN interface" is an important aspect, or at least stating
the assumptions about this WAN interface. Some obvious questions apply here:
is the WAN the interface which has the default route? Is it the interface
that has a DHCPv6 client? What if there are multiple such "WAN" interfaces?
What if a single "WAN" has multiple IPv6 prefixes? What if it has NO global
IPv6 prefix? What if it doesn't have a /64 prefix. etc.
--snip--
One doesn't see the draft answering any of these.

> [Qi] I don't see any "help" here...

As an operator and implementer, it would be very advantageous that all of
IPv4 in IPv6 and NAT44 data plane aspects, as specified by Softwire drafts
are the same, unless it is made clear as to why they should be different.
This applies especially to lw46 and MAP, since there is clear overlap.

> doesn't prevent you from using MAP to do anything else. So I think the text

Well, that is "a characterisation", and as stated, it is not quite correct,
i.e. mesh-mode is not the defining feature of MAP (although you appear to
think so).

>> - The PSID and the port range are algorithmically derived & related as
>> per the MAP algorithm (covered in Section 5.1)
>>  [ian] The PSID usage in lw4o6 is written so that you don’t have to
>> the MAP algorithm, but it doesn’t prevent you from using MAP to implement
>> won’t even be called that anymore. How does this make lw4o6
>> a ‘specialisation' of MAP?
>> As it’s potentially a significant change that you are requesting here,
>> I’d appreciate the opinions of other members of the WG on this.
>>
>
>> [ian] This is entirely implementation specific and something that hasn’t
>> and RFC7084 (né RFC6204). What’s the problem that you are trying to solve?
>>
>
>>> [ian] The text is taken directly from RFC6146. I guess that doesn’t

Well, that text as you point comes from NAT64, and concerns IPv6 header
chain to IPv4 header "fitting". In lwB4, unless I misunderstand, the only
fragmentation there may be is that of IPv4 that would be driven by an IPv4
MTU < 40 (violation of IPv4 min MTU 68). So what exactly the draft is
requiring here isn't clear.
In any case the fragmentation behaviour is not something specific to lw46,
so it would be best if you pointed the draft at the source.

Cheers,
Wojciech.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 25 Feb 2014 20:10:04 -0500

Hi Woj,

> that don't change the matter that lw46 is a standalone draft.

In all fairness, your comments came in a few hours before the draft 
submission deadline for this IETF. It is unreasonable to expect the 
issues to get addressed by draft changes, at least until the submission 
reopens. I do think the above points merit a response from the document 
editors.

 > be ranged from N to 1 per CPE. lw46 focuses on the 1:1 case)

Why do you think this is required here? Isn't this the goal of the 
unified CPE work (to clarify the commonalities between MAP and lw4over6)?

Thanks
Suresh

---

From: <[email-masked]>
Date: Wed, 26 Feb 2014 10:31:55 +0100

Hi Woj,

I’ve been out of the office for a couple of days, so sorry for the be late reply.

Please see inline.

Cheers,
Ian

From: Wojciech Dec <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 19 February 2014 09:34
To: Ian Farrer <[email-masked]<mailto:[email-masked]>>
Cc: Softwires-wg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

Hi Ian,

Just to be clear: I'm ok with lw46 defining a specific functional mode as I believe it does in this draft, also leaving "as-is" the DHCP part of it (i.e. it's a capability that can be signalled using the lw46 container, etc).

[ian] It would help if you could propose text for what you would like to see. The inline discussion has become quite protracted.

[ian] The text relating to this was specifically requested, discussed and agreed during the WGLC. It would be better to pick up the discussion on that thread and then document the outcome (It starts with: http://www.ietf.org/mail-archive/web/softwires/current/msg05786.html)

[ian] Again, the text was previously discussed and agreed as part of the WGLC. Can you pick up the discussion at http://www.ietf.org/mail-archive/web/softwires/current/msg05792.html

[ian] Let’s discuss this based on your proposed text changes.

continued inline...

Detailed comments:

[ian] Discussed above.

[ian] 'MAY require' is a suggested possible solution which the CPE could implement: If there is not a complete L4 header in the first fragment, then it’s discarded. Implement it if you want to, don’t if you don’t (I.e. a MAY requirement).  I’m really not sure what’s not clear here.

Section 5.2: "

   same time"

[ian] What’s being added here is the translation of packets as they arrive, instead of queuing, re-assembing, then NATing as-per RFC2743. This is not documented anywhere for NAT44 (to my knowledge), only for NAT64.

This is not saying that RFC2473 is incorrect, it’s saying that there could be another alternative.

* Section 5.2: Text:

   packets.

[ian] How is ‘enough resources’ untestable? Earlier in the section, it already specifically states that the amount of resources allocated for fragmented packets must be limited. The amour of a fixed fragment buffer in use or number of fragments in a fixed sized queue are perfectly testable.

>From a customers perspective, if I tested an implementation that discarded all such fragmented packets in all conditions, then the implementation is not compliant.

Regardless, if we can agree that the lwB4 SHOULD re-assemble if it can and discard if it can’t, then I’ll modify the paragraph to that effect.

Cheers,
Wojciech.

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 26 Feb 2014 11:12:30 +0100

Ted,
May I kindly ask that you read my comments before starting apparently
rhetorical discussions of the type that I didn't intend, and that do not
progress things?

In summary: I said that having a lw46 draft/solution is fine, but it is
clear that there is significant technical overlap between the two (use of
PSID w/ MAP algorithm, IP address embedding, NAT44 port sharing). At this
stage it doesn't matter how it came to be that we have two solutions+
(personally I believe that it was a case of WG leadership gone totally
wrong at the time).

What matters is that it is readily apparent that any divergences in the
area of IP tunneling and ICMP handling are not warranted - or if they are,
then the draft doesn't clarifyr why that is so. What also matters is to
make this clear to implementers. Yes, I do belive that people outside of
this WG will be interested to implement devices that cover both solutions
and minimize the work in doing so, which doesn't take away from them the
ability to do just one.

As a separate set of feedback points, a number of requirements in the lw46
draft do not appear to belong there (e.g they restate, selectively, NAT44
best practices). The WAN IP address selection appears either a) broken (e.g
author's didn't answer how to configure the IPv6 address in case of
multiple prefixes, or if the WAN interface doesn't have a global IPv6
prefix) or b) limited to a specific deployment. This needs to be clarified.

On 25 February 2014 19:29, Ted Lemon <[email-masked]> wrote:

> sort of reverse the claim and suggest that if 1:1 mode is desired, LW4o6 is
> the better way to go.
>

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 26 Feb 2014 12:05:40 +0100

Ian,

inline..

On 26 February 2014 10:31, <[email-masked]> wrote:

> Hi Woj,
>
> I've been out of the office for a couple of days, so sorry for the be late
> reply.
>
> Please see inline.
>
> Cheers,
> Ian
>
> From: Wojciech Dec <[email-masked]>
> To: Ian Farrer <[email-masked]>
> Cc: Softwires-wg <[email-masked]>
> Just to be clear: I'm ok with lw46 defining a specific functional mode as
> I believe it does in this draft, also leaving "as-is" the DHCP part of it
> [ian] It would help if you could propose text for what you would like to
> see. The inline discussion has become quite protracted.
>

I'll follow up on that...

> [ian] The text relating to this was specifically requested, discussed and
> agreed during the WGLC. It would be better to pick up the discussion on
> that thread and then document the outcome (It starts with:
> http://www.ietf.org/mail-archive/web/softwires/current/msg05786.html)
>

Please view my comments as part of the WGLC...
The key point is that IP tunnel fragementation handling and NAT44 best
practices have abundant and much better specificaion. Thus instead of
adding text here, please remove it and defer to the authoritative drafts in
that space or clarify what are the differences (and why).

Suggested text:

The NAT44 in the lwB4 MUST implement the behavior for ICMP message
conforming to the
   best current practice documented in [RFC5508
<http://tools.ietf.org/html/rfc5508>].
If a LwB4 receives an ICMP error message without the ICMP
   identifier field for errors that is detected inside a IPv6 tunnel, the
   node should relay the ICMP error message to the original source.
   This behavior SHOULD be implemented conforming to the section 8 of
   [RFC2473] <http://tools.ietf.org/html/rfc2473#section-8>.
 FOr TCP and UDP traffic the NAT44 implemented in the LwB4 SHOULD
conform with the behavior
   and best current practice documented in [RFC4787
<http://tools.ietf.org/html/rfc4787>], [RFC5508
<http://tools.ietf.org/html/rfc5508>], and
   [RFC5382 <http://tools.ietf.org/html/rfc5382>].

> [ian] Again, the text was previously discussed and agreed as part of the
> WGLC. Can you pick up the discussion at
> http://www.ietf.org/mail-archive/web/softwires/current/msg05792.html
>

Well, so the text from the above discussion does not appear in the draft.
What more however is that the text does not describe how a case of a WAN
without a global IPv6 prefix is to be handled (is that also invalid -
please state so in the draft).
Other cases:
- What is the WAN doesn't have a /64?
- What if there are multiple WAN interfaces?

If these are all invalid w/ lw46 - then please state so.

> [ian] Let's discuss this based on your proposed text changes.
>
>
> continued inline...
>
>
>
>
>>
>>> Detailed comments:
>>>
> [ian] 'MAY require' is a suggested possible solution which the CPE could
> implement: If there is not a complete L4 header in the first fragment, then
> it's discarded. Implement it if you want to, don't if you don't (I.e. a MAY
> requirement).  I'm really not sure what's not clear here.
>

The lwB4 cannot require anything is the point here: Instead the draft could
require the lwB4 to have some functionality. In this case, what is it?
Otherwise it appears to be a dead/null requirement here (That is a tell
tale characteristic of MAY requirements in general). So, the draft can
either a) remove it b) state the functionality that is needed (and here I
don't get it, because tiny fragments are not a lw46 specific thing, and you
can readily refer to existing specs on the matter which surely also provide
other valuable additions , eg 5508. If the functionality is not in that
text, then file an errata, rather than re-creating some sub-text here.

> [ian] What's being added here is the translation of packets as they
> arrive, instead of queuing, re-assembing, then NATing as-per RFC2743. This
> is not documented anywhere for NAT44 (to my knowledge), only for NAT64.
>

It is documented in RFC  4787 section 11...

> This is not saying that RFC2473 is incorrect, it's saying that there could
> be another alternative.
>
>
>
>>
>>
>>>
>>> * Section 5.2: Text:
>>>
> [ian] How is 'enough resources' untestable? Earlier in the section, it
> already specifically states that the amount of resources allocated for
> fragmented packets must be limited. The amour of a fixed fragment buffer in
> use or number of fragments in a fixed sized queue are perfectly testable.
>
> From a customers perspective, if I tested an implementation that discarded
> all such fragmented packets in all conditions, then the implementation is
> not compliant.
>
> Regardless, if we can agree that the lwB4 SHOULD re-assemble if it can and
> discard if it can't, then I'll modify the paragraph to that effect.
>

Having done some TDD in a past life, I'll assert that this is not a
testable requirement in its current form. One's "resources" are not
another's "resources", which is the missing piece here. I'd say that we can
agree to just state that lwB4 SHOULD resemble is cleaner. But, deferring to
rfc 4878 and friends may be better.

Cheers,
Wojciech.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Feb 2014 07:59:36 -0500

On Feb 26, 2014, at 5:12 AM, Wojciech Dec <[email-masked]> wrote:
> May I kindly ask that you read my comments before starting apparently rhetorical discussions of the type that I didn't intend, and that do not progress things? 

You may, I have, and I'm happy to see some forward progress happening in the discussion.