- ipv6-wg - mailman.ripe.net

[joao@ripe.net: Modifications to the inet6num in the RIPE Database]
by David Kessens 15 Mar '99

15 Mar '99

Hi, I think this should have been forwarded to the ipv6 mail list earlier ... I don't have much trouble with it myself. I will be sending a few minor comments to Joao on the <db-wg(a)ripe.net> mail list were he originally posted the message. David K. --- ----- Forwarded message from Joao Luis Silva Damas <joao(a)ripe.net> ----- Delivered-To: lists-db-wg-out(a)lists.ripe.net X-Mailer: exmh version 2.0.2 2/24/98 To: lir-wg(a)ripe.net, db-wg(a)ripe.net Subject: Modifications to the inet6num in the RIPE Database From: Joao Luis Silva Damas <joao(a)ripe.net> X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Thu, 04 Mar 1999 10:20:17 +0100 Precedence: bulk Dear all, below are the proposed modifications to the inet6num object in the RIPE Database as discussed during the past RIPE Meeting. These are mainly to bring the IPv6 object up to the IPv4 object's functionality. The two suggested changes are: - addition of a "status" attribute with the following possible values: TLA, NLA and SLA. Syntax checks will be done so that: TLA is only allowed if the prefix length is 3<x<=16 NLA is only allowed if the prefix length is 16<x<=48 SLA is only allowed if the prefix length is 48<x<=64 - addition of "mnt-lower" capabilities, as in the IPv4 object. We would like to open a comment period of 1 week from today to gather input and proceed with implementation if there is consensus. Regards, Joao Damas DB Group RIPE NCC ----- End forwarded message -----

1 0

Fw: (IPng 7300) Update to IPng web pages
by Thomas Trede 12 Mar '99

12 Mar '99

FYI. Regards, Thomas Trede -----Original Message----- From: Bob Hinden <hinden(a)iprg.nokia.com> To: ipng(a)sunroof.eng.sun.com <ipng(a)sunroof.eng.sun.com> Cc: hinden(a)iprg.nokia.com <hinden(a)iprg.nokia.com> Date: Donnerstag, 11. Mdrz 1999 03:03 Subject: (IPng 7300) Update to IPng web pages >I have completed a set of updates to the IPng web pages at: > > http://playground.sun.com/ipng > >Changes include new specs, current standardization status, meeting minutes, >6REN link, and new implementations. > >Please send changes and corrections to me. > >Thanks, >Bob > >-------------------------------------------------------------------- >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

[kato@wide.ad.jp: Re: Meeting on IPv6 Address Allocation Policy]
by David Kessens 11 Mar '99

11 Mar '99

