Subject: [mobile-ip] Mipv6 issue #235: dhaad and prefixlen != 64

From: Jari Arkko <[email-masked]>
Date: Mon, 03 Feb 2003 18:19:16 +0200

Pekka Savola writes:

 > issues about possible subnets where prefixlen is longer than 64, as
 > noted by draft-savola-ipv6-127-prefixlen-04.  Should there be an explicit
 > restriction (somewhere) to use DHAAD only if the prefix length is 64?

Yes.

Note that that while RFC 2373 doesn't define any prefixs other than those
of 64 bits, RFC 2526 allows the home agent anycast address to have also
other prefix lengths. But as you correctly note in your draft, this
fails when the prefix length becomes too small...

We could of course try to formulate an exact rule when these other
prefix lengths could be used, but I fear that might become a lengthy
discussion. So I agree with you that we should specify the use of
only 64 bit prefix lengths for DHAAD. Add to Section 6.5:

   "It is assumed that the home subnet prefix length is 64 bits."

Add to section 11.4.1, second paragraph:

   "In this case, the mobile node MAY attempt to discover the address of
    a suitable home agent on its home link (NEW TEXT:) if the length of
    mobile node's home subnet prefix is 64 bits.  To initiate the
    discovery, the ..."

Jari

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Feb 2003 18:41:54 +0200 (EET)

>     mobile node's home subnet prefix is 64 bits.  To initiate the

Excellent wording choices, IMO.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 03 Feb 2003 12:54:19 -0800

I am not comfortable with hard-coding 64 in the MIPv6 spec.
everybody knows it is controversial, people have argued
against it.

>  > noted by draft-savola-ipv6-127-prefixlen-04.  Should there be an explicit

there is a difference between 64 and 127. 
draft-savola-ipv6-127-prefixlen-04.txt states 

>       4. [ADDRARCH] could be revised to state that Subnet-router anycast
>          address should not be used if the prefix length of the link is
>          not /64 (or even longer than /120).  This does not seem like a
>          good approach, as we should avoid making assumptions about
>          prefix lengths in the specifications, to maintain future
>          flexibility.  Also, in some cases, it might be usable to have a
>          Subnet-router anycast address in some networks with a longer
>          prefix length.

this is what you are proposing Jari.

> fails when the prefix length becomes too small...

whatever the prefix length, 2526 tells you how to construct
an anycast address. 2373 talks about the prefix length being 
64. to construct an Home Agent anycast address, isnt it enough 
to reference 2526 and 2373? implementors will look at 2526 and 
2373 when they try to construct a Home Agent anycast address. 
why should MIPv6 say DHAAD should be used only if the prefix 
length is 64? makes no sense, IMHO.

Vijay

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Feb 2003 23:16:22 +0200 (EET)

> everybody knows it is controversial, people have argued

Certainly, but this is IMO just the opposite of the argument.

I would certainly argue against hardcoding 64 bits if it was for core
functionality, such as being able to act as CN, MN, whatever.

> to reference 2526 and 2373? 

Not really, as it may be that some (rather rare) cases are that the prefix
length is _not_ 64.  I wonder if MIPv6 HA would react if it was configured 
with a /124, for example.

> implementors will look at 2526 and 

I would call this a pragmatic approach.  I would be very surprised to see 
MIPv6 being used as a home link when the prefix is not 64.

You could also eliminate disable some security threats this way, e.g. if
you have router-router point to point links with prefix length less than
64, you could just outright discard DHAAD attempts.  Of course, 64 could
be the technical limit (/120 ?) too if one doesn't want to be pragmatic.

My point basically is that DHAAD is not a core function of MIPv6, and the
behaviour is best defined in such a manner we always know it behaves in a
consistant manner.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 03 Feb 2003 13:32:57 -0800

> with a /124, for example.

if subnet router anycast fails for a specific prefix lenth, 
it needs to be fixed it. your draft is very good effort in 
that direction. but it doesnt make sense putting a 
restriction in the MIPv6 spec. we would have to revise MIPv6 
spec if something changes in the future. IMO, MIPv6 should 
always point to the document which specifies how to construct
a subnet router anycast address.

> MIPv6 being used as a home link when the prefix is not 64.

I am not disputing that. I am not against mandating 64 as the
longest prefix length. I am against hard coding it in the MIPv6
spec. ADDRARCH document already does that.

> behaviour is best defined in such a manner we always know it behaves in a

I dont follow the argument. DHAAD would work perfectly for a 
prefix length of 80.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 04 Feb 2003 00:27:30 +0200

What we are discussing -- is just about the way how either
2373, 2526, or MIPv6 is revved when the prefix issue is
fixed?

If so, part of the answer seems to be that RFC editor
generally tracks the most current standard RFCs and when
e.g. 2526 is revved, folks would know about that.

Maybe the only thing we need on top of that is a warning
in the MIPv6 RFC that the current RFCs don't quite get this
right.

Is this approach acceptable to you both? If yes, we need to
craft text for the "warning" so that it doesn't give the
wrong impression.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 03 Feb 2003 14:53:30 -0800

> 2373, 2526, or MIPv6 is revved when the prefix issue is

that too. but in the first place MIPv6 has no business talking
about which prefix lengths are safe and which are not. that
is in IPv6 specs.

> craft text for the "warning" so that it doesn't give the

IMO, we dont have to say anything. setting prefix length to
127 is certainly bad for subnet router anycast mechanism. this
is documented in Pekka's draft. for every other prefix length 
it seems to be safe (atleast to me). let the IPv6 WG decide 
which prefix length is safe for subnet router anycast mechanism
and which isnt.

