- ipv6-wg - mailman.ripe.net

Re: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy
by CJ Wittbrodt 06 Feb '02

06 Feb '02

Thomas, Comments are below: From: Thomas Narten <narten(a)us.ibm.com> Subject: Re: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment >>Global Policy I wasn't at the RIPE meeting, but I do have at least one big concern based on what I heard. > To be precise, I proposed the following: > - any LIR that is established (has done all the paperwork, paid their > fees, and whatnot) and can document the need for one IPv6 address > can get a /32. No further justification required. Does this mean end sites, those that are not transit providers become eligible for a /32? In other words, what is to prevent a land grab on what will largely be perceived as PI IPv6 address blocks? (I heard from someone who was at the meeting that the answer was a clear yes, end sites will be eligible.) I think we would be sending entirely the wrong message if end sites are able to get /32s. I was at the RIPE meeting. The consensus was that anyone willing to become an LIR and pay the fees could get a /32. Certainly within RIPE there are requirements for becoming an LIR, but I don't believe those requirements distinguish between being and end site or whatever. We certainly discussed this at the meeting. There is nothing to prevent an end user from becoming an LIR and getting a /32. Note also that my main concern has much less to do with utilization or how much address space we have (we do have a lot). It has much more to do with having registry policies that are supportive of aggregation of routing information in the long term. This will only happen if most end sites get address space from their providers. Allowing end sites to get big allocations now, will cause nothing but problems later. It risks replaying some of the bad history of IPv4. That's right. > - to avoid a horrible mistake, every region is permitted to allow only > assigment of 2000 /32s per region. So the maximum wastage is 6000 > /32s (out of 500 million /32s in the 1/8th of the space we're talking > about), and 6000 additional routes. > After that, we're going to reconsider policy. And once we have 6000 such /32s allocated, then what? We replay the haves vs. the have nots? Won't there be a lot of pressure then to continue giving out /32s freely, since current router technology supports more than 6K routes, etc.? What makes you think we'll be able to put in more conservative policies at this point? This is definitely an issue. One that folks at the meeting didn't want to hear > - why are we putting criteria there? To keep out "some that we do not > want". Conservation is not an issue. Routing table growth might > be influenced by this, or might be not, we don't know. Having RIR policies that make it harder to have good aggregatability of routes should not be done rashly. It is far easier to take steps now that limit potential problems, than try to reverse poor decisions after the fact. Yup. > - do we want major national research networks connecting something like > "50 universities"? YES So, can we come up with alternate criteria that support giving /32s to such entities that doesn't also allow just anyone to get a /32? This desire seems reasonable to me. But the proposed solution seems to gone way beyond what was needed, and has some real down sides. That was attempted to be proposed. I'd like to see this group come up with something more than just pay the fee and get a block. A portable no aggregatable block. Further, the way blocks are being handed out now they aren't geographically aggregatable either. So each registry just peels off the next block. There aren't blocks per registry. > Who are the ones that we want to keep out anyway? Why? To achieve what? End sites. If every end site gets its own /32, we will have another routing disaster. So much for IPv6 learning from the IPv4 experience. Well the argument is that they'll never come back for more. This means (believe me this isn't my argument) that the routing table should be smaller because everyone will only have one prefix. There are only as many multi-homed sites as there are ASNs, right? Anyway, this is an argument that I have heard proposed. Please remember it isn't my argument. ----CJ

1 0

Re: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy
by Thomas Narten 06 Feb '02

06 Feb '02

I wasn't at the RIPE meeting, but I do have at least one big concern based on what I heard. > To be precise, I proposed the following: > - any LIR that is established (has done all the paperwork, paid their > fees, and whatnot) and can document the need for one IPv6 address > can get a /32. No further justification required. Does this mean end sites, those that are not transit providers become eligible for a /32? In other words, what is to prevent a land grab on what will largely be perceived as PI IPv6 address blocks? (I heard from someone who was at the meeting that the answer was a clear yes, end sites will be eligible.) I think we would be sending entirely the wrong message if end sites are able to get /32s. Note also that my main concern has much less to do with utilization or how much address space we have (we do have a lot). It has much more to do with having registry policies that are supportive of aggregation of routing information in the long term. This will only happen if most end sites get address space from their providers. Allowing end sites to get big allocations now, will cause nothing but problems later. It risks replaying some of the bad history of IPv4. > - to avoid a horrible mistake, every region is permitted to allow only > assigment of 2000 /32s per region. So the maximum wastage is 6000 > /32s (out of 500 million /32s in the 1/8th of the space we're talking > about), and 6000 additional routes. > After that, we're going to reconsider policy. And once we have 6000 such /32s allocated, then what? We replay the haves vs. the have nots? Won't there be a lot of pressure then to continue giving out /32s freely, since current router technology supports more than 6K routes, etc.? What makes you think we'll be able to put in more conservative policies at this point? > - why are we putting criteria there? To keep out "some that we do not > want". Conservation is not an issue. Routing table growth might > be influenced by this, or might be not, we don't know. Having RIR policies that make it harder to have good aggregatability of routes should not be done rashly. It is far easier to take steps now that limit potential problems, than try to reverse poor decisions after the fact. > - do we want major national research networks connecting something like > "50 universities"? YES So, can we come up with alternate criteria that support giving /32s to such entities that doesn't also allow just anyone to get a /32? This desire seems reasonable to me. But the proposed solution seems to gone way beyond what was needed, and has some real down sides. > Who are the ones that we want to keep out anyway? Why? To achieve what? End sites. If every end site gets its own /32, we will have another routing disaster. So much for IPv6 learning from the IPv4 experience. Thomas

