Subject: [netlmm] Home Network Prefix in draft-ietf-netlmm-pmip6-ipv4-support-02

From: Julien Laganier <[email-masked]>
Date: Thu, 17 Jan 2008 17:22:41 +0100

Folks,

It seems there's a misalignment between 
draft-ietf-netlmm-pmip6-ipv4-support-02 and 
draft-ietf-netlmm-proxymip6-08.

Section 6.9 "Signaling Considerations" of draft-ietf-netlmm-proxymip6-08 
state:

>    o  The Home Network Prefix option MUST be present.  The prefix
>    value MAY be set 0::/0 or to a specific prefix value.

OTOH Section 3.2.2 of draft-ietf-netlmm-pmip6-ipv4-support-02 "Signaling 
Considerations" state:

>                            [...] The mobile access gateway MAY also
>       include the IPv6 Home Network Prefix option in the same message
>       for requesting IPv6 home address support in addition to IPv4
>       home address support for the mobile node.

What's the reason for a MAY when the basis for the IPv4 support, i.e. 
PMIPv6 makes it a MUST?

Cheers,

--julien

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

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 17 Jan 2008 08:54:50 -0800 (PST)

Hi Julien,

> What's the reason for a MAY when the basis for the IPv4 support, i.e.

There is no misalignment here. We need IPv6 HNP for requesting
a IPv6 prefix and for the base draft that is mandatory. However,
for IPv4 document, for requesting IPv4 address, the IPv4 HoA
option is mandatory and the request for IPv6 is optional. In
other words, this IPv6 HNP prefix mandatory requirement is
modified for the IPv4 support. This is for supporting legacy nodes
as there is no need for IPv6 HNP.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Thu, 17 Jan 2008 19:05:25 +0100

Hi Sri,

On Thursday 17 January 2008, Sri Gundavelli wrote:
> >>                            [...] The mobile access gateway MAY
> >> also include the IPv6 Home Network Prefix option in the same
> >> message for requesting IPv6 home address support in addition to
> >> IPv4 home address support for the mobile node.
> >
> > What's the reason for a MAY when the basis for the IPv4 support,
> > i.e. PMIPv6 makes it a MUST?
>

Ok, now I understand the intent. But I don't think the wording is okay 
since the intent is not spelled out.

If I implement spec 1 and spec 2, spec 1 says MAY do this and spec 2 
says MUST do this, I end up implementing the thing anyway, i.e. MUST 
win.

I think we should word it with something along those lines:

>                            [...] When IPv4 support for PMIPv6
> is present, the requirement on presence of the IPv6 home network
> prefix is relaxed, i.e., the PBU MAY NOT contain a Home Network 
> Prefix option. However, the mobile access gateway MAY
> also include the IPv6 Home Network Prefix option in the same
> message for requesting IPv6 home address support in addition to
> IPv4 home address support for the mobile node.

What do you think?

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 17 Jan 2008 10:24:31 -0800 (PST)

Hi Julien,

>> IPv4 home address support for the mobile node.

Actually, Ryuji and myself thought we will add the correct
wording in the IPv4 spec w.r.t the relaxing the requirement
of IPv6 HNP and only when the IPv4 HoA option is present.
So, we need to ensure the correct wording is there in the
IPv4 support document. The other way is as you suggested
above, but this requires references to the IPv4 HoA option.
When some one implements the base spec, the HNP is mandatory
and when some one implements both the specs, the modified
behavior is per the IPv4 document. Do you see any issues with
this ?

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Jan 2008 11:24:48 -0800

> behavior is per the IPv4 document. Do you see any issues with

Or you could make it more explicit the IPv4 support document
that the PMIPv6 spec is expected to also support an IPv4-only
mobile node. So the MAG might be requesting only for an IPv4
home address in some cases.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 17 Jan 2008 17:35:41 -0800

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Thursday, January 17, 2008 11:25 AM
> To: Sri Gundavelli
> Cc: Julien Laganier; [email-masked]; 
> [email-masked]
> Subject: Re: [netlmm] Home Network Prefix in 
> draft-ietf-netlmm-pmip6-ipv4-support-02
> 
> Sri Gundavelli wrote:
> > Hi Julien,
> > 
> > 

