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

[Wojciech Dec <[e-mail]>]

Ian,

inline..


On 26 February 2014 10:31, <[e-mail]> 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 <[e-mail]>
> Date: Wednesday, 19 February 2014 09:34
> To: Ian Farrer <[e-mail]>
> Cc: Softwires-wg <[e-mail]>
> 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.
>

I'll follow up on that...


>
> General items remain open (as commented):
> - Cleanup text that does not belong to lw46 (eg 2473 fixes, or NAT44 best
> practice).
>
> [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>].


> - Clarification of WAN selection or assumptions
>
> [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.


> 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...
>
> [ian] Let's discuss this based on your proposed text changes.
>
>
> continued inline...
>
>
>
>
>>
>>> 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?
>>
>
> 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] Discussed above.
>
>
>
>>
>> * 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.
>>
>
> Woj> Ok, but what does "MAY require" mean, and how should a device go
> about requiring it?
>
> [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.


>
>
>>>
>>> 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?
>>
>
> 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] 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:
>>>
>>> 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.
>>
>
> 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.
>
> [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.


>
>
> Cheers,
> Wojciech.
>
>