1 0

BOUNCE global-v6@lists.apnic.net: Non-member submission from [David Kessens <david@iprg.nokia.com>] Admin request of type /\bsubscribe\b/i at line 9
by owner-global-v6＠lists.apnic.net 06 Feb '02

06 Feb '02

Return-Path: <anne(a)apnic.net> Received: from cumin.apnic.net (cumin.apnic.net [202.12.29.59]) by data.staff.apnic.net (8.10.1/8.10.1) with ESMTP id g16J3PX13501 for <global-v6(a)lists.apnic.net>; Thu, 7 Feb 2002 05:03:25 +1000 (EST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by cumin.apnic.net (8.12.1/8.12.1) with ESMTP id g16J0XKa030195 for <global-v6(a)lists.apnic.net>; Thu, 7 Feb 2002 05:00:34 +1000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA00250; Wed, 6 Feb 2002 11:05:37 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g16J5ae26718; Wed, 6 Feb 2002 11:05:36 -0800 X-mProtect: Wed, 6 Feb 2002 11:05:36 -0800 Nokia Silicon Valley Messaging Protection Received: from david.iprg.nokia.com (4.22.78.79, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6B5WaC; Wed, 06 Feb 2002 11:05:34 PST Received: (from david@localhost) by iprg.nokia.com (8.11.2/8.11.2) id g16J7d327077; Wed, 6 Feb 2002 11:07:39 -0800 Date: Wed, 6 Feb 2002 11:07:39 -0800 From: David Kessens <david(a)iprg.nokia.com> To: global-v6(a)lists.apnic.net, ipv6-wg(a)ripe.net Subject: crossposting to multiple lists Message-ID: <20020206110738.D26988(a)iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) Just a short request: It would be appreciated if global ipv6 policies are being discussed on the global policy list only. Please don't CC the RIPE ipv6 working group maillist. A reminder to the people on the RIPE ipv6 wg maillist: if you want to take part in the global policy discussions, please subscribe to the global policy maillist (global-v6-request(a)lists.apnic.net) if you haven't done so already. Thanks :-), David K. ---

1 0

RE: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy
by Gordon.Lennox＠cec.eu.int 06 Feb '02

06 Feb '02

My apologies. I sometimes I think I need a sig-block!<g> I was at the meeting too, on the Friday afternoon. I am a frequent attendee at RIPE and I have participated in several meetings of the "informal group", or to give it perhaps its full title "Internet: informal working group", here in Brussels. I was just trying to clear up a possible misunderstanding, to avoid a lot of people looking for the "European Government Advisory Council". You would be surprised how often people call here asking strange questions!<g> Kind regards, Gordon Lennox Internet-related Services Directorate: Communications Services - Policy and Regulatory Framework Directorate-General: Information Society European Commission -----Original Message----- From: packetgrrl(a)palm.com [mailto:packetgrrl@palm.com] Sent: 06 February 2002 18:37 To: LENNOX Gordon (INFSO); cjw(a)groovy.com; gert(a)Space.Net Cc: narten(a)us.ibm.com; stuart.prevost(a)btinternet.com; global-v6(a)lists.apnic.net; ipv6-wg(a)ripe.net Subject: RE: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy Gordon Call it whatever you want. I was at a meeting with them. The ASO address council (I am a member) met with them. I was just referring to the group as the other folks did. Anyway based on the mtg I was at, it is very clear they are expecting global policy -- CJ --- This email was sent from my Palm(TM) i705 handheld (www.palm.com)