For those of you attending the next IETF meeting: ----- Forwarded message from Akira Kato <kato(a)wide.ad.jp> ----- To: 6bone(a)ISI.EDU Subject: Re: Meeting on IPv6 Address Allocation Policy From: Akira Kato <kato(a)wide.ad.jp> Date: Wed, 10 Mar 1999 10:48:50 +0900 I sent the pre-announcement attached below in Mar 07 afternoon. I got positive responses from at least two Regional Registries and I would like to confirm the meeting: It will be held as below: March 16 (TUE), 11:30 -- 12:30 in Room Salon G (-- 11:15, the first NGtrans meeting held in the same room The purpose of the meeting is *not* to bash the registries but to - Demonstrate how we are requiring IPv6 address space, - Understand the current situation of each Regional Registry, - Find out what kind of help from IPv6 community to the registries is needed to expedite the allocation process, - so on. Note that we will only have only 1 hour slot. So please understand that we can not discuss the issues in detail. Also please read the IPv6 Address Allocation Policy in advance. See you soon in Minneapolis! -- Akira Kato, WIDE Project > Folks, > > The Regional Registries (ARIN, RIPE/NCC, APNIC) is about to define the > IPv6 address allocation policy. Their current draft may be referred > from your regional registries. In the case of APNIC, you can get > through the URL below: > http://www.apnic.net/ipv6draft.html > > The registries held a meeting to discuss the guidelines last week in > Singapore (in conjunction with Apricot'99) and some IPv6 people have > been invited to the meeting. Althrough I was not able to attend it, > a quick report from my colleague said that there was some discussion > on the current bootstrap condition which requires an IPv6 (s)TLA > applicant should have at least 100 non-dialup customers (corresponding > to the 8th paragraph of 4.1.1 in the case of APNIC draft). > > One of the conclusion of the meeting was to hold a continuous > discussion during the Minnepolis IETF meeting. Current candidate > timeslot is just after the first NGtrans session is over (March 16 (TUE) > 11:30 -- 12:30, in Room Salon G). > > Please note that the above schedule is tentative and may be changed or > even entirely cancelled. Those who are interested to participate it, > please stay tuned. > > -- Akira Kato, WIDE Project ----- End forwarded message ----- David K. ---

1 0

IPv6 Registry to Qwest??
by Marijke Kaat 05 Mar '99

05 Mar '99

Hi David, At the last RIPE meeting you said the registry will be moved from ISI to Qwest. Do you have any update on this?? Another thing, it says in your minutes that for the 6REN a registry will be available at Qwest also. Will this be the same registry or a separate one??? A more general question (not just to you): are there any ideas/plans how registries are going to be set up later on??? Regards, Marijke

1 0

Fw: (IPng 7267) I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-03.txt
by Thomas Trede 05 Mar '99

05 Mar '99

FYI. Regards, Thomas Trede -----Original Message----- From: Internet-Drafts(a)ietf.org <Internet-Drafts(a)ietf.org> To: "IETF-Announce:;;;@sunroof.Eng.Sun.COM"@Eng.Sun.COM; <"IETF-Announce:;;;@sunroof.Eng.Sun.COM"@Eng.Sun.COM;> Cc: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Freitag, 5. Mdrz 1999 03:10 Subject: (IPng 7267) I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-03.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IPNG Working Group of the IETF. > > Title : IPv6 Node Information Queries > Author(s) : M. Crawford > Filename : draft-ietf-ipngwg-icmp-name-lookups-03.txt > Pages : 6 > Date : 03-Mar-99 > > This document describes an experimental protocol for asking an IPv6 > node to supply certain network information, such as its fully- > qualified domain name. IPv6 implementation experience has shown > that direct queries for FQDN are useful, and a direct query > mechanism for other information has been requested. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-03. txt > >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-icmp-name-lookups-03.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-icmp-name-lookups-03.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-icmp-name-lookups-03.txt

1 0

Re: IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft)
by Philip Smith 05 Mar '99

05 Mar '99

