Subject: RE: [mobile-ip] draft-ietf-mobileip-ipv6-13 comments

From: "Powell, Ken" <[email-masked]>
Date: Tue, 26 Jun 2001 10:59:08 -0400

Hi Charlie,

> > Section 5.6 ICMP Home Agent Address Discovery Request Message
> > 
> >    What does the mobile node specify in the home address field
> >    if it doesn't have a home address, like upon initialization?
> >    Should it use the unspecified address in this case?
> 
> O.K.  This sounds fine to me, but I expect that there may be
> some networks where policy forbids the operation.  Anyway,
> whether or not the operation works should be controlled by
> whether the mobile node can create a security association,
> and not by whether the protocol specification says which
> addresses to use.
 
I hadn't thought that this field would be used for a policy
table lookup. Interesting idea. I was simply looking for a
consistent way to handle the problem of not knowing the home
address at initialization to avoid possible interoperability
questions later. I see no problem having it be an optional
feature that can be disabled or rejected by local policy.

> > Section 9.2 Dynamic Home Agent Address Discovery
> > 
> >> - For each entry in this home agents ...
> >>                 ... The selected global IP address for each home
> >>   agent to include in forming the Home Agent Addresses field in the
> >>   Reply message MUST be the global IP address of the respective
> >>   home agent sharing a prefix with the mobile node's home address
> >>   as indicated in the Home Address option in the Request message;
> > 
> >    During initialization, the mobile node may not have a home
> >    address when it performs home agent address discovery. Assuming
> >    the mobile node sent the unspecified address instead, what global
> >    IP addresses does the home agent select? Perhaps it could
> >    select IP addresses that share a prefix with the destination
> >    address from the Home Agent Address Discovery Request packet's
> >    IPv6 header instead.
> > 
> >    Same problem in the fourth rule for constructing the Home Agent
> >    Addresses Field:
> > 
> >>                 ... The selected global IP address for each home
> >>   agent to include in forming the Home Agent Addresses field in the
> >>   Reply message MUST be the global IP address of the respective
> >>   home agent sharing a prefix with the mobile node's home address
> >>   as indicated in the Home Address option in the Request message;
> 
> Done.  I replaced:
> 	"mobile node's home address as indicated in the Home 
> Address option in"
> by
> 	"Destination IP address of"
> 
> However, I only found one instance of the problem; your first example
> was, I think, the text in the fourth rule.  Please let me 
> know if somehow I missed something.

Oops, looking back at my notes, I see that I misread something.
Changing the one place is OK.

> 
> 
> > Section 9.5 Intercepting Packets for a Mobile Node
> > 
> >> - The home agent examines the value of the Prefix Length field
> >>   in the new "home registration" Binding Cache entry.  If this
> >>   value is zero, the following step is carried out only for the
> >>   individual home address specified for this binding.  If, instead,
> >>   this field is nonzero, then the following step is carried out
> >>   for each address for the mobile node formed from the interface
> >>   identifier in the mobile node's home address in this binding
> >>   (the remaining low-order bits in the address after the indicated
> >>   subnet prefix), together with each one of the subnet prefixes
> >>   currently considered by the home agent to be on-link ...
> >                              ==============
> >    The home agent should forward messages considered by other
> >    routers on the home network to be on-link as well. In other
> >    words, we think the home agent should use the aggregate list
> >    of home network prefixes for this.
> 
> I don't know about this.  It seems to me that the current wording
> is correct.  I don't know about why a home agent would try to
> protect addresses that it considers to be off-link.

I assumed the home agent should be capable of intercepting
and forwarding any messages that the mobile node would accept
if it were home (except link-local of course).

I read "currently considered by the home agent to be
on-link" to mean those prefixes defined in the home agent's
own AdvPrefixList with the "L"ink bit set. If the mobile
node were home, it would autoconfigure itself to prefixes
advertised with the "A"utonomous bit set by any router
on the home subnet, not just those advertised by the home
agent.

