Re: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt

[Alexandru Petrescu <[e-mail]>]

Kilian Weniger wrote:
[...]
>>> - Section 6.9.2 begins with "The mobile node sends a Router 
>>> Solicitation message on the access link when ever the link-layer
>>>  detects a media change.". I think this is only the case if the
>>> MN implements DNA. If MN doesn't implement DNA, it doesn't need
>>> to send RS when it changes links.
>>> 
>> It should send RS any time it detects a media change. I will look 
>> into this.
> 
> My comment still applies in draft-06. Sending RS is only a "may" 
> according to RFC2461 and RFC2461bis:
> 
> "When an interface becomes enabled, a host may be unwilling to wait 
> for the next unsolicited Router Advertisement to locate default 
> routers or learn prefixes.  To obtain Router Advertisements quickly, 
> a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router 
> Solicitation messages each separated by at least 
> RTR_SOLICITATION_INTERVAL seconds.  Router Solicitations may be sent 
> after any of the following events:
> 
> - The interface is initialized at system startup time.
> 
> - The interface is reinitialized after a temporary interface failure
>  or after being temporarily disabled by system management.
> 
> - The system changes from being a router to being a host, by having 
> its IP forwarding capability turned off by system management.
> 
> - The host attaches to a link for the first time.
> 
> - The host re-attaches to a link after being detached for some time."
> 
> 
On this particular topic.

For one, I think the mobile will do whatever it already does when
attaching to a new link: MLD REPORT first, RS first, NS first,
optimistic DAD, or DNA.  Our requirement is to not modify the mobile, so
we can't demand the mobile what to do first.

We thus can't assume that the mobile will do a RS first when it attaches.

The MAG should be able to react on any one of the following: linkup
trigger, NS, RS and even on MLD JOIN.

Nit:
> Further, if the mobile node uses an interface identifier that is not
>  based on EUI-64 identifier, such as specified in IPv6 Stateless 
> Autoconfiguration specification [RFC-2462], there is a very low 
> possibility of a link-local address collision between the two 
> neighbors on that access link.

I think you meant "id that _is_ based on EUI-64 identifier", right?  Or
you meant "for mobiles which negotiate addresses with a ptp lower layer
protocol the probability of collision is low?

And also maybe we should refer to draft-ietf-ipv6-rfc2462bis-08.txt
and/or rfc4862 instead of rfc2462?

I think for 802.16 access we can assume the address is formed from the
48bit MAC address.

Nit:
> 
> o  The mobile access gateway on receiving the Router Solicitation 
> message SHOULD send a Router Advertisement containing the mobile 
> node's home network prefix as the on-link prefix.  However, before 
> sending the Router Advertisement message containing the mobile node's
>  home network prefix, it SHOULD complete the binding registration 
> process with the mobile node's local mobility anchor.

I think it should say that the MAG should _have_ completed the binding
registration process; because the paragraph interpreted on itself means
the order of operations is like this: RS, PBU/PBAck, RA.  Or, figure 2
says it's: PBU/PBAck, RS, RA.  I think figure 2 is correct and the
paragraph above is incorrect, should contain the 'have completed'.

Nit:
> The mobile access gateway can learn the mobile node's link-local
> address, by snooping the DAD messages sent by the mobile node for

I think a better term than 'snooping' here is to require MAG to read the 
Target Address from the NS sent by the mobile with a src address field 
unspecified.  That's surely a DAD'ing NS.  Alternatively, the MAG could 
read the dst address of that NS and convert it from multicast to 
link-local unicast format.

An even faster way for MAG to learn that address is to read and 
interpret the MLD Report message sent by the mobile _before_ that NS was 
sent.

> establishing the link-local address uniqueness on the access link.
> Subsequently, at each handoff, the mobile access gateway can obtain
> this address from the local mobility anchor to ensure link-local
> address uniqueness and may change its own link-local address, if it
> detects a collision.

This I really don't understand.  A MAG will see only one attachment of a 
mobile, not any subsequent 'handovers'.  A handover involves two MAGs.

This is really unclear to me, sorry. 	

Alex


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

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