Subject: Re: [netlmm] Home Network Prefix indraft-ietf-netlmm-pmip6-ipv4-support-02

From: "Ali Irfan-FIA225" <[email-masked]>
Date: Wed, 6 Feb 2008 13:00:08 -0000

Hi Vijay/Julien,

I am not sure if a resolution to the this item has been achieved.

If the IPv4 draft allows the case that only IPv4 home network prefix and
no IPv6 Home network prefix option is included in PBU, is that not a
violation of the base draft?  The base draft *requires* IPv6 Home
network prefix option to be present in PBU. IMO, since IPv4 draft is an
extension to the base draft, it should not change the MUST requirement
in the base draft. Hence, in IPv4 extension draft, either (a) only Ipv6
Home network prefix option should be included (base draft), or (b) the
Ipv6 Home network prefix option and IPv4 Home address option.

Hence PBUs with only IPv4 Home address option should not be allowed.
[This may not allow optimizations in some situations, but no serious
concern with creation of IPv6 prefixes that are not used has been
raised. Moreover, this would keep the IPv4 draft to be in compliance
with the base draft]. If the UE only requires IPv4 address and the MAG
is aware of this, the MAG should only forward the IPv4 address to the
UE.

Rgds
Irfan 

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Thursday, January 24, 2008 5:16 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [netlmm] Home Network Prefix 
> indraft-ietf-netlmm-pmip6-ipv4-support-02
> 
> Hello Vijay,
> 
> On Wednesday 23 January 2008, Vijay Devarapalli wrote:
> > Julien Laganier wrote:
> > >
> > > 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".
> >
> > Yes. Otherwise the IPv6 prefix/address is always 
> advertised/assigned.
> >
> > > What would be a method by which the network determine 
> whether the MN 
> > > is IPv4-only (resp. IPv6 enabled) or not.
> >
> > Multiple mechanisms.
> 
> All right. See my comments below:
> 
> > - 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.
> 
> 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 
> mechanism.
> 
> 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.
> 
> > 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.
> 
> 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
> 
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
> 
_______________________________________________
netlmm mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/netlmm

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 6 Feb 2008 07:20:09 -0800 (PST)

Hi Irfan,

In networks where only IPv4 is enabled, ex: HRPD, its a waste of
IPv6 prefix space. IMO, we can give control to the network as when
to when to allow what combination of protocols. But, is there an
issue that you see if we dont always enable IPv6 ? Any case, this
is an open issue and we have not resolved this yet.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 6 Feb 2008 07:31:36 -0800 (PST)

Also, to be more specific. By requiring IPv6 to be added be default
will have a significant resource consumption on both the LMA and MAG.
If a LMA has a million bindings, it would have now have to have a
route table with that many IPv6 prefix routes and a prefix entry in each
BCE for each MN's interface, has an implication on the memory
requirements. We should do the math, its comming at a cost. Since, this
has an issue of scalability, we need to be sure if we want to enable IPv6
by default, as supposed to giving the operator the control knob.

Sri

---

From: "Ali Irfan-FIA225" <[email-masked]>
Date: Thu, 7 Feb 2008 05:52:29 -0000

Hi Sri,

To answer your question: I do not see any reason to always enable IPv6
support in LMA. Also I do agree with some of the benefits that you point
out below for not always having IPv6 support enabled if not required. I
was thinking about interoperation issues of a MAG that support IPv4
extension and LMA that does not (LMA will send an option-not supported
msg if MAG sends IPv4 HoA option even it this includes the HNP option),
or if the MAG does not support the IPv4 extensions and the LMA does (the
first para of section 3.3.2 covers this pretty well). Seems OK.

So, atleast from interoperability point of view, I am OK with allowing
for all three modes, IPv4 only, IPv6 only and both IPv4/IPv6 address
options in the IPv4 extensions draft.

Rgds 
Irfan

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Wednesday, February 06, 2008 5:32 PM
> To: Ali Irfan-FIA225
> Cc: [email-masked]; 
> [email-masked]; Julien Laganier
> Also, to be more specific. By requiring IPv6 to be added be 
> default will have a significant resource consumption on both 
> the LMA and MAG.
> If a LMA has a million bindings, it would have now have to 
> have a route table with that many IPv6 prefix routes and a 
> prefix entry in each BCE for each MN's interface, has an 
> implication on the memory requirements. We should do the 
> math, its comming at a cost. Since, this has an issue of 
> scalability, we need to be sure if we want to enable IPv6 by 
> default, as supposed to giving the operator the control knob.
> 
> Sri
> 
> 
> 
> > IPv6 prefix space. IMO, we can give control to the network 
> as when to 
> > when to allow what combination of protocols. But, is there an issue 
> > that you see if we dont always enable IPv6 ? Any case, this 
> is an open 
> >> If the IPv4 draft allows the case that only IPv4 home 
> network prefix 
> >> and no IPv6 Home network prefix option is included in PBU, is that 
> >> not a violation of the base draft?  The base draft *requires* IPv6 
> >> Home network prefix option to be present in PBU. IMO, since IPv4 
> >> draft is an extension to the base draft, it should not change the 
> >> MUST requirement in the base draft. Hence, in IPv4 
> extension draft, 
> >> either (a) only Ipv6 Home network prefix option should be included 
> >> (base draft), or (b) the
> >> with the base draft]. If the UE only requires IPv4 address and the 
> >> MAG is aware of this, the MAG should only forward the IPv4 
> address to 
> >> the UE.
> >>
> >> Rgds
> >> Irfan
> >>
> >>> 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.
> >>>
> 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.
> >>>
> >>> I'd rather say "admin configuration if the operator wants 
> to deploy 
> >>> an
> 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
> >>>
> >>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Feb 2008 13:27:44 -0800

IMO, it is ok to relax the requirement to always allocate an IPv6
home network prefix when it is known that the mobile node is
IPv4-only.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Feb 2008 15:12:28 -0800 (PST)

I agree. Looking at the impact on scalability of the box
with the default allocation logic, we need to provide a
knob for the operator to turn it off, if IPv6 is not
going to be enabled in a given deployment. Irfan also
agreed to this.

Sri