To avoid this kind of confusion, I think "currently
considered by the home agent to be on-link" should be
changed to "included in the Aggregate List of Home
Network Prefixes (section 9.8.1) with the A bit set".

> >> - For each specific IP address for the mobile node determined
> >>   in the first step above, the home agent multicasts onto the
> >>   home link (to the all-nodes multicast address) a Neighbor
> >>   Advertisement message [17] on behalf of the mobile node, to
> >>   advertise the home agent's own link-layer address for this IP
> >>   address.
> >>
> >>   All fields in each such Neighbor Advertisement message SHOULD be
> >>   set in the same way they would be set by the mobile node itself
> >>   if sending this Neighbor Advertisement while at home [17], with
> >>   the following exceptions:
> >>
> >>    *  The Target Address in the Neighbor Advertisement message MUST
> >>       be set to the specific IP address for the mobile node.
> > 
> >    Does the home agent set the Neighbor Advertisement source IP
> >    address to its own link-local address as opposed to the
> >    mobile node's link-local address?
> 
> I think the purpose is for the home agent to substitute its own
> link-layer address for that of the mobile node.  And, it needs to
> do this for the mobile node's link-local IPv6 address also.  Thus,
> I wouldn't expect for the home agent to use its own link-local
> address in that field.

OK.

> 
> >> While a node is serving as a home agent for some mobile node (it
> >> still has a "home registration" entry for this mobile node in its
> >> Binding Cache), the home agent uses IPv6 Neighbor Discovery [17]
> >> to intercept unicast packets on the home link addressed the mobile
> >> node's home address.  In order to intercept packets in this way,
> >> the home agent MUST act as a proxy for this mobile node to reply to
> >> any received Neighbor Solicitation messages for it.  When a home
> >> agent receives a Neighbor Solicitation message, it MUST 
> check if the
> >> Target Address specified in the message matches the home address
> >> of any mobile node for which it has a Binding Cache entry marked
> >> as a "home registration".  This check MUST include all possible
> >> home addresses for the mobile node, based on the subnet prefixes
> >> currently considered to be on-link by the home agent ...
> >                                     =================
> > 
> >    The home agent probably should use the aggregate list of prefixes
> >    for this as well?
> 
> Maybe I'm missing something, but I think the "on-link" criterion
> is appropriate here as well.

Same reasoning as above.

> 
> > Section 9.6 Tunneling Intercepted Packets to a Mobile Node
> > 
> >> Tunneling of multicast packets to a mobile node follows similar
> >> limitations to those defined above for unicast packets addressed to
> >> the mobile node's link-local and site-local addresses.  Multicast
> >> packets addressed to a multicast address with link-local scope [9],
> >> to which the mobile node is subscribed, MUST NOT be tunneled
> >> to the mobile node; such packets SHOULD be silently discarded
> >> (after delivering to other local multicast recipients).  Multicast
> >> packets addressed to a multicast address with scope larger
> >> than link-local but smaller than global (e.g., site-local and
> >> organization-local) [9], to which the mobile node is subscribed,
> >> SHOULD be tunneled to the mobile node by default, but this behavior
> >> MUST be configurable to disable it; this default behavior might
> >> change at some point in the future as the definition of these
> >> scopes become better defined in IPv6.
> > 
> >    This spec does not explain how a home agent determines what
> >    multicast addresses to forward to a mobile node. Host systems
> >    normally send Multicast Listener Discovery (MLD) messages to
> >    attached routers to join/leave multicast groups. The rules
> >    for doing this between mobile node and home agent are undefined.
> 
> Not really...?  Why can't the tunneled packets use the same rule
> as in other cases.  In other words, the mobile node should use
> a Home Address destination option here, but that would be implicit.
> It would be a mistake for the Mobile IPv6 specification to go specify
> the inclusion of the Home Address option for _every_ possible 
> application  between endpoints.  Tunneling is not essentially
> different here, as far as I can tell.

