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

[Ian Farrer <[e-mail]>]

Hi Woj,

Please see inline.

Cheers,
Ian

On 16 Feb 2014, at 17:32, Wojciech Dec <[e-mail]> 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.

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

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

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