Sure. The text in IPv4 spec should be clear about this.

Sri

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 18 Jan 2008 13:49:56 +0900

Hi all

> Sure. The text in IPv4 spec should be clear about this.

We've already explained the IPv4-only MN support in several sections.

Ex.
In Section1.

    o  IPv4 Home Address Mobility Support: A mobile node that has IPv4
       stack enabled will be able to obtain an IPv4 address and be able
       to use that address from any of the access networks in that Proxy
       Mobile IPv6 domain.  The mobile node is not required to be
       allocated or assigned an IPv6 address for enabling IPv4 home
       address support.

In section 3
    The support for IPv4 addressing is orthogonal to the IPv6 addressing
    support.  Unlike as specified in [ID-DSMIP6], the mobile node is not
    required to have an IPv6 home address for obtaining IPv4 home  
address
    mobility.  A mobile node attached to an access link in a Proxy  
Mobile
    IPv6 domain will be able to obtain just an IPv4 address  
configuration
    or both IPv4 and IPv6 address configurations on the connected
    interface.  The policy on the mobile access gateway will determine  
if
    the mobile node is entitled for both the protocols or a single
    protocol and based on what is enabled, only those protocols will be
    enabled on the access link.  Further, when the mobile node after
    obtaining the IPv4 or IPv4/IPv6 address configuration on the access
    link, performs an inter-technology handoff, the network will ensure
    the mobile node will be able to use the same IPv4/IPv6 address
    configuration on the new interface.

However, the text is not clear whether MAG can request only for IPv4  
HoA or not.
We will update the spec and explicitly explain this.

thanks,
ryuji

---

From: Julien Laganier <[email-masked]>
Date: Fri, 18 Jan 2008 09:53:31 +0100

Hi Sri,

On Thursday 17 January 2008, Sri Gundavelli wrote:
> > Ok, now I understand the intent. But I don't think the wording is
> > okay since the intent is not spelled out.
> >
> > If I implement spec 1 and spec 2, spec 1 says MAY do this and spec
> > 2 says MUST do this, I end up implementing the thing anyway, i.e.
> > MUST win.
> >

I think we agree. The wording I was suggesting was an update to Section 
3.2.2 of draft-ietf-netlmm-pmip6-ipv4-support-02 "Signaling 

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 22 Jan 2008 09:23:07 +0100

Hi Sri,

I've been thinking more about that -- see below.

> as there is no need for IPv6 HNP.

Right, there's no need, but getting an IPv6 HNP does not hinder legacy 
IPv4 nodes to access the IPv4 Internet in any way. They will get RA's 
and will not process them, that's it. There's no need to provide the 
the PMIP *version6* protocol not to allocate an IPv6 prefix where we're 
trying to support legacy IPv4 nodes. This paragraph of the draft 
disturbs me:

>   stack enabled will be able to obtain an IPv4 address and be
>   able to use that address from any of the access networks in that
>   Proxy Mobile IPv6 domain.  The mobile node is not required to be
>   allocated or assigned an IPv6 address for enabling IPv4 home address
>   support.

The IETF designed a new Internet Protocol, IPv6, that IIRC has been 
called "our future". 

By allowing a PMIPv6 domain to not allocate an IPv6 address you make it 
possible for an IPv6 enabled node to not get access to the IPv6 
Internet -- what if my network provider believes I am a "legacy" node 
with v4 support only but I actually do have IPv6, and get allocated no 
v6 prefix. I thought v6 prefixes were available in sufficient 
quantities such that we don't need to worry about using one of them for 
one mobile node. 

I think we should discuss more about that. What's the usecase for 
allowing a network not to offer a v6 prefix to a PMIPv6 MN. And should 
we, in the IETF, design a protocol allowing that?

Cheers,

--julien

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 22 Jan 2008 09:34:51 -0800

Hi Julien,

> trying to support legacy IPv4 nodes. This paragraph of the draft 

(IPv4 Support document discussion)

