Subject: [netlmm] IPv4 Support in PMIPv6

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 1 Feb 2007 01:53:48 -0800

This is not a topic raised in any of the reviews, but, I'd like to get a
discussion going on this topic to see what we should do here. 

There are two aspects of IPv4 support that I'd like folks to comment on
- IPv4 MN support and use of IPv4 data tunnels. 

Support for IPv4 MNs - 

One important problem to be addressed is the case of IPv4 MNs being
supported in the PMIP domain. It should be possible to register an IPv4
address with the LMA using PMIPv6 - this requires the regular home
address in the BU to be set to 0 (or some such value) and send the IPv4
address alone using extensions defined in DS-MIP6. I think this is
really crucial to support IPv4 MNs in the short term. In this case, we
need to discuss the addressing model, since the prefix-per-MN model is
not viable for IPv4. 

Support for IPv4 data tunnels - 

The other aspect of this is where the PMA and LMA are dual-stacked
(supporting PMIP6), while the larger part of the infrastructure is still
IPv4. The PMIP6 signaling itself in that case will be carried in IPv4
(potentially), but, to force an IPv4-in-IPv6-in-IPv4 data tunnel seems
wasteful (too much unnecessary overhead). It seems relatively
straightforward to allow the data tunnel to just be IPv4 in that case
(extensions defined for DS-MIP6 should already allow this). This will
allow the access network to largely still remain IPv4, while the PMA
alone is dual-stacked. In this case, the CoA will basically be an IPv4
address. 

Thoughts? 

Vidya

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 01 Feb 2007 12:10:55 +0100

Vidya, we're rehashing pre-PMIP discussion.  I'll give my point as
posted earlier.  Remark change in subject.

I support a v4 version of the protocol designed by netlmm.  Transition
mechanism from v4 to v6 are just transition, quick dirty works with
tunnels and hacks.  Same from v6 to v4.  I prefer a complete natural v4
netlmm solution, where no IPv6 headers are involved.

Alex

Narayanan, Vidya wrote:
> This is not a topic raised in any of the reviews, but, I'd like to
> get a discussion going on this topic to see what we should do here.
> 
> There are two aspects of IPv4 support that I'd like folks to comment
> on - IPv4 MN support and use of IPv4 data tunnels.
> 
> Support for IPv4 MNs -
> 
> supported in the PMIP domain. It should be possible to register an
> IPv4 address with the LMA using PMIPv6 - this requires the regular
> home address in the BU to be set to 0 (or some such value) and send
> the IPv4 address alone using extensions defined in DS-MIP6. I think
> this is really crucial to support IPv4 MNs in the short term. In this
> case, we need to discuss the addressing model, since the
> prefix-per-MN model is not viable for IPv4.
> 
> (supporting PMIP6), while the larger part of the infrastructure is
> still IPv4. The PMIP6 signaling itself in that case will be carried
> in IPv4 (potentially), but, to force an IPv4-in-IPv6-in-IPv4 data
> tunnel seems wasteful (too much unnecessary overhead). It seems
> relatively straightforward to allow the data tunnel to just be IPv4
> in that case (extensions defined for DS-MIP6 should already allow
> this). This will allow the access network to largely still remain
> IPv4, while the PMA alone is dual-stacked. In this case, the CoA will
> basically be an IPv4 address.
> 
> Thoughts?
> 
> Vidya
> 
> _______________________________________________ netlmm mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>

---

From: <[email-masked]>
Date: Thu, 1 Feb 2007 15:06:43 +0200

Hi,

Having PMIP6 to include the DSMIP6 extensions from the start is a good
idea.
Just from operational point of view I'm sure network administrators
prefer having
just one mobility protocol to manage instead of having a separate PMIPv4
variant.

I don't think updating the access network is that big of an issue
especially
if we conclude to a solution which has the PMA as a functional entity in
AR. In that
case the access network needs to be updated anyway.

Markku Ala-Vannesluoma

