From jeast@breathe.co.uk Mon Aug 3 19:52:34 1998 From: jeast@breathe.co.uk (James East) Date: Mon, 3 Aug 1998 19:52:34 +0100 Subject: IPv6 support on Solaris Message-ID: Dear members, I have only just joined this list after finding out about IPv6 (which I am very interested in), so please forgive any "faux pas". :) I wondered if anyone could tell me what was happening with regard to the support of IPv6 on Sun's Solaris platform, and also, how to get an IPv6 client for Win95. I searched the FTP software site, but could not find anything useful. Thanks in advance. -- James East From mike.crawfurd@cmg.nl Tue Aug 4 08:20:25 1998 From: mike.crawfurd@cmg.nl (Mike Crawfurd) Date: Tue, 04 Aug 1998 09:20:25 +0200 Subject: Question about IPng addressing Message-ID: <35C6B639.4DD7A28F@cmg.nl> Dear people, I'm researching IPng, and read various documents, rfc's and white papers. Today I found something that confused me. The pages from sun's playground, http://playground.sun.com/pub/ipng/html/INET-IPng-Paper.html#CH7 indicated that the prefix for Provider-Based Unicast Address is 010 and 100 is reserved for Neutral-Interconnect-Based Unicast Addresses. However in the internet-draft draft-ietf-ipngwg-addr-arch-v2-05.txt these two are not in the reservation specs, although it is a more current document. Are the two mentioned prefixes discarded in the new specs ? And if so, what's the reason behind this decision ? Thanks for all your Help, Mike Crawfurd. Mike Crawfurd Telephone. (+31) 10 253 7000 CMG Advanced Technologies Industries Telefax. (+31) 10 253 7033 Kralingseweg 241, 3062 CE Rotterdam Mobile. (+31) 65 534 7574 The Netherlands Email. mike.crawfurd@cmg.nl From pb@bieringer.de Tue Aug 4 09:23:34 1998 From: pb@bieringer.de (Peter Bieringer) Date: Tue, 04 Aug 1998 10:23:34 +0200 Subject: IPv6 support on Solaris In-Reply-To: Message-ID: <3.0.5.32.19980804102334.009454d0@penelope.et.unibw-muenchen.de> At 19:52 03.08.98 +0100, James East wrote: >Dear members, > >I have only just joined this list after finding out about IPv6 (which I >am very interested in), so please forgive any "faux pas". :) > >I wondered if anyone could tell me what was happening with regard to the >support of IPv6 on Sun's Solaris platform Take a look at http://playground.sun.com/pub/ipng/html/ipng-implementations.2.html#Solaris or http://playground.sun.com/pub/solaris2-ipv6/html/solaris2-ipv6.html >, and also, how to get an IPv6 >client for Win95. I searched the FTP software site, but could not find >anything useful. AIK, no topical software for Win95 is available (the FTP-Software client is out of date because it doesn't support AGU-addresses) :-(. Perhaps, the working driver for WinNT from MS can be ported anytime from MS to Win95/98. It's also possible that they are working on it but do not publish anything about it (it was long not known that MS was developing a NT-driver...). Peter From narten@raleigh.ibm.com Tue Aug 4 14:18:33 1998 From: narten@raleigh.ibm.com (Thomas Narten) Date: Tue, 04 Aug 1998 09:18:33 -0400 Subject: Question about IPng addressing In-Reply-To: Your message of "Tue, 04 Aug 1998 09:20:25 -0400." <35C6B639.4DD7A28F@cmg.nl> Message-ID: <199808041318.JAA07608@cichlid.raleigh.ibm.com> > I'm researching IPng, and read various documents, rfc's and white > papers. Today I found something that confused me. The pages from sun's > playground, > http://playground.sun.com/pub/ipng/html/INET-IPng-Paper.html#CH7 > indicated that the prefix for Provider-Based Unicast Address is 010 and > 100 is reserved for Neutral-Interconnect-Based Unicast Addresses. > However in the internet-draft draft-ietf-ipngwg-addr-arch-v2-05.txt > these two are not in the reservation specs, although it is a more > current document. In the case of 100 (Geographic-Based Unicast Addresses according to rfc 1884), there was no concrete proposal on how these prefixes would actually be used, and in the absense of a concrete proposal, the bits were simply changed to the "reserved" category. Also, I believe the ideas behind this prefix are not incompatable with the generic unicast aggregation prefix (001), so it is not clear that a separate prefix needed to be reserved. This could of course be changed in the future if necessary. In the case of the provider-based prefix 010, it has changed (in a sense) to 001 (Aggregatable Global Unicast Addresses). The provider based schemes are compatable with the definitions of the new prefix. In a sense the 001 prefix is a superset of the other prefixes, hence they are no longer needed. Thomas From rrockell@sprint.net Tue Aug 4 14:22:12 1998 From: rrockell@sprint.net (Robert Rockell) Date: Tue, 4 Aug 1998 09:22:12 -0400 (EDT) Subject: IPv6 support on Solaris In-Reply-To: Message-ID: For Solaris, 2.5, check out http://playground.sun.com/pub/solaris2-ipv6/html/solaris2-ipv6.html I haven't heard anything for Windows 95, but I believe that NT 5 has an IPV6 stack. Thanks Rob Rockell Sprintlink Internet Service Center Operations Engineering 703-689-6322 1-800-724-3329, PIN 385-8833 On Mon, 3 Aug 1998, James East wrote: ->Dear members, -> ->I have only just joined this list after finding out about IPv6 (which I ->am very interested in), so please forgive any "faux pas". :) -> ->I wondered if anyone could tell me what was happening with regard to the ->support of IPv6 on Sun's Solaris platform, and also, how to get an IPv6 ->client for Win95. I searched the FTP software site, but could not find ->anything useful. -> ->Thanks in advance. ->-- ->James East -> From rlfink@lbl.gov Tue Aug 4 22:51:27 1998 From: rlfink@lbl.gov (Bob Fink) Date: Tue, 04 Aug 1998 14:51:27 -0700 Subject: ngtrans agenda - 4Aug98 version Message-ID: <1309880207-652915906@cnrmail.lbl.gov> 6bone/ngtrans folk (and AATN as well) The following is my current take on the ngtrans agenda (including the 6bone and aatn stuff) for Chicago. I've agreed to host a few topics for the AATN folk to help out Jim Bound as they do relate to transition (last two topics on the agenda). I will forward the final agenda early next week to the secretariat, so please come forward now with offers of new topics, or to speak or help with anything shown below. Thanks, Bob ======================================= NGTRANS AGENDA TUESDAY, August 25, 1998 1300-1400 Afternoon Sessions I OPS ngtrans Next Generation Transition WG 1415-1515 Afternoon Sessions II OPS ngtrans Next Generation Transition WG --- ngtrans intro and agenda bashing -Bob Fink -5 mins Changes in ngtrans charter - Bob Fink - 10 mins "IPv6 Transitions Mechanisms" draft for advancement to replace RFC 1933 - 10 mins Status of IPv6 address registry issues with RIPE/ARIN/APNIC - Bob Hinden - 5 mins 6bone status report - Bob Fink - 5 mins 6bone backbone routing - ???? - 5-10 mins When/if do we change from a 'test' AUP to a production 'AUP' - Bob Fink - 10 mins "6bone Routing Practices" draft for advancement to Info RFC - Bertrand Buclin -10 mins draft-tsuchiya-ipv4-ipv6-translator-00.txt - Kazuaki Tsuchiya - 5 mins new ASpath-tree tool features - Ivano Guardini - 10 mins Negotiated Address Reuse - Gabriel Montenegro - 20 mins Distributed Network Address Translation - Michael Borella - 20 mins -end ngtrans agenda =========================== PS: the IPng meetings are: TUESDAY, August 25, 1998 1545-1645 Afternoon Sessions III INT ipngwg IPNG WG 1700-1800 Afternoon Sessions IV INT ipngwg IPNG WG THURSDAY, August 27, 1998 0900-1130 Morning Sessions INT ipngwg IPNG WG -end From mike.crawfurd@cmg.nl Wed Aug 5 08:13:57 1998 From: mike.crawfurd@cmg.nl (Mike Crawfurd) Date: Wed, 05 Aug 1998 09:13:57 +0200 Subject: IPv6 Security - Encryption, Authenticity, Trust, anything! References: <35996FAE.DD06086D@escape.com> Message-ID: <35C80635.8EC88EC2@cmg.nl> Dear 'Quool', The following documents may come in handy for you: rfc1825.txt Security Architecture for the Internet Protocol rfc1826.txt IP Authentication Header rfc1827.txt IP Encapsulating Security Payload (ESP) rfc1828.txt IP Authentication using Keyed MD5 rfc1829.txt The ESP DES-CBC Transform The following url contains maybe some information of what you seek: http://www.fys.ruu.nl/~vginkel/ Maybe the Association for Computing Machinery (ACM.ORG) can help you more on security or a mailinglist from the IPsec group. When your research is done, could you send me a copy of your thesis or document ? I'm also interested in security, but since my research consists of the difference between IPv4 and IPv6, security is only an aspect. I hope it helps, Mike Crawfurd. Mike Crawfurd Telephone. (+31) 10 253 7000 CMG Advanced Technologies Industries Telefax. (+31) 10 253 7033 Kralingseweg 241, 3062 CE Rotterdam Mobile. (+31) 65 534 7574 The Netherlands Email. mike.crawfurd@cmg.nl From rlfink@lbl.gov Thu Aug 6 13:50:23 1998 From: rlfink@lbl.gov (Bob Fink) Date: Thu, 06 Aug 1998 05:50:23 -0700 Subject: (ngtrans) NAT-PTv02 update In-Reply-To: Message-ID: <1309739870-661358489@cnrmail.lbl.gov> George, At 11:36 AM 8/6/98 +0000, George Tsirtsis wrote: >Dear all, > >Here you can find v02 of the NAT-PT draft that was just submited to the >IETF. > >The updated version includes the following changes: >- Various editorial >- Addition of Applicability Statement (section 7) >- Removal of colocated DNS/NAT-PT section 4.2.1 >- 4.2.1 is now "DNS Application Layer Gateway (ALG) support" >- Addition of section 6.5 "DNS Translation and DNSSEC" > >The authors (Pyda Srishuresh and myself) have not yet requested a slot in >the ngtrans meeting. We could, however, give a 5min update if people (and >the chairs) think will help. Comments/discussion on the mailing list are >always welcome. > >Could the chairs also let me know what the process is in order to get this >draft moving? I will add this to the agenda for Chicago and we can discuss then what may be possible to move it forward. I would also like to get comments going on the mail list now in preparation. Comments from the last meeting were: > >Several issues were raised in the discussion that followed: > >- Tony Hain pointed out that the document needs to discuss >applicability of this technique (what types of sites could use >it, what types should not), and also needs to discuss scaling >issues. > >- Brian Carpenter suggested that the group needs to consider how >this technique would combine with the various other transition >techniques, and API issues it raises. > >- Concern was raised about the translation of DNS queries and >replies. It was not clear whether this could be made to work >with signed DNS queries/replies. Regards, Bob From brian@hursley.ibm.com Thu Aug 6 14:35:00 1998 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 06 Aug 1998 14:35:00 +0100 Subject: (ngtrans) NAT-PTv02 update References: <1309739870-661358489@cnrmail.lbl.gov> Message-ID: <35C9B104.D95265B9@hursley.ibm.com> > >- Brian Carpenter suggested that the group needs to consider how > >this technique would combine with the various other transition > >techniques, and API issues it raises. I did, and I'm still worried about that, but I think it's oustide the scope of this particular document. It is more a question of how applications layer code can be written in such a way that it doesn't care whether it's running over IPv4 with or without traditional NAPT, IPv6, either half of a dual stack, or a v4/v6 translator. Brian From brian@hursley.ibm.com Thu Aug 6 17:43:53 1998 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 06 Aug 1998 17:43:53 +0100 Subject: (ngtrans) NAT-PTv02 update References: <199808061414.HAA26664@kc.livingston.com> Message-ID: <35C9DD49.BED862BB@hursley.ibm.com> I suspect we agree on the immediate issue: this topic is outside the scope of NAT-PT. Brian Pyda Srisuresh wrote: > > > > > > >- Brian Carpenter suggested that the group needs to consider how > > > >this technique would combine with the various other transition > > > >techniques, and API issues it raises. > > > > I did, and I'm still worried about that, but I think it's oustide > > the scope of this particular document. It is more a question of > > how applications layer code can be written in such a way that it > > doesn't care whether it's running over IPv4 with or without traditional > > NAPT, IPv6, either half of a dual stack, or a v4/v6 translator. > > > > Brian > > > > I am not sure, I understand what you are saying. > > NAT-PT does not have any issues with the API on V4-only or V6-only > end nodes. As for dual stack nodes, once again, the API doesnt > change because of NAT-PT enroute. However, I do agree, an > application using the dual-stack API could (a) opt to go with the > appropriate native protocol (V4 or v6) or, (b) opt to go with > using a single stack if assured of NAT-PT services en-route, > no matter who it is trying to connect to. > > The API issues are outside the scope of this document. > > cheers, > suresh From bmanning@ISI.EDU Sat Aug 15 17:32:31 1998 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Sat, 15 Aug 1998 09:32:31 -0700 (PDT) Subject: With great sorrow Message-ID: <199808151632.AA10998@zed.isi.edu> I must remove our 6bone core node from service until I get a problem resolved with the BGP code. The effect is that a directly connected IPv4 network shows this behaviour: BGP: no valid path for 198.32.64.0/24 BGP: nettable_walker 198.32.64.0/255.255.255.0 no best path selected ... neighbors marking the route transition ... BGP: 198.32.146.18 send UPDATE 198.32.64.0/24 -- unreachable BGP: nettable_walker 198.32.64.0/255.255.255.0 route sourced locally ... neighbors marking the route transition ... This behaviour occurs every 40sec or so and all known attempts to stablize it while keeping the ipv6 code base intact have proven vain. network 3FFE:800::0/48 and its downstreams will be offline for the duration. I am sorry. I am looking for other platforms to run the code on but it will be a few days. --bill From rlfink@lbl.gov Sun Aug 16 20:21:43 1998 From: rlfink@lbl.gov (Bob Fink) Date: Sun, 16 Aug 1998 12:21:43 -0700 Subject: draft-ietf-ngtrans-header-trans-02.txt progression Message-ID: <1308852390-714746563@cnrmail.lbl.gov> ngtrans folk, Erik Nordmark and I feel that the most effective track for the header translation draft is Experimental RFC. I also propose this for other less production ready standards as well to get them moving along. Please ruminate on this either to me or the list. While on the subject of the various drafts, I don't think combining any of them makes any sense unless the specific proposing authors of two or more of them agree to do so, and submit them to ngtrans ready to go in that form. Thanks, Bob From rlfink@lbl.gov Sun Aug 16 20:27:50 1998 From: rlfink@lbl.gov (Bob Fink) Date: Sun, 16 Aug 1998 12:27:50 -0700 Subject: final ngtrans agenda for Chicago IETF Message-ID: <1308852024-714768620@cnrmail.lbl.gov> ngtrans/6bone folk (and AATN as well), The following is my final (to the secretariat) ngtrans agenda (including the 6bone and aatn stuff) for Chicago. If I've missed something, please let me know by private email or at the meeting, and I will correct. Thanks, Bob ======================================= NGTRANS AGENDA TUESDAY, August 25, 1998 1300-1400 Afternoon Sessions I OPS ngtrans Next Generation Transition WG 1415-1515 Afternoon Sessions II OPS ngtrans Next Generation Transition WG --- ngtrans intro, agenda, charter and handling drafts -Bob Fink - 10 mins "IPv6 Transitions Mechanisms" for advancement to replace RFC 1933 - 10 mins "Stateless IP/ICMP Translator (SIIT)", changes and next step - Erik Nordmark - 10 mins "Network Address Translation-Protocol Translation (NAT-PT)", changes and next step - George Tsirtsis - 10 mins "6bone Routing Practices" for advancement to Info RFC - Bertrand Buclin - 10 mins draft-tsuchiya-ipv4-ipv6-translator-00.txt - Kazuaki Tsuchiya - 5 mins 6bone status report - Bob Fink - 10 mins vBNS current 6bone plans - Greg Miller -5 mins new ASpath-tree tool features - Ivano Guardini - 10 mins Negotiated Address Reuse - Gabriel Montenegro - 20 mins Distributed Network Address Translation - Michael Borella - 20 mins -end ngtrans agenda =========================== PS: the IPng meetings are: TUESDAY, August 25, 1998 1545-1645 Afternoon Sessions III INT ipngwg IPNG WG 1700-1800 Afternoon Sessions IV INT ipngwg IPNG WG THURSDAY, August 27, 1998 0900-1130 Morning Sessions INT ipngwg IPNG WG -end From Harald.Alvestrand@maxware.no Mon Aug 17 09:00:10 1998 From: Harald.Alvestrand@maxware.no (Harald Tveit Alvestrand) Date: Mon, 17 Aug 1998 10:00:10 +0200 Subject: draft-ietf-ngtrans-header-trans-02.txt progression In-Reply-To: <1308852390-714746563@cnrmail.lbl.gov> Message-ID: <3.0.2.32.19980817100010.00a17db0@dokka.maxware.no> At 12:21 16.08.98 -0700, Bob Fink wrote: >ngtrans folk, > >Erik Nordmark and I feel that the most effective track for the header translation draft is Experimental RFC. > >I also propose this for other less production ready standards as well to get them moving along. > >Please ruminate on this either to me or the list. > Ruminations coming right along....... there are really 2 kinds of transition strategies: - Those that can be deployed locally, and the "outer world" sees nothing except IPv4 networking and/or IPv6 networking. I think most of the NAT-based drafts are like this. - Those that need some piece of global deployment in order to be effective. Dual-stack with AAAA/A record choosing and automatic-tunnel drafts require some of this, I think. For the first kind, having multiple competing proposals is really a Good Thing. Each organization needing to test something can take its pick, try it out, and see if it works. It's likely that we will end up with a small number of proposals that work, but have different scaling and/or deployment characteristics. Experimental publication should be encouraged, with standards track processing once it's proven that it works; merging of drafts isn't important as long as solutions are clearly intended for distinct parts of the problem space. For the second kind, we need to be much more careful; global mistakes are *very* expensive to recover from - even if we don't factor in the loss of prestige of the IETF. Here again experimental publication is a Good Thing, but one needs much more care in describing how one tells an experiment from a production network (the IPv6 Testing Address Allocation was one such marker, to pull in an example from another context), and the eventual target is to have a sharply limited number of strategies (ideally zero or one) that need to go standards-track and deployed on the Internet. After all, we only have one Internet to deploy global-scope solutions on. My preliminary conclusion: Yes, Experimental publication is a Good Thing. Drafts need to identify clearly their scope of visibility, and their scaling properties; once they've done that, and the authors are pretty sure it works - SHIP IT. Harald A Harald Tveit Alvestrand IETF Area Director, Operations and Management From Marc.Blanchet@viagenie.qc.ca Mon Aug 17 20:32:08 1998 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Mon, 17 Aug 1998 15:32:08 -0400 Subject: 6bone whois service mirror Message-ID: <3.0.5.32.19980817153208.00a4d100@mail.viagenie.qc.ca> Hi, this is to announce the availability of a whois server (whois.viagenie.qc.ca) which is a mirror of the 6bone registry. It is synchronized "real-time" with the 6bone registry at isi. You can access it by: whois -h whois.viagenie.qc.ca SEARCHWORD Have fun, Regards, Marc. ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ pgp :57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 ------------------------------------------------------------ Auteur du livre TCP/IP Simplifié, Éditions Logiques, 1997 ------------------------------------------------------------ From richdr@microsoft.com Tue Aug 18 00:46:45 1998 From: richdr@microsoft.com (Richard Draves) Date: Mon, 17 Aug 1998 16:46:45 -0700 Subject: routing loop Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81100@RED-MSG-50> I'm seeing a routing loop inside the 3ffe:300::/24 pTLA... Today is the first time I've tried to access this site, so I don't know if this is a transient condition. Thanks, Rich C:\NT\system32>tracert6 -d 3ffe:302:12:3::3 Tracing route to 3ffe:302:12:3::3 over a maximum of 30 hops: 1 10 ms * <10 ms 3ffe:a00:2:1:200:cff:fe1a:c8a8 2 70 ms 70 ms * 3ffe:900:0:8:0:c8e:50c2:e 3 340 ms * 240 ms 5f04:fb00:80b0::1:2:1 4 530 ms 450 ms 520 ms 3ffe:302:11:2:0:2:0:61 5 390 ms * * 3ffe:302:11:1::8 6 690 ms 1241 ms 1301 ms 3ffe:302:11:2:0:2:0:61 7 1001 ms * 941 ms 3ffe:302:11:1::8 8 580 ms 640 ms 560 ms 3ffe:302:11:2:0:2:0:61 9 * * 420 ms 3ffe:302:11:1::8 10 550 ms * * 3ffe:302:11:2:0:2:0:61 11 470 ms * 440 ms 3ffe:302:11:1::8 12 400 ms * * 3ffe:302:11:2:0:2:0:61 13 400 ms * * 3ffe:302:11:1::8 ... From Fabian_Foote-P13721@email.mot.com Thu Aug 20 23:30:29 1998 From: Fabian_Foote-P13721@email.mot.com (M. Fabian Foote) Date: Thu, 20 Aug 1998 15:30:29 -0700 Subject: IPv6 Transitioning for future LEO IP Based Systems? Message-ID: <35DCA385.8B1BD894@email.mot.com> I'm interested in transition, and trend information for IP Risk analysis based upon the following: 1) Transition of Ipv4 backbone to 6bone archictecture, time frame. 2) IPv4 and IPv6 interaction(dual stack and translator) and interworking and API implementations. 3) Trends for IPv4 to Ipv6 routing and name resolution by 2000 and beyond time frame. I've assumed that over time as confidence builds to vendor routers will carry native IPv6 packets, as it is expected that the 6BONE would disappear by agreement of all parties. But by when? It would be replaced in a transparent way by production ISP and user network IPv6 Internet-wide transport. Respectully, -- M. Fabian Foote, Motorola SSTG / Advanced Systems Division Senior Staff Engineer e-mail: Fabian_Foote-p13721@email.mot.com From jefros@sprintmail.com Sun Aug 23 20:16:13 1998 From: jefros@sprintmail.com (Jeff Efros) Date: Sun, 23 Aug 1998 12:16:13 -0700 Subject: unsubscibe Message-ID: <005401bdceca$83238260$036e6e6e@jeff> This is a multi-part message in MIME format. ------=_NextPart_000_004F_01BDCE8F.D216D9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe ------=_NextPart_000_004F_01BDCE8F.D216D9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe
------=_NextPart_000_004F_01BDCE8F.D216D9C0-- From pete@trumpet.com.au Mon Aug 24 06:30:33 1998 From: pete@trumpet.com.au (Peter R. Tattam) Date: Mon, 24 Aug 1998 16:30:33 +1100 Subject: finding an AUS TLA for 6bone Message-ID: <3c8s3o8$1eb@jimmy.trumpet.com.au> second try. maybe this will work. Trying to find a TLA that is best for Australian usage. If one is not available, how could I establish one for the Australian region. Peter From rlfink@lbl.gov Mon Aug 24 15:45:39 1998 From: rlfink@lbl.gov (Bob Fink) Date: Mon, 24 Aug 1998 07:45:39 -0700 Subject: pTLA request In-Reply-To: Message-ID: <1308177754-29959145@cnrmail.lbl.gov> 6bone folk, Below is the pTLA request from the BME-FSZ folk at the Technical University of Budapest in Hungary. http://www.isi.edu/cgi-bin/davidk/whois.pl?bme-fsz Please send your comments on this to the list. If approved, I would like to assign the pTLA by 8 Sep. Thanks, Bob ===================================== At 11:34 AM 8/24/98 +0200, you wrote: > >Dear Bob, > >I'm writing on behalf of our IPv6 team at the Department of Control >Engineering and Information Technology at the Technical University of >Budapest (BME-FSZ). We would like to apply for the assignment of a pTLA to >us. > >Our department is active in computer networks research and education. As a >part of this research, we have been working with IPv6 for nearly two >years. We are taking part in several academic projects on next generation >internetworking. > >Brief description about our site: http://www.ipv6.fsz.bme.hu/ > > >> 1. Must have experience with IPv6 in the 6bone, at least as a leaf site, >> and preferably as an NLA transit under a pTLA. > >We are connected to the 6bone since early 1997, as transit site under >SURFNET and SWITCH. We are providing transit services for several leaf >sites in Hungary. We have experience with several host and router IPv6 >implementations. > >> 2. Must have the ability and intent to provide "production-like" 6bone >> backbone service to provide a robust and operationally reliable 6bone >> backbone. > >We are currently providing services for several sites, and we are planning >to increase this number. We are constantly enhancing our IPv6 network and >we have the necessary network infrastructure to do this. > >> 3. Must have a potential "user community" that would be served by >> becoming a pTLA, e.g., the requester is a major player in a region, >> country or focus of interest. > >Our site is part of the Hungarian Academic IP network, our main "user >community" is the other academic institutions using IPv6, as well as >other sites interested in IPv6. > >> 4. Must commit to abide by whatever the 6bone backbone operational rules >> and policies are (currently there are no formal ones, but the Alain >> Duran draft is a start in trying to define some). > >We state that we will commit to abide to these rules. > > >Thank you, > > Szabolcs Szigeti > EE MSc > Dept. of Control Engineering and Information Technology, TUB > -end From Marc.Blanchet@viagenie.qc.ca Tue Aug 25 04:04:11 1998 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Mon, 24 Aug 1998 23:04:11 -0400 Subject: ipv6 connections available in the terminal room of the ietf meeting Message-ID: <3.0.5.32.19980824230411.02dc8d70@mail.viagenie.qc.ca> Hi, we have configured an ipv6 router on the network of the ietf terminal room. This router is connected to our ipv6 router on Viagénie-network (which is one of the pTLA on the 6bone) by a ipv6 over ipv4 tunnel, so that it is connected to the 6bone. Anybody who have an IPv6 stack can automatically get an ipv6 address without any configuration to get connected to the 6bone. You will receive an address in the viagénie net range 3ffe:0b00:c18:2::/64. The router is up since 20h00 monday 24th and will be there all week long. We've tested both freebsd inria ipv6 and Microsoft NT ipv6 implementations on our portables and were able to connect to any ipv6 host on the 6bone. The idea of this service came from my collegue Florent Parent. We would like to hear anybody who tried this service. Please mention your implementation. Have fun, Marc. ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ pgp :57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 ------------------------------------------------------------ Auteur du livre TCP/IP Simplifié, Éditions Logiques, 1997 ------------------------------------------------------------ From rajiv@cir.nus.edu.sg Tue Aug 25 06:14:05 1998 From: rajiv@cir.nus.edu.sg (Rajiv M Ranganath) Date: Tue, 25 Aug 1998 13:14:05 +0800 (SGT) Subject: new 6bone "looking glass" Message-ID: hi all, I have setup a new 6bone testing tools site, to test your 6bone connectivity from my part of the world. It is available at, http://www.6bone.cir.nus.edu.sg/testing-tools.html Currently "ping", "traceroute" and "whois" are the tools that have been made available. BGP4+ stats should be available once we get bgp connectivity up with our provider. Feedback about this website will be greatly appreciated. thank you, regards, rajiv From Y.Adamopoulos@noc.ntua.gr Tue Aug 25 12:26:43 1998 From: Y.Adamopoulos@noc.ntua.gr (Yiorgos Adamopoulos) Date: Tue, 25 Aug 1998 14:26:43 +0300 Subject: pTLA request In-Reply-To: <1308177754-29959145@cnrmail.lbl.gov>; from Bob Fink on Mon, Aug 24, 1998 at 07:45:39AM -0700 References: <1308177754-29959145@cnrmail.lbl.gov> Message-ID: <19980825142643.B7654@noc.ntua.gr> On Mon, Aug 24, 1998 at 07:45:39AM -0700, Bob Fink wrote: > > Please send your comments on this to the list. If approved, I would like to assign the pTLA by 8 Sep. > I think they should be assigned the pTLA. But, just like in our case (GRNET, 3FFE:2D00::), they should open more tunnels the just with SWITCH and SURFNET. -- Yiorgos Adamopoulos -- #include mailto: Y.Adamopoulos@noc.ntua.gr -- Network Operations Center, NTUA, GREECE From simon@switch.ch Tue Aug 25 16:47:30 1998 From: simon@switch.ch (Simon Leinen) Date: 25 Aug 1998 17:47:30 +0200 Subject: How many Tunnels [Re: Re: pTLA request] In-Reply-To: Yiorgos Adamopoulos's message of Tue, 25 Aug 1998 14:26:43 +0300 References: <1308177754-29959145@cnrmail.lbl.gov> <19980825142643.B7654@noc.ntua.gr> Message-ID: Yiorgos Adamopoulos writes: > I think they should be assigned the pTLA. But, just like in our > case (GRNET, 3FFE:2D00::), they should open more tunnels the just > with SWITCH and SURFNET. Yiorgos raised an interesting point here: How many tunnels should pTLA/transit sites have to other sites. There seems to be a tendency to build a full mesh between backbone sites. I think this is very undesirable, because it makes the 6bone less realistic as a prototype for routing on a global IPv6 network: * The diameter of the network is kept artificially small. * Abundance of tunnels introduces an unrealistic level of redundancy, which reduces the pressure on sites to fix routing problems to a given neighbor. * Some "single hops" over the 6bone represent many many hops over the IPv4 Internet, sometimes including congested subpaths. Those "shortcuts" attract transit traffic that could use a different path consisting of several hops between 6bone neighbors that are actually close to each other in the IPv4 Internet topology. This has a bad impact on global 6bone connectivity. Personally I would prefer the 6bone topology to resemble the IPv4 topology closer than is the case today. SWITCH's policy as a pTLA has been to set up tunnels to other networks that we either peer with or that we have good connectivity with. In particular, we try to avoid the "shortcuts" I mentioned above, as well as links that regularly experience congestion. Is there any opinion on mentioning these problems in the "6bone Routing Practice" I-D, not as a recommendation but as a problem statement? Personally, I find BME-FSZ's connectivity quite sufficient - SURFNET and SWITCH are both connected to Hungary over few hops the TEN-34 research backbone. -- Simon Leinen simon@switch.ch SWITCH http://www.switch.ch/lan/ipv6/ From itojun@iijlab.net Tue Aug 25 17:13:33 1998 From: itojun@iijlab.net (Jun-ichiro itojun Itoh) Date: Wed, 26 Aug 1998 01:13:33 +0900 Subject: ipv6 connections available in the terminal room of the ietf meeting In-Reply-To: Marc.Blanchet's message of Mon, 24 Aug 98 23:04:11 -0400. <3.0.5.32.19980824230411.02dc8d70@mail.viagenie.qc.ca> Message-ID: <7079.904061613@cardamom.itojun.org> >we have configured an ipv6 router on the network of the ietf terminal room. > This router is connected to our ipv6 router on Viag nie-network (which is >one of the pTLA on the 6bone) by a ipv6 over ipv4 tunnel, so that it is >connected to the 6bone. Anybody who have an IPv6 stack can automatically >get an ipv6 address without any configuration to get connected to the >6bone. You will receive an address in the viag nie net range >3ffe:0b00:c18:2::/64. (snip) >We would like to hear anybody who tried this service. Please mention your >implementation. KAME (http://www.kame.net/) works right with your router, and I can perform ssh6 toward my home. Thanks for your effort, itojun@kame.net jun-ichiro itojun itoh From rlfink@lbl.gov Tue Aug 25 17:26:27 1998 From: rlfink@lbl.gov (Bob Fink) Date: Tue, 25 Aug 1998 09:26:27 -0700 Subject: How many Tunnels [Re: Re: pTLA request] In-Reply-To: References: <1308177754-29959145@cnrmail.lbl.gov> <19980825142643.B7654@noc.ntua.gr> Message-ID: <1308085307-35520472@cnrmail.lbl.gov> Simon, At 05:47 PM 8/25/98 +0200, Simon Leinen wrote: >Yiorgos Adamopoulos writes: >> I think they should be assigned the pTLA. But, just like in our >> case (GRNET, 3FFE:2D00::), they should open more tunnels the just >> with SWITCH and SURFNET. > >Yiorgos raised an interesting point here: How many tunnels should >pTLA/transit sites have to other sites. > >There seems to be a tendency to build a full mesh between backbone >sites. I think this is very undesirable, because it makes the 6bone >less realistic as a prototype for routing on a global IPv6 network: > >* The diameter of the network is kept artificially small. >* Abundance of tunnels introduces an unrealistic level of redundancy, > which reduces the pressure on sites to fix routing problems to a > given neighbor. >* Some "single hops" over the 6bone represent many many hops over the > IPv4 Internet, sometimes including congested subpaths. Those > "shortcuts" attract transit traffic that could use a different path > consisting of several hops between 6bone neighbors that are actually > close to each other in the IPv4 Internet topology. This has a bad > impact on global 6bone connectivity. > >Personally I would prefer the 6bone topology to resemble the IPv4 >topology closer than is the case today. SWITCH's policy as a pTLA has >been to set up tunnels to other networks that we either peer with or >that we have good connectivity with. In particular, we try to avoid >the "shortcuts" I mentioned above, as well as links that regularly >experience congestion. Actually there is not anything near a full mesh between pTLA sites. The average seems to be in the 3 to 4 range. Only a few establish many peerings, like UUNET-UK with 15 or so. In fact I believe that many/most 6bone pTLAs try to peer realistically based on service quality. Though I should defer to others to respond to this whom are more active in these options and choices for their own 6bone backbone peering. >Is there any opinion on mentioning these problems in the "6bone >Routing Practice" I-D, not as a recommendation but as a problem >statement? Not the place for a problem statement, though it might ellaborate a bit in the section 4 comments on at least 3 peerings. Maybe saying that a full mesh is NOT the goal (Bertrand?) >Personally, I find BME-FSZ's connectivity quite sufficient - SURFNET >and SWITCH are both connected to Hungary over few hops the TEN-34 >research backbone. Thanks for the comments. Bob From Bertrand.Buclin@ch.att.com Tue Aug 25 17:26:29 1998 From: Bertrand.Buclin@ch.att.com (Buclin, Bertrand) Date: Tue, 25 Aug 1998 17:26:29 +0100 Subject: How many Tunnels [Re: Re: pTLA request] Message-ID: <71203AED30DAD111AFEF0000C09940BE088778@gvamsx1.ch.att.com> > Is there any opinion on mentioning these problems in the "6bone > Routing Practice" I-D, not as a recommendation but as a problem > statement? > Simon, You're making a set of good points. The I-D currently recommends that pTLAs have at least 3 peerings with other pTLAs to maintain a good level of service. This was discussed on the mailing list back in April. If some pTLAs want to maintain a larger set of peerings, this is fine by me (I'm actually one of those maintaining a larger set, currently we have about 12 peerings with other pTLAs). There are benefits in doing this to: - I do this because I have nodes both in Europe and in the US, and this way I can provide a transit service and experiment with what it takes. UUNET-UK is in the same situation. I agree though with your point if a pTLA has only one site, in that case establishing peerings with entities all over the world is counter productive. - Abundance of tunnels also allows us to work on the issue raised by the wider propagation of routing problems. This is particularly true if you operate a distributed pTLA. - Ideally, having a 6bone topology matching the underlying IPv4 Internet topology is a neat objective. We've been trying to do that for a while with little success. Remember that the 6Bone connects entities doing research on Ipv6, not yet operators. CHeers, Bertrand From pete@trumpet.com.au Wed Aug 26 03:08:45 1998 From: pete@trumpet.com.au (Peter R. Tattam) Date: Wed, 26 Aug 1998 13:08:45 +1100 Subject: Leaf node access. Message-ID: <3bure5h$1ef@jimmy.trumpet.com.au> I'm still trying to get leaf node access. If anyone who is willing to offer me access to the 6bone, could they please contact me. There seems to be no clear good access point at the moment. Rather than beat on doors individually. Some info on our location IPv4 wise. We are connected to the internet in three places. Two links in Aus through Telstra big pond, and through Connect.com.au. Both of these are major backbones in Aus. Connect is peered with Telstra as well, and both of these have good international connectivity via Telstra's links to the US. I understand that this link is peered via MCI in California. We also have a direct frame relay (512Kbps) through to our LA office which has a 10Mbps connection to clubnet who in turn have several T1's. A substantial part of our incoming traffic comes through this link. This may change should the price/performance issues related to the link not improve. So anywhere in the California region should get through to us quite well. Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-362-450220 Fax: +61-362-450210 From lalle@sics.se Wed Aug 26 10:12:24 1998 From: lalle@sics.se (Lars Albertsson) Date: 26 Aug 1998 11:12:24 +0200 Subject: How many Tunnels [Re: Re: pTLA request] In-Reply-To: "Buclin, Bertrand"'s message of Tue, 25 Aug 1998 17:26:29 +0100 References: <71203AED30DAD111AFEF0000C09940BE088778@gvamsx1.ch.att.com> Message-ID: > - Ideally, having a 6bone topology matching the underlying IPv4 Internet > topology is a neat objective. We've been trying to do that for a while with > little success. Remember that the 6Bone connects entities doing research on > Ipv6, not yet operators. Is it not possible to reflect IPv4 topology in BGP? An example would be mapping the IPv4 hop count for a tunnel to BGP metric. /Lalle From pink@fsz.bme.hu Wed Aug 26 10:44:08 1998 From: pink@fsz.bme.hu (Szabolcs Szigeti (PinkPanther)) Date: Wed, 26 Aug 1998 11:44:08 +0200 (MET DST) Subject: How many Tunnels [Re: Re: pTLA request] In-Reply-To: Message-ID: On 25 Aug 1998, Simon Leinen wrote: > Is there any opinion on mentioning these problems in the "6bone > Routing Practice" I-D, not as a recommendation but as a problem > statement? I agree with Simon, that this would be a good idea. The importance of good IPv4 connectivity for a tunnel should be stressed, i think, especially as 6bone expands. I would even suggest, that some requirements should be set up for for tunnels, so that routing would somehow reflect the underlying ipv4 links' parameters (rtt or hops). > Personally, I find BME-FSZ's connectivity quite sufficient - SURFNET > and SWITCH are both connected to Hungary over few hops the TEN-34 > research backbone. Yes, we have ipv4 ping times around 35ms (11 hops) to SWITCH, while around 180ms (16 hops) to CICNET, with whom we also have a tunnel. In the meantime, they are all one hop away in ipv6. Szabolcs From itojun@itojun.org Wed Aug 26 22:30:14 1998 From: itojun@itojun.org (Jun-ichiro itojun Itoh) Date: Thu, 27 Aug 1998 06:30:14 +0900 Subject: (IPng 6336) Re: ipv6 connections available in the terminal room of the ietf meeting In-Reply-To: itojun's message of Wed, 26 Aug 98 01:13:33 JST. <7079.904061613@cardamom.itojun.org> Message-ID: <936.904167014@turmeric.itojun.org> >>we have configured an ipv6 router on the network of the ietf terminal room. >> This router is connected to our ipv6 router on Viag nie-network (which is >>one of the pTLA on the 6bone) by a ipv6 over ipv4 tunnel, so that it is >>connected to the 6bone. Anybody who have an IPv6 stack can automatically >>get an ipv6 address without any configuration to get connected to the >>6bone. You will receive an address in the viag nie net range >>3ffe:0b00:c18:2::/64. >(snip) >>We would like to hear anybody who tried this service. Please mention your >>implementation. > KAME (http://www.kame.net/) works right with your router, and I can > perform ssh6 toward my home. Thanks for your effort, It does not work since lunchtime of Wednesday, since autonomous bit of prefix information is not set. (I once thought that it is a KAME local problem, but it seems to be cisco problem...) itojun --- 06:20:11.995020 fe80::200:cff:fe34:6f1b > fe80::200:86ff:fe05:80da: icmp6: router advertisement(chlim=255, router_ltime=1800, reachable_time=0, retrans_time=0)(src lladdr: 0:0:c:34:6f:1b)(prefix info: valid_ltime=86400, preffered_ltime=86400, prefix=3ffe:b00:c18:2::/64) [pri 0x7] (len 56, hlim 255) 6700 0000 0038 3aff fe80 0000 0000 0000 0200 0cff fe34 6f1b fe80 0000 0000 0000 0200 86ff fe05 80da 8600 38e3 ff00 0708 0000 0000 0000 0000 0101 0000 0c34 6f1b 0304 4000 0001 5180 0001 5180 0000 0000 ~~ has to be 0x40 3ffe 0b00 0c18 0002 0000 0000 0000 0000 From parent@viagenie.qc.ca Thu Aug 27 00:05:54 1998 From: parent@viagenie.qc.ca (Florent Parent) Date: Wed, 26 Aug 1998 19:05:54 -0400 (EDT) Subject: (ngtrans) Re: ipv6 connections available in the terminal room of the ietf meeting In-Reply-To: <936.904167014@turmeric.itojun.org> Message-ID: hi, Fixed. Thanks for reporting it ! Florent. On Thu, 27 Aug 1998, Jun-ichiro itojun Itoh wrote: > > >>We would like to hear anybody who tried this service. Please mention your > >>implementation. > > KAME (http://www.kame.net/) works right with your router, and I can > > perform ssh6 toward my home. Thanks for your effort, > > It does not work since lunchtime of Wednesday, since autonomous bit > of prefix information is not set. > > (I once thought that it is a KAME local problem, but it seems to be > cisco problem...) > > itojun > > > --- > 06:20:11.995020 fe80::200:cff:fe34:6f1b > fe80::200:86ff:fe05:80da: icmp6: router advertisement(chlim=255, router_ltime=1800, reachable_time=0, retrans_time=0)(src lladdr: 0:0:c:34:6f:1b)(prefix info: valid_ltime=86400, preffered_ltime=86400, prefix=3ffe:b00:c18:2::/64) [pri 0x7] (len 56, hlim 255) > 6700 0000 0038 3aff fe80 0000 0000 0000 > 0200 0cff fe34 6f1b fe80 0000 0000 0000 > 0200 86ff fe05 80da 8600 38e3 ff00 0708 > 0000 0000 0000 0000 0101 0000 0c34 6f1b > 0304 4000 0001 5180 0001 5180 0000 0000 > ~~ has to be 0x40 > 3ffe 0b00 0c18 0002 0000 0000 0000 0000 > -- Florent Parent Florent.Parent@viagenie.qc.ca Viagénie inc. http://www.viagenie.qc.ca 3107 des hôtels tél.: 418-656-9254 Ste-Foy, Québec, Canada, G1W 4W5 fax.: 418-656-0183 PGP fingerprint = D2 EE 61 51 D7 49 0D 07 69 BE AA 47 1D F4 6D F4 From rlfink@lbl.gov Thu Aug 27 00:36:00 1998 From: rlfink@lbl.gov (Bob Fink) Date: Wed, 26 Aug 1998 16:36:00 -0700 Subject: ngrans summary, chicago IETF Message-ID: <1307973133-42268039@cnrmail.lbl.gov> Summary of NGTRANS WG Meeting - 25 August 1998 - Chicago IETF Chairs: Bob Fink, Bob Gilligan and Tony Hain Attendance: 218 signed in, more than 250 actually present Marc Blanchet, of Viagenie, announced that he had placed a Cisco IPv6 capable router on the IETF terminal room network for anyone's use to reach the 6bone. The KAME project's IPv6 stack operating on a unix workstation in the terminal room was soon operating over this router using ssh6 back to Japan. Congrats, folks! Tony Hain discussed changes that will be made to the ngtrans charter to more accurately reflect the actual work of the group, which is to develop tools and advice to aid in the eventual transition to IPv6, and to make clear that it is not to specify timelines, plans and policies for such a conversion. Bob Fink discussed the processing of drafts beyond RFC 1933, noting that Experimental will be the preferred status of tools such as SIIT and NAT-PT, and Informational for practice/advice such as 6bone Routing Practice. The Experimental status will allow various ideas to be tried out without full understanding of their final role in transition to IPv6. Erik Nordmark presented recent changes in the "IPv6 Transitions Mechanisms" draft for advancement to replace RFC 1933. He also presented a few remaining issues to be resolved on the mailing list. As soon as Erik finishes these few remaining issues up a working group last call will be done to approve sending the draft in to replace the current version, RFC 1933, which is at Proposed Standard status. Erik Nordmark presented recent changes in the "Stateless IP/ICMP Translator (SIIT)" draft for advancement to Experimental RFC. A working group last call for comments will now be made to send this in for processing as Experimental. George Tsirtsis presented recent changes in the "Network Address Translation-Protocol Translation (NAT-PT)" draft for advancement to Experimental RFC. A working group last call for comments will now be made to send this in for processing as Experimental. Bertrand Buclin presented recent changes in the "6bone Routing Practices" draft for advancement to Informational RFC. A working group last call for comments will now be made to send this in for processing as Informational. Kazuaki Tsuchiya presented the Hitachi protocol exchange software for Windows95/98/NT4 systems based on their draft . This software is available now for use at http://www.hitachi.co.jp/Prod/comp/network/pexv6-e.htm. The draft of this work should move forward through ngtrans to Experimental RFC. David Kessens and Bob Fink gave a brief review of the status of the 6bone. There are now 303 sites in 36 countries participating. There are 47 sites participating as backbone sites. Greg Miller presented the vBNS 6bone plans, which basically is to provide native IPv6 transport across the US with IPv6 routers located in the Wash. DC, Chicago and San Francisco Bay areas operating over OC3c links into the vBNS OC12c ATM network. This will make a full native cross country IPv6 backbone available to the 6bone! See http://www.vbns.net/IPv6/index.html for more information. Ivano Guardini presented his new ASpath-tree tool features for monitoring BGP4+ routing inside the 6bone. These tools are up and available at http://carmen.cselt.it/ipv6/bgp/index.htm. Two updated drafts were then presented from previous work presented at the AATN BOF at the previous IETF as a courtesy to that group as they could not easily schedule there own meeting at this IETF. Gabriel Montenegro presented the "Negotiated Address Reuse" draft . Michael Borella presented the "Distributed Network Address Translation" draft It is most likely that work on these two drafts will continue elsewhere, unless they have more ready transition application to IPv6 than currently observed. -end From pete@trumpet.com.au Wed Aug 26 23:44:24 1998 From: pete@trumpet.com.au (Peter R. Tattam) Date: Thu, 27 Aug 1998 09:44:24 +1100 Subject: Leaf node access. Message-ID: <3budbiv$1lu@lana-2.trumpet.com.au> On Tue, 25 Aug 1998, Peter Grehan wrote: > Hi, > > Maybe a dumb question, but are we going to see v6 Trumpet > applications anytime soon ? > > later, > > Peter. > Yes, you guessed right. I am in the throws of building basic IPv6 into Winsock 4.0. Only a few days away from a working stack. Once that is running, I'll look at porting our full Fanfare internet server suite to IPv6. Currently in win32 there is SMTP, POP3, Radius, FTP, HTTP. In win3.x the above plus DNS & News. There is also a possibility of porting our latest mail reader to Ipv6 if anyone is interested. Peter From rlfink@lbl.gov Fri Aug 28 14:21:48 1998 From: rlfink@lbl.gov (Bob Fink) Date: Fri, 28 Aug 1998 06:21:48 -0700 Subject: last call for Hitachi's IPv6 over IPv4 Xlator draft for Experimental RFC forwarding Message-ID: <1307837185-50445949@cnrmail.lbl.gov> ngtrans, The following I-D by Kazuaki Tsuchiya and others of Hitachi and WIDE has been presented in the past and now has an experimental implementation available (announced at this week's ngtrans meeting in Chicago). Thus I want us to ready this for being submitted for Experimental RFC status, so this is the equivalent of last call before forwarding to the IESG. Please send your comments to the ngtrans list by 11 September. For your refernce, I have included the RFC 2026 "Internet Standards Process" information on Experimental status: >4.2.1 Experimental > The "Experimental" designation typically denotes a specification that > is part of some research or development effort. Such a specification > is published for the general information of the Internet technical > community and as an archival record of the work, subject only to > editorial considerations and to verification that there has been > adequate coordination with the standards process (see below). An > Experimental specification may be the output of an organized Internet > research effort (e.g., a Research Group of the IRTF), an IETF Working > Group, or it may be an individual contribution. Thanks, Bob _____________________________________cut here___________________________ INTERNET-DRAFT K. Tsuchiya, Hitachi M. Sumikawa, Hitachi Expires in six month K. Watanabe, Hitachi Y. Atarashi, Hitachi T. Miyamoto, Hitachi K. Yamamoto, IIJ J. Murai, Keio University A Communication Mechanism between IPv4 and IPv6 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract In the late stage of the transition from IPv4 to IPv6, IPv4 lands are interconnected by IPv6 ocean and it is necessary for an IPv4 node and an IPv6 to communicate directly. This memo proposes a mechanism to enable such direct communication with extension name servers, an address mapper, and translators for each IPv4 land. 1. Introduction RFC1933 [TRANS-MECH] proposed mechanisms to transit IPv4 [IPv4] to IPv6 [IPv6], including dual stack and tunneling, for the early stage. IPv6 nodes are assumed to have IPv4 stack and IPv4 addresses. In the late stage of the transition, however, the space of IPv4 Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 1] INTERNET-DRAFT August 1998 address will be exhausted. So, an IPv4 address cannot be assigned to dual-stack hosts. Moreover, IPv6-only hosts will appear for cost reasons. It is expected that IPv4 hosts will retain for a long time, even after appearance of IPv6-only hosts. Therefore, it is highly desired to develop a mechanism to enable a communication between an IPv4 host and an IPv6 host directly. Though a header conversion mechanism is defined in [HDRCNV], interaction for an IPv4 host, an IPv6 host, a header conversion router, and name servers is not mentioned. This memo describes an entire scheme of direct communications between IPv4 hosts and IPv6 hosts. The scheme is applicable to environments where there are multiple name servers and multiple site boundary routes thanks to one "address mapper". It is not necessary to modify IPv4 hosts and IPv6 hosts. This document uses the words defined in [IPV4], [IPV6], and [TRANS-MECH]. 2. Components In the late stage of the transition, IPv4 "land"s are interconnected by IPv6 "ocean". A set of IPv4-only nodes in an organization is an example of IPv6 island. The proposed system consists of extension name servers, one address mapper, and translators. To implement communication between IPv4 nodes and IPv6 nodes, each IPv4 island needs to install such components. Extension name servers have both IPv4 stack and IPv6 stack and provides name service to IPv4 nodes and IPv6 nodes. Translators also have dual-stack functionality and translates "language" of IPv4 nodes and that of IPv6 nodes. The address mapper is communicates only with the extension name servers and the translators. Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 2] INTERNET-DRAFT August 1998 Figure 1 illustrates an IPv4 land which installed the proposed system. +---------+ +-------- // |IPv4 node| | +----+----+ | | | +------+------+ | | | | |An IPv4 land | | IPv6 ocean | | | | | +------------------------+ | +---------+ | +--+ extension name servers +--+ |IPv6 node| | | +------------+-----------+ | +---------+ | | | | | | +------------+-----------+ | +---------+ | | | one address mapper | | |IPv6 node| | | +------------+-----------+ | +---------+ | | | | | | +------------+-----------+ | +---------+ | +--+ translators +--+ |IPv6 node| | | +------------------------+ | +---------+ | | | +------+------+ | | | +----+----+ | |IPv4 node| +-------- // +---------+ Figure 1 2.1 Translator between IPv4 and IPv6 The followings are examples of Translator between IPv4 and IPv6. (1) Proxy gateway An proxy gateway locates between an IPv4 host and an IPv6 host and establishes both an IPv4 connection to the IPv4 host and an IPv6 connection to the IPv6 host. The proxy gateway relays data from the IPv4 host to the IPv6 host and vice versa. (2) Header conversion router A header conversion router locates between an IPv4 host and an Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 3] INTERNET-DRAFT August 1998 IPv6 host. When the router receives an IPv4 packet, the router converts its IPv4 header to an IPv6 header then forwards it. When the router receives an IPv6 packet, the router converts its IPv6 header to an IPv4 header then fragments the packet if necessary and forwards it. 2.2 Extension Name Server Extension name servers returns a "proper" answer in a response to IPv4 node's request or IPv6 node's request. An IPv4 node typically requests one of extension name servers to resolve 'A' record correspond to a host name. If 'A' record is resolved, the server returns it. If only 'AAAA' record is available, the server requests an address mapper to assign one IPv4 address correspond to its IPv6 address. Then the server returns the assigned IPv4 address to the IPv4 node. An IPv6 node typically requests one of extension name servers to resolve 'AAAA' record correspond to a host name. If 'AAAA' record is resolved, the server returns it. If only 'A' record is available, the server requests the address mapper to assign one IPv6 address correspond to its IPv4 address. Then the server returns the assigned IPv6 address to IPv6 node. 2.3 Address Mapper An address mapper maintains an IPv4 address spool and an IPv6 address spool. An example of the IPv4 address spool is private addresses(e.g number 10). An example of the IPv6 address spool is a part of IPv6 space assigned to the organization where the IPv4 land locates inside. When an extension name server or a translator requests one IPv6 address for an IPv4 address, the address mapper selects one IPv6 address from the IPv6 address spool and returns it. When an extension name server or a translator requests one IPv4 address for an IPv6 address, the address mapper selects one IPv4 address from the IPv4 address spool and returns it. 3. Interaction Examples The following subsection explains communication from an IPv4 node to an IPv6 node and communication from an IPv6 node to an IPv4 node, respectively. Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 4] INTERNET-DRAFT August 1998 3.1 Communication from an IPv4 node to an IPv6 node This subsection describes communication between an IPv4 node called "host4" and an IPv6 node called "host6". The communication is triggered by "host4". "host4" sends a query to an extension name server to resolves 'A' record for "host6". The extension name server tries resolving both 'A' record and 'AAAA' record for "host6" but only 'AAAA' record is resolved. Then the server requests an address mapper to assign one IPv4 address correspond to the IPv6 address. The address mapper selects one IPv4 address out of its IPv4 address spool and returns it to the server. The server creates 'A' record for the assigned IPv4 address and returns it to "host4". "host4" sends IPv4 data to "host6". The IPv4 data reaches a translator. The translator tries translating the IPv4 data to IPv6 data but does not know how to translate. (For example, a proxy gateway cannot create an IPv6 connection to "host6" since the IPv6 address of "host6" is not available.) So, the translator requests the mapper to tell mapping entries for the IPv4 source address and the IPv4 destination address. The mapper looks up its mapping table with the IPv4 destination address and finds one IPv6 address for it. Then the mapper looks up its mapping table with the IPv4 source address. In this case, there is not a mapping entry so the mapper selects one IPv6 address for the IPv4 source address. Finally, the mapper returns a pair of the IPv6 source address and the IPv6 destination address to the translator. The translator translates the IPv4 data to IPv6 data. (For example, the proxy gateway creates one IPv6 connection to "host6" and relay the IPv4 data.) The IPv6 data reaches "host6". "host6" sends new IPv6 data to "host4". The IPv6 data reaches the translator. This time the translator has mapping entries for the IPv6 source address and the IPv6 destination Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 5] INTERNET-DRAFT August 1998 address. The translator translates the IPv6 data to IPv4 data. (For example, the proxy gateway just relays the data.) The IPv4 data reaches "host4". The following diagram illustrates the interaction above: IPv4 extension address translator IPv6 node name server mapper node "host4" "host6" Resolve an IPv4 address for host6 ---> Query of 'A' record for "host6". only 'AAAA' record is resolved. ---> Request one IPv4 address correspond to the IPv6 address. Assign on IPv4 address. <--- Reply with the IPv4 address. Create 'A' record for the IPv4 address. <--- Reply with the 'A' record. Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 6] INTERNET-DRAFT August 1998 IPv4 extension address translator IPv6 node name server mapper node "host4" "host6" Send data to host6 =============================> IPv4 data Try translating but don't know how to translate it. <--- Request IPv6 addresses corresond to the IPv4 source address and to the IPv4 destination address. One IPv6 address correspond to the IPv4 destination address is already available. Assign one IPv6 address for the IPv4 source address. ---> Reply with the IPv6 source address and the IPv6 destination address. Translate IPv4 to IPv6. ===> IPv6 data Reply data to host4 <=== IPv6 data Translate IPv6 to IPv4 <============================== IPv6 data 3.2 Communication from an IPv6 node to an IPv4 node In a case where communication is triggered by "host6", its query to resolve 'AAAA' record for "host4" is eventually delivered to one of extension name servers. After interaction is symmetric to the case described in Sention 3.1. Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 7] INTERNET-DRAFT August 1998 4. Security Consideration Header conversions of AH [AH] and ESP [ESP] are cryptographically impossible. This is a big disadvantage of header conversion router approach. On the other hand, it is possible to use AH and ESP in proxy gateway approach. 5. References [AH] Stephen Kent and Randall Atkinson, "IP Authentication Header", Internet-Draft, July 1997. [ESP] Stephen Kent and Randall Atkinson, "IP Encapsulating Security Payload (ESP)", Internet-Draft, July 1997. [HDRCNV] Erik Nordmark, "IPv4/IPv6 Stateless Header Translator", Inernet-Draft, July 1997. [IPV4] J. Postel, "Internet Protocol", RFC 791, September 1981. [IPV6] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, January 1996. [TRANS-MECH] R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. 10. Author's Addresses Kazuaki TSUCHIYA Server & Network Development Division, Hitachi, Ltd. 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN Phone: +81-462-32-2111 Fax: +81-462-35-8325 Email: tsuchi@ebina.hitachi.co.jp Munechika SUMIKAWA Server & Network Development Division, Hitachi, Ltd. 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN Phone: +81-462-35-2111 FAX: +81-462-35-8325 EMail: sumikawa@ebina.hitachi.co.jp Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 8] INTERNET-DRAFT August 1998 Ken WATANABE Server & Network Development Division, Hitachi, Ltd. 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN Phone: +81-462-35-2111 FAX: +81-462-35-8325 Email: nabeken@ebina.hitachi.co.jp Yoshifumi ATARASHI Server & Network Development Division, Hitachi, Ltd. 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN Phone: +81-462-35-2111 FAX: +81-462-35-8325 EMail: atarashi@ebina.hitachi.co.jp Takahisa MIYAMOTO Server & Network Development Division, Hitachi, Ltd. 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN Phone: +81-462-35-2111 FAX: +81-462-35-8325 Email: t-miyamo@ebina.hitachi.co.jp Kazu YAMAMOTO Internet Initiative Japan Inc. Takebashi Yasuda Bldg.,3-13, Kanda Nishiki-cho, Chiyoda-ku, Tokyo 101-0054, Japan Phone: +81-3-5259-6000 FAX: +81-3-5259-6001 EMail: kazu@iijlab.net Jun MURAI Keio University 5322 Endo, Fujisawa 252 JAPAN Phone: +81-466-47-5111 Fax: +81-466-49-1101 EMail: jun@wide.ad.jp Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 9] -end From rlfink@lbl.gov Mon Aug 31 16:49:03 1998 From: rlfink@lbl.gov (Bob Fink) Date: Mon, 31 Aug 1998 08:49:03 -0700 Subject: pTLA request from RCCN Message-ID: <1307569151-66569462@cnrmail.lbl.gov> 6bone folk, Below is the pTLA request from the RCCN folk at the National Research Community Network in Lisbon, Portugal. http://www.isi.edu/cgi-bin/davidk/whois.pl?rccn Please send your comments on this to the list. If approved, I would like to assign the pTLA by 15 Sep. Thanks, Bob ===================================== >Date: Fri, 28 Aug 1998 14:02:52 +0100 (WEST) >From: Pedro Figueiredo >To: rlfink@lbl.gov >Subject: ptla assignment request >Cc: wg-wan@rccn.net, rsofia@rccn.net > >dear bob, > >i am responsible for the rccn (who manages the portuguese research >network) ipv6 project. fccn would like to apply for a ptla assignment. > >fccn is in charge of managing rccn, the portuguese research community >network. we've been working with ipv6 since may, with the goal of >establishing an appropriate transition scheme when the time comes, and >to assess the benefits for the network. > >1. must have experience with ipv6 in the 6bone, at least as a leaf >site, and preferably as an NLA transit under a pTLA. > >we are operating a 6bone node at rccn's management center, and have >established tunnels and bgp4+ routing peers with switch/ch; ul/pt and >sprint/us. > >2. must have the ability and intent to provide "production-like" 6bone >backbone service to provide a robust and operationally reliable 6bone >backbone. > >we currently run several services on an ipv6 node at rccn's management >center and have several agreements to connect several institutions who >have an insterest in ipv6, namely several portuguese universities. > >3. must have a potential "user community" that would be served by >becoming a pTLA, e.g., the requester is a major player in a region, >country or focus of interest. > >fccn manages the portuguese national research comunnity network, >connecting the majority of the universities in the country, as well as >many research laboratories. > >4. must commit to abide by whatever the 6bone backbone operational >rules and policies are (currently there are no formal ones, but the >alain duran draft is a start in trying to define some). > >we hereby state that will abide to the 6bone operational rules and >policies. > >thank you very much for your time. >--- >pedro figueiredo -end From rlfink@lbl.gov Mon Aug 31 17:01:31 1998 From: rlfink@lbl.gov (Bob Fink) Date: Mon, 31 Aug 1998 09:01:31 -0700 Subject: (ngtrans) our paper on translator In-Reply-To: <19980828075856S.kazu@iijlab.net> Message-ID: <1307568403-66614413@cnrmail.lbl.gov> Kazu, At 07:58 AM 8/28/98 +0900, kazu@mew.org wrote: >Hi, > >Our paper entitled "Deployment and Experiences of WIDE 6bone", which >was accepted for inclusion in proceedings of INET 98, is now available >from the following URL: > > http://www.v6.wide.ad.jp/Papers/yamamoto/ > >The last section of this paper explains essential components of >translators and nicely categorize them. > >If necessary, I will write up a new ID based on this paper for >circulation. This type of real experience is just the type of Info RFC we want published from ngtrans, so I encourage you to put it in RFC format and circulate to the list for processing. Good work! Thanks, Bob From rlfink@lbl.gov Mon Aug 31 17:38:49 1998 From: rlfink@lbl.gov (Bob Fink) Date: Mon, 31 Aug 1998 09:38:49 -0700 Subject: (ngtrans) last call for Hitachi's IPv6 over IPv4 Xlator draft forExperimental RFC forwarding Message-ID: <1307566166-66749043@cnrmail.lbl.gov> Regarding my "last call" for the Hitachi translator work, Kazuaki Tsuchiya has decided to split the draft up, so we will wait till he forwards the new one(s) before any more review. Bob ===== >Sorry, Bob. >I'd like to follow your advice if I can do. >But I want to divide into another draft about the IPv6 tool >announced in this ngtrans-wg. > >Would you please give me for a while? >I will try to write another draft about of the IPv6 tool. >And I'd like to make the draft an Experimental RFC. > > >Regards, >-Kazuaki Tsuchiya, Hitachi,Ltd. > > > >At 06:21 98/08/28 -0700, you wrote: >> ngtrans, >> >> The following I-D by Kazuaki Tsuchiya and others of Hitachi and WIDE has >been presented in the past and now has an experimental implementation >available (announced at this week's ngtrans meeting in Chicago). Thus I >want us to ready this for being submitted for Experimental RFC status, so >this is the equivalent of last call before forwarding to the IESG. >> >> Please send your comments to the ngtrans list by 11 September. >> >> For your refernce, I have included the RFC 2026 "Internet Standards >Process" information on Experimental status: >> >> >4.2.1 Experimental >> > The "Experimental" designation typically denotes a specification that >> > is part of some research or development effort. Such a specification >> > is published for the general information of the Internet technical >> > community and as an archival record of the work, subject only to >> > editorial considerations and to verification that there has been >> > adequate coordination with the standards process (see below). An >> > Experimental specification may be the output of an organized Internet >> > research effort (e.g., a Research Group of the IRTF), an IETF Working >> > Group, or it may be an individual contribution. >> >> >> Thanks, >> >> Bob >> _____________________________________cut here___________________________ >> INTERNET-DRAFT K. Tsuchiya, Hitachi >> M. Sumikawa, Hitachi >> Expires in six month K. Watanabe, Hitachi >> Y. Atarashi, Hitachi >> T. Miyamoto, Hitachi >> K. Yamamoto, IIJ >> J. Murai, Keio University >> >> >> A Communication Mechanism between IPv4 and IPv6 >> >> >> >> Status of this Memo >> >> This document is an Internet-Draft. Internet-Drafts are working >> documents of the Internet Engineering Task Force (IETF), its areas, >> and its working groups. Note that other groups may also distribute >> working documents as Internet-Drafts. >> >> Internet-Drafts are draft documents valid for a maximum of six >> months and may be updated, replaced, or obsoleted by other documents >> at any time. It is inappropriate to use Internet-Drafts as >> reference material or to cite them other than as ``work in >> progress.'' >> >> To learn the current status of any Internet-Draft, please check the >> ``1id-abstracts.txt'' listing contained in the Internet-Drafts >> Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net >> (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific >> Rim). >> >> Abstract >> >> In the late stage of the transition from IPv4 to IPv6, IPv4 lands >> are interconnected by IPv6 ocean and it is necessary for an IPv4 >> node and an IPv6 to communicate directly. This memo proposes a >> mechanism to enable such direct communication with extension name >> servers, an address mapper, and translators for each IPv4 land. >> >> >> 1. Introduction >> >> RFC1933 [TRANS-MECH] proposed mechanisms to transit IPv4 [IPv4] to >> IPv6 [IPv6], including dual stack and tunneling, for the early >> stage. IPv6 nodes are assumed to have IPv4 stack and IPv4 addresses. >> In the late stage of the transition, however, the space of IPv4 >> >> >> >> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 1] >> INTERNET-DRAFT August 1998 >> >> >> address will be exhausted. So, an IPv4 address cannot be assigned to >> dual-stack hosts. Moreover, IPv6-only hosts will appear for cost >> reasons. It is expected that IPv4 hosts will retain for a long time, >> even after appearance of IPv6-only hosts. Therefore, it is highly >> desired to develop a mechanism to enable a communication between an >> IPv4 host and an IPv6 host directly. >> >> Though a header conversion mechanism is defined in [HDRCNV], >> interaction for an IPv4 host, an IPv6 host, a header conversion >> router, and name servers is not mentioned. This memo describes an >> entire scheme of direct communications between IPv4 hosts and IPv6 >> hosts. The scheme is applicable to environments where there are >> multiple name servers and multiple site boundary routes thanks to >> one "address mapper". It is not necessary to modify IPv4 hosts and >> IPv6 hosts. >> >> This document uses the words defined in [IPV4], [IPV6], and >> [TRANS-MECH]. >> >> 2. Components >> >> In the late stage of the transition, IPv4 "land"s are interconnected >> by IPv6 "ocean". A set of IPv4-only nodes in an organization is an >> example of IPv6 island. >> >> The proposed system consists of extension name servers, one address >> mapper, and translators. To implement communication between IPv4 >> nodes and IPv6 nodes, each IPv4 island needs to install such >> components. >> >> Extension name servers have both IPv4 stack and IPv6 stack and >> provides name service to IPv4 nodes and IPv6 nodes. Translators also >> have dual-stack functionality and translates "language" of IPv4 >> nodes and that of IPv6 nodes. The address mapper is communicates >> only with the extension name servers and the translators. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 2] >> INTERNET-DRAFT August 1998 >> >> >> Figure 1 illustrates an IPv4 land which installed the proposed >> system. >> >> +---------+ +-------- // >> |IPv4 node| | >> +----+----+ | >> | | >> +------+------+ | >> | | | >> |An IPv4 land | | IPv6 ocean >> | | | >> | | +------------------------+ | +---------+ >> | +--+ extension name servers +--+ |IPv6 node| >> | | +------------+-----------+ | +---------+ >> | | | | >> | | +------------+-----------+ | +---------+ >> >> | | | one address mapper | | |IPv6 node| >> | | +------------+-----------+ | +---------+ >> | | | | >> | | +------------+-----------+ | +---------+ >> | +--+ translators +--+ |IPv6 node| >> | | +------------------------+ | +---------+ >> | | | >> +------+------+ | >> | | >> +----+----+ | >> |IPv4 node| +-------- // >> +---------+ >> >> Figure 1 >> >> >> 2.1 Translator between IPv4 and IPv6 >> >> The followings are examples of Translator between IPv4 and IPv6. >> >> (1) Proxy gateway >> >> An proxy gateway locates between an IPv4 host and an IPv6 host >> and establishes both an IPv4 connection to the IPv4 host and an >> IPv6 connection to the IPv6 host. The proxy gateway relays data >> from the IPv4 host to the IPv6 host and vice versa. >> >> (2) Header conversion router >> >> A header conversion router locates between an IPv4 host and an >> >> >> >> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 3] >> INTERNET-DRAFT August 1998 >> >> >> IPv6 host. When the router receives an IPv4 packet, the router >> converts its IPv4 header to an IPv6 header then forwards it. >> When the router receives an IPv6 packet, the router converts its >> IPv6 header to an IPv4 header then fragments the packet if >> necessary and forwards it. >> >> 2.2 Extension Name Server >> >> Extension name servers returns a "proper" answer in a response to >> IPv4 node's request or IPv6 node's request. >> >> An IPv4 node typically requests one of extension name servers to >> resolve 'A' record correspond to a host name. If 'A' record is >> resolved, the server returns it. If only 'AAAA' record is available, >> the server requests an address mapper to assign one IPv4 address >> correspond to its IPv6 address. Then the server returns the assigned >> IPv4 address to the IPv4 node. >> >> An IPv6 node typically requests one of extension name servers to >> resolve 'AAAA' record correspond to a host name. If 'AAAA' record is >> resolved, the server returns it. If only 'A' record is available, >> the server requests the address mapper to assign one IPv6 address >> correspond to its IPv4 address. Then the server returns the assigned >> IPv6 address to IPv6 node. >> >> 2.3 Address Mapper >> >> An address mapper maintains an IPv4 address spool and an IPv6 >> address spool. An example of the IPv4 address spool is private >> addresses(e.g number 10). An example of the IPv6 address spool is a >> part of IPv6 space assigned to the organization where the IPv4 land >> locates inside. >> >> When an extension name server or a translator requests one IPv6 >> address for an IPv4 address, the address mapper selects one IPv6 >> address from the IPv6 address spool and returns it. >> >> >> When an extension name server or a translator requests one IPv4 >> address for an IPv6 address, the address mapper selects one IPv4 >> address from the IPv4 address spool and returns it. >> >> 3. Interaction Examples >> >> The following subsection explains communication from an IPv4 node to >> an IPv6 node and communication from an IPv6 node to an IPv4 node, >> respectively. >> >> >> >> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 4] >> INTERNET-DRAFT August 1998 >> >> >> 3.1 Communication from an IPv4 node to an IPv6 node >> >> This subsection describes communication between an IPv4 node called >> "host4" and an IPv6 node called "host6". The communication is >> triggered by "host4". >> >> "host4" sends a query to an extension name server to resolves 'A' >> record for "host6". >> >> The extension name server tries resolving both 'A' record and 'AAAA' >> record for "host6" but only 'AAAA' record is resolved. Then the >> server requests an address mapper to assign one IPv4 address >> correspond to the IPv6 address. >> >> The address mapper selects one IPv4 address out of its IPv4 address >> spool and returns it to the server. >> >> The server creates 'A' record for the assigned IPv4 address and >> returns it to "host4". >> >> "host4" sends IPv4 data to "host6". >> >> The IPv4 data reaches a translator. The translator tries translating >> the IPv4 data to IPv6 data but does not know how to translate. (For >> example, a proxy gateway cannot create an IPv6 connection to "host6" >> since the IPv6 address of "host6" is not available.) So, the >> translator requests the mapper to tell mapping entries for the IPv4 >> source address and the IPv4 destination address. >> >> The mapper looks up its mapping table with the IPv4 destination >> address and finds one IPv6 address for it. Then the mapper looks up >> its mapping table with the IPv4 source address. In this case, there >> is not a mapping entry so the mapper selects one IPv6 address for >> the IPv4 source address. Finally, the mapper returns a pair of the >> IPv6 source address and the IPv6 destination address to the >> translator. >> >> The translator translates the IPv4 data to IPv6 data. (For example, >> the proxy gateway creates one IPv6 connection to "host6" and relay >> the IPv4 data.) >> >> The IPv6 data reaches "host6". "host6" sends new IPv6 data to >> "host4". >> >> The IPv6 data reaches the translator. This time the translator has >> mapping entries for the IPv6 source address and the IPv6 destination >> >> >> >> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 5] >> INTERNET-DRAFT August 1998 >> >> >> address. The translator translates the IPv6 data to IPv4 data. (For >> example, the proxy gateway just relays the data.) >> >> The IPv4 data reaches "host4". >> >> The following diagram illustrates the interaction above: >> >> >> IPv4 extension address translator IPv6 >> node name server mapper node >> "host4" "host6" >> >> >> Resolve an IPv4 address for host6 >> >> ---> Query of 'A' record for "host6". >> >> only 'AAAA' record is resolved. >> >> ---> Request one IPv4 address correspond to >> the IPv6 address. >> >> Assign on IPv4 address. >> >> <--- Reply with the IPv4 address. >> >> Create 'A' record for the IPv4 address. >> >> <--- Reply with the 'A' record. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 6] >> INTERNET-DRAFT August 1998 >> >> >> IPv4 extension address translator IPv6 >> node name server mapper node >> "host4" "host6" >> >> Send data to host6 >> >> =============================> IPv4 data >> >> Try translating but don't >> know how to translate it. >> >> <--- Request IPv6 addresses >> corresond to the IPv4 source >> address and to the IPv4 >> destination address. >> >> One IPv6 address correspond to the IPv4 >> destination address is already >> available. Assign one IPv6 address for >> the IPv4 source address. >> >> ---> Reply with the IPv6 source >> address and the IPv6 >> destination address. >> >> Translate IPv4 to IPv6. >> >> ===> IPv6 data >> >> Reply data to >> host4 >> >> <=== IPv6 data >> >> Translate IPv6 to IPv4 >> >> <============================== IPv6 data >> >> >> 3.2 Communication from an IPv6 node to an IPv4 node >> >> In a case where communication is triggered by "host6", its query to >> resolve 'AAAA' record for "host4" is eventually delivered to one of >> extension name servers. After interaction is symmetric to the case >> described in Sention 3.1. >> >> >> >> >> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 7] >> INTERNET-DRAFT August 1998 >> >> >> 4. Security Consideration >> >> Header conversions of AH [AH] and ESP [ESP] are cryptographically >> impossible. This is a big disadvantage of header conversion router >> approach. On the other hand, it is possible to use AH and ESP in >> proxy gateway approach. >> >> >> 5. References >> >> [AH] Stephen Kent and Randall Atkinson, "IP Authentication Header", >> Internet-Draft, July 1997. >> >> >> [ESP] Stephen Kent and Randall Atkinson, "IP Encapsulating Security >> Payload (ESP)", Internet-Draft, July 1997. >> >> [HDRCNV] Erik Nordmark, "IPv4/IPv6 Stateless Header Translator", >> Inernet-Draft, July 1997. >> >> [IPV4] J. Postel, "Internet Protocol", RFC 791, September 1981. >> >> [IPV6] S. Deering and R. Hinden, "Internet Protocol, Version 6 >> (IPv6) Specification", RFC 1883, January 1996. >> >> [TRANS-MECH] R. Gilligan and E. Nordmark, "Transition Mechanisms for >> IPv6 Hosts and Routers", RFC 1933, April 1996. >> >> 10. Author's Addresses >> >> Kazuaki TSUCHIYA >> Server & Network Development Division, Hitachi, Ltd. >> 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN >> >> Phone: +81-462-32-2111 >> Fax: +81-462-35-8325 >> Email: tsuchi@ebina.hitachi.co.jp >> >> Munechika SUMIKAWA >> Server & Network Development Division, Hitachi, Ltd. >> 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN >> >> Phone: +81-462-35-2111 >> FAX: +81-462-35-8325 >> EMail: sumikawa@ebina.hitachi.co.jp >> >> >> >> >> >> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 8] >> INTERNET-DRAFT August 1998 >> >> >> Ken WATANABE >> Server & Network Development Division, Hitachi, Ltd. >> 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN >> >> Phone: +81-462-35-2111 >> FAX: +81-462-35-8325 >> Email: nabeken@ebina.hitachi.co.jp >> >> Yoshifumi ATARASHI >> Server & Network Development Division, Hitachi, Ltd. >> 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN >> >> Phone: +81-462-35-2111 >> FAX: +81-462-35-8325 >> EMail: atarashi@ebina.hitachi.co.jp >> >> Takahisa MIYAMOTO >> Server & Network Development Division, Hitachi, Ltd. >> 810 Shimoimaizumi, Ebina-shi 243-0435 JAPAN >> >> Phone: +81-462-35-2111 >> FAX: +81-462-35-8325 >> Email: t-miyamo@ebina.hitachi.co.jp >> >> Kazu YAMAMOTO >> Internet Initiative Japan Inc. >> Takebashi Yasuda Bldg.,3-13, Kanda Nishiki-cho, >> Chiyoda-ku, Tokyo 101-0054, Japan >> >> Phone: +81-3-5259-6000 >> FAX: +81-3-5259-6001 >> EMail: kazu@iijlab.net >> >> Jun MURAI >> Keio University >> 5322 Endo, Fujisawa 252 JAPAN >> >> Phone: +81-466-47-5111 >> Fax: +81-466-49-1101 >> EMail: jun@wide.ad.jp >> >> >> >> >> >> >> >> >> >> Tsuchiya draft-ietf-ngtrans-ipv4-ipv6-xlator-00.txt [Page 9] >> -end >> >-------------------------------------------------------- >Kazuaki Tsuchiya (E-mail:tsuchi@ebina.hitachi.co.jp) > Hitachi, Ltd. Server & Network Development Division > Phone:+81-462-32-2111(ex.5835) Fax:+81-462-35-8337 > From rrockell@sprint.net Mon Aug 31 19:27:09 1998 From: rrockell@sprint.net (Robert Rockell) Date: Mon, 31 Aug 1998 14:27:09 -0400 (EDT) Subject: PTLA requirements Message-ID: While I believe that the minimum tunnel requirement may not be the best and most reasonable idea, based on geographic distribution of sites, and all the other reasons mentioned, I do believe that there should be some mechanism in place such that we can guarantee that the vast majority of PTLA owners are serious about the 6-bone... Maybe something such as "all PTLA owners must accept reasonable peering requests with other PTLA owners, and seriously consider requests for downstream sessions wiht those desirous of 6bone connectivity", though this brings into account the need to define "seriously". Any thoughts? Thanks Rob Rockell Sprintlink Internet Service Center Operations Engineering 703-689-6322 1-800-724-3329, PIN 385-8833 From kazu@iijlab.net Mon Aug 31 20:22:26 1998 From: kazu@iijlab.net (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue, 01 Sep 1998 04:22:26 +0900 Subject: (ngtrans) last call for Hitachi's IPv6 over IPv4 Xlator draft forExperimental RFC forwarding In-Reply-To: Your message of "Mon, 31 Aug 1998 09:38:49 -0700" <1307566166-66749043@cnrmail.lbl.gov> References: <1307566166-66749043@cnrmail.lbl.gov> Message-ID: <19980901042226X.kazu@iijlab.net> From: Bob Fink Subject: Re: (ngtrans) last call for Hitachi's IPv6 over IPv4 Xlator draft forExperimental RFC forwarding Date: Mon, 31 Aug 1998 09:38:49 -0700 > Regarding my "last call" for the Hitachi translator work, Kazuaki > Tsuchiya has decided to split the draft up, so we will wait till he > forwards the new one(s) before any more review. Let me clarify. (1) I will write up an ID on translators based on the INET '98 papar to sophisticate our previous translator ID. (2) Tsuchiya will write an ID on his *driver-base* duail stack implementation. I think we cannot call it translator. Rather, it is a technic called *bump-in-the-stack* (in IPsec terminology) for dual-stack. And, (3) WIDE Project will publish our mail experience on 6bone which explained in LA meeting. Japanese note is already on the table. I have to translate into English. Allow me one month or so because I'm suffering from my Ph. D paper.... --Kazu, WIDE Project