1 0

RE: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy
by packetgrrl＠palm.com 06 Feb '02

06 Feb '02

Gordon Call it whatever you want. I was at a meeting with them. The ASO address council (I am a member) met with them. I was just referring to the group as the other folks did. Anyway based on the mtg I was at, it is very clear they are expecting global policy -- CJ --- This email was sent from my Palm(TM) i705 handheld (www.palm.com) Gordon.Lennox(a)cec.eu.int wrote: __________ >"European Government Advisory Council"? I don't think that such a thing >exists. > >There was a meeting with the so-called "informal group" - a group of EU >Member State officials with an interest in Internet matters - on the Friday >of the RIPE meeting. They then met with a number of people from RIPE NCC, >ICANN, ARIN, APNIC, IETF, etc.. on the Friday afternoon. > >The confusion may come from the fact that some of the participants in the >"informal gropup" also participate in the GAC, the ICANN Government Advisory >Committee (see http://www.icann.org/committees/gac/) > >Gordon Lennox > >-----Original Message----- >From: CJ Wittbrodt [mailto:cjw@groovy.com] >Sent: 05 February 2002 23:55 >To: Gert Doering >Cc: Thomas Narten; Stuart Prevost; global-v6(a)lists.apnic.net; >ipv6-wg(a)ripe.net >Subject: Re: [GLOBAL-V6] New draft available: IPv6 Address Allocation >and Assignment Global Policy > > > >Since the events of the recent RIPE working group meeting have not >been discussed at either of the other regional policy forums, >proposing something here may be somewhat premature. I do not believe, >although things never cease to amaze me, that this will reach any sort >of consensus within the ARIN region. I am not sure about the APNIC >region. Based on some meetings with the European Government >Advisory Council (just after the RIPE meeting) it is clear that it is >important that we have a global policy. Is there maybe some way >that we could come up with a compromise that would reach consensus >in all three policy forums? Something other than requiring no >justification for a /32? > >Thanks >---CJ Wittbrodt > >/snip..... >

1 0

RE: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy
by Gordon.Lennox＠cec.eu.int 06 Feb '02

06 Feb '02

"European Government Advisory Council"? I don't think that such a thing exists. There was a meeting with the so-called "informal group" - a group of EU Member State officials with an interest in Internet matters - on the Friday of the RIPE meeting. They then met with a number of people from RIPE NCC, ICANN, ARIN, APNIC, IETF, etc.. on the Friday afternoon. The confusion may come from the fact that some of the participants in the "informal gropup" also participate in the GAC, the ICANN Government Advisory Committee (see http://www.icann.org/committees/gac/) Gordon Lennox -----Original Message----- From: CJ Wittbrodt [mailto:cjw@groovy.com] Sent: 05 February 2002 23:55 To: Gert Doering Cc: Thomas Narten; Stuart Prevost; global-v6(a)lists.apnic.net; ipv6-wg(a)ripe.net Subject: Re: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy Since the events of the recent RIPE working group meeting have not been discussed at either of the other regional policy forums, proposing something here may be somewhat premature. I do not believe, although things never cease to amaze me, that this will reach any sort of consensus within the ARIN region. I am not sure about the APNIC region. Based on some meetings with the European Government Advisory Council (just after the RIPE meeting) it is clear that it is important that we have a global policy. Is there maybe some way that we could come up with a compromise that would reach consensus in all three policy forums? Something other than requiring no justification for a /32? Thanks ---CJ Wittbrodt /snip.....

1 0

Re: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy
by Gert Doering 05 Feb '02

05 Feb '02

