Re: IPv6 adoption
Jason Gunthorpe wrote:
> I'm just trying to say that a 128 bit address space is isn't really too
> large, but probably about the right size.
Oh, ok. I agree. :-)
> > Anyway, having aggregatable addresses is simply a matter of
> > assigning addresses so that they are tied to network topology.
> > The routing information doesn't actually eat up any "extra bits"
> > in the addresses.
>
> Well, it does make the address larger than it technically needs to be.
> With 64 bits you can represent enough devices (indeed, IPv6 already
> assumes this, since that is the interface ID length). But adding another
> 64 bits makes it alot easier and faster to route - which is the point :>
By "it" I guess you actually mean the interface id. That's the on-link
address and doesn't actually have anything to do with routing. It's only
ever used when the destination is on the same link. I was talking about
the network prefix, which contains the routing information.
Yes, a fixed length interface id does make routing simpler. You know
that
the network prefix is exactly 64 bits instead of something variable with
a host identifier glued to the end (like in IPv4). That makes it easier
to route and gives more room for aggregation ids.
One of the ideas behind this is that you can have fixed boundaries
between
TLA and NLAs. If every network provider on the same level in the routing
hierarchy gives you a prefix of the same length, it is a simple matter
to
switch providers.
And yes, it does make the address technically larger than it would have
to be. I think the message is that router performance and flexibility
are
considered to be much more crucial than the transmission delay caused by
a few extra bytes in the address.
> This thread did start because people were complaining that 128 bit
> addresess were unecessiarily large.
I see. The first thing I saw was arguing that 128 bits was too little.
:)
> > Can't do that. There's no guarantee that the interface id has been
> > constructed from an Ethernet address and even if it has, the
> > destination might be proxied. The router has to do ND as usual.
>
> I was under the impression that link layer resolution ND messages were
> only for use in unusual cases, not for general use on ethernet?
Nope, you normally have to use ND to resolve on-link addresses on all
multiple access links. Point-to-point links are an exception.
Using the Ethernet MAC as basis for the interface id is simply an
administrative convenience (makes it easier to debug the network).
Technically, you could in many cases optimise away ND for EUI64's
that are based on Ethernet addresses in the way you suggest, but
you're not supposed to do that.
> It seems to me that if you do use ND for each IP then you will end up with
> rather low IP utilization - of the 2^64 addresses that are delivered to a
> router, maybe about 10000 would fit in the neighbour cache of a router?
You're correct. It's not likely that you would have 2^64 hosts on
a single link (or even close). There are practical limits to how
many hosts you can connect to a single Ethernet segment, for instance.
As I said before, currently this only applies to 1/8 of the total IPv6
address space. There are 6 more blocks like this in reserve, for which
an addressing format has not been defined. If having a 64 bit interface
id turns out to be a bad idea, the new blocks could be defined
differently.
> I don't see the problem with proxies, if they are able to do the
> equivilant of 'proxy arp' then they can just as easially listen for
> multiple MACs (like a switch).
Well, they could, but not all NICs support that (and you don't really
want a proxy ND gateway to run its interfaces in promiscuous mode).
Therefore, proxy ND works pretty much like proxy ARP: a proxy will be
listening for multiple IPv6 addresses behind a single MAC address.
> Jason
MikaL
Reply to: