Subject: Re: [netlmm] Working Group Last Call - draft-ietf-netlmm-pmip6-ipv4-support-05

From: Julien Laganier <[email-masked]>
Date: Wed, 5 Nov 2008 15:33:34 +0100

Another, late, comment:

> .  Constructing the Proxy Binding Acknowledgement Message
>
>
>    The local mobility anchor when sending the Proxy Binding
>    Acknowledgement message to the mobile access gateway MUST
> construct the message as specified in Section 5.3.6 of [RFC-5213].
>    Additionally, the following considerations MUST be applied.
>
>    o  Section 5.3.6 of [RFC-5213] requires the local mobility anchor
> to include at least one instance of Home Network Prefix option [RFC-
> 5213] in the Proxy Binding Acknowledgement message that it
> sends to the mobile access gateway.  However, if the received Proxy
> Binding Update message has only the IPv4 Home Address option [ID-
> DSMIP6] and did not contain the Home Network Prefix option(s), then
> the local mobility anchor MUST NOT include any Home Network Prefix
> option(s) in the reply.
>
>    o  The IPv4 Address Acknowledgement option [ID-DSMIP6] MUST be
>       present in the Proxy Binding Acknowledgement message.
>
>       1.  If the Status field is set to a value greater than or equal
> to 128, i.e., if the Proxy Binding Update is rejected, then there
> MUST be an IPv4 Address Acknowledgement option [ID-DSMIP6]
> corresponding to the IPv4 Home Address option [ID-DSMIP6] present in
> the request and with the IPv4 address value and the prefix length
> fields in the option set to the corresponding values in the request. 
> The status field value in the option must be set to the specific
> error code.
>
>       2.  For all other cases, there MUST be an IPv4 Address
>           Acknowledgement option for carrying the IPv4 home address
>           assigned for that mobility session and with the value in
> the option set to the allocated IPv4 address.  The prefix length in
> the option MUST be set to the prefix length of the allocated address.
>  The status field value in the option must be set to 0 (Success).

When the MAG requests both IPv4 HoA and IPv6 HNP, the text above makes 
it impossible for the LMA to reply with only the IPv4 HoA, or only the 
IPv6 HNP. Is that intentional?

It seems it would be useful for the LMA to be able to downgrade 
dual-stack IP connectivity requests from the MAG to IPvx only, and 
provide an appropriate, below 128, cause reason, e.g. IP version 
limitation.

What do you think?
 
--julien
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 5 Nov 2008 09:09:59 -0800 (PST)

Hi Julien,

> provide an appropriate, below 128, cause reason, e.g. IP version

The IPv4 Address Ack option has a status code and that can indicate if
the request is accepted or not. The option presence requirement is not
indicative of address assignement.

We should clearly allow this, will rephrase to clarify.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Wed, 5 Nov 2008 18:15:57 +0100

On Wednesday 05 November 2008, Sri Gundavelli wrote:
> Hi Julien,
>
> > When the MAG requests both IPv4 HoA and IPv6 HNP, the text above
> > makes it impossible for the LMA to reply with only the IPv4 HoA, or
> > only the IPv6 HNP. Is that intentional?
> >
> The IPv4 Address Ack option has a status code and that can indicate
> if the request is accepted or not. The option presence requirement is
> not indicative of address assignement.
>

Ok. But another question then, in case the MAG requested for both IPv4 
and IPv6, would you use the status code in the IPv4 Address Ack to 
cover both the two scenarios:

- LMA decided to allocate IPv4 only
- MAG decided to allocate IPv6 only

?

Thanks,

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 5 Nov 2008 09:22:25 -0800 (PST)

> - MAG decided to allocate IPv6 only

We support both the cases.

True, there is some inconsistency here. We have the IPv4 Address Ack
option, specified in DSMIP, and not for the IPv6 HNP option. So, we
are requiring the IPv4 Address Ack in the reply, if the request is
accpeted or rejected. For IPv6, the option absence is the indicator.
We probably should not require the IPv4 Address Ack in the reply,
if the request is rejected.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Wed, 5 Nov 2008 18:40:56 +0100

On Wednesday 05 November 2008, Sri Gundavelli wrote:
> >>> makes it impossible for the LMA to reply with only the IPv4 HoA,
> >>> or only the IPv6 HNP. Is that intentional?
> >>>
> >>> dual-stack IP connectivity requests from the MAG to IPvx only,
> >>> and provide an appropriate, below 128, cause reason, e.g. IP
> >>> version limitation.
> >>
> >> The IPv4 Address Ack option has a status code and that can
> >> indicate if the request is accepted or not. The option presence
> >> requirement is not indicative of address assignement.
> >>
> > Ok. But another question then, in case the MAG requested for both
> > IPv4 and IPv6, would you use the status code in the IPv4 Address
> > Ack to cover both the two scenarios:
> >

All right Sri, that's fine then. [FYI - 3GPP Rel-8 does need that 
functionality.]

--julien

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 05 Nov 2008 11:48:05 -0600

Sri,

As a followup:

>> - MAG decided to allocate IPv6 only

Why not assign an IPv6 HNP to the MN as a default even if the host requests
an IPv4 only address?
PMIP6 as a protocol for network based mobility for IPv4 only hosts IMO
defeats the purpose. Supporting IPv4 only hosts is fine. But given that this
is an IPv6 network based mobility protocol, I think that the v6 HNP should
be always assigned to the MN.

-Raj

---

From: Julien Laganier <[email-masked]>
Date: Wed, 5 Nov 2008 18:57:44 +0100

Raj,

