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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 29 Jan 2002 16:48:21 +0100

Alex

I don't know if this was already answered...so
I'll answer it anyway

  > Reversing your statement, I truly support the future 
  > attacks argument
  > in that, as an implementor of MN, I don't want CN's services to our
  > MN's be denied.  But also as an implementor of MN's I can say that
  > everything is possible; only when crypto comes in it gets rather
  > complex.  I'm a bit doubtful of public key operations every time MN
  > moves 

=> But that does not need to be the case. A BSA can be
established.

or by core network routing according to keys (in addresses).

=> Routing in the core network is never done
on the interface id anyway. 

Cheers,
Hesham

---

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

> 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

---

From: Alexandru Petrescu <[email-masked]>
Date: 30 Jan 2002 12:13:59 +0100

> than a /96 (and that would be for the ipv4-mapped prefix when using a SIIT

Sure.  Except of course for smaller domains and "less core" routers.
But this was only a side effect of my argument.  I was mainly trying
to say that, that CGA's assume 64bit and other types of addresses
potentially have other interface id lengths.  This may turn into
CGA-with-Ethernet, or CGA-with-LocalTalk, CGA-with-IPv4compatible.
CGA's probably have a minimum length of Interface ID for which it
keeps its crypto properties, assuming a population of 2^128.

> plus the interface ID makes a total of 128 bits.

Thanks for this advice, I didn't think about the last check.

Alex

---

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

> keeps its crypto properties, assuming a population of 2^128.

Ah - got it.
I've heard statements that less than about 60-64 bits probably doesn't make
sense.

So CGA with ipv4-compatible doesn't make sense for this reason.
And it also doesn't make sense since in that case the bottom 32 bits
of the address is an IPv4 address assigned e.g. using DHCP with no knowledge
of IPv6 or CGA.

   Erik