Subject: Re: [Mip6] Dynamic HoA assignment

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 Apr 2007 09:09:04 -0700 (PDT)

Hi Raj,
  I have a question and a comment:

What is nsn  ?

My comment is the assignment of HoA using BU/BA seems to be against the spirit of RFC 3775. RFC 3775 requires BU to contain HoA destination option. RFC 3775, unlike RFC 3344 does not define a home address parameter in BU.
Also I am against to keep bringing Mipv4 aspects into Mipv6, ones wonders what is next? Use UDP signaling? 

Regards,

--behcet

----- Original Message ----
From: "[email-masked]" <[email-masked]>
To: [email-masked]; [email-masked]
Cc: [email-masked]
Sent: Friday, April 6, 2007 4:40:06 PM
Subject: RE: [Mip6] Dynamic HoA assignment

Inline: 

>-----Original Message-----
>From: ext Chowdhury, Kuntal [mailto:[email-masked]] 
>Sent: Friday, April 06, 2007 10:40 AM
>To: Gerardo Giaretta; Patil Basavaraj (NSN US/Irving)
>Cc: Mobile IPv6 Mailing List
>Subject: RE: [Mip6] Dynamic HoA assignment
>
>HI Gerardo, Raj,
>
>> -----Original Message-----
>> From: Gerardo Giaretta [mailto:[email-masked]]
>> Sent: Friday, April 06, 2007 3:53 AM
>> To: Basavaraj Patil
>> Cc: Mobile IPv6 Mailing List
>> Subject: Re: [Mip6] Dynamic HoA assignment
>> 
>> Hi Raj,
>> 
>> > Hello,
>> >
>> > Currently the I-D draft-ietf-mip6-hiopt proposes the MN obtain the
>HoA
>> as
>> > well in addition to the HA address and prefix via DHCP.
>> >
>> > I think the MN should obtain the minimal information required to
>> bootstrap.
>> > It is better to have the HA assign the MN an HoA.
>> 
>> I fully agree. The HA is the node in the better position to 
>assign the
>> HoA. This is the rationale behind the choices made by the
>> bootstrapping DT two years ago.
>> 
>[KC>] We are talking about basic DHCP capability as defined in
>draft-ietf-mip6-hiopt. We are NOT talking about the MIP6 bootstrapping
>solutions that came out of the DT. The inclusion of HoA in
>draft-ietf-mip6-bootstrapping-integrated-02.txt was debated over the ML
>and in Prague meeting. At this time, we have decided to NOT include HoA
>in draft-ietf-mip6-bootstrapping-integrated-02.txt. However, 
>this should
>not be linked with what can be done in DHCP. If someone wants to assign
>HoA via DHCP regardless of which mip6 bootstrapping solution is used or
>not used, it should be allowed, IMHO. BTW, it was added in the
>draft-ietf-mip6-hiopt because SDOs like WiMAX forum needed such info in
>DHCP.
>

Raj> Having multiple ways to assign the MN an HoA via the bootstrap
process
is not a good idea. At the moment the bootstrapping mechanisms suggest:
1. HoA assignment via IKEv2
2. HoA assignment via DHCP

Now we are discussing the possibility of the HA assigning the MN an HoA
in the BAck. 

I think it would be best to recommend a single method. And from that
perspective assigning the HoA in the BAck is more attractive since the
HA is the one doing the address assignment.

So if we were to recommend only a single way for HoA assignment, we 
could consider not having the HoA option in the hiopt I-D. 

>
>> > To do this we would
>> > require capability similar to MIP4 wherein the BU can be sent with
>an
>> > unspecified HoA. This is currently not possible as per RFC3775.
>> >
>> 
>> I guess you are talking about rfc4285 (auth protocol). If IPsec is
>> used, IKEv2 can be used to assign the HoA, as specified in
>> draft-ietf-mip6-bootstrapping-split
>> 
>[KC>] Again, regardless of IKEv2, we should allow the dynamic HoA
>assignment via mip6 BU/BA. People may like to do HoA (address)
>management based on MIP6 _authorization_ and NOT IKEv2 
>_authentication_.
>

Raj> Yes. I think that even in the case of bootstrapping with IKEv2,
we should still have the HoA assigned by the HA. Is there a reason 
why this would not work? Is there an issue with the IPsec SA
establishment
in case the HoA assignment has to be delayed until the MN sends the BU?
Or can the SA be modified to reflect the HoA assigned by the HA?

>> > Should we consider allowing the MN sending a BU with the 
>unspecified
>HoA
>> and
>> > obtain an HoA (assigned by the HA) in the BAck?
>> >
>> 
>> Again this would be needed only for auth protocol. No need 
>for this if
>> IPsec is used.
>> 
>[KC>] Nope, we should allow it via BU/BA as well.

Raj> I agree... Note the comment above. 

>
>> > I-D: draft-devarapalli-mip6-authprotocol-bootstrap proposes such
>> capability.
>> > Also do we need to consider standardizing the bootstrapping
>mechanism
>> for
>> > the auth protocol (RFC 4285)?
>> >
>> 
>> Some SDOs use rfc4285 authentication for MIPv6, but as far as I know,
>> they have already defined their own bootstrapping solution. 
>What would
>> be the role of an IETF solution with regards to those?
>> 
>[KC>] role of IETF is to define an IETF way to provide dynamic HoA
>allocation capability via mip6 BU/BA. We don't have that today. Also,
>you are forgetting the per-Node SA model that is used in PMIP6. We need
>this capability for PMIP6 also.
>