Hi David, Paula, colleagues, Some comments on the IPv6 policy draft document and the IAB comments. Hopefully these can be considered by the registries for the next revision. I decided not to take the document and analyse sections of it; rather I think we should collectively step back and look at the problem we are trying to address (no pun intended). What the document does not cover sufficiently: - Internet Exchange Points - newcomers to the IPv6 transit service - what is meant by a "customer" - what is meant by "transit" It is my understanding that the address design of IPv6 intended a subTLA (and later, a TLA) to be allocated to transit providers only, not leaf providers. The document doesn't declare this. A transit provider is a service provider who accepts routing information from a customer AS or peer AS, into his AS, and then announces that routing information to another customer AS or peer AS. Those of us who configure routers and run ISP backbones use this definition. It is my opinion that these service providers are the ones who qualify for subTLAs. "customers" are service providers who connect to transit providers as defined above. Service providers could be enterprise networks who have their own AS appearing in the Internet routing table for multihoming or management purposes. They could be ISPs as we know them in the commercial world, or they could be educational establishments; all have their own AS. These "customers" would be the organisations I'd envisage qualifying for NLA address space. These "customers" would assign address space to the end users. Using these definitions, look at the numbers. How many transit providers have 100 customers in the relationship as defined above. Well, a straw poll on the routing table shows very very few. 100 is too big, and I agree with the IAB that 10 may be a more realistic number. Secondly, IXPs. These are not mentioned, but I think we need separate paragraphs to cover IXPs. I'd suggest that an IXP would qualify for a subTLA provided they have a public document showing a memorandum of understanding, or a signed agreement, that the peering relationship between service providers at that location forms an IXP. Maybe a minimum of 10 service providers could realistically qualify such an operation as an IXP. Same barrier to entry as "transit" providers. 100 is definitely too high. Newcomers. Work needed here, and probably the most difficult one to properly define. Some businesses may wish to only offer IPv6 transit services. If they can show business relationships to provide transit services (defined above) to "customers" defined above, they should qualify for a subTLA. (By "relationships" I mean signed contracts or commitments from potential customers to "buy" transit services.) Build in safeguards re deployment etc, but allow for up to 2 years. We aren't switching IPv4 off one day, and IPv6 on the next. Now to a reality check. Using my definitions above, I analysed the current IPv4 Internet routing table. It makes interesting reading! - There are 4619 ASes originating networks in the Internet routing table today, 5th March. - There are 1608 ASes providing transit services in the Internet today. This is the number of providers who are providing connectivity to ASes originating networks. Rather than constructing complex rules about allocation to existing providers, we have the solution above. 1608 ASes are providing IPv4 transit services, so 1608 ASes qualify for subTLA space. Give it to them now, and they have two years to do something with it. If they don't do anything with it, revoke it. Second, the ASes which are originating networks are the service providers who will receive NLA address space from the subTLA holders. Some originating ASes will be transit providers too, but then this is why the hierarchy has been built into the address scheme... Wasting address space? I think not. 1608 transit ASes is 1608 of 8192 possible subTLAs. 1608 routes in the IPv6 routing table is tiny compared with the potential 16384 defined by RFC2450 in FP 001 IPv6 space. We'll need significant growth of the Internet to use all 8192 subTLAs. Yes, that is a huge amount of address space relative to the IPv4 Internet, but it is still only one of 8192 TLAs in one eighth of the total IPv6 address space. People "dusting off" ASes in their back pocket? Well, you need to do a lot of dusting off to become a transit service provider, especially if you have to show that you are providing transit to at least 10 other ASes. No danger there, provided "transit" is defined. People rushing to get ASes so they can get a subTLA? Well, same applies. You need to provide transit service. If newcomers sign business agreements or contracts with 10 other ASes (same barrier as existing service providers), then they too should qualify. And remember, the registries don't assign ASes unless you are multihoming between different ISPs. I hope this is useful and can act as a reality check - I hope we introduce a system whereby service providers from all parts of the industry and the world are encouraged to deploy IPv6. The document in its current form is an excellent first step at tackling the issue but I hope it can be enhanced to encourage further development and deployment of IPv6. best wishes! philip -- -------------------------------------------------------- Philip Smith vm: 6178202 ph: +61 7 3238 8202 Consulting Engineering, Office of the CTO, Cisco Systems --------------------------------------------------------

1 0

Fw: (IPng 7259) I-D ACTION:draft-ietf-ipngwg-jumbograms-00.txt
by Thomas Trede 03 Mar '99

03 Mar '99

FYI. Regards, Thomas Trede -----Original Message----- From: Internet-Drafts(a)ietf.org <Internet-Drafts(a)ietf.org> To: "IETF-Announce:;;@sunroof.Eng.Sun.COM"@Eng.Sun.COM <"IETF-Announce:;;@sunroof.Eng.Sun.COM"@Eng.Sun.COM> Cc: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Mittwoch, 3. Mdrz 1999 06:52 Subject: (IPng 7259) I-D ACTION:draft-ietf-ipngwg-jumbograms-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IPNG Working Group of the IETF. > > Title : IPv6 Jumbograms > Author(s) : D. Borman, S. Deering, B. Hinden > Filename : draft-ietf-ipngwg-jumbograms-00.txt > Pages : 8 > Date : 01-Mar-99 > > A 'jumbogram' is an IPv6 packet containing a payload longer than > 65,535 octets. This document describes the IPv6 Jumbo Payload > option, which provides the means of specifying such large payload > lengths. It also describes the changes needed to TCP and UDP to make > use of jumbograms. > > Jumbograms are relevant only to IPv6 nodes that may be attached to > links with a link MTU greater than 65,575 octets, and need not be > implemented or understood by IPv6 nodes that do not support > attachment to links with such large MTUs. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-jumbograms-00.txt > >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-jumbograms-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-ipngwg-jumbograms-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-ipngwg-jumbograms-00.txt

1 0

Fw: (IPng 7257) I-D ACTION:draft-ietf-ipngwg-mld-01.txt
by Thomas Trede 03 Mar '99

03 Mar '99