>-----Original Message-----
>From: ext Narayanan, Vidya [mailto:[email-masked]] 
>Sent: 01 February, 2007 11:54
>To: [email-masked]
>Subject: [netlmm] IPv4 Support in PMIPv6
>
>
>This is not a topic raised in any of the reviews, but, I'd 
>like to get a discussion going on this topic to see what we 
>should do here. 
>
>One important problem to be addressed is the case of IPv4 MNs 
>being supported in the PMIP domain. It should be possible to 
>register an IPv4 address with the LMA using PMIPv6 - this 
>requires the regular home address in the BU to be set to 0 (or 
>some such value) and send the IPv4 address alone using 
>extensions defined in DS-MIP6. I think this is really crucial 
>to support IPv4 MNs in the short term. In this case, we need 
>to discuss the addressing model, since the prefix-per-MN model 
>is not viable for IPv4. 
>
>The other aspect of this is where the PMA and LMA are 
>dual-stacked (supporting PMIP6), while the larger part of the 
>infrastructure is still IPv4. The PMIP6 signaling itself in 
>that case will be carried in IPv4 (potentially), but, to force 
>an IPv4-in-IPv6-in-IPv4 data tunnel seems wasteful (too much 
>unnecessary overhead). It seems relatively straightforward to 
>allow the data tunnel to just be IPv4 in that case (extensions 
>defined for DS-MIP6 should already allow this). This will 
>allow the access network to largely still remain IPv4, while 
>the PMA alone is dual-stacked. In this case, the CoA will

---

From: Julien Laganier <[email-masked]>
Date: Thu, 1 Feb 2007 14:38:34 +0100

On Thursday 01 February 2007 10:53, Narayanan, Vidya 
wrote:
> This is not a topic raised in any of the reviews,
> but, I'd like to get a discussion going on this
> topic to see what we should do here.

Thanks for bringing that up.

> There are two aspects of IPv4 support that I'd like
> folks to comment on - IPv4 MN support and use of
> IPv4 data tunnels.
>
> Support for IPv4 MNs -
>
> One important problem to be addressed is the case of
> IPv4 MNs being supported in the PMIP domain. It
> should be possible to register an IPv4 address with
> the LMA using PMIPv6 - this requires the regular
> home address in the BU to be set to 0 (or some such
> value) and send the IPv4 address alone using
> extensions defined in DS-MIP6. I think this is
> really crucial to support IPv4 MNs in the short
> term. In this case, we need to discuss the
> addressing model, since the prefix-per-MN model is
> not viable for IPv4.

On the contrary I think the prefix-per-MN model is even 
more viable for IPv4. The NetLMM fabric just assign 
(e.g. via DHCP, or PPP) a /32 to each MN. This fits in 
the prefix-per-MN model and it doesn't waste address 
space. (ofcourse one might prefer to refer to that an 
address-per-MN model)

(The issue with prefix-per-MN model in IPv6 comes from 
supposedly unnecessary address space consumption, 
which in turns comes from the fact that a subnet 
prefix is in many cases no longer than 64 bits -- for 
stateless autoconfiguration amongst other things -- 
thus "forcing" to consume a /64 per MN in the domain)

> The other aspect of this is where the PMA and LMA
> are dual-stacked (supporting PMIP6), while the
> larger part of the infrastructure is still IPv4. The
> PMIP6 signaling itself in that case will be carried
> in IPv4 (potentially), but, to force an
> IPv4-in-IPv6-in-IPv4 data tunnel seems wasteful (too
> much unnecessary overhead). It seems relatively
> straightforward to allow the data tunnel to just be
> IPv4 in that case (extensions defined for DS-MIP6
> should already allow this). This will allow the
> access network to largely still remain IPv4, while
> the PMA alone is dual-stacked. In this case, the CoA
> will basically be an IPv4 address.
>
> Thoughts?

I am wondering if we should not make NETLMM IP version 
agnostic. Thus it would be possible for an MN, PMA and 
LMA to have v4 and/or v6 addresses, the NETLMM 
protocol would deal with registration of both v4 and 
v6 addresses, while data tunnelling would be any of 
{v4|v6}over{v4|v6[|gre|...]}

Thoughts?

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 01 Feb 2007 14:48:10 +0100

> {v4|v6}over{v4|v6[|gre|...]}

I support making NETLMM IP version agnostic.  The best way to achieve 
that is to use UDP instead of MH.  That is re-use and version agnostic.

But I think I'll stop posting this because it seems two things:

-either people just want to do PMIP and be left alone do that, because
  they voted it largely for that.
-or people just want to do netlmm-DT in which case we've already
  discussed extensively all these points raised anew by Vidya.

