On Tue, 14 Jan 2014, Suresh Krishnan wrote:
Hi all,
This message starts a two week softwire working group last call on
advancing the draft about Lightweight 4over6 as a Standards Track RFC.
The authors believe that this version has addressed all the issues
raised on the document till now. The latest version of the draft is
available at
http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt
http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03
Substantive comments and statements of support/opposition for advancing
this document should be directed to the mailing list. Editorial
suggestions can be sent directly to the authors. This last call will
conclude on January 28, 2014.
I have re-read this document in its entirety, and found two things I would
like to have discussed.
The fragmentation handling needs more guidance. 5.2.1. says:
"On receiving an encapsulated packet containing an IPv4 fragment, the
lwB4 MUST wait until all other fragments have been received and de-
capsulated."
What happens if one of the fragments are lost? I would believe there is
work to be referenced when it comes to handling fragmentation, and the
document would be better guidance if that was referenced.
Also:
"When an lwB4 receives an IPv4 packet from its connected host that is
larger than the MTU size after encapsulation, the lwB4 MUST fragment
the IPv4 packet before encapsulation."
If the DF flag is set, the packet shouldn't be fragmented, instead PMTUD
mechanism should be honored. Right? Fragmenting an IPv4 packet with DF bit
set sounds like a bad thing.
Now, going on to ICMP handling.
The wording in section 8 at least to me could read like an implementor
could implement "drop all ICMP on the outside interface" and say they've
complied to the SHOULD in the second paragraph. I think the logic in
section 8 should be that an implementor SHOULD implement 1, 2 and 3, and
if they don't, then they SHOULD drop all ICMP. Right now it's SHOULD for
(1-3 OR drop). I don't think the "drop" option should be in the initial
SHOULD. So wrapping 1-3 in the initial SHOULD, and then say alternative to
this is to drop.
Also, the RFC6269 reference, RFC6269 is an informational issues document,
it doesn't give guidance to implementors on how to solve the problem
(right?). In the next-to-last paragraph there is guidance to how to solve
the problem. I think the better way would be to bring up the
second-to-last paragraph of section 8 to between paragraph 1 and 2, and
then look at what the 3 bullet points says and if they're mentioned in
RFC5508 and if they are, just point to RFC5508 instead. So the flow would
be RFC6269 points out the problem, to solve it, implementor SHOULD
implement 5508, and then have the current "either/or" sections say what's
specific to lw4o6, and have a last entry to say that if proper ICMP
handling isn't implemented at all, SHOULD drop the packet.
So to sum up above, section 8 seems to me to contain enough information, I
would just like to see it structured in a different way/order and the
logic checked so implementors do the right thing. Right now I find it a
bit hard to understand.
--
Mikael Abrahamsson email: [email protected]
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