FYI. Regards, Thomas Trede -----Original Message----- From: Internet-Drafts(a)ietf.org <Internet-Drafts(a)ietf.org> To: "IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;; <"IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;;> Cc: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Mittwoch, 3. Mdrz 1999 00:26 Subject: (IPng 7257) I-D ACTION:draft-ietf-ipngwg-mld-01.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IPNG Working Group of the IETF. > > Title : Multicast Listener Discovery (MLD) for IPv6 > Author(s) : S. Deering, B. Fenner, B. Haberman > Filename : draft-ietf-ipngwg-mld-01.txt > Pages : 20 > Date : 01-Mar-99 > > This document specifies the protocol used by an IPv6 router to > discover the presence of multicast listeners (that is, nodes > wishing to receive multicast packets) on its directly attached > links, and to discover specifically which multicast addresses are > of interest to those neighboring nodes. This protocol is referred > to as Multicast Listener Discovery or MLD. > > MLD is derived from version 2 of IPv4's Internet Group Management > Protocol, IGMPv2. One important difference to note is that MLD > uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP > Protocol 2) message types. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-01.txt > >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-mld-01.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-mld-01.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-mld-01.txt

1 0

Fw: (IPng 7256) I-D ACTION:draft-ietf-ipngwg-jumbograms-00.txt
by Thomas Trede 03 Mar '99

03 Mar '99

FYI. Regards, Thomas Trede -----Original Message----- From: Internet-Drafts(a)ietf.org <Internet-Drafts(a)ietf.org> To: "IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;; <"IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;;> Cc: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Mittwoch, 3. Mdrz 1999 00:23 Subject: (IPng 7256) I-D ACTION:draft-ietf-ipngwg-jumbograms-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IPNG Working Group of the IETF. > > Title : IPv6 Jumbograms > Author(s) : D. Borman, S. Deering, B. Hinden > Filename : draft-ietf-ipngwg-jumbograms-00.txt > Pages : 8 > Date : 01-Mar-99 > > A 'jumbogram' is an IPv6 packet containing a payload longer than > 65,535 octets. This document describes the IPv6 Jumbo Payload > option, which provides the means of specifying such large payload > lengths. It also describes the changes needed to TCP and UDP to make > use of jumbograms. > > Jumbograms are relevant only to IPv6 nodes that may be attached to > links with a link MTU greater than 65,575 octets, and need not be > implemented or understood by IPv6 nodes that do not support > attachment to links with such large MTUs. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-jumbograms-00.txt > >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-jumbograms-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-ipngwg-jumbograms-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-ipngwg-jumbograms-00.txt

1 0

Fw: (IPng 7255) I-D ACTION:draft-ietf-ipngwg-router-renum-08.txt
by Thomas Trede 03 Mar '99

03 Mar '99

FYI. Regards, Thomas Trede -----Original Message----- From: Internet-Drafts(a)ietf.org <Internet-Drafts(a)ietf.org> To: "IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;; <"IETF-Announce:;;;;@ns.cnri.reston.va.us;"@Eng.Sun.COM;;;> Cc: ipng(a)sunroof.Eng.Sun.COM <ipng(a)sunroof.Eng.Sun.COM> Date: Mittwoch, 3. Mdrz 1999 00:23 Subject: (IPng 7255) I-D ACTION:draft-ietf-ipngwg-router-renum-08.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IPNG Working Group of the IETF. > >Note: This revision reflects comments received during the last call period. > > Title : Router Renumbering for IPv6 > Author(s) : M. Crawford > Filename : draft-ietf-ipngwg-router-renum-08.txt > Pages : 30 > Date : 01-Mar-99 > > IPv6 Neighbor Discovery and Address Autoconfiguration conveniently > make initial assignments of address prefixes to hosts. Aside from > the problem of connection survival across a renumbering event, these > two mechanisms also simplify the reconfiguration of hosts when the > set of valid prefixes changes. > > This document defines a mechanism called Router Renumbering ('RR') > which allows address prefixes on routers to be configured and > reconfigured almost as easily as the combination of Neighbor > Discovery and Address Autoconfiguration works for hosts. It > provides a means for a network manager to make updates to the > prefixes used by and advertised by IPv6 routers throughout a site. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-08.txt > >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-router-renum-08.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-router-renum-08.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-router-renum-08.txt

1 0