Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4

From: Alexandru Petrescu <[email-masked]>
Date: 29 Jan 2002 22:04:15 +0100

"Hesham Soliman (ERA)" <[email-masked]> writes:
> or by core network routing according to keys (in addresses).
> 
> => Routing in the core network is never done
> on the interface id anyway.

Thanks Hesham for bringing this up.

I'm wondering if the 64bit boundary for Interface ID is fixed.  It
seems to me that 000-prefixed addresses are about to be reserved
exactly in order to allow prefix lengths longer than 64
(draft-ietf-ipngwg-addr-arch).  I might be wrong, though.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jan 2002 11:35:08 +0100 (CET)

> (draft-ietf-ipngwg-addr-arch).  I might be wrong, though.

I think practical use of address in 0::/8 (such as the ipv4-mapped, 
ipv4-compatible, ipv4-translatable, loopback, unspecified)
are not likely to cause routes to be advertised in the network for longer
than a /96 (and that would be for the ipv4-mapped prefix when using a SIIT
translator).

So implementors *could* get away with /64 in many places - but DOOOOONT!!!
While today /64 is used to do stateless address autoconfiguration
it would be short-sighted to assume that this will always be the case.
Twenty or fourty years from now we might need something different.

Thus IMHO a prudent implementation would limit the places where the
/64 boundary is known to a minimum.
The best would be to only have this be known by the device driver for
IP-over-foo. For instance, an Ethernet device driver would need to
know that it should create a 64 bit Interface ID from the MAC address.
Then it could pass this up to whatever entity implements RFC 2462 but
that entity only needs to verify that the prefixes advertised by the routers
plus the interface ID makes a total of 128 bits.

  Erik