There seems to be _no_ proposal that would put together the netlmm-DT 
work with PMIP work, eg use UDP but call it 'Proxy Binding Update'.  If 
such proposal exist then I'll support it.

Alex

---

From: "Youn-Hee Han" <[email-masked]>
Date: Thu, 1 Feb 2007 22:55:50 +0900

Hi, 

Narayanan, Vidya wrote:
> requires the regular home address in the BU to be set to 0 
> (or some such value) and send the IPv4 address alone using 
> to discuss the addressing model, since the prefix-per-MN 
> model is not viable for IPv4. 

The goal of DS-MIPv6 is to extend RFC3775 to allow "dual stack" MNs.
Do you say the use of extension defined in DS-MIPv6 for supporting IPv4-MN?

The assumption of IPv4-only network (or IPv6 only network) is ok.
But, IMHO, IPv4-only MN will not happen much. Regarding PMIPv6,
like DS-MIPv6's assumption, the "dual-stack" MNs is more reasonable, too.

Youn-Hee

---

From: "Youn-Hee Han" <[email-masked]>
Date: Fri, 2 Feb 2007 01:53:38 +0900

Youn-Hee

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 1 Feb 2007 09:47:04 -0800 (PST)

> need to discuss the addressing model, since the prefix-per-MN model is

Agreed. We currently do support IPv4 HoA allocation in the
Shared-Prefix-Model (IPv4) model. We will continue to support
this and evolve this as required.

> alone is dual-stacked. In this case, the CoA will basically be an IPv4

Agreed. We did mention this in the ML, on our interest to support
this. We are working on adding this in our next version of the draft.
We will support IPv4 transport for PMIP6 tunnels.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 01 Feb 2007 10:19:29 -0800

> - IPv4 MN support and use of IPv4 data tunnels. 

I agree that both MUST be supported.

> need to discuss the addressing model, since the prefix-per-MN model is

We should go with one shared prefix for all IPv4 proxy
home addresses that the pHA/LMA gives out and
per-MN-prefix model for IPv6 pHoAs. For the IPv4 pHoA
allocation, we will be using the IPv4 Home Address
option from DS-MIPv6.

> alone is dual-stacked. In this case, the CoA will basically be an IPv4

Yes of course. When IPv4 traffic is carried over the
PMIPv6 tunnel, it will be IPv4 traffic directly
encapsulated over IPv4 tunnels. There won't be an
IPv6 header in between.

IPv4 hdr (src=PMA-IPv4, dst=HA-IPv4)
IPv4 hdr (src=MN-IPv4-HoA, dst=CN)
Payload

For NAT traversal we need an UDP header, between the
two IPv4 headers.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 1 Feb 2007 16:50:28 -0800 (PST)

Hi Julien,

