Subject: RE: [Mip6] about draft-ietf-mip6-bootstrapping-split-00.txt

From: Gerardo Giaretta <[email-masked]>
Date: Fri, 05 Aug 2005 10:31:29 +0200

>  In your previous mail you wrote:
> 
>    I still think it should be part of MIPv6 code. As Vijay mentioned,
>    auht-protocol should be bootstrapped too. And in 
> integrated scenario we
>    may come up with solutions that uses IKEv1 to setup the 
> IPsec SA or with
>    scenarios where the HoA is not assigned by the Home Agent. 
> I think we
>    should not have a different DNS update solution for all these
>    bootstrapping approaches.
>    
> => Gerardo, you are forgetting an important part of the context:
> DNS update makes sense only when HoA allocation/assignment (best term
> please?) is possible. With IKEv1 this is not the case and PTR RRs
> are simply static.

I was not referring to IKEv1 as a tool to assign the HoA. My point is
that there could be other mechanisms (different from IKEv2) to assign a
HoA. Examples are DHCPv6 or HoA assignment during network access
authentication (e.g. using EAP or PANA). 

--Gerardo

> So I repeat my argument: the DNS update should be part of the tool
> which already is in charge of allocation/assignment and by the
> proposed but not yet extension in charge of the validation of MN
> auto-configured & co HoAs.
> When this tool includes the authentication (of the MN) / authorization
> (to use the mobility service including the HoA) it likely can check
> the FQDN too.
> So please don't extra burden on the shoulders of the MIPv6 code...
> 
> Regards
> 
> [email-masked]
> 
> PS: as noted this issue is a second order one: the IPv6 reverse tree
> is so poorly managed than it is nearly useless... IMHO to replace
> the intrinsicly DHAAD mechanism by DNS SRV is far more important
> (and I am running out of power :-).
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

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

---

From: Francis Dupont <[email-masked]>
Date: Fri, 05 Aug 2005 10:52:59 +0200

> please?) is possible. With IKEv1 this is not the case and PTR RRs
   
   I was not referring to IKEv1 as a tool to assign the HoA.

=> I cited IKEv1 because you did.

   My point is that there could be other mechanisms (different from
   IKEv2) to assign a HoA.

=> I agree: my argument is these other mechanisms provide DNS update
of the PTR RR.

   Examples are DHCPv6

=> DHCPv6 has it.

   or HoA assignment during network access
   authentication (e.g. using EAP or PANA). 
   
=> in general they are front ends to DHCPv6 for this function (just
there are no good reasons to reinvent the wheel). BTW it will be
likely the case of IKE CFG_REQUEST implementations, and surely
for all the other DHCP over IPsec/IKE/...
   
Regards