True, the prefix can always be allocated. But, if IPv6 support is not
enabled for the terminal, it may not be worth locking up one prefix
for each interface. Secondly, the cost of carrying the option in all
messages (all thought its minor). The issue is not about the terminal's
ability to handle an IPv6 RA, the RA can always be denied or the terminal
will ignore the packet. But, can we not optimize it by not allocating one
IPv6 prefix for each interface, not having to create a route on both
the ends, create the required tunnel interface for supporting the
IPv6 payload (this may be implementation dependent). So, why allocate it
when we dont need it. That was the thought process.

> The IETF designed a new Internet Protocol, IPv6, that IIRC has been 

I agree, but we also DSMIP6 with a complete IPv4 transport. I see your
point that we should always keep IPv6. But, if its not used for sure,
its a baggage.

> we, in the IETF, design a protocol allowing that?

Good that we started discussions on the IPv4 support document. Lets
do that.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 22 Jan 2008 13:52:32 -0800

Sri,

My understanding was that we don't assign an IPv6 prefix/address
only if it is an IPv4-only mobile node. Otherwise we do assign
the IPv6 prefix/address even if the mobile node is not initiating
any IPv6 sessions.

The mobile node can of course be configured to ignore the IPv6
router advertisement.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 22 Jan 2008 14:03:22 -0800 (PST)

Hi Vijay,

This is a policy decision. The MAG has the choice to request
exclusively for a IPv6 prefix, IPv4-HoA or the combination.
The IPv4 support document allows all the cases. If we always
allocate IPv6 prefix, even when its not required, its an
overhead.

Sri

On Tue, 22 Jan 2008, Vijay Devarapalli wrote:

>> >  and will not process them, that's it. There's no need to provide the the 
>> >  PMIP *version6* protocol not to allocate an IPv6 prefix where we're 
>> >  possible for an IPv6 enabled node to not get access to the IPv6 Internet 
>> >  -- what if my network provider believes I am a "legacy" node with v4 
>> >  support only but I actually do have IPv6, and get allocated no v6 
>> >  prefix. I thought v6 prefixes were available in sufficient quantities 
>> >  such that we don't need to worry about using one of them for one mobile 
>> >  node. 
>> >

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 22 Jan 2008 14:07:55 -0800 (PST)

Hi Behcet,

Sure, you raised this discussion before. We can always assign
a IPv6 prefix even for a legacy terminal, but it will be
optimal not to do that. We need to close this issue before
we go for the LC on the IPv4 support document.

Sri

Hi Sri,
   I share Julien's concerns. In fact I was the first to raise this issue 
several months ago
The added concern I have is that an extension should not have requirement 
on all other extensions. This is the situation we have now without 
Julien's suggested modification.

Kind regards,

Behcet

On Tue, 22 Jan 2008, Sri Gundavelli wrote:

>> > >   Right, there's no need, but getting an IPv6 HNP does not hinder 
>> > >   legacy IPv4 nodes to access the IPv4 Internet in any way. They will 
>> > >   get RA's and will not process them, that's it. There's no need to 
>> > >   provide the the PMIP *version6* protocol not to allocate an IPv6 
>> > >   prefix where we're trying to support legacy IPv4 nodes. This 
>> > >   paragraph of the draft disturbs me:
>> > > 
>> > 
>> > >   By allowing a PMIPv6 domain to not allocate an IPv6 address you make 
>> > >   it possible for an IPv6 enabled node to not get access to the IPv6 
>> > >   with v4 support only but I actually do have IPv6, and get allocated 
>> > >   no v6 prefix. I thought v6 prefixes were available in sufficient 
>> > >   quantities such that we don't need to worry about using one of them 
>> > >   for one mobile node. 
>> > > 
>> > >   allowing a network not to offer a v6 prefix to a PMIPv6 MN. And 
>> > >   should we, in the IETF, design a protocol allowing that?
>> > > 
>> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 22 Jan 2008 14:10:24 -0800

> allocate IPv6 prefix, even when its not required, its an

I suggest modifying the text to say that the IPv6 prefix/address
is always assigned unless it is is known that the mobile node is
IPv4-only. And no, it is not a policy decision.

Vijay

