Hi Yiu,
> >From: Yiu L. Lee <[email protected]> >To: Behcet Sarikaya <[email protected]>; [email protected] >Sent: Tuesday, July 14, 2009 10:42:21 PM >Subject: Re: [Softwires] Fw: New Version Notification >fordraft-sarikaya-softwire-dslitemobility-00 > > >>- 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. >> Yes, this is good action point. I believe the same applies to HA and CGN, right? We need to discuss the changes required on this more. >>> >>>- 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) >> Yes, that seems to be DS-Lite requirement. Which holds true in DS-Lite domain and not necessarily in any other domain. >>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? >> Yes, if MN does inter-domain handoff then it gets a different IPv4 CoA. That is the reason why MN needs an IPv4 HoA. >>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) >> I don't know if I need to add any text about this issue to the draft? >>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. >> Ooh, I see, you are talking about http://tools.ietf.org/html/draft-ymbk-aplusp-04 So use A+P together with DS-Lite? Regards, Behcet _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
