Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-hmipv6-05.txt

From: Alexandru Petrescu <[email-masked]>
Date: 09 Dec 2001 00:24:40 +0100

Hi Greg, I'm catching up with old mails.

Greg Daley <[email-masked]> writes:
> 	I'm not sure if this is what we want to do
> 	(replicate router function), but it is an
> 	easy thing to do, and the trust relationships
> 	between adjacent nodes on a link is likely 
> 	to be easy to manage (since there is a good
> 	chance that SA exist between Routers on the
> 	same link).
> 
> 	Router Renumbering sounds OK, but who do
> 	you allow to send the MAP propagations?

Auth/authorization is something to be considered in HMIPv6, but I was
not referring to this.

In my oppinion, the section 5.2.1 of HMIPv6 draft is insufficient.  It
shows how to match a prefix and update with a MAP option.  This
deviates from "genuine" RR where you match a prefix and update with
another prefix.  From this, other things become difficult to do,
deleting MAP options for example.

I suppose that RR is normally used like this: you administer a site
and decide to replace all 3ffe:ffff::/64 with 3ffe:fffe::/64 on your
entire site.  I comes down to put 3ffe:ffff::/64 in your match
prefixes and 3ffe::fffe::/64 in use prefixes of all CHANGE messages.

In HMIPv6 as I understand it, you would need to specify all the /128
addresses of all advertising interfaces of all AR's as use-prefixes
and add the MAP option.  It's so un-natural.

> *	MAPS?
> 	
> 	If so, then dependent on the number of MAPs,
> 	the key distribution mechanisms are more
> 	complex (since it is unlikely that every AR will
> 	have an SA for every MAP). 
> 	
> *	an Central NMS?
> 
> 	If you allow just a small set of trusted servers,
> 	to send the RR Map options, then you have a
> 	situation where the NMS will have to collect
> 	information about the MAPs before distributing it
> 	on the to AR's.

Among the existing protocols that could be used for this I would
rather think of DHCPv6.  In DHCPv6 a Relay could be located with the
AR and the DHCPv6 Server would pass the address of the MAP (as it
passes the address of a DNS server.)

> 	Maybe it is appropriate to develop separate
> 	guidance for dynamic map option propagation
> 	and management?

I guess it's too early to discuss MAP (or LMM agent for that matter)
discovery.  It's not even known for sure what is wanted from a local
mobility management scheme.  MAP discovery is already in the solution
space.

> > Also, I still think HMIPv6 should specify a way to delete MAP-options
> > from an advertising interface.(RR means to do that is to put 0 in
> > use-prefix of a CHANGE).
> 
> 	It is easy to delete map options by setting the
> 	Preference value to 255 (do not use).

Any means to delete the MAP option should go hand in hand with how
genuine RR deletes prefixes from the interfaces.  I think this is not
the case now.  This is why I raised this issue.  When you delete you
need to first match it with something.  And that something can not be
a MAP option but should be a prefix.

Alex