Subject: Re: [mobile-ip] Mipv6 issue #160: HA discovery single address (was: AD review comments)

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Dec 2002 14:50:53 +0200

Vladislav Yasevich wrote:
> I am not sure I understand the issue here...
> 
> HA discovery protocol provides a list of global HA addresses to
> the mobile node.  That list is generated by each HA and is based
> on all of the RAs with 'H' bit set and  Prefix Info options with
> the 'R' bit set that were seen on the "home" link.
> 
> If there are multiple prefixes (prefix info options) advertised by
> a home agent on the home link, there is nothing stopping that HA from
> setting the 'R' bit for each prefix.  This will result in multiple
> addresses being added to the Home Agent List.

You are right about the HAL itself, but the current text for constructing
DHAAD replies indicates that only a single address be selected for
the response. This was seen as a problem.

Anyway, I've been working on the text to fix this issue. Here comes:

The basic approach is to change the reply message format to carry
multiple addresses per home agent, and to show that certain addresses
belong to a certain home agent. At the same time I'm suggesting we get
rid of the DHAAD reply omit-your-own-ip optimization as it becomes
more cumbersome with the new format.

Comments appreciated.

In Section 6.6, change the format of the reply message to the
following:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |            Checksum           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Identifier          |             Reserved          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    .                                                               .
    .                       Home Agent Entries                      .
    .                                                               .
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Home Agent Entries

        A list of home agents on the home link for the mobile
        node. Each home agent is described by an entry of the format
        described below. The number of entries present in the list is
        indicated by the remaining length of the IPv6 packet carrying
        the Home Agent Address Discovery Reply message, and the length
        of the entries.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Number of Addresses       |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                           Reserved                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    .                                                               .
    .                       Home Agent Addresses                    .
    .                                                               .
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Number of Addresses

        This 16 bit unsigned integer field specifies the number of
        addresses for this home agent.

    Reserved

        This field is unused.  It MUST be initialized to zero by the
        sender and MUST be ignored by the receiver.

    Home Agent Addresses

        A list of addresses for the given home agent. The number of
        addresses present in the list is indicated by the Number of
        Addresses field.

In Section 10.5.1, replace the current list of response construction
rules with the following. Note that the optimization about the
respnding agent's own address has been taken away at the same time,
since it would become more complex given the new structure.

    The Home Agent Entries field in the Reply message is constructed as
    follows:

     -  The Home Agent Entries field SHOULD contain an entry for
        each home agent currently listed in this home agent's
        own Home Agents List (Section 10.1).

     -  The entries in the Home Agent Addresses field SHOULD be listed
        in order of decreasing preference values, based either on the
        respective advertised preference from a Home Agent Information
        option, on the default preference of 0 if no preference is
        advertised, or on the configured home agent preference for this
        home agent itself.

     -  Among home agents with equal preference, the entries in the Home
        Agent Entries field SHOULD be listed in an order randomized
        with respect to other home agents with equal preference. A new
        random order is provided every time the Home Agent Address
        Discovery Reply message is returned by this home agent.

     -  The Home Agent Addresses field in each entry SHOULD contain the
        global IP addresses for the given home agent. These addresses
        SHOULD be listed in a randomized order.

     -  The home agent SHOULD reduce the number of entries so that the
        packet fits within the minimum IPv6 MTU [11]. The home agents
        selected for inclusion in the packet SHOULD be those from the
        complete list with the highest preference. If minimum IPv6
        MTU is exceeded even with a single entry, the home agent SHOULD
        reduce the number of addresses by removing randomly selected
        addresses from this entry.

In Section 11.4.1, change

    ... link that receives this Request message will return an ICMP Home
    Agent Address Discovery Reply message, giving this home agent's own
    global unicast IP address along with a list of the global unicast IP
    address of each other home agent operating on the home link. ...

=>

    ... link that receives this Request message will return an ICMP Home
    Agent Address Discovery Reply message, giving the global unicast IP
    addresses for the home agents operating on the home link. ...