On Wednesday 05 November 2008, Basavaraj Patil wrote:
> Why not assign an IPv6 HNP to the MN as a default even if the host
> requests an IPv4 only address?
> PMIP6 as a protocol for network based mobility for IPv4 only hosts
> IMO defeats the purpose. Supporting IPv4 only hosts is fine. But
> given that this is an IPv6 network based mobility protocol, I think
> that the v6 HNP should be always assigned to the MN.

As I said in my other note to Sri, 3GPP does have a requirement on this 
feature, thus it makes sense to support it since it doesn't have bad 
side effects. 

Otherwise the protocol will inherit one more 3GPP vendor specific option 
without any gain, which I believe is counter-productive to the goal of 
the IETF.

My 2 cents,
 
--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 5 Nov 2008 10:00:33 -0800 (PST)

Hi Raj,

> be always assigned to the MN.

We had some discussions in the past in the ML on this. The main
concern is the platform scalability. Forcing IPv6 support even
when its not needed, has a significant impact on the platform
resources, Binding Table, Routes in the RIB ... , we will see a
huge hit  w.r.t the number of bindings the LMA can support, so turn
off the feature when its not needed.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 05 Nov 2008 12:12:06 -0600

Sri,

On 11/5/08 12:00 PM, "Sri Gundavelli" <[email-masked]> wrote:

> concern is the platform scalability.

Scalability argument IMO is a bit weak. It depends on specific platform that
you have in mind. Also scalability itself can be addressed via other means.

> Forcing IPv6 support even

I don't think that the size of the binding table will be a major factor. If
a BCE for an MN is being created, having an IPv6 HNP as part of that BCE is
not going to cause scalability issues. IMHO I believe the issue about
resources, binding table (size I guess) are superficial at best.
With the current approach the PMIP6 protocol will end up being a solution
for network based mobility for IPv4 hosts (which is contrary to the protocol
intent).

Can you give an explicit example of how allocating an IPv6 HNP to every MN
served by an LMA will result in reduced scalability?

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 05 Nov 2008 12:18:58 -0600

Hi Julien,

> feature, thus it makes sense to support it since it doesn't have bad

I agree that there is really no downside to assigning an IPv6 HNP by
default. I hope the concern is not about running out of IPv6 prefixes.

> without any gain, which I believe is counter-productive to the goal of

Agree. Better to not have too many variants of the protocol.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 5 Nov 2008 10:23:06 -0800 (PST)

Hi Raj,

> you have in mind. Also scalability itself can be addressed via other means.

One of the key parameters for HA/LMA deployment is the binding scalability
and data throughput. A box that can support 5 million bindings, if it goes
down to 2 million bindings due to some feature that is not needed, if can
be avoided should be avoided.

> served by an LMA will result in reduced scalability?

There is a memory cost, each binding needs to hold these additional
parameters, IPv6 HNP, CoA ..etc. Routing table needs to be populated
with additional prefix routes, additional options in the PBU/PBA.
This is a cost.

Going back to our discussion on the UDP header optimization for data
path, like you wanted to avoid those additional few bytes, same thing,
drop it when not needed.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 05 Nov 2008 12:41:36 -0600

Sri,

> be avoided should be avoided.

Does the LMA support 5 million IPv4 only MNs? Or does this capacity claim
include MNs which are assigned IPv6 prefixes and IPv4 addresses? The LMA
needs to be capable of supporting MNs which may request IPv6 HNPs and IPv4
addresses. That is your capacity. IMO I don't consider the support for IPv6
in PMIP6 as being a feature that is not needed. I mean this protocol is
designed for supporting IPv6, right? Having IPv4 support is the add-on
feature here and not the other way around which is what you seem to be
saying above. 

Besides if the LMA supports only 2 mil bindings, and the deployment calls
for 5 mil, I think the operator would deploy the additional LMA. That is a
cost. But one that cannot be avoided anyway. Unless the operator is planning
on deployments with an assumption of a certain % of users being IPv4 only.

> with additional prefix routes, additional options in the PBU/PBA.

Memory is cheap. The additional options being carried in the PBU/PBA is a
non-issue since the signaling load is marginal. And this signaling is
happening on the links between the MAG and LMA which I think would be
provisioned with sufficient BW. If the additional options are going to be an
issue on the link, then I think there are much bigger issues w.r.t how you
are going to handle the traffic.
If we start optimizing the protocol using the cost-factor argument, then I
think we will need to look at many aspects of the protocol.

> path, like you wanted to avoid those additional few bytes, same thing,

You may be mixing up someone elses comments here.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 5 Nov 2008 10:50:17 -0800 (PST)

Raj,

> feature here and not the other way around which is what you seem to be

How else would you measure scalability of a box ? Its weight ?
Give me a metric. Do the math. If you are arguing that supporting
IPv6 feature, has no cost on the box scalability, there is not
much to argue. You are probably thinking from the handset
perspective. Memory is cheap, computing power is cheap, bandwidth
is cheap and so we can carry additional options, I agree with all of
it. :)

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 05 Nov 2008 14:10:31 -0600

Hi Sri,

On 11/5/08 12:50 PM, "Sri Gundavelli" <[email-masked]> wrote:

> Give me a metric. Do the math.

I guess you missed the point. Is the capacity in terms of the number of
connections supported based on only IPv4 hosts being served by that LMA? Or
does the LMA take into consideration that every host may require an IPv6
prefix and IPv4 address?

> If you are arguing that supporting
> much to argue. 

If the IPv6 capability on the box is going to add cost, why implement PMIP6?
You may as well implement PMIP4 which supports IPv4 hosts if that is what is
needed. PMIP6 requires IPv6 capability on the box. It is not optional. And
adding this additional HNP to the BCE IMO is not going to reduce your
sclability factor by half.