The problem I have is that the term "tunnel" is extremely
ambiguous. I can envision multiple ways to set up tunnels
between a mobile node and its home agent. For example, I
get the impression from your statement here that you were
thinking of creating a bi-directional tunnel between the
mobile node's home address and the home agent's address.
I always assumed you were intending to create the tunnel
using the mobile node's care-of address for the tunnel
endpoint as is done in section 9.6. 

> 
> >    The text above and in section 10.19 indicates a bi-directional
> >    tunnel could be used to support this. There is no clear 
> definition
> >    of how to set up such a tunnel. What addresses are used for
> >    tunnel source and destination? Would the tunnel have its own
> >    link local and global interface addresses? Will it carry MLD
> >    traffic specifically for the mobile node? What other traffic
> >    should such a tunnel between a mobile node and the home agent
> >    carry?
> 
> I don't think there is a problem here.  The tunnel should be set
> up just like any tunnel would be set up. The outer header should
> have the natural IP addresses.

What are the tunnel endpoints? The home agent address is one,
but do we use the mobile node's home address or care-of address
for the other?

> A home address destination option
> would be used as normal.  The inner header should have the same
> field values as if the mobile node were on its home network.

I agree with this part, and think it should be stated.

> Policy determination for tunnel use is, I reckon, outside the scope
> of the Mobile IPv6 specification. Otherwise, we would have to do
> it for every protocol, not just MLD.  That could be bad, and seems
> like a major potential source for specification errors.

I thought MLD was critical to supporting multicast traffic
on a host in much the same way as Router Solicitation/
Advertisements are critical to unicast traffic support.
Therefore, I think MLD is a special case that needs to
be mentioned how it fits. It could be obvious depending
on how the tunnel setup is defined.

> >    IMHO we should not try to solve the multicast tunneling
> >    issues now. Instead, descriptions of tunneling multicast
> >    traffic should be removed from the spec and left for future
> >    work. Perhaps the spec could say something like:
> > 
> >  + It may be possible to tunnel multicast traffic between
> >  + a mobile node and it's home agent to extend the range of
> >  + a multicast zone. The rules for setting up such tunnels and
> >  + for identifying which traffic to forward is beyond the scope
> >  + of this spec.
> 
> As of now, I don't believe this is the right technical direction;
> I have left the current specification as is.

In that case, I think more detail will be needed in this section.

I envision the mobile node and the home agent set up bi-directional
tunnels per RFC 2473 between the mobile node's home address and the
home agent's address to carry multicast traffic. The tunnel pseudo
interfaces must have link local addresses to support MLD (RFC 2710)
traffic between the home agent and the mobile node. Global addresses
on the tunnel pseudo-interfaces are not necessary.

This sounds like quite a bit of overhead in the home agent
for a feature that may not be used often. Would it make sense
to add a flag to the binding update request/response options
to request support for such a tunnel? This might give home
agents an option to save memory when the overhead is not
needed.

Section 9.7 mentions that the home agent MUST support decapsulating
reverse tunneled packets. What is the tunnel source address in this
case, the mobile node's care-of address or its home address? Will
it use the same bi-directional configured tunnel that is used to
support multicast traffic?

> > Section 10.19 Routing Multicast Packets
> > 
> >  > Alternatively, a mobile node MAY join multicast groups via a
> >  > bi-directional tunnel to its home agent.  The mobile 
> node tunnels its
> >  > multicast group membership control packets to its home 
> agent, and the
> >  > home agent forwards multicast packets down the tunnel to 
> the mobile
> >  > node.
> >  >
> >  > A mobile node that wishes to send packets to a multicast group
> >  > also has two options:  (1) send directly on the foreign 
> link being
> >  > visited; or (2) send via a tunnel to its home agent.  Because
> >  > multicast routing in general depends upon the Source 
> Address used in
> >  > the IPv6 header of the multicast packet, a mobile node 
> that tunnels a
> >  > multicast packet to its home agent MUST use its home 
> address as the
> >  > IPv6 Source Address of the inner multicast packet.
> > 
> >    Same concern with multicast messages as for section 9.6. We think
> >    this spec should describe option (1) and leave option 
> (2) as beyond
> >    scope for now.
> 
> Well, I hope we can keep the specification.  It's likely to work well
> enough for Proposed Standard, and deployment and experience 
> are clearly
> needed.

