OOPS,
Joel Hapern signaled me that the normal procedure hadn't been followed (WG
consensus _before_ posting a newly edited version).
Thanks to you, Joel, and sorry for this, due to my inexperience (first time in
this situation).
Please take version -01 as just one particular proposal, approved by only the 5
authors so far.
All comments, including objections, remain more than ever welcome.
Regards,
RD
Le 2012-06-19 à 15:28, Rémi Després a écrit :
> Dear all,
>
> The main difference between -00 and -O1 concerns protection against address
> or protocol corruption during 4rd-domain traversal:
> Problem: the CNP only protected IPv4 addresses of full-or-shared-address CEs?
> In particular, they didn't protect IPv4 addresses embedded in BR-destined
> IPv6 addresses (an overlook)
> Solution: include a checksum of IPv4 addresses and protocol in the flow label
> field
> . It provides the desirable protection in a simple and intuitive way
> . It remains compatible with the flow-label specification (see below)
>
>
> Relationship with FLs of RFC6437 is analyzed as follows:
>
> a) RFC6437 says "A node that forwards a flow whose flow label value in
> arriving packets is zero MAY change the flow label value. In that case, it
> is RECOMMENDED that the forwarding node sets the flow label field for a flow
> to a uniformly distributed value as just described for source nodes. ... In
> such cases, a flow can be defined by fewer IPv6 header fields, typically
> using only the 2-tuple {dest addr, source addr}."
>
> b) In CEs and BRs, arriving packets are IPv4, i.e. equivalent to packets
> without FLs.
>
> c) In RFC2119, "RECOMMENDED" means that "there may exist valid reasons in
> particular circumstances to ignore a particular item, but the full
> implications must be understood and carefully weighed before choosing a
> different course".
>
> d) Implications, which have been well understood, have also been well
> weighted:
> - With this, FLs of 5-tuple flows aren't evenly distributed FLs, contrary to
> what is recommended
> - BUT this maintains IPv4 addresses-and-port protection without needing any
> extra header between the IPv6 header and the unchanged IP payload, a
> desirable feature of 4rd.
>
> Comments on all aspects of the proposal are welcome.
>
> Regards,
> RD
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