> You are probably thinking from the handset

Good. So why do you think the above do not hold for the LMA platform which
has scalability and cost issues ;) ?

-Raj

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 5 Nov 2008 12:13:44 -0800 (PST)

I support Raj.
In fact Julien and myself were the ones who brought this up first as Sri mentioned. I don't understand why Julien changed his mind now .

PMIPv6 searches the binding cache based on HNP, this is the distinctive feature of the protocol as opposed to MIPv6 which uses the home address. 

With the change this fundamental property of PMIPv6 is lost. There is no strong justification for it.

Regards,

Behcet

________________________________
From: Sri Gundavelli <[email-masked]>
To: Basavaraj Patil <[email-masked]>
Cc: [email-masked]; Julien Laganier <[email-masked]>; [email-masked]
Sent: Wednesday, November 5, 2008 12:50:17 PM
Subject: Re: [netlmm] Working Group Last Call - draft-ietf-netlmm-pmip6-ipv4-support-05

Raj,

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 5 Nov 2008 12:38:45 -0800 (PST)

Hi Raj,

> does the LMA take into consideration that every host may require an IPv6

Capacity is based on the number of sessions supported and that has the
dependency on the session state, including the routing state. When
a box is deployed, based on what is supported, the scalability is
measured. A box that can support X sessions with IPv4-only, will
support Y session with both IPv4 and IPv6 support. X > Y, unless
you want to argue its the other way round. The use of this metric
is at a deployment time and not at run time as you are pointing at,
in most cases.

In a deployment that is only supporting IPv4-only nodes, should the
network deal with IPv6 network configuration, should the MAG and
LMA deal with this additional state and when that is clearly not
needed. We argued on removing the additional UDP header for control
packets, because its not needed in a given architecture/deployment,
same thing here.

If you are keen on forcing IPv6 and there is a good reason, we can
discuss, assuming you are looking beyond a client centric view and
realizing the impact on the LMA and MAG which some other vendors
have to deal with. This is surely not an issue for an handset vendor.

Bottom line, forcing features which are not needed in all cases, has
an implication on the box/deployment cost and that has a negative
impact on the overall protocol itself. That was the motivation behind
retaining that flexibility in the protocol, in terms of allowing
IPv4-only or IPv6-only support.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 05 Nov 2008 15:04:28 -0600

Hi Sri,

> is at a deployment time and not at run time as you are pointing at,

You could support X IPv4 only sessions or Y IPv4/v6 sessions and Z IPv6 only
sessions. Would you agree that X = Z (or does the additional memory
requirement of the IPv6 HoA/CoA in the BCE cause Z to be < X.)? I don't
believe you can claim session capacity of an LMA based on supporting IPv4
only sessions. The LMA should support all types of hosts and hence the
capacity would be Y (IMO). Of course marketing and brochures will claim X or
posisbly even X+Y+Z as the capacity... :)
A deployment cannot foresee an LMA supporting only IPv4 hosts and hence
being provisioned for such.

> needed. 

A deployment supporting IPv4-only nodes should not be using PMIP6. Why use a
protocol and platforms that require IPv6.

> We argued on removing the additional UDP header for control

I have not followed this discussion. But I believe the discussion here is
not analogous to the use of UDP headers for control packets.

> If you are keen on forcing IPv6 and there is a good reason,

Because PMIP6 is a protocol for network based IPv6 mobility??? And the
support for v4 hosts/addresses is only an add-on????

> we can

I think you are making assumptions here that my interest is only from a host
perspective ;)

> impact on the overall protocol itself.

What feature are we forcing here? PMIP6 as per RFC 5213 assigns the host an
IPv6 prefix. Now what is being suggested is that there is no need for this
IPv6 HNP. You are changing the protocol. If RFC 5213 had allowed you to
establish a BCE without any address/prefix being assigned, I would agree
that a BCE could contain only an IPv6 prefix or IPv4 address or both. But
that is not the case.

What is the negative impact on the protocol if you were to assign the IPv6
HNP? Maybe I don't understand.

> That was the motivation behind

And I disagree with the motivation.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 5 Nov 2008 13:28:24 -0800 (PST)

Hi Raj,

To require/force IPv6 session allocation, even when not required is
not a protocol design issue, its a general direction issue. I'm ok
with this approach, if we decide to go that route with all extensions
and if we decide to mandate IPv6 requirement. Jari, any comment on
the direction ?

I do see only one point from your discussions that, since its an
extension to an IPv6 protocol, we should always mandate IPv6
session allocation or assume the hosts are always IPv6 capable,
irrespective of the fact that it may be deployed for IPv4-only
hosts/network. I dont agree with your other comments that it
has no impact on session scalability or on how deployments check
the box scalability ..., or the comments that memory/CPU/bandwidth
is cheap and hence all features or no featueres scale the same way.

Also, on a lighter note, this is not really an issue for vendor like
us with massive routing engines :) You are killing some other vendors :)

> I have not followed this discussion. But I believe the discussion here 
> is not analogous to the use of UDP headers for control packets.

Well, I will point you to your postings :). The cost is the same,
additional unneeded IPv6 options in signaling packets, like the
additional UDP header that you wanted to avoid when not needed.

Lets discuss this in Minneapolis.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 5 Nov 2008 18:37:09 -0500

Julien, Sri, 

> All right Sri, that's fine then. [FYI - 3GPP Rel-8 does need that 

We need to add some text that says at least one of the options, the IPv6
HNP or IPv4 Address Ack MUST be present in the proxy binding ack.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 5 Nov 2008 15:39:32 -0800 (PST)

