Hi, Tetsuya-san, Thanks for your comments.
Le 2012-03-28 à 00:42, Tetsuya Murakami a écrit : > Hi Remi, > > Thank you for having the informational meeting of 4rd-u. I can understand > 4rd-u very much. > > As you mentioned during the informational meeting, 4rd-u defines the new type > of the translation between IPv4 and IPv6 instead of MAP-E/MAP-T. Reversible header translation, yes, thus achieving transparent tunneling of IPv4 packets. > Also, this new type of the translation has no relationship with the mapping > rule. Hence, I think 4rd-u draft can be changed only to define the new type > of the translation similar to MAP-E/MAP-T by removing any text related to > mapping rule and refer to MAP for the mapping rule. In this case, it depends > on deployment scenario to choose MAP-E, MAP-T or 4rd-u. The purpose of U is to remove the need for ISPs to make a deployment choice. If U is standardized, ISPs can safely deploy THE standard, without having to make a choice. > Also, as I mentioned during the meeting, I double-checked the current > implementation of IPv6 stack (Linux/BSD). If implementing 4rd-u, IPv6 stack > gives received IPv6 packet to 4rd-u module after processing it. But, > according to the current implementation of IPv6 stack, IPv6 stack totally > removes IPv6 fragment header when IPv6 stack finds IPv6 fragment header and > processes it. Thanks for this confirmation. > Since 4rd-u module gets the packet after IPv6 stack processes the packet, > IPv6 fragment header is not present when 4rd-u module gets the packet. 4rd-u > utilizes IPv6 fragment header to carry some of IPv4 information. But all > information embedded in IPv6 fragment header is disappeared in IPv6 stack > before 4rd-u module gets the packet. Hence, in order to keep/pass the > information embedded in IPv6 fragment header to 4rd-u module, I think the > existing IPv6 stack needs to be changed. > > In terms of MAP-T, IPv6 fragment header is also required but no information > is embedded in IPv6 fragment header. Also, the current IPv6 implementation > can give only information if there is a fragment header or not. So, MAP-T can > know if there is a fragment header or not after IPv6 stack processes the > packet without any change of the existing IPv6 stack. Yes, support of 4rd-U in Linux/BSD as you describe it implies an upgrade of the IPv6 module so that it conveys to higher layers not only the fact that there was an extension header, but also its contained packet ID. However, in order to be capable to forward IPv6 fragments without packet reassembly (important for performance), BRs will have to do some processing below the API you are referring to. Different implementations are possible. > I think MAP/4rd-u are transition technology and so it is good to eliminate > any impact on the existing implementation of IPv6 stack as much as possible. As much as possible, I agree, but if some adaptation is needed to avoid two incompatible variants, the new code is worth having. Regards, RD > Thanks, > Tetsuya Murakami > > On 2012/03/26, at 11:57, Rémi Després wrote: > >> Hi, all, >> >> With some co-authors of the 4rd-U proposal, we will hold an informal meeting >> about it. >> - subject: Clarification on what 4rd-U is designed to do, and how it does it. >> - Participants: whoever is interested in a good understanding of the 4rd-U >> proposal. >> - place: room 204 >> - time : Tuesday 15:15 (duration depending on questions, maximum till >> 16:30). >> >> The meeting can be seen as a bar BOF... without drinks in the room. >> >> See you there if interested, >> 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
