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

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 02 Jan 2003 13:20:46 -0500

Another alternative is simply specifiy a different
message format with a different ICMP code field and
keep the types the same.

-vlad

Vijay Devarapalli wrote:
> hi Jari and Thomas,
> 
> Jari Arkko wrote:
> 
>>Thomas Narten wrote:
>>
>>
>>>The other factor is that the simple approach now might require
>>>on-the-wire format changes later. This has a very high deployment
>>>cost.
>>
>>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.
> 
> 
> 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
> 
> 

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Jan 2003 22:32:24 +0200

> message format with a different ICMP code field and

Yes, though we'd still need Vijay's flag to signal the
desire to receive the new format.

Anyways, all the solutions are pretty equal. Can I roll
the dice and put one of them in?

Jari

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 02 Jan 2003 15:44:18 -0500

Jari

Personally I don't think that the current format needs to be
altered at all.

Whatever the new format will be, I think it should be
a separate proposal and it can be made as to not impact
the current format and processing (you've heard 2 alternatives,
and there could be more).

-vlad

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Jan 2003 23:04:32 +0200

> and there could be more).

Allright. It should be enough that we have shown there's no
deployment problems in adding the structured information, should
it become necessary. I'll mark the issue closed.

Jari