On Mar 1, 2012 1:22 AM, "Ole Trøan" <[email protected]> wrote: > > Qi, > > >> It's a good draft and makes a nice support for the MAP mechanism. I would like to propose some comments on the draft(sorry if they've been discussed ever). Please check below. > >> ----------------------------------------------------------------- > >> Section > >> > >> > >> 5.2 > >> Packet Forwarding Behavior on MAP-E > >> BR > >> > >> Part (b) BR reception of an IPv6 packet > >> BR derives a CE IPv6 address from > >> the IPv4 source address or the IPv4 source > >> address and the source port in the encapsulated > >> IPv4 packet based on the BMR. If the CE IPv6 > >> address is eqaul to the IPv6 source address in > >> the received IPv6 packet, BR decapsulates the > >> IPv4 packet and then forward it via the IPv4 > >> interface. > >> > >> I have a few questions here. > >> 1. How can the BR get from an IPv6 packet the IPv4 source address or the IPv4 source address and the source port in the encapsulated IPv4 packet? > > In case of MAP-E, IPv4 packet is encapsulated in IPv6. The above text is for check the validation of the received packet. In terms of IPv6 packet received at BR, the IPv6 source address should be based on the IPv6 prefix delegated to CE. Also, according to the MAP rule, IPv4 address and port number can be derived from the same delegated IPv6 prefix. So, BR can calculate CE IPv6 address from the IPv4 source address and source port number in IPv4 packet encapsulated in the received IPv6 packet. If the calculation is failed, then the packet could be dropped. If the calculation is succeeded but the calculated CE IPv6 address is not matched to the source IPv6 address in the received IPv6 packet, then the packet could be dropped. > > > > [Qi Sun] I have 2 questions here. > > [Qi Sun] 1.My understanding is that the BR get the IPv4 related info from the IPv6 packet by reading the specific bits in the IPv6 packet, that is the IPv4 address is put in the exact position in the IPv6 packet. Right? > > [Qi Sun] 2.You said,'If the calculation is failed, then the packet could be dropped.' I think this action may cause the data loss of normal IPv6 flow. > > > >> 2. If the received IPv6 packet is a normal one, instead of an IPv4-encapsulated packet, what will the BR do? That is, dose the BR can act as a normal router? > > > > In this case, BR should handle this IPv6 packet based on the normal IPv6 routing because the next header is not IPv4 in this case. > > > > [Qi Sun] Agree :) > >> 3. What can cause the inequality between the derived CE IPv6 address and the IPv6 source address in the received IPv6 packet? And what will BR do with it, discard it ? > > > > It might depend on the implementation. But the derived CE IPv6 address must be same as the IPv6 source address in case of MAP-E because the derived CE IPv6 address should be the tunnel end-point address on the CE. So, the received packet should be discarded or not processed as MAP-E packet. > > > > [Qi Sun] You mean, in the MAP-E case, the inequality won't happen, right? > > > > My question is that whether the MAP-E nodes can be deployed with the normal IPv6 nodes. If can't, won't it cost too much to deploy brand new MAP-E domains for SP? If can, is it possible to be stated in the draft, with the considerations of BR handling non-MAP-E IPv6 packets ? > > MAP-E is no different than any other tunnel in this regard. MAP-E packets are terminated at a single IPv6 address on the BR. all other IPv6 traffic will be forwarded like normal. i.e. traffic with a destination address not being the BR's MAP-E IPv6 address. >
What is the expected behavior when that address becomes unavailable? Cb > cheers, > Ole > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
