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

[Wojciech Dec <[e-mail]>]

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


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

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

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.

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

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.

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



>
>
> 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).
>
>
>
> continued inline...
>
>
> On 17 February 2014 17:15, Ian Farrer <[e-mail]> wrote:
>
>> 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?
>>
> 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...
>

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.

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

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


>
>
>> 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).
>>
> 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] 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.
>>
>
> [Qi] I think the current lw4o6 draft is good to read and it reflects the
> outcome of the last Vancouver meeting.
>
>
>
>>
>>> 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.
>
>
>>
>>  * 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?
>
>
> [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.
>

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.

>
>
>>>
>>> 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.
>
>
>
>
>>
>>
>>>
>>> * 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.
>
>
> [Qi] I prefer to use a SHOULD for re-asembly and a MUST for discarding the
> packet if it cannot be reassembled.
>

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.

>
> Thanks,
> Qi
>
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>
>
>