and

    The mobile node, upon receiving this Home Agent Address Discovery
    Reply message, MAY then send its home registration Binding Update to
    the home agent address given as the IP Source Address of the packet
    carrying the Reply message or to any of the unicast IP addresses
    listed in the Home Agent Addresses field in the Reply.  For example,
    if necessary, the mobile node MAY attempt its home registration
    with each of these home agents, in turn, by sending each a Binding
    Update and waiting for the matching Binding Acknowledgement, until
    its registration is accepted by one of these home agents.  The mobile
    ...

=>

    The mobile node, upon receiving this Home Agent Address Discovery
    Reply message, MAY then send its home registration Binding Update
    to any of the unicast IP addresses listed in the Home Agent
    Addresses field in the entries contained in the Reply. For
    example, if necessary, the mobile node MAY attempt its home
    registration with each of these home agents, in turn, by sending
    each a Binding Update and waiting for the matching Binding
    Acknowledgement, until its registration is accepted by one of these
    home agents. The mobile ...

In Section 11.7.1, add the following text to indicate that
retransmission may optionally try a secondary address as well as a
secondary home agent:

    The mobile node MAY also try an alternative unicast IP address
    for currrent home agent.

---

From: Brian Haley <[email-masked]>
Date: Mon, 16 Dec 2002 12:00:04 -0500

Hi Jari,

I think this is making DHAAD more complex than it needs to be.

