>> >- Does the ds-lite CGN and LMAA use the same IPv6 address? > > Yes. What do you think? > > [YL] If we do this, it will impose the req to the LMA such that the LMA and > CGN must be tightly coupled. So we must scale the LMA and CGN together rather > than independently. > >> > >> >- For client Mobile IPv6, I agree that the ds-lite CGN should collocate with >> HA. > > You don't agree with PMIPv6 one? > > [YL] The only thing I have yet 100% agreed is to use the same address for both > LMAA and CGN. > >> >- 3.1 Step 2. Since multiple MNs may use the same MAG to go to the same >> destination, the LMA can't search only the binding cache for the dst IPv4 >> address (128.0.0.1). Instead, the LMA must search the <MAG-IPv6-addr, >> MN-IPv4-addr, src-port, transport-protocol, dst-IPv4-addr, dst-port, >> transport-protocol> tuple. >> > > > Binding cache and NAT state are two different types of states. Binding cache > does not contain transport layer info you mentioned above and is searched > first. Next NAT state is searched. > I hope this is clear, maybe we should make it more clear in the text. > > [YL] That¹s fine. I just want to make it clear that dst address alone can¹t > uniquely identify the flow. > >> >- Section 4 is really puzzling me. Why does MN need to get the IPv4 home >> address from HA? Can it request only the IPv6 home address and use the IANA >> assigned ds-list IPv4 address (e.g. a.b.c.d)? Then the MN will source all >> IPv4 datagram with this well-known address. >> > > > Actually this is an interesting point. > The way DSMIPv6 works is every MN is given a home address. > In normal mobility scenario, MN would get a different CoA from each AR. In > Section 4, local AR is where DHCP Proxy is located. > When MN moves to a different AR it could get a different CoA but its home > address remains the same. > > However ds-lite MN is always assigned the same CoA, right? > > [YL] No, my understanding is the MN will get different IPv6 CoA when it moves > to different AR. But the IPv4 address will remind the same (hard-coded to MN > similar to loopback) > > Since MN may move to a different domain that assigns a different (possibly > private) CoA MN needs to be assigned an HoA. > > [YL] You mean domain hand-off? > > I hope this clarifies. > >> >- Section 4.2. This is not true. The well-known IPv4 address is unique to >> the client because the binding table will index the client by both the IPv6 >> Home address and the well-known address. As such, all the ports are available >> to the client. >> > > > Really? DS-Lite -00 draft Sec. 7.1 discusses per customer port allocation. > I couldn't read yet -01 draft. > > [YL] That section discusses the static port mapping for inbound traffic to the > host behind the ds-lite home gateway. So each home gateway will be given a > small number of ports. The user can inform the CGN (out-of-band) to > port-forward the traffic to a specific host behind the gateway. This function > is to mimic today home gateway to port forward traffic from one port to > another (e.g. Port-forward 8080 to 192.168.1.10:80) > > You can find 01 here: > http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite-01 > >> > >> > * There is cost for client MIPv6 . The MIPv6 client must send keepalive >> to maintain the NAT binding in the HA. > > Keepalives are already mentioned in RFC 5555. Maybe we need some text here as > you said. > >> >This is less than ideal in battery sensitive mobile device. So a combination >> of A+P and >> >ds-lite may be a better fit in this model. > > I don't understand this please elaborate. > > [YL] A+P suggests that each user will be given a specific range of ports. > Since these ports are ³given² to a specific client, the CGN will create a > static NAT binding instead of dynamic NAT binding. As such, no keepalive is > required for the client to punch hole. > > Regards, > Yiu > > > > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