> HNP or IPv4 Address Ack MUST be present in the proxy binding ack.

Vijay,

We have that for the request, we need to add the same for the
reply. Agree.

Sri

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Thu, 06 Nov 2008 10:07:20 +0200

Hello everybody,

IMHO scalability of a box like LMA or MAG would be is actually a combination
of things. Though, the FIBs, and RIBs are a part of it, there are also other
parameters (like user-plane capacity, etc.) I don't think the impact is
quite as direct as Sri explains it. However, there is definitely an impact.

That said, here in the IETF we have different responsibilities. One of them
is to make sure that the Internet works and is enhanced in a future proof
manner. There allocating an IPv6 address as part of the protocol does sound
good, and would be logical. Despite the scalability impact on products, we
might feel that adding IPv6 prefix for all hosts would be useful.

In that sense I would think giving the IPv6 prefix to everybody would be
useful. However, I do have one concern. Clients should never get an IPv6
address where there is no routing behind it. So, I would like to have the
text explain that IPv6 prefix is allocated if the LMA has IPv6 connectivity
- even when the network would assume the client cannot use it.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 6 Nov 2008 08:53:43 -0800 (PST)

This is a nice solution but not sufficient. The draft has text in other parts that assume that no HNP is assigned to MN.

So with some more changes we could resolve this issue in a good way.

Regards,

Behcet

________________________________
From: Sri Gundavelli <[email-masked]>
To: Vijay Devarapalli <[email-masked]>
Cc: [email-masked]; Julien Laganier <[email-masked]>; [email-masked]
Sent: Wednesday, November 5, 2008 5:39:32 PM
Subject: Re: [netlmm] Working Group Last Call -draft-ietf-netlmm-pmip6-ipv4-support-05

Vijay,

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 6 Nov 2008 09:00:30 -0800 (PST)

> - even when the network would assume the client cannot use it.

The MAG in the access network would have no clue about the IPv6 capability
in the home network. The forced IPv6 address allocation via PMIP6
signaling will enable the MAG to enable IPv6 on the access link, any time
it detects the terminal is IPv6 capable from the network triggers. This
has the bad side affect of mobile obtaining an IPv6 address, for which
routing is not enabled, getting its traffic black holed and with a very
bad user experience of PMIP network :)

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 06 Nov 2008 12:38:29 -0600

I am surprised we are going down the path where we are saying that a PMIP6
LMA does not or may not have IPv6 routing into the network (core).

An LMA that does not provide IPv6 prefixes/addresses to an MN and routing
capability is something else than what is specified in RFC5213.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 6 Nov 2008 10:47:42 -0800 (PST)

> LMA does not or may not have IPv6 routing into the network (core).

The choice of IPv6 based signaling protocol does/should not prevent
IPv4-only deployment. The immediate deployment of this protocol is
indeed primarily for an IPv4 network. IPv6 signaling choice is with
the goal to future proof this solution and with the ability to
support today's network.

We can force IPv6 allocation, again as I said, that is more about
the direction and we need to discuss that. But, that decision should
not impose too much of pain for an immediate deployment. If we
indeed decide to go this route, lets be consistent and do it across
the board.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 06 Nov 2008 12:58:08 -0600

Hi Sri,

On 11/6/08 12:47 PM, "Sri Gundavelli" <[email-masked]> wrote:

> IPv4-only deployment.

Let me just say that IMO the protocol has not been designed with intent to
support an IPv4-only deployment. A network based mobility protocol for
supporting IPv4-only deployments would be different (eg. It would not be
built on IPv6 and MIP6 signaling).

> The immediate deployment of this protocol is
> indeed primarily for an IPv4 network.

Says who? I agree that it makes sense to support IPv4 only hosts as well.
But to say that it is for IPv4 only networks and hosts is not true.

> IPv6 signaling choice is with
> the direction and we need to discuss that.

Given the design objective and scope of this protocol I don't see if there
is need for discussion. But if that is what you want, maybe the chairs can
include it in the agenda for IETF73 (?).

> But, that decision should
> not impose too much of pain for an immediate deployment.

Pain to whom? Operators planning on deploying PMIP6 or people who are
building products?

> If we

Sure.
-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 6 Nov 2008 11:04:04 -0800 (PST)

Hi Raj,

> But to say that it is for IPv4 only networks and hosts is not true.

You are arguing IPv6 is deployed today or that this protocol should not
be deployed till IPv6 is deployed, both home and access domains have
full IPv6 routing ?

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 6 Nov 2008 11:06:44 -0800 (PST)

Hi Raj,

Also, we should solve this problem. A terminal comes up and sends an RS,
we assign an IPv6 address, making it believe it can use it. Given the
lack of triggers for the network to influcence the terminal on the
source address or source address family selection, where does the traffic
go ? Its given most terminals will be IPv6 enabled, like Linux, Vista ..
etc... but thats not the case in the network.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 06 Nov 2008 13:19:05 -0600

Hi Sri,

> be deployed till IPv6 is deployed, both home and access domains have

Is there a problem in enabling IPv6 routing from the LMA today? The term
"till IPv6 is deployed" is invalid. You can claim that IPv6 is not widely
deployed and that's fine.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 6 Nov 2008 11:32:53 -0800 (PST)

Hi Raj,

To shorten this discussion, I've no issue forcing IPv6,
if we decide to do that, lets do it consistently. However,
I do have concerns on the impact on the terminal sessions
by allocating these psuedo addresses that in reality have
no routing setup. Thats a big issue and we need to solve
that.

