From DRN8937@ritvax.isc.rit.edu Mon Jan 5 20:53:19 1998 From: DRN8937@ritvax.isc.rit.edu (Darrell Newcomb) Date: Mon, 05 Jan 1998 15:53:19 -0500 (EST) Subject: RFC1883 and ipv6 spec v2 Message-ID: <01IS0V1UTIKYAPTW3A@ritvax.isc.rit.edu> Upon reading both Flow Label sections from RFC 1883 and draft-ietf-ipngwg-ipv6-spec-v2-01.txt I wonder about a few points. 1) From my understanding the Flow Labels, once assigned by the originating node, will remain the same. This represents a very interesting problem for backbone routers, 20-bit's is not very much address space and a backbone router could foreseeably encounter two Flow Labels equal randomly generated by two different hosts. Upon discussing this with a friend. We decided that if the label is changed by the router after each hop, that the 20-bits for the label would be enough. Providing (number of routers)^20th or even more if the Flow Label Table was done on a per interface basis. 2) A rogue user could easily setup millions of flows to use up this space. 3) Is the Flow Label supposed to be used in conjuction with the Hop-by-Hop routing options? Thanks, Darrell Newcomb From dykang@snad.ncsl.nist.gov Mon Jan 5 22:14:14 1998 From: dykang@snad.ncsl.nist.gov (Deukyoon Kang) Date: Mon, 05 Jan 1998 17:14:14 -0500 Subject: RFC1883 and ipv6 spec v2 Message-ID: <3.0.32.19980105171413.007b33c0@snad.ncsl.nist.gov> At 03:53 PM 1/5/98 -0500, you wrote: >Upon reading both Flow Label sections from RFC 1883 and >draft-ietf-ipngwg-ipv6-spec-v2-01.txt I wonder about a few points. > >1) From my understanding the Flow Labels, once assigned by the originating >node, will remain the same. This represents a very interesting problem for >backbone routers, 20-bit's is not very much address space and a backbone router >could foreseeably encounter two Flow Labels equal randomly generated by two >different hosts. > >Upon discussing this with a friend. We decided that if the label is changed by >the router after each hop, that the 20-bits for the label would be enough. >Providing (number of routers)^20th or even more if the Flow Label Table was >done on a per interface basis. > >2) A rogue user could easily setup millions of flows to use up this space. > >3) Is the Flow Label supposed to be used in conjuction with the Hop-by-Hop >routing options? > >Thanks, Darrell Newcomb > > 1) from my understanding, the flow labels shall remain the same from a source node to a destination. yes, there's possiblity that two flows from different hosts may be assigned the same flow labels. however, note that a flow is identified uniquely by the combination of its source address and flow label. the idea of you and your friend was implemented in ATM switching. but it requires either manual configuration of routers on the path from a source to a destination or a signalling protocol. i guess that ipv6 desingers hated both of ways. :) 2) yes. it's a possible scenario. but that kind of abnormal users could be easily(?) tracked down if some security mechanism is enforced for the use of the flow labels such as IP authentication header. 3) yes or not. it's up to you. deukyoon. From deering@cisco.com Mon Jan 5 22:43:50 1998 From: deering@cisco.com (Steve Deering) Date: Mon, 5 Jan 1998 14:43:50 -0800 Subject: RFC1883 and ipv6 spec v2 In-Reply-To: <01IS0V1UTIKYAPTW3A@ritvax.isc.rit.edu> Message-ID: At 12:53 PM -0800 1/5/98, Darrell Newcomb wrote: > 1) From my understanding the Flow Labels, once assigned by the originating > node, will remain the same. This represents a very interesting problem for > backbone routers, 20-bit's is not very much address space and a backbone > router could foreseeably encounter two Flow Labels equal randomly generated > by two different hosts. The intent is that routers identify flows by the concatenation of the source address and the flow label, not by the flow label alone. The requirement for random selection of flow labels by source nodes is *not* to avoid duplicate flow labels, but rather to allow any subset of the bits of a flow label to serve as a pre-computed hash key for more efficient look-up of the set of possible matching flows. > Upon discussing this with a friend. We decided that if the label is changed > by the router after each hop, that the 20-bits for the label would be >enough. > Providing (number of routers)^20th or even more if the Flow Label Table was > done on a per interface basis. Yes, there has been some sporadic discussion in the past about redefining some or all of the flow label space to be used in a hop-by-hop manner, rather than end-to-end, but the only written-down proposal for such a change expired from the internet-drafts directories a long time ago. If the WG receives a solid proposal for a change of flow label semantics (including addressing the problem of flow-label allocation to multicast flows across multi-access links), we will give it serious consideration. The weasel words at the beginning of the Flow Labels section of the IPv6 spec are intended to leave open the possiblity of such changes. > 3) Is the Flow Label supposed to be used in conjuction with the Hop-by-Hop > routing options? The Flow Label is intended to be used with or without any extensions headers. (However, there aren't any "Hop-by-Hop routing options" defined at present; the Routing header is not a Hop-by-Hop option.) Steve From bmanning@ISI.EDU Tue Jan 6 19:21:06 1998 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Tue, 6 Jan 1998 11:21:06 -0800 (PST) Subject: day minus one Message-ID: <199801061921.AA15813@zed.isi.edu> >So list members, here is one more chance to voice your concerns >over a policy issue. Please let me (not the list) know if you >would like me to remove the current restriction on posting. > >The 6bone list has been moved to majordomo. >The "normal" configuration here is to restrict >postings to list members. One group (WIDE) is >asking for that restriction to be removed. > >You have three choices: > > Yes - remove the restriction > No - keep the restriction > No Response - Keep the restriction. > >There are 877 subscribers to this list. I'll take comments/votes >for the next two weeks and will post the results (and make the changes, if any) >to the list on 06 Jan 1998. I would like at least a 10% response. ------------------------------------------------------ 51 votes to retain the members-only restriction 10 votes to remove the members-only restriction 2 of the yes votes were conditional, to remove the restriction only until we can agree on a way to handle exception lists, then re-instate the members only restriction One yes and one no vote asked for how much non-list releated mail had been blocked. The answer is 6 postings since the restriction was placed in early december of 1997. Four folks indicated that there might be fairly easy ways to include an exception list. My concern with this is that if I do this for WIDE, I'll be asked to do it for other groups as well. If I do implement an exception list, it will be a single list that all groups will be added to. For now, I'll leave the list restricted to members-only for posting while I review how to add exception list processing. -- "When in doubt, Twirl..." -anon From RLFink@lbl.gov Tue Jan 6 21:50:44 1998 From: RLFink@lbl.gov (Bob Fink) Date: Tue, 6 Jan 1998 13:50:44 -0800 Subject: day minus one In-Reply-To: <199801061921.AA15813@zed.isi.edu> Message-ID: Bill, Thanks for taking the time to take a vote, and to look into the exception list issue. Yet again, it's hard working volunteers that make the Internet what it is :-) Thanks, Bob ===================================================== At 11:21 AM -0800 1/6/98, bmanning@ISI.EDU wrote: >>So list members, here is one more chance to voice your concerns >>over a policy issue. Please let me (not the list) know if you >>would like me to remove the current restriction on posting. >> >>The 6bone list has been moved to majordomo. >>The "normal" configuration here is to restrict >>postings to list members. One group (WIDE) is >>asking for that restriction to be removed. >> >>You have three choices: >> >> Yes - remove the restriction >> No - keep the restriction >> No Response - Keep the restriction. >> >>There are 877 subscribers to this list. I'll take comments/votes >>for the next two weeks and will post the results (and make the changes, >>if any) >>to the list on 06 Jan 1998. I would like at least a 10% response. > >------------------------------------------------------ > >51 votes to retain the members-only restriction >10 votes to remove the members-only restriction > >2 of the yes votes were conditional, to remove the restriction >only until we can agree on a way to handle exception lists, then >re-instate the members only restriction > >One yes and one no vote asked for how much non-list releated >mail had been blocked. The answer is 6 postings since the >restriction was placed in early december of 1997. > >Four folks indicated that there might be fairly easy ways >to include an exception list. My concern with this is >that if I do this for WIDE, I'll be asked to do it for >other groups as well. If I do implement an exception list, >it will be a single list that all groups will be added to. > >For now, I'll leave the list restricted to members-only for >posting while I review how to add exception list processing. > >-- >"When in doubt, Twirl..." -anon From gavin@london.virgin.net Wed Jan 7 11:07:20 1998 From: gavin@london.virgin.net (Gavin Starks) Date: Wed, 07 Jan 1998 11:07:20 +0000 Subject: admin question Message-ID: <34B361E8.63DE@london.virgin.net> Hi, Is there any chance of automatically prepending a descriptor string (e.g. [6bone]) to the subject field of postings? This would make it much more easy to identify them in high volume mailboxes... Thanks -Gavin. From erik@sockdev.uni-c.dk Wed Jan 7 14:52:02 1998 From: erik@sockdev.uni-c.dk (Erik Bertelsen) Date: Wed, 7 Jan 1998 15:52:02 +0100 (MET) Subject: admin question In-Reply-To: <34B361E8.63DE@london.virgin.net> Message-ID: On Wed, 7 Jan 1998, Gavin Starks wrote: .. Is there any chance of automatically prepending a descriptor string .. (e.g. [6bone]) to the subject field of postings? This would make it much .. more easy to identify them in high volume mailboxes... Please don't ! For all those people who filter incoming mail into different inboxes for different mailing lists (using e.g. procmail or filter), this only adds non-informative noice to the screen display. regards Erik Bertelsen, UNI-C From smurf@noris.de Wed Jan 7 15:54:28 1998 From: smurf@noris.de (Matthias Urlichs) Date: Wed, 7 Jan 1998 16:54:28 +0100 (Funky) Subject: admin question In-Reply-To: <34B361E8.63DE@london.virgin.net> from "Gavin Starks" at Jan 7, 98 11:07:20 am Message-ID: <19980107155429.25644.qmail@nova.noris.de> Hi, >Is there any chance of automatically prepending a descriptor string >(e.g. [6bone]) to the subject field of postings? This would make it much >more easy to identify them in high volume mailboxes... Please don't. The real solution is to use procmail (or similar) filtering to put the stuff into its own dedicated folder, or into an internal newsgroup. -- Matthias Urlichs noris network GmbH From gavin@london.virgin.net Wed Jan 7 19:01:32 1998 From: gavin@london.virgin.net (Gavin Starks) Date: Wed, 07 Jan 1998 19:01:32 +0000 Subject: admin question References: <19980107155429.25644.qmail@nova.noris.de> Message-ID: <34B3D10C.52BF@london.virgin.net> ok ok ok, enough already... I think I've had enough responses about this! It was only a suggestion :) -Gavin. From RLFink@lbl.gov Wed Jan 7 23:05:20 1998 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 7 Jan 1998 15:05:20 -0800 Subject: new tool prototypes -- routing/topology analysis In-Reply-To: <199712231546.KAA04910@merit.edu> Message-ID: Craig, I've added a pointer for the Merit IPMA tools page to the 6bone tools page. http://www.6bone.net/6bone_tools.html Thanks, Bob From RLFink@lbl.gov Thu Jan 8 15:09:40 1998 From: RLFink@lbl.gov (Bob Fink) Date: Thu, 8 Jan 1998 07:09:40 -0800 Subject: new tool prototypes -- routing/topology analysis In-Reply-To: <3.0.5.32.19980108093649.009a8360@penelope.et.unibw-muenchen.de> References: <199712231546.KAA04910@merit.edu> Message-ID: Peter, At 12:36 AM -0800 1/8/98, Peter Bieringer wrote: >At 15:05 07.01.98 -0800, you wrote: >>Craig, >> >>I've added a pointer for the Merit IPMA tools page to the 6bone tools page. >> >> http://www.6bone.net/6bone_tools.html > >But what's about removing following link or displaying a warning: > >Ben's IPv6 test address generation tool > Ben Kirkpatrick's tool for automatically generating an IPv6 test >addresses. > >It' a little bit out of date... I've removed the link to Ben's tool for address generation as it is still in the old format. http://www.ibs-us.net/ipv6/ipv6-addr.html Maybe he can get around to updating it, then I'll add it back in. Thanks for letting me know. Bob From jimmy.kyriannis@nyu.edu Thu Jan 8 19:37:50 1998 From: jimmy.kyriannis@nyu.edu (Jimmy Kyriannis) Date: Thu, 08 Jan 1998 14:37:50 -0500 Subject: admin question In-Reply-To: <19980107155429.25644.qmail@nova.noris.de> References: <34B361E8.63DE@london.virgin.net> Message-ID: I simply use the "Sender: owner-6bone@ISI.EDU" header to identify my 6bone mail. I use the Eudora mail client, which can filter a message based on a header (among other things) and then perform and action if that filter matches, such as filing in a specific mailbox. Other mail clients/UNIX utilities should be able to do the same. Jimmy At 10:54 AM -0500 1/7/98, Matthias Urlichs wrote: >Hi, >>Is there any chance of automatically prepending a descriptor string >>(e.g. [6bone]) to the subject field of postings? This would make it much >>more easy to identify them in high volume mailboxes... > >Please don't. The real solution is to use procmail (or similar) filtering >to put the stuff into its own dedicated folder, or into an internal >newsgroup. > >-- >Matthias Urlichs >noris network GmbH From adailton@na-cp.rnp.br Thu Jan 8 19:55:09 1998 From: adailton@na-cp.rnp.br (Adailton J. Santos Silva) Date: Thu, 8 Jan 1998 17:55:09 -0200 (EDT) Subject: Request for a pTLA ID and tunnel to 6Bone Message-ID: Hello Bob, I spoke with you about the inclusion of the Brazilian Research Network (or RNP - Rede Nacional de Pesquisa, in portuguese) in the 6Bone, during the Munich and Washington IETF meetings. The RNP (http://www.rnp.br) is a Brazilian federal governmental instituition responsible for Internet access for nationsīs universities and scientific and technological instituitions. The National Research Network (english translation) is an Internet Service Provider that manage the Brazilian Internet backbone (http://www.rnp.br/1.3.bone.html) for academical services and act as an ISP for others ISPs. The RNP wish to join to the 6Bone and start IPv6 network. As soon as possible, we intend to extend Brazilian IPv6 (Brazilian 6Bone) network to others RNP's Points of Presence. We have six E1 links to MCI/Washington, one E1 to MCI/Boston and one E1 to MCI/Florida. Now we are looking for the best peer (in Washington?) to implement our IPv6 connectivity tunnel. Are there any volunteer? Thanks in advance, Adailton Silva Brasilian Research Network Phone: +55 19 788-3210 Fax: +55 19 788-3214 E-mail: adailton@na-cp.rnp.br From MOSTHAVM@plcman.siemens.co.uk Fri Jan 9 14:39:46 1998 From: MOSTHAVM@plcman.siemens.co.uk (Mosthav, Marc (IT Man.)) Date: Fri, 9 Jan 1998 14:39:46 -0000 Subject: TCP Wrappers for IPv6 Message-ID: Hi all, I ported the package tcp wrappers 7.6 to IPv6 under Linux, in order to give me the possibility to use hosts.allow and hosts.deny. Peter Bieringer was kind enough to put it on his FTP server. It can be found at: ftp://ftp.bieringer.de/pub/linux/IPv6/tcp-wrapper/tcp_wrapper_7.6+ipv6-1 .tar.gz I hope somebody finds it usefull, but be aware, it's only a quick and dirty hack. If you find any bugs or have any ideas for improvements please let me know Regards, Marc Mosthav From MOSTHAVM@plcman.siemens.co.uk Fri Jan 9 16:48:56 1998 From: MOSTHAVM@plcman.siemens.co.uk (Mosthav, Marc (IT Man.)) Date: Fri, 9 Jan 1998 16:48:56 -0000 Subject: No subject Message-ID: Hi all, I have send this before, but my computer crashed during transmission. So just in case it got lost: I ported the package tcp wrappers 7.6 to IPv6 under Linux, in order to give me the possibility to use hosts.allow and hosts.deny. Peter Bieringer was kind enough to put it on his FTP server. It can be found at: ftp://ftp.bieringer.de/pub/linux/IPv6/tcp-wrapper/tcp_wrapper_7.6+ipv6-1 .tar.gz I hope somebody finds it usefull, but be aware, it's only a quick and dirty hack. If you find any bugs or have any ideas for improvements please let me know Regards, Marc Mosthav From bound@zk3.dec.com Sun Jan 11 17:38:56 1998 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Sun, 11 Jan 1998 12:38:56 -0500 Subject: RFC1883 and ipv6 spec v2 In-Reply-To: Your message of "Mon, 05 Jan 1998 14:43:50 PST." Message-ID: <199801111738.AA28632@wasted.zk3.dec.com> Steve, >> Upon discussing this with a friend. We decided that if the label is changed >> by the router after each hop, that the 20-bits for the label would be >>enough. >> Providing (number of routers)^20th or even more if the Flow Label Table was >> done on a per interface basis. >Yes, there has been some sporadic discussion in the past about redefining some >or all of the flow label space to be used in a hop-by-hop manner, rather than >end-to-end, but the only written-down proposal for such a change expired from >the internet-drafts directories a long time ago. If the WG receives a solid >proposal for a change of flow label semantics (including addressing the >problem of flow-label allocation to multicast flows across multi-access links), >we will give it serious consideration. The weasel words at the beginning >of the Flow Labels section of the IPv6 spec are intended to leave open the >possiblity of such changes. I think your statement here may create an objection from me regarding your base spec (RFC 1883) at last call, but let me check. For IPv6 I am assuming that we will have an end-to-end flow in the IPv6 header. Applications want this and the first use of this field has validity in RSVP for IPv6. I don't want to parse into the data portion of a UDP or TCP packet to identify the flow for many reasons and one of the drawbacks of RSVP for IPv4 and that its not part of the "standard" socket data structure. What do we need to do to guarantee the behavior of the flow label for applications. This cannot be a router / forwarding path only consideration? I would like to see this nailed down and committed to. If you want IPv6 deployed widely soon we need to start telling ISVs they can use this header field for what I speak of above, the first incantations are RSVP for IPv6 but I believe many integrated services for networking can use the field as defined now. The other input is a very serious issue I bring forth here. Most of all vendor business revenue streams are from private enterprise we coin Intranets NOT Internet. I realize the confusion at present around defining "differential services" and how "neat" it is for researchers to speculate on what it may or may not do for IPv6. But, we need to move forward with IPv6 and the Flow Label field so we can start deployment of IPv6. I would like to see these weasel words fixed one way or the other for the purposes I state above in the next version of the base spec. Maybe you clarifying where you think things are will cause a productive discussion of nailing this down. The limbo state of a critical feature of an IPv6 header part for deployment is unacceptable. And sloth on our part for not completing this attribute of IPv6. /jim From kuznet@ms2.inr.ac.ru Sun Jan 11 18:56:26 1998 From: kuznet@ms2.inr.ac.ru (A.N.Kuznetsov) Date: Sun, 11 Jan 1998 21:56:26 +0300 (MSK) Subject: RFC1883 and ipv6 spec v2 In-Reply-To: <199801111738.AA28632@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Jan 11, 98 12:38:56 pm Message-ID: <199801111856.VAA04175@ms2.inr.ac.ru> hello! > I would like to see this nailed down and committed to. Golden words! End-to-end flow label interpretation should be declared "MUST" in RFCs. Look at Cisco tag switching! They DO already assume, that they are allowed to mangle flow labels. Maybe, it should be stressed specially that if someone wants to override flow label while a packet passes through a cloud with special policy he MUST restore original value upon exiting from cloud or delivering packet to end host. Otherwise, all the concept will be useless. Alexey Kuznetsov From kuznet@ms2.inr.ac.ru Sun Jan 11 20:34:16 1998 From: kuznet@ms2.inr.ac.ru (A.N.Kuznetsov) Date: Sun, 11 Jan 1998 23:34:16 +0300 (MSK) Subject: RFC1883 and ipv6 spec v2 In-Reply-To: <199801112009.PAA01770@newdev.harvard.edu> from "Scott Bradner" at Jan 11, 98 03:09:15 pm Message-ID: <199801112034.XAA04290@ms2.inr.ac.ru> Hello! > 1/ expensive to do - gotta stick the old flow ID somewhere in the meantime Right. Hence, this practice will be automatically deprecated :-) If flow labels will loose their end-to-end meaning at least sometimes, they will be useless for rsvp. Is it correct? > 2/ the diff serv work (some of which is already being tested in the > field) may depend of the changability of some of the packet header at > cloud (e.g. ISP) borders I was not aware about diff serv work, but Cisco tag switching can be made efficiently or by link layer (ATM) or by inserting tag between ll header and network header (that is made for IPv4 in nay case). Mangling flow label is not necessary at all. Alexey Kuznetsov From brian@hursley.ibm.com Mon Jan 12 09:49:22 1998 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Mon, 12 Jan 1998 09:49:22 +0000 Subject: RFC1883 and ipv6 spec v2 References: <199801112034.XAA04290@ms2.inr.ac.ru> Message-ID: <34B9E722.29F0@hursley.ibm.com> > 2/ the diff serv work (some of which is already being tested in the > field) may depend of the changability of some of the packet header at > cloud (e.g. ISP) borders I expect that diff serv will change the traffic class byte on the fly but is unlikely to consider the flow ID at all. It's clear that there are two camps on the flow ID - those who believe it should be used for label switching, in which case it changes on the fly, and those who believe it should be an invariant. I agree we need a resolution of this but there are arguments both ways. Anybody want to do the pro/con analysis? Brian Carpenter From crawdad@fnal.gov Mon Jan 12 14:58:43 1998 From: crawdad@fnal.gov (Matt Crawford) Date: Mon, 12 Jan 1998 08:58:43 -0600 Subject: RFC1883 and ipv6 spec v2 In-Reply-To: Your message of Mon, 12 Jan 1998 09:49:22 GMT. <34B9E722.29F0@hursley.ibm.com> Message-ID: <199801121458.IAA29118@gungnir.fnal.gov> > It's clear that there are two camps on the flow ID - those who > believe it should be used for label switching, in which case > it changes on the fly, and those who believe it should be an > invariant. I agree we need a resolution of this but there are > arguments both ways. Anybody want to do the pro/con analysis? For invariant: IPv4 will be around for a long while. Using the IPv6 flow id for label switching buys nothing for IPv4. Putting the label at a lower layer (e.g., layer "2.5") works equally for all protocols. * * * Here's an efficiency hack, for free. Include a byte in the lower layer label which is initalized to the TTL or Hop Limit, decremented at each label-switched hop (by having the outgoing label have a value one less in that byte), and copied back to the TTL (with checksum update) or HL field of the header when the packet is forwarded to a non-label-switched link, or when an ICMP error is to be generated for the packet. From deering@cisco.com Mon Jan 12 15:08:16 1998 From: deering@cisco.com (Steve Deering) Date: Mon, 12 Jan 1998 07:08:16 -0800 Subject: RFC1883 and ipv6 spec v2 In-Reply-To: <34B9E722.29F0@hursley.ibm.com> References: <199801112034.XAA04290@ms2.inr.ac.ru> Message-ID: At 1:49 AM -0800 1/12/98, Brian E Carpenter wrote: > It's clear that there are two camps on the flow ID... > Anybody want to do the pro/con analysis? I'll give it a try this evening -- I'm traveling and attending meetings until then. Steve From bound@zk3.dec.com Mon Jan 12 15:26:31 1998 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 12 Jan 1998 10:26:31 -0500 Subject: RFC1883 and ipv6 spec v2 In-Reply-To: Your message of "Sun, 11 Jan 1998 15:40:15 EST." <199801112040.PAA01807@newdev.harvard.edu> Message-ID: <199801121526.AA09652@wasted.zk3.dec.com> >the basic question being addressed by the diffserv effort is the >best way to provide different qualities of Internet service in diferent >environments - RSVP is just the right answer for some types of QoS >problems but may not be the best way to deal with others. I agree. To stress my point further. I can deploy IPv6 within XYZ Motors Intranet and use RSVP and IPv6 flow label to define a QOS strategy that will permit Warren MI to Engineering Workstation running UNIX flavor "Finite Element Analysis" application to accept multiple streams a) from Arizona Test Bed and b) from Rochester Design Center at a higher priority than other packets on the XYZ private internet. The MCAD engineers packet never touches the "Internet" its pure private enterprise and this can be done with RSVP and I believe today with IPv6, if we as vendors can get some gurantee of what bits we can count on for IPv6 Flow Label. But if the MCAD engineer wants to get a part from Ireland and to do that must go through ISP and possibly over the Internet then the gurantees of RSVP may not apply and diff services need to be used. But, IMO the Flow and other parameters in the packet must be in tact when the packet is delivered to the Server or Client in Ireland for continuity and priority within that Intranet so a global network corporate policy can be maintained for that company. The ISP market will differentiate themselves IMO on who can give the best proximation of diff services to support global corporate entities between-Intranet sites. As far as TAG-SWITCHING. First I think its a really good idea. But given the mail on this list I will read their specs before as they go to last call to the IESG (as I am not on that mail list) and will raise an objection and support within the IETF if that WG attempts to step on the IPv6 Flow Label and not put it back in tact when exiting their DOI of that packet when forwarding back to the private Intranet site. Same for diff services. The legal implications of stepping on my packet must be consistent with the legal agreement I have with my ISP in entry to the Internet, or I with my ISP will have the option of using any legal means necessary to protect my privacy and right of packet containment en-pass thru the Internet. I don't think the IETF or IESG should permit alteration of packets that affect the semantics of the packet being depended on by a business, without legal council from the ISOC and in the U.S. by the DOC. All this adds up to "ergo" ----> what does the flow label constitute in IPv6?????? And possibly the entire header. IPSEC makes it even more complex, add Key Escrow and it goes over the top. It is a very slippery slope to touch packets with IETF specifications. /jim From bound@zk3.dec.com Mon Jan 12 17:11:49 1998 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 12 Jan 1998 12:11:49 -0500 Subject: Congrats to IBM - IPv6 support shipping in AIX 3.3 Message-ID: <199801121711.AA17100@wasted.zk3.dec.com> Good job IBM...another leap to get IPv6 used and deployed in the market. http://www.rs6000.ibm.com/ipv6/ /jim From pcurran@ticl.co.uk Mon Jan 12 20:50:56 1998 From: pcurran@ticl.co.uk (Peter Curran) Date: Mon, 12 Jan 1998 20:50:56 -0000 Subject: Congrats to IBM - IPv6 support shipping in AIX 3.3 Message-ID: <01bd1f9b$c7fdc190$0f0120c1@desktop.ticl.co.uk> This is a multi-part message in MIME format. ------=_NextPart_000_009B_01BD1F9B.C7B60A30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Congrats to INRIA - I thinks its their code! http://www-frec.bull.com/OSBU2_0/aixhighlight_eg.htm :-) >Good job IBM...another leap to get IPv6 used and deployed in the market. > >http://www.rs6000.ibm.com/ipv6/ > >/jim > /peter TICL/UK ------=_NextPart_000_009B_01BD1F9B.C7B60A30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII0TCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAnkwggHioAMCAQICEFIfNR3ycH4AK77KWYcE1TkwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDYyNzAwMDAwMFoXDTk5MDYyNzIz NTk1OVowYjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTQwMgYD VQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJzY3JpYmVyMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQC2FKbPTdAFDdjKI9BvqrQpkmOOLPhvltcunXZLEbE2jVfJw/0c xrr+Hgi6M8qV6r7jW80GqLd5HUQq7XPysVKDaBBwZJHXPmv5912dFEObbpdFmIFH0S3L3bty10w/ cariQPJUObwW7s987LrbP2wqsxaxhhKdrpM01bjV0Pc+qQIDAQABozMwMTAPBgNVHRMECDAGAQH/ AgEBMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAwfr3 AudXyhF1xpwM+it3T4dFFzvj0sHaD1g5jq6VmQOhqKE4/nmakxcLl4Y5x8poNGa7x4hF9sgMBe6+ lyXv4NRu5H+ddlzOfboUoq4Ln/tnW0ilZyWvGWSI9nLYKSeqNxJqsSivJ4MYZWyN7UCeTcR4qIbs 6SxQv6b5DduwpkowggQQMIIDeaADAgECAhApF9yEa2f1I6vNhJOMYHGgMA0GCSqGSIb3DQEBBAUA MGIxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMr VmVyaVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzExMjEwMDAw MDBaFw05ODAxMjAyMzU5NTlaMIIBDTERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJz Y3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4g YnkgUmVmLixMSUFCLkxURChjKTk2MScwJQYDVQQLEx5EaWdpdGFsIElEIENsYXNzIDEgLSBNaWNy b3NvZnQxFTATBgNVBAMTDFBldGVyIEN1cnJhbjEhMB8GCSqGSIb3DQEJARYScGN1cnJhbkB0aWNs LmNvLnVrMFswDQYJKoZIhvcNAQEBBQADSgAwRwJAbGS4S0SN7NX2OODlfiOves53hbLKytcxawKy ipnvwVqlHCtugU+GznF/cq3jvMQeehvX+9+lxts1Q7BXxw9QuQIDAQABo4IBXTCCAVkwCQYDVR0T BAIwADCBrwYDVR0gBIGnMIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEa PVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVy aVNpZ24AAAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2 M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2Rh NWMxZTMxNDFiZWFkYjJiZDI5YWZhMTJiZDY4OTFhMTExNDk5OGExYmE0M2Y0ZTY5MTY1NDEwDQYJ KoZIhvcNAQEEBQADgYEAUXbKrrDI9DdxdSL9W4pMtNBTZpFV9yMkBkiKdSOwdjmSh3/qPl11P/HM KDT9CtIXpeT0JcUlkZsXaGkLGZnVWHvsqjUyvqT6XOCy1Vm1VokROmbfFItKacbTwoQsArhISOYB DdUOwpZiD/HEdCTnTb4r6bC3MZ+6afsCn0zi//sxggE6MIIBNgIBATB2MGIxETAPBgNVBAcTCElu dGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3Mg MSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcgIQKRfchGtn9SOrzYSTjGBxoDAJBgUrDgMCGgUA oF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTgwMTEyMjA1MDU2 WjAjBgkqhkiG9w0BCQQxFgQUkaDw8XM+ipc6IYa8KT64PBuzkZ4wDQYJKoZIhvcNAQEBBQAEQA8l rVrIzRjyJSgFaVxnQyxkyQPiZUkytlRIdvKWqvVADffLdsQ7ryC5GIL1qMB9WtGOPBp1ybH7oEh5 HOCBZ0IAAAAAAAA= ------=_NextPart_000_009B_01BD1F9B.C7B60A30-- From bound@zk3.dec.com Tue Jan 13 02:36:20 1998 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 12 Jan 1998 21:36:20 -0500 Subject: (IPng 5136) Congrats to IBM - IPv6 support shipping in AIX 3.3 In-Reply-To: Your message of "Mon, 12 Jan 1998 12:11:49 EST." <199801121711.AA17100@wasted.zk3.dec.com> Message-ID: <199801130236.AA17185@wasted.zk3.dec.com> >Good job IBM...another leap to get IPv6 used and deployed in the market. > >http://www.rs6000.ibm.com/ipv6/ Much apologies. Its AIX 4.3. sorry, /jim From pink@fsz.bme.hu Tue Jan 13 10:01:53 1998 From: pink@fsz.bme.hu (Szabolcs Szigeti (PinkPanther)) Date: Tue, 13 Jan 1998 11:01:53 +0100 (MET) Subject: Congrats to IBM - IPv6 support shipping in AIX 3.3 In-Reply-To: <199801121711.AA17100@wasted.zk3.dec.com> Message-ID: On Mon, 12 Jan 1998 bound@zk3.dec.com wrote: > Good job IBM...another leap to get IPv6 used and deployed in the market. > > http://www.rs6000.ibm.com/ipv6/ Actually, we've just installed it yesterday, it does indeed contain IPv6. So far we haven't been able to get the steteless autoconfiguration working (router sol & adv). Which is strange, since an INRIA/FreeBSD box is the router on that segment, and works flawlessly with a Digital Unix/ipv6 implementation, but then I haven't had much time to work with it. Anyway, if someone else is playing with AIX4.3 + IPv6 i'd be happy to share any info. Regards, szabolcs -------------------------------------------------------------- | Szabolcs Szigeti | pink@fsz.bme.hu | | Electrical Engineer | http://www.fsz.bme.hu/~pink/ | | No woman, No Cray! | +3630218697 | -------------------------------------------------------------- From Alain.Durand@imag.fr Tue Jan 13 13:27:33 1998 From: Alain.Durand@imag.fr (Alain Durand) Date: Tue, 13 Jan 1998 14:27:33 +0100 Subject: 6bone backbone map Message-ID: <980113142733.ZM12252@rama.imag.fr> Happy new year to all of you. I would like to make a suggestion about the new automatic backbone map: I would like tunnels to be drawn _only_ if they are listed in _both_ site entries. I mean, if A says "I've a tunnel to B" and B says nothing about it, it sould be either a configuration mistake or an inconsistancy in the database, thus I would like nothing to be drawn on the map. Maybe, an automatic mail could be sent to site mainteners. I'm asking this because I've updated my entry months ago, I've noticed many peers about the changes in the tunnels, and those old/broken/unused tunnels are still showing on the map. - Alain. From RLFink@lbl.gov Wed Jan 14 19:37:45 1998 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 14 Jan 1998 11:37:45 -0800 Subject: minutes from ngtrans/6bone meeting in Washington DC Message-ID: Sorry to be slow in posting these...they were actually completed right after the meeting in December, but forgot to post them. Bob _____________cut here___________________________________________________________ ngtrans tools WG meeting December 9, 1997 Washington, DC IETF Bob Gilligan chair, Tony Hain reporting Discussion: ngtrans@sunroof.eng.sun.com Subscribe: majordomo@sunroof.eng.sun.com Archive: ftp://playground.sun.com/pub/ngtrans Chairs: Bob Fink rlfink@lbl.gov Robert Gilligan gilligan@freegate.net Tony Hain tonyhain@microsoft.com Updates to RFC-1933 - Bob Gilligan Updates to RFC-1933, the current Proposed standard for Transition Mechanisms, were discussed to move it to Draft status. An I-D was submitted for review at this meeting which contained, among other things, the following: Remove ::127.0.0.1 from discussion Eliminated 'raw IPv6 form' when sending IPv4 on link (implementation complexity, low gain) Added definitions for operating mode (dual stack needs to know if one is to be turned off) DNS resolver filtering/ordering options clarified IPv4 compatible used only with automatic tunneling 'v6 only' to 'v6 native' update MTU for new 1280 byte min MTU size misc. clarifications in text Needs: definition of link-local address for configured tunnels Automatic tunnel operational issues Source address selection when automatic tunnel Scope of IPv4-compatible address Steve Deering noted that use of ND over pt-to-pt links will be discussed in the IPv6 group on Thursday. Need to clearly define mechanism where configured tunnel is unidirectional with an automatic tunnel back. Issue is where to tunnel back since any router attached to v4 cloud can forward to avoid injecting v4 routing table into v6 cloud. Technique of using well-known v4 anycast as default tunnel is written up, but actual pattern not defined. Discussion diverted into should we or not, allow asymmetric use of configured and auto tunnels. Tony Hain commented that we are here to define the mechanisms, not define how they get used. Discussion about how to document injection of v4 routes or not into v6. Should be a BCP from the 6bone implementers, since it is a topic for that deployment timeframe. Bob Fink said he would handle this one in consultation with Steve Deering. Bob Gilligan will revise the document as an ID and send to the list. NNAT - Jim Bound A No NAT (NNAT) draft was presented in Munich - Jim Bound gave an overview and walkthrough of it here. An IPv4 host requests DNS lookup, where a record is set as forwarder to NNAT server which sends DHCPv6 reconfig message which hosts MUST listen to, which is a temporary v4 address which allows building v4 compatible, then the NNAT server updates DNS and responds back to original requestor. Open issues: DHCPv4 use and CNAME fix TTL cache Hybrid Stack Question Tunnels move to egress router Use of RFC 1183 records Authoritative DNS Server Response Update to lifetime for long running clients Default reassignment hold-down time NNAT name of the draft - open to discussion Concern that temporary assignment may get out of sync if host to be reconfigured is not up at the time. Since the reconfig message is Ack'd, the language will be clarified to note that the NNAT server will not complete the DNS response if the Ack doesn't happen. SIIT - Eric Nordmark SIIT is a stateless header translator. It is not a single point of failure. Assumes mechanism like NNAT for temporary v4 addr. Transport-mode ESP works Open issues: use v4 comp as address. Works as long as v6 cloud is clean. v4 traceroute NAT-PT - George Tsirtsis This is v6 to v4 NAT to connect the clouds. It is a combination of NAT in outbound direction with NNAT in inbound direction. There is aminimal use of compatible/mapped address only v6 hosts need to do anything This breaks end-to-end principle...same issues as any NAT This is a statefull version of SIIT. George will work with Eric and Jim to see if a combined document is possible. WIDE Translators - K. Tsuchiya, K. Yamamoto, T. Niinomi Three translators developed by members of the WIDE project in Japa were presented. NR60 Translator - K. Tuchiya A modified DNS, address mapper & header translator used Straight NAT using DNS as resolver in both directions Implemented all on one node FAITH - K. Yamamoto Header conversion has limitations Address conversion in legacy applications is difficult AH works when translator is trusted and rebuilds connection Socks64 - T. Niinomi No DNS modification or address mapping management Application level gateway based on Socks 5 Distributes fake v4 address for v6 end points Only modifies clients where other 2 modify infrastructure These three translators represent actual implemented work. The chairs would like to thank the Wide project members for their willingness to come a long distance to share their ideas and extensive experience, and hope that it will continue. _____________cut here___________________________________________________________ ngtrans 6bone WG meeting December 9, 10 & 11, 1997 Washington, DC IETF Bob Fink chair, Ben Crosby, ALain Durand and Bob Fink reporting Discussion: 6bone@isi.edu (6BONE Mailer) Subscribe: majordomo@isi.edu "subscribe 6bone" Archive: http://www.ipv6.nas.nasa.gov/6bone/ Chairs: Bob Fink rlfink@lbl.gov Robert Gilligan gilligan@freegate.net Tony Hain tonyhain@microsoft.com Web site: http://www.6bone.net Due to limited time in the main ngtrans session, the discussions on 6bpne routing issues were handled in two lunchtime disussions on 10/11 December. WIDE 6bone status - K. Yamamoto A brief status report of the WIDE 6bone project was given. Of special note is the broad participation of many research/educational and industry partners, and the development of many IPv6 implementations. WIDE efforts started when, on June 9 1996, NAIST and Tokyo were connected via a 64kbps circuit using v6 and then on July 16, 1996 connection was made to the 6bone. Currently 28 sites are connected to 4 backbone routers using RIPng. BGP4+ conversion is delayed until later in the month. Future plans include linking the WIDE registry to the 6bone registry, creating an IPsec testbed, and of course BGP4+. Again the Chairs want to thank the WIDE project members for sharing their extensive IPv6 experience. 6bone status - Bob Fink A brief status report of the 6bone and the backbone conversion project was given. 206 sites, 30 countries 14 hosts & 13 router implementations (probably more at this time) 42 sites using aggregation address format auto address delegation done via registry auto map generation from registry daily courtesy of Andrew Scott of Univ. of Lancaster reverse registry courtesy Bill Manning of ISI The backbone conversion to aggregation was accomplished on schedule Different strategies are emerging for sub-delegation A brief overview of the inet6num registry object and how it relates to automatic IPv6 address delegation through the registry was given. This is a result of David Kessens' work at ISI. Discussion of backbone routing policy issues was reserved for the two lunchtime meetings on the following two days (10/11 December). Palo Alto IPv6 Exchange Point - Stephen Stuart The new PAix IPv6 exchange point was described. A LAN switch has been devoted to native IPv6 transported in the PAix, with DIGITAL-CA, UUNET-UK and NWNET currently peering across it. Stephen encouraged others interested and able to secure rack space in the exchange to particpate. CAIRN 6bone Report - Suresh CAIRN is a network testbed funded by DARPA. Currently CAIRN's 6bone peering is done with NRL. Futire peering is planned with University College London, PAix, and UUNET-UK. The transatlantic link will be native IPv6 peering over T1. UK Status: Ben Crosby An overview of the current IPv6 links in the UK was given. It was noted that there is a move to native links to janet, and to the Univ. of Southampton. 6bone Routing Issues I-D - Alain Durand An early draft outline of 6bone Routing Issues was presented and discussed in greater detail. The following is an outline of the topics covered: - Identify all special cases - link local prefixes MUST NOT be advertised - site local only within a site - but what is a site? Should refer IPngwg work on that topic - loopback address and unspecified MUST NOT be advertised - multicast prefixes - should they be advertised in BGP 4+ ? - decided that they SHOULD / MUST NOT be advertised - ipv4 mapped addresses - wait on the decisions from NGtrans on "ipv4 translatable" addresses - this applies only to backbone The draft should specify for each section if it applies to all routers or only to backbone routers - ipv4 compatible SHOULD NOT be advertised on 6bone - perhaps they should be banned - suggestion that they should only be used on tunnels - be careful in case there is a good reason to use them in the future - advertise some compatible bridges using a ::/96 - NEW SERVICE - general consensus not on the backbone - dimitri haskin wants this to happen automatically - auto tunnels dont need to have addresses advertised ? - one router to provide auto tunnelling ? - suggest that this is handled by the IGP ? ACTION - bob to send the idea to the mailing list. - No cases in which you would accept something that you wouldnt send on Stephen Stuart - liberal in recieve, but careful in sending Alain Durand - Ok to receive, but be carefull on what you put on your routing table - what happens with prefixes that dont yet exist - e.g. not 2000::/8 - routes SHOULD be discarded - Aggregation SHOULD be mandatory at every level - SLA, NLA, TLA - Backbone routers MUST be default free - sites MAY have a default route - Tunnels - prefix length ? - which address space ? - DMZ ? - Point to point tunnels could use a /128 - hardware implementation problem ? (some refuse to use /128 prefixes) - point about the use of /128 - BGP 4+ problems due to not sharing subnet - dimitri says use link local but this raises next hop routing problems - then routers automatically change into Site level ? - routing entry in IGP to support the /128 ? This is an IDR wg issue, not a 6bone one. - Tunnel meshing/transit issues - all pTLAs MUST advertise all pTLA routes to/from each other - for prefixes not in pTLA, should not advertise more specific routes - e.g., never advertise less that /24 - never aggregate for someone else (no proxy aggregation) It was suggested making all the changes above and send out to the list as a draft BCP spec for the 6bone. The purpose would be to thus document our operating policies on the 6bone backbone. 6bone General Planning - Bob Fink What to do nextwas discussed, given that the backbone has been converted to the new addressing. It was agreed that it was time to declare all 0ld (5f00) test addresses personna non grata - i.e., as of now we stop routing them. The general registry issue was also addressed, i.e., a lot of sites' registry entries have not been touched since they were automatically generated. Bob proposed deleting entries not cleaned up, given some warning. It was agreed to discuss this on the mail list. Multihomed Sites - Ben Crosby et al The general multihoming issue, i.e., how to do it at all, was discussed. An example of 2 TLAs, with NLAs allocated in each TLA, and a site multihomed to the 2 NLAs was used for this. One idea was to inject a /48 site level for the given site in both NLA & TLA, which there was general agreement on, i.e., this does not scale!!! A 2nd idea was to use limited multihoming - the problem is that this loses benefits of multihoming. In further discussion on Thursday a way was discussed to attempt this by using mobility. Matt Crawford presented the concept during the IPng meeting on Friday. and there was enough interest that it will at least be pursued at the discussion level. Note that this issue is only slightly different for IPv6 than it is for IPv4, and there needs to be more participation from IPv4 folk experienced in routing and multihoming to help move IPv6's multihoming issue along. -end From Alain.Durand@imag.fr Tue Jan 20 17:57:31 1998 From: Alain.Durand@imag.fr (Alain Durand) Date: Tue, 20 Jan 1998 18:57:31 +0100 Subject: new routing issue draft Message-ID: <980120185732.ZM3035@rama.imag.fr> -- --PART-BOUNDARY=.1980120185731.ZM3035.imag.fr Content-Type: text/plain; charset=us-ascii Hi I've submited a new version of the routing-issue draft draft-ietf-ngtrans-6bone-routing-issues-01.txt I've tried to include all feedbacks from last IETF meetings. Here is a copy of it for the impatients. - Alain. --PART-BOUNDARY=.1980120185731.ZM3035.imag.fr Content-Type: text/plain ; name="draft-ietf-ngtrans-6bone-routing-issues-01.txt" ; charset=us-ascii Content-Disposition: attachment ; filename="draft-ietf-ngtrans-6bone-routing-issues-01.txt" X-Zm-Content-Name: draft-ietf-ngtrans-6bone-routing-issues-01.txt INTERNET-DRAFT Alain Durand, IMAG January 19, 1997 Expires July 20, 1998 IPv6 routing issues 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet- drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. This draft expires July 20, 1998. Introduction ------------ The 6bone provides examples of bogus routes which introduced serious operational issues. This memo identifies some pathological cases and gives some guidelines on how 6bone sites should handle them. It defines the 'best current practise' acceptable in the 6bone for the config- uration of both Interior Gateway Protocols (like RIPng) and Exterior Gateway Protocols (like BGP4+). NB: Core routers used in pTLA sites MUST use BGP4+. This memo will cover: 1) link local prefixes 2) site local prefixes 3) special case prefixes: loopback prefix & unspecified prefix 4) multicast prefixes 5) IPv4-mapped prefixes 6) IPv4-compatible prefixes 7) Yet undefined unicast prefixes (from a different /3 prefix) 8) default routes 9) aggregation issues 10) Inter site tunnel issues 1) link local prefixes ---------------------- Link local prefixes MUST NOT be advertized. 2) site local prefixes ---------------------- Site local prefixes MAY be advertized by IGPs within a site. The precise definition of a site is ongoing work discussed in IPng working group. Site local prefixes MUST NOT be advertised by EGPs. 3) special case prefixes ------------------------ a) loopback prefix ::1/128 b) unspecified prefix ::/128 Loopback prefix and unspecified prefix MUST NOT be advertised by any routing protocol. 4) multicast prefixes --------------------- Multicast prefixes MUST NOT be advertised by any unicast routing protocol. 5) IPv4-mapped prefixes ----------------------- IPv4-mapped prefixes MAY be advertised by IGPs withing a site. It may be usefull for some site to have such a route pointing to a translation device. IPv4-mapped prefixes MUST NOT be advertised by EGPs. 6) IPv4-compatible prefixes --------------------------- Sites may choose to use IPv4 compatible addresses internally. As they is no real rationale today for doing that, this practise should be discouraged in the 6bone. It is believed that the use of IPv4 compatible SHOULD be limited to end points of configured tunnels. The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs. Other IPv4-compatible prefixes MUST NOT be advertised by IGPs. IPv4-compatible prefixes MUST NOT be advertised by EGPs. 7) Yet undefined unicast prefixes ---------------------------------- a) from a format prefix different from 2000::/3 b) from a prefix different from 3ffe::/16 (6bone prefix) Such prefixes MUST NOT be advertised by any routing protocol in the 6bone. 8) Default routes ----------------- 6bone core pTLA routers MUST be default free. 9) Aggregation issues --------------------- Aggregation SHOULD be mandatory whenever possible. Site border router MUST aggregate all interior prefixes to a /48 one. pTLA MUST NOT advertise prefixes longer than 24 to other pTLAs. Sites MUST NOT do proxy aggregation, i.e. sites MUST NOT aggregate on behalf of other sites. 10) Inter site tunnel issues ---------------------------- Sites MAY use a /128 prefix taken from their own address space to give an IPv6 address to their endpoint of the tunnels. 11) Security considerations --------------------------- The result of bogus routing tables is usually unreachable sites. Having guidelines to aggregate or reject routes will clean up the routing tables. It is expected that using this guidelines, routing will be less sensitive to denial of service attacks due to misleading routes. 12) Author address ------------------ Alain Durand Institut d'Informatique et de Mathematiques Appliquees de Grenoble IMAG BP 53 38041 Grenoble CEDEX 9 France Phone : +33 4 76 63 57 03 Fax : +33 4 76 51 49 64 E-Mail: Alain.Durand@imag.fr --PART-BOUNDARY=.1980120185731.ZM3035.imag.fr-- From RLFink@lbl.gov Wed Jan 21 15:10:48 1998 From: RLFink@lbl.gov (Bob Fink) Date: Wed, 21 Jan 1998 07:10:48 -0800 Subject: a question on what to specify for buying IPv6-capable routers Message-ID: Dear 6bone folk, I would like to elicit comments from you on appropriate features and characteristics to specify when buying routers that are IPv6-capable. This would be collated and posted on our web pages to help those who need help in specifying IPv6 in their router procurements. So...any specifications, comments and ideas, to the list please, are appreciated (including pointers that this already exists somewhere). Thanks, Bob From richdr@microsoft.com Thu Jan 22 22:32:12 1998 From: richdr@microsoft.com (Richard Draves) Date: Thu, 22 Jan 1998 14:32:12 -0800 Subject: automatic tunnels? Message-ID: <4D0A23B3F74DD111ACCD00805F31D81002398E75@red-msg-50.dns.microsoft.com> Does anyone out there support automatic tunnels? My 6bone node does (it's ::131.107.65.121) but I haven't found anyone else to ping. Thanks, Rich From richdr@microsoft.com Thu Jan 22 22:48:36 1998 From: richdr@microsoft.com (Richard Draves) Date: Thu, 22 Jan 1998 14:48:36 -0800 Subject: v4 given v6 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81002398E76@red-msg-50.dns.microsoft.com> Given a 6bone node's v6 address, what's the best way to find a v4 address for the node (if it has one)? It would be handy for debugging to have such a method. For example, I was pinging 3ffe:200::2c0:33ff:fe02:8b from my node (which is 3ffe:a00:6::836b:4179). I noticed that the performance was poor: several hundred ms latencies, several percent dropped packets. So I traced the route and tried pinging the nodes along the path. It looks like the problem first crops up with the node 3ffe:1100:0:f004::1, which from the registry would appear to be in England. The previous node, 3ffe:1280:1001:1::2, in California, pings just fine. So presumably it's the jump across the ocean causing the problem. But I'd like to try pinging a v4 address for 3ffe:1100:0:f004::1, to see if it behaves equally poorly. Rich From crawdad@fnal.gov Thu Jan 22 23:18:46 1998 From: crawdad@fnal.gov (Matt Crawford) Date: Thu, 22 Jan 1998 17:18:46 -0600 Subject: v4 given v6 In-Reply-To: Your message of Thu, 22 Jan 1998 14:48:36 PST. <4D0A23B3F74DD111ACCD00805F31D81002398E76@red-msg-50.dns.microsoft.com> Message-ID: <199801222318.RAA08487@gungnir.fnal.gov> > Given a 6bone node's v6 address, what's the best way to find a v4 address > for the node (if it has one)? I would look up the PTR record in ip6.int, then look up the A record for that name. However, there are some obstacles: The ip6.int is often not well-maintained. We knew about this problem from the git-go. Some people are naming their IPv6 nodes in a separate subdomain, maybe because their regular DNS servers don't support AAAA records. From raj@cisco.com Thu Jan 22 23:27:32 1998 From: raj@cisco.com (Richard Johnson) Date: Thu, 22 Jan 1998 15:27:32 -0800 Subject: v4 given v6 In-Reply-To: Your message of "Thu, 22 Jan 1998 14:48:36 PST." <4D0A23B3F74DD111ACCD00805F31D81002398E76@red-msg-50.dns.microsoft.com> Message-ID: <199801222327.PAA01876@rast.cisco.com> Theoretically you should be able to do a "PTR" query to find the hostname and then to a "A" query to find the corresponding v4 address. (Remember, I *did* say "theoretically".) /raj From richdr@microsoft.com Fri Jan 23 00:02:02 1998 From: richdr@microsoft.com (Richard Draves) Date: Thu, 22 Jan 1998 16:02:02 -0800 Subject: v4 given v6 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81002398E7D@red-msg-50.dns.microsoft.com> > > Given a 6bone node's v6 address, what's the best way to find a v4 > address > > for the node (if it has one)? > > I would look up the PTR record in ip6.int, then look up the A record > for that name. However, there are some obstacles: > [Richard Draves] Yes, in practice the DNS doesn't do the job, at least today. It's too bad I can't just send a Neighbor Solicitation to the v6 address and ask the node what it's link-level address is... the node would receive the solicitation on its tunnel interface and the v4 address would be the link-level address for the tunnel interface. But it won't work because NS validation will fail: the packet will have a hop count != 255. In fact I can see implementations disabling all ND on tunnel pseudo-interfaces used for configured and automatic tunnels, since those forms of tunneling don't use ND. Maybe we can define a limited form of NS/NA for use with tunnel pseudo-interfaces? Or would that be too confusing? Or perhaps more generally, for all interfaces allow a NS with hop count != 255 to query the link-level address, but if the hop count != 255, don't update the Neighbor Cache in any way because the source isn't actually a neighbor. Rich From leewb@dcn.soongsil.ac.kr Fri Jan 23 05:38:59 1998 From: leewb@dcn.soongsil.ac.kr (leewb@dcn.soongsil.ac.kr) Date: Fri, 23 Jan 1998 14:38:59 +0900 Subject: How can I get PTLA address? Message-ID: <3.0.1.32.19980123143859.00697094@dcn.soongsil.ac.kr> Does anyone have a advice for getting PTLA address? Our IPv6 host is running with test address(5f0d:: type). and Now we hope to change this address. Thanks. -------------------------------- Lee Wangbong. DCN-SSU-KOREA. http://dcn.soongsil.ac.kr/~leewb phone : 02-820-0823 fax : 02-820-0900 pager : 012-1011-2323 -------------------------------- From RLFink@lbl.gov Fri Jan 23 14:20:27 1998 From: RLFink@lbl.gov (Bob Fink) Date: Fri, 23 Jan 1998 06:20:27 -0800 Subject: v4 given v6 In-Reply-To: <199801222318.RAA08487@gungnir.fnal.gov> References: Your message of Thu, 22 Jan 1998 14:48:36 PST. <4D0A23B3F74DD111ACCD00805F31D81002398E76@red-msg-50.dns.microsoft.com> Message-ID: At 3:18 PM -0800 1/22/98, Matt Crawford wrote: >> Given a 6bone node's v6 address, what's the best way to find a v4 address >> for the node (if it has one)? > >I would look up the PTR record in ip6.int, then look up the A record >for that name. However, there are some obstacles: > > The ip6.int is often not well-maintained. We knew about this > problem from the git-go. > > Some people are naming their IPv6 nodes in a separate > subdomain, maybe because their regular DNS servers don't > support AAAA records. Might it be a good time to try to go away from this convention (i.e., a separate ipv6 subdomain)? As we try more and more to act like a real dual v4/v6 environment it would be best to not do this. Can advocates of maintaining this convention please state their reasons for this to the list? Thanks, Bob From RLFink@lbl.gov Fri Jan 23 14:49:53 1998 From: RLFink@lbl.gov (Bob Fink) Date: Fri, 23 Jan 1998 06:49:53 -0800 Subject: How can I get PTLA address? In-Reply-To: <3.0.1.32.19980123143859.00697094@dcn.soongsil.ac.kr> Message-ID: At 9:38 PM -0800 1/22/98, leewb@dcn.soongsil.ac.kr wrote: > Does anyone have a advice for getting PTLA address? As discussed in http://www.6bone.net/6bone_hookup.html "The best way to find an appropriate attachment point to the 6bone (i.e., a site to build a tunnel to) is to find a 6bone backbone site (see current list of 6bone backbone sites) that is closely conneceted to your best IPv4 connectivity path, has good up-time and round-trip time characteristics, and is willing to have you attach." As for becoming a pTLA, you should get lots of experience as a leaf site first, then if you want to be a transit, become an NLA under your pTLA to gain experience, and then develop a strong case for becoming a pTLA level transit. If you have questions on this, please ask. Thanks, Bob From mccann@zk3.dec.com Fri Jan 23 14:57:51 1998 From: mccann@zk3.dec.com (Jack McCann) Date: Fri, 23 Jan 1998 09:57:51 -0500 Subject: automatic tunnels? Message-ID: <199801231457.AA06379@wasted.zk3.dec.com> Rich, > Does anyone out there support automatic tunnels? Try ::206.152.163.3 (sipper.zk3-x.dec.com). The IPv6 address is 3ffe:1200:2002:1000:200:f8ff:fe23::6972 (sipper6.ipv6.zk3-x.dec.com). - Jack From mccann@zk3.dec.com Fri Jan 23 15:44:54 1998 From: mccann@zk3.dec.com (Jack McCann) Date: Fri, 23 Jan 1998 10:44:54 -0500 Subject: automatic tunnels? Message-ID: <199801231544.AA09421@wasted.zk3.dec.com> >> Does anyone out there support automatic tunnels? > >Try ::206.152.163.3 (sipper.zk3-x.dec.com). The IPv6 address is >3ffe:1200:2002:1000:200:f8ff:fe23::6972 (sipper6.ipv6.zk3-x.dec.com). ^^^^^^^ Sorry, that should be: sipper.ipv6.zk3-x.dec.com - Jack From RLFink@lbl.gov Mon Jan 26 15:49:09 1998 From: RLFink@lbl.gov (Bob Fink) Date: Mon, 26 Jan 1998 07:49:09 -0800 Subject: v4 given v6 In-Reply-To: <034543B7FDC5D011BAC10000C06F25BE42920E@gvamsx1.ch.att.com> Message-ID: Bertrand, At 8:59 AM -0800 1/23/98, Buclin, Bertrand wrote: >Hi Bob, > >> Can advocates of maintaining this convention please state their reasons for >> this to the list? > >As one of those using a separate domain for Ipv4 and IPv6, here is my >(only) reason to do so: > >The IPv6 lab I am running is an experimental environment, and it is our >corporate policy not to mix experimental stuff with production. I guess >anybody around running a service business has similar policies. > >DNS use for IPv6 is far from mature yet, and if we want to experiment >with the new proposals, we should not constrain ourselves with >production-level requirements. We want to be able to upgrade the DNS >servers quickly if new DNS RR types are introduced, and there is no way >I can push Operations to put on production nodes an early and un-tested >BIND release... > >Also, several of the nodes in my lab only have IPv6 stacks and no Ipv4. >So, trying to find what their Ipv4 address does not really make sense. >As we will see more native transports for Ipv6 (over PPP, ATM, Frame >Relay,...), more and more Ipv6-only systems and especially routers will >be on the 6Bone. Thanks for the reply. Your points are well taken. My main purpose is to enable clients to decide which stack to use by querying the dns for a specific domain name, which seems to require (in general) the A and AAAA record being under the same domain name "path". Maybe an easier way to do this for now, rather than trying to have everyone move their AAAA into the production directory, is to have the IPv4 A record appear along with the IPv6 AAAA record in the experimental IPv6 subdomain. Regarding the state of most current BIND releases in common use, it was my understanding that AAAA support way widely implemented (even if the site doesn't know about it :-) Anyone know if this is remotely true, or am I dreaming? I appreciate this wasn't your point on newer RR types in advanced BIND versions. >The initial question was about how to find automatic tunnel end-points. >Even if one find which is the Ipv4 address of my boxes, that does not >mean that I am ready to offer an automatic tunnel on those. Actually, on >almost all my systems, automatic tunnelling is disabled. > >What might be of better use would be to have a new application code for >the registry letting people know the IPv4 address of systems accepting >auto-tunnels (After all, tunnels are also a sort of application). >Something like: > >application: Auto-Tunnel ::a.b.c.d > >or > >application: Auto-Tunnel domain.name > >provided there is a AAAA (or whatever will replace them) for domain.name >translating to ::a.b.c.d I can't evaluate the value of doing this, so would prefer others comment, but if there is a use in doing this we can ask David Kessens to add it. Thanks, Bob From Francis.Dupont@inria.fr Mon Jan 26 19:39:01 1998 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Mon, 26 Jan 1998 20:39:01 +0100 Subject: multihomed routing domain issues Message-ID: <199801261939.UAA17200@givry.inria.fr> Here is a preliminary version of a draft about multihomed routing domain issues (as discussed at the last IETF meeting during 6bone BOFs' lunch-time)... Francis.Dupont@inria.fr Internet Engineering Task Force Francis Dupont INTERNET DRAFT GIE DYADE January 25, 1998 Multihomed routing domain issues for IPv6 aggregatable scheme 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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). Distribution of this memo is unlimited. Abstract This document exposes some issues for multihomed routing domains using the aggregatable addressing and routing scheme. A routing domain is multihomed when it uses two or more providers of the upper level. Most of these issues are not specific to IPv6 but are consequences of the addressing and routing scheme. 1. Introduction The aggregatable addressing and routing scheme [AGGR] defines an IPv6 aggregatable global unicast address format for use in the Internet and the associated routing. The address assignment and allocation mechanism is fully hierarchical, a prefix of a given level (ie. of a given length) denotes all the destinations in the prefix ie. aggregates them. The customers of an Internet service provider are in its prefix (as a consequence a multihomed routing domain has several prefixes). The routing is standard datagram routing, hop by hop, on destination address only (as in IPv4). But it is a prefix routing, ie. forwarding decisions are based on a "longest prefix match" algorithm on arbitrary bit boundaries without any knowledge of the internal structure of addresses. When there are two routes for the same prefix with the same length then the best is caught for the inter-domain routing protocol [BGP]: o policy rules; o shortest path, the path being the list of routing domains to cross; o protocol metric. The aggregation idea is the bet that in most of the cases a single-homed Internet service provider at a given level should know (ie. has routes to) only: o its upper provider (ie. a shorter prefix, used as a default) if it is not a top-level provider; o its customers (ie. longer routes in its prefix); o some routes to other customers of its upper provider (ie. sibling prefixes, at the same level). With addresses this gives (with P1:P2/x for the concatenation of prefixes P1 and P2 with the length x): o T/t for the upper provider; o T:P/t+p for the provider itself; o T:P1/t+p1, T:P2/t+p2, ..., T:Pn/t+pn for siblings; o T:P:C1/t+p+c1, T:P:C2/t+p+c2, ..., T:P:Cn/t+p+cn for customers. The routing information for siblings is only needed for top-level providers. For an other provider it is only an optimization (ie. a backdoor) because any destination, including sibling, not in its own prefix, is reachable through the upper provider. Usual routing exchanges for P at prefix T:P/t+p are: o from the upper provider the route to T/t which can be used as a default (ie. <>/0); o from a customer the route to T:P:C/t+p+c; o from a sibling the route to T:Q/t+q; o to anybody the route for T:P/t+p (and nothing else). The scheme is with arrows for route (and traffic) exchange: +-----+ Upper Level | T | +-----+ | ^ T/t | | T:P/t+p V | +-------+ +-----+ | |------ T:P/t+p --->| | Siblings | P | | Q | | |<---- T:Q/t+q -----| | +-------+ +-----+ ^ | ^ | | | | | | | | +-------- T:P/t+p ----+ | | | | | | +---- T:P:Cn/t+p+cn --+ | | | | | T:P:C1/t+p+c1 | | | | | | T:P/t+p | | | V | V +-----+ +-----+ | | | | Customers | C 1 | | C n | | | | | +-----+ +-----+ The aggregation is shown by the fact one announces only the route to its own "aggregated" prefix and masks routes to longer prefixes. Upper levels should not know the details of lower levels, this transparency property should be kept. A top-level provider has no upper provider (ie. no default) and must exchange routes with all the other top-level providers (ie. full routing with its siblings is mandatory). In order to avoid routing table explosion, the length of top-level prefixes is bounded (therefore the number of top-level providers is bounded too). 2. Multihomed Routing Domains A multihomed routing domain has more than one provider then it has more than one prefix (usually a prefix per provider). There are several reasons to be multihomed: o the "two coasts" case where the routing domain is split into sub-domains in different locations, each domain using a local provider: +-----+ +-----+ | | | | | T w | | T e | | | | | +-----+ +-----+ ^ | ^ | | | | | +---------|-|--------------------|-|--------+ | S | V | V | | +-----+ +-----+ | | | |--------------->| | | | | S w | | S e | | | | |<---------------| | | | +-----+ +-----+ | | | +-------------------------------------------+ But in fact this comes down to two routing domains with a backdoor between them. The extra routes can be hidden and there is no further matter. o reliable service: to be able to use another provider in case of a connectivity problem. Of course the purpose is to limit trouble to the only case when all the providers fail (and NOT when at least one fails!). +-----+ +-----+ | | | | | T 1 | | T 2 | | | | | +-----+ +-----+ ^ | ^ | | | | | | +--------+ +--------+ | | | | | +--------+ | | +--------+ | | | | | V | V +--------+ | | | S | | | +--------+ A given host of a such routing domain may (and should if reliable connectivity is needed) have two different addresses, one for each prefix (T1:S1:H in T1:S1/t1+s1 and T2:S2:H in T2:S2/t2+s2). This document mainly covers this case. 3. The Transparency Issue If a domain prefix is announced at an upper level, it has to be announced to this whole level. ^ A/x ^ B/x and A:S/x+y | | +-----+ +-----+ | | | | | A | | B | | | | | +-----+ +-----+ ^ | ^ | | | | | | +--------+ +--------+ | | | | | +--------+ | | +--------+ | | | | | V | V +--------+ | | | S | | | +--------+ If the provider B tries to announce the prefix A:S/x+y in order to be able to route the traffic for S with both prefixes A:S/x+y and B:S/x+y then B will catch the whole traffic for S because the prefix A:S/x+y is longer than the prefix A/x (x+y > x) so it is a better match... In this case the only solution is that both A and B announce routes to prefixes A:S/x+y and B:S/x+y which breaks the transparency property and obviously does not scale. 4. Mutual Backup There is a case where the transparency property is kept, routing is as reliable as possible and is optimal in almost all the cases. ^ A/x and B/x ^ B/x and A/x | | +-----+ +-----+ | |------ A/x ---->| | | A | | B | | |<------ B/x ----| | +-----+ +-----+ ^ | B:S/x+y ^ | | | A:S/x+y | | | +-- A/x -+ +--------+ | | | | | +--------+ | | +- B/x --+ A:S/x+y | | | | B:S/x+y | V | V +--------+ | | | S | | | +--------+ For a provider T in an upper level or the same one than providers A and B, routes for the prefix A/x are not equivalent because the prefix A/x announced by A is direct (one element (A) in the path) and the prefix A/x announced by B is indirect (two elements (B and A) in the path). Then traffic for A will go to A directly. The same thing applies for B. The prefix A:S/x+y is longer (ie. better) than the prefix A/x then for A the whole traffic for S will go directly, same for B. S has routes for A/x and B/x and can use any provider for other destinations. The choice of the provider is managed by internal policy rules, in order to avoid asymmetrical routing the source address selection should be coherent with the policy. Usually S managers ask for routes to upper levels up to the first common upper provider. If the path through A is not available then the whole traffic for S, including the one to or from addresses in the prefix A:S/x+y will go through B. This case supposes a mutual backup agreement between A and B which can be the case if A and B are not in competition, for instance A is a mission provider and B a geographical one. But it is a real constraint... This still works if announces between A and B do not carry full prefixes (but they should include (ie. be shorter than) the prefix *:S/x+y). The backup will work only for a part of A and B (with a dark hole in case of failure for customers not implied in the backup agreement). Unfortunately this does not work in more complex cases: ^ A/x and B/x ^ B/x, A/x and C/x ^ C/x and B/x | | | +-----+ +--------+ +-----+ | |--- A:S/x+y --->| |--- B:R/x+y --->| | | A | | B | | C | | |<--- B:S/x+y ---| |<--- C:R/x+y ---| | +-----+ +--------+ +-----+ ^ | B:S/x+y ^ | ^ | C:R/x+y ^ | | | A:S/x+y | | | | B:R/x+y | | | +-- A/x -+ +--------+ | | +-- B/x -+ +--------+ | | | | | | | | | +--------+ | | +- B/x --+ +--------+ | | +- C/x --+ A:S/x+y | | | | B:R/x+y | | | | B:S/x+y | V | V C:R/x+y | V | V +--------+ +--------+ | | | | | S | | R | | | | | +--------+ +--------+ The backup is not transitive in this case, if something goes wrong in the B path for S the traffic can try to cross C which knows nothing about S and will drop packets... 5. Broken Bit Consider the standard multihomed case when a link is broken: +-----+ +-----+ | | | | | A | | B | | | | | +-----+ +-----+ ^ | X ^ | | | X | | | +--------+ +---X----+ | | | | X | +--------+ | | +---X----+ | | | | X | V | V X +--------+ | | | S | | | +--------+ If we look inside the routing domain S: +-----+ +-----+ | | | | | A | | B | | | | | +-----+ +-----+ +---+ ^ | X ^ | | X | | | X | | +---+ | +--------+ +---X----+ | | | | X | +--------+ | | +---X----+ | | | | X | V | V X +----+ +----+ +----| RA |---| RB |----+ | +----+ +----+ | | | | | | ------------------- | | | | | +---+ | | | R | | | +---+ | | | | | ------- | | | | | +---+ | | | H | | | S +---+ | | | +-----------------------+ The host H has two addresses, A:S:H and B:S:H, and the path through B is broken. An external host X will use A:S:H because B:S:H does not work. The DNS will return both addresses but the applications should try all of them (on BSD 4.4 derived Unixes we have found only one standard application trying only the first returned address). We can try to play on address order in the DNS but the DNS caching mechanism makes this difficult (but it is not necessary). In conclusion new connections from X to H will work. For new connections from H to X the problem is to force the choice of the good source address (A:S:H) by H. The proposal is to add a "broken bit" in prefix information in router advertisement in order to inform nodes that addresses in a given prefix should not be used. The border router RB knows there is a problem and should send this information to all the routers of S using for instance the router renumbering protocol. The last case, existing (ie. established before the failure) connections between H (using B:S:H) and X are dealt with in the next section. 6. Use Of Mobility Mechanisms The idea is to use some mechanisms of IPv6 mobility [MOB] (home address and binding update but not home-agent nor (in fact) true mobility) in order to make critical connections resilient to provider failures. +---+ aaaaaaaaaaaaaaaaaaa| X | a +---+ a b a b +-----+ b +-----+ | | b | | | A | bb| B | | | | | +-----+ +-----+ ^ | X ^ | | | X | | | +--------+ +---X----+ | | | | X | +--------+ | | +---X----+ | | | | X | V | V X +--------------+ | a b | | a b | | a b | | a b | | a +---+ | | aaaaa| H | | | +---+ | | S | +--------------+ There is a connection between H and X (using addresses B:S:H and X) with a security association for authentication (necessary for mobility and not a real constraint for a critical connection because it is easy to mess an unauthentic connection, for instance with junk RST TCP packets). After the (used) path through B fails, the broken bit is set in the prefix B:S information in router advertisements then H is informed of the problem. H uses a home address B:S:H destination option in each packet for X in order to use A:S:H as the source address: for each router the source is in A's prefix and only X replaces the source address by B:S:H before looking up the PCB of the connection. H sends a binding update with A:S:H as the care-of address to X in a packet with an Authentication Header. X receives and processes it, sends a binding acknowledgement and uses a routing header with A:S:H as the (first) destination and B:S:H as the final destination. Summary: o packets from H to X: source = A:S:H destination = X home-address = B:S:H binding-update (in first packets, should be acknowledged): care-of = A:S:H o packets from X to H: source = X destination = A:S:H routing-header: one address = B:S:H While X must implement the full mobile correspondent node operation, H must implement only the binding management (no movement detection, no new care-of address acquisition, no operation with a home agent). In fact H does not move, it only changes its address choice. 7. Security Considerations A better reliability in Internet connectivity can only improve security. Critical connection should be authenticated and binding updates must be carried in authenticated packets (see [MOB] for the discussion). IPSEC is mandatory for compliant IPv6 implementations. 8. ACKNOWLEDGEMENTS All these ideas were discussed or found at the 40th IETF meeting at Washington during lunch-time 6bone BOFs. The transparency issue was well-known (and presented by XXX). The mutual backup scheme was built by the author for a regional/organization dual-homing at a G6 meeting. The non-transitive issue was presented by Alain Durand. The diversion of mobility mechanisms appeared in the discussion between the author and Matt Crawford who proposed the broken bit. 9. References [AGGR] Hinden, R., O'Dell, M. and Deering, S., "An IPv6 Aggregatable Global Unicast Address Format", Internet Draft, , July 1997. [BGP] Rekhter, Y. and Li, T. "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, cisco Systems, March 1995. [MOB] Johnson, D. B., Perkins, C., "Mobility Support in IPv6", Internet Draft, , November 1997. Author's Address Francis Dupont GIE DYADE INRIA Rocquencourt Domaine de Voluceau B.P. 105 78153 Le Chesnay CEDEX FRANCE Fax: +33 1 39 63 55 66 EMail: Francis.Dupont@inria.fr From pcurran@ticl.co.uk Mon Jan 26 23:42:32 1998 From: pcurran@ticl.co.uk (Peter Curran) Date: Mon, 26 Jan 1998 23:42:32 -0000 Subject: v4 given v6 Message-ID: <01bd2ab4$126523e0$0f0120c1@desktop.ticl.co.uk> Bob >Might it be a good time to try to go away from this convention (i.e., a >separate ipv6 subdomain)? > >As we try more and more to act like a real dual v4/v6 environment it would >be best to not do this. > >Can advocates of maintaining this convention please state their reasons for >this to the list? > The original reason for adopting this convention (as I think is mentioned in an item on the web site) is that it gets around the problem of older DNS implementations that may not have support for AAAA. In practice I think that there are a couple of good reasons to maintain the convention. One has been given by Bertran Buclin (i.e. not mixing 'experimental' and 'production' environments). My reason is equally practical: I have a number of v6 systems. Not all of them are dual-stacked. On some of the dual-stacked systems, not all of the services have been ported to v6. If I have a dual-stack client then I need some way to discriminate between a v4-only app, a v6-only app and a v4/v6 app. The mapIPv6 resolver option doesn't help me here - it is an all or nothing solution. If I want to access a service on a v4/v6 node and I know the service is v4-only than I can specify the 'regular' name and as an A record is retreived then I can successfully access the service. Conversely, if I know the service is v6-only or v4/v6 then I specifiy the ipv6 subdomain and I get an AAAA record. So, I think that the concept of a parallel IPv6 domain has some continuing value for me until all of my applications are bilingual. My 2p Peter Curran TICL/UK From richdr@microsoft.com Mon Jan 26 23:33:28 1998 From: richdr@microsoft.com (Richard Draves) Date: Mon, 26 Jan 1998 15:33:28 -0800 Subject: automatic tunnels? Message-ID: <4D0A23B3F74DD111ACCD00805F31D81002398E97@red-msg-50.dns.microsoft.com> Thanks, I was able to ping both addresses. Although I notice that the route (for the aggregatable address) goes through 5f00:1000:0:10:b::1 - I thought the 6bone was no longer using the old-style addresses? > -----Original Message----- > From: Jack McCann [SMTP:mccann@zk3.dec.com] > Sent: Friday, January 23, 1998 7:45 AM > To: 6bone@ISI.EDU; mccann@zk3.dec.com; Richard Draves > Subject: Re: automatic tunnels? > > > >> Does anyone out there support automatic tunnels? > > > >Try ::206.152.163.3 (sipper.zk3-x.dec.com). The IPv6 address is > >3ffe:1200:2002:1000:200:f8ff:fe23::6972 (sipper6.ipv6.zk3-x.dec.com). > ^^^^^^^ > Sorry, that should be: sipper.ipv6.zk3-x.dec.com > > - Jack From richdr@microsoft.com Mon Jan 26 23:42:33 1998 From: richdr@microsoft.com (Richard Draves) Date: Mon, 26 Jan 1998 15:42:33 -0800 Subject: finding automatic tunnels Message-ID: <4D0A23B3F74DD111ACCD00805F31D81002398E98@red-msg-50.dns.microsoft.com> > >The initial question was about how to find automatic tunnel end-points. > >Even if one find which is the Ipv4 address of my boxes, that does not > >mean that I am ready to offer an automatic tunnel on those. Actually, on > >almost all my systems, automatic tunnelling is disabled. > [Richard Draves] Why are people disabling automatic tunneling? > >What might be of better use would be to have a new application code for > >the registry letting people know the IPv4 address of systems accepting > >auto-tunnels (After all, tunnels are also a sort of application). > >Something like: > > > >application: Auto-Tunnel ::a.b.c.d > > > >or > > > >application: Auto-Tunnel domain.name > > > >provided there is a AAAA (or whatever will replace them) for domain.name > >translating to ::a.b.c.d > > I can't evaluate the value of doing this, so would prefer others comment, > but if there is a use in doing this we can ask David Kessens to add it. > [Richard Draves] I don't have any opinions on the specific proposal, but I think it would be valuable for testing purposes to have something in the registry that points out sites that support automatic tunnels. Especially if it's not widely supported. Rich From bmanning@ISI.EDU Tue Jan 27 21:59:15 1998 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Tue, 27 Jan 1998 13:59:15 -0800 (PST) Subject: v4 given v6 In-Reply-To: <199801222318.RAA08487@gungnir.fnal.gov> from "Matt Crawford" at Jan 22, 98 05:18:46 pm Message-ID: <199801272159.AA08005@zed.isi.edu> > > > Given a 6bone node's v6 address, what's the best way to find a v4 address > > for the node (if it has one)? > > I would look up the PTR record in ip6.int, then look up the A record > for that name. However, there are some obstacles: > > The ip6.int is often not well-maintained. We knew about this > problem from the git-go. > > Some people are naming their IPv6 nodes in a separate > subdomain, maybe because their regular DNS servers don't > support AAAA records. Hum.. ip6.int total zones successful no-zone other %accurate 252 149 103 0 59.1% e.f.f.3.ip6.int. only total zones successful no-zone other %accurate 139 92 47 0 66.1% For the e.f.f.3.ip6.int. tree, of the no-zone failures, total firewalled failures refused no server other 47 26 18 3 Compare that with the last data on the IPv4 inverse tree of just over 57% accurate. I need to go off and compare the IPM stats vs Tony Bates prefix lists and get a stability metric for the routing system. I expect it is close. To paraphrase your statement Matt, I would say, "The routing system is often not well-maintained. We knew about this problem from the git-go." --bill From davidk@ISI.EDU Fri Jan 30 23:22:45 1998 From: davidk@ISI.EDU (davidk@ISI.EDU) Date: Fri, 30 Jan 1998 15:22:45 -0800 (PST) Subject: FYI: 6BONE registry software & machine change Message-ID: <199801302322.PAA02719@ra0.isi.edu> Hi, Today, I changed to a new machine and new software. You might experience some service interruptions due to this fact. Please issue your queries directly to 'whois1.avalon.rs.net' if you find that 'whois.6bone.net' is still pointing to the old machine. Also the web interface at my site (http://www.isi.edu/cgi-bin/davidk/whois.pl) is already up to date. The copies and statistics of the registry are again available from: ftp://whois.6bone.net/6bone/ The software is very new and will contain almost certainly quite some bugs. Please let me know if you experience any problems and I will try to fix them as soon as possible. David K. --- From ziyas@ebim.net Sat Jan 31 16:33:20 1998 From: ziyas@ebim.net (Ziya Suzen) Date: Sat, 31 Jan 1998 18:33:20 +0200 Subject: trying to join 6bone Message-ID: <34D35250.44070092@ebim.net> Hi, I work for an ISP in Northern Cyprus and i would like to join the 6bone eventualy. I have read the "how to join 6bone" page on the site and i foun out i need atleast two machines one router and one host. I was wondering if two Linux boxes could do. One as a host and one as a router. Thank you for your attention. Regards Ziya Suzen ziyas@ebim.net System Admin EbimNet Network Systems