Re: [Softwires] Fw: New Version Notification fordraft-sarikaya-softwire-dslitemobility-00

["Yiu L. Lee" <yiu_lee at cable.comcast.com>]

Title: 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.
>
> >
> >- 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
>  
>
>