> space. (ofcourse one might prefer to refer to that an

An IPv4 prefix with /32 prefix length, from routing perspective
is normal. It can certainly be injected in IGP as a route.
However, I do not think any of the standard IPv4 stacks support
an interface address configuration that has:

- A Prefix Length of /32, or
- A default router that does not share the same prefix.

This can be verified on a widely used platform such as W2K
and Linux FC4.

Further, I do not think:

- A DHCP server can assign an IPv4 address with /32 bit
   prefix length to a client. Verified on Cisco IOS DHCP
   Server.

Regards
Sri

---

From: "Sangjin Jeong" <[email-masked]>
Date: Fri, 2 Feb 2007 11:44:55 +0900

Hi,

> alone is dual-stacked. In this case, the CoA will basically be an IPv4

In addition to that, I think transport of IPv6 packet over IPv4 data
tunnel also needs to be considered because most MNs are likely
to have IPv4/IPv6 dual-stack and they may communicate with
both IPv4 and IPv6 CNs.

- Sangjin

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 1 Feb 2007 19:38:30 -0800

I agree with Sri here - I don't think assignment of a /32 in IPv4 is
feasible. 

Vidya

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Thursday, February 01, 2007 4:50 PM
> To: Julien Laganier
> Cc: [email-masked]
> Subject: Re: [netlmm] IPv4 Support in PMIPv6
> 
> 
> Hi Julien,
> 
> 
> >> really crucial to support IPv4 MNs in the short term. In 
> this case, 
> >> we need to discuss the addressing model, since the prefix-per-MN 
> > On the contrary I think the prefix-per-MN model is even more viable 
> > for IPv4. The NetLMM fabric just assign (e.g. via DHCP, or 
> PPP) a /32 
> > to each MN. This fits in the prefix-per-MN model and it 
> doesn't waste 
> > address space. (ofcourse one might prefer to refer to that an 
> > address-per-MN model)
> >
> 
> An IPv4 prefix with /32 prefix length, from routing 
> perspective is normal. It can certainly be injected in IGP as a route.
> However, I do not think any of the standard IPv4 stacks 
> support an interface address configuration that has:
> 
> > (The issue with prefix-per-MN model in IPv6 comes from supposedly 
> > unnecessary address space consumption, which in turns comes 
> from the 
> > fact that a subnet prefix is in many cases no longer than 
> 64 bits -- 
> > for stateless autoconfiguration amongst other things -- 
> thus "forcing"

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 02 Feb 2007 10:36:53 +0100

Vijay Devarapalli wrote:
>>  get a discussion going on this topic to see what we should do
>> here. There are two aspects of IPv4 support that I'd like folks to
>>  comment on - IPv4 MN support and use of IPv4 data tunnels.
> 
>> Support for IPv4 MNs - One important problem to be addressed is the
>>  case of IPv4 MNs being supported in the PMIP domain. It should be
>>  possible to register an IPv4 address with the LMA using PMIPv6 - 
>> this requires the regular home address in the BU to be set to 0 (or
>>  some such value) and send the IPv4 address alone using extensions
>>  defined in DS-MIP6. I think this is really crucial to support IPv4
>>  MNs in the short term. In this case, we need to discuss the 
>> addressing model, since the prefix-per-MN model is not viable for 
>> IPv4.
> 
> We should go with one shared prefix for all IPv4 proxy home addresses
>  that the pHA/LMA gives out and per-MN-prefix model for IPv6 pHoAs. 
> For the IPv4 pHoA allocation, we will be using the IPv4 Home Address 
> option from DS-MIPv6.

I think this may lead to incoherency: shared prefix for IPv4 and
prefix-per-mobile for IPv6?  Why do you prefer this different treatment
for IPv4 vs IPv6 addresses?  Couldn't this become a nightmare for
address architecture deployment planners?

Regarding the use of DS-MIPv6: do we want to continue the limitation of
having both IPv4 and IPv6 on the LMA?  I consider DS-MIPv6 potentially
requiring the LMA to run both IPv4 _and_ IPv6 to be a strong limitation.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Fri, 2 Feb 2007 11:15:49 +0100

On Friday 02 February 2007 01:50, Sri Gundavelli wrote:
> >> addressing model, since the prefix-per-MN model
> >> is not viable for IPv4.
> >
> > On the contrary I think the prefix-per-MN model is
> > even more viable for IPv4. The NetLMM fabric just
> > assign (e.g. via DHCP, or PPP) a /32 to each MN.
> > This fits in the prefix-per-MN model and it
> > doesn't waste address space. (ofcourse one might
> > prefer to refer to that an address-per-MN model)
>
> perspective is normal. It can certainly be injected
> in IGP as a route. However, I do not think any of
> the standard IPv4 stacks support an interface
> address configuration that has:
>

Ah yes, you're right. We'd need to assign a /30, e.g:

network 123.45.67.124/30
router 	123.45.67.125/30
mn 	123.45.67.126/30
bcast 	123.45.67.127/30

> [...]
>
> Further, I do not think:
>
> - A DHCP server can assign an IPv4 address with /32
> bit prefix length to a client. Verified on Cisco IOS
> DHCP Server.

With above setting (/30) ISC DHCP servers works fine 
along with FreeBSD MN.

But that mean that we "consume" 4 addresses per MN...

--julien

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Feb 2007 06:51:03 -0800

> This can be verified on a widely used platform such as W2K

Works fine under FC5 in our lab, and also worked fine
under FBSD last time I tried it. 
 
>    prefix length to a client. Verified on Cisco IOS DHCP

Works fine under ISC DHCP server v3.0.4; just need to add
a config line option to set the subnet-mask to all-1's.

Fred
[email-masked]

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 2 Feb 2007 11:27:23 -0800 (PST)

> [email-masked]

Thanks Fred. Good to know, some nodes allows this configuration.

Regards
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 02 Feb 2007 16:12:25 -0800

Alexandru Petrescu wrote:
>>> addressing model, since the prefix-per-MN model is not viable for IPv4.
>>
> prefix-per-mobile for IPv6?  

Shouldn't be a problem.

> requiring the LMA to run both IPv4 _and_ IPv6 to be a strong limitation.

It is actually a feature having the same box support
session continuity for both IPv4 and IPv6 sessions. :)

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 03 Feb 2007 14:16:46 +0100