Lets leave the debate on if IPv6 is deployed or not, or
why an operator wont enable IPv6 routing right away both
in the home and access networks. You or me surely want to
see IPv6 every where, no issue there. Lets make sure,
we dont kill the protocol usage in the process.

> deployed and that's fine.

You did not answer my question. For the protocol deployment,
should we require IPv6 to be enabled or not. If not, then
our logic of default address assignment has an impact on the
sessions where IPv6 is not enabled.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 06 Nov 2008 13:48:34 -0600

On 11/6/08 1:32 PM, "Sri Gundavelli" <[email-masked]> wrote:

> should we require IPv6 to be enabled or not.

This is a decision that someone deploying the protocol will have to make.
But IMO any PMIP6 deployment should (strong should) enable IPv6.

-Raj

> If not, then

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 6 Nov 2008 16:14:58 -0800 (PST)

Hi Sri,
  I read this draft and have a few comments. Firstly thanks to the authors for having done such a thorough job.
   I am for keeping DHCP server text in 3.4.1
  I am for HNP for all nodes.

1. IPv4 default-router address. In Sec. 1.1 it says that 
The mobile access gateway is the IPv4 default-router for the
      mobile node on its access link.

If this is the case then why in Sec. 3.2.1 BU List at the MAG is extended to keep the IPv4 default-router address?

2. In Sec. 3.4.1, it is stated that (Step-2 to Step-4) may happen in parallel and in no specific order. I don't understand how PBA can be sent before PBU and how tunnel/route setup could be done before all of that?

Same comment for the text in Sec. 3.4.2?

3. Draft mentioned the (T) Flag which is not defined. It seems like this flag is defined in ID-DSMIP6. I think this should be clarified.

4. Typos. 
3.1.2.5 with respect TO 
3.2.2. This field identifies <- The supported modes identify
3.4.1 DHCP server that is on col-located ... remove on
3.4.2. DHCPDISOCVERY
a regular DHCP relay agent as [RFC-2131]. as in [RFC-2131]
4.1.2 This are mandatory These
4.1.3.2 NAT detection procedure like in Sec. 5.2 of [ID-DSMIP6]?
4.2.2 Section references like 6.9.1.5, add of [RFC-5213].
4.2.2.2 Figure 13: Tunneled IPv4 Packet from LMA to MAG 
MAG to LMA?

Regards,

Behcet

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Fri, 07 Nov 2008 17:48:44 +0200

Raj and Sri,

Perhaps I should clarify my view point. I would really like to mandate the
usage of IPv6, and the IPv6 routing from the LMA. No question there. I don't
agree with Sri that the protocol would be useless if it would mandate IPv6.
I think PMIP6 has to take into account IPv4 also and mandating IPv6 _only_
would be foolish. However, mandating IPv6 IMHO would not destroy the
protocol.

That said, I'm afraid that by mandating allocating IPv6 prefix to the MN we
would make many deployments give an IPv6 to the MN without the routing. In
addition, I don't think we can mandate deployment models or business models
to the operators deploying PMIP6.

However, I would like to mandate the allocation of IPv6 prefix to every
mobile when there is IPv6 routing from the LMA (LMA returns the prefix to
the MAG). Even if the network either does not know, or would think the MN is
IPv4 only.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 7 Nov 2008 08:24:39 -0800 (PST)

Hi Jonne,

> the MAG). Even if the network either does not know, or would think the MN is

Agreed. This is perfect fine. When there is IPv6 routing in the home,
we can certainly assign an IPv6 prefix. This change is ok. At the same
time, when there is no IPv6 routing in the home, we will not assign an
IPv6 prefix to the mobile. This will ensure, a dual-stacked terminal will
not endup with an IPv6 address for which routing is not setup and will
not attempt to use an IPv6 address for its sessions and potentiallly
avoid a major break down.

Regards
Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 07 Nov 2008 10:27:53 -0600

Sri,

> avoid a major break down.

What is the major breakdown if you assign the MN an IPv6 prefix for which no
routing is provided by the LMA? Obviously you cannot use the address for any
IPv6 session. But this idea that somehow things would breakdown is invalid.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 7 Nov 2008 08:38:09 -0800 (PST)

Hi Raj,

> IPv6 session. But this idea that somehow things would breakdown is invalid.

A dual-stacked terminal that is attached to the PMIP network will
obtain address from IPv4 and IPv6 address families. Both appear to
be valid, there is a DR on the link and it can use any of those
addresses for source-address selection. Given that there is no way
to further influence the terminal to use one address over the other,
insted we made it believe both the addresses are routable and will
have mobility property. The host may end up using IPv6 for its sessions
and the time to recover based on the maturity of the stack may take
any length of time. It is not clear the current dual-stack implementations
in Vista or Linux have the ability to try one address family and retry
using the other when failure is seen. IMO, this wont be a pleasent
experience for the terminal and is a indeed a *break-down*. Disagree ?

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 07 Nov 2008 10:43:23 -0600

> experience for the terminal and is a indeed a *break-down*. Disagree ?

Yes. I disagree.

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 7 Nov 2008 08:55:07 -0800 (PST)

Raj,

>> experience for the terminal and is a indeed a *break-down*. Disagree ?

We cannot simply assign an IPv6 address when we know that cant be used.
I'm with you or Jonne, on forcing IPv6 when there is routing setup, but
not when the network is simply not capable of that. Its like giving
car keys to some one and tell the person later that, it does not have
wheels and that they will figure it out.

Any case, lets discuss in Minneapolis.

Regards
Sri

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Fri, 07 Nov 2008 19:11:27 +0200

Raj,

