RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
Andrius Kasparavicius wrote: And at the end, would I be bad if I will use /127 for point-to-point(tunnels).
VERY bad. Not only there are known issues with doing this, but it violates both RFC2373 and its replacement draft-ietf-ipngwg-addr-arch-v3-11.txt. Not respecting IETF _standards_ is not a good idea in any case and at some point people that think they are gods and can have their own standard will have to renumber their entire network. Michel.
"Michel Py" <michel@arneill-py.sacramento.ca.us> writes:
Andrius Kasparavicius wrote: And at the end, would I be bad if I will use /127 for point-to-point(tunnels).
VERY bad. Not only there are known issues with doing this, but it violates both RFC2373 and its replacement draft-ietf-ipngwg-addr-arch-v3-11.txt. Not respecting IETF _standards_ is not a good idea in any case and at some point people that think they are gods and can have their own standard will have to renumber their entire network.
As you say, the issues are known, and as such we know that they don't affect us. There are a number of advantages of non-/64 for p2p. For example, you can have an easy address allocation scheme like ...:<router number>:<index>:<host id>" which does not require any bookkeeping. That's not possible with /64 addresses. The standard also requires EUI-64 addresses which is clearly not desirable for a number of application. For example, it would be very silly to require a change all your peering sessions just because you change your NIC. So it is obvious that the requirement for EUI-64 cannot be taken too seriously, and consequently the requirement for a /64 seems not convincing either. Robert
In your previous mail you wrote: There are a number of advantages of non-/64 for p2p. For example, you can have an easy address allocation scheme like ...:<router number>:<index>:<host id>" which does not require any bookkeeping. That's not possible with /64 addresses. => I strongly disagree. IMHO your claim is based on the false assumption that EUI-64 is mandatory. The standard also requires EUI-64 addresses which is clearly not => NO, EUI-64 is not mandatory. Only the modified EUI-64 *format* is mandatory: you can put what you want in 63 bits if one bit is set to zero. desirable for a number of application. For example, it would be very silly to require a change all your peering sessions just because you change your NIC. => I agree but as EUI-64 is not mandatory I have no problem too... So it is obvious that the requirement for EUI-64 cannot be taken too seriously, and consequently the requirement for a /64 seems not convincing either. => of course it cannot be taken too seriously because it doesn't exist (:-). But the requirement for a /64 is a real one. Regards Francis.Dupont@enst-bretagne.fr
Hi, On Thu, Feb 13, 2003 at 04:34:38PM +0100, Francis Dupont wrote:
In your previous mail you wrote:
There are a number of advantages of non-/64 for p2p. For example, you can have an easy address allocation scheme like ...:<router number>:<index>:<host id>" which does not require any bookkeeping. That's not possible with /64 addresses.
=> I strongly disagree. IMHO your claim is based on the false assumption that EUI-64 is mandatory.
The standard also requires EUI-64 addresses which is clearly not
=> NO, EUI-64 is not mandatory. Only the modified EUI-64 *format* is mandatory: you can put what you want in 63 bits if one bit is set to zero.
The boundary between "network part" and "host part" needs to be shifted to the right - people are not trying to invent fancy schemes to generate *host* parts, they want to do structured numbering for the *network* part. If you use /64s, the structure has to go in the bits to the left of that, which is obviously undesireable. (I agree with Daniel Karrenberg, btw, that trying to squeeze too much structure into 60 bits will come back and bite me. Yes. But that's something that should be up to the implementor to decide...) [..]
desirable for a number of application. For example, it would be very silly to require a change all your peering sessions just because you change your NIC.
=> I agree but as EUI-64 is not mandatory I have no problem too...
We're not talking about use of EUI-64 or not. We're talking about bringing structure into the *network* part of the address. The host part is extremely simple: "1", or "2" -> 4 bits is plenty. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56029 (55671) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
participants (4)
-
Francis Dupont -
Gert Doering -
Michel Py -
Robert Kiessling