From owner-ipv6-registry@ns.apnic.net Fri Feb 12 00:21:48 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id AAA03808; Fri, 12 Feb 1999 00:20:45 GMT Received: from gateway (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id AAA03803 for ; Fri, 12 Feb 1999 00:20:43 GMT From: gih@telstra.net Received: (from mail@localhost) by gateway (8.8.7/SCO5) id KAA23981 for ; Fri, 12 Feb 1999 10:20:43 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by gateway via smap (V2.1) id xma023976; Fri, 12 Feb 99 10:20:24 +1000 Received: (from paulg@localhost) by hadrian.staff.apnic.net (8.9.1a/8.9.1) id AAA04343 for ipv6-registry@lists.apnic.net; Fri, 12 Feb 1999 00:20:24 GMT Date: Fri, 12 Feb 1999 00:20:24 GMT Message-Id: <199902120020.AAA04343@hadrian.staff.apnic.net> Received: from nico.telstra.net (nico.telstra.net [139.130.204.16]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id LAA11232 for ; Wed, 10 Feb 1999 11:03:37 GMT Received: from testacc (gunk.telstra.net [203.10.60.2]) by nico.telstra.net Sender: owner-ipv6-registry@apnic.net Precedence: bulk (8.8.8/8.6.10) with SMTP id WAA01358 for ; Wed, 10 Feb 1999 22:03:35 +1100 (EST) Message-Id: <4.1.19990210214146.0094de70@nico.telstra.net> X-Sender: gih@nico.telstra.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 10 Feb 1999 21:50:04 +1100 To: ipv6-registry@apnic.net From: Geoff Huston Subject: Comments on proposed IPv6 proposal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I note: 4.3 Reclamation Methods/Conditions Allocations are valid only as long as the original criteria are still met. I believe that this somewhat open-ended and vague statement will lead to problems down the track (RFC 1744 documents the nature of such issues, as it applies to IPv4 address space). I beleive that it would be a significant improvement to place a more definitive time limit on the validity of an allocation, ensuring that an allocation shouldbe periodically 'refreshed' to renew the application (a 'lease' is perhaps a better word to use than 'allocation' in such a context. We should also condider the use of some form of digital certificate with the V6 address space lease, allowing other parts of the infrastructure to be able to validate the address, such as in validating the origin of an address advertisiement, for example. (While I personally believe that we should take further steps to use a market-based approach to management of the V6 address space, I'll refrain from advocating these views here :-) ) regards, Geoff Huston IPv6-Registry: A list to discuss developing a registry for IPv6 To unsubscribe, send "unsubscribe" to ipv6-registry-request@apnic.net From owner-ipv6-registry@ns.apnic.net Fri Feb 12 13:56:23 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id LAA12449; Fri, 12 Feb 1999 11:16:30 GMT Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id LAA12443 for ; Fri, 12 Feb 1999 11:16:26 GMT Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.2/3.7W/02/03/99) with ESMTP id UAA10731 for ; Fri, 12 Feb 1999 20:16:12 +0900 (JST) Received: from lancer.slab.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.2/3.7W/02/02/99) with ESMTP id UAA05035 for ; Fri, 12 Feb 1999 20:15:17 +0900 (JST) Received: from erika.slab.ntt.co.jp (erika.slab.ntt.co.jp [129.60.146.117]) by lancer.slab.ntt.co.jp (8.8.8/3.6W/lancer) with ESMTP id UAA01899 for ; Fri, 12 Feb 1999 20:16:11 +0900 (JST) Received: from nttslb.slab.ntt.co.jp (localhost [127.0.0.1]) by erika.slab.ntt.co.jp (8.9.1a/3.7W-98102421) with ESMTP id UAA28403 for ; Fri, 12 Feb 1999 20:16:11 +0900 (JST) To: ipv6-registry@apnic.net Subject: [ipv6-registry] Comments on IPv6 address assignments draft X-Mailer: Mew version 1.70 on Emacs 19.28.2 / Mule 2.3 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Feb_12_20:16:09_1999)--" Content-Transfer-Encoding: 7bit Date: Fri, 12 Feb 1999 20:16:11 +0900 Message-ID: <28400.918818171@nttslb.slab.ntt.co.jp> From: (Tomohiro -INSTALLER- Fujisaki/=?ISO-2022-JP?B?GyRCRiM6akNSOSgbKEI=?= ) Sender: owner-ipv6-registry@apnic.net Precedence: bulk ----Next_Part(Fri_Feb_12_20:16:09_1999)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Here is my commnets on "IPv6 Assignment and Allocation Policy Document". ----Next_Part(Fri_Feb_12_20:16:09_1999)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit About allocation policy: This allocation policy mainly targeted IPv4 ISP. I believe the assumption is wrong that an organization who is willing to request IPv6 address is a traditional IPv4 ISP. I think this policy obstruct new comers to start novel IP services, and suppress the evolution of Internet. I hope that the condition for aquiring IPv6 address should be easier. It's enough to check strictly whether IPv6 address holders meet the conditions for maintaining. There are already many conditions in the APNIC draft and RFCs to maintain (sub-)TLA.If they doesn't meet one of them, their address should be revoked strictly. About renumbering: "Renumbering" is not so easy even with IPv6, so it should not be "must" condition. As this draft says, some mechanisms for renumbering are discussed and implemented with IPv6, but they can be used in limited situation. Even if such "address" renumbering is possible, IP address renumbering affect to upper layer applications such as DNS. Moreover, From the ISP's viewpoint, when ISP must renumber their customers because of getting TLA,ISP will already have about 10,000 site needed to renumber.It's very awful to imagine to renumber ISP's internal nodes and customer's network... ----Next_Part(Fri_Feb_12_20:16:09_1999)---- IPv6-Registry: A list to discuss developing a registry for IPv6 To unsubscribe, send "unsubscribe" to ipv6-registry-request@apnic.net From owner-ipv6-registry@ns.apnic.net Wed Feb 17 07:24:46 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id HAA16014; Wed, 17 Feb 1999 07:23:37 GMT Received: from gateway.staff.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id HAA16010 for ; Wed, 17 Feb 1999 07:23:36 GMT Received: (from mail@localhost) by gateway.staff.apnic.net (8.8.7/SCO5) id RAA02458; Wed, 17 Feb 1999 17:23:29 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by gateway.staff.apnic.net via smap (V2.1) id xma002456; Wed, 17 Feb 99 17:23:03 +1000 Received: from localhost (anne@localhost) by hadrian.staff.apnic.net (8.9.1a/8.9.1) with SMTP id HAA02540; Wed, 17 Feb 1999 07:23:02 GMT Date: Wed, 17 Feb 1999 17:23:02 +1000 (EST) From: Anne Lord X-Sender: anne@hadrian Reply-To: Anne Lord To: fujisaki@nttslb.slab.ntt.co.jp cc: ipv6-registry@ns.apnic.net Subject: Re: [ipv6-registry] Comments on IPv6 address assignments draft In-Reply-To: <28400.918818171@nttslb.slab.ntt.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipv6-registry@apnic.net Precedence: bulk Dear Tomohiro Fujisaki, Many thanks for your review of this document - your comments will be shared with other Regional Registries who are the co-authors of this document. All the comments received to date, will be discussed and evaluated for incorporation into the next revision of the document. One minor clarification over the criteria that are applied during the "bootstrapping" phase and the criteria that apply in "normal" conditions. It is during the "bootstrap" period only, that a reference is made to IPv4 customers. If you have any specific suggestions or recommendations for criteria that could apply during this period, we would be happy to receive them. Otherwise, the conditions for requesting a sub-TLA criteria that do not refer to IPv4. We would welcome your further feedback on the document when it is re-released. Thanks again, Anne Lord APNIC Member Services > Hi, > > Here is my commnets on "IPv6 Assignment and Allocation Policy Document". > > About allocation policy: > > This allocation policy mainly targeted IPv4 ISP. I believe the > assumption is wrong that an organization who is willing to request > IPv6 address is a traditional IPv4 ISP. I think this policy obstruct > new comers to start novel IP services, and suppress the evolution of > Internet. > > I hope that the condition for aquiring IPv6 address should be easier. > It's enough to check strictly whether IPv6 address holders meet the > conditions for maintaining. There are already many conditions in the > APNIC draft and RFCs to maintain (sub-)TLA.If they doesn't meet one of > them, their address should be revoked strictly. > > > About renumbering: > > "Renumbering" is not so easy even with IPv6, so it should not be > "must" condition. As this draft says, some mechanisms for renumbering > are discussed and implemented with IPv6, but they can be used in > limited situation. Even if such "address" renumbering is possible, IP > address renumbering affect to upper layer applications such as > DNS. Moreover, From the ISP's viewpoint, when ISP must renumber their > customers because of getting TLA,ISP will already have about 10,000 > site needed to renumber.It's very awful to imagine to renumber ISP's > internal nodes and customer's network... > > IPv6-Registry: A list to discuss developing a registry for IPv6 To unsubscribe, send "unsubscribe" to ipv6-registry-request@apnic.net