Le 2012-04-03 à 11:40, Ole Trøan a écrit :

>> If you would have a detailed scenario where ANY transparency difference 
>> could be noticeable e2e between a MAP-E tunnel and a 4rd-U tunnel, this 
>> sentence would be fair.
>> However, you haven't shown such a scenario, and AFAIK you can't have one 
>> because it doesn't exist.
>> The above assertion, being wrong, is therefore misleading.
> 
> there is more to this than comparing the IPv4 packet put into to the 4rd-U 
> cloud against the packet exiting the 4rd-U cloud.

What else?

> (from that perspective MAP-T and 4rd-U are for most practical solutions equal 
> (IMHO)).

Nothing new here, but this is only an opinion, not a technical consideration.

> 1) MAP-E supports independence of IPv4 and IPv6 addressing. by using hub and 
> spoke mode with a separate
>  mapping rule per subscriber. in this mode e.g only ports could be embedded 
> in the address.

New requirement?
New feature?
Your draft says "Each MAP node in the domain has the same set of rules."
It's getting very confusing.

BTW, is this something you claim to have been tested?

If you want to pursue this point, a use-case example with its mapping rules 
could help to understand what you have in mind.



> this is not
>  possible in a translation solution like 4rd-U.
> 
> 2) a node inside the network will treat translated packets different from 
> encapsulated ones.

Yes, but so what?

>  e.g. for the purposes of counting or for applying features. for an 
> encapsulated packet both the complete
>  IPv4 datagram and the IPv6 header is available, and different features can 
> be applied to both.

I don't see what would be missing with 4rd-U: 
- the IPv4 payload is available
- IPv4 source and destination addresses are available in a fixed position of 
IPV6 addresses
- IPv6 packets that are header-mapped IPv4 packets are recognizable wit the V 
octet of the CE address

Cheers,
RD


> 
> Ole
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to