Re: [Softwires] New version of 4rd-U - with plain Encapsulation as a variant

[Rémi Després <[e-mail]>]

Le 2012-01-30 à 11:47, Maoke a écrit :

> 
> 2012/1/30 Rémi Després <[e-mail]>
> Hi Maoke,
> 
> Good to see you back in technical discussions, of which we had so many useful ones.
> More in line.
> 
>  
> Le 2012-01-29 à 05:38, Maoke a écrit :
> 
>> 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)
> 
> No difference (as said).
> 
>>  
>> 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.
> 
> Not clear AFAIK.
> It can be discussed if you expand, but less subjective issues like those below are IMHO more important.
> 
>> losing the compatibility with single translation; 2.
> 
> I don't see this because, in my understanding:
> - IPv6-only CPEs, in order to work with IPv4 shared addresses processed by BRs are stateless, MUST be modified anyway.
> - Unmodified IPv6-only CPEs don't need to be modified to work with shared addresses processed by stateful NAT64/DNS64 (with known limitations NAT-related limitations, but this is understood). 
> - 4rd-U can coexist with NAT64/DNS64 in ISP networks. (Provided IPv4 address-spaces used by NAT64 and 4rd-U are disjoint, there is AFAIK no operational issue.
>  
>  
> well, if address spaces (as well as routings) are totally disjoint, it is hard to call it as "coexist", ;-)

Do you mean it would be difficult to route some of the ISP IPv4 prefix(es) to the NAT64 and some to the 4rd-U BR?
Isn't there already the same need if there are several NAT64s? (They must work with disjoint IPv4 address spaces.)
  

> and definitely there is no compatibility to single translation in RFC6145 at all. as the result, RFC6145 provides a unified solution, while 4rd-U requires ISP (who prefer to use translation) disjointly deploy their networks for single and double translations.
>  
>  
> 
> If you have a specific configuration that illustrates your concern, it could be discussed with more details.

Could you, for the sake of a less abstract discussion, describe at least one configuration you have in mind, in which some IPv4 addresses are statelessly shared, and in which there is the RFC6145 compatibility you are talking about.
Without that, I can't figure out what you mean. 
(The goal remains customer service, without harm if this happens to be possible without full support of RFC4125, right?)

RD





> 
>>  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.
> 
> 
> For a site having a customer-provided CPE that integrates a firewall to take advantage of stateless IPv4-address sharing, its FW  MUST be upgraded anyway. Adding to it 4rd-U support is for this a logical solution.  
>  
>  
> the attack preventing should be done everywhere, including in the middle of the IPv6 domain. however, IPv6-containing-ICMPv4 loses information checksum regarding the original IPv4 addresses and therefore (no matter how the firewall is upgraded) the consistency check is not possible. it should be a big security concern.
>  
> this is one of the major reasons that i don't think putting ICMPv4 into IPv6 directly is a good idea. either full encapsulation or Simple IP/ICMP translation is far better.
>  
> best,
> maoke
>  
>  
> If the FW-CPE is not modified, its operation across IPv6-only networks remains IPv6-only (translatable to IPv4 by NAT64 if supported by the ISP).
> Adding a note on this in the document would be possible, if found useful.  
> 
> Cheers,
> RD
> 
> 
>>  
>> best regards,
>> maoke
>> 2012/1/29 Rémi Després <[e-mail]>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>> 
> 
>