Vijay

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Feb 2003 08:23:58 +0200 (EET)

> which prefix length is safe for subnet router anycast mechanism

Subnet router anycast address is okay except in 127, but "Mobile IPv6 
Home-Agents anycast" in RFC2526 requires like /120, I think.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 04 Feb 2003 00:14:29 -0800

> Home-Agents anycast" in RFC2526 requires like /120, I think.

nope. from RFC 2526

> 4. Examples
> 
>    To illustrate the construction of reserved subnet anycast addresses,
>    this section details the construction of the reserved Mobile IPv6
>    Home-Agents subnet anycast address [4].  As noted in Section 3, the
>    7-bit anycast identifier for the Mobile IPv6 Home-Agents anycast
>    address is 126 (decimal) or 7E (hexadecimal).
> 
>    For IPv6 addresses containing a format prefix indicating that
>    interface identifiers are required to be 64 bits in length and are
>    required to be in EUI-64 format (currently format prefixes 001
>    through 111, except for 1111 1111 [3]), the reserved Mobile IPv6
>    Home-Agents subnet anycast address consists of the 64-bit subnet
>    prefix followed by the 64-bit interface identifier shown below:
> 
>    |0              1|1              3|3              4|4              6|
>    |0              5|6              1|2              7|8              3|
>    +----------------+----------------+----------------+----------------+
>    |1111110111111111|1111111111111111|1111111111111111|1111111111111110|
>    +----------------+----------------+----------------+----------------+
>           ^                                                     ^^^^^^^
>           +--- universal/local bit        anycast identifier ---+-----+
> 
>    For other IPv6 address types, the interface identifier may be other
>    than 64 bits in length and is not in EUI-64 format.  In this example,
>    assume that the length of the interface identifier is 64 bits, to
>    allow clear comparison with the example given above (although
>    interface identifiers of lengths other than 64 bits follow the same
>    general construction of the interface identifier shown here).  In
>    this case, the reserved Mobile IPv6 Home-Agents subnet anycast
>    address consists of the 64-bit subnet prefix followed by the 64-bit
>    interface identifier shown below:
> 
>    |0              1|1              3|3              4|4              6|
>    |0              5|6              1|2              7|8              3|
>    +----------------+----------------+----------------+----------------+
>    |1111111111111111|1111111111111111|1111111111111111|1111111111111110|
>    +----------------+----------------+----------------+----------------+
>                                                                 ^^^^^^^
>                                           anycast identifier ---+-----+

infact the prefix length is 64 in both examples. am I missing something?

and anyway /120 will work too.

Vijay

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Feb 2003 10:23:04 +0200 (EET)

> infact the prefix length is 64 in both examples. am I missing something?

yes.

What if the prefix part is 125 bits long?  Then replacing the last 7 bits
with the anycast identifier "1111110" will replace last two bits of the
prefix (ouch), result in nothing or a warning (there was a check) or crash
the system?  Robust implementations must have a check in the code anyway..

---

From: Jari Arkko <[email-masked]>
Date: Tue, 04 Feb 2003 11:28:58 +0200

> Home-Agents anycast" in RFC2526 requires like /120, I think.

The set of reserved anycast addresses uses the last byte, so I think
/120 is the safe assumption.

> this is what you are proposing Jari.

You may be right here. OTOH I think Pekka's list of solutions
could be improved. In particular, it doesn't differentiate
between what the users should be doing and what the IPv6
documents should say about the limitations. Even if the
best course of action seems to be Pekka's choice #3, IMHO
some of this should probably be mentioned in some IPv6 RFC,
right?

 > 127 is certainly bad for subnet router anycast mechanism.

I think we established that there are some bad cases, even
if we didn't at the beginning agree on the exact limit...
I think we'll eventually agree that /120 is the right limit.

But lets not argue about the number of bits. The higher
level issues are:

* Overall this is an IPv6 issue, IPv6 WG will have to
   deal with it.
* Still, for the purposes of "truth in advertising"
   it would make sense, imho, that we indicate in our
   document that currently the router anycast address
   doesn't work for all prefix lengths.

I'm withdrawing my earlier proposal for keyword text
on this. Instead, I'd like to add the following note
to 6.5: "Note that the currently defined anycast
addresses may not work with all prefix lengths other
than those defined by in RFC 2373 [2373, draft-savola]".

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 04 Feb 2003 11:02:13 -0800

Pekka Savola wrote:
> the system?  

agreed. since 7E is reserved as MIPv6 HA anycast address, the
prefix length should not be greater than 124.

> Robust implementations must have a check in the code anyway..

exactly. when I implement RFC 2526, I will put the check in my code.

but how does this relate to

"DHAAH should only be performed if the prefix length is 64 bits"
(which is the proposal we are discussing). 

I am against hard coding any prefix lengths in the MIPv6 spec. 

Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 04 Feb 2003 16:02:21 -0500

I agree with Vijay on this.  MIPv6 should not specify this
but instead refer to the appropriate docs (which I think
it already does).

Actually I think this is completely a non-issue.  Since MIPv6
assumes statless autoconfig as a default mechanism,
the 64 bit prefix in implicit requirement (based on 2462).

-vlad

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 04 Feb 2003 14:02:52 -0800

> than those defined by in RFC 2373 [2373, draft-savola]".

this is fine with me.

Vijay

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Feb 2003 08:50:11 +0200 (EET)

> > than those defined by in RFC 2373 [2373, draft-savola]".

Agree.