I'm beginning to agree, just need to nail down what the tunnel
endpoints are, and that the tunnel pseudo-interfaces must be
configured with link-local addresses to carry MLD traffic. Also
be clear that we are using bi-directional tunnels as defined in
RFC 2473. 

> 
> > Section 10.20 Returning Home
> > 
> >> .....
> >> In addition, when returning home prior to the expiration 
> of a current
> >> binding for its home address, and configuring its home 
> address on its
> >> network interface on its home link, the mobile node MUST 
> NOT perform
> >> Duplicate Address Detection on its own home address, in order to
> >> avoid confusion or conflict with its home agent's use of the same
> >> address.  .....
> > 
> >    Could a mobile node perform DAD if it had knowledge of the home
> >    agent's link layer address? It could work as follows:
> > 
> >      1) the mobile node runs DAD when it moves to any new
> >         physical link;
> >      2) if this happens on the home link, the home agent will
> >         respond with a neighbor advertisement defending the mobile
> >         node's address;
> >      3) the mobile node recognizes the home agent's link
> >         layer address in the neighbor solicit and thus
> >         determines it moved home;
> >      4) the mobile node immediately sends a binding update
> >         to the home agent to delete the binding (no neighbor
> >         solicit needed);
> >      5) the home agent responds with a binding ack to
> >         signal that the binding is deleted and the home
> >         agent is no longer defending the mobile node's
> >         home address;
> >      6) The mobile node runs DAD again;
> >      7) Communication proceeds as normal.
> 
> I don't see anything wrong with this, but on the other hand I am
> reluctant to put it into the revised protocol specification without
> some additional working group discussion.

I understand. This is one mechanism that would be extremely
easy to add later, so I have no problem leaving the spec as
is for now. Perhaps I should start a separate discussion
on this point?

> 
> > 11. Protocol Constants
> > 
> >>   HomeRtrAdvInterval        1,000 seconds
> > 
> >    This is the maximum interval between periodic router
> >    advertisements from the home agent to the mobile node.
> >    Given that advertisements are acknowledged and the
> >    periodic advertisements are primarily a fail-safe
> >    feature, would it be reasonable to increase this to
> >    something like 36000 seconds (1 hour) to further
> >    overhead?
> 
> I guess you meant 3600 seconds.  So, I made that change.

Yes. Got carried away with those zeros.

Thanks
Ken

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sat, 30 Jun 2001 19:31:56 -0700

> endpoint as is done in section 9.6.

Maybe the tunnel does not need a lot of setup.  Is it O.K.
to use the home address?  The only reason for using the
care-of address would be if the mobile node doesn't have
a valid home address, it seems to me, except maybe for some special-
case protocol that I don't know about.

>>>    tunnel could be used to support this. There is no clear definition

How about the home address?

> I agree with this part, and think it should be stated.

Again, if the _general_ packet from a mobile node to the home
agent uses the Home Address destination option, and there isn't
any specific reason why these packets are different, then I am
not yet understanding why it has to be stated for these particular
cases, in addition to the implicit specification which would
be inferred from the general case.

But if you can suggest some natural text, I could go ahead and
include it as long as people agree that it is O.K. to do so.

> on how the tunnel setup is defined.

But if the special case just works like the general case, then
the special case is not special in this particular regard.

...

> on the tunnel pseudo-interfaces are not necessary.

But then we might start to import more of RFC 2710 into the Mobile IPv6
specification.  That is scary.

> agents an option to save memory when the overhead is not

Maybe this kind of tunneling doesn't automatically require
tunnel setup beforehand.  What if the mobile node sends a
tunneled packet to the home agent without any setup?  Then
the home agent would have to check to see whether it was
legal to receive a packet.  Any required setup could be done
at that time, it seems to me.

> support multicast traffic?

How about using the home address?

> be clear that we are using bi-directional tunnels as defined in

Do you still think so after the discussion up until now?

Regards,
Charlie P.