second point, on tunnel and transparency.

2012/4/11 Rémi Després <[email protected]>

> 6. The statement that "double translation is also a sort of tunneling in
> general sense" is IMHO confusing in view of its lack of IPv4 end-to-end
> transparency.
>

limited to the definition of "a source route that circumvents conventional
routing mechanisms", IMHO, it has no business with the end-to-end
transparency and therefore not confusing with explictly specifying "in
general sense".


> The statement that "It needs further investigation to ensure if 4rd-U is
> qualified to be called as a tunnel in the narrow sense" expresses a doubt
> without substance to justify it.
>

because 4rd-u draft calls itself a "tunnel". the commentary identifies it
is surely a general-sense tunnel. the commentary tries to understand
whether it is also a narrow-sense tunnel but did not yet concluded at the
time of writing. now it looks we can conclude that 4rd-u is hard to be
called as a tunnel in the narrow sense. see below, regarding the
transparency.


> 4rd-U only claims that IPv4 packets traverse ISP domains transparently
> (unless they have IPv4 options in which case the domain signals it doesn't
> support them).
>

now we have clearified the checksum end-to-end transparency covering
payload length and payload protocol type is lost for IPv4/ICMPv4 datagrams
in 4rd-u. i suggest 4rd-u draft is revised, if anyway the work will
continue, to reflect this understanding too, by explicitly claiming that
4rd-u keeps end-to-end transparency for most of IPv4 fields but checksum
covering payload length and payload protocol type (instead of only
mentioning options) when the payload is ICMPv4, less than the transparency
provided by encapsulation.

commentary document will include this understanding in next revision,
without judging how severe this concern is in practice.

if no further significant dissent, this subsubject is closed.

- maoke
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to