Subject: [Softwires] Fw: New Version Notification for draft-sarikaya-softwire-dslitemobility-00

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 14 Jul 2009 08:01:57 -0700 (PDT)

Hi all,
  We submitted this draft, please send your comments to the list.

Regards,

Behcet

----- Forwarded Message ----
> From: IETF I-D Submission Tool <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Monday, July 6, 2009 10:28:32 AM
> Subject: New Version Notification for draft-sarikaya-softwire-dslitemobility-00
> 
> 
> A new version of I-D, draft-sarikaya-softwire-dslitemobility-00.txt has been 
> successfuly submitted by Behcet Sarikaya and posted to the IETF repository.
> 
> Filename:    draft-sarikaya-softwire-dslitemobility
> Revision:    00
> Title:        Dual-stack Lite Mobility Solutions
> Creation_date:    2009-07-06
> WG ID:        Independent Submission
> Number_of_pages: 12
> 
> Abstract:
> Two solutions are presented to show how to use Dual-Stack Lite
> transition technique in mobile networks: one for Proxy Mobile IPv6
> and the other for Dual-Stack Mobile IPv6.  Proxy Mobile IPv6 allows
> IPv4 nodes to receive mobility services using an IPv4 home address.
> Mobile node can have IPv4 only operation by sending IPv4 datagrams
> which are encapsulated by the Mobile Access Gateway (MAG) at the DS-
> lite home router and and tunneled to Local Mobility Anchor (LMA)
> which is also DS-lite carrier-grade Network Address Translator (NAT).
> In case of client based mobility using DSMIPv6, mobile node is a
> dual-stack node and it can receive an IPv4 home address from the home
> agent which is co-located with DS-lite carrier-grade NAT.  Mobile
> node (MN) encapsulates IPv4 datagrams in IPv6 which are decapsulated
> at the home agent (HA).  Mobile network could be WiMAX network or
> 3GPP Long Term Evolution network.
>                                                                                 
>   
> 
> 
> The IETF Secretariat.

---

From: "Yiu L. Lee" <[email-masked]>
Date: Tue, 14 Jul 2009 12:10:23 -0400

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

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

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

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

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

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

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

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

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

* There is cost for client MIPv6 . The MIPv6 client must send keepalive to
maintain the NAT binding in the HA. 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.

Thanks,
Yiu

On 7/14/09 11:01 AM, "Behcet Sarikaya" <[email-masked]> wrote:

>> > Subject: New Version Notification for
>> draft-sarikaya-softwire-dslitemobility-00
>> >
>> >
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 14 Jul 2009 13:46:11 -0700 (PDT)

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

>
>From: Yiu L. Lee <[email-masked]>
>To: Behcet Sarikaya <[email-masked]>; [email-masked]
>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,
>
>- 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 

I don't understand this please elaborate.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 14 Jul 2009 13:46:11 -0700 (PDT)

Hi Yiu,

Sure, will do.

Yes. What do you think?

Agree.

I hope this clarifies.

Regards,

Behcet

---

From: "Yiu L. Lee" <[email-masked]>
Date: Tue, 14 Jul 2009 23:42:21 -0400

> [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.
> 
>> >
> [YL] The only thing I have yet 100% agreed is to use the same address for both
> LMAA and CGN.
> 
> 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.
> [YL] That¹s fine. I just want to make it clear that dst address alone can¹t
> uniquely identify the flow.
> 
>  In normal mobility scenario, MN would get a different CoA from each AR. In
> Section 4, local AR is where DHCP Proxy is located.
> [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.
> 
>> Home address and the well-known address. As such, all the ports are available
>> to the client.
>> >
> 
> [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
> 
>> >
> [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
>  
> 
>      
> 
>

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 15 Jul 2009 09:23:16 -0400

> Hi Sarikaya,
> [YL] Finally I got a chance to read RFC5213. When the LMA created the binding
> cache for the MAG, wouldn¹t the LMA create the binding cache based on the
> <MN-Identifier, MAG¹s HA and MAG¹s CoA>? I thought the binding cache is used
> for identifying which MN anchors to the LMA. Why does LMA need to search the
> dst-addr in the encapsulated IPv4 datagram in the binding cache?
> 
> Thanks,
> Yiu
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 15 Jul 2009 11:39:02 -0700 (PDT)

Hi Yiu,

>Sent: Wednesday, July 15, 2009 8:23:16 AM
>>[YL] Finally I got a chance to read RFC5213. When the LMA created the binding cache for the MAG, wouldn’t the LMA create the binding cache based on the <MN-Identifier, MAG’s HA and MAG’s CoA>? I thought the binding cache is used for identifying which MN anchors to the LMA. Why does LMA need to search the dst-addr in the encapsulated IPv4 datagram in the binding cache?
>>

Thanks for checking this in detail.

This was to see if the packet has to be routed back down stream for local routing because the corresponding node could be connected to the same LMA. Not for anything else. Maybe we should add some text here to avoid confusion.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 15 Jul 2009 11:55:33 -0700 (PDT)

Hi Yiu,

>Sent: Tuesday, July 14, 2009 10:42:21 PM
>>[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.

>>[YL] The only thing I have yet 100% agreed is to use the same address for both LMAA and CGN.
>>
>>[YL] That’s fine. I just want to make it clear that dst address alone can’t uniquely identify the flow.
>>
>>[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. 

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

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