From rrockell@sprint.net Fri Sep 4 17:21:45 1998 From: rrockell@sprint.net (Robert Rockell) Date: Fri, 4 Sep 1998 12:21:45 -0400 (EDT) Subject: routing policy questions Message-ID: Should backbone nodes be filtering out anything beyond a /24 that is not from their ptla? For instance, if I am getting a /24 aggregate from a peer, and someone else is announcing a more specific /48, it really makes a mess. Is there a definitive policy put forth that we can ask to have enforced? I am seeing many assymetries due to differences in routing policy. Thanks Rob Rockell Sprintlink Internet Service Center Operations Engineering 703-689-6322 1-800-724-3329, PIN 385-8833 From rlfink@lbl.gov Sat Sep 5 01:00:32 1998 From: rlfink@lbl.gov (Bob Fink) Date: Fri, 04 Sep 1998 17:00:32 -0700 Subject: routing policy questions In-Reply-To: Message-ID: <1307194062-89133915@cnrmail.lbl.gov> Robert, At 12:21 PM 9/4/98 -0400, Robert Rockell wrote: >Should backbone nodes be filtering out anything beyond a /24 that is not >from their ptla? > >For instance, if I am getting a /24 aggregate from a peer, and someone else >is announcing a more specific /48, it really makes a mess. > >Is there a definitive policy put forth that we can ask to have enforced? I >am seeing many assymetries due to differences in routing policy. Our operating policies are in the document: http://www.6bone.net/6bone-routing-practice.htm which also has a pointer on the 6bone home page. The operative portion is: > pTLA MUST NOT advertise prefixes longer than 24 to other pTLAs unless > special peering agreements are implemented. When such special peering > agreements are in place between any two or more pTLAs, care MUST be taken > not to leak the more specific prefixes to other pTLAs not participating > in the peering agreement. Bob From Bertrand.Buclin@ch.att.com Mon Sep 7 08:28:35 1998 From: Bertrand.Buclin@ch.att.com (Buclin, Bertrand) Date: Mon, 7 Sep 1998 08:28:35 +0100 Subject: routing policy questions Message-ID: <71203AED30DAD111AFEF0000C09940BE0B3DD0@gvamsx1.ch.att.com> > Should backbone nodes be filtering out anything beyond a /24 > that is not from their ptla? As Bob Fink pointed out, first of all backbone nodes should only be announcing a /24 for their own pTLA. If everyone does this, then we have already reduced the problem quite a bit. You can receive more specific routes from NLAs as well. In that case, you can easily convince your NLA site to fix the list of prefix they advertise. There has been discussion among some backbone sites to see if it would make sense that the backbone TLAs implement strict filtering rules (i.e. block everything but the /24 pTLAs). The consensus was that this would not be a productive way of doing things: we would hide the problems instead of giving us an opportunity to work them out. > For instance, if I am getting a /24 aggregate from a peer, and someone else > is announcing a more specific /48, it really makes a mess. > > Is there a definitive policy put forth that we can ask to > have enforced? I > am seeing many assymetries due to differences in routing policy. > > > Thanks > Rob Rockell > Sprintlink Internet Service Center > Operations Engineering > 703-689-6322 > 1-800-724-3329, PIN 385-8833 > > From Bertrand.Buclin@ch.att.com Mon Sep 7 08:31:14 1998 From: Bertrand.Buclin@ch.att.com (Buclin, Bertrand) Date: Mon, 7 Sep 1998 08:31:14 +0100 Subject: routing policy questions Message-ID: <71203AED30DAD111AFEF0000C09940BE0B3DD1@gvamsx1.ch.att.com> Sorry, I hit the send button too quickly on my previous mail... > For instance, if I am getting a /24 aggregate from a peer, > and someone else is announcing a more specific /48, it > really makes a mess. You should contact the site advertising the more specific /48 and ask them to fix their filtering list. > > Is there a definitive policy put forth that we can ask to > have enforced? As Bob Fink mentioned already, the 6bone routing is governed by . Cheers, Bertrand From rzm@icm.edu.pl Mon Sep 7 14:59:14 1998 From: rzm@icm.edu.pl (Rafal Maszkowski) Date: Mon, 7 Sep 1998 15:59:14 +0200 Subject: routing policy questions In-Reply-To: <71203AED30DAD111AFEF0000C09940BE0B3DD0@gvamsx1.ch.att.com>; from Buclin, Bertrand on Mon, Sep 07, 1998 at 08:28:35AM +0100 References: <71203AED30DAD111AFEF0000C09940BE0B3DD0@gvamsx1.ch.att.com> Message-ID: <19980907155914.P19673@icm.edu.pl> On Mon, Sep 07, 1998 at 08:28:35AM +0100, Buclin, Bertrand wrote: > > Should backbone nodes be filtering out anything beyond a /24 > > that is not from their ptla? > As Bob Fink pointed out, first of all backbone nodes should only > be announcing a /24 for their own pTLA. If everyone does this, then > we have already reduced the problem quite a bit. You can receive > more specific routes from NLAs as well. In that case, you can easily > convince your NLA site to fix the list of prefix they advertise. Let us imagine a pNLA site with two tunnels to pTLAs. When the main link (main in a sense that most machines have IP numbers from this site) fails there is no way to reach this pNLA site from anywhere else except second pTLA networks (if the agreement provides). The solutions could be: - allow to send /32 between pTLAs - become a pTLA - have a tunnel to every pTLA - have double (triple, quadruple, ...) IP numbers (?) are there any better ideas? What is the reason of not propagating > /24 prefixes and how to setup backup links not being pTLA? R. From rlfink@lbl.gov Tue Sep 8 17:50:29 1998 From: rlfink@lbl.gov (Bob Fink) Date: Tue, 08 Sep 1998 09:50:29 -0700 Subject: BME-FSZ now has pTLA 3FFE:2F00::/24 In-Reply-To: Message-ID: <1306874266-108372732@cnrmail.lbl.gov> Szabolcs , At 11:34 AM 8/24/98 +0200, Szabolcs Szigeti (PinkPanther) 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. ... The two weeks have passed with supportive comment, thus I have assigned BME-FSZ the pTLA of 3FFE:2F00::/24. You can look at http://www-ntd.lbl.gov/cgi-bin/whois.pl?bme-fsz to see it in the registry. Please note that your previous inet6num is still there. Please delete it if you think appropriate. The 6bone pTLA page is not yet updated, but will soon be. Thanks, and welcome to the 6bone backbone. Bob From masaki@merit.edu Tue Sep 8 18:07:34 1998 From: masaki@merit.edu (Masaki Hirabaru) Date: Tue, 08 Sep 1998 13:07:34 -0400 Subject: routing policy questions In-Reply-To: Your message of "Mon, 7 Sep 1998 08:31:14 +0100 " <71203AED30DAD111AFEF0000C09940BE0B3DD1@gvamsx1.ch.att.com> References: <71203AED30DAD111AFEF0000C09940BE0B3DD1@gvamsx1.ch.att.com> Message-ID: <19980908130734L.masaki@merit.edu> Hi. 6bone folks, Recently, I established a tunnel with an European site that has a /48 assigned from a pTLA (in US but not me) through some transit site. I'd like to ask people on 6bone who are involved in multi-homing about how you implement it (keeping the 6bone routing policy). Thanks, Masaki From kuznet@ms2.inr.ac.ru Tue Sep 8 19:18:11 1998 From: kuznet@ms2.inr.ac.ru (kuznet@ms2.inr.ac.ru) Date: Tue, 8 Sep 1998 22:18:11 +0400 (MSK DST) Subject: routing policy questions In-Reply-To: <19980908130734L.masaki@merit.edu> from "Masaki Hirabaru" at Sep 8, 98 01:07:34 pm Message-ID: <199809081818.WAA18334@ms2.inr.ac.ru> Hello! > Recently, I established a tunnel with an European site that has a > /48 assigned from a pTLA (in US but not me) through some transit > site. > > I'd like to ask people on 6bone who are involved in multi-homing > about how you implement it (keeping the 6bone routing policy). It is pretty clear that this 6bone rule is in serious contradiction with bgp4 paradigm and with concept of AS numbers. Read, with reality 8) Probably, I do not understand something, but it is impossible to inhibit exporting shorter prefixes without getting rid of these concepts. Suppose, my pTLA is collection of 3 AS. 2 of them have tunnels. If I do aggregation, it will not only make paths much longer, I will be forced to export aggregate with different AS paths!!! I am sorry, I prefer to violate any rules, only to avoid BGP breaking. Alexey Kuznetsov From rrockell@sprint.net Tue Sep 8 19:36:09 1998 From: rrockell@sprint.net (Robert Rockell) Date: Tue, 8 Sep 1998 14:36:09 -0400 (EDT) Subject: routing policy questions In-Reply-To: <19980907155914.P19673@icm.edu.pl> Message-ID: stricly speaking, it is routing table size. On big backbones, when you allow a more specific to be announced by one of your customers (that is using youR address space) you not only have to now listen to that announcement from the other provider that YOU peer with, but you now have to de-aggregate your own outbound announcements to the rest of the world, which, for instance, if everyone was multi-homed, that woudl triple your table size (aggregate, other provider's announcements, and your own deaggreagate) for every multi-homed customer. In v4, this is already a problem for backbones that are not optimized to handle >65k routes, and we know that routing table size can only get bigger. If everyone would dual-assign their interaces of all machines, then the routing table size tops out at 15 bits of size, as in any given backbone, one only needs to hear all the /24 of other TLA's, and then their own internal /48's that they have delegated. Without doing this, we can see that routing table sizes grow beyond a manageable amount quickly. This is why I was asking. When a fully implementable solution for v6 occurs, the assignment of address space should become a lot easier, making this solution more feasible to network administrators, as ipv6 address assignment will be done automatically, through the solicited node request stuff. What had spurred this question on was that I was seeing more specific routes to a destination from a provider who is not even directly connectected to that node, than from the network provider who is directly connected. This leads to bad routing. The only solutions are: 1. stop that and filter on the /24 from other tla's, or 2. allow the /48's and fully de-aggregate your announcements. -as stated above, #2 is not feasilbe based on potential routing table size. This is not a problem now, but will quickly become one if this sort of routing table is allowed to go to production. Just wondering if anyone actually is doing the nice-guy thing of dually assigning when multi-homed. Thanks Rob Rockell Sprintlink Internet Service Center Operations Engineering 703-689-6322 1-800-724-3329, PIN 385-8833 On Mon, 7 Sep 1998, Rafal Maszkowski wrote: ->On Mon, Sep 07, 1998 at 08:28:35AM +0100, Buclin, Bertrand wrote: ->> > Should backbone nodes be filtering out anything beyond a /24 ->> > that is not from their ptla? ->> As Bob Fink pointed out, first of all backbone nodes should only ->> be announcing a /24 for their own pTLA. If everyone does this, then ->> we have already reduced the problem quite a bit. You can receive ->> more specific routes from NLAs as well. In that case, you can easily ->> convince your NLA site to fix the list of prefix they advertise. -> ->Let us imagine a pNLA site with two tunnels to pTLAs. When the main link (main ->in a sense that most machines have IP numbers from this site) fails there is no ->way to reach this pNLA site from anywhere else except second pTLA networks (if ->the agreement provides). The solutions could be: ->- allow to send /32 between pTLAs ->- become a pTLA ->- have a tunnel to every pTLA ->- have double (triple, quadruple, ...) IP numbers (?) ->are there any better ideas? -> ->What is the reason of not propagating > /24 prefixes and how to setup backup ->links not being pTLA? -> ->R. -> From patrickm@savvis.com" Can anyone direct me to a reference which discusses, at a somewhat general level, the major differences between IPv4 and v6? Probably a 20 or so page discussion would be helpful. Also, any references which deal with the concepts of the hierarchical addressing scheme in IPv6? I have been unable to find anything which explains high level concepts. Rather, everything seems to go straight to the bits and bytes. My brain only makes sense of bits and bytes after it understands the concepts. Thanks! --------------------------------------------------------- Patrick Morris - Manager, Sales Engineering SAVVIS Communications Corporation 7777 Bonhomme - Suite 1501 St. Louis, MO 63105 (314)719-2453 phone (314)719-2498 fax (888)688-0190 pager -----Original Message----- From: kuznet@ms2.inr.ac.ru [SMTP:kuznet@ms2.inr.ac.ru] Sent: Tuesday, September 08, 1998 1:18 PM To: Masaki Hirabaru Cc: 6bone@ISI.EDU Subject: Re: routing policy questions Hello! > Recently, I established a tunnel with an European site that has a > /48 assigned from a pTLA (in US but not me) through some transit > site. > > I'd like to ask people on 6bone who are involved in multi-homing > about how you implement it (keeping the 6bone routing policy). It is pretty clear that this 6bone rule is in serious contradiction with bgp4 paradigm and with concept of AS numbers. Read, with reality 8) Probably, I do not understand something, but it is impossible to inhibit exporting shorter prefixes without getting rid of these concepts. Suppose, my pTLA is collection of 3 AS. 2 of them have tunnels. If I do aggregation, it will not only make paths much longer, I will be forced to export aggregate with different AS paths!!! I am sorry, I prefer to violate any rules, only to avoid BGP breaking. Alexey Kuznetsov From aavella@advtech.uswest.com Wed Sep 9 00:51:21 1998 From: aavella@advtech.uswest.com (Alejandro Avella) Date: Tue, 08 Sep 1998 17:51:21 -0600 Subject: IPv4 vs IPv6 Comparison References: <01BDDB4E.000C4CA0.patrickm@savvis.com> Message-ID: <35F5C2F9.889FDB3B@advtech.uswest.com> Patrick Morris wrote: > Also, any references which deal with the concepts of the > hierarchical addressing scheme in IPv6? Take a look to:Stallings, William, "IPv6: The New Internet Protocol", IEEE Communications Magazine, pp. 96-108, July 1996. It is more high level than most references. -Alejandro From pete@trumpet.com.au Wed Sep 9 00:25:12 1998 From: pete@trumpet.com.au (Peter R. Tattam) Date: Wed, 9 Sep 1998 10:25:12 +1100 Subject: Beta of IPv6 Trumpet Winsock release imminent, some musings Message-ID: <3c0l72i$1m7@lana-2.trumpet.com.au> As I have a beta just about ready to release, I just want to be prepared for the onslaught that it may generate. If a whole bunch of people want to connect to the 6bone, are 6bone members able to provide quick access to those that may want to beta test. I plan to make the beta available to regular Trumpet beta testers. The initial beta will be LAN only, I don't have PPP ready yet. Anyone want to offer me PPP over Ipv6 access for testing? One possible way of providing rapid access to a large group of people might be to use a reflector site similar to Cuseeme. Has any work been done on that yet? I could see it implemented as a automatically configurable multi user tunnel (cavern?) with the client connecting to a fixed IP, and bootp/dhcp over ipv6 used to provide an IPv6 address, the Ipv4/Ipv6 tuple being used to maintain the tunnel. I could write such a beast fairly quickly now. Also, is there a defined way of compressing Ipv6 headers that are operating over a tunnel. I can see a scenario where a user is tunnelling direct from their machine over an Ipv4 PPP connection. The overhead of an extra 40 bytes per Ipv6 header might make conenctions a little chunky especially something like telnet, and also the IPv4 header won't be compressed either as it won't be TCP protocol so there will be a minimum of 60 bytes per tunneled packet each way. Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-362-450220 Fax: +61-362-450210 From pete@trumpet.com.au Wed Sep 9 08:02:08 1998 From: pete@trumpet.com.au (Peter R. Tattam) Date: Wed, 9 Sep 1998 18:02:08 +1100 Subject: Beta of IPv6 Trumpet Winsock release imminent, some musings Message-ID: <3bujlia$1eu@jimmy.trumpet.com.au> some recipients of the 6bone list have asked how they can join our beta program. There is no formal process to join. What I normally do is publish the beta copies from our FTP site for all and sundry to grab. Betas are released AS IS and no liability will be taken by us if something goes wrong. I make announcements of betas from the "trumpet.announce" newsgroup. If your news site doesn't carry the trumpet.* newsgroups, they are publicly accessible from newsroom.trumpet.com.au. Please note however that our news server keeps a historic list going back quite a way so you might want to tell your news browser to "catch up" all the trumpet.* groups and then unread the last 20 or so. Other servers will of course expire articles as they may see fit. Peter From masaki@merit.edu Wed Sep 9 05:41:50 1998 From: masaki@merit.edu (masaki@merit.edu) Date: Wed, 09 Sep 1998 10:41:50 +0600 (EDT) Subject: routing policy questions In-Reply-To: Your message of "Tue, 8 Sep 1998 22:18:11 +0400 (MSK DST)" <199809081818.WAA18334@ms2.inr.ac.ru> References: <199809081818.WAA18334@ms2.inr.ac.ru> Message-ID: <19980909104150A.masaki@merit.edu> > Suppose, my pTLA is collection of 3 AS. 2 of them have tunnels. > If I do aggregation, it will not only make paths much longer, > I will be forced to export aggregate with different AS paths!!! Hi. Alexey, In your example, a pTLA is "shared" by more than one AS? In common cases, I think prefixes are allocated "hierarchally"; a pTLA is assigned to one AS (site) and the site delegates NLAs to the others. I think that your example could be translated into that a site other than root of pTLA wants to do multi-homing. Masaki >> From: kuznet@ms2.inr.ac.ru >> Subject: Re: routing policy questions >> Date: Tue, 8 Sep 1998 22:18:11 +0400 (MSK DST) >> Message-ID: <199809081818.WAA18334@ms2.inr.ac.ru> >> > Hello! > > > Recently, I established a tunnel with an European site that has a > > /48 assigned from a pTLA (in US but not me) through some transit > > site. > > > > I'd like to ask people on 6bone who are involved in multi-homing > > about how you implement it (keeping the 6bone routing policy). > > It is pretty clear that this 6bone rule is in serious contradiction > with bgp4 paradigm and with concept of AS numbers. Read, with reality 8) > > Probably, I do not understand something, but it is impossible > to inhibit exporting shorter prefixes without getting rid of > these concepts. > > Suppose, my pTLA is collection of 3 AS. 2 of them have tunnels. > If I do aggregation, it will not only make paths much longer, > I will be forced to export aggregate with different AS paths!!! > > I am sorry, I prefer to violate any rules, only to avoid BGP breaking. > > Alexey Kuznetsov > From kuznet@ms2.inr.ac.ru Wed Sep 9 16:50:47 1998 From: kuznet@ms2.inr.ac.ru (kuznet@ms2.inr.ac.ru) Date: Wed, 9 Sep 1998 19:50:47 +0400 (MSK DST) Subject: routing policy questions In-Reply-To: <19980909104150A.masaki@merit.edu> from "masaki@merit.edu" at Sep 9, 98 10:41:50 am Message-ID: <199809091550.TAA25178@ms2.inr.ac.ru> Hello! > In your example, a pTLA is "shared" by more than one AS? Yes. > In common > cases, I think prefixes are allocated "hierarchally"; a pTLA is > assigned to one AS (site) and the site delegates NLAs to the others. > I think that your example could be translated into that a site other > than root of pTLA wants to do multi-homing. - Today "root" has pretty poor connectivity. - Tomorrow it will have superb connectivity. - After week, it (probably) will have no connectivity, except for their peers due to collapse of russian economics 8)8) Als, 6bone works on existing IPv4 infrastructure, and tla policy is determined by it rather than any aestetical reasons. Your statement means only one thing: any AS, which wants to make its own policy, have right to get its own pTLA. It will result only in TLA proliferation, rather than to nice hierarchical picture. Alexey From pete@trumpet.com.au Thu Sep 10 00:46:34 1998 From: pete@trumpet.com.au (Peter R. Tattam) Date: Thu, 10 Sep 1998 10:46:34 +1100 Subject: GSE, future of Ipv6 Message-ID: <3c41t4c$1f0@jimmy.trumpet.com.au> I had a read of draft-ietf-ipngwg-esd-analysis-02 last night with some interest. I have also browsed some of the more recent drafts if IPv6, and have noticed a trend towards the concepts of GSE - am I right? A few comments... 1) It is quite a paradigm shift, and takes a little bit of thought to grasp the full issues, although if it could established, I can see some clear benefit. However getting the rest of the world to agree on the paradigm shift might set the development of IPv6 back a few more years. 2) As I need to plan future development of our products, having a clear direction of what has to happen vs what would be nice to happen are needed to make decisions on that future development. 3) What are going to be the trends of global routing over the next year or so. 4) Is the paradigm shift needed yet, and will it's implementation slow down the rolling out of IPv6? Peter From pete@trumpet.com.au Thu Sep 10 08:28:18 1998 From: pete@trumpet.com.au (Peter R. Tattam) Date: Thu, 10 Sep 1998 18:28:18 +1100 Subject: Trumpet Winsock 4.1 IPv6 (Beta 1) Message-ID: <3cuffpb$1f1@jimmy.trumpet.com.au> Just posted this to our trumpet.announce newsgroup. Feel free to try it out and send me your feedback. Of special interest to those on the list is my attempt at IPv6 to IPv4 address translation. This allows one to use existing IPv4 apps running over winsock to access the IPv6 network. For e.g., I am able to use regular IPv4 Netscape to browse any of the IPv6 web sites that are out there. My apologies for the minimalist approach, but I'm doing a proof of concept at the moment. The next in list to be done is Address Autoconfiguration, and making the resolver work with IPv6 DNS servers (It does understand AAAA records mind you - read the readme) Enjoy!!! Peter From: peternews@trumpet.com.au (Peter R. Tattam) Newsgroups: trumpet.announce Subject: Trumpet Winsock 4.1 IPv6 (Beta 1) - BETA TESTERS ONLY Date: Thu, 10 Sep 1998 18:21:25 +1100 IMPORTANT: This is not a production release and as such our tech support lines are not obliged to respond to questions relating to this release. All enquiries regarding this beta release should be sent to me (peternews@trumpet.com.au) or posted in trumpet.feedback until further notice. I'm posting this mainly to give explanation to people are wondering what the new beta is about. Now down to business. Location: ftp://ftp.trumpet.com/winsock/beta-4.1/twsk41b1.exe USA or ftp://ftp.trumpet.com.au/winsock/beta-4.1/twsk41b1.exe AUS This is pretty much a work in progress, but I'd like to get as wide a coverage as possible. I'd also like to discontinue the 4.0 source tree. All future Trumpet Winsock enhancements will be made to the 4.1 beta tree. I have designed it so that the IPv6 stuff can be completely compiled out should there be a problem. Trumpet Winsock beta testers... please check that I haven't broken any of the IPv4 functionality. There was a bit of radical surgery required to graft in the IPv6 support. It is basically 4.0C with IPv6 enhancements. Note: The IPv6 support is only for those who can make reasonable use of it. You will either have to have an IPv6 enabled network or apply for your site to be hooked to the 6bone. Until widespread deployment happens, availability of IPv6 connectivity may be patchy. You can find more about the 6bone at http://www.6bone.net. There is a readme which provides additional information about the enhancements. Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. From stephenb@uk.uu.net Thu Sep 10 13:33:57 1998 From: stephenb@uk.uu.net (Stephen Burley) Date: Thu, 10 Sep 1998 13:33:57 +0100 (BST) Subject: Can some one bring me up to speed? Message-ID: Hi I am interested in the "AAAA"/"A6" thread which is not on the web site archive yet could someone please bring me up to speed as to the current thoughts? Stephen Burley  Senior HOSTMASTER for UUNET(UK) Internet House 332 Science Park, Milton Rd. Cambridge CB4 4BZ http://www.uk.uu.net Todays weirdness is tomorrows reasons why. From rlfink@lbl.gov Thu Sep 10 17:42:42 1998 From: rlfink@lbl.gov (Bob Fink) Date: Thu, 10 Sep 1998 09:42:42 -0700 Subject: Can some one bring me up to speed? In-Reply-To: Message-ID: <1306701932-118740060@cnrmail.lbl.gov> Stephen, At 01:33 PM 9/10/98 +0100, Stephen Burley wrote: >Hi > I am interested in the "AAAA"/"A6" thread which is not on the web site >archive yet could someone please bring me up to speed as to the current >thoughts? Here is the best I can do easily (note it's on ngtrans not the 6bone). Bob >Date: Wed, 09 Sep 1998 10:36:41 +0200 >To: ngtrans@sunroof.Eng.Sun.COM >From: Harald Tveit Alvestrand >Subject: (ngtrans) Possible AAAA Record Transition Strategies > >OK, now we're settled (I think): > > >- The One True Draft is draft-ietf-ipngwg-dns-lookups-01.txt >- The One True Record Type is "A6" >- The IPNG WG has agreement that they want "A6" to be deployed. > > >Now it's a transition issue. > > >QUESTION 1: What is the current state? > > >- Fact: AAAA records exist. >- Possibility 1: Deployed code that uses AAAA only exists, and is >prohibitively > expensive to update >- Possibility 2: Deployed code that uses AAAA only exists, but can be > updated at reasonable cost to A6 given enough time > > >QUESTION 2: What is the desired final state? > > >- Possibility 1: Only A6 records exist in the DNS >- Possibility 2: Some sites have A6 records, some sites have AAAA records >- Possibility 3: Some sites have A6 records, all sites have AAAA records >- Possibility 4: All sites have A6 records, some sites have AAAA records > > >I sure hope we're not aiming for 2..... > > >QUESTION 3: What are the intermediate states between now and the final state? > > >No suggestions. > > > Harald A > > >-- >Harald Tveit Alvestrand, Maxware, Norway >Harald.Alvestrand@maxware.no From rlfink@lbl.gov Thu Sep 10 18:31:03 1998 From: rlfink@lbl.gov (Bob Fink) Date: Thu, 10 Sep 1998 10:31:03 -0700 Subject: GSE, future of Ipv6 In-Reply-To: <3c41t4c$1f0@jimmy.trumpet.com.au> Message-ID: <1306699032-118914534@cnrmail.lbl.gov> Peter, At 10:46 AM 9/10/98 +1100, Peter R. Tattam wrote: >I had a read of draft-ietf-ipngwg-esd-analysis-02 last night with some >interest. > >I have also browsed some of the more recent drafts if IPv6, and have noticed a >trend towards the concepts of GSE - am I right? > >A few comments... > >1) It is quite a paradigm shift, and takes a little bit of thought to grasp >the full issues, although if it could established, I can see some clear >benefit. However getting the rest of the world to agree on the paradigm shift >might set the development of IPv6 back a few more years. > >2) As I need to plan future development of our products, having a clear >direction of what has to happen vs what would be nice to happen are needed to >make decisions on that future development. > >3) What are going to be the trends of global routing over the next year or so. > >4) Is the paradigm shift needed yet, and will it's implementation slow down >the rolling out of IPv6? GSE/ESD (previsously known as 8+8) is an older work that is documented because of it's useful background info (we hope to turn it into an Info RFC so it doesn't get lost). The Aggregatable Unicast Address structure is partly the result of this work and much evolving thought. So I would suggest looking at: ftp://ftp.isi.edu/in-notes/rfc2374.txt Aggregatable addressing http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-tla-assignment-05.txt TLA/NLA rules http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-04.txt Router Renumbering and then ask some specific questions. If I've missed your question, please say so. Thanks, Bob From brianw@unidec.co.uk Thu Sep 10 20:15:05 1998 From: brianw@unidec.co.uk (Brian Williams) Date: Thu, 10 Sep 1998 20:15:05 +0100 Subject: Coming Back Message-ID: <90CFA4E30D16D01189560000F83047E704DF65@alpha1.unidec.co.uk> Hi Guys, I have been out of the 6bone and IPV6 for about 8-10 months due to personal problems, I need to get back on top of things, anyone care to help out. I need a new tunnel and all the information on the development of routing policies and border gateway control. Thanks in advance Brian From rlfink@lbl.gov Tue Sep 15 01:38:56 1998 From: rlfink@lbl.gov (Bob Fink) Date: Mon, 14 Sep 1998 17:38:56 -0700 Subject: new site AMS-IX as 6bone pTLA 3FFE:3000::/24 Message-ID: <1306327759-141249126@cnrmail.lbl.gov> 6bone Folk, I have added the new site AMS-IX as pTLA 3FFE:3000::/24: http://www.isi.edu/cgi-bin/davidk/whois.pl?ams-ix I have done this without the usual 2-week review cycle as it didn't quite fit the normal process,and they are certainly ready and qualified. AMS-IX will be a native IPv6 Exchange and has SURFnet, AT&T, UUnet-NL, and Cistron as their first participants. After they get it going, and we have the Sub-TLA assignments coming out of the registries, they would be one of the first candidates to provide a real service. So, welcome to AMS-IX! Bob === At 11:53 PM 9/9/98 +0200, Henk Steenman wrote: >Bob, > >On behalf of the Amsterdam Internet Exchange (AMS-IX, >http://www.ams-ix.net/ ) I have the following request. > >In Amsterdam (The Netherlands) we are currently starting an experiment with >a native IPv6 Internet Exchange. The IPv6 based Exchange will be >implemented on the current production platform of the AMS-IX but will be >defined in a different VLan in order not to disturb any production traffic. >The Initial parties involved in the experiment are: > SURFnet, AT&T, UUnet-NL, Cistron >After a start-up period the experiment will be opened up for more. >Part (large) of the experiment will involve different addressing structures >and one of the more interesting ones will involve the issue of a pTLA for >the exchange itself, pNLA's of this pTLA for the AMS-IX connected parties >and routing of the AMS-IX pTLA by several transit providers. >To be able to implement this, we would like to get a 6Bone pTLA for the >AMS-IX. > >Regards. > >- Henk > >Henk Steenman Telephone: + 31 20 4097 656 >Internetworking Architect Fax: + 31 20 4531 574 >AT&T, ICoE >e-mail:Henk.Steenman@icoe.att.com > -end From bmanning@ISI.EDU Tue Sep 15 02:38:51 1998 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 14 Sep 1998 18:38:51 -0700 (PDT) Subject: new site AMS-IX as 6bone pTLA 3FFE:3000::/24 In-Reply-To: <1306327759-141249126@cnrmail.lbl.gov> from "Bob Fink" at Sep 14, 98 05:38:56 pm Message-ID: <199809150138.SAA29405@zephyr.isi.edu> > > 6bone Folk, > > I have added the new site AMS-IX as pTLA 3FFE:3000::/24: > > http://www.isi.edu/cgi-bin/davidk/whois.pl?ams-ix > > I have done this without the usual 2-week review cycle as it didn't quite fit the normal process,and they are certainly ready and qualified. AMS-IX will be a native IPv6 Exchange and has SURFnet, AT&T, UUnet-NL, and Cistron as their first participants. > > After they get it going, and we have the Sub-TLA assignments coming out of the registries, they would be one of the first candidates to provide a real service. > Actually, that would be the second LAP was/is the first. I should have that part of the 6bone core back online within the next few hours. > So, welcome to AMS-IX! > > > Bob > > > === > At 11:53 PM 9/9/98 +0200, Henk Steenman wrote: > >Bob, > > > >On behalf of the Amsterdam Internet Exchange (AMS-IX, > >http://www.ams-ix.net/ ) I have the following request. > > > >In Amsterdam (The Netherlands) we are currently starting an experiment with > >a native IPv6 Internet Exchange. The IPv6 based Exchange will be > >implemented on the current production platform of the AMS-IX but will be > >defined in a different VLan in order not to disturb any production traffic. > >The Initial parties involved in the experiment are: > > SURFnet, AT&T, UUnet-NL, Cistron > >After a start-up period the experiment will be opened up for more. > >Part (large) of the experiment will involve different addressing structures > >and one of the more interesting ones will involve the issue of a pTLA for > >the exchange itself, pNLA's of this pTLA for the AMS-IX connected parties > >and routing of the AMS-IX pTLA by several transit providers. > >To be able to implement this, we would like to get a 6Bone pTLA for the > >AMS-IX. > > > >Regards. > > > >- Henk > > > >Henk Steenman Telephone: + 31 20 4097 656 > >Internetworking Architect Fax: + 31 20 4531 574 > >AT&T, ICoE > >e-mail:Henk.Steenman@icoe.att.com > > > -end > -- --bill From stuart@tech.org Tue Sep 15 06:31:43 1998 From: stuart@tech.org (Stephen Stuart) Date: Mon, 14 Sep 1998 22:31:43 -0700 Subject: new site AMS-IX as 6bone pTLA 3FFE:3000::/24 In-Reply-To: Your message of "Mon, 14 Sep 1998 18:38:51 PDT." <199809150138.SAA29405@zephyr.isi.edu> Message-ID: <199809150531.WAA17383@center.tech.org> > Actually, that would be the second LAP was/is the first. > I should have that part of the 6bone core back online within > the next few hours. Or third, if you consider the native IPv6 IX set up at the Palo Alto Internet Exchange way back when (addressed using part of the DIGITAL-CA pTLA). Nice to see the idea catching on, though! Stephen From pete@trumpet.com.au Tue Sep 15 10:27:56 1998 From: pete@trumpet.com.au (Peter R. Tattam) Date: Tue, 15 Sep 1998 20:27:56 +1100 Subject: Progress noted, PPP question, Stateless config question. Message-ID: <3cvuirp$1f2@jimmy.trumpet.com.au> In article <199809150531.WAA17383@center.tech.org> Stephen Stuart writes:>To: Bill Manning >cc: rlfink@lbl.gov (Bob Fink), 6bone@ISI.EDU >Subject: Re: new site AMS-IX as 6bone pTLA 3FFE:3000::/24 >Date: Mon, 14 Sep 1998 22:31:43 -0700 >From: Stephen Stuart >> Actually, that would be the second LAP was/is the first. >> I should have that part of the 6bone core back online within >> the next few hours. >Or third, if you consider the native IPv6 IX set up at the Palo Alto >Internet Exchange way back when (addressed using part of the >DIGITAL-CA pTLA). >Nice to see the idea catching on, though! >Stephen Sounds good. I've got Auto Address Configuration working now. PPP to come soon when I can figure out what I'm supposed to do about compression. Peter From rrockell@sprint.net Tue Sep 15 21:39:29 1998 From: rrockell@sprint.net (Robert Rockell) Date: Tue, 15 Sep 1998 16:39:29 -0400 (EDT) Subject: IPV6 question (fwd) Message-ID: noticed some strange routes today when grooming my routing table. Anyone know if there is a special delegation I don't know about? AS Paths removed in case it was a downstream/peer mistake: 5F00:4700::0/32 5F00:6D00::0/32 5F01:7800::0/32 5F04:C500:CB26:1100::0/64 5F0B:4F00::0/32 5F0D:E900:CE9C:9400::0/64 5F0F:8800::0/32 5F10:8800::0/32 5F11:D000:CCA2:E400::0/64 These appear to be only coming from you. I must be behind on my ipv6 delegation, because I can't recall what 5f00::/8 is doing on the backbone. (comign from cisco mostly???) If you could refresh my memory, I would most appreciate it,and make sure not to filter it. thanks in advance. Thanks Rob Rockell Sprintlink Internet Service Center Operations Engineering 703-689-6322 1-800-724-3329, PIN 385-8833 From rrockell@sprint.net Tue Sep 15 22:51:39 1998 From: rrockell@sprint.net (Robert Rockell) Date: Tue, 15 Sep 1998 17:51:39 -0400 (EDT) Subject: IPV6 question (fwd) In-Reply-To: Message-ID: My bad. Thanks for all the quick replies. Too used to seeing 3ffe's... Thanks Rob Rockell Sprintlink Internet Service Center Operations Engineering 703-689-6322 1-800-724-3329, PIN 385-8833 On Tue, 15 Sep 1998, Robert Rockell wrote: ->noticed some strange routes today when grooming my routing table. Anyone know ->if there is a special delegation I don't know about? -> ->AS Paths removed in case it was a downstream/peer mistake: -> ->5F00:4700::0/32 -> 5F00:6D00::0/32 -> 5F01:7800::0/32 -> 5F04:C500:CB26:1100::0/64 -> 5F0B:4F00::0/32 -> 5F0D:E900:CE9C:9400::0/64 -> 5F0F:8800::0/32 -> 5F10:8800::0/32 -> 5F11:D000:CCA2:E400::0/64 -> ->These appear to be only coming from you. I must be behind on my ipv6 delegation, ->because I can't recall what 5f00::/8 is doing on the backbone. (comign from cisco ->mostly???) If you could refresh my memory, I would most appreciate it,and make ->sure not to filter it. -> ->thanks in advance. -> -> ->Thanks ->Rob Rockell ->Sprintlink Internet Service Center ->Operations Engineering ->703-689-6322 ->1-800-724-3329, PIN 385-8833 -> -> From bmanning@ISI.EDU Wed Sep 16 01:08:38 1998 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Tue, 15 Sep 1998 17:08:38 -0700 (PDT) Subject: IPV6 question (fwd) In-Reply-To: from "Robert Rockell" at Sep 15, 98 04:39:29 pm Message-ID: <199809160008.AA12074@zed.isi.edu> The IPv6 address space has had a number of proposed addressing formats. This was one of them. It has been deemed "historic" but it works fine. The Current format looks like it will be "historic" RSN. > > noticed some strange routes today when grooming my routing table. Anyone know > if there is a special delegation I don't know about? > > AS Paths removed in case it was a downstream/peer mistake: > > 5F00:4700::0/32 > 5F00:6D00::0/32 > 5F01:7800::0/32 > 5F04:C500:CB26:1100::0/64 > 5F0B:4F00::0/32 > 5F0D:E900:CE9C:9400::0/64 > 5F0F:8800::0/32 > 5F10:8800::0/32 > 5F11:D000:CCA2:E400::0/64 > > These appear to be only coming from you. I must be behind on my ipv6 delegation, > because I can't recall what 5f00::/8 is doing on the backbone. (comign from cisco > mostly???) If you could refresh my memory, I would most appreciate it,and make > sure not to filter it. > > thanks in advance. > > > Thanks > Rob Rockell > Sprintlink Internet Service Center > Operations Engineering > 703-689-6322 > 1-800-724-3329, PIN 385-8833 > > > -- --bill From pete@trumpet.com.au Wed Sep 16 15:39:21 1998 From: pete@trumpet.com.au (Peter R. Tattam) Date: Thu, 17 Sep 1998 01:39:21 +1100 Subject: Trumpet Winsock 4.1 IPv6 (Beta 2) available. Message-ID: <3cop9et$1f8@jimmy.trumpet.com.au> This is the next installment. Added in this release - Stateless Address Autoconfig. - Default Router discovery and auto address prefixing. - Basic IPv6 over PPP. (no compression yet) Fixed in this release - Parsing and display of IPv4 compatible addresses. Location: ftp://ftp.trumpet.com/winsock/beta-4.1/twsk41b2.exe USA or ftp://ftp.trumpet.com.au/winsock/beta-4.1/twsk41b2.exe AUS Enjoy!!! Peter -- Peter R. Tattam - Managing Director Trumpet Software International Pty Ltd. Phone: +61-3-6245-0220 Fax: +61-3-6245-0210 From rlfink@lbl.gov Wed Sep 16 18:02:41 1998 From: rlfink@lbl.gov (Bob Fink) Date: Wed, 16 Sep 1998 10:02:41 -0700 Subject: RCCN added as 6bone pTLA 3FFE:3100::/24 Message-ID: <1306182335-149997545@cnrmail.lbl.gov> 6bone Folk, The RCCN pTLA request has gone thru its 2-week posting and review so I have assigned it pTLA 3FFE:3100::/24. http://www.isi.edu/cgi-bin/davidk/whois.pl?RCCN Welcome to RCCN on the 6bone backbone! Thanks, Bob From Niels.Baggesen@uni-c.dk Fri Sep 18 12:40:36 1998 From: Niels.Baggesen@uni-c.dk (Niels Baggesen) Date: Fri, 18 Sep 1998 13:40:36 +0200 Subject: IPv6 / RSVP enabled versions of vic/vat Message-ID: <19980918134036.A22231@mediator.uni-c.dk> We are currently gearing up for experiments with IPv6 multicasting and RSVP. To get some applications for this, vic and vat of course springs to mind, and the question is therefore: who has done this before? I currently have vic with RSVP from ISI, and sdr/vat with IPv6 from UCLA, and would like to create the double: vic and vat, both with IPv6 and RSVP, but the question is: has anybody else done this? The second question is: how far are these versions from "current" vic and vat? The sdr, at least, is rather old. And my feeling is that the Win95 versions are somewhat different. Who (has/is willing to give) the source? /Niels -- Niels Baggesen, UNI-C, Olof Palmes Alle 38, DK-8200 Aarhus N, Denmark Email: Niels.Baggesen@uni-c.dk Tel: +45 89 37 66 69 Fax: +45 89 37 66 77 --- Never underestimate the bandwidth of a CD flying through the lab --- From richterr@reed.edu Mon Sep 21 06:53:50 1998 From: richterr@reed.edu (Ryan H Richter) Date: Sun, 20 Sep 1998 22:53:50 -0700 (PDT) Subject: Reed College on 6bone Message-ID: I'm Ryan Richter from Reed College in Portland, OR. We want to get connected to and play around with the 6bone, and I want to know if anyone can recommend a pTLA. Our ISP is NWNet, which is apparently on the 6bone, and I emailed their person listed in the RIPE database 2 weeks ago and have received no response. Any suggestions would be appreciated. Ryan From rlfink@lbl.gov Mon Sep 21 16:57:33 1998 From: rlfink@lbl.gov (Bob Fink) Date: Mon, 21 Sep 1998 08:57:33 -0700 Subject: Minutes of NGTRANS WG Meeting - 25 August 1998 - Chicago IETF Message-ID: <1305754241-175750388@cnrmail.lbl.gov> ngtrans Folk: I've added some detail to the previously distributed summary and forwarded it on to the Secretariat. Bob === Minutes 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 from -00 to -01 for the "IPv6 Transitions Mechanisms" draft for advancement to replace RFC 1933: * Clarified that configured tunnels are unidirectional * Clarified that IPv4-compatibleaddresses areassigned exclusively to nodes that support automatic tunnels,i.e., that can receive such packets * Added tect about formation of link-local addresses and non-use of ND: Zero padding IPv4 address to form 64 bit token, ND and DAD can not be used on unidirectional tunnels, and a bidirectional tunnel should accept and respond to NUD. * Added restriction that decapsulated packets not be forwarded unless source address is acceptable to the decapsulating router (decapsulate and forward without such checks circumvents ingress filtering) He also replayed previous changes made from RFC 1933 to draft -00: * Deleted section on "compatible" IPv4 loopback address (::127.0.0.1) to not require routers to filter that address * Removed the use of IPv6 "raw form" when sending to IPv4-compatible on-link destinations * Revised DNS section to clarify resolver filtering and ordering options * Made the IPv4-compatible addresses only apply to automatic tunneling * Changed the term "IPv6-only addresses" to "IPv6-native address" per current usage * Changed minimum MTU to 1280 bytes * Revised IPv4-compatible address configuration section (5.2) to recognize multiple interfaces * Added discussion ofsource address selection when using IPv4-compatible addresses * Added section on the combination of the default tunneling technique with hosts using automatic tunneling * Added prohibition against automatic tunneling to IPv4 broadcast or multicast destinations He also presented a few remaining issues to be resolved on the mailing list: * Disallow the (asymmetric) use of default configured tunneling in one direction and automatic tunneling in the reverse direction? * Create a DHCPv4 option for configuring the tunnel destination for default configured tunnels? * Require that configured tunnels be biderectional?: Routing protocols need bidirectional,makes ingress filtering easy, but different than tunnels over IPv6 * Require nodes to respond to NUD probes on bidirectional configured tunnels? * Require nodes to send NUD probes on bidirectional configured tunnels? (Omitted for roputer-router links as specified in RFC 1970) 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 from draft -01 to-02 for the "Stateless IP/ICMP Translator (SIIT)" draft for advancement to Experimental RFC: * Clarified generating ICMP "TTL exceeded" when TTL or hoplimit reaches zero * Added 1-1 mapping between IPv4 TOS and IPv6 Traffic Class * Clarified that IPv4-mapped addresses are sent over wire * Introduced the notion of IPv4-translated addresses separate from IPv4-mapped and IPv4-compatible addresses: 0000:0000:0000:0000:FFFF:0000:(IPv4 address) IPv4-compatible: IPv6/IPv4 node that supports automatic tunneling IPv4-mapped: IPv4 node IPv4-translated: IPv6 node Example: IPv6 IPv4 src ::ffff:0:129.0.0.1 src 129.0.0.1 dst ::0:ffff:192.2.2.2 dst 192.2.2.2 * Acquiring IPv4-translatable addresses out of scope A working group last call for comments will now be made to send this in for processing as Experimental. George Tsirtsis presented recent changes from draft -01 to-02 for the "Network Address Translation-Protocol Translation (NAT-PT)" draft for advancement to Experimental RFC. * Various editorial changes * Dropped collocated DNS/NAT section * Added Applicability statement * Added section on the impact of DNS-ALG to DNS-SEC He then discussed several aspects of this proposal: * Protocol Translation Limitations * Impact of address translation - ALGs will be required for certain applications that refer hosts by their IP addresses in payload * Security between IPv6 and IPv4 - IPsec does not work across routing realms * Impact of DNS-ALG on DNS-SEC - DNS traffic across the DNS-ALG can not be signed! 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. This draft represents the collective experience of 6bone participants and lists best practice when operating over the 6bone between leaf and transit/backbone sites. Kazuaki Tsuchiya presented the Hitachi protocol exchange software for Windows95/98/NT4 systems based on the previous draft . This software is available now for use at . The draft of this work should move forward through ngtrans to Experimental RFC. (Editor's note: subsequent to the meeting it was agreed that the draft would be reworked to emphasize the implementation experience relating to the mechanism previously described and to redescribe the mechanism more accurately, not as a translator but rather as a technique known commonly as "bump-in-the-stack". Also, the INET 98 "Deployment and Experiences of WIDE 6bone" URL was supplied for more details on the various WIDE project's translators .) David Kessens and Bob Fink gave a brief review of the status of the 6bone. There are now 302 sites (was 240 last time) in 35 countries (was 32 last time) participating in the 6bone. There are now 47 backbone sites. There are currently about 1500 queries and 7 updates per day to the registry. 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 for more information. Ivano Guardini, of CSELT/IT, presented his new ASpath-tree tool features for monitoring BGP4+ routing inside the 6bone. These tools are up and available at . ASpath-tree is being used by CSELT to monitor their routing configuration, and is being used by several other pTLAs (ATT-LABS-EUROPE and BT-LABS) as well. Some of the ASpath-tree features are: showing the BGP4+ routing tree, the last 24 hours of routing history, changes in the routing tree, the odd routes report and the routing stability report. 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 . His talk is available at . Negotiated Address Reuse proposes a border device that does allow end-to-end traffic like IPSEC, IP tunnels (including Mobile IP and GRE tunnels) and QOS. It does this by extending and complementing NAT and by introducing a control mechanism based on SOCKS. 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 Robert L. Fink Lawrence Berkeley National Laboratory 1 Cyclotron Road Bldg. 50A, Room 3139 Berkeley, CA 94720 +1 510 486-5692 office +1 510 486-4790 fax rlfink@lbl.gov From rlfink@lbl.gov Sun Sep 27 00:07:59 1998 From: rlfink@lbl.gov (Bob Fink) Date: Sat, 26 Sep 1998 16:07:59 -0700 Subject: draft-harrington-ngtrans-dhcp-option-01.txt In-Reply-To: Message-ID: <1305296416-203292290@cnrmail.lbl.gov> Ralph, At 08:04 AM 9/26/98 -0400, Ralph Droms wrote: >I recently conducted a review IANA list of the assigned DHCP option codes, >and found that option code 96 has been assigned to Dan Harrington for use >in an "IPv6 Transition" option. Since that assignment, the Internet Draft >defining the option has expired and there has been no request submitted to >the DHC WG to consider the definition of the "IPv6 Transition" option as a >standard. I contacted Dan about the option and he told me that he is no >longer interested in pushing the "IPv6 Transition" option through the >standards process. Does the ngtrans working group have any interest in the >"IPv6 Transition" option at this point? If so, I'd like to work with you >to move the option through the standards process; if you're not using the >option code, it can be >officially returned to the IANA for reassignment. I don't think ngtrans has an interest in this, but am not sure, so am posting your request to the various IPng related lists for comment. I suggest we wait a week, then officially return the option code if we hear nothing to the contrary. Bob From Wojciech.Gawlik@idi.ntnu.no Tue Sep 29 10:31:54 1998 From: Wojciech.Gawlik@idi.ntnu.no (Wojciech Gawlik) Date: Tue, 29 Sep 1998 11:31:54 +0200 Subject: undefined reference to 'dn_expand' Message-ID: <3610A90A.7066C2A3@idi.ntnu.no> I installed kernel for IPv6 version 2.1.112, and then inet6-apps-0.34. But I can't install net-tools-1.45. Do I need different headers? I got this message when compiling net-tools /usr/inet6/lib/libinet6.a(getaddrinfo.o): In function `resolver_lookup_addr': /usr/src/inet6-apps-0.34/lib/getaddrinfo.c:365: undefined reference to `res_search' /usr/src/inet6-apps-0.34/lib/getaddrinfo.c:399: undefined reference to `dn_expand' /usr/src/inet6-apps-0.34/lib/getaddrinfo.c:413: undefined reference to `dn_expand' /usr/inet6/lib/libinet6.a(getnameinfo.o): In function `resolver_lookup_name': /usr/src/inet6-apps-0.34/lib/getnameinfo.c:125: undefined reference to `res_search' /usr/src/inet6-apps-0.34/lib/getnameinfo.c:155: undefined reference to `dn_expand' /usr/src/inet6-apps-0.34/lib/getnameinfo.c:169: undefined reference to `dn_expand' /usr/src/inet6-apps-0.34/lib/getnameinfo.c:188: undefined reference to `dn_expand' make: *** [ifconfig] Error 1 From Wojciech.Gawlik@idi.ntnu.no Tue Sep 29 11:58:31 1998 From: Wojciech.Gawlik@idi.ntnu.no (Wojciech Gawlik) Date: Tue, 29 Sep 1998 12:58:31 +0200 Subject: radvd-0.4.2 Message-ID: <3610BD57.3CB5342A@idi.ntnu.no> when I was compiling radvd-0.4.2 I got error like this device.c: In function `setup_allrouters_membership': device.c:163: structure has no member named `ipv6mr_ifindex' device.c:166: structure has no member named `s6_addr32' device.c:167: structure has no member named `s6_addr32' make: *** [device.o] Error 1 help me please.