>> experience for the terminal and is a indeed a *break-down*. Disagree ?

You may disagree, but the fact is that the host has no idea if the address
it gets works or not. For instance, if you would get an A record, and an
AAAA record for a web site, the MN might (and most would) try to use the
IPv6 address of the web site. However, the packets would never get to the
other end. It is like a denial of service attack on the host.

I'm afraid Sri is right here.

Cheers,

Jonne.
-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 Nov 2008 09:58:53 -0800 (PST)

Hi Jonne,
  Can I respectfully disagree with you  ?

I don't understand why IPv6 routing would not exist in a PMIPv6 deployment?

Regards,

Behcet

________________________________
From: Soininen Jonne (NSN FI/Espoo) <[email-masked]>
To: Basavaraj Patil <[email-masked]>; ext Sri Gundavelli <[email-masked]>
Cc: Julien Laganier <[email-masked]>; "[email-masked]" <[email-masked]>; [email-masked]
Sent: Friday, November 7, 2008 11:11:27 AM
Subject: Re: [netlmm] Working Group Last Call - draft-ietf-netlmm-pmip6-ipv4-support-05

Raj,

Cheers,

Jonne.
-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 7 Nov 2008 13:16:18 -0500

Hi Raj,

> built on IPv6 and MIP6 signaling).

I disagree. Supporting an IPv4-only mobile node was one of the goals in
PMIPv6. I think it is OK to not allocate an IPv6 prefix for the mobile
node and create forwarding entries for that prefix on the MAG and the
LMA when it is known that the mobile node is IPv4-only.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 07 Nov 2008 12:33:33 -0600

Hi Vijay,

> LMA when it is known that the mobile node is IPv4-only.

There is no easy way to know if the MN is IPv4-only. You could have a policy
which says that an MN is only assigned an IPv4 only address. But that does
not make sense. Supporting IPv4 hosts via PMIP6 is fine. But not by making
PMIP6 a protocol for network based mobility for IPv4 (to repeat what I
said).

-Raj

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 7 Nov 2008 13:39:14 -0500

Basavaraj Patil wrote:
>>> Let me just say that IMO the protocol has not been designed with
>>> intent to support an IPv4-only deployment. A network based mobility
>>> protocol for supporting IPv4-only deployments would be different
>>> (eg. It would not be built on IPv6 and MIP6 signaling).
>> 
>> I disagree. Supporting an IPv4-only mobile node was one of the goals
>> in PMIPv6. I think it is OK to not allocate an IPv6 prefix for the
>> mobile node and create forwarding entries for that prefix on the MAG
>> and the LMA when it is known that the mobile node is IPv4-only.
> 
> PMIP6 a protocol for network based mobility for IPv4 (to repeat what
> I said). 

That's why I said "...if it known that the mobile node is IPv4-only". I
don't think we should mandate that the IPv6 HNP must be allocated all
the time and the routing for that prefix must be setup on the MAG and
the LMA.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 7 Nov 2008 20:43:05 +0200

> >> support an IPv4-only deployment. 

Isn't it too late now that the protocol supports both IPv4 address
assignment and even IPv4 transport?
Unless operation of IPv4 depends on the MN also using IPv6 (there is no such
dependency in the design), 
I don't see why IPv4-only MN cannot be supported. 

Alper

A network based mobility protocol
> for
> in

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 07 Nov 2008 12:55:18 -0600

Alper,

> I don't see why IPv4-only MN cannot be supported.

An IPv4 only host is supported by the protocol. That is not the point. It
was more about whether the LMA should always assign an IPv6 HNP even in the
case where the MN may not be able to use it.

-Raj

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 7 Nov 2008 21:35:35 +0200

Raj,

> case where the MN may not be able to use it.

I don't see the necessity of LMA "always" assigning IPv6 HNP. Like Vijay was
saying, when the network knows that the MS is not going to use it, why
bother make that assignment.

Alper

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 7 Nov 2008 11:42:50 -0800 (PST)

> case where the MN may not be able to use it.

To further clarify, the discussion was more about the extreme of
IPv6 address allocation, even when the LMA has no IPv6 support on
the back haul. About assigning some IPv6 address to the mobile, for
which there is no routing in the home network. We were discussing
about the issues in this scenario, Jonne's thread ...

Sri

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 Nov 2008 12:53:43 -0800 (PST)

Hi Sri,
  Knowing a little bit the situation in some SDOs it can be easily stated that no PMIPv6 deployments will occur without needing any IPv6 routing. And you agreed that it is OK to assign a HNP in this case.
  So, maybe that's it. You may wish to state your other reasons of truely IPv4 only and no IPv6 routing in order to justify not assigning HNP as an exception rather than default, that will be fine.
  If you properly state the above in the revised draft then no problems, I think.

Regards,

Behcet

________________________________
From: Sri Gundavelli <[email-masked]>
To: Basavaraj Patil <[email-masked]>
Cc: Julien Laganier <[email-masked]>; [email-masked]; [email-masked]
Sent: Friday, November 7, 2008 1:42:50 PM
Subject: Re: [netlmm] Working Group Last Call - draft-ietf-netlmm-pmip6-ipv4-support-05

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 7 Nov 2008 13:02:07 -0800 (PST)

Hi Behcet,

>  If you properly state the above in the revised draft then no problems, I think.

The protocol has to adopt to the operating environment, with out
requiring huge changes. We will assign IPv6 prefix to the mobile
when the LMA has IPv6 back-haul support. This is inline with
Raj, Jonne, Vijay or as others think. But, we will not force IPv6
address assignment to the terminal when there is no back haul
routing support.