When I first read this section of the draft (in #13), I was under the
impression that there could be a MN that only knows it's home prefix,
does DHAAD, and gets a reply with HAs *only* with that prefix.

When I implemented it, I realized that wasn't correct since the text
says to return all HA addresses on-link - that's easy enough to do too.

Now we must keep them sorted into HA Entry lists and remember more than
just the prefix info, ugh.

Maybe a good question to ask is: "What does the MN need in a DHAAD
reply to choose a Home Agent?".  I'm not sure the new list structure
is any better than what we have now for bootstrapping the MN - the only
difference I see is that a MN shouldn't try the same HA twice on a
failure (ie each HA Entry section is treated singularly on error).  Now
I'm not a MN implementor, what do they feel is necessary?  I don't like
this change as an HA implementor this late in the process.

-Brian

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Dec 2002 19:33:54 +0200

> I think this is making DHAAD more complex than it needs to be.

I don't like the added complexity either, but read on...

> this change as an HA implementor this late in the process.

I think there's two issues here. One issue is whether we return a single
or multiple addresses for the home agent. The second issue is whether there's
structure in the answer that allows us to determine which addresses belong
to the same home agent.

I guess Thomas' primary concern was not including all addresses. We currently
give only one global address as a response to a query. We can fix this
by saying that all addresses should be included.

Perhaps your complexity concerns are related more to the structure question.
Yes, the fallback behaviour appears to be the only possible reason why
the structure would be needed. OTOH, it isn't clear to me that the likelihood
of a HA being down is any different from a particular path to the HA being
down in a multihoming case. Does this point to just including all addresses
and not having any structure? I don't know. What do you think?

Jari

---

From: Vladislav Yasevich <[email-masked]>
Date: Mon, 16 Dec 2002 13:43:33 -0500

Jari

> the response. This was seen as a problem.

I missed that text.  Upon another reading this text (section 10.5.1, p 87)
somewhat contradicts the text in section 6.6 (at least it looks
inconsistent).

> more cumbersome with the new format.

One questions about the reasons for the proposal.
Is it really necessary for a MN to know which set of addresses
belongs to the which/same home agent?

I mean, given a list of addresses, MN can just try then in the order
of preference and use the first one that works.

I think we can simply get away with changing text in 10.5.1 to say
that all HA addresses on the link should be transmitted, but a given
HA may optimize the list by sending 1 address per home agent randomizing
which one address is picked.  So if a give HA addvertizes 3 address, then
the HA either transmitts all 3 or picks one at random every time.

Just a thought.

Additionally, I would support the getting rid of "omit-your-own-ip", but
I don't have a very strong feeling about it.

-vlad
-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Brian Haley <[email-masked]>
Date: Mon, 16 Dec 2002 15:30:43 -0500

> the HA either transmitts all 3 or picks one at random every time.

Something like this sounds fine with me, and has minimal impact on the
current draft.

> I don't have a very strong feeling about it.

I would too, but we've already been down that road in another thread...

-Brian

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Dec 2002 00:28:00 +0200

>>that all HA addresses on the link should be transmitted, but a given

It seems like we are coming to this conclusion, yes. I'm ready to go
for all-addresses-but-no-structure approach. Thomas, are you OK with
it?

The required text changes are then quite small. I'll post them to the
list tomorrow after I have gotten some sleep (its after midnight here).

> Something like this sounds fine with me, and has minimal impact on the

I thought about this too. I'd actually prefer listing all addresses.
I *do* like the pick-a-random-address-at-the-HA approach, but I'm
not sure it fits the DHAAD "philosophy" so well. If we wanted the HA
to start picking addresses, wouldn't it have been enough for the
DHAAD reply to return a *single* address from the start? Better yet, why
not rely on anycast and look at the source address of the reply?

> I would too, but we've already been down that road in another thread...

My proposal to get rid of it was in the new situation with the more
complicated format. We had get rid of it in that case. Do we still have
a changed situation with just multiple addresses but same format? Dunno.
[We *do* have AD comments complaining about "questionable micro-optimizations".
I say the ADs comments are enough for us to reopen the issue and revert
the earlier decision.]

Jari

---

From: Brian Haley <[email-masked]>
Date: Mon, 16 Dec 2002 17:48:19 -0500

> for all-addresses-but-no-structure approach. Thomas, are you OK with

I would still like to see input from a MN implementor on this, but I
guess silence implies agreement...

> I say the ADs comments are enough for us to reopen the issue and revert

Ok, and this would make the MN people happy too.

-Brian

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 16 Dec 2002 15:35:45 -0700

Brian -

> guess silence implies agreement...

Yes, silence implies consent. Believe me, our "optimized for embedded
systems" MN implementation isn't going to be tracking which set of HA
addresses belong to which HA, we are just going to be trying HA addresses
returned in the list in the given preference order until we find one that
works.

Also, FYI we won't ever be looking in the Router Advertisements to discover
a HA when we are on the home network, we will always use DHAAD for this
purpose regardless of whether we are on the home network or on a foreign
network (see issue #166 "Allow DHAAD in home"). That simplifies our MN
logic, and reduces code size.

> Ok, and this would make the MN people happy too.

Yup. I'm holding my breath and hoping ;-)

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Dec 2002 17:53:35 -0800

> for all-addresses-but-no-structure approach. Thomas, are you OK with

I too prefer the no-structure approach. the other option is just too
complicated.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Dec 2002 14:00:47 +0200

Ok, it seems most folks prefer the multiple-address-but-no-structure
approach as well as getting rid of the "questionable micro-optimization"
at the same time. The rest of this e-mail lists the text modifications.

Comments appreciated.

In Section 10.5.1, replace the current list of response construction
rules with the following.

    The Home Agent Addresses field in the Reply message is constructed as
    follows:

     -  The Home Agent Addresses field SHOULD contain all global IP
        addresses for each home agent currently listed in this home
        agent's own Home Agents List (Section 10.1).

     -  The IP addresses in the Home Agent Addresses field SHOULD
        be listed in order of decreasing preference values, based
        either on the respective advertised preference from a Home
        Agent Information option or on the default preference of 0 if
        no preference is advertised (or on the configured home agent
        preference for this home agent itself).

     -  Among home agents with equal preference, their IP addresses
        in the Home Agent Addresses field SHOULD be listed in an
        order randomized with respect to other home agents with equal
        preference, each time a Home Agent Address Discovery Reply
        message is returned by this home agent.

     -  If more than one global IP address is associated with a
        home agent, these addresses SHOULD be listed in a randomized
        order.

     -  The home agent SHOULD reduce the number of home agent IP
        addresses so that the packet fits within the minimum IPv6
        MTU [11]. The home agent addresses selected for inclusion in the
        packet SHOULD be those from the complete list with the highest
        preference. This limitation avoids the danger of the Reply
        message packet being fragmented (or rejected by an intermediate
        router with an ICMP Packet Too Big message [14]).

=>

and

=>

    The mobile node, upon receiving this Home Agent Address Discovery
    Reply message, MAY then send its home registration Binding Update
    to any of the unicast IP addresses listed in the Home Agent
    Addresses field in the Reply. For example, the mobile node MAY
    attempt its home registration to each of these addresses, in turn,
    until its registration is accepted. The mobile node sends a Binding
    Update to an addresses and waits for the matching Binding
    Acknowledgement, moving on to the next address if there is no
    response. The mobile ...

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 17 Dec 2002 10:12:46 -0500

Jari

> not rely on anycast and look at the source address of the reply?

I thought that "pick-a-random-HA-address" would provide better "path
balancing" ie. HA reachable via path A vs. path B.

On the onther hand I don't know if thats such a great idea, so
I really don't care about this.

Another way can think about this is, if you have some many addresses,
you'll blow the MTU.  This is one optimization to decrease the
amount of addresses sent.

-vlad--

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Dec 2002 18:15:00 +0200

> amount of addresses sent.

We can actually accommodate that, I think, if the last bullet in the
list construction rules is as follows:

     -  The home agent SHOULD reduce the number of home agent IP
        addresses so that the packet fits within the minimum IPv6
        MTU [11]. The home agent addresses selected for inclusion in the
        packet SHOULD be from the home agents with the highest
        preference, with a random selection if there are multiple home
        agents with the same preference or when there are multiple addresses
        for a single home agent. This procedure avoids the danger of the Reply
        message packet being fragmented (or rejected by an intermediate
        router with an ICMP Packet Too Big message [14]).

As far as adopting this for all DHAAD replies... I have nothing
against that but I think if we go down that path then we should change
the nature of the replies to return always just a single address.

Jari

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 17 Dec 2002 11:30:26 -0500

Jari

Ok, I agree.

-vlad

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 17 Dec 2002 08:46:30 -0700

Jari -

Awesome. I think you missed one, please also remove the following MN
requirement from section 11.4.1. "Dynamic Home Agent Address Discovery":

"If the home agent identified by the Source Address field in the IP header
of the packet carrying the Home Agent Address Discovery Reply message is not
listed in the Home Agent Addresses field in the Reply, it SHOULD be tried
before the first address given in the list; otherwise, it SHOULD be tried in
its listed order."

You could also change the status of issue #165 "HA address in DHAAD response
always" from "Rejected" to "Adopted", since I believe that is what you are
doing here when you remove the "questionable micro-optimization".

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jari Arkko
> Sent: Tuesday, December 17, 2002 5:01 AM
> To: Vijay Devarapalli
> Cc: Brian Haley; Vladislav Yasevich; [email-masked];
> Thomas Narten
> Subject: Re: [mobile-ip] Mipv6 issue #160: HA discovery single address
> (was:ADreview comments)
>
>

---

From: Thomas Narten <[email-masked]>
Date: Tue, 17 Dec 2002 12:04:51 -0500

> by saying that all addresses should be included.

Yes. I question whether it is wise to assume that a node other than
the MN can pick a single address out of a set of addresses for a
specific HA (and hard wire this into the protocol where it can't be
changed later). This would be like having the DNS return on only one
address in a AAAA query under the theory that a node doesn't need to
know the other addresses. This assumption is not valid in general. Why
would it be valid in the case of MIPv6?

Thus,  I would assume that the right thing (for at least the protocol
formats to support) is that one can list all HAs, and all of their
individual addresses (group together as belonging to the same HA). 

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 17 Dec 2002 12:08:03 -0500

> of preference and use the first one that works.

A better strategy might be  to try different HAs, not just different
addresses. Would you want the first three attempts to contact a HA to
be using different addresses for the same node? That would be
suboptimal if the HA were down.

A better strategy might be to try another HA (and maybe even a
different prefix) next.

The current message format (that just has a single address) or a
format that doesn't indicate which addresses belong to the  same HA
don't allow this sort of an algorithm. That seems like a mistake to
wire into the  protocol formats today, as it will be hard to change later.

Thomas

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 17 Dec 2002 10:01:52 -0700

Thomas -

In some cases, the HA won't be down, but the MN is just having trouble
communicating with it when it is trying to do DHAAD. A wireless MN will
probably frequently experience a temporary loss of network connectivity;
even with a very reliable L2, packets (i.e. DHAAD request or reply) will
sometimes be lost/dropped because of this. How can the MN tell the
difference between this case and the case where the HA is just simply down
(i.e. without access to L2 information)? Even if the HA is down, it might be
in the process of rebooting. If the HA is not down but instead the MN is
experiencing a temporary loss of network connectivity, the MN should keep
trying other HA addresses in the list in the given preference order,
regardless of whether or not they belong to the same HA which may or may not
actually be down.

If the HA is down for an extended period of time, then its addresses should
not appear in the DHAAD reply that the MN receives. So, in that case there
is no reason for concern if the MN just iterates through that list trying
each HA in preference order until it finds one that works.

The MN won't be executing DHAAD that frequently, only when it doesn't have a
HA to use. In that case, it is "dead-in-the-water" w/ respect to using any
of its home addresses on a foreign network. So, whether DHAAD takes 5
seconds or over a minute to complete successfully in this scenario doesn't
seem to matter that much. Once the MN finds a working HA, it should persist
that in NVRAM so that it continues to try to use the same HA, regardless of
any temporary loss of network connectivity. Resorting to another DHAAD to
find a new HA should be a last resort.

Also, w/ regards to interface design (which I expect also applies to
protocol message design), if there isn't a really good reason to add some
extra piece of information/status/control to an interface, then don't do it.
IMHO there doesn't seem to be a really good reason for including the extra
information about which HA addresses belong to which specific HA in the
DHAAD reply, for example.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> [mailto:[email-masked]]On Behalf Of Thomas Narten
> Sent: Tuesday, December 17, 2002 10:08 AM
> To: Vladislav Yasevich
> Cc: Jari Arkko; [email-masked]
> (was: AD review comments)
>
>

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 17 Dec 2002 12:13:06 -0700

Jari -

Perhaps I jumped the gun with my excitement...

Are we leaving the other "Rejected" issue #165 text in the draft? I assume
that is there for the MIPL implementation, which gets HA addresses from the
HA list it maintains but doesn't know if an interface is acting as a HA
necessarily (unless it sends RAs on that interface with the H-bit set,
causing it to discover its own addresses as HA addresses) therefore may not
put its own address in the HA list it returns in the DHAAD reply. If this is
the case, then perhaps we can tone it down to say something like the
following:

"If the Home Agent Addresses field in the Home Agent Address Discovery Reply
message is empty, then the MN MAY use the home agent identified by the
Source Address field in the IP header of the packet carrying that message."

This seems like that would allow the MN to handle the case of interoperating
with a HA implementation that doesn't include its own addresses in the HA
list of the DHAAD reply. Or, if you'd prefer, you could make it a SHOULD
instead of a MAY. This requirement is a little simpler than the current
requirement, which has the MN always first checking the entire content of
the Home Agent Addresses field to see if the source address of the DHAAD
reply message is in the HA list before it can select a HA address.

Anyways, unless I hear otherwise, I'm assuming the current requirement on
the MN (i.e. "Rejected" issue #165 text) still stands.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> [mailto:[email-masked]]On Behalf Of Ed Remmell
> Sent: Tuesday, December 17, 2002 8:47 AM
> To: Jari Arkko; Vijay Devarapalli
> Subject: RE: [mobile-ip] Mipv6 issue #160: HA discovery single address
> (was:ADreview comments)
>
>
> Jari -
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Dec 2002 23:35:02 +0200

> would it be valid in the case of MIPv6?

Right. I think everyone's now in agreement with this, and sees that
we need to get all the addresses.

> A better strategy might be to try another HA (and maybe even a

This is the part that is still debated. There seems to be a few
issues involved:

- I initially assumed this would be exactly the strategy, if the
   HA doesn't answer try the next one. However, after the discussion
   on this list I'm no longer sure this is the right thing. If
   we can't reach agent1 with address agent1addr1, is it more likely
   that agent1 is down or that the path associated with agent1addr1
   is down? So should we try agent2addr1 (that uses the same path)
   or agent1addr2 which uses a different prefix. I don't know
   the answer. If we don't know the answer, will the mobile node
   be able to do any better than choosing "one of the yet untried
   addresses"? And if this is what it does, why bother to carry
   more information in the messages?

- The complexity of the format necessary to group the addresses
   together gets some pushback from folks.

- It is true that if we later discover a way to use the
   structured information then the flat format will prevent that.
   (Unless we start to use some heuristics, such as matching
   IIDs of different addresses to find out which of them are for
   the same HA.)

Overall, this seems like a tradeoff between simple & sufficient
for now vs. complex & possibly useful later.

Jari

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 17 Dec 2002 16:56:07 -0500

Jari

I agree with your analisys.  I would vote for simple & sufficient.

If we determine later that it is not necessary, the protocol can
be easily extended to support structured format.

-vlad

---

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Dec 2002 00:03:09 +0200

Ed Remmell wrote:

> I think you missed one, please also remove the following MN

Right. Thanks.

> doing here when you remove the "questionable micro-optimization".

Yeah.

 > Source Address field in the IP header of the packet carrying that message."

Lets just fix the "questionable micro-optimization" and avoid all this...
of course your implementation should be liberal in what it accepts so
you may of course do the above as well.

Yes, some implementations may have to change. But the shorter the spec
is, the happier I am...

Jari

---

From: Thomas Narten <[email-masked]>
Date: Tue, 17 Dec 2002 17:35:59 -0500

> we need to get all the addresses.

OK. I wasn't entirely sure from the thread.

> This is the part that is still debated. There seems to be a few

To be clear, I'm not saying my proposal should be what goes into the
spec. For now, its probably fine to just say go through them in order
(or something).

But, I think it would be better to not preclude such an algorithm in
the future, should the simpler ones turn out to be inadequate.

>    more information in the messages?

Agree with the above. So, one possibility  it so try agent2addr2
*next*, i.e., pick a different HA *and* a different prefix, in order
to increase the odds of picking something that works. (at least for
equal preference HAs)

>    together gets some pushback from folks.

I understand. Its also painful to see 6 bytes of padding needed...

> for now vs. complex & possibly useful later.

The other factor is that the simple approach now might require
on-the-wire format changes later. This has a very high deployment
cost.

Thomas

---

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Dec 2002 15:19:55 +0200

> on-the-wire format changes later. This has a very high deployment

Yes.

So how do we resolve this? There's a tradeoff between the perceived
complexity now and the possibility that we need more information later.
The camp that dislikes the structured format seems pretty strong.

Can we find some compromise in using the current format, but modified
in a manner that it makes it possible to extend it later? The current
format is not extensible at all because the receiver will assume all
data is IP addresses.

For instance, if we added a Number-of-Addresses field, a Reserved
field for future flags, and mandated that current implementations
shall not read the message beyond what Number-of-Addresses indicates?
This is still a relatively simple format for current implementations
but allows a later extension that would group the addresses.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 30 Dec 2002 18:32:28 -0800

hi Jari and Thomas,

> format is not extensible at all because the receiver will assume all

here is another suggestion. we can have three ICMP messages.

ICMP type 150 - "Home Agent Address Discovery Request Message"

ICMP type 151 - "Home Agent Address Discovery Reply Message". 
 
    no change from draft 19. it still contains a list of addresses
    of home agents on the home link. one address per home agent

ICMP type 152 - "Extended Home Agent Address Discovery Reply Message".
    this message is new and it contains multiple addresses per 
    home agent. this can be of the format Jari suggested earlier.

there is already a reserved field in the request message (section 
6.5). we can introduce a flag in this reserved field to request 
either 151 or 152. if the MN is capable of keeping track of 
multiple addresses per home agent then it sets the bit to 1 and
gets the reply 152. if the bit is 0, its gets 151 back.

the bit in the reserved filed, ICMP type 152 and how the MN keeps
tracks of multiple addresses per home agent can be specified in
a separate spec as an extension to the base MIPv6 spec. this 
separate spec should also talk about what to do if the MN wants
152, but the home agent can only send 151.

this approach lets you keep the current simple format while making
it possible to extend it later.

comments?

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 31 Dec 2002 12:20:30 +0200

> it possible to extend it later.

So, are you suggesting to define all these formats now in draft 20,
or do only 150/151 and add 152 later? At the moment I see _some_
potential future need for the structured information, but I would
not like to add the complexity to the current protocol. (I'm hoping
that Thomas agrees that the possibility of adding the structured
information without horrible deployment problems is enough.)

IF we can't do this but need to add the structured information
in draft 20, then I'd really like to have just one format, the
complex one. BUT if we don't need to do it now, then we need an
"extensibility solution". We have two candidates:

1) Add a length field to the current format, making it possible
    to add some data beyond the IP addresses and make this ignored
    by current hosts. Advanced hosts would be able to read also the
    new data.
2) Settle for adding a flag and a new message type when we need
    the structured information.

The advantage of the first candidate is that the eventual solution
is pretty simple. The disadvantage is a small change in the current
format. The advantage of the second candidate is that no modifications
whatsoever are needed in draft 20. The disadvantage is a more complicated
end result, if it turns out later that we need the structured information.

I'm really fine solving this either way. Thomas, are you happy with the
possibility of adding the structured information easily in a later
protocol extension? If yes, do you have a preference between candidates
1 and 2?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 31 Dec 2002 12:48:45 +0200

>    the structured information.

Here's the proposed format modification for the first candidate
solution. (The second candidate solution uses the current format, and
extends it later by allocating a bit from the current "Reserved" field.)

    6.6. ICMP Home Agent Address Discovery Reply Message

    The ICMP Home Agent Address Discovery Reply message is used by a home
    agent to respond to a mobile node that uses the dynamic home agent
    address discovery mechanism, as described in Section 10.5.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |            Checksum           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Identifier          |   No of Addrs |    Reserved   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    .                                                               .
    .                      Home Agent Addresses                     .
    .                                                               .
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type

          151 <To Be Assigned by IANA>

       Code

          0

       Checksum

          The ICMP checksum [14].

       Identifier

          The identifier from the invoking Home Agent Address Discovery
          Request message.

       No of Addrs

          This 8 bit unsigned integer field indicates the number of home
	 agent addresses sent in this message. The indicated number of
	 addresses MUST fit to the IPv6 packet carrying this message.

       Reserved

       Home Agent Addresses

          A list of addresses of home agents on the home link for the
          mobile node.  The number of addresses present in the list is
          indicated by the No of Addrs field. If the IPv6 packet carrying
	 this message contains data beyond the indicated number of
	 addresses, that data MUST be initialized to zero by the sender
	 and MUST be ignored by the receiver.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 31 Dec 2002 10:22:22 -0800

Jari Arkko wrote:
> or do only 150/151 and add 152 later?

I was saying 150 and 151 now in draft 20. 152 can be done later.
the bit in the reserved field is also be done later.

> At the moment I see _some_

I prefer (2). but fine with (1) also.

Vijay