Snipped text Inline... Woj>
On 21 February 2014 10:25, Qi Sun <[email protected]
<mailto:[email protected]>> 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.
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).
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.
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.
- Clarification of WAN selection or assumptions
[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.
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...
[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...
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.
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 ".
Alternatively, state that "lw46 describes a
deployment/implementation of MAP 1:1"
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] 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.
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.
* 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.
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