Any case, we will discuss this in Minneapolis. Hopefully, we can
resolve it correctly and avoid any issues on the terminal sessions.
Thanks for the discussion.

Sri

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 7 Nov 2008 16:46:50 -0500

> the time and the routing for that prefix must be setup on the MAG and

[RKo:>] It is possible to determine the MN's capabilities and the user
subscription profile at the time of attachment. IPv4-only is one
possibility. We should not make it the only possibility in the spec.
Instead, we should refer to "policy", and let the spec support whatever
is determined at the time of attach.

-Rajeev

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 7 Nov 2008 17:51:31 -0600

I agree with Sri too.

If the LMA has the information that the MN is IPv4_Only, It makes sense
not to allocate an IPv6 HNP.
However, is it possible to make the decision based on the MN
capabilities and the LMA local policy or MAG-LMA per-peer policy, for
example. 

Regards,
Ahmad

> >>>> Agreed. This is perfect fine. When there is IPv6 routing in the 
> >>>> home, we can certainly assign an IPv6 prefix. This 
> change is ok. At 
> >>>> the same time, when there is no IPv6 routing in the 
> home, we will 
> >>>> not assign an
> >>>> IPv6 prefix to the mobile. This will ensure, a dual-stacked 
> >>>> terminal will not endup with an IPv6 address for which 
> routing is 
> >>>> not setup and will not attempt to use an IPv6 address for its 
> >>>> sessions and potentiallly avoid a major break down.
> >>> 
> >>> What is the major breakdown if you assign the MN an IPv6 
> prefix for 
> >>> which no routing is provided by the LMA? Obviously you cannot use 
> >>> the address for any
> >> obtain address from IPv4 and IPv6 address families. Both 
> appear to be 
> >> valid, there is a DR on the link and it can use any of those 
> >> addresses for source-address selection. Given that there 
> is no way to 
> >> further influence the terminal to use one address over the other, 
> >> have mobility property. The host may end up using IPv6 for its 
> >> sessions and the time to recover based on the maturity of 
> the stack 
> >> may take any length of time. It is not clear the current 
> dual-stack 
> >> implementations in Vista or Linux have the ability to try 
> one address 
> >> family and retry using the other when failure is seen. 
> IMO, this wont 
> >> be a pleasent experience for the terminal and is a indeed 
> a *break-down*. Disagree ?
> > 
> > Yes. I disagree.
> 
> You may disagree, but the fact is that the host has no idea 
> if the address it gets works or not. For instance, if you 
> would get an A record, and an AAAA record for a web site, the 
> MN might (and most would) try to use the
> IPv6 address of the web site. However, the packets would 
> never get to the other end. It is like a denial of service 
> attack on the host.
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 08 Nov 2008 13:17:13 +0900

Hi Raj,

At Fri, 07 Nov 2008 12:55:18 -0600,
> case where the MN may not be able to use it.

If LMA assign an HNP to an IPv4 only MN, how can MAG decide wehther it
advertises the HNP or not. If the MN is dual stack but it only
requests IPv4, how can MAG determin not to advertise the HNP for the
MN? If the assignment policy is always available at MAG, it's
fine. But this is not the only case.

regards,
ryuji

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 12 Nov 2008 07:36:48 -0800

Hi Behcet,

  _____  

From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Thursday, November 06, 2008 4:15 PM
To: Sri Gundavelli
Cc: [email-masked]
Subject: Review of draft-ietf-netlmm-pmip6-ipv4-support-05

Hi Sri,
  I read this draft and have a few comments. Firstly thanks to the authors
for having done such a thorough job.
   I am for keeping DHCP server text in 3.4.1
  I am for HNP for all nodes.

If this is the case then why in Sec. 3.2.1 BU List at the MAG is extended to
keep the IPv4 default-router address? 
 
[Sri] Because, that address is part of the HNP subnet, which is assigned by
the LMA and not a preconfigured
static address. 

2. In Sec. 3.4.1, it is stated that (Step-2 to Step-4) may happen in
parallel and in no specific order. I don't understand how PBA can be sent
before PBU and how tunnel/route setup could be done before all of that?
 
[Sri] Its says Step-1 (DHCP Discover) and Step 2-4 (PMIP signaling), may
happen in parallel.

[Sri] Same response. 

3. Draft mentioned the (T) Flag which is not defined. It seems like this
flag is defined in ID-DSMIP6. I think this should be clarified.

4. Typos. 
3.1.2.5 with respect TO 

[Sri] Ok. Thanks
 
Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 12 Nov 2008 08:11:31 -0800 (PST)

Hi Sri,
  Thanks for your kind reply.

See inline.

Regards,

Behcet

________________________________
From: Sri Gundavelli <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, November 12, 2008 9:36:48 AM
Subject: RE: Review of draft-ietf-netlmm-pmip6-ipv4-support-05

Hi Behcet,

Hi Sri,

 
[Sri] Because, that address is part of the HNP subnet, which is  assigned by the LMA and not a preconfigured
static address. 
[behcet] But HNP is IPv6, right? Here we're talking about IPv4 default-router address.
2. In Sec. 3.4.1, it is  stated that (Step-2 to Step-4) may happen in parallel and in no specific  order. I don't understand how PBA can be sent before PBU and how tunnel/route  setup could be done before all of that?
 
[Sri] Its says Step-1 (DHCP Discover) and Step 2-4 (PMIP signaling),  may happen in parallel.
 [behcet] Sorry, I read the second line independently of the first  maybe because of the "*" you have there, please remove it as in Fig. 6. 
Same comment for the text in Sec.  3.4.2?

[Sri] Same response. 
[behcet]  OK.

