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

[Behcet Sarikaya <behcetsarikaya at yahoo.com>]

Hi Yiu,
  Thanks for your comments. Please see my replies inline below.

>
>From: Yiu L. Lee <yiu_lee at cable.comcast.com>
>To: Behcet Sarikaya <sarikaya at ieee.org>; softwires at ietf.org
>Sent: Tuesday, July 14, 2009 11:10:23 AM
>Subject: Re: [Softwires] Fw: New Version Notification fordraft-sarikaya-softwire-dslitemobility-00
>
>Hi Behect and Frank,
>
>Thanks for putting this draft together. I have few comments/questions: 
>
>- Introduction, 5th paragraph. Mention the MAG is the ds-lite softwire initiator and CGN collocates with LMA (HA). 
>

Sure, will do.

>
>- Does the ds-lite CGN and LMAA use the same IPv6 address?

Yes. What do you think?

>
>- For client Mobile IPv6, I agree that the ds-lite CGN should collocate with HA.

You don't agree with PMIPv6 one?

>
>- It should recommend to use public ipv4 addresses for the CGN pool.. This can greatly reduce the complexity to avoid double-NAT.

I don't understand, please elaborate.

>
>- Discuss DNS proxy placement for IPv4 client as such DNS traffic won't run over ds-lite softwire.
>

Yes, sure, like Sec. 7 in -01 DS-lite draft.

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

>- 3.2 mentions about GRE. It is worth to mention if GRE is used, the MAG will run GRE-in-IPv6 instead of IPv4-in-IPv6. Either case, only one tunnel protocol is used rather than tunnel-in-tunnel.
>

Agree.

>- 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?

Since MN may move to a different domain that assigns a different (possibly private) CoA MN needs to be assigned an 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. 

>
>    * 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.

>

Regards,

Behcet