February 2003 - ipv6-wg - mailman.ripe.net

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 12 Feb '03

12 Feb '03

Robert, >> Michel Py wrote: >> +-----+---------+---------+-------+--------------+ >> | 8 | 16 | 16 | 8 | 16 | >> | | hostid | | index | routernumber | >> +-----+---------+---------+-------+--------------+ >> 02 ca : fe FF : FE 77 : beef > Robert Kiessling wrote: > I'm talking about network address derived from router number > and some local interface index. This is not possible in the > 16 bits available in the assignment. I don't understand; there are 40 bits in the example? (and I could have squeezed 6 more). > cisco3640(config-if)#mac-address ca.fe77.beef > Changing the MAC address to get an easily usable IP address > seems quite perverse to me. Indeed it is, but this was the long way to demonstrate how it is derived. And is besides the point, as we were talking about tunnels and they don't have a MAC address of their own, so you can go ahead and directly configure an EIU-64 or modified-EUI-64 IPv6 address directly as show in the short way. Michel.

2 1

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 12 Feb '03

12 Feb '03

Sam, > Sam Wilson wrote: > It's an odd feature of that RFC that it's published as > Informational rather then Proposed Standard, Which RFC are you referring to? 2373 is in the standards track and so is draft-ietf-ipngwg-addr-arch-v3-11.txt which is going to obsolete 2373 soon. >> [RFC2373] >> Network Working Group R. Hinden >> Request for Comments: 2373 Nokia >> Obsoletes: 1884 S. Deering >> Category: Standards Track Cisco Systems > and the only reference to the RFC 2119 terms "MUST", "MUST NOT" etc. > is in the Introduction. It specifically does not say: > "Interface IDs are REQUIRED to be 64 bits long and to be > constructed in IEEE EUI-64 format [EUI64]." > Perhaps someone who is further into the the IETF process can say > whether this was an oversight or if the latitude was intended. I can't speak for the authors in terms of intent, but the fact of the matter is that if it said "REQUIRED" there would be no compliant implementation today, which would forbid the standards track. This very point has actually been appealed recently, so regardless of the intent the latitude is necessary as of today. This an egg-and-chicken problem: there are a lot of legacy tunnels that use /127, and software developers don't want to enforce the /64 boundary because it would force legacy networks to renumber, which can't happen overnight so the likely result is that almost no one would use the updated software which is no good for a protocol under development such as IPv6. This is largely a user education problem, because the old reflexes of using a /30 or a /31 that are justified in v4 are not required anymore for v6. Michel.

1 0

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 12 Feb '03

12 Feb '03

> Do the ops types include people like me who worry that every > time a NIC has to be replaced it's going to require changes > to DNS, ACLs and anything else that's keyed on IP address? Mmm, I don't know. I'm the kind of ops type that also reads RFCs and understand the importance of respecting standards. From an operational standpoint, it pays off in the long run. I would never configure a server or router with an IPv6 address that includes some part of the BIA, but I try to respect standards too, and even the current standard could be respected although its clumsiness definitely makes modified EUI-64 desirable. Michel.

1 0

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 12 Feb '03

12 Feb '03

Robert, > There are a number of advantages of non-/64 for p2p. For example, > you can have an easy address allocation scheme like ...: > <routernumber>:<index>:<host id>" which does not require any > bookkeeping. That's not possible with /64 addresses. You are completely mistaken. Using your own example: Hostid = 0xcafe Index = 0x77 Routernumber = 0xbeef I'll even go over an EUI-64/RFC2373 example although it's going to be obsolete real soon. +-----+---------+---------+-------+--------------+ | 8 | 16 | 16 | 8 | 16 | | | hostid | | index | routernumber | +-----+---------+---------+-------+--------------+ 02 ca : fe FF : FE 77 : beef The long way: ------------- cisco3640#conf t cisco3640(config)#inte e0/0 cisco3640(config-if)#mac-address ca.fe77.beef cisco3640(config-if)#ipv6 address 2001:db8::/64 eui-64 cisco3640(config-if)#end cisco3640#sh ipv6 inte e0/0 Global unicast address(es): 2001:DB8::2CA:FEFF:FE77:BEEF, subnet is 2001:DB8::/64 ^^ ^^ ^^ ^^^^ \\|| || |||| CAFE 77 BEEF The short way: cisco3640#conf t cisco3640(config)#inte e0/0 cisco3640(config-if)#ipv6 address 2001:db8::02CA:FEff:fe77:BEEF/64 This is compliant with EUI-64 and RFC 2373. As I said before, we're talking about straight EUI-64 here and this is soon to be obsoleted. The replacement for RFC2373 (draft-ietf-ipngwg-addr-arch-v3-11.txt) uses _modified_ EUI-64, and you can do almost whatever you want, such as: ipv6 address 2001:db8::02CA:FE00:0077:BEEF/64 ipv6 address 2001:db8::02:CAFE:77:BEEF/64 ipv6 address 2001:db8::1/64 All of which are compliant modified EUI-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. There is no relation. You can construct an EUI-64 or a modified EUI-64 address without using the BIA, what's your problem here? Michel.