4. Typos. 
3.1.2.5 with  respect TO 

[Sri] Ok. Thanks
 
Regards,

Behcet

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 12 Nov 2008 08:22:50 -0800

Hi Behcet,

  _____  

From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Wednesday, November 12, 2008 8:12 AM
To: Sri Gundavelli
Cc: [email-masked]
Subject: Re: Review of draft-ietf-netlmm-pmip6-ipv4-support-05

Hi Sri,

See inline.

Regards,

Behcet

  _____  

Hi Behcet,

  _____  

Hi Sri,

 
[Sri] Because, that address is part of the HNP subnet, which is assigned by
the LMA and not a preconfigured
static address. 
[behcet] But HNP is IPv6, right? Here we're talking about IPv4
default-router address.
 
[Sri] IPv4 HoA and IPv4 Def-Router address are part of some subnet, which
belongs to the home and
not to the access network.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 12 Nov 2008 09:23:55 -0800 (PST)

My point was that this is this MAG's address why this MAG should keep its own address in each BU List entry for each MN that it serves?

Maybe I am wrong.

Regards,

Behcet

Sent: Wednesday, November 12, 2008 10:22:50 AM

Hi Behcet,

Hi Sri,

See  inline.

Regards,

Behcet

Hi Behcet,

Hi Sri,

 
 
[Sri] IPv4 HoA and IPv4 Def-Router address are part of some subnet,  which belongs to the home and
not to the access network.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 12 Nov 2008 09:32:40 -0800

_____  

From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Wednesday, November 12, 2008 9:24 AM
To: Sri Gundavelli
Cc: [email-masked]
Subject: Re: Review of draft-ietf-netlmm-pmip6-ipv4-support-05

My point was that this is this MAG's address why this MAG should keep its
own address in each BU List entry for each MN that it serves?
 
[Sri]  As I said, its not statically configured on the MAG, else, it will
change on each MAG. It belongs to the MN's home subnet.
 
Maybe I am wrong.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 12 Nov 2008 18:50:12 -0800 (PST)

Hi Sri,
  It seems like due to MN mobility, the default router address assigned might need to be kept for each MN, e.g. each MAG may have a different address assigned initially. That would justify your decision.
  OTOH it is possible and probably more logical due to IPv4 address depletion that a single address is used. In that case my comment would be justified.
  Regards,

Behcet

Sent: Wednesday, November 12, 2008 11:32:40 AM

 
[Sri]  As I said, its not  statically configured on the MAG, else, it will change on each MAG. It belongs  to the MN's home subnet.
 
Maybe I am 
wrong.

Regards,

Behcet

---

From: Julien Laganier <[email-masked]>
Date: Fri, 14 Nov 2008 02:01:27 +0100

Hello Behcet,

Not sure I follow you, but anyway...

The bottom line is: the LMA assigns to a MN a default router address at 
the initial attach. Then this default router address is sent to any MAG 
to which the MN attaches, and the MAG uses it.

To achieve that the LMA needs not to assign different default router 
addresses to different MNs, it can use the same default router address 
for all of the MNs anchored at a given MAG.

Thus I'm not sure I understand your comment about address depletion...

Regards,

--julien

Behcet Sarikaya wrote:
> Hi Sri,
>   It seems like due to MN mobility, the default router address assigned 
> might need to be kept for each MN, e.g. each MAG may have a different 
> address assigned initially. That would justify your decision.
>   OTOH it is possible and probably more logical due to IPv4 address 
> depletion that a single address is used. In that case my comment would 
> be justified.
>   Regards,
> 
> Behcet
> 
> ------------------------------------------------------------------------
> *From:* Sri Gundavelli <[email-masked]>
> *To:* Behcet Sarikaya <[email-masked]>
> *Cc:* [email-masked]
> *Sent:* Wednesday, November 12, 2008 11:32:40 AM
> *Subject:* RE: Review of draft-ietf-netlmm-pmip6-ipv4-support-05
> 
>  
> 
>     ------------------------------------------------------------------------
>     *From:* Behcet Sarikaya [mailto:[email-masked]]
>     *Sent:* Wednesday, November 12, 2008 9:24 AM
>     *To:* Sri Gundavelli
>     *Cc:* [email-masked]
>     *Subject:* Re: Review of draft-ietf-netlmm-pmip6-ipv4-support-05
> 
>     My point was that this is this MAG's address why this MAG should
>     keep its own address in each BU List entry for each MN that it serves?
>      
>     [Sri]  As I said, its not statically configured on the MAG, else, it
>     will change on each MAG. It belongs to the MN's home subnet.
>      
>     Maybe I am wrong.
> 
>     Regards,
> 
>     Behcet
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 14 Nov 2008 08:04:56 -0800 (PST)

Hi Julien,

  Please see inline.

Regards,
Behcet

________________________________
From: Julien Laganier <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: Sri Gundavelli <[email-masked]>; [email-masked]
Sent: Thursday, November 13, 2008 7:01:27 PM
Subject: Re: [netlmm] Review of draft-ietf-netlmm-pmip6-ipv4-support-05

Hello Behcet,

The bottom line is: the LMA assigns to a MN a default router address at the initial attach. Then this default router address is sent to any MAG to which the MN attaches, and the MAG uses it.
[behcet] This is an IPv4 address, right.

To achieve that the LMA needs not to assign different default router addresses to different MNs, it can use the same default router address for all of the MNs anchored at a given MAG.
[behcet]This was exactly my point. So the draft does not need to keep this address in BUL because it is unique and does not change per MN.

[behcet] As per above, we are in agreement.
 
Regards,

--julien