Dear colleagues, After looking at the material presented in RFC 2374 and the discussions in the working group at the 38th RIPE meeting I am left with a few questions. My understanding of IPv6 is that it is supposed to solve some of the problems that we have with IPv4. These include: - Running out of IPv4 address space - Difficulties of Route aggregation - Renumbering And a new problem addressed at the last RIPE meeting - Running out of AS Numbers (prediction mid 2005) (It will become obvious later why I mention this here) With the current proposal, I do not see that any of these problems will be adequately (or if at all) addressed. The most obvious problem is that the 13 bits of sTLA space that is being given to providers today is TOO small. One way of increasing this would be to implement CIDR in IPv6, and not to include EUI-64 interface addresses in the IP header. Is arp really that bad that we have to throw it away? There is no medium that I know of that can support 2^64 addresses in the one segment, and I see no advantage of shipping this information across the Internet. Mutlihoming and Renumbering are still very much up in the air. Aggregation (including the GSE (8+8) draft) all seem to base their design on the Internet Registries (RIPE, etc ) or 'Tier 1' providers having the most significant bits (leftmost) in an IP address. The problem I see with this approach is that - It is not usual for an ISP to 'Peer' with a routing registry, and therefore not really getting a great gain from route aggregation - How do you determine which Tier a provider belongs to, and should he change size, moving or down a Tier is almost impossible due to renumbering difficulties. A suggestion that I would like to throw into the ring would be to include the AS Number into the start of the IP Header, and maybe a bits after that, to help control entry/exit points into boarding networks (a type of tag). | 3| 21 | 8 | 24 | 8 | 64 bits | +--+-----+---+--------+--------+--------------------------------+ |FP| AS |TAG| NLA | SLA | Interface ID | | | NUM | | ID | ID | | +--+-----+---+--------+--------+--------------------------------+ or | 3| 21 | 8 | 32 | 64 bits | +--+-----+---+-----------------+--------------------------------+ |FP| AS |TAG| NLA | Customers address | | | NUM | | ID | Range (CIDR) | +--+-----+---+-----------------+--------------------------------+ depending whether one wanted to get rid of arp. This way the border routers would only require the path information on how to get from one AS to the other, without requiring detailed information on the prefixes. Dual homing would be solved by issuing those customers with their own AS number, as is the practice today. It is obvious however that the number of bits in an AS Number would have to be increased, but this is the case anyway. To ease renumbering it might make sense to issue the numbers out of a smaller range (96 bit for example). The customers edge routers would then add the current ISPs AS Number to the packet before forwading them out. This way, the only change required when chaing ISPs is on the boarder routers. The field lengths/ names above are just an example, and would have to be closely examined. I would be interested in hearing any opinions, Regards Andrew -- Andrew Miehs Cybernet AG email: amiehs@cybernet-ag.net phone: +49 89 993 15-0 fax : +49 89 993 15-199
On Sun, Jan 28, 2001 at 02:22:46AM +0100, Andrew Miehs wrote: Hi Andrew, This is an interesting proposal. However I think the big problem is that if you do not have EUI-64 then you throw out address auto-configuration, which is a big win in too many situations to really just throw away. (Arp still exists in a way; it's sort of in neighbor discovery.) Also, a fixed boundary really helps when you are building routing software - it makes it simpler, cheaper and faster. Well, it *will* make it so :-)
- Running out of AS Numbers (prediction mid 2005) (It will become obvious later why I mention this here)
With the current proposal, I do not see that any of these problems will be adequately (or if at all) addressed.
This is certainly a more serious problem than it might at first appear, as several members of the community have said to me. The problem is not really the difficulty of preparing a new standard, or extending the existing in some way (although it's clear that there should *not* be a BGP 5 which extends AS space one month, and a BGP 6 which does v6 the next, for all the usual management reasons) -- the problem is that BGP-speaking core routers only get upgraded very rarely, and if we want to have a standard ready in time *we have to start now*. In fact it would be really great if we finished tomorrow :-)
The most obvious problem is that the 13 bits of sTLA space that is being given to providers today is TOO small.
There is a document being prepared on this (and other sTLA issues) as we speak.
There is no medium that I know of that can support 2^64 addresses in the one segment, and I see no advantage of shipping this information across the Internet.
Well, 64 bits is very handy because it nicely encapsulates ethernet and leaves room for future growth. Remember - the 3G people are coming, and they might use the phone number in the interface token, or might not, but it's useful to have more room anyway.
Mutlihoming and Renumbering are still very much up in the air.
You said it. That's definitely one of the things everyone would be much happier if it were sorted out as soon as possible. A good sign is that (apparently) an explicit IETF working group has been created for it. Your guess is as good as mine as to whether the standards process will produce a result quickly enough before 2005. (Of course you could always run this proposal past them as well.)
I would be interested in hearing any opinions,
I will have to look at this more closely (after IPv6 forum has closed...) Niall -- Enigma Consulting Limited 45 Dawson Street, Dublin 2, Ireland.
participants (2)
-
Andrew Miehs -
Niall Richard Murphy