Vijay Devarapalli wrote:
>>>> This is not a topic raised in any of the reviews, but, I'd like
>>>> to get a discussion going on this topic to see what we should
>>>> do here. There are two aspects of IPv4 support that I'd like
>>>> folks to comment on - IPv4 MN support and use of IPv4 data
>>>> tunnels.
>>> 
>>>> Support for IPv4 MNs - One important problem to be addressed is
>>>> the case of IPv4 MNs being supported in the PMIP domain. It
>>>> should be possible to register an IPv4 address with the LMA
>>>> using PMIPv6 - this requires the regular home address in the BU
>>>> to be set to 0 (or some such value) and send the IPv4 address
>>>> alone using extensions defined in DS-MIP6. I think this is
>>>> really crucial to support IPv4 MNs in the short term. In this
>>> We should go with one shared prefix for all IPv4 proxy home
>>> addresses that the pHA/LMA gives out and per-MN-prefix model for
>>> IPv6 pHoAs. For the IPv4 pHoA allocation, we will be using the
>>> IPv4 Home Address option from DS-MIPv6.
>> 
>> Regarding the use of DS-MIPv6: do we want to continue the
>> limitation of having both IPv4 and IPv6 on the LMA?  I consider
>> DS-MIPv6 potentially requiring the LMA to run both IPv4 _and_ IPv6
>> to be a strong limitation.
> 
> It is actually a feature having the same box support session
> continuity for both IPv4 and IPv6 sessions. :)

This means that we may not be able to turn the IPv4 switch off in some
parts of the network at some point in the future, because DS-MIPv6
requires the HA to be IPv4-enabled, thus IPv4 routing to it is mandatory.

There are many other transitioning mechanisms that don't have this
inconvenient.

I have a subnet here with a HAv4 and a HAv6 and for nothing will I try
to mix the two boxes together.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 03 Feb 2007 08:47:48 -0800

> to mix the two boxes together.

This is a completely different discussion that belongs
to the MIP6 mailing list on DS-MIPv6. You have already
brought this up numerous times in the past and this has
been discussed extensively on the MIP6 mailing list.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 03 Feb 2007 21:49:43 +0100

Vijay Devarapalli wrote:
>>>>>> Support for IPv4 MNs - One important problem to be
>>>>>> addressed is the case of IPv4 MNs being supported in the
>>>>>> PMIP domain. It should be possible to register an IPv4
>>>>>> address with the LMA using PMIPv6 - this requires the
>>>>>> regular home address in the BU to be set to 0 (or some such
>>>>>> value) and send the IPv4 address alone using extensions
>>>>>> defined in DS-MIP6. I think this is really crucial to
>>>>>> support IPv4 MNs in the short term. In this case, we need
>>>>> addresses that the pHA/LMA gives out and per-MN-prefix model
>>>>> for IPv6 pHoAs. For the IPv4 pHoA allocation, we will be
>>>>> using the IPv4 Home Address option from DS-MIPv6.
>>>> 
>>>> I think this may lead to incoherency: shared prefix for IPv4
>>>> and prefix-per-mobile for IPv6?
>>> 
>>> Shouldn't be a problem.
>>> 
>>>>  DS-MIPv6 potentially requiring the LMA to run both IPv4 _and_
>>>> IPv6 to be a strong limitation.
>>> 
>> This means that we may not be able to turn the IPv4 switch off in
>> some parts of the network at some point in the future, because
>> DS-MIPv6 requires the HA to be IPv4-enabled, thus IPv4 routing to
>> it is mandatory.
>> 
>> I have a subnet here with a HAv4 and a HAv6 and for nothing will I
>> try to mix the two boxes together.
> 
> This is a completely different discussion that belongs to the MIP6
> mailing list on DS-MIPv6. You have already brought this up numerous
> times in the past and this has been discussed extensively on the MIP6
> mailing list.

That is MIP6 WG.  We have no reason to think that because MIP6 WG 
adopted DS-MIP6 then netlmm WG should adopt it too.

Alex