2 1

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 12 Feb '03

12 Feb '03

> Jeroen Massar > Thus 2001:db8::1 is a 'modified' EUI-64 and thus can be > assigned. You are just lying a bit that the local scope > id is not available and thus you are making it up, but > you do correctly set it as per RFC. Easy to fix, make it 2001:db8:2::1 Michel.

1 0

[ipv6-wg@ripe.net] urls with ipv6 ip.
by Priyaupnp＠netscape.net 06 Feb '03

06 Feb '03

hi all, I couldn't load a loacal page from my linux system with IPv6 link local IP,(The browser used was netscape7). When the site local ip is added to the system, could load the page using that ip. Is it possible to load a page with link local ip using netscape or any other browser. Thanks in advance. Regards Pria __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

3 2

[ipv6-wg@ripe.net] ANNOUNCEMENT: IPv6 support for RIPE NCC TTM Service
by Henk Uijterwaal (RIPE-NCC) 03 Feb '03

03 Feb '03

Dear All, (Apologies for any duplicate mails). The RIPE NCC is pleased to announce full IPv6 support for its test-boxes and Test Traffic Measurement Service (TTM). This new version can do all the measurements that the previous version could do on IPv4 networks, but now on IPv6. Measurements can be done on IPv4 and IPv6 networks in parallel. Most of the porting work has been done by Florian Frotzler, an CS student doing an Internship at the RIPE NCC. It is described in more detail in an internal report available at: http://www.ripe.net/ttm/Documents/Various/florian_xmas.pdf as well as in the slides of his presentation at RIPE44 last week: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-tt-i… IPv6 support will be included on all test-boxes ordered after 1/2/2003. To order a test-box, please go to: http://www.ripe.net/ttm/Host_testbox/host_testbox.html If you are already hosting a test-box and want to upgrade to the IPv6 enabled version, then please find instructions for upgrading at the bottom of this mail. If anything is unclear, please contact us at ttm(a)ripe.net. More about the TTM service can be found at: http://www.ripe.net/ttm Kind regards, Henk Uijterwaal Instructions for upgrading test-boxes ===================================== If you already own a test-box and want to upgrade to the IPv6-capable version of the software, then this is the procedure: 1. Determine the version of your test-box. This can be series A, B, C or D. Series D boxes are 1u high and manufactured by Dell. Series C boxes are all boxes delivered after 1/1/2001. A or B are boxes delivered before 1/1/2001. 2. Your box is series A or B: 1. In this case, a hardware upgrade to a series D box will be necessary. The (usually 3-5 years) old hardware does not support v6. 2. Series D boxes cost 2,500 euro, however, if you return your old box, you will get a 500 euro discount. 3. Send an email with a v6 address to tt-ops(a)ripe.net 4. A new box will be configured and shipped. 5. Schedule a time to unplug the old box and plug in the new box with our operators. 3. Your box is series C or D: 1. Send an IPv6 address to tt-ops(a)ripe.net 2. Our operators will schedule a time for the upgrade 3. You will have to download a boot floppy from our ftp site. 4. At the time of the upgrade, boot with the floppy. Note that we will only do this upgrade if all outstanding invoices have been paid and the service contract for the existing box has been signed. ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC)

1 0