>>> legacy >  IPv4 nodes to access the IPv4 Internet in any way. They 
>>> will get RA's >  and will not process them, that's it. There's no 
>>> need to provide the the >  PMIP *version6* protocol not to allocate 
>>> an IPv6 prefix where we're >  trying to support legacy IPv4 nodes. 
>>> This paragraph of the draft >  disturbs me:
>>> >
>>>
>>> > >    allocated or assigned an IPv6 address for enabling IPv4 >  
>>> home address
>>> > >    support.
>>> >  The IETF designed a new Internet Protocol, IPv6, that IIRC has 
>>> been >  called "our future". >
>>>
>>> >  By allowing a PMIPv6 domain to not allocate an IPv6 address you 
>>> make it >  possible for an IPv6 enabled node to not get access to the 
>>> IPv6 Internet >  -- what if my network provider believes I am a 
>>> "legacy" node with v4 >  support only but I actually do have IPv6, 
>>> and get allocated no v6 >  prefix. I thought v6 prefixes were 
>>> available in sufficient quantities >  such that we don't need to 
>>> worry about using one of them for one mobile >  node. > >  I think we 
>>> should discuss more about that. What's the usecase for >  allowing a 
>>> network not to offer a v6 prefix to a PMIPv6 MN. And should >  we, in 
>>> the IETF, design a protocol allowing that?
>>> >
>>>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 22 Jan 2008 20:25:34 -0800 (PST)

> IPv4-only. And no, it is not a policy decision.

Currently, we allow the MAG to specify this. It will be hard to
base this on a RS/DHCP type of trigger from the MN. That would
be difficult for the MAG to synchronize and specify it in a
single PBU. In other words, IPv4 capability trigger via DHCP
or an IPv6 capability trigger via RS, will not happen at the
exact time for the MAG to decide what all protocol mobility to
request. Ryuji and me had some discussions on this we left it
as a policy decision, as it can simplify it, but the usual argument
of MAG knowing for certain will come back. Lets get some input on
this.

Sri

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Wed, 23 Jan 2008 14:13:52 +0900

Vijay,

> is always assigned unless it is is known that the mobile node is

This is what we try to explain in the spec.

> IPv4-only. And no, it is not a policy decision.

How can MAG know which terminal is IPv6-only or not?
In the current text, we simply say that the information is stored in  
the policy profile

ryuji

>>>> >  Right, there's no need, but getting an IPv6 HNP does not  
>>>> hinder legacy >  IPv4 nodes to access the IPv4 Internet in any  
>>>> way. They will get RA's >  and will not process them, that's it.  
>>>> There's no need to provide the the >  PMIP *version6* protocol  
>>>> not to allocate an IPv6 prefix where we're >  trying to support  
>>>> legacy IPv4 nodes. This paragraph of the draft >  disturbs me:
>>>> >
>>>>
>>>> >  By allowing a PMIPv6 domain to not allocate an IPv6 address  
>>>> you make it >  possible for an IPv6 enabled node to not get  
>>>> access to the IPv6 Internet >  -- what if my network provider  
>>>> believes I am a "legacy" node with v4 >  support only but I  
>>>> actually do have IPv6, and get allocated no v6 >  prefix. I  
>>>> thought v6 prefixes were available in sufficient quantities >   
>>>> such that we don't need to worry about using one of them for one  
>>>> mobile >  node. > >  I think we should discuss more about that.  
>>>> What's the usecase for >  allowing a network not to offer a v6  
>>>> prefix to a PMIPv6 MN. And should >  we, in the IETF, design a  
>>>> protocol allowing that?
>>>> >
>>>>

---

From: Julien Laganier <[email-masked]>
Date: Wed, 23 Jan 2008 10:43:07 +0100

Hello Vijay, Ryuji, Sri,

> In the current text, we simply say that the information is stored in

I have a problem with Vijay's statement "the IPv6 prefix/address is 
always assigned unless it is is known that the mobile node is 
IPv4-only." 

I'm assuming that meant "unless the network knows that the mobile node 
is IPv4 only". 

What would be a method by which the network determine whether the MN is 
IPv4-only (resp. IPv6 enabled) or not.