Raj> I think it makes sense for the MIP6 WG to define bootstrapping
which
covers all the cases. Having a solution for bootstrapping in the IETF
would
enable other SDOs to use it instead of defining their own specific
methods.

-Raj

>
>
>> --Gerardo
>> 
>> > -Basavaraj
>> >
>> >
>> > _______________________________________________
>> > Mip6 mailing list
>> > [email-masked]
>> > https://www1.ietf.org/mailman/listinfo/mip6
>> >
>> 
>> _______________________________________________
>> Mip6 mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/mip6
>
>
>"This email message and any attachments are confidential 
>information of Starent Networks, Corp. The information 
>transmitted may not be used to create or change any 
>contractual obligations of Starent Networks, Corp.  Any 
>review, retransmission, dissemination or other use of, or 
>taking of any action in reliance upon this e-mail and its 
>attachments by persons or entities other than the intended 
>recipient is prohibited. If you are not the intended 
>recipient, please notify the sender immediately -- by replying 
>to this message or by sending an email to 
>[email-masked] -- and destroy all copies of 
>this message and any attachments without reading or disclosing 
>their contents. Thank you."
>

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

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 16 Apr 2007 12:20:13 -0700 (PDT)

Jean-Michel, it is good to hear that MIP6 is being deployed in Europe.

Regards,

Behcet

----- Original Message ----
From: Jean-Michel Combes <[email-masked]>
To: [email-masked]
Cc: [email-masked]; [email-masked]
Sent: Monday, April 16, 2007 5:22:22 AM
Subject: Re: VS: Re: [Mip6] Dynamic HoA assignment

Hi Jouni,

2007/4/13, [email-masked] <[email-masked]>:
> Hi Jean,
>
> I doubt the the fw rules (or other filtering) would be based on HoA,

Why not?
IMHO, this is the more logical:
- the HoA is the more 'permanent' IP address for a MN which is needed
for the stateful function of a FW
- the HoA is owned by the operator and so the security administrator
is aware of them and can set up the security policy easily
- the MIPv6 aware FWs I have tested work with HoA policy based

>  at least not for BUs. Of course it is up to the operator's deployment but I would not generalize..

I agree on this point. But this is just an advertisement in the case
where security policy would be based on HoAs.

Best regards.

JMC.

>
> /jouni
>
> [snip]
>
> The second issue is that, normally, security policy (i.e. filtering
> rules) at the border of an  administrative domain (i.e. HA's domain
> here) should be based on HoA. If the BU has HoA=0::0, the packet
> should be rejected.
>
> Best regards.
>
> JMC.
>
> >
> > The intent is to allow the MN to send a BU with HoA=0:0 only in the case
> > when IPsec is not used between the MN and HA (i.e 4285 mode).
> >
> > -Raj
> >
> >
> >
> >
> > On 4/13/07 12:22 AM, "ext Chowdhury, Kuntal"
> > <[email-masked]> wrote:
> >
> > > IPv6CP is used to negotiate the IID only which helps in producing the
> > > link local address. RS/RA or DHCPv6 is used to configure the global
> > > scope address.
> > >
> > > -Kuntal
> > >
> > >
> > >> From: Vijay Devarapalli [mailto:[email-masked]]
> > >> Sent: Thursday, April 12, 2007 2:07 PM
> > >> To: Alper Yegin
> > >> Cc: [email-masked]; [email-masked]
> > >> Alper Yegin wrote:
> > >>>> The base PMIPv6 protocol assumes that the home prefix is sent
> > >>>> to the mobile node using a router advertisement and then the
> > >>>> mobile node auto-configures a home address from this prefix.
> > >>>
> > >>> Isn't an IPv6 host in charge of whether it uses address
> > >> autoconfiguration or
> > >>> DHCP? If so, PMIPv6 spec shall accommodate that, assuming it does
> > > not
> > >> want
> > >>> to dictate any particular behaviour on the hosts.
> > >>
> > >> 2461bis says
> > >>
> > >>     Router Advertisements (and per-prefix flags) allow routers to
> > > inform
> > >>     hosts how to perform Address Autoconfiguration.  For example,
> > > routers
> > >>     can specify whether hosts should use DHCPv6 and/or
> > >>     autonomous (stateless) address configuration.
> > >>
> > >> Stateful address configuration is not mandatory to support.
> > >> RFC 4294 says
> > >>
> > >>     Stateful Address Autoconfiguration MAY be supported.
> > >>
> > >> But I do agree DHCPv6 could be used between the mobile node
> > >> and the MAG (Mobile Access Gateway).
> > >>
> > >> However, the address configuration for PMIPv6 depends to a
> > >> large extent on what kind of link layer is used between the
> > >> mobile node and the MAG. If the link layer is PPP, for e.g.,
> > >> IPv6CP is used. If the link layer is an IPsec tunnel then
> > >> IKEv2 configuration payloads are used. The PMIPv6 protocol
> > >> does consider this and has some text addressing this.
> > >>
> > >> Anyway, this discussion needs to happen on the NETLMM
> > >> mailing list.
> > >>
> > >> Vijay
> > >>