hi Remi,

it a little confuses me that the new version introduces 2 variants - what
is the technical difference of 4rd-U encapsulation variant vs.
MAP-E? (except written in a single or some separated documents)

on the other hand, it is unfair to state the benefit "Header-mapping
provides more complete transparency to IPv4 packets than solutions using
twice the IPv6/IPv4 translation of RFC6145" without mentioning the (at
least the following two pieces of) cost: 1. losing the compatibility with
single translation; 2. putting ICMPv4 PDU as the payload of IPv6 directly,
with neither IP header nor ICMP header has the address checksum information
- this will disable firewall preventing attacks.

best regards,
maoke
2012/1/29 Rémi Després <[email protected]>

> Hello all,
>
> The new version of the proposed unified 4rd has just ben posted.
> It is available at:
>  http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03
>
> A major evolution since the previous version has been to have in it two
> variants.
> - The Header-mapping variant is as in the previous version
> - The Encapsulation variant is added after comments received, and
> accepted, that some use cases cannot be satisfied if the Header-mapping
> variant is the only one.
>
> Compared to the alternative approach of several MAP documents, the
> single-document approach is expected to avoid duplicate specifications, and
> to facilitate consistency checks of the design.
> Besides:
> - Header-mapping provides more complete transparency to IPv4 packets than
> solutions using twice the IPv6/IPv4 translation of RFC6145.
> - It has also the advantage of a simpler and self-sufficient specification.
> - The algorithm which permits BRs to forward datagram fragments without
> datagram reassembly is included.
> - The problem of fragmented datagrams from shared address CEs that must
> have different Identification if they go to common destinations is covered.
> - The design re-introduces the Domain IPv6 suffix which in some earlier
> 4rd designs, and somehow has been lost.
> - The port-set algorithm is without parameter.
>
> All questions and comments will be most 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

Reply via email to