It can't be statically configured in the network since I can use an IPv4 
only cell-phone to connect my IPv6 enabled laptop. In the end that's an 
IPv6 mobile node, even though the network thought that cell-phone is 
IPv4 only. So saying it's stored in the policy profile isn't an option 
since the profile is either about the L2 terminal, or the user, and 
none gives an indication about IP level capabilities. Since IP stack 
have no identifiers we don't have an IP stack profile and we don't know 
what it can do, or can't do.

It can't be based on the MN issuing or not IPv6 configuration signalling 
(i.e. RS, DHCPv6) since as a MN I'm entitled not to send out any RS and 
wait for an RA to configure an address. The only thing a MN has to do 
to bring an IPv6 interface up is to join the all-nodes multicast 
address. This could be a way by which the network determines the 
presence of IPv6 capability on the MN. If that is acceptable that 
should be specified in the draft. We'd also need to make sure the new 
MAG after a handover is told about the v6 capability of the MN since it 
is not clear whether the MN will join the all-nodes multicast address 
after each handover. In the end it's maybe simpler to accept the 
negligible overhead of an IPv6 prefix allocation even though the MN 
does not support it.

Maybe I'm missing something. Anyway it would help if any of you could 
sketch a method by which the network determine which MN is IPv4-only, 
being it a profile, or by protocol interaction.

Thanks.

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 23 Jan 2008 10:36:59 -0800

> I'm assuming that meant "unless the network knows that the mobile node 

Yes. Otherwise the IPv6 prefix/address is always
advertised/assigned.

> IPv4-only (resp. IPv6 enabled) or not.

Multiple mechanisms.

- The fact that the mobile node is IPv4-only is stored in the
user's policy profile. This of course won't work if the user
changes the device.

- Device capabilities based on the device identifier.

- Mobile node indicates it capabilities to the MAG via a L2
mechanism.

4. Admin configuration on the MAG and the LMA if the admin
knows that it is all going to be IPv4-only mobile nodes in a
particular system.

These are of course out of scope of the IPv4 support document.

Vijay

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 24 Jan 2008 15:54:12 +0100

Vijay,

> > What would be a method by which the network determine 
> whether the MN 
> > is IPv4-only (resp. IPv6 enabled) or not.
> 
> Multiple mechanisms.
> 

Yes.

> - Device capabilities based on the device identifier.

It is not reliable, the user may install a new firmware. It doesn't work either for devices like laptops. 

> - Mobile node indicates it capabilities to the MAG via a L2 mechanism.

Yes. The downside is that it requires support from L2 technology and this might involve some SDO work (and the same work would need to be repeated in different SDOs)

domagoj

---

From: Julien Laganier <[email-masked]>
Date: Thu, 24 Jan 2008 16:15:31 +0100

Hello Vijay,

On Wednesday 23 January 2008, Vijay Devarapalli wrote:
> > I'm assuming that meant "unless the network knows that the mobile
> > node is IPv4 only".
>
> > What would be a method by which the network determine whether the
> > MN is IPv4-only (resp. IPv6 enabled) or not.
>
> Multiple mechanisms.

> user's policy profile. This of course won't work if the user

Right. So this is not an option.

> - Device capabilities based on the device identifier.

The device identifier most likely identifies the hardware, not the 
software running on it. We would rather need to use a S/W release 
identifier. Not sure this is reasonable to assume that 1) a S/W release 
identifier is available to the network, and 2) that the network knows 
which IP version is support by a given S/W release.

> - Mobile node indicates it capabilities to the MAG via a L2

This assumes that the L2 is aware of L3 capabilities. Not sure this is 
realistic (how can the L2 knows which S/W release of IP is above), 
neither if this is good thing -- sounds a bit like a layering 
violation.

> knows that it is all going to be IPv4-only mobile nodes in a

I'd rather say "admin configuration if the operator wants to deploy an 
IPv4 only network". Would you agree? But then there's the question of 
whether or not it's good to use v6-enabled technology for v4-only 
deployments... Maybe this is too philosophical, but I'd like us to at 
least think about the implications.

Cheers,

--julien