Hi, from your comments, I gather you have not been to the RIPE IPv6/LIR policy meeting. So let's add a few comments (while waiting for James Aldridge to publish the "official" word on it): On Fri, Feb 01, 2002 at 02:50:38PM -0500, Thomas Narten wrote: > > 5.2.1. Initial allocation criteria [..] > The goal was to give a site a /32 if it can justify it will use > it. The word "immediately" (as in demonstrate an immediate need) is [..] > So the real issue here (and this comes up again in later parts of the > document) is what is a reasonable way to objectively evaluate a > request for address space that requires some guessing as to whether a > proposed plan will actually be carried out. If the time frame is too > long, it becomes easy to make optimistic plans that won't pan out, and > then the RIRs get into a different problem. Consensus on the IPv6/LIR policy meeting was "drop the criteria". To be precise, I proposed the following: - any LIR that is established (has done all the paperwork, paid their fees, and whatnot) and can document the need for one IPv6 address can get a /32. No further justification required. - to avoid a horrible mistake, every region is permitted to allow only assigment of 2000 /32s per region. So the maximum wastage is 6000 /32s (out of 500 million /32s in the 1/8th of the space we're talking about), and 6000 additional routes. After that, we're going to reconsider policy. There was concern from the other regional registries (ARIN and APNIC), but broad consensus from the people from the RIPE region. Reasoning (shortened): - why are we putting criteria there? To keep out "some that we do not want". Conservation is not an issue. Routing table growth might be influenced by this, or might be not, we don't know. - do we want major national research networks connecting something like "50 universities"? YES - will this research network meet any criteria based on "you must use up a big number of /48s, otherwise you can't get a /32"? NO, if you assign a /48 per university (which would be plenty!), because that means "you can only demonstrate a need for 50 /48s" On the other hand, if you say "I connect lots of private customers over DSL lines, using fixed IP addresses, giving each user a /48 (which is OK according to IETF guidelines)", reaching over 50 /48s is very easy. Does this mean the second example is "more worthy" to get a /32? Does it mean they will make "better use" of it? So all technical criteria based on /48 usage must fail, and criteria based on single IP usage will fail as well (due to the /48 rule). If we can't propose criteria that work, drop them - BUT limit the amount of damage that can be done. [..] > Or is it the 776 end site figure (i.e., too high)? Think of the research networks. One /48 per university would be "according to the /48 rule: each SITE gets a /48". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71770 (72395) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

1 0

WG: I-D ACTION:draft-ietf-ipv6-3gpp-recommend-00.txt
by Thomas Trede 23 Jan '02

23 Jan '02

FYI. Regards, Thomas Trede -----Ursprï¿½ngliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Internet-Drafts(a)ietf.org Gesendet: Mittwoch, 23. Januar 2002 15:24 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-ietf-ipv6-3gpp-recommend-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Recommendations for IPv6 in 3GPP Standards Author(s) : M. Wasserman Filename : draft-ietf-ipv6-3gpp-recommend-00.txt Pages : 22 Date : 22-Jan-02 This document contains recommendations from the Internet Engineering Task Force (IETF) IPv6 Working Group to the Third Generation Partnership Project (3GPP) community regarding the use of IPv6 in the 3GPP standards. The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-3gpp-recommend-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-3gpp-recommend-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-3gpp-recommend-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-3gpp-recommend-00.txt

1 0

WG: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-04.txt
by Thomas Trede 18 Jan '02

18 Jan '02

FYI. Regards, Thomas Trede -----Ursprï¿½ngliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Internet-Drafts(a)ietf.org Gesendet: Mittwoch, 16. Januar 2002 13:02 An: IETF-Announce: Cc: ipng(a)sunroof.eng.sun.com Betreff: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei Filename : draft-ietf-ipngwg-rfc2292bis-04.txt Pages : 79 Date : 15-Jan-02 A separate specification [RFC-2553] contain changes to the sockets API to support IP version 6. Those changes are for TCP and UDP-based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-rfc2292bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-04.txt

1 0

WG: Request to Advance "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"
by Thomas Trede 18 Jan '02

18 Jan '02

FYI. Regards, Thomas Trede -----Ursprungliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Bob Hinden Gesendet: Mittwoch, 16. Januar 2002 23:40 An: Erik.Nordmark(a)eng.sun.com; narten(a)us.ibm.com Cc: scoya(a)ietf.org; ipng(a)sunroof.eng.sun.com Betreff: Request to Advance "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" Erik, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as an Draft Standard: Title: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Author(s): A. Conta, S. Deering Filename: draft-ietf-ipngwg-icmp-v3-02.txt Pages: 23 Date: 29-Nov-01 This document will replace RFC2463 that is currently a Draft Standard. Appendix A in the draft summarizes the changes from RFC2463. A working group last call for this document was completed on December 26, 2001. Bob Hinden / Steve Deering IPv6 Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo(a)sunroof.eng.sun.com --------------------------------------------------------------------

1 0