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. cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
