From owner-ipng@sunroof.eng.sun.com Tue Sep 2 14:54:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA26528; Tue, 2 Sep 1997 14:44:13 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA26521; Tue, 2 Sep 1997 14:44:05 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA29602; Tue, 2 Sep 1997 14:46:45 -0700 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA20113 for ; Tue, 2 Sep 1997 14:46:53 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id RAA28807; Tue, 2 Sep 1997 17:46:30 -0400 Date: Tue, 2 Sep 1997 17:46:30 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <970902174629.ZM28805@seawind.bellcore.com> In-Reply-To: Robert Elz "Re: (IPng 4333) Following DNS record discussion in Munich..." (Aug 27, 4:00pm) References: <587.872672439@aussie.cs.mu.OZ.AU> X-Mailer: Z-Mail (4.0.1 13Jan97) To: Robert Elz Subject: (IPng 4379) Re: Following DNS record discussion in Munich... Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3315 On Aug 27, 4:00pm, Robert Elz wrote: > This is not usually going to be true with just a modicum of rational > DNS design - any more than it is for MX record lookups, or NS record > lookups, which return a name, which must subsequently (to be useful as > more than an ornament) be translated into an A record. I agree with you, this is trivial. Just add a rule that says that available AAAA records should be returned in the additional section whenever a domain name is present in a NS, MX or AAAA record. > This would arguably be much slower, and also more error prone. > > It would only rarely be slower, and not at all more error prone. Uh? Potential of errors include wrong name for net in AAAA record (human error) and DNS server for reference record going antipodic, plus many more. That cannot occur if you need exactly one record. > > What if, for example, updates to the two entries are not propagated > simultaneously to the various DNS caches throughout the Internet? > > I'm not sure what you're getting at here, the DNS has always had a window > of inconsistent results from caches that are yet to time out stale data, > this is not new, and this proposal makes it no worse. Well, AAAA up to date, network record off base ? Wrong TTL ? > I actually very much like this proposal, though I would make two small > changes. > > Instead of this... > > Instead of > just storing 16 octets of address, we can store in the same record a > prefix length and the name of a subnet. > > +--------------+-------------+-----------------------+ > | Address | Pre. length | Domain name of subnet | > | (16 octets) | (1 octet) | (variable) | > +--------------+-------------+-----------------------+ > > Do this instead .. > > +--------------+------------------+-----------------------+ > | Pre. length | Address low bits | Domain name of subnet | > | (1 octet) | (0..16 octets) | (variable, 0..256) | > +--------------+------------------+-----------------------+ You spare a few bytes (typically 6 to 8) but loose compatibility with the existing spec. In fact, one reason for my proposal is a remark made by Jim Bound during the Munich meeting. He was concerned with the transition mess between existing AAAA records and the new ones. My format allows at least some compatibility: * for new hosts: - place a valid 16 octet address in the record, e.g. the preferred address. - the reference to the domain allows smart hosts which understand the new spec to list the complete values, and be sure to always have an uptodate entry. * for old hosts: - they just have a 16 octets AAAA. - new hosts read that, find that the length is exactly 16 octets, understand that prefix length and domain are absent. That is, we can omit both prefix length and domain when there is no domain. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 3 11:40:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA27872; Wed, 3 Sep 1997 11:24:34 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA27865; Wed, 3 Sep 1997 11:24:20 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA21752; Wed, 3 Sep 1997 11:26:34 -0700 Received: from yosemite.cs.utk.edu (YOSEMITE.CS.UTK.EDU [128.169.92.103]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA10431 for ; Wed, 3 Sep 1997 11:26:19 -0700 Received: from localhost by yosemite.cs.utk.edu with SMTP (cf v2.11c-UTK) id OAA08582; Wed, 3 Sep 1997 14:26:39 -0400 Date: Wed, 3 Sep 1997 14:26:39 -0400 (EDT) From: J Scott Thompson To: ipng@sunroof.eng.sun.com Subject: (IPng 4380) Performance Measurement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1595 I am interested in focussing my Master's Thesis work in measurement of network performance. Specifically, I would like to develop a means by which historical data can be collected and made public looking at various metrics (bandwidth, latency, etc.), on various networks (6bone, ESNet, VBNS, etc.). Additionally, I would like to develop a means by which researchers can get real-time data for connections of interest (through CGI scripts or Java Applets executed from web pages). I am especially interested in trying to identify changes in network performance as the industry continues in its conversion to IPv6 and ATM over the coming years. I would appreciate feedback regarding this project. Specifically: 1) What metrics are the research community most interested in? 2) What metrics are measurable now using current tools? 3) What metric data are desired but which are currently not measurable using any known tools? 4) Is there anyone (or any group) currently interested in and working on similar measurements. 5) Any suggestions regarding a "good place to start" with a project of this nature. Jay Thompson University of Tennessee Computer Science Department jthompso@cs.utk.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 3 21:37:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA28668; Wed, 3 Sep 1997 21:29:32 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA28661; Wed, 3 Sep 1997 21:29:22 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA06337; Wed, 3 Sep 1997 21:32:03 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA27104; Wed, 3 Sep 1997 21:32:12 -0700 Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id AAA03581; Thu, 4 Sep 1997 00:29:32 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA07242; Thu, 4 Sep 1997 00:29:26 -0400 Message-Id: <9709040429.AA07242@wasted.zk3.dec.com> To: Erik Nordmark - Sun Sweden Cc: mobile-ip@hosaka.smallworks.com, ipng@sunroof.eng.sun.com, solomon@comm.mot.com Subject: (IPng 4381) Re: Mobile IPv6 requirements on all nodes In-Reply-To: Your message of "Mon, 18 Aug 1997 10:57:47 +0200." Date: Thu, 04 Sep 1997 00:29:26 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3326 Erik and Jim, I reviewed the draft and spoke with Charlie too. I think its fine for PS as the only way to test this is to get it implemented on IPv6 and get it running on the 6bone. Experience tells me in the IPv6 culture folks don't like to write a heck of a lot of code until things are at PS. I also think the IPv6 reqs for corresponding nodes makes a lot of sense. It would be good if the draft would develop a conceptual model or diagram of the potential means to process binding updates using a routing table or ND Dst Cache for an IPv6 corresponding node. It took me anyway awhile to parse the rule set from the draft. And I spent time with Charlie too. So I don't think its just me. I was mostly concerned re the affect from swapping the src address via the home agent option and using the binding update after the upper layers process the packet on transmit. I also think somewhere it should say that as far any upper layer is concerned it is always sending and receiving from the mobile nodes home address. That if a corresponding node has a binding cache for care of address the sending of the packet is direct via a src route. Its in the spec now but I think more clarity would be great. I think also for clarity stating at what point in a corresponding node the src route should be created would be good. I think its at the point of the Internet Layer (at ip6_output.c). I think for the Home Agent ND proxy and use of anycast address can only be verified via some testing at some point but should not hold up this draft going to PS. ALso the notes for reachability confirmation have to be tested for mobile via IPv6 NUD. I assume the mobile node is fine with ICMPv6 msgs from interim routers prior to reaching the dst address, as the router will send back to the care-of-address if for example PMTU to big occurs. The router won't look for dst options. I think several issues in the future should be reviewed as we gain more implementation experience: 1. Ingress Filtering - Geez this is still work in progress and I am not clear this will apply to IPv6 with mandated authentication. If not it changes what we do with the Home Agent option. Is Ingress Filtering to be a FULL STD within the IETF? Is that how its being tracked? 2. I think avoiding the src route would be good but we don't want to put more work on the "mobile" node it has to much to do now. 3. Is 16bits for the lifetimes and Refresh and such too small. This leaves only 18.2 hours. What if I leave my mobile node in one place over the weekend, I don't want to have to rebind everything. THis is why we made most of our lifetimes in IPv6 (except for Router Lifetime) 32 bits. I also joined the mobile mail list, but thought this mail needed to go to both lists. Dave and Charlie and the Mobile WG have done a good job to get this technology integrated and started for IPv6. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 3 23:07:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA28698; Wed, 3 Sep 1997 22:57:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA28691; Wed, 3 Sep 1997 22:56:58 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA15146; Wed, 3 Sep 1997 22:59:39 -0700 Received: from ux5.sp.cs.cmu.edu (UX5.SP.CS.CMU.EDU [128.2.198.221]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA11936 for ; Wed, 3 Sep 1997 22:59:49 -0700 Received: from localhost by ux5.sp.cs.cmu.edu id aa28381; 4 Sep 97 1:59 EDT To: bound@zk3.dec.com Cc: Erik Nordmark , mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, solomon@comm.mot.com In-Reply-To: Your message of "Thu, 04 Sep 1997 00:29:26 EDT" <9709040429.AA07242@wasted.zk3.dec.com> From: Dave Johnson Subject: (IPng 4382) Re: Mobile IPv6 requirements on all nodes Date: Thu, 04 Sep 1997 01:59:00 -0400 Message-ID: <28379.873352740@ux5.sp.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1373 Jim, It's good to hear the positive words from you about the Mobile IPv6 requirements on all nodes. I've been traveling (too much!) and am behind on replying to some email, including your previous message, but I'll send a more detailed reply shortly. I am currently working on a new version of the draft and will incorporate your comments, as well as any others I receive. By the way, in our Mobile IPv6 implementation at CMU, we have now added support for the Home Address option, and now support everything up through the current version (03) of the draft. We'll be releasing the code in the next week or two. Adding the Home Address option support was actually fairly easy, although there are some details to make it work right that will be in the new draft (04). In case others are interested in sending comments on the current draft, the file name is draft-ietf-mobileip-ipv6-03.txt. Please send your comments to the Mobile IP mailing list at mobile-ip@smallworks.com. Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 4 06:04:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA29048; Thu, 4 Sep 1997 05:55:34 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA29041; Thu, 4 Sep 1997 05:55:24 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA25540; Thu, 4 Sep 1997 05:58:07 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA19125 for ; Thu, 4 Sep 1997 05:58:17 -0700 Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id IAA25470 for ; Thu, 4 Sep 1997 08:51:20 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA02132; Thu, 4 Sep 1997 08:51:20 -0400 Message-Id: <9709041251.AA02132@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4383) ND Prefix "L" bit on/off Date: Thu, 04 Sep 1997 08:51:20 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 673 Folks, In ND if the "L" bit is set to on we are to set it and treat the prefix on-link. But, if the "L" bit is then set to "off" the ND spec is not clear to me that we should set the "L" bit off for the prefix per words in 6.3.4. I think we have to set it to off. Comments???? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 4 07:53:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA29160; Thu, 4 Sep 1997 07:44:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA29153; Thu, 4 Sep 1997 07:44:17 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA22795; Thu, 4 Sep 1997 07:47:01 -0700 Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA16392 for ; Thu, 4 Sep 1997 07:47:05 -0700 Received: from [203.154.130.33] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.51) id AA01205; Fri, 5 Sep 1997 00:46:42 +1000 (from kre@cs.mu.oz.au) Received: from aussie.cs.mu.OZ.AU (kre@localhost [127.0.0.1]) by aussie.cs.mu.OZ.AU (8.8.5/8.8.5) with ESMTP id EAA00658; Thu, 4 Sep 1997 04:02:13 +0700 (ICT) From: Robert Elz To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4384) Re: Following DNS record discussion in Munich... In-Reply-To: Your message of "Tue, 02 Sep 1997 17:46:30 -0400." <970902174629.ZM28805@seawind.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Sep 1997 04:02:12 +0700 Message-Id: <654.873320532@aussie.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 10553 Date: Tue, 2 Sep 1997 17:46:30 -0400 From: huitema@bellcore.com (Christian Huitema) Message-ID: <970902174629.ZM28805@seawind.bellcore.com> Uh? Potential of errors include wrong name for net in AAAA record (human error) Sure, but balance the likelihood of the human mistyping the 64 bits (or however many) of meaningless hex gibberish, against the likelihood of mistyping the domain name part (a meaningful human name). Sure, either can happen, but I'd submit that it's more likely that an error would be in the all hex AAAA type than in the mixed version (an error in the hex part of the mixed version is identically likely in the two cases). Then there's the possibility that the network AAAA record might contain an error - that's the one I worry very little about, as it is a catastrophic error, everything breaks when that one goes wrong, which means the human who made the error finds about it very very quickly, and because of that can fix it just as quickly (and for the same reason, is likely to be much more careful dealing with this one special record, tripple checking that the right numbers have been entered, which for hundreds, or thousands, of regular AAAA records they'd never bother with). and DNS server for reference record going antipodic, In most cases it is very likely to be the same server, so we're talking about a small fraction of the AAAA lookups that happen here - and in any case this is what we have redundant servers for, we know that sometimes servers will break, and we design to cope. So this one looks to be a small problem, which is already adequately dealt with. plus many more. Like? So far I don't think we have any. That cannot occur if you need exactly one record. If you talk about simply absolutes, the number of places an error might occur, then yes, I'd agree, if you add something extra, there's a new possibility for error. But that's an insane metric, you need to consider the probabilities of the errors, and I'd submit that the split AAAA actually reduces the probability of an undetected error, rather than raises it. Well, AAAA up to date, network record off base ? Wrong TTL ? Again, consider the probabilities - with the split record, when changes are made (which is the time when those inconsistencies can happen) we have one of two cases - either the id portion (the hex that is left in the first AAAA record) changes, in which case the possible inconsistencies are exactly what they would be with a unified AAAA, or the network number part changes (the value of the AAAA from the name), in which case it can certainly happen that you'd get an old cached net number value, which is exactly the same as if you'd received an old cached full AAAA before, no different at all - except that being a special case record, more care is likely to be taken in making changes to that one than your average 128 bit AAAA record, and more effort is likely to be taken to ensure that it is properly timed out of caches, or at least, where the DNS admins care about this consistency, which some do, with the split scheme they have the tools to do things well and carefully, with the 128 bit only AAAA scheme, they don't, as they can't even guarantee to find all of the hosts that should be updated. And the third possibility is that both change. That is (roughly) that an old name is assigned to a new piece of hardware with new connectivity, there old cache info is irrelevant (or as irrelevant as it would be for 128 bit AAAAs) - if the network name part of the new record is an existing old network name, then its cache data should be stable, if it is a new one, it will have no cache data, if we're changing the value of a network name AAAA record, and changing the host AAAA record at the same time, we just have both the above cases simultaneously, each already shown to be be no worse than changing a single AAAA. Wrong TTL? What's that? A TTL is a 32 bit integer, any value is legal. What we can have is a TTL longer than we would like - that just leads to the possibilities of cache inconsistencies just covered above (where the host name AAAA has the big TTL, we have the same problem with split AAAA records and 128 bit ones, where the network name AAAA has the bad TTL we actually have a defence available - we can change the name in the host AAAA record, to a new one, with a sane TTL, and simply allow the bogus AAAA record to time out over however many years it takes, unused, and unwanted). We can also have a TTL that is too short - all that causes is excess traffic, easily remedied. Now just in case anyone thinks that Christian and I are having a big argument here, and that because of that this proposal may be a bit risky, we're not. I know Christian would never have proposed the method if he didn't believe it would work - by pointing out the possible drawbacks he's just showing proper care and diligence. His problem however is that there are so few real drawbacks that he has had to stretch quite a bit to find something to note - lest he be criticised for ignoring problems. What I'm doing is just pointing out that the drawbacks are so trivially minor that they can be ignored, just in case someone reads Christian's proposal sees his list of potential problems, and decides that this looks to be too risky to bother with, without properly evaluating the risks. And now to details... You spare a few bytes (typically 6 to 8) but loose compatibility with the existing spec. Yes. Am I concerned? No. The existing code base of AAAA using resolvers and nameservers is so small that throwing it out and making this change, at this comparatively early stage, if it will be an overall benefit, is clearly the right thing to do. Normally, I wouldn't care much about a few bytes here or there, but packet size has become one of the major DNS issues, and anything that adds needless bloat is a real problem there. There will certainly be work done on the DNS to permit bigger packets than are currently allowed, but whatever is done there, we really don't want fragmented DNS packets, and as long as the required MTU remains at 576 DNS servers will never want to send longer than 576 without fragmenting the packet - unfortunately the DNS is one of those applications for which PMTU discovery is just a dream, and no help at all. If we can decide to raise that limit to 1500 as was postulated in Munich (I'm not sure I recall what the current state is of that proposal) that will help a lot, but 1500 is still pretty small. (This is actually less of an issue for IPv4 DNS than for IPv6 - for v4, the DNS server can just send its packet of whatever size it believes the resolver can handle, and in many cases it will arrive safely, with no fragmentation required, if a small MTU link is encountered, the routers fragment - for IPv6 the server cannot rely on this assistance, it must fragment itself if the packet is larger than the PMTU, and since it will almost never know that value, it must fragment when greater than the minimum required MTU). The one issue with the 16 byte size of IPv6 addresses (as opposed to, say, 8 byte addresses) that I ever had was the DNS packet size problem, your split address proposal, with my variation on the formatting, comes close to eliminating that as an issue totally - if the extra AAAA record won't fit in the packet (the value of the name part) it can simply be omitted, and if the resolver happened not to know it anyway, a separate query will discover that one. Note that the most likely problem here comes during renumbering, when a host has multiple prefixes, the old ones on the way to being phased out, and the new ones, being phased in. During that period the host is likely to have multiple AAAA records (especially using dynamic DNS, where the host registers its own addresses - as it has no way of knowing why this new prefix just appeared, or which other prefix may no longer really be wanted). With the single AAAA scheme, it is possible that a host with several interfaces (say a router with 20 or so), and with 2 or 3 prefixes for each, simply wouldn't be able to fit the entire RRset into a DNS answer (60 16 byte addresses is 960 bytes, way above the magic 576, not even bothering to count the name, and other packet overheads). (The DNS can deal with this by reverting to TCP for the lookup, but that has horrid performance penalties.) The split scheme allows just the network name part to hold the multiple prefixes, so we'd need to fit just 23 (rather than 60) addresses, and further, 20 of those would be shorter, as the name would compress away to just 2 bytes in all but two occurrences. (Note, the assumption here is that for this router, we enter the AAAA records for its interfaces including the local subnet numbers with the name AAAA record, each of those referring to one network prefix record, which would contain the site's prefixes, 3 we're assuming here). Even if the router's AAAA records all referred to names for each subnet, and each of those names referred to another name for the site prefix, we'd still have a net win. I think this (DNS packet size) is an important enough issue, that simply scrapping the current AAAA and installing a new one which will save those bytes is more important than keeping compatability with what now is in use. But, naturally, we could have a new number assigned to the new AAAA record, and servers that wanted to keep supporting the old format, could. Even better, such servers could synthesise the old AAAA record out of the components of the new one and return that when queried. The security (signatures and stuff) implications that killed that as a general scheme aren't relevant now, as none of the (small number of) legacy systems we're trying to support is using DNS security with AAAA records anyway - for 6 months or a year, having this transition method in place (if someone, Jim for example, thinks it is needed at all) wouldn't harm anyone. Anyone running IPv6 code now and not planning on replacing it with newer stuff inside a year isn't worth worrying about. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 4 08:23:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA29217; Thu, 4 Sep 1997 08:13:10 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA29210; Thu, 4 Sep 1997 08:12:58 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA01086; Thu, 4 Sep 1997 08:15:41 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA26042 for ; Thu, 4 Sep 1997 08:15:49 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA22933; Thu, 4 Sep 1997 10:08:57 -0500 Message-Id: <199709041508.KAA22933@gungnir.fnal.gov> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4385) Re: ND Prefix "L" bit on/off In-reply-to: Your message of Thu, 04 Sep 1997 08:51:20 EDT. <9709041251.AA02132@wasted.zk3.dec.com> Date: Thu, 04 Sep 1997 10:08:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1220 > But, if the [ND Router Advertisement Prefix Information Option] "L" > bit is then set to "off" the ND spec is not clear to me that we > should set the "L" bit off for the prefix per words in 6.3.4. > > I think we have to set it to off. I take it that the second use of "L bit" refers to a flag in the hosts' prefix list. The "conceptual model" doesn't include any such flag and, by my reading, an advertised prefix with L=0 never gets put into the prefix list. Section 5.1 defines the prefix list as "A list of the prefixes that define a set of addresses that are on-link." But on the other hand, this is somewhat obfuscated by the phrase in section 5.2, "The sender performs a longest prefix match against the Prefix List ..." What *longest* match? A match is a match. If you find any match, the destination is on-link. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 4 09:49:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29264; Thu, 4 Sep 1997 09:38:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29257; Thu, 4 Sep 1997 09:38:05 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA23527; Thu, 4 Sep 1997 09:40:48 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA26644 for ; Thu, 4 Sep 1997 09:40:56 -0700 Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id MAA38502; Thu, 4 Sep 1997 12:38:06 -0400 (EDT) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA04644; Thu, 4 Sep 1997 12:38:09 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA20852; Thu, 4 Sep 1997 12:38:05 -0400 Message-Id: <9709041638.AA20852@cichlid.raleigh.ibm.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4386) Re: ND Prefix "L" bit on/off In-Reply-To: Your message of "Thu, 04 Sep 1997 08:51:20 EDT." <9709041251.AA02132@wasted.zk3.dec.com> Date: Thu, 04 Sep 1997 12:38:05 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3231 > In ND if the "L" bit is set to on we are to set it and treat the prefix > on-link. Yep. > But, if the "L" bit is then set to "off" the ND spec is not clear to me > that we should set the "L" bit off for the prefix per words in 6.3.4. The intent is that you should NOT. Here is some relevant text: In 4.6.2. Prefix Information: > L 1-bit on-link flag. When set, indicates that this > prefix can be used for on-link determination. When > not set the advertisement makes no statement about > on-link or off-link properties of the prefix. For > instance, the prefix might be used for address > configuration with some of the addresses belonging > to the prefix being on-link and others being off- > link. Later, in 6.3.4, Processing Received Router Advertisements: > Prefix Information options that have the "on-link" (L) flag set > indicate a prefix identifying a range of addresses that should be > considered on-link. Note, however, that a Prefix Information option | > with the on-link flag set to zero conveys no information concerning | > on-link determination and MUST NOT be interpreted to mean that | > addresses covered by the prefix are off-link. The default behavior | > (see Section 5.2) when no information is known about an address is to | > send the packets to a default router and the reception of a Prefix | > Information option with the "on-link " (L) flag set to zero does not | > change this behavior. The reasons for an address being treated as | > on-link is specified in the definition of "on-link" in Section 2.1. | > Prefixes with the on-link flag set to zero would normally have the | > autonomous flag set and be used by [ADDRCONF]. This paragraph is supposed to have made the point clear. However, the second half starting with "The default behavior..." could be a bit misleading. How about we add the sentence: The only way to cancel a previous on-link indication is to advertise that prefix with the L-bit set and the Lifetime set to zero. "Matt Crawford" writes: > into the prefix list. Section 5.1 defines the prefix list as "A list > of the prefixes that define a set of addresses that are on-link." > But on the other hand, this is somewhat obfuscated by the phrase in > section 5.2, "The sender performs a longest prefix match against the > Prefix List ..." What *longest* match? A match is a match. If you > find any match, the destination is on-link. Strictly speaking, you are right. That text is there for the benefit of multi-homed hosts, in which case you must do the longest match in order to identify the correct outgoing interface. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 4 11:33:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA29485; Thu, 4 Sep 1997 11:21:44 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA29478; Thu, 4 Sep 1997 11:21:33 -0700 Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id LAA01322; Thu, 4 Sep 1997 11:24:14 -0700 (PDT) Date: Thu, 4 Sep 1997 11:23:43 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4387) Re: (mobile-ip) Re: Mobile IPv6 requirements on all nodes To: bound@zk3.dec.com, pferguso@cisco.com, dts@openroute.com Cc: Erik Nordmark - Sun Sweden , mobile-ip@SmallWorks.COM, ipng@sunroof.eng.sun.com, solomon@comm.mot.com In-Reply-To: "Your message with ID" <9709040429.AA07242@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3492 Jim, It is good that you are looking at the mobile IPv6 specifications from an implementors perspective and I'd encourage other IPv6 implementors to do the same so that we can make the document as clear as possible. > I think several issues in the future should be reviewed as we gain more > implementation experience: > > 1. Ingress Filtering - Geez this is still work in progress and I am > not clear this will apply to IPv6 with mandated authentication. > If not it changes what we do with the Home Agent option. > > Is Ingress Filtering to be a FULL STD within the IETF? Is that > how its being tracked? Good question. I've included the authors of draft-ferguson-ingress-filtering-02.txt on the to list to get their views on what will happen to the draft. As far as I know the draft is not going through any IETF working group which would make it hard to put it on the standards track. > 2. I think avoiding the src route would be good but we don't want > to put more work on the "mobile" node it has to much to do > now. You somehow have to include two destination addresses in the packet sent to the mobile node (the care of address and the home address). Currently using a source route is the most space efficient way to include the extra address. Are you proposing something else? One could envision instead creating yet another destination option (e.g. Destination Home Address option) which would be distinct from the current Home address option which applies to the source of the packet. > 3. Is 16bits for the lifetimes and Refresh and such too small. > This leaves only 18.2 hours. What if I leave my mobile node > in one place over the weekend, I don't want to have to rebind > everything. THis is why we made most of our lifetimes in > IPv6 (except for Router Lifetime) 32 bits. I think you have a point when the binding is done with the home agent. However, when sending binding updates to correspondent nodes the lifetime (in the binding update) is the last fallback for maintaining communication in certain cases thus you want the lifetime to be shorter than the time it takes for a TCP connection to give up. An example of such a case is when two mobile nodes are communicating and they both move at about the same time. If their previous default routers does not accept functioning as a home agent for their previous care of address then the two mobiles will fail to communicate until the binding cache entries time out. They will both send (based on their binding update list) a binding update to each other which will be addressed to their previous care of address hence it will be dropped on the floor. Thus if we want to be able to have long lifetimes (longer than 30 seconds to 2 minutes) for the binding cache in correspondent nodes we need a more robust mechanism for determining that the binding cache entry might be stale. I think such a mechanism can be built by having the CH send a binding request message when it does not have end-to-end reachability confirmation for the binding cache entry. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 4 11:55:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA29507; Thu, 4 Sep 1997 11:42:59 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA29500; Thu, 4 Sep 1997 11:42:44 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA02401; Thu, 4 Sep 1997 11:45:26 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA12132 for ; Thu, 4 Sep 1997 11:45:34 -0700 Received: by mail3.microsoft.com with Internet Mail Service (5.0.1459.27) id ; Thu, 4 Sep 1997 11:43:17 -0700 Message-ID: From: Richard Draves To: "'bound@zk3.dec.com'" , ipng@sunroof.eng.sun.com Subject: (IPng 4388) RE: ND Prefix "L" bit on/off Date: Thu, 4 Sep 1997 11:42:34 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1741 Jim, do I understand your question to mean, when processing an RA with a prefix with on-link flag of zero, should the prefix be removed from the conceptual model's on-link prefix list? If that's the question, I think the answer is pretty clearly no. If the on-link flag is zero, then the option does not affect the on-link prefix list in any way. The "right" way to remove an entry from the on-link prefix list is to use the lifetimes. > -----Original Message----- > From: bound@zk3.dec.com [SMTP:bound@zk3.dec.com] > Sent: Thursday, September 04, 1997 5:51 AM > To: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 4383) ND Prefix "L" bit on/off > > Folks, > > In ND if the "L" bit is set to on we are to set it and treat the > prefix > on-link. > > But, if the "L" bit is then set to "off" the ND spec is not clear to > me > that we should set the "L" bit off for the prefix per words in 6.3.4. > > I think we have to set it to off. > > Comments???? > > thanks > /jim > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 4 15:02:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00145; Thu, 4 Sep 1997 14:52:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00137; Thu, 4 Sep 1997 14:52:05 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA28783; Thu, 4 Sep 1997 14:54:48 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA16754 for ; Thu, 4 Sep 1997 14:54:53 -0700 Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id RAA01180; Thu, 4 Sep 1997 17:41:41 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA07093; Thu, 4 Sep 1997 17:41:40 -0400 Message-Id: <9709042141.AA07093@wasted.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4389) Re: ND Prefix "L" bit on/off In-Reply-To: Your message of "Thu, 04 Sep 1997 12:38:05 -0400." <9709041638.AA20852@cichlid.raleigh.ibm.com> Date: Thu, 04 Sep 1997 17:41:39 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 557 Thomas, >The only way to cancel a previous on-link indication is to >advertise that prefix with the L-bit set and the Lifetime set to >zero. Works for me. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 4 19:41:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA00541; Thu, 4 Sep 1997 19:30:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA00534; Thu, 4 Sep 1997 19:30:49 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA08153; Thu, 4 Sep 1997 19:33:32 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA17412; Thu, 4 Sep 1997 19:33:42 -0700 Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id WAA32521; Thu, 4 Sep 1997 22:29:22 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA16651; Thu, 4 Sep 1997 22:29:16 -0400 Message-Id: <9709050229.AA16651@wasted.zk3.dec.com> To: Erik Nordmark Cc: pferguso@cisco.com, dts@openroute.com, mobile-ip@SmallWorks.COM, ipng@sunroof.eng.sun.com, solomon@comm.mot.com Subject: (IPng 4391) Re: (mobile-ip) Re: Mobile IPv6 requirements on all nodes In-Reply-To: Your message of "Thu, 04 Sep 1997 11:23:43 MST." Date: Thu, 04 Sep 1997 22:29:15 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5765 Erik, >> I think several issues in the future should be reviewed as we gain more >> implementation experience: >> >> 1. Ingress Filtering - Geez this is still work in progress and I am >> not clear this will apply to IPv6 with mandated authentication. >> If not it changes what we do with the Home Agent option. >> >> Is Ingress Filtering to be a FULL STD within the IETF? Is that >> how its being tracked? >Good question. I've included the authors of >draft-ferguson-ingress-filtering-02.txt on the to list to get their views on >what will happen to the draft. As far as I know the draft is not going through >any IETF working group which would make it hard to put it on the >standards track. Ouch. I have a real problem saying that Mobile cannot use its home agent address as the source address and then possibly a dst-option with the care-of-address because of a spec that does not have a working group. This don't sit well with me at all. But I assume the Mobile WG has determined this has to be the case. I don't see fighting this battle before going to PS status but I certainly will do what I can to validate "world wide" how many enterprises that are lets say fortune 500 companies that actually use Ingress Filtering, before IPv6 Mobile reaches FULL STD as a Global Internet Standard. I will shut up now as this really XXXXX's me off. >> 2. I think avoiding the src route would be good but we don't want >> to put more work on the "mobile" node it has to much to do >> now. >You somehow have to include two destination addresses in the packet sent >to the mobile node (the care of address and the home address). >Currently using a source route is the most space efficient way to >include the extra address. Yep. Another idea Charlie mentioned to me is to use one of those new bits available in the IPv6 header to denote its for a mobile node. Then the mobile node knows its from a corresponding node who has a binding update. My comment about more work for the mobile node is germain too. Right now the source route makes it much easer on the mobile node, which already has a lot of work to do (e.g. maintain binding lists. default routers, home agent proxy location, etc..). I am not clear not doing the src route is a big win. >Are you proposing something else? Not right now. But if we had the IP Dynamic Update Address part I work on as a research activity then we would have a way for the mobile node to dynamically tell any correspondent node please start using this new address. But this would require changes to upper layer protocol control blocks and notification to applications (esp UDP). THis is the work Christian Huitema and I produced independently with different views but the same objective. But this would take much work to even think about putting into the game now. I will propose this once I feel it will really work with running code and quite frankly I just don't got the time right now. But it will be useful for non-mobile situations too and if it is germain folks can look at it. If I can (and I probably can't) I will try to get a spec out before D.C. just for grins. >One could envision instead creating yet another destination option >(e.g. Destination Home Address option) which would be distinct from the >current Home address option which applies to the source of the packet. Yes. But will that also create more work for the mobile node? And is it worth it. I think moving this to PS and getting it implemented is a good idea at this point I guess. >> 3. Is 16bits for the lifetimes and Refresh and such too small. >> This leaves only 18.2 hours. What if I leave my mobile node >> in one place over the weekend, I don't want to have to rebind >> everything. THis is why we made most of our lifetimes in >> IPv6 (except for Router Lifetime) 32 bits. >I think you have a point when the binding is done with the home agent. >However, when sending binding updates to correspondent nodes the lifetime >(in the binding update) is the last fallback for maintaining communication >in certain cases thus you want the lifetime to be shorter than the time it >takes for a TCP connection to give up. An example of such a case >is when two mobile nodes are communicating and they both >move at about the same time. If their previous default routers does not >accept functioning as a home agent for their previous care of address then >the two mobiles will fail to communicate until the binding cache entries >time out. They will both send (based on their binding >update list) a binding update to each other which will be addressed to >their previous care of address hence it will be dropped on the floor. Good point. >Thus if we want to be able to have long lifetimes (longer than 30 seconds to 2 >minutes) for the binding cache in correspondent nodes we need a more robust >mechanism for determining that the binding cache entry might be stale. >I think such a mechanism can be built by having the CH send a binding request >message when it does not have end-to-end reachability confirmation for >the binding cache entry. I agree. Kind of like long reaching neighbor discovery NUD. But again, it might be good to just move forward with what exists now and get it running and using the soon to be IPv6 leg of the 6bone to test it on. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 5 05:33:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA00944; Fri, 5 Sep 1997 05:20:20 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA00937; Fri, 5 Sep 1997 05:20:05 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA15320; Fri, 5 Sep 1997 05:22:48 -0700 Received: from dcn.soongsil.ac.kr (dcn.soongsil.ac.kr [203.253.2.104]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA08816 for ; Fri, 5 Sep 1997 05:22:58 -0700 Received: from dragon.soongsil.ac.kr ([203.253.3.77]) by dcn.soongsil.ac.kr (8.6.9H1/8.9.11h) with SMTP id WAA03634 for ; Fri, 5 Sep 1997 22:27:02 +1000 Message-Id: <3.0.1.32.19970905220011.0069b1b4@dcn.soongsil.ac.kr> X-Sender: dragon@dcn.soongsil.ac.kr X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 05 Sep 1997 22:00:11 +0900 To: ipng@sunroof.eng.sun.com From: kim yong sin Subject: (IPng 4393) Q:DNS server implement Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1193 I'm tring config DNS server for ipv6. 1. BIND version 8 is support AAAA type. ---> download 2. make (compile) 3. make 'zone file' for domain (q1: Can I involve ipv4 and ipv6 hosts information into same zone file?) anyway, i write ipv4 and ipv6 hosts into same zone file. For 'nslookup', it operates well. 4. for client, first it searchs 'hosts' file, and if don't exist that host name then it sends 'query' message to DNS server. (q2: Does client sends 'query' message using ipv6 packet?) (q3: This case, Which 'resolv.conf' file contains DNS server address ipv6 or ipv4 addr?) 5. If DNS server can't find that host name, it send to other DNS server (q4: Which DNS server for ipv6 avilable?) If i can't config DNS server, i hope using resolver-only client and query to avilable server Thanks -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 5 11:19:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01547; Fri, 5 Sep 1997 11:09:38 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01540; Fri, 5 Sep 1997 11:09:31 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id LAA21782 for ; Fri, 5 Sep 1997 11:12:18 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA04821; Fri, 5 Sep 1997 11:10:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA01512; Fri, 5 Sep 1997 10:59:43 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA09957; Fri, 5 Sep 1997 11:02:26 -0700 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA28089; Fri, 5 Sep 1997 11:02:15 -0700 Received: (from smap@localhost) by ns.newbridge.com (8.6.12/8.6.12) id NAA29427; Fri, 5 Sep 1997 13:59:31 -0400 Received: from kanata-gw1(192.75.23.72) by ns via smap (V1.3) id sma029398; Fri Sep 5 13:59:14 1997 Received: from kanmaster.ca.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 5 Sep 1997 17:59:14 UT Received: (from smap@localhost) by ca.newbridge.com. (8.8.6/8.8.6) id NAA06247; Fri, 5 Sep 1997 13:59:06 -0400 (EDT) Received: from lobster.us.newbridge.com(138.120.85.102) by kanmaster.ca.newbridge.com via smap (V1.3) id sma005981; Fri Sep 5 13:57:55 1997 Received: from lobster by lobster.nni (SMI-8.6/SMI-SVR4) id NAA02529; Fri, 5 Sep 1997 13:52:18 -0400 Date: Fri, 5 Sep 1997 13:52:18 -0400 (EDT) From: Joel Halpern Reply-To: Joel Halpern Subject: (IPng 4397) Re: (mobile-ip) Re: Mobile IPv6 requirements on all nodes To: bound@zk3.dec.com cc: Erik Nordmark , pferguso@cisco.com, dts@openroute.com, mobile-ip@SmallWorks.COM, ipng@sunroof.eng.sun.com, solomon@comm.mot.com In-Reply-To: <9709050229.AA16651@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 944 The ingress filtering issue is NOT becuase of an internet draft with no working group. That internet draft (and IAB discussions related to it) reflect a growing practice in the internet. And requiring Mobile-IP to work with "the ways things are actually done" is a very reasonable restriction. Further, the reason this was originally brought to the working group as an issue was at the request of the IAB, who considers that ingress filtering will be a common and useful tool for ISPs. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 5 19:28:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA02551; Fri, 5 Sep 1997 19:19:24 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA02544; Fri, 5 Sep 1997 19:19:15 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA27449; Fri, 5 Sep 1997 19:21:58 -0700 Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA10948; Fri, 5 Sep 1997 19:21:53 -0700 Received: from rodan.UU.NET by relay1.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQdftp05460; Fri, 5 Sep 1997 22:22:04 -0400 (EDT) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQdftp07078; Fri, 5 Sep 1997 22:21:44 -0400 (EDT) Message-Id: To: Joel Halpern cc: bound@zk3.dec.com, Erik Nordmark , pferguso@cisco.com, dts@openroute.com, mobile-ip@SmallWorks.COM, ipng@sunroof.eng.sun.com, solomon@comm.mot.com Subject: (IPng 4398) Re: (mobile-ip) Re: Mobile IPv6 requirements on all nodes In-reply-to: Your message of "Fri, 05 Sep 1997 13:52:18 EDT." Date: Fri, 05 Sep 1997 22:21:44 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1294 High Heresy time, folks.... i have come to believe that "IP mobility" which attempts to avoid "3-corner routes" is almost certainly doomed. it has become clear that in the real world, if you want to be "remote from your home site but with your previous IP address", in most cases, the remote also wants to be (logically) "within the site security boundary" (ie, "behind the firewall") but actually remote, which implies crypto tunnels. and what's happening these days is that we have at least half a dozen tunneling schemes around (and more appearing on the doorstep every week or so), some with crypto, some with walnuts, and some with hot-fudge and walnuts and crypto, and that the existing IP-mobility stuff is yet just another variant with free extra complexity. we need to get serious about deciding the architectural question of exactly how many ways we need (or want) to have to do the same job. -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Sep 7 18:36:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01120; Sun, 7 Sep 1997 18:18:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01113; Sun, 7 Sep 1997 18:18:43 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA24392; Sun, 7 Sep 1997 18:21:28 -0700 Received: from dcn.soongsil.ac.kr (dcn.soongsil.ac.kr [203.253.2.104]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA04348 for ; Sun, 7 Sep 1997 18:21:38 -0700 Received: from dragon.soongsil.ac.kr ([203.253.3.77]) by dcn.soongsil.ac.kr (8.6.9H1/8.9.11h) with SMTP id LAA04955 for ; Mon, 8 Sep 1997 11:25:41 +1000 Message-Id: <3.0.1.32.19970908105853.0069da44@dcn.soongsil.ac.kr> X-Sender: dragon@dcn.soongsil.ac.kr X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 08 Sep 1997 10:58:53 +0900 To: ipng@sunroof.eng.sun.com From: kim yong sin Subject: (IPng 4403) Q:DNS server implement Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1193 I'm tring config DNS server for ipv6. 1. BIND version 8 is support AAAA type. ---> download 2. make (compile) 3. make 'zone file' for domain (q1: Can I involve ipv4 and ipv6 hosts information into same zone file?) anyway, i write ipv4 and ipv6 hosts into same zone file. For 'nslookup', it operates well. 4. for client, first it searchs 'hosts' file, and if don't exist that host name then it sends 'query' message to DNS server. (q2: Does client sends 'query' message using ipv6 packet?) (q3: This case, Which 'resolv.conf' file contains DNS server address ipv6 or ipv4 addr?) 5. If DNS server can't find that host name, it send to other DNS server (q4: Which DNS server for ipv6 avilable?) If i can't config DNS server, i hope using resolver-only client and query to avilable server Thanks -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 8 08:45:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA01530; Mon, 8 Sep 1997 08:34:34 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA01523; Mon, 8 Sep 1997 08:34:29 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id IAA22977 for ; Mon, 8 Sep 1997 08:37:18 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06711; Mon, 8 Sep 1997 08:35:00 -0700 Received: from hsmpka.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA02562; Fri, 5 Sep 1997 19:55:00 -0700 Received: from finesse by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA18835; Fri, 5 Sep 1997 19:57:46 -0700 Message-Id: <199709060257.TAA18835@hsmpka.eng.sun.com> Date: Fri, 5 Sep 1997 19:57:40 -0700 (PDT) From: Charles Perkins Reply-To: Charles Perkins Subject: (IPng 4404) Re: (mobile-ip) Re: Mobile IPv6 requirements on all nodes To: mo@UU.NET Cc: pferguso@cisco.com, dts@openroute.com, mobile-ip@SmallWorks.COM, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: G1pKg2VvCGsHunCOI/58gg== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2690 > High Heresy time, folks.... Were we having a religion? > it has become clear that in the real world, if you want to be "remote > from your home site but with your previous IP address", in most cases, > the remote also wants to be (logically) "within the site security > boundary" (ie, "behind the firewall") but actually remote, which implies > crypto tunnels. The mobile-IP group, recognizing the problem you describe, is trying to devise realistic ways to co-exist with real world security concerns. The problem is hard, and as a result the solutions are taking a while to understand. I don't think it means that the effort is doomed. It could be premature, if the necessary tools to create the right solution are not yet widely available. The drivers for Mobile IP remain quite interesting: - the possible deployment of wireless LANs - the reduction in cell sizes - user convenience The evidence so far indicates that wireless LANs are failing to live up to expectations, cell sizes are still conveniently large, and most Internet nomads will put up with anything. I don't think those three observations will remain true forever. If we're talking about IPv6, then other factors enter the picture which may be more compelling. > and what's happening these days is that we have at least half a dozen > tunneling schemes around (and more appearing on the doorstep every week or > so), some with crypto, some with walnuts, and some with hot-fudge and > walnuts and crypto, and that the existing IP-mobility stuff is yet just > another variant with free extra complexity. There's been a suggestion that we need a tunneling working group. I'm wholly in favor of such a thing, as long as it doesn't become a rubber stamp for existing approaches. By the way, I dispute your characterization that Mobile IP has "extra" complexity. > we need to get serious about deciding the architectural question of > exactly how many ways we need (or want) to have to do the same job. You said it! But that word you used, "deciding", requires a set of architectural criteria from which a decision can be made, and one or more people with the authority to make the decision. Are the criteria selected by the working group, or the IESG, or ...? What are the possible results of the decision? > -mo Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 8 10:04:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01674; Mon, 8 Sep 1997 09:53:13 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01667; Mon, 8 Sep 1997 09:53:04 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA11393; Mon, 8 Sep 1997 09:55:44 -0700 Received: from Conrad.Harvard.EDU (conrad.harvard.edu [128.103.65.122]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA13321 for ; Mon, 8 Sep 1997 09:55:36 -0700 Received: by Conrad.Harvard.EDU (Linux Smail3.1.28.1 #1) id m0x86vk-00096ZC; Mon, 8 Sep 97 12:44 EDT Date: Mon, 8 Sep 1997 12:44:52 -0400 (EDT) From: Andy Grosser To: Charles Perkins cc: mo@UU.NET, pferguso@cisco.com, dts@openroute.com, mobile-ip@SmallWorks.COM, ipng@sunroof.eng.sun.com Subject: (IPng 4405) Re: (mobile-ip) Re: Mobile IPv6 requirements on all nodes In-Reply-To: <199709060257.TAA18835@hsmpka.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 629 > > High Heresy time, folks.... > > Were we having a religion? 'Having' a religion? Is that like 'having' a tantrum or 'having' a milkshake? :) Oops... sorry. Now back to IPv6... --- Andy Grosser | andy@conrad.harvard.edu --- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 9 10:26:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03330; Tue, 9 Sep 1997 10:14:27 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03323; Tue, 9 Sep 1997 10:14:14 -0700 From: gfisher@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA00798; Tue, 9 Sep 1997 10:17:02 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA27964 for ; Tue, 9 Sep 1997 10:17:04 -0700 Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id NAA10122 for ; Tue, 9 Sep 1997 13:08:54 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA21696; Tue, 9 Sep 1997 13:08:53 -0400 Message-Id: <9709091708.AA21696@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: gfisher@zk3.dec.com Subject: (IPng 4406) Clarifications needed for Adv. Socket API options processing Date: Tue, 09 Sep 97 13:08:53 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4350 Greetings, I'm currently tasked with implementing the Advanced Socket API. Currently I'm working on section 6.3 "Hop-by-Hop and Destination Options Processing" and I feel that some clarification is needed. The following points are what I've come up with so far. inet6_option_space ------------------ . In the description it states "The argument is the size of the structure defining the option, which must include any pad bytes at the beginning (the Y value), the type byte, the length byte, and the option data". I think this might need more clarification. Take for example an alignment requirement of 8n+1. After the 'hdr ext len' byte, we will need an additional 7 bytes to get to 8n+1 alignment. The Y value of 1 doesn't cut it. . There needs to be some discussion about padding in between options when we have more than one. In the options examples, ip6_X_opt and ip6_Y_opt each have a structure member on the front end which is the padding. If this is an absolute requirement for all options structures then this should be stated. . The discussion of overestimating the amount of space by N-1 cmsghdr structures is not clear. In the example a call is made to option_space and the argument passed in is sizeof(X)+sizeof(Y). Option_space has no idea we're talking about 2 options here. "The argument is the size of the structure defining the option" so one cmsghdr structure is assumed. inet6_option_append ------------------- . In the examples, the wording "...function notices that the appended data requires 4 bytes of padding at the end, to make the size of the ancillary data object a multiple of 8...". The implies that the function always does this before returning as the function cannot know that it will be called again. If this is the case, it should be spelled out in the description of the function rather than in the text of the example. . Given that the above 'padding before return' is true, doesn't this do away with the "multx" parameter ? . Given that the 'padding before return' is not true, what should the kernel do when it sees an A.D.O. which is not a multiple of 8 octets ? inet6_option_alloc ------------------ . The first paragraph describing this function is essentially the same as the first paragraph describing the append function, except for the return values. When read in conjuction with the second paragraph, the two seem to almost contradict themselves. I think a slight reword of "This function appends ..." would be helpful. . In the description of the 'datalen' argument, the second sentence could perhaps be reworded to something like "This value is required as an argument to allow the function to determine if padding has to be written at the predicted end of the option data". . Would the above issue of "padding before return" also nullify the need for the "multx" parameter? in general ---------- . There should be some wording somewhere that spells out that there should be no padding between the cmsghdr and the next header/hdr ext len fields. . Perhaps another example or two showing odd cases of data fields which don't so conveniently fit such as options with 2,3 and 5 octet fields or perhaps an option with 1,4,5 and 7 octets to give everyone a good flavor for the alignment issue. . With respect to the alignment issue, I think some clarification is needed to show the decision making that goes into determining the 'Xn+Y' numbers. . Further on in the examples we have "Alternately, the application could build two ancillary data objects, one per option...The kernel must combine these into a single..." What if we just disallow this and save work and complexity in the kernel? What does everyone think ?? Thanks much, Gary Fisher -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 9 11:18:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA03396; Tue, 9 Sep 1997 11:04:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA03389; Tue, 9 Sep 1997 11:03:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA16837; Tue, 9 Sep 1997 11:06:39 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA14152 for ; Tue, 9 Sep 1997 11:06:38 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA00512; Tue, 9 Sep 97 11:04:38 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id LAA06038; Tue, 9 Sep 1997 11:06:36 -0700 Date: Tue, 9 Sep 1997 11:06:36 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199709091806.LAA06038@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4407) Re: Clarifications needed for Adv. Socket API options processing X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1077 Gary, > > . Further on in the examples we have "Alternately, the > application could build two ancillary data objects, one > per option...The kernel must combine these into a single..." > What if we just disallow this and save work and complexity > in the kernel? What does everyone think ?? > I agree with this. The whole point of moving to user space construction of option headers was to avoid having the kernel do option by option copying, padding and searching. Allowing for this puts us right back where we started with the added complexity of having to support the user space code to do the same manipulations. I support the deleting of this text. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 10 14:11:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA05599; Wed, 10 Sep 1997 13:58:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA05592; Wed, 10 Sep 1997 13:58:34 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA22079; Wed, 10 Sep 1997 14:01:20 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA20486 for ; Wed, 10 Sep 1997 14:01:25 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id OAA25215; Wed, 10 Sep 1997 14:01:10 -0700 Message-Id: <3.0.3.32.19970910140054.00747ee4@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 10 Sep 1997 14:00:54 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4410) IPng Minutes for August IETF Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 35549 IPng Meeting Munich IETF August 1997 ------------ Meeting chaired by Steve Deering / Cisco and Bob Hinden / Ipsilon. Minutes by Bob Hinden. Agenda ------ Introduction / Deering, Hinden (5 min) Action Items / Hinden (5 min) Document Status / Hinden (10 min) Plan for Advancing Current Drafts / Hinden ( 10 min) IPv6 Protocol Updates / Deering (30 min) - Restrictions on Routing header reversal - Specification of Class (formerly Priority) field - Reserved bits for Explicit Congestion Notification bits - Inclusion of Class in Flow constant fields? - Neighborness rules for Strict/Loose Bit Map - Encoding of Option types TLA/NLA Assignment Rules / Hinden (20 min) Neighbor Discovery Issues / Nordmark, Narten (20 min) Decision on Advancing Current Documents / Hinden (10 min) Mobile IP / Johnson (10 min) IPv6/NBMA work in the ION group / Armitage (10 min) IPv6 Transmission over Frame Relay / Conta (5 min) IPv6 Transmission over IPv6/IPv4 Tunnels / Conta (5 min) Inverse Neighbor Discovery for IPv6 / Conta (5 min) Inverse Neighbor Discovery for IPv6/IPv4 Tunnels / Conta (5 min) Site prefixes in Neighbor Discovery / Nordmark (10 min) Router Renumbering / Crawford (10 min) IPv6 Name Lookups Through ICMP / Crawford (10 min) DNS Alternatives to ICMP Name Lookups / Gudmundsson (5 min) Header Compression / Degermark (10 min) Traceroute using hop-by-hop options / Durand (5 min) DHCP vs. Prefix changes Introduction / Deering, Hinden ------------------------------ Steve Deering introduced the meeting and reviewed the agenda. IPv6 Testing Event / Deering ---------------------------- 15 companies attended (up from 12). They were Digital, IBM, Sun Microsystems, FTP Software, Fujitsu, Hitachi, Bay, 3COM, Epilog, Toshiba, BSDI, Process Software, Ipsilon, SGI, and Inria. Testing included 11 host and 6 routers implementations (3 hosts did routing too). They did interoperability testing only, not conformance testing. Results were: - 15 nodes supported ping - All nodes supported new (aggregatable) address format - 3 nodes did Path MTU discovery and Packet too big, 6 did not, rest unknown. - 7 nodes did both client and server telnet - 6 nodes did client and server FTP - 2 nodes did PPP - 3 Routers sent ICMP redirects, 5 hosts processed them correctly - 5 1/2 hosts did auto-configuration - A few nodes supported FDDI and/or token ring Next event is first week in December. Action Items / Hinden --------------------- Action Items (San Jose IETF) - Document editor will submit Tunneling Spec to IESG for proposed standard. o Sent request to IESG on 12/10/96. IESG last call sent on 12/30/96 which ended on 1/17/97. Many comments received. IESG restarted last call for this document and two GRE documents on IPv4 tunneling. o Steve Deering currently reviewing GRE documents and will respond to IESG last call. On Agenda for Memphis. o IPng Chairs sent email to Internet ID's. Waiting for IESG action. o Jeff Burgan (Internet AD) reported that IESG would vote on this document separately from IPv4 tunneling documents. - Document editor will do a working group last call on Header Compression specification. o Sent on 12/10/96. Working group last call ended 12/24/96. o Comments received from Thomas Narten. Once comments resolved (and new draft published) document editor will send to IESG. o New Internet Draft Published. On agenda for Thursday session. - Dimitry Haskin and Dave Katz to write a draft proposing adding an option to BGP4 to carry IPv6 interdomain routes. o Drafts written for BGP4+ and BGP5. IDR discussed. Compromise discussions underway. o Discussed at Tuesday IDR session. Consensus to go forward with BGP4+. - Thomas Narten to include in next version of neighbor discovery rule to silently drop non-DAD packets which use the unspecified address as the source of the packet. o Open o On agenda for Wednesday session. Action Items (Interim Meeting) - "WhoAreYou" ICMP Message / Matt Crawford o Draft missed ID deadline. Sent to IPng list and on Memphis agenda. o On agenda for Thursday Session. - Modify Link Name Draft / Dan Harrington o Update underway o Waiting for outcome of "WhoAreYou" draft - Lessons from interim meeting / Thomas Narten, John Stewart, Allison Mankin, Lixia Zhang, Matt Crawford o Done. Internet Draft published. Discussion on agenda. o New draft published. Publish as Informational RFC? o Authors plan to publish as RFC. Action Items (Memphis IETF) - Issue working group last call for IPv6 MIB's once new drafts are published. o W.G. last call completed. o Sent to IESG for Experimental, Internet AD's reviewing. o Jeff Burgan (Internet AD) reported that it will be considered for proposed standard. Need to get a code-point outside of the experimental subtree. Document Status / Hinden ------------------------ - RFC - Proposed Standard o TCP and UDP over IPv6 Jumbograms (RFC2147) - IETF Last Call completed o Generic Packet Tunneling in IPv6 Specification - Submitted to IESG for Proposed Standard o IPv6 Router Alert Option - Submitted to IESG for Informational o Advanced Sockets API for IPv6 - Submitted to IESG for Experimental o MIB for IPv6: ICMPv6 Group o MIB for IPv6: TCP o MIB for IPv6: Textual Conventions & General Group o MIB for IPv6: UDP - Working Group Last Call Completed o Header Compression for IPv6 o IPv6 Router Alert Option o A Method for the Transmission of IPv6 Packets over ARCnet Networks o An IPv6 Aggregatable Global Unicast Address Format o IP Version 6 Addressing Architecture o IPv6 Multicast Address Assignments o IPv6 Testing Address Allocation o TLA and NLA Assignment Rules o Transmission of IPv6 Packets over Ethernet Networks o Transmission of IPv6 Packets over FDDI Networks Plan for Advancing Current Drafts / Hinden ------------------------------------------- Hinden talked about it is now time to move the base IPv6 specifications to Draft Standard. The main criteria is that they are stable. After some discussion with the Internet AD's the important thing is that we don't make any changes which break interoperability. Once a document is at Draft Standard it will be important to not make changes that are not critical. It is important that we stabilize the documents to encourage products and deployment. With each document we wish to move to Draft Standard an implementation report will have to be written. The document editor will coordinate the creation of a feature list for each specification with the authors and create a template for an implementation report. The list of documents with a proposal for advancement is as follows: Document Current Proposal ------------- ----------- ----------- IPv6 Protocol Proposed Std. Draft Std. Addressing Architecture Proposed Std. Proposed Std. ICMP Proposed Std. Draft Std. DNS Proposed Std. Draft Std. Neighbor Discovery Proposed Std. Draft Std. Address Auto Configuration Proposed Std. Draft Std. Aggregatable Addresses Internet Draft Proposed Std. IP_over_Ethernet Proposed Std. Proposed Std. IP_over_FDDI Proposed Std. Proposed Std. IP_over_PPP Proposed Std. Proposed Std. IP_over_ARCnet Internet Draft Proposed Std. TLA/NLA Assignment Rules Internet Draft BCP Testing Address Allocation Experimental Experimental Multicast Assignments Internet Draft Informational Path MTU Discovery Proposed Std. Draft Std. Packet Tunneling Internet Draft Proposed Std. This list will be reviewed later in the meeting after the current drafts are discussed. IPv6 Protocol Updates / Deering ------------------------------- Restrictions on Routing header reversal Question about need for requiring RH reversal. Currently: three legal behaviors: reply without a source route, reply with a configured source route (independent from received source route), or reverse received source route if packet was successfully authenticated. Current text is compatible with current Mobile IPv6 draft. Group agreed to keep current behavior. Specification of Class (formerly Priority) field 4 4 24 +-----+-------+-----------------------------------------+ | ver | class | flow label | +-----+-------+-----------------------------------------+ Bits are available for rewriting by routers. High order class bit recommended for interactive, other three are not defined, but left open for experimentation. These bits and flow label are not included in IPSEC AUTH header. Reserved bits for Explicit Congestion Notification bits Deering proposed congestion experienced bit (like "DEC" bit in CLNP). Has been lobbied for many years. Idea is to mark packets when congestion occurs to notify the receiver instead of just dropping packets. Van Jacobson had always resisted idea. At last End-to-End meeting, group came up with approach to use this bit with RED algorithm. Unfortunately VJ liked the new idea (not so bad). It is too early to be a required part of IPv6. Does show lots of potential. Thinking about freeing up more bits to allow this usage. Proposes: 4 8 20 +-----+-------+-----------------------------------------+ | ver | class | flow label | +-----+-------+-----------------------------------------+ The class bits would be set to zero on sending and ignored on reception. Reduces number of flows to ~1,000,000 per source address. Group agreed to make class field 8 bits long. Discussion about how tightly they should be defined. Deering thinks it is important to keep these bits reserved to allow IPv6 to be extensible. Suggestion to only reserve bits, and make definition of usage in a separate document. Christian Huitema disagreed, he thought it should be defined. Deering thought we should move the definition to a separate document. Group agreed to do this. Inclusion of Class in Flow constant fields? Question is: must the Class bits be constant for all packets in the same flow? One side of argument is that as long as the Class bits can affect routing, they should be constant within a flow -- otherwise, opportunistic flow set-up can violate desired routing semantics. The other side is the desire not to eliminate the potential flexibility of allowing applications to vary some of the Class bits within a single flow. Allison Mankin suggested we might delete opportunistic flow setup text. This would be reasonable when going to draft standard. Choices are to take class out of flow definition, or to define that the "D" bit is not to affect routing. Group agree to remove opportunistic behavior from specification, and to exclude Class from set of fields that must be constant within a flow. There are no known current implementations of opportunistic flow setup. Neighborness rules for Strict/Loose Bit Map Specification never defined Neighborness rules for strict/loose source behavior. Deering speculated that this was included in IPv4 was for security behavior. To keep this behavior it would require adding detailed rules for tunnel behavior, etc. Suggestion was made that we should get rid of strict source route capability. D. Hasken thought we should keep strict, but would need consistent set of rules. Deering polled group. Consensus to remove strict bits. Bits become zeros and text describing usage is removed. Further discussion, but no change of consensus. Encoding of Option types Should IPv6 option be identified by full 8 bit value or 5 bit option type. Current spec shows full 8 bits. No objections from group. Change recommended order of Extension Headers Deering had changed order based on what he thought was in ESP and AH drafts. This change was in error, and will be changed back to original behavior. Suggestion to make options fixed length to make it easier to implement IPv6 in hardware. Deering replied that this would also require removing all extension headers. There was a consensus to not make this change. Bigger MTU? Should we change the IPv6 minimum MTU to something closer to 1500 (i.e., something like 1300, to allow room for one or two levels of encapsulating/ tunnel overhead without exceeding the Ethernet MTU of 1500). This is the last opportunity to make this change, given the increasing number of existing implementations and the strong desire to move the base IPv6 spec to Draft Standard ASAP. This change would significantly reduce the importance of doing MTU discovery for multicast, which is something best avoided because of the ICMP implosion hazard. 576 was chosen because of IPoverAppletalk. Most links (except for dialup) are already ~1500. Comment that this would be a problem for dialup links. Deering replied that for slow-speed links it's preferable to do link-specific fragmentation and reassembly, below the IP layer. Several people supported the idea. Very strong consensus to raise MTU to ~1300 bytes. Editors Note: The Integrated Services over Specific Link-layers (ISSLL) working group is currently developing standards for doing link-specific fragmentation. Some of their techniques address criticisms of using large MTUs on slow links (e.g., having small packets get stuck behind bigger ones). This may be relevant to this issue. ------------------ Thursday Session ------------------ Deering reported continued issue with decision to increase MTU. Proposes to discuss on mailing list. Need to resolve quickly. Note: Alex Conta said that ICMP spec needs to get changed for multicast group membership messages. Deering proposes removing multicast membership messages from this document and create a new document for these messages. Proposal to Add Explicit Congestion Notification (ECN) to IPv6 and to TCP / Sally Floyd -------------------------------------------------------------- Reference: Floyd, S., TCP and Explicit Congestion Notification, ACM Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23., http://www-nrg.ee.lbl.gov/ What is New - Deployment of active queue management (e.g., RED) in the internet. - Increasing amount of best-effort traffic where the user is sensitive to the delay (due to retransmission) or drop of an individual packet (e.g., telnet, web browsing, best-effort audio and video, etc. What is Needed in IPv6? - Two bits: o An ECN-capable bit set by the origin transport protocol o An ECN-bit set by the router (instead of dropping the packet) when the buffer has not overflowed, and the ECN-capable bit is set, and the router would otherwise drop the packet because of the RED algorithm, based on the average queue size. - There is a single-bit version of this, described in Floyd94, that overloads a single bit What does ECN Bit Indicate? - Indicates incipient congestion as indicated by the "average" queue size exceeding a threshold, using the RED algorithms [FJ93, RED-ietf-draft] - The ECN bit should "not" be set in response to an unfiltered signal such as the instantaneous queue size. - A "single" packet with the ECN bit set should be treated by the end-nodes as an indication of congestion, just as would a "single" dropped packet. How do transport protocols respond to the ECN bit? - Congestion control response should be the same as that to a dropped packet. - Details depend on specific transport o Reliable unicast (e.g., TCP) o Reliable multicast (e.g., SRM) o Unreliable unicast o Unreliable multicast (e.g., vic) What modifications are needed for TCP? - Negotiation between the endpoints during setup to determine if they are both ECN-capable - A TCP option with an ECN-Notify bit so that the data receiver can inform the data sender when a packet has been received with the ECN bit set. - The data sender halves its congestion window "cwnd" in response to an ECN-notify. This is done only once per window of data. Internet draft will be out in a few weeks. TLA/NLA Assignment Rules / Hinden --------------------------------- Overview - Goal to Provide Guidance to Registries and Organizations receiving TLA IDs o Avoid "Land Rush" on TLA IDs - Focus on assigning TLA IDs to Organizations providing Public Transit Service - Assignment does NOT mean ownership o It implies "stewardship" TLA Assignment Rules - Must have a plan to offer public native IPv6 service within 6 months from assignment. The plan must include plan for NLA ID allocation. - Must have a plan or track record of providing public Internet transit service on fair, reasonable, and non-discriminatory terms, to other providers. TLA IDs must not be assigned to organizations that are only providing leaf service even if multihomed. - Must provide registry services on fair, reasonable, and non-discriminatory terms, for the NLA ID address space it is responsible for under its TLA ID. This must include both sites and next level providers. - Must provide transit routing and forwarding to all assigned TLA IDs on fair, reasonable, and non-discriminatory terms. - Organizations are not allowed to filter out any specific TLA IDs (except temporarily for diagnostic purposes or emergency repair purposed). Periodically (interval set by registry) provide to registry utilization statistics of the TLA ID it has custody of. The organization must also show evidence of carrying TLA routing and transit traffic. This can be in the form of traffic statistics, traceroutes, routing table dumps, or similar means. Comments: Erik Nordmark: don't rule out tunnels for TLA access (e.g., for hopping over non-IPv6-supporting secondary provider). Brian Carpenter: The wg's responsibility is to specify technical proposal and the technical rationale/justification Steve Deering: Gov't example is special case of an ISP that serves a closed community Someone: please don't use word "rules". Too strong. Internet AD's will help wordsmithing. General consensus to move forward as a BCP when new draft is out incorporating suggested clarifications. An IETF last call will be useful to have the broader IETF community review the idea in this document. Neighbor Discovery Issues / Nordmark ------------------------------------ Changes - Change move solicited node MC address changed to pointer to Address Arch. - Remove priority references - Decrementing lifetime variables - Default lifetime infinity changed to 60 days Clarifications - Use of unspecified source - Setting of NUD state - Setting of Ls router flag - Added "renumbering considerations" section The zero lifetime issue is still unresolved. This is the remaining issue that needs to be resolved before moving ND and AddrConf to Draft Standard. The authors will make a proposal on the mailing list. Decision on Advancing Current Documents / Hinden ------------------------------------------------ IPv6 Protocol Group agreed to move to Draft Standard once the MTU issue was settled. Addressing Architecture Group agreed to move to Proposed Standard. ICMP Group agreed to move to Draft Standard once multicast membership messages were removed. DNS No action at this time. Waiting for resolution of other DNS related work. Neighbor Discovery No consensus to move this forward. Zero lifetime issue still open. Address Auto Configuration No consensus to move this forward. Zero lifetime issue still open. Aggregatable Addresses Group agreed to move to Proposed Standard. IP_over_Ethernet Group agreed to move to Proposed Standard. IP_over_FDDI Group agreed to move to Proposed Standard once bridging text was removed. IP_over_PPP Group agreed to move to Proposed Standard once terminology was clarified. IP_over_ARCnet Group agreed to move to Proposed Standard once terminology was clarified. TLA/NLA Assignment Rules Group agreed to request publication as a BGP once revision available. Testing Address Allocation Group agreed to move to Experimental. Multicast Assignments Group agreed to move forward as either Informational RFC or IANA database input. Path MTU Discovery Group agreed to move to Draft Standard. Packet Tunneling IESG will consider for Proposed. Mobile IP / Johnson ------------------- Status of IPv6 Mobile work. - Current spec is . - High Level Overview o Care-of addresses from IPv6 address autoconfiguration o Mobile node sends its own Binding Update o Uses for correspondent nodes and home registration o Nodes cache bindings in a Binding Cache o Correspondents route own packets directly to mobile node - One implementation almost available. Dynamic Home Agent Address Discovery - Mobile node may not always know its home agent address o While mobile node is away from home o Home network may need to be reconfigured o Different machine may take over as home agent - In Mobile IPv4, this is solved by o Mobile node can send to "directed broadcast" address o All home agents in home network receive request o All reject, giving their own unicast address o Mobile node tries again with one of these addresses - Can't do this in Mobile IPv6 since no broadcast in IPv6 New Home-Agents Anycast Address - To register when don't know own home agent address o Mobile node sends Binding Update to "Home-Agents anycast address" for home subnet o Receiving home agent replies, giving unicast address o Mobile node registers to that IP address o All IPv6 home agents MUST support this Deering suggested that we reserve some number local interface identifiers for anycast addresses for applications that need anycast addresses. Suggest a new document for initial anycast assignments. ACTION: Document Editor. Replay Protection for Binding Updates - Must guard against replay attacks on Binding Updates - IPsec AH and ESP can do replay protection o Protection based on sequence number o Must re-key before sequence number wraps around o Only accept packet if sequence number >= max or within a "replay window" of sequence numbers before that o Allows out-of-order delivery - Problem: Binding updates MUST be applied ONLY in order Solution for Binding Updates - Use IPsec for "Replay Protection" o Lets IPsec worry about re-keying before wrap around - Use our own sequence number for sequencing o Similar to TCP sequence number when using IPsec replay protection o Our sequence number only needs to be large enough to cover replay protection window reordering. Getting through Ingress Filtering - Original Mobile IPv6 addressing for packets sent from a mobile node o Source address = mobile node home address o Destination address = correspondent node address o Problem: Ingress filtering drops all these packets - New solution uses "Home Address" destination option o All IPv6 nodes MUST support receiving packets containing a Home Address option. Questions about how this works and if it affects FTP and telnet. Document will be clarified. Use of Home Address Option - Mobile node uses care-of address as source address... - But only while packet on its way to the destination node - At the Sender o Sender builds packet (e.g., TCP) using home address o Then substitutes care-of address as source o Move home address into a Home Address option in packet - At the Receiver o Receiver substitutes correct source address (home address) back into packet in place of care-of address - Implementation of this would be required in all IPv6 receivers Home Address Option vs. Binding Update Option - Binding Update option o Creates state in receiver in Binding Cache o Used by receiver for sending future outgoing packets o MUST be authenticated o Use is only an optimization (not required in all nodes) - Home Address option o Creates NO state in receiver o Does NOT affect future routing of any packets o Need NOT be authenticated (unless IPv6 header already is) o Receiving MUST be supported by ALL IPv6 nodes Home Address Option Security - If IPv6 header "source address" is authenticated o Home Address option MUST also be authenticated o Need to preserve protection of this field - Otherwise o Home address option need NOT be authenticated either o IPv6 header source address may be forged/modified o So may Home Address option data Movement Detection Timing - Helpful to know when to expect packets from router o Mobile node know when it missed one o Mobile node can decided for itself home many missed packets are a cause for concern (possible movement) - Neighbor discovery provides good source of packet form router o Periodic Router Advertisements o Must receive new one before old one expires o But router must send more frequently, since some might be dropped o Would help mobile node to know nominal advertisement interval o Example: long lifetimes, but frequent advertisements Comments Please - Send comments to mobile IP mailing list - Also can be sent to Dave Johnson and Charlie Perkins IPv6/NBMA work in the ION group / Armitage ------------------------------------------ Current draft is: Suggestion to put "ipv6" in name of draft Updates - Interface token now based on 8 octet EUI-64 - Cleaned up vague text - Specified host triggered transient neighbor discovery - folded in some text from expired TODO - Syntax mapping between ND and NHRP at routers - Clean up the misleading "ATM dependency" implied by current text Current approach - "on link" => "on logical link" (on LL) - ND used on LL (native multicast or augmented MARS/RFC2022) - Flow detection in router leads to NHRP query for destination o NHRP reply translated to Redirect on source LL o "transient" neighbor - Host Trigger (NS for remote dst sent to router) also leads to NHRP inter-router query - NHRP reply translated into NA back to soliciting host Current approach does not require ND to change. Questions to gja@lucent.com IPv6 Transmission over Frame Relay / Conta ------------------------------------------ Draft: Defines: - Min, max, default MTU - Frame format for IPv6 over FR - Interface ID for FR interfaces - IPv6 local address - Source/target link layer address options in ND MTU - Min frame size, 5,6, or 7 octets - General requirement for at least 262 octets - IPv6 requires a minimum MTU size of 576 - Default MTU = 1600 - 575 <= MTU <= 4080 with CRC16 - MTU > 4080 less error detection / correction at link layer - MTU defined per link - implementation limitation. Deering comment need strong link layer CRC. Should discourage MTU greater than 2080. Frame Format using SNAP identifier. Found out there is a NLPID (0x8E) , would save same header bits. Slides showing figures with two approaches to create Interface IDs (first includes FR Node Identifier, FR Link Identifier, and FR DLCI, second is random number and FR DLCI), Link Local address, and Unicast Address Mapping. Editors Note: After discussion with the author and the chairs of the ION working group, the IPng chairs decided that the ION working group should own this topic. The IPng working group will consulted to insure that the work is consistent with IPv6. IPv6 Transmission over IPv6/IPv4 Tunnels / Conta ------------------------------------------------- Draft: Extension to existing IPv6 tunneling document Goals - Tunnel minimum, maximum, and default MTU - Frame format for IPv6 over IPv6 and IPv4 tunnels - Interface ID for IPv6 tunnel interfaces - IPv6 link-local addresses for tunnel virtual links - Source/Target Link-layer address option used in ND or IND over IPv6 and IPv4 tunnels. MTU - Default tunnel MTU is Physical underlaying IPv6 interface MTU - tunnel headers size - 576 <= tunnel MTU < default tunnel MTU Tunnel Packet Format - IPv6 tunnel packets re encapsulated as IPv6 and IPv4 packets Interface ID (IPv6 tunnels only) - The IPv6 tunnel pseudo-interface ID o Unique on the virtual link represented by the tunnel o Based on the underlying physical interface identifier - Mask the forth and fifth octets of the EUI-64 identifier with the fixed 0xFFFC value - Example 36-56-78-FF-FE-9A-BC-DE becomes 36-56-78-FF-FC-9A-BC-DE Link Local Address - The IPv6 link-local address for an IPv6 tunnel interface is formed by appending the interface token, as defined above, to the prefix FE80::/64. Address Mapping [figure not included] Inverse Neighbor Discovery for IPv6 / Conta ------------------------------------------- Draft is Introduced topic. Extension to IPv6 for FR and similar links when link layer is known, but IPv6 address is not known. Read document and send comments to author . Inverse Neighbor Discovery for IPv6/IPv4 Tunnels / Conta -------------------------------------------------------- Draft is Introduced topic. Extension to ND to allow inverse discovery for tunnels to aid in tunnel configuration. Read document and send comments to author . Site Prefixes in Neighbor Discovery / Nordmark ---------------------------------------------- Includes automatic creation of site local addresses and the creation of global version for DNS lookup. Only global addresses need to be in the DNS. Motivation / Requirements - Reduce the risk of renumbering a site - Ensure that communication local to a site uses site-local addresses - Do not require that sites use a two-faced DNS (i.e., do not store the site-local addresses in the DNS). [Slide with additions to ND Prefix Option] Name Lookups - Create site-local addresses when an address returned by DNS matches a site prefix. The first Site PLength bits are taken from the site-local address (FEC0::0) and the remaining bits are taken from the returned address. - Add the created site-local addresses to the front of the list returned to the application. - Hidden from applications (i.e., in gethostbyname library). Name Lookup Example - Name service returns (for a multihomed node) 2837:a:b:987:X:Y:W:Z1 2837:a:b:34:X:Y:W:Z2 2abc:77:66:23:X:Y:W:Z3 2000:1:2:987:X:Y:W:Z1 2000:1:2:34:X:Y:W:Z2 - List of Prefixes 2837:a:b::0/48 2000:1:2::0/48 - Resulting list of addresses (duplicates removed) fec0::987:X:Y:W:Z1 2837:a:b:987:X:Y:W:Z1 2837:a:b:34:X:Y:W:Z2 fec0::34:X:Y:W:Z2 2abc:77:66:23:X:Y:W:Z3 2000:1:2:987:X:Y:W:Z1 2000:1:2:34:X:Y:W:Z2 Address Lookups - No change unless a site-local address - For site-local form the potential global addresses using the prefix list and the site-local address - For example, if the site-local address is: fec0::987:X:YX:W:Z1 - List of site prefixes 2837:a:b::0/48 2000:1:2::0/48 - The addresses that should be tried 2837:a:b:987:X:Y:W:Z1 2000:1:2:987:X:Y:W:Z1 Open Issues: - Node on link can be use this to spoof the address and names returned by the DNS. o But such a node can already intercept all traffic o Doing name/address lookup without communicating - Subnet number must be the same for all global and site-local addresses used by the site. Is this too strict? - Should the formed site-local address replace (instead of being added to) the global addresses returned to the application. - Common API to access the list of site prefixes. Many questions. Need additional discussion on the list. We need to discussion on the mailing list. Header Compression / Degermark ------------------------------ Three drafts: - Main draft: - How to compress RTP: Status - Protocol ID's from PPP ext - Negotiation of header compression parameters - Name Change: Header Compression for IP - Changed the order of the field in compressed TCP headers to conform with RFC1144 - Priority/Class field: How to deal with this when we go to Proposed Standard? - MTU: Not problematic fro PPP. There is a standard for link-level fragmentation. ACTION: Document editor will do W.G. last call once new draft is available. DHCP vs. Prefix changes -------------------------------------------------- Issue is nodes can get addresses through manual config, addr conf, and DHCP. If you have gotten addresses from one method, how to deal with changes received from DHCP and/or ADDR CONF. This needs clarification. One possible rule is that changes only apply based on way they were learned. This is consistent to how DHCP works now for IPv4 (dynamic from DHCP and manual config) and how routing protocols work with dynamic routes vs. static routes. ND and DHCP specs need minor revision. DNS Alternatives to ICMP Name Lookups / Gudmundsson --------------------------------------------------- IPng DNS, and DNS Provide an alternative to "WHO ARE YOU" message. This is a change from the plan to always return AAAA records. This would return two pieces and host would put together. Claim made that for secure DNS it is necessary to return two pieces. Needs to be discussed further on the mailing list. This affects moving the DNS draft to "Draft Standard". This needs to be resolved first. ------------------------------------------------------------------------- At this point the session ran out of time. The following agenda topics were not discussed: Router Renumbering / Crawford IPv6 Name Lookups Through ICMP / Crawford Traceroute using hop-by-hop options / Durand The IPng chairs apologize to speakers for not covering their topics at this meeting. ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 11 13:57:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07218; Thu, 11 Sep 1997 13:43:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07211; Thu, 11 Sep 1997 13:42:56 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA24394; Thu, 11 Sep 1997 13:45:45 -0700 Received: from ietf.org ([132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA03266 for ; Thu, 11 Sep 1997 13:45:23 -0700 Received: from ietf.ietf.org by ietf.org id aa17665; 11 Sep 97 16:38 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4416) I-D ACTION:draft-ietf-ipngwg-tokenring-00.txt Date: Thu, 11 Sep 1997 16:38:46 -0400 Message-ID: <9709111638.aa17665@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3203 ---NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over Token Ring Networks Author(s) : S. Thomas, S. Thomas Filename : draft-ietf-ipngwg-tokenring-00.txt Pages : Date : 11-Sep-97 This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-tokenring-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-tokenring-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-tokenring-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ---NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" ---OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970911161522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-tokenring-00.txt ---OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-tokenring-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970911161522.I-D@ietf.org> ---OtherAccess-- ---NextPart-- - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 11 13:58:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07209; Thu, 11 Sep 1997 13:42:49 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07199; Thu, 11 Sep 1997 13:42:37 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA24300; Thu, 11 Sep 1997 13:45:25 -0700 Received: from ietf.org ([132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA03173 for ; Thu, 11 Sep 1997 13:45:09 -0700 Received: from ietf.ietf.org by ietf.org id aa17624; 11 Sep 97 16:37 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4415) I-D ACTION:draft-ietf-ipngwg-tokenring-00.txt Date: Thu, 11 Sep 1997 16:37:46 -0400 Message-ID: <9709111637.aa17624@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3221 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over Token Ring Networks Author(s) : S. Thomas, S. Thomas Filename : draft-ietf-ipngwg-tokenring-00.txt Pages : Date : 11-Sep-97 This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-tokenring-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-tokenring-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-tokenring-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970911161522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-tokenring-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-tokenring-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970911161522.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 11 14:03:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07227; Thu, 11 Sep 1997 13:45:51 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07220; Thu, 11 Sep 1997 13:45:35 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA25216; Thu, 11 Sep 1997 13:48:20 -0700 Received: from ietf.org ([132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA04128 for ; Thu, 11 Sep 1997 13:48:13 -0700 Received: from ietf.ietf.org by ietf.org id aa17925; 11 Sep 97 16:46 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4417) I-D ACTION:draft-ietf-ipngwg-tokenring-00.txt Date: Thu, 11 Sep 1997 16:46:15 -0400 Message-ID: <9709111646.aa17925@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3196 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over Token Ring Networks Author(s) : S. Thomas, S. Thomas Filename : draft-ietf-ipngwg-tokenring-00.txt Pages : Date : 11-Sep-97 This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-tokenring-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-tokenring-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-tokenring-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970911161522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-tokenring-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-tokenring-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970911161522.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 11 17:30:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA07409; Thu, 11 Sep 1997 17:18:25 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA07402; Thu, 11 Sep 1997 17:18:16 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA24370; Thu, 11 Sep 1997 17:21:04 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA08004 for ; Thu, 11 Sep 1997 17:21:13 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA27862; Thu, 11 Sep 1997 17:20:57 -0700 Message-Id: <3.0.3.32.19970911172029.0078d56c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 11 Sep 1997 17:20:29 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4418) IPng Web Page Update Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 716 I am working on an update to the IPng web pages (http://playground.sun.com/ipng). Please let me know if you have any changes/additions you would like to see. Also, if you gave a presentation at the IPng session at the Munich IETF and would like me to add them to the minutes page, please send me the postscript or a URL. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Sep 14 10:50:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA08914; Sun, 14 Sep 1997 10:42:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA08907; Sun, 14 Sep 1997 10:42:07 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA14449; Sun, 14 Sep 1997 10:42:04 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA18318 for ; Sun, 14 Sep 1997 10:42:20 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id NAA27981 for ; Sun, 14 Sep 1997 13:37:34 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA01507; Sun, 14 Sep 1997 13:37:33 -0400 Message-Id: <9709141737.AA01507@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 4420) Addr Conf Denial of Service and Interact with DHCPv6 Date: Sun, 14 Sep 1997 13:37:33 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 10411 From: draft-ietf-ipngwg-addrconf-v2-00.txt Several issues and things to be resolved. >5.5.3. Router Advertisement Processing > On receipt of a valid Router Advertisement (as defined in > [DISCOVERY]), a host copies the value of the advertisement's M bit > into ManagedFlag. If the value of ManagedFlag changes from FALSE to > TRUE, the host should invoke the stateful address autoconfiguration > protocol, requesting address information. If the value of the > ManagedFlag changes from TRUE to FALSE, the host should terminate the > stateful address autoconfiguration protocol (i.e., stop requesting > addresses and ignore subsequent responses to in-progress > transactions). If the value of the flag stays unchanged, no special > action takes place. In particular, a host MUST NOT reinvoke stateful > address configuration if it is already participating in the stateful > protocol as a result of an earlier advertisement. I think we need words above that permit DHCPv6 to continue running if it is being used for Dyanmic Updates to DNS (DDNS) via a DHCPv6 server. So I object to the words that say "terminate" the stateful protocol. I propose the following: .................. If the value of the ManagedFlag changes from TRUE to FALSE, the host MUST terminate the use of the stateful address autoconfiguration protocol as a mechanism to obtain new addresses or update existing address lifetimes. If addr conf changes a stateless address the node still can use DHCPv6 for example to update the DNS, so we don't want to say kill the stateful protocol which MAY serve multiple purposes. Also if an address from stateful valid-life becomes zero via addr conf, in the case of DHCPv6 I would think we would want a DHCPv6 RELEASE to be sent to the DHCPv6 server as one example, rather than the default to time out at the server as an implementation choice. I think customers will want this done in an orderly manner. > An advertisement's O flag field is processed in an analogous manner. > A host copies the value of the O flag into OtherConfigFlag. If the > value of OtherConfigFlag changes from FALSE to TRUE, the host should > invoke the stateful autoconfiguration protocol, requesting > information (excluding addresses). If the value of the > OtherConfigFlag changes from TRUE to FALSE, any activity related to > stateful autoconfiguration for parameters other than addresses should > be halted. If the value of the flag stays unchanged, no special > action takes place. In particular, a host MUST NOT reinvoke stateful > configuration if it is already participating in the stateful protocol > as a result of an earlier advertisement. This is a problem too. If the "M" flag is set it should imply the client can accept OTHER configuration information as part of the DHCPv6 exts specification. Like DNS processing or the POSIX TIMEZONE variable. I propose the following: ..... If the value of the OtherConfigFlag changes from TRUE to FALSE any activity related to stateful autoconfiguration for paramters that would alter the value of the link as defined in this specification or Neighbor Discovery [ND-REF] MUST be halted. I think we need also to make it clear in this spec that: 1. M bit means you don't get to receive link parameters like from DHCPv6. 2. O bit must be set for a node to get link parameters like from DHCPv6. Sorry I did not see these two above issues sooner but it popped out at me as I started to implement DHCPv6 next to/integrated with Addr Conf. > For each Prefix-Information option in the Router Advertisement: > > a) If the Autonomous flag is not set, silently ignore the Prefix > Information option. > > b) If the prefix is the link-local prefix, silently ignore the > Prefix Information option. > > c) If the preferred lifetime is greater than the valid lifetime, > silently ignore the Prefix Information option. A node MAY wish to > log a system management error in this case. > > d) If the prefix advertised matches the prefix of an autoconfigured | > address (i.e., one obtained previously via stateless or stateful | > autoconfiguration) in the list of addresses associated with the | > interface, and the valid lifetime in the received RA is both less | > than 2 hours and less than the remaining valid Lifetime in the | > cached entry, ignore the Prefix Information option for the | > purpose of stateless address autoconfiguration. | This has now come up for DHCPv6 too as an issue too. I realize the Denial of Service issue but this fix is unacceptable to me as a vendor. I must be able to permit my customer sys admins to do three things: 1. Recover if a bogus address was given out (stateless or stateful). 2. Recover if they want to change the valid lifetime to 1 hour. 3. For some reason cause all connections to break by sending out a valid lifetime of zero or by some other mechanism. These are market requirements for IPv6 Autoconfiguration. Either we go back to the way it was and live with the denial of service issue or come up with a new answer. I think we have the answer at hand with IPSEC. If a user does not want to experience this denial of service attack they must use IPSEC Authentication at a minimum and Encryption as a maximum. If IPSEC can't do this in an environment like the IETF Terminal room then IPSEC needs to go back to the drawing board and figure it out. We as vendors are making a huge investment in IPSEC and it is costing us money and our customers want IPSEC. I would suggest we connect with the IPSEC group and get their input on how difficult and why it would not be possible to use IPSEC to distribute keys in an IETF terminal room environment. Before we make the above change to addr conf. ALso we should check with Bob Moskowitz if this has been an issue at the present IPSEC ANX bake-offs as other data before we adopt the above change too in addition to running this by IPSEC WG. > f) If the prefix advertised matches the prefix of an autoconfigured | > address (i.e., one obtained previously via stateless or stateful | > autoconfiguration) in the list of addresses associated with the | > interface, and the preferred lifetime in the received RA is both | > less than 2 hours and less than the remaining preferred Lifetime | > in the cached entry, ignore the Prefix Information option for the | > purpose of stateless address autoconfiguration. | Same issues essentially as stated for valid lifetime above. > In those cases where a site requires the use of longer prefixes > than can be accommodated by the interface identifier, stateful | > autoconfiguration can be used. | I think this should not be stated now per the new Addr Arch spec and use of TLAs, SLAs, etc. and IPv6 over FOO using EUI 64. All prefixes should not be greater than 64bits and should be the left most 64bits of an IPv6 address. So I suggest we just delete the above from the text. This will apply to both addr conf and stateful. > If an address is formed successfully, the host adds it to the > list of addresses assigned to the interface, initializing its > preferred and valid lifetime values from the Prefix Information > option. Note for next set of comments that this conceptual list will also contain addresses from DHCPv6. >5.6. Configuration Consistency > It is possible for hosts to obtain address information using both > stateless and stateful protocols since both may be enabled at the > same time. It is also possible that the values of other > configuration parameters such as MTU size and hop limit will be > learned from both Router Advertisements and the stateful > autoconfiguration protocol. If the same configuration information is > provided by multiple sources, the value of this information should be > information received from multiple sources is inconsistent. Hosts > accept the union of all information received via the stateless and > stateful protocols. If inconsistent information is learned from > different sources, the most recently obtained values always have > precedence over information learned earlier. There is an issue here for addresses and lifetimes. If stateless and stateful are in synch through system administration they could be using the same prefixes. If stateful is in process and addresses are assigned to the interface with lifetimes like: 4c6e::12 valid=2 days preferred=1 day Then addr conf says use stateless and: 4c6e::12 valid=1 day preferred= 5 hours We have an inconsistecy at the stateful server and I think we should RELEASE the address when this happens via DHCPv6 from the client node. But the words in addr conf in 5.5.3 do not permit me to send this message. The issue is to provide consistency and keep any stateful server databases up-to-date (kind of like garbage collection for network addresses in IPv6 addr conf). Suggestion: I think the fix is to permit releasing of addresses when a Router Advertisement shuts off stateful (M-bit clear), and an address or lifetime is altered via stateless that was last created or updated via Stateful mechanisms. If both A bit is set as prefix option and M bit is set in Router Advertisement. AND. Stateless overrides lifetimes or deletes an address the stateful processing module should release that address to the stateful server or process handling this (e.g. DHCPv6 server). For link configuration information the UNION and most recently used algorithm stated above in 5.6 will work. The only issue is for addresses and lifetimes. I think my suggestions for 5.5.3 and 5.6 are congruent but the WG should check out if my wording is in synch. Thanks............ Comments ???? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 16 15:56:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA10415; Tue, 16 Sep 1997 15:46:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA10408; Tue, 16 Sep 1997 15:46:32 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA09145; Tue, 16 Sep 1997 15:46:27 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA17430 for ; Tue, 16 Sep 1997 15:46:24 -0700 Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id PAA12687 for ; Tue, 16 Sep 1997 15:46:15 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id PAA23117 for ipng@sunroof.Eng.Sun.COM; Tue, 16 Sep 1997 15:46:14 -0700 (MST) Message-Id: <199709162246.PAA23117@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 16 Sep 1997 15:46:14 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: ipng@sunroof.eng.sun.com Subject: (IPng 4424) Munich WG minutes Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 651 /www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: ipng@sunroof.Eng.Sun.COM Subject: Munich WG minutes Have the minutes from the Munich WG meeting been sent to the list yet? I don't see them on the home page either. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 16 19:14:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA10540; Tue, 16 Sep 1997 19:06:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA10533; Tue, 16 Sep 1997 19:06:19 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA02484; Tue, 16 Sep 1997 19:06:18 -0700 Received: from postoffice.cisco.com (postoffice-hme0.cisco.com [171.69.192.13]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA12695 for ; Tue, 16 Sep 1997 19:06:19 -0700 Received: from [171.69.199.193] (dhcp-h-199-193.cisco.com [171.69.199.193]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA12050; Tue, 16 Sep 1997 19:05:55 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199709162246.PAA23117@kohala.kohala.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Sep 1997 19:06:18 -0700 To: "W. Richard Stevens" From: Steve Deering Subject: (IPng 4425) Re: Munich WG minutes Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 757 At 3:46 PM -0700 9/16/97, W. Richard Stevens wrote: > Have the minutes from the Munich WG meeting been sent to the > list yet? I don't see them on the home page either. They were posted to this list on September 10. The subject line was: Subject: (IPng 4410) IPng Minutes for August IETF If you can't find it, send me private mail and I'll forward a copy to you. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 10:52:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA11712; Thu, 18 Sep 1997 10:41:25 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA11705; Thu, 18 Sep 1997 10:40:30 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA24288; Thu, 18 Sep 1997 10:40:25 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA27964 for ; Thu, 18 Sep 1997 10:40:18 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id MAA02589; Thu, 18 Sep 1997 12:40:05 -0500 Message-Id: <199709181740.MAA02589@gungnir.fnal.gov> X-Mailer: exmh version 2.0zeta 7/24/97 To: ipng@sunroof.eng.sun.com, 6bone@ISI.EDU Reply-To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4426) /126 or /127 -- neither! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Sep 1997 12:40:05 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2902 At the PAL1 meeting, when we were considering the 64 bit identifier which is now part of the addressing architecture, the question arose of teensy little subnets (such as /126's) for point-to-point links. I argued at the time that we have no place, and need no place, for any prefix with length in the range 65 to 127 bits, inclusive. That is, every entry in a (unicast) IPv6 routing table ought to be either a 128 bit "host route" or a prefix of 64 bits or less. I'd like to elaborate a bit on this argument. To be specific, I'm discussing the case of a point-to-point link between two routers under different organizational control. This may be a link between two sites, two ISPs, or a site and an ISP from which the site does not derive address space. Possibly what I have to say will be applicable to p-p links within an organization. Not being an enormous ISP or a seller of boxes to enormous ISPs, I enjoy a vast ignorance about operational customs. The fundamental reason that IPv4 needs a /30 for a point-to-point link is that one address is reserved to be the broadcast address on that subnet. IPv6 has no broadcast. A secondary reason is that another address is reserved as an ill-defined numeric name for the subnet itself. (I say ill-defined because so many implementations treat it as a synonym the above broadcast address.) IPv6 uses a similar bit-pattern as an anycast address for "any router on this subnet." What I've seen requested here for IPv6 is a slice of the address space to be used for non-routable /126 (or /127) prefixes to number point-to-point links. This space would carry, besides scaling problems, a weighty bureaucracy to administer assignments. It should have, therefore, an equally weighty justification. I think there is none. The alternative is for each end of a p-p link to be assigned an address out of its respective site's prefix. I believe routing protocols can perfectly well handle links whose endpoints have unrelated global-scope addresses. RIPng, for example, uses link-local next-hop addresses, and the last section of draft-bates-bgp4-multiprotocol-03.txt seems to take care of this situation quite nicely. In summary, the only capability that's lost by having no subnet allocated to a p-p link is the ability to address "either end of this link." The cost of providing that ability is to either use one of our very large /64 subnets per link, or to do great violence to the interface identifier concept in the new addressing architecture. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 11:08:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA11747; Thu, 18 Sep 1997 10:56:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA11740; Thu, 18 Sep 1997 10:56:37 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA29628; Thu, 18 Sep 1997 10:56:32 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA27268 for ; Thu, 18 Sep 1997 10:56:05 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA03190; Thu, 18 Sep 1997 10:55:58 -0700 Message-Id: <3.0.3.32.19970918105536.00785e28@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 18 Sep 1997 10:55:36 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4427) IPng Web Pages Updated Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 652 I installed an update to the IPng web pages at: http://playground.sun.com/ipng Changes include minutes and presentations for Munich IETF, new implementations that includes two product announcements, updated specifications, and a pointer to a new ngtrans web page. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 12:19:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA11816; Thu, 18 Sep 1997 12:04:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA11809; Thu, 18 Sep 1997 12:04:22 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA21250; Thu, 18 Sep 1997 12:04:08 -0700 Received: from akita.cisco.com (akita.cisco.com [171.69.223.72]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA20196 for ; Thu, 18 Sep 1997 12:03:20 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by akita.cisco.com (8.6.12/8.6.5) with ESMTP id MAA04602; Thu, 18 Sep 1997 12:02:16 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA04758; Thu, 18 Sep 1997 12:02:15 -0700 (PDT) Date: Thu, 18 Sep 1997 12:02:15 -0700 (PDT) Message-Id: <199709181902.MAA04758@pedrom-ultra.cisco.com> From: Pedro Marques To: ipng@sunroof.eng.sun.com Cc: 6bone@ISI.EDU, "Matt Crawford" Subject: (IPng 4428) /126 or /127 -- neither! In-Reply-To: <199709181740.MAA02589@gungnir.fnal.gov> References: <199709181740.MAA02589@gungnir.fnal.gov> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5048 >>>>> "Matt" == Matt Crawford writes: Matt> At the PAL1 meeting, when we were considering the 64 bit Matt> identifier which is now part of the addressing architecture, Matt> the question arose of teensy little subnets (such as /126's) Matt> for point-to-point links. I argued at the time that we have Matt> no place, and need no place, for any prefix with length in Matt> the range 65 to 127 bits, inclusive. That is because the address space should be 64 bits in length in the first place or is there any other reason that escapes me ? Matt> I'd like to elaborate a bit on this argument. To be Matt> specific, I'm discussing the case of a point-to-point link Matt> between two routers under different organizational control. I don't think p-to-p links within an organization are different. Matt> A secondary reason is that another address is reserved as an Matt> ill-defined numeric name for the subnet itself. (I say Matt> ill-defined because so many implementations treat it as a Matt> synonym the above broadcast address.) IPv6 uses a similar Matt> bit-pattern as an anycast address for "any router on this Matt> subnet." Matt> What I've seen requested here for IPv6 is a slice of the Matt> address space to be used for non-routable /126 (or /127) Matt> prefixes to number point-to-point links. The two issues aren't really related... one issue is the use of non-routable addresses for peering, another issue is the question of /127 being valid subnet lengths. The issue with /127 is as you pointed out if anycast addresses are mandatory. Matt> This space would Matt> carry, besides scaling problems, a weighty bureaucracy to Matt> administer assignments. It should have, therefore, an Matt> equally weighty justification. I think there is none. This is an argument against non-routable addresses, which i consider quite reasonable. The motivation for non-routable addresses btw is to ease "automatic" renumbering of ASes (which is something of a very unproven concept). Matt> The alternative is for each end of a p-p link to be assigned Matt> an address out of its respective site's prefix. You mean unnumbered links ? but there are good reasons to have numbered p-to-p links. I don't understand why you are mixing the p-to-p issue with the peering address issue. What if instead of a serial the peer uses an ethernet ? Do you proprose to use unnumbered ethernets too ? Matt> I believe routing protocols can perfectly well handle links whose Matt> endpoints have unrelated global-scope addresses. In the context of BGP peering you have: i A ----- B if link is numbered (global scope address): A and B will announce routes to each other using as nexthop the global addresses Ia and Ib (respectivly). Those addresses are the ones annouced in to the IBGP mesh. I's global prefix will be injected into the IGP. if the link is unnumbered: A and B will need to make those annoucements with Ag and Bg. That means site B needs to manually configure a route to A's prefix and inject it in it's own IGP a vice-versa. So, taking the address out of the link only adds complexity and creates two possible reasons for manual reconfiguration: the renumbering of site A and the renumbering of site B. While you only had one with a numbered link: the renumbering of link i. I'm not claiming that using non-routable addresses on link i is the right thing to do. I'm just trying to clarify what the potential problem might be (i'm very tempted to say there is none)... Matt> RIPng, for example, uses link-local next-hop addresses Which is a real pain in the neck... because of all the nice effects you get when you try to redistribute RIP into/from other routing protocols. But then you need to have link locals anyway in your table (because of the potential need to send redirects)... Matt> In summary, the only capability that's lost by having no Matt> subnet allocated to a p-p link is the ability to address Matt> "either end of this link." No. What you loose by not having a subnet in a p-to-p link is the ability to address the link's end-points knowing only how to route to the link. That is why numbered links are very useful. Matt> The cost of providing that Matt> ability is to either use one of our very large /64 subnets Matt> per link, Not really. Matt> or to do great violence to the interface Matt> identifier concept in the new addressing architecture. Since i've absolutely no idea what interface identifiers are useful for i cannot comment on that. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 15:12:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA12111; Thu, 18 Sep 1997 15:00:28 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA12104; Thu, 18 Sep 1997 15:00:20 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA17508; Thu, 18 Sep 1997 15:00:17 -0700 Received: from postoffice.cisco.com (postoffice-hme0.cisco.com [171.69.192.13]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA08554 for ; Thu, 18 Sep 1997 11:28:11 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA25426 for ; Thu, 18 Sep 1997 11:28:06 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199709181740.MAA02589@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Sep 1997 11:27:37 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 4430) Re: /126 or /127 -- neither! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1431 In support of what Matt Crawford said, another reason to discourage the use of /126 subnet prefixes for point-to-point links is that we probably ought to reserve additional well-known interface IDs on every subnet, for use in global-routing-scope, subnet-specific, well-known, anycast addresses (whew!). Currently we have one such reserved interface ID, the value zero, which is reserved to mean "all routers on this subnet". The Mobile IP working group has requested designation of another well-known interface ID to mean "all mobility agents on this subnet", and it seems like a reasonable request to me. So I would not be surprised to see additional good uses for the well-known interface ID concept in the future. If people start assigning 126-bit subnet prefixes, that won't work. If people think this makes sense, we should immediately set aside a block of local-identifier-scope interface IDs for this purpose, e.g., IDs 0-256, so that assignments of local-identifier-scope IDs to real interfaces will avoid that range. Comments? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 16:38:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA12261; Thu, 18 Sep 1997 16:28:07 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA12254; Thu, 18 Sep 1997 16:28:00 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id QAA20441 for ; Thu, 18 Sep 1997 16:27:59 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA25326; Thu, 18 Sep 1997 16:25:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA12218; Thu, 18 Sep 1997 16:16:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA11711; Thu, 18 Sep 1997 16:16:27 -0700 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA14860 for ; Thu, 18 Sep 1997 11:46:51 -0700 Received: from abfab.juniper.net (abfab.juniper.net [208.197.169.86]) by red.juniper.net (8.8.5/8.8.5) with SMTP id LAA29942; Thu, 18 Sep 1997 11:46:46 -0700 (PDT) Message-Id: <3.0.1.32.19970918114657.006a2264@pobox.juniper.net> X-Sender: jstewart@pobox.juniper.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 18 Sep 1997 11:46:57 -0700 To: ipng@sunroof.eng.sun.com, 6bone@ISI.EDU From: John W Stewart III Subject: (IPng 4433) Re: /126 or /127 -- neither! In-Reply-To: <199709181740.MAA02589@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4463 for addresses which are intended to have a globally unique low-order 64 bits, i agree that masks with length >64 and <128 seem quite broken. further, it seems broken to allow some addresses to have, e.g., /127 masks and other addresses not to, so saying that no masks >64 and <128 are allowed seems fine to me but there's one thing that should be clearly noted here. doing this results in lack of "automatic connectivity" between two routers directly connected over a point-to-point link. in v4, no extra config is required and no IGP needs to be running to reach an adjacent router over a point-to-point link (the addresses configured on either end of the link need to be coordinated, but i think that's true in any case). in a situation where point-to-point links don't have subnets associated with them, in order for a system to reach an adjacent router on a shared point-to-point interface, the systems must be participating in an IGP or they need static config information (p-to-p interface config'd with address of other end or more general static routes) /jws At 12:40 PM 9/18/97 -0500, Matt Crawford wrote: >At the PAL1 meeting, when we were considering the 64 bit identifier >which is now part of the addressing architecture, the question arose >of teensy little subnets (such as /126's) for point-to-point links. I >argued at the time that we have no place, and need no place, for any >prefix with length in the range 65 to 127 bits, inclusive. That is, >every entry in a (unicast) IPv6 routing table ought to be either a >128 bit "host route" or a prefix of 64 bits or less. > >I'd like to elaborate a bit on this argument. To be specific, I'm >discussing the case of a point-to-point link between two routers >under different organizational control. This may be a link between >two sites, two ISPs, or a site and an ISP from which the site does >not derive address space. Possibly what I have to say will be >applicable to p-p links within an organization. Not being an >enormous ISP or a seller of boxes to enormous ISPs, I enjoy a vast >ignorance about operational customs. > > >The fundamental reason that IPv4 needs a /30 for a point-to-point >link is that one address is reserved to be the broadcast address on >that subnet. IPv6 has no broadcast. > >A secondary reason is that another address is reserved as an >ill-defined numeric name for the subnet itself. (I say ill-defined >because so many implementations treat it as a synonym the above >broadcast address.) IPv6 uses a similar bit-pattern as an anycast >address for "any router on this subnet." > >What I've seen requested here for IPv6 is a slice of the address >space to be used for non-routable /126 (or /127) prefixes to number >point-to-point links. This space would carry, besides scaling >problems, a weighty bureaucracy to administer assignments. It should >have, therefore, an equally weighty justification. I think there is >none. > >The alternative is for each end of a p-p link to be assigned an >address out of its respective site's prefix. I believe routing >protocols can perfectly well handle links whose endpoints have unrelated >global-scope addresses. RIPng, for example, uses link-local next-hop >addresses, and the last section of draft-bates-bgp4-multiprotocol-03.txt >seems to take care of this situation quite nicely. > >In summary, the only capability that's lost by having no subnet >allocated to a p-p link is the ability to address "either end of this >link." The cost of providing that ability is to either use one of >our very large /64 subnets per link, or to do great violence to the >interface identifier concept in the new addressing architecture. > > Matt > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 16:38:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA12249; Thu, 18 Sep 1997 16:27:35 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA12242; Thu, 18 Sep 1997 16:27:26 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA14732; Thu, 18 Sep 1997 16:27:22 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA09779 for ; Thu, 18 Sep 1997 16:27:14 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id QAA21733; Thu, 18 Sep 1997 16:27:07 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id QAA20246; Thu, 18 Sep 1997 16:15:01 -0700 (PDT) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id QAA10332; Thu, 18 Sep 1997 16:25:12 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id QAA08133; Thu, 18 Sep 1997 16:26:57 -0700 (PDT) Date: Thu, 18 Sep 1997 16:26:57 -0700 (PDT) Message-Id: <199709182326.QAA08133@lookout.nsd.3com.com> To: Pedro Marques Cc: ipng@sunroof.eng.sun.com, 6bone@ISI.EDU, "Matt Crawford" Subject: (IPng 4432) /126 or /127 -- neither! In-Reply-To: <199709181902.MAA04758@pedrom-ultra.cisco.com> References: <199709181740.MAA02589@gungnir.fnal.gov> <199709181902.MAA04758@pedrom-ultra.cisco.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4274 Hi Pedro, Well if you mean by ununumbered ethernets assigning nodes on the ethernet (which are peering in some arbitrary fashion) in different ASs, addresses out of their respective AS's prefix then the case is no different then the p-to-p link case. In the ethernet case, as per Matt's suggestion you will configure nodes from AS A on that etherenet with addresses from a global prefix assigned to A and let nodes on the same subnet from AS B know that this prefix is on-link though they are not configured with addresses from the prefix and vice-versa. Yes the question still remains which method is better. 1) Do we use global prefixes assigned to the link which are not part of the prefixes assigned to either AS as you suggested or somebody did ? 2) Or configure nodes on the link with prefixes belonging to their respective ASs as Matt suggest. 3) Or use a global prefix which is part of a prefix assigned to one of the ASs and configure all nodes on the link with that prefix. As you said in the cases 2) and 3) you have to reconfigure the nodes with addresses out of new prefixes if renumbering occurs and introducing them in the IGPs of the involved ASs. But BGP anyway will require some reconfiguration on renumbering, atleast in policies. While in case of using 1) you will need to setup an administrative body. Quaizar > > I don't understand why you are mixing the p-to-p issue with the peering > address issue. What if instead of a serial the peer uses an ethernet ? > Do you proprose to use unnumbered ethernets too ? > > Matt> I believe routing protocols can perfectly well handle links whose > Matt> endpoints have unrelated global-scope addresses. > > In the context of BGP peering you have: > > i > A ----- B > > if link is numbered (global scope address): > > A and B will announce routes to each other using as nexthop the global > addresses Ia and Ib (respectivly). Those addresses are the ones annouced > in to the IBGP mesh. I's global prefix will be injected into the IGP. > > if the link is unnumbered: > > A and B will need to make those annoucements with Ag and Bg. That means > site B needs to manually configure a route to A's prefix and inject it > in it's own IGP a vice-versa. > > So, taking the address out of the link only adds complexity and creates > two possible reasons for manual reconfiguration: the renumbering of > site A and the renumbering of site B. While you only had one with > a numbered link: the renumbering of link i. > > I'm not claiming that using non-routable addresses on link i is the right > thing to do. I'm just trying to clarify what the potential problem might > be (i'm very tempted to say there is none)... > > Matt> RIPng, for example, uses link-local next-hop addresses > > Which is a real pain in the neck... because of all the nice effects you > get when you try to redistribute RIP into/from other routing protocols. > > But then you need to have link locals anyway in your table (because of > the potential need to send redirects)... > > Matt> In summary, the only capability that's lost by having no > Matt> subnet allocated to a p-p link is the ability to address > Matt> "either end of this link." > > No. What you loose by not having a subnet in a p-to-p link is the > ability to address the link's end-points knowing only how to route > to the link. That is why numbered links are very useful. > > Matt> The cost of providing that > Matt> ability is to either use one of our very large /64 subnets > Matt> per link, > Not really. > > Matt> or to do great violence to the interface > Matt> identifier concept in the new addressing architecture. > > Since i've absolutely no idea what interface identifiers are useful for i > cannot comment on that. > > Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 17:16:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA12312; Thu, 18 Sep 1997 17:04:39 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA12305; Thu, 18 Sep 1997 17:04:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA24949; Thu, 18 Sep 1997 17:04:27 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id RAA20441 for ; Thu, 18 Sep 1997 17:04:25 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id RAA25843; Thu, 18 Sep 1997 17:04:23 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id QAA24577; Thu, 18 Sep 1997 16:52:16 -0700 (PDT) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id RAA11651; Thu, 18 Sep 1997 17:02:27 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id RAA08147; Thu, 18 Sep 1997 17:04:12 -0700 (PDT) Date: Thu, 18 Sep 1997 17:04:12 -0700 (PDT) Message-Id: <199709190004.RAA08147@lookout.nsd.3com.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4434) Re: /126 or /127 -- neither! In-Reply-To: References: <199709181740.MAA02589@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2691 Steve, I think all these well known interface ids become useful in conjunction with their routing prefix. So if a site were assigned a /48 prefix a:b:c::/48, and I as a admin choose to use a:b:c:d::/64 part of my address space solely to carve out subnets for my p-to-p links, i.e. see no harm in it (as long as I am inverting the L bit in the EID part). I am not breaking the global uniqueness of some other EIDs using global EUIs because I am inverting the L bit, and I have no use for the well known anycast or all mobilty agents subnet address on this particular prefix. So there are EIDs which are globally unique and might be useful later. Then there are local EIDs which are well known on a link if I have use for them within the particular prefixes assigned to the link. Quaizar > In support of what Matt Crawford said, another reason to discourage the > use of /126 subnet prefixes for point-to-point links is that we probably > ought to reserve additional well-known interface IDs on every subnet, for > use in global-routing-scope, subnet-specific, well-known, anycast addresses > (whew!). > > Currently we have one such reserved interface ID, the value zero, which is > reserved to mean "all routers on this subnet". The Mobile IP working group > has requested designation of another well-known interface ID to mean "all > mobility agents on this subnet", and it seems like a reasonable request > to me. So I would not be surprised to see additional good uses for the > well-known interface ID concept in the future. If people start assigning > 126-bit subnet prefixes, that won't work. > > If people think this makes sense, we should immediately set aside a block > of local-identifier-scope interface IDs for this purpose, e.g., IDs 0-256, > so that assignments of local-identifier-scope IDs to real interfaces will > avoid that range. > > Comments? > > Steve > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 17:33:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA12353; Thu, 18 Sep 1997 17:21:35 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA12346; Thu, 18 Sep 1997 17:21:22 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA28501; Thu, 18 Sep 1997 17:21:20 -0700 Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA24740 for ; Thu, 18 Sep 1997 17:21:21 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with ESMTP id RAA18364; Thu, 18 Sep 1997 17:21:18 -0700 (PDT) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id RAA04882; Thu, 18 Sep 1997 17:21:18 -0700 (PDT) Date: Thu, 18 Sep 1997 17:21:18 -0700 (PDT) Message-Id: <199709190021.RAA04882@pedrom-ultra.cisco.com> From: Pedro Marques To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4435) Re: /126 or /127 -- neither! In-Reply-To: References: <199709181740.MAA02589@gungnir.fnal.gov> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1404 >>>>> "Steve" == Steve Deering writes: Steve> In support of what Matt Crawford said, another reason to Steve> discourage the use of /126 subnet prefixes for Steve> point-to-point links is that we probably ought to reserve Steve> additional well-known interface IDs on every subnet, for Steve> use in global-routing-scope, subnet-specific, well-known, Steve> anycast addresses (whew!). That will really lock us in the "class C" path permanently... We currently have absolutely no idea on how to use anycast addresses... It would make sense to ponder how to use them before reserving n bits of the address space for it, imho. Steve> If people think this makes sense, we should immediately set Steve> aside a block of local-identifier-scope interface IDs for Steve> this purpose, e.g., IDs 0-256, so that assignments of Steve> local-identifier-scope IDs to real interfaces will avoid Steve> that range. Please leave the small integers for humans... Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 17:41:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA12366; Thu, 18 Sep 1997 17:25:45 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA12359; Thu, 18 Sep 1997 17:25:29 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA29267; Thu, 18 Sep 1997 17:25:27 -0700 Received: from postoffice.cisco.com (postoffice-hme0.cisco.com [171.69.192.13]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA25917 for ; Thu, 18 Sep 1997 17:25:21 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA20750; Thu, 18 Sep 1997 17:24:47 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <3.0.1.32.19970918114657.006a2264@pobox.juniper.net> References: <199709181740.MAA02589@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Sep 1997 17:24:19 -0700 To: John W Stewart III From: Steve Deering Subject: (IPng 4436) Re: /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1520 [I have deleted the 6bone mailing list from the Cc: line. I think it is reasonable to expect that evryone on the 6bone list is also on the ipng list. -SD] At 11:46 AM -0700 9/18/97, John W Stewart III wrote: > but there's one thing that should be clearly noted here. doing this > [restricting subnet prefixes to <= 64 bits] results in lack of "automatic > connectivity" between two routers directly connected over a > point-to-point link. I don't see this. It is not mandatory that a point-to-point link be assigned a global-scope subnet prefix, thus it can be "unnumbered" in exactly the same way that an IPv4 p-to-p link can be unnumbered. (Note, however, that the interfaces on either end are required to have link-local addresses on that link, which is a concept that does not arise in IPv4. They may or may not also have site-local addresses.) I think that all that is being proposed is that *if* a global-scope (or site-local-scope) subnet prefix is assigned to a link, that prefix must not exceed 64 bits in length. I don't understand how such a restriction could prevent some functionality that is present in IPv4. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 17:57:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA12393; Thu, 18 Sep 1997 17:43:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA12385; Thu, 18 Sep 1997 17:43:00 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA02892; Thu, 18 Sep 1997 17:42:55 -0700 Received: from postoffice.cisco.com (postoffice-hme0.cisco.com [171.69.192.13]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA00699 for ; Thu, 18 Sep 1997 17:42:39 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA21866; Thu, 18 Sep 1997 17:42:37 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199709190021.RAA04882@pedrom-ultra.cisco.com> References: <199709181740.MAA02589@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Sep 1997 17:42:09 -0700 To: Pedro Marques From: Steve Deering Subject: (IPng 4437) Re: /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1818 At 5:21 PM -0700 9/18/97, Pedro Marques wrote: > That will really lock us in the "class C" path permanently... I don't know what the "class C" path means to you. To me, the mistake that was made with classful IPv4 address was to end up with the bit boundaries of the hierarchical components of addresses being hardcoded into routers and hosts. The lesson I took away from that is to keep all implicit knowledge of hierarchy boundaries out of the code (or the hardware or whatever). However, my suggestion regarding reserving some space within each subnet for anycast addresses, as well as Matt's proposal to limit subnet prefix lengths to <= 64 bits, are proposals for address allocation conventions, not something that IPv6 protocol implementations would know anything about (and which, therefore, could be changed in the future without having to change any of the installed base). > Steve> If people think this makes sense, we should immediately set > Steve> aside a block of local-identifier-scope interface IDs for > Steve> this purpose, e.g., IDs 0-256, so that assignments of > Steve> local-identifier-scope IDs to real interfaces will avoid > Steve> that range. > > Please leave the small integers for humans... What does that mean? The small integer range I am talking about is precisely for assignment by humans (the v6 IANA) to well-known anycast addresses, just like well-known port numbers. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 18:09:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA12412; Thu, 18 Sep 1997 17:54:10 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA12405; Thu, 18 Sep 1997 17:53:54 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA05514; Thu, 18 Sep 1997 17:53:51 -0700 Received: from rottweiler.cisco.com (rottweiler.cisco.com [171.69.1.237]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA03849 for ; Thu, 18 Sep 1997 17:53:47 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by rottweiler.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA04071; Thu, 18 Sep 1997 17:53:45 -0700 (PDT) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id RAA04920; Thu, 18 Sep 1997 17:53:45 -0700 (PDT) Date: Thu, 18 Sep 1997 17:53:45 -0700 (PDT) Message-Id: <199709190053.RAA04920@pedrom-ultra.cisco.com> From: Pedro Marques To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4438) Re: /126 or /127 -- neither! In-Reply-To: References: <199709181740.MAA02589@gungnir.fnal.gov> <199709190021.RAA04882@pedrom-ultra.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1303 >>>>> "Steve" == Steve Deering writes: Steve> At 5:21 PM -0700 9/18/97, Pedro Marques wrote: >> That will really lock us in the "class C" path permanently... Steve> I don't know what the "class C" path means to you. To me, Steve> the mistake that was made with classful IPv4 address was to Steve> end up with the bit boundaries of the hierarchical Steve> components of addresses being hardcoded into routers and Steve> hosts. Exactly... >> Please leave the small integers for humans... Steve> What does that mean? The small integer range I am talking Steve> about is precisely for assignment by humans (the v6 IANA) Steve> to well-known anycast addresses, just like well-known port Steve> numbers. I mean leave small integers to be assigned as the lower component of the address on manually configured addresses... As in prefix::1. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 18:15:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA12456; Thu, 18 Sep 1997 18:02:39 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA12449; Thu, 18 Sep 1997 18:02:21 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA07287; Thu, 18 Sep 1997 18:02:19 -0700 Received: from postoffice.cisco.com (postoffice-hme0.cisco.com [171.69.192.13]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA06240 for ; Thu, 18 Sep 1997 18:02:15 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA23147; Thu, 18 Sep 1997 18:01:45 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199709190021.RAA04882@pedrom-ultra.cisco.com> References: <199709181740.MAA02589@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Sep 1997 18:01:17 -0700 To: Pedro Marques From: Steve Deering Subject: (IPng 4439) Re: /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1373 Oops, I forgot to respond to another part of your message, Pedro: > We currently have absolutely no idea on how to use anycast addresses... > It would make sense to ponder how to use them before reserving n bits > of the address space for it, imho. It's exactly because we don't know how anycast addresses are going to be used that I want to reserve some space for them. If we don't reserve some space, we effectively rule out doing subnet-specific, well-known multicast addresses in the future, because there won't be any particular interface IDs that know are unassigned on all existing subnets. We *have* lots of address space, so I don't see what harm there is in setting some of it aside for a promising potential use of anycast. If it doesn't pan out, fine, we can put the reserved space back into the pool later. If anything, I expected someone to object that 256 reserved values is too few, given that we don't know how popular this potential usage might turn out to be. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 18:41:06 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA12523; Thu, 18 Sep 1997 18:24:54 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA12512; Thu, 18 Sep 1997 18:22:49 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA11096; Thu, 18 Sep 1997 18:22:46 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA11582 for ; Thu, 18 Sep 1997 18:22:48 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA01602; Thu, 18 Sep 97 18:21:14 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id SAA00471; Thu, 18 Sep 1997 18:23:18 -0700 Date: Thu, 18 Sep 1997 18:23:18 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199709190123.SAA00471@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4441) Re: /126 or /127 -- neither! X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1603 Matt, > > At the PAL1 meeting, when we were considering the 64 bit identifier > which is now part of the addressing architecture, the question arose > of teensy little subnets (such as /126's) for point-to-point links. I > argued at the time that we have no place, and need no place, for any > prefix with length in the range 65 to 127 bits, inclusive. That is, > every entry in a (unicast) IPv6 routing table ought to be either a > 128 bit "host route" or a prefix of 64 bits or less. > If I remember correctly one of the reasons some router vendors supported the move to the 64-bit EID was because they saw it as an oppurtunity to avoid having to inspect more than the high order 64-bits of the destination address during their route lookups. This is an Nth order justification but it would be rendered inoperative if we allow network prefixes to extend beyond 64-bits. Like you and Steve, I don't see what we lose by removing the possibility of network prefixes greater than 64-bits in length. I was not in favor of the change to the 64-bit EID's but if we have the change we ought to embrace it completely. That means that the "network" portion of the address is 64-bits in length or shorter. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 18:48:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA12555; Thu, 18 Sep 1997 18:34:20 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA12548; Thu, 18 Sep 1997 18:34:02 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA13181; Thu, 18 Sep 1997 18:34:00 -0700 Received: from postoffice.cisco.com (postoffice-hme0.cisco.com [171.69.192.13]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA14538 for ; Thu, 18 Sep 1997 18:33:59 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA24847; Thu, 18 Sep 1997 18:33:25 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <3.0.1.32.19970918180234.006964ac@pobox.juniper.net> References: <3.0.1.32.19970918114657.006a2264@pobox.juniper.net> <199709181740.MAA02589@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Sep 1997 18:32:57 -0700 To: John W Stewart III From: Steve Deering Subject: (IPng 4442) Re: /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2027 At 6:02 PM -0700 9/18/97, John W Stewart III wrote: > my concern is with numbered links. global-scope-unnumbered links > don't concern me OK, now I understand. Thanks. I think what you are asking for is that the two ends of a point-to-point link always be assigned interface IDs 1 and 2. Using a /30 prefix in IPv4 guarantees that that will be the case, but you still need external information to tell you that the prefix assigned to a given p2p link is in fact a /30 (since it is not mandatory in IPv4 that the subnet prefix of a p2p link be a /30). For those links under your own control you presumably have that info, but for those links that you control you could also simply impose the rule that the two ends are numbered 1 and 2, regardless of the subnet prefix length. Now, in IPv6, we could require that any subnet prefix assigned to a p2p link be a /127. But that would impose the burden of manual configuration of the address of at least one end of every p2p link, i.e., it would take away the ability to simply use stateless autoconfig to assign the addresses of both ends of a link. So it looks like a tradeoff between configuration convenience for some users vs. operational convenience for some other users. Given that a link owner can always use his/her own addressing convention within the non-globally-unique interface ID space (subject to avoiding reserved anycast IDs, if we decide to do that), I don't see a justification for denying to other link owners the ability to do stateless autoconfig of their own p2p links. If the above is totally incoherent, please say so. It felt that way when I wrote it. :-) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 19:03:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA12590; Thu, 18 Sep 1997 18:52:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA12583; Thu, 18 Sep 1997 18:52:34 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA16136; Thu, 18 Sep 1997 18:52:32 -0700 Received: from postoffice.cisco.com (postoffice-hme0.cisco.com [171.69.192.13]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA19291 for ; Thu, 18 Sep 1997 18:52:30 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA25786; Thu, 18 Sep 1997 18:52:28 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199709190053.RAA04920@pedrom-ultra.cisco.com> References: <199709181740.MAA02589@gungnir.fnal.gov> <199709190021.RAA04882@pedrom-ultra.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Sep 1997 18:51:29 -0700 To: Pedro Marques From: Steve Deering Subject: (IPng 4443) Re: /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1903 At 5:53 PM -0700 9/18/97, Pedro Marques wrote: > Steve> I don't know what the "class C" path means to you. To me, > Steve> the mistake that was made with classful IPv4 address was to > Steve> end up with the bit boundaries of the hierarchical > Steve> components of addresses being hardcoded into routers and > Steve> hosts. > > Exactly... OK, so do you buy my explanation as to why the proposal to reserve some space for well-known anycast addresses does not lock us into the "class C" path? > Steve> What does that mean? The small integer range I am talking > Steve> about is precisely for assignment by humans (the v6 IANA) > Steve> to well-known anycast addresses, just like well-known port > Steve> numbers. > > I mean leave small integers to be assigned as the lower component of the > address on manually configured addresses... As in prefix::1. Ah, I understand, and that concern did occur to me. My proposal would require that manually configured addresses would start at prefix::101 rather than prefix::1. Is that so bad? The alternative would be to reserve the anycast space from higher up in the interface ID space, but it's not clear where to put it. If we make it the top 256 (or 65536 or whatever) addresses in a 64-bit space, and if well-know anycast addresses actually get used for important services, then we are forever committed to keeping the interface ID field at least 64 bits wide, which is a commitment I was hoping to avoid making if possible. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 18 21:02:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA12737; Thu, 18 Sep 1997 20:54:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA12730; Thu, 18 Sep 1997 20:54:04 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA29998; Thu, 18 Sep 1997 20:54:03 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA14874 for ; Thu, 18 Sep 1997 20:54:03 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-29) id ; Thu, 18 Sep 1997 20:54:00 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199709190354.AA08634@zephyr.isi.edu> Subject: (IPng 4445) Re: /126 or /127 -- neither! To: thartric@mentat.com (Tim Hartrick) Date: Thu, 18 Sep 1997 20:54:00 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199709190123.SAA00471@feller.mentat.com> from "Tim Hartrick" at Sep 18, 97 06:23:18 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1259 > Like you and Steve, I don't see what we lose by removing the possibility > of network prefixes greater than 64-bits in length. I was not in favor of > the change to the 64-bit EID's but if we have the change we ought to embrace > it completely. That means that the "network" portion of the address is > 64-bits in length or shorter. > > Tim Hartrick Why does this strike me as roughly equal to the old network/host alignment in IPv4... It was found to be broken and we migrated to classes. In our maturity, we finally got rid of that idea with a very flexable address/mask pairing that really provides the most flexability. Now we are abandoning this flexability for the old network/host paradigm? Way too many steps back folks. Just because it seems really really huge, it sounds like a dis-service to our future to turn our backs on what we learned. -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 07:03:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA13068; Fri, 19 Sep 1997 06:51:07 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA13061; Fri, 19 Sep 1997 06:50:56 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA26419; Fri, 19 Sep 1997 06:50:53 -0700 Received: from mailhost1.BayNetworks.COM ([134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA03395 for ; Fri, 19 Sep 1997 06:50:54 -0700 Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id GAA02439 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id JAA11724 Posted-Date: Fri, 19 Sep 1997 09:50:48 -0400 (EDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id JAA10860; Fri, 19 Sep 1997 09:50:46 -0400 for Message-Id: <3.0.32.19970919094707.006865b8@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 19 Sep 1997 09:47:07 -0400 To: Steve Deering From: Dimitry Haskin Subject: (IPng 4447) Re: /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 882 At 11:27 AM 9/18/97 -0700, Steve Deering wrote: >If people think this makes sense, we should immediately set aside a block >of local-identifier-scope interface IDs for this purpose, e.g., IDs 0-256, >so that assignments of local-identifier-scope IDs to real interfaces will >avoid that range. > >Comments? > I think it is a good idea but please decide quickly. It affects the IPv6/PPP spec. I'm already waiting for resolution on the Min. Path MTU value before I can re-issue the spec. >Steve Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 09:48:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13399; Fri, 19 Sep 1997 09:31:45 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13392; Fri, 19 Sep 1997 09:31:35 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA08742; Fri, 19 Sep 1997 09:31:33 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA24883 for ; Fri, 19 Sep 1997 09:31:31 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA21739; Fri, 19 Sep 1997 12:16:51 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA06082; Fri, 19 Sep 1997 12:16:44 -0400 Message-Id: <9709191616.AA06082@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4448) Re: /126 or /127 -- neither! In-Reply-To: Your message of "Thu, 18 Sep 1997 18:23:18 PDT." <199709190123.SAA00471@feller.mentat.com> Date: Fri, 19 Sep 1997 12:16:44 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 649 I support network prefixes not being greater than 64bits. In fact this is a critical assumption I believe we must depend on for IPv6. I won't go into all the pain if this is not the case. I support reserving bits for anycast addressees per Steves suggestion. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 09:54:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13408; Fri, 19 Sep 1997 09:40:05 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13401; Fri, 19 Sep 1997 09:39:49 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA11433; Fri, 19 Sep 1997 09:39:46 -0700 Received: from mailhost2.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA27752 for ; Fri, 19 Sep 1997 09:39:36 -0700 Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by mailhost2.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id JAA26752 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id MAA20051 Posted-Date: Fri, 19 Sep 1997 12:39:30 -0400 (EDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id MAA06059; Fri, 19 Sep 1997 12:39:29 -0400 for Message-Id: <3.0.32.19970919123550.006c3658@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 19 Sep 1997 12:35:51 -0400 To: ipng@sunroof.eng.sun.com From: Dimitry Haskin Subject: (IPng 4449) BGP and renumbering.. was Re: /126 or /127 -- neither! Cc: idr@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4143 At 12:02 PM 9/18/97 -0700, Pedro Marques wrote: > > i > A ----- B > >if link is numbered (global scope address): > >A and B will announce routes to each other using as nexthop the global >addresses Ia and Ib (respectivly). Those addresses are the ones annouced >in to the IBGP mesh. I's global prefix will be injected into the IGP. > >if the link is unnumbered: > >A and B will need to make those annoucements with Ag and Bg. That means >site B needs to manually configure a route to A's prefix and inject it >in it's own IGP a vice-versa. > >So, taking the address out of the link only adds complexity and creates >two possible reasons for manual reconfiguration: the renumbering of >site A and the renumbering of site B. While you only had one with >a numbered link: the renumbering of link i. > I think this requires a little bit of elaboration. At a BGP WG meeting in Munich I did a presentation that pointed to a potential affect of advertising a global-scope address in the NEXT_HOP attribute of BGP route updates. Since a route to such a global address has to be injected into IGP, it would make re-numbering somewhat more difficult. In essence, if a global address of one site it advertised as a next hop address to another site, the addressing information of one site gets injected into IGP of another site. This is exactly what I believe we tried to avoid in order to minimize re-numbering dependencies between sites. Note that currently there is no automatic way to correct IGP tables of at least one of two bordering sites when another site renumbers. As a solution, I proposed to avoid advertising of a global-scope address as the NEXT_HOP across site boundaries. Instead a link-local address is used and, when a border router re-advertise external routes within own AS, it replaces the NEXT_HOP with a site-local address of one of the router own interfaces. During the deliberation at the meeting this approach seems to be rejected on the following grounds: 1) There is no conceptual relationship between Site and AS. Therefore site and AS topologies can arbitrary overlap and as the result site-local addresses can not be generally used within AS. 2) We loose some functionality since "third party" addresses can't be advertised in the NEXT_HOP and all traffic will be forced through the border router that does route re-advertisement. Under examination 1) does not appear to be a valid concern. If site-local addresses are to be used for communications within a site (as recommended), an AS must be completely contained within a single site. Otherwise site-local prefixes of one site can be flooded to other sites of the same AS by a intra-AS routing protocol (IGP). 2) is partially true. But is it really a problem for the vast majority of sites? I believe that generally border routers that redistribute external routes within its AS also serve as forwarders for routes they advertise. Note that it is still possible to advertise a site-local address of a different border router within own AS. The functionality that is lost is the ability to use BGP information alone to establish NBMA shortcuts to a BGP peer in an adjacent AS. I'm not sure if it's normally done due to the policy concerns. To summarize I believe that the proposed approach is applicable and desirable in many deployments. It can be definitely used at 6bone. For those sites that insist on advertising global-scope next hop addresses across site boundaries, it may be desirable to allocate prefixes from a single reserved non-routable TLA which can be assigned to their DMZ links (links connecting ASs). Assuming that such prefixes never need to be renumbered, it takes re-numbering concern away but will require administration. Do svidanja, Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 10:10:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13422; Fri, 19 Sep 1997 09:51:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13415; Fri, 19 Sep 1997 09:51:01 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA14572; Fri, 19 Sep 1997 09:50:58 -0700 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA01606 for ; Fri, 19 Sep 1997 09:50:26 -0700 Received: from rama.imag.fr (rama.imag.fr [129.88.30.9]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id SAA12163; Fri, 19 Sep 1997 18:50:06 +0200 (MET DST) Received: (from durand@localhost) by rama.imag.fr (8.8.5/8.8.5) id SAA03731; Fri, 19 Sep 1997 18:50:06 +0200 (MET DST) From: "Alain Durand" Message-Id: <970919185006.ZM3725@rama.imag.fr> Date: Fri, 19 Sep 1997 18:50:06 +0200 In-Reply-To: Dimitry Haskin "(IPng 4447) Re: /126 or /127 -- neither!" (Sep 19, 9:47am) References: <3.0.32.19970919094707.006865b8@pobox> X-Mailer: Z-Mail (4.0.1 13Jan97) To: 6bone@isi.edu, ipng@sunroof.eng.sun.com Subject: (IPng 4450) /64 or /124,/126,/127,/128 addresses? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2596 I would like to make some comments on this issue from my 6bone experience with tunnels. 1) There is an interroperability issue now on the way people are doing tunnels (which are by essence Point ot Point links). Some implementations can use /128 addresses, end-point addresses may be taken from any address spaces. Some implementations do not allow anything longer that /127, thus there is a technical need to number the tunnel with a /124, /126 or /127 network. 2) If the tunnel need a network number, the question is now in which address space this network is taken from? If it's a tunnel between an ISP and a site,it's not a serious matter, if it's a tunnel between two ISPs, then it's an issue: will this network be taken from address space A, B or from a neutral "DMZ". Taking addresses from the DMZ simplify renumbering (I buy Pedro's arguments) but it's a real burden to delegate small chunk of this DMZ. Using networks from address space A or B doens't help for renumbering anymore than using /128 addresses. 3) In designing the G6 networks on the 6bone with pTLA & pNLAs, I have dedicated a /64 network for all my ppp links, serial or tunnels. This prooved very easy to extend to any number of links If I had to use a /64 prefix for each tunnel, I will first waste a huge lot of address space (maybe it's not an issue?) and, worse, to maintain a good design in my addressing architecture, I will have to reserve a large part of my site /48 prefix for the tunnels, a /52 or /56 prefix. That's the reason why I like long prefixes, like /124 (easier to read in hex. digits), and I even like /128 more! 4) Routers must be configured manually. We can not use stateless autoconf. I found easier to number my routers starting from 1 than to build manually an EUI64 for them. If ever one wants to reserve well known addresses, I'd rather like to have 0x000 to 0xFFF reserved for manually configured hosts and then from 0x1000 to, let's say 0x1FFF for well known addresses 5) If there a need of well known addresses for a point to point link? Couldn't we say "well known addresses are reserved for non PtP links. So my personal take is that /128 addresses for tunnels are the simplest thing to use. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 10:21:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA13584; Fri, 19 Sep 1997 10:02:50 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA13570; Fri, 19 Sep 1997 10:01:51 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id KAA10741 for ; Fri, 19 Sep 1997 10:00:54 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA26401; Fri, 19 Sep 1997 09:58:10 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA12458; Thu, 18 Sep 1997 18:02:48 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA07381; Thu, 18 Sep 1997 18:02:46 -0700 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA06410 for ; Thu, 18 Sep 1997 18:02:45 -0700 Received: from abfab.juniper.net (abfab.juniper.net [208.197.169.86]) by red.juniper.net (8.8.5/8.8.5) with SMTP id SAA08164; Thu, 18 Sep 1997 18:02:23 -0700 (PDT) Message-Id: <3.0.1.32.19970918180234.006964ac@pobox.juniper.net> X-Sender: jstewart@pobox.juniper.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 18 Sep 1997 18:02:34 -0700 To: Steve Deering From: John W Stewart III Subject: (IPng 4451) Re: /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <3.0.1.32.19970918114657.006a2264@pobox.juniper.net> <199709181740.MAA02589@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2409 my concern is with numbered links. global-scope-unnumbered links don't concern me with v4 links numbered out of a /30, if i am logged on to a router and need to jump across a point-to-point link to an adjacent router, i know that the remote address is +/-1 relative to the address of my side of the link. in v6, for link-local addresses, is it an implementation detail whether or not i (a user) have access to the ND data heard over the p-to-p link to know which address to telnet to? if i don't know what address to telnet to, then it doesn't help. (this is a serious question .. my concerns may not matter) yes this is boring operational stuff, but i can't tell you how many times a bunch of concatenated hop-by-hop telnets was the only way to get to a sick router to fix a whole network's igp... /jws At 05:24 PM 9/18/97 -0700, Steve Deering wrote: >[I have deleted the 6bone mailing list from the Cc: line. I think it >is reasonable to expect that evryone on the 6bone list is also on the >ipng list. -SD] > >At 11:46 AM -0700 9/18/97, John W Stewart III wrote: >> but there's one thing that should be clearly noted here. doing this >> [restricting subnet prefixes to <= 64 bits] results in lack of "automatic >> connectivity" between two routers directly connected over a >> point-to-point link. > >I don't see this. It is not mandatory that a point-to-point link be >assigned a global-scope subnet prefix, thus it can be "unnumbered" in >exactly the same way that an IPv4 p-to-p link can be unnumbered. >(Note, however, that the interfaces on either end are required to have >link-local addresses on that link, which is a concept that does not >arise in IPv4. They may or may not also have site-local addresses.) > >I think that all that is being proposed is that *if* a global-scope >(or site-local-scope) subnet prefix is assigned to a link, that prefix >must not exceed 64 bits in length. I don't understand how such a >restriction could prevent some functionality that is present in IPv4. > >Steve > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 11:17:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA13673; Fri, 19 Sep 1997 11:07:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA13666; Fri, 19 Sep 1997 11:06:59 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA09617; Fri, 19 Sep 1997 11:06:56 -0700 Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA27827 for ; Fri, 19 Sep 1997 11:06:54 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by trix.cisco.com (8.6.12/8.6.5) with ESMTP id LAA17858; Fri, 19 Sep 1997 11:06:59 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA05297; Fri, 19 Sep 1997 11:06:51 -0700 (PDT) Date: Fri, 19 Sep 1997 11:06:51 -0700 (PDT) Message-Id: <199709191806.LAA05297@pedrom-ultra.cisco.com> From: Pedro Marques To: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4453) BGP and renumbering.. was Re: /126 or /127 -- neither! In-Reply-To: <3.0.32.19970919123550.006c3658@pobox> References: <3.0.32.19970919123550.006c3658@pobox> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5072 >>>>> "Dimitry" == Dimitry Haskin writes: >> i A ----- B >> >> if link is numbered (global scope address): >> >> A and B will announce routes to each other using as nexthop the >> global addresses Ia and Ib (respectivly). Those addresses are >> the ones annouced in to the IBGP mesh. I's global prefix will >> be injected into the IGP. >> >> if the link is unnumbered: >> >> A and B will need to make those annoucements with Ag and >> Bg. That means site B needs to manually configure a route to >> A's prefix and inject it in it's own IGP a vice-versa. >> >> So, taking the address out of the link only adds complexity and >> creates two possible reasons for manual reconfiguration: the >> renumbering of site A and the renumbering of site B. While you >> only had one with a numbered link: the renumbering of link i. >> Dimitry> I think this requires a little bit of elaboration. Dimitry> At a BGP WG meeting in Munich I did a presentation that Dimitry> pointed to a potential affect of advertising a Dimitry> global-scope address in the NEXT_HOP attribute of BGP Dimitry> route updates. Since a route to such a global address has Dimitry> to be injected into IGP, it would make re-numbering Dimitry> somewhat more difficult. In essence, if a global address Dimitry> of one site it advertised as a next hop address to Dimitry> another site, the addressing information of one site gets Dimitry> injected into IGP of another site. This is exactly what I Dimitry> believe we tried to avoid in order to minimize Dimitry> re-numbering dependencies between sites. Note that Dimitry> currently there is no automatic way to correct IGP tables Dimitry> of at least one of two bordering sites when another site Dimitry> renumbers. Dimitry> As a solution, I proposed to avoid advertising of a Dimitry> global-scope address as the NEXT_HOP across site Dimitry> boundaries. Instead a link-local address is used and, Dimitry> when a border router re-advertise external routes within Dimitry> own AS, it replaces the NEXT_HOP with a site-local Dimitry> address of one of the router own interfaces. Dimitry> During the deliberation at the meeting this approach Dimitry> seems to be rejected on the following grounds: Dimitry> 1) There is no conceptual relationship between Site and Dimitry> AS. Therefore site and AS topologies can arbitrary Dimitry> overlap and as the result site-local addresses can not be Dimitry> generally used within AS. Dimitry> 2) We loose some functionality since "third party" Dimitry> addresses can't be advertised in the NEXT_HOP and all Dimitry> traffic will be forced through the border router that Dimitry> does route re-advertisement. 3) We loose the ability to include the metric of the interconnection link in the BGP best path decision. Dimitry> Under examination 1) does not appear to be a valid Dimitry> concern. If site-local addresses are to be used for Dimitry> communications within a site (as recommended), an AS must Dimitry> be completely contained within a single site. No. An AS can potentially encompass several sites... Dimitry> Otherwise Dimitry> site-local prefixes of one site can be flooded to other Dimitry> sites of the same AS by a intra-AS routing protocol Dimitry> (IGP). Running the same IGP instance across AS boundaries ? Somehow that doesn't sound a realistic solution to me. Dimitry> For those sites that insist on advertising global-scope Dimitry> next hop addresses across site boundaries, it may be Dimitry> desirable to allocate prefixes from a single reserved Dimitry> non-routable TLA which can be assigned to their DMZ links Dimitry> (links connecting ASs). Assuming that such prefixes Dimitry> never need to be renumbered, it takes re-numbering Dimitry> concern away but will require administration. Like i told you in Munich, let's not break the protocol. If you really want to you can still use site local addresses for all the addresses you advertise into your IBGP... As it is currently defined, IPv6's BGP can take any beating you want. Restricting it to carry link locals in ebgp sessions would seriously handicap the protocol. For instance you would completly loose the capability to do multihop ebgp. A very personal opinion: Is this dicussion really relevant ? Is this really the major obstacle to automatic renumbering on the fly of entire confederations of ASes without any manual intervention ? Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 12:45:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA13798; Fri, 19 Sep 1997 12:35:49 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA13791; Fri, 19 Sep 1997 12:35:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA07394; Fri, 19 Sep 1997 12:35:37 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA26903 for ; Fri, 19 Sep 1997 12:35:38 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id MAA28000; Fri, 19 Sep 1997 12:34:57 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id MAA00096; Fri, 19 Sep 1997 12:22:42 -0700 (PDT) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id MAA04172; Fri, 19 Sep 1997 12:33:01 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id MAA00518; Fri, 19 Sep 1997 12:34:54 -0700 (PDT) Date: Fri, 19 Sep 1997 12:34:54 -0700 (PDT) Message-Id: <199709191934.MAA00518@lookout.nsd.3com.com> To: Pedro Marques Cc: Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4457) BGP and renumbering.. was Re: /126 or /127 -- neither! In-Reply-To: <199709191806.LAA05297@pedrom-ultra.cisco.com> References: <3.0.32.19970919123550.006c3658@pobox> <199709191806.LAA05297@pedrom-ultra.cisco.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1525 > you advertise into your IBGP... > > As it is currently defined, IPv6's BGP can take any beating you want. > Restricting it to carry link locals in ebgp sessions would seriously > handicap the protocol. > > For instance you would completly loose the capability to do multihop ebgp. I think if we remove the restriction that the NEXT_HOP will either only carry link-local or global IPv6 address, i.e. allow either, then as per Dimitry's Proposal we can avoid propogating global IX addresses in the most usual case of single hop ebgp. THIS will also allow us to do multihop ebgp at the added complexity of propagating IX addresses into IGPs of the AS. Instead of replacement of link-local address of ebgp peer by the site-local, I would propose that the site-local address be added to the link-local address of the ebgp peer. This will allow the us to retain the NBMA shortcut functionality too. Quaizar > > A very personal opinion: Is this dicussion really relevant ? Is this really > the major obstacle to automatic renumbering on the fly of entire confederations > of ASes without any manual intervention ? > > Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 13:54:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13864; Fri, 19 Sep 1997 13:21:48 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13857; Fri, 19 Sep 1997 13:21:42 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id NAA02605 for ; Fri, 19 Sep 1997 13:21:41 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26630; Fri, 19 Sep 1997 13:19:18 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA13654; Fri, 19 Sep 1997 11:02:56 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA08300; Fri, 19 Sep 1997 11:02:53 -0700 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA29955 for ; Fri, 19 Sep 1997 11:02:46 -0700 Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id LAA18333; Fri, 19 Sep 1997 11:02:13 -0700 (PDT) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id LAA09497; Fri, 19 Sep 1997 11:02:11 -0700 (PDT) Message-Id: <199709191802.LAA09497@base.juniper.net> To: Dimitry Haskin cc: ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4459) Re: BGP and renumbering.. was Re: /126 or /127 -- neither! In-reply-to: Your message of "Fri, 19 Sep 1997 12:35:51 EDT." <3.0.32.19970919123550.006c3658@pobox> Date: Fri, 19 Sep 1997 11:02:11 -0700 From: Paul Traina Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 632 I have to agree with Dmitry's conclusions. Operational experience on the IPv4 network shows that the vast majority of large sites are already reseting the next hop to an address on the border router itself before advertising info into their IGP mesh. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 13:56:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13894; Fri, 19 Sep 1997 13:23:12 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13884; Fri, 19 Sep 1997 13:22:58 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id NAA02821 for ; Fri, 19 Sep 1997 13:22:57 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26684; Fri, 19 Sep 1997 13:20:34 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA13735; Fri, 19 Sep 1997 11:50:56 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA24337; Fri, 19 Sep 1997 11:50:53 -0700 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA12541 for ; Fri, 19 Sep 1997 11:50:51 -0700 Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id LAA20431; Fri, 19 Sep 1997 11:50:19 -0700 (PDT) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id LAA10063; Fri, 19 Sep 1997 11:50:17 -0700 (PDT) Message-Id: <199709191850.LAA10063@base.juniper.net> To: Vince Fuller cc: Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4462) Re: BGP and renumbering.. was Re: /126 or /127 -- neither! In-reply-to: Your message of "Fri, 19 Sep 1997 11:17:59 PDT." Date: Fri, 19 Sep 1997 11:50:16 -0700 From: Paul Traina Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1770 From: Vince Fuller Subject: Re: BGP and renumbering.. was Re: (IPng 4426) /126 or /127 -- neither! I have to agree with Dmitry's conclusions. Operational experience on the IPv4 network shows that the vast majority of large sites are already reseting the next hop to an address on the border router itself before advertising info into their IGP mesh. ^^^ sorry: s/IGP/IBGP/ Really? Can you provide specific references to large providers? I was under the impression that most propagate public-peering next-hops unmolested (thoug this is becoming less relavent along with the public interconnects). In a past life, I've seen "set next-hop-self" used on ibgp peers in configs by Sprint, MCI, and UUNET to specificly avoid carrying the "DMZ" network's routing information in their IGP. I agree, in principal, that rewriting next-hops on export to IGP can generall avoid having to globally propagate addresses specific to an IX, but the exact technique for doing that needs to be clearly indicated (and there are a few rare cases, i.e. a provider with multiple routers at an IX, where it may be problematic). We're in 100% agreement. There are cases where this isn't optimal, then you need to do something else, my point was that in the general case, we have operational experience that shows it's a win. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 13:55:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13881; Fri, 19 Sep 1997 13:22:26 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13866; Fri, 19 Sep 1997 13:22:17 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id NAA02681 for ; Fri, 19 Sep 1997 13:22:15 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26657; Fri, 19 Sep 1997 13:19:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA13676; Fri, 19 Sep 1997 11:22:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA15044; Fri, 19 Sep 1997 11:22:42 -0700 Received: from valinor.barrnet.net (valinor.barrnet.net [204.160.73.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA03113 for ; Fri, 19 Sep 1997 11:22:23 -0700 Received: (from vaf@localhost) by valinor.barrnet.net (8.6.8/8.6.6) id LAA27577; Fri, 19 Sep 1997 11:18:00 -0700 Date: Fri, 19 Sep 97 11:17:59 PDT From: Vince Fuller To: Paul Traina Cc: Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Phone: (415) 528-7227 USMail: 3801 East Bayshore Rd, Palo Alto, CA, 94303 Subject: (IPng 4460) Re: BGP and renumbering.. was Re: /126 or /127 -- neither! In-Reply-To: Your message of Fri, 19 Sep 1997 11:02:11 -0700 Message-ID: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1207 I have to agree with Dmitry's conclusions. Operational experience on the IPv4 network shows that the vast majority of large sites are already reseting the next hop to an address on the border router itself before advertising info into their IGP mesh. Really? Can you provide specific references to large providers? I was under the impression that most propagate public-peering next-hops unmolested (though this is becoming less relavent along with the public interconnects). I agree, in principal, that rewriting next-hops on export to IGP can generally avoid having to globally propagate addresses specific to an IX, but the exact technique for doing that needs to be clearly indicated (and there are a few rare cases, i.e. a provider with multiple routers at an IX, where it may be problematic). --Vince -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 13:57:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13905; Fri, 19 Sep 1997 13:24:03 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13898; Fri, 19 Sep 1997 13:23:51 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id NAA02956 for ; Fri, 19 Sep 1997 13:23:50 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26711; Fri, 19 Sep 1997 13:21:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA13746; Fri, 19 Sep 1997 11:57:46 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA26609; Fri, 19 Sep 1997 11:57:43 -0700 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA14078 for ; Fri, 19 Sep 1997 10:25:47 -0700 Received: from abfab.juniper.net (abfab.juniper.net [208.197.169.86]) by red.juniper.net (8.8.5/8.8.5) with SMTP id KAA17478; Fri, 19 Sep 1997 10:25:45 -0700 (PDT) Message-Id: <3.0.1.32.19970919102555.006b0294@pobox.juniper.net> X-Sender: jstewart@pobox.juniper.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Sep 1997 10:25:55 -0700 To: Steve Deering From: John W Stewart III Subject: (IPng 4463) Re: /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <3.0.1.32.19970918180234.006964ac@pobox.juniper.net> <3.0.1.32.19970918114657.006a2264@pobox.juniper.net> <199709181740.MAA02589@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3371 you ascribe too much religion to my concerns :-) i'm being a dumb requirements person and saying: if i'm on an ipv6 router (or, more generally, an ipv6 node) i would like to be able to reach an adjacent router connected via a p-to-p line without having to depend on any kind of dynamic routing and with little-to-no static configuration information. this is a requirement that ipv4 supports (with /30s and coordinated addressing) and is something that many many people currently depend on now, how to reach the requirement? well, you could do the /127 (or /126) mask, but i think that's contradictory to the [option for] globally-unique low-order 64 bits, so i'd prefer if that weren't the mechanism. another mechanism would be to make sure that i have enough access to the ND data to know the link-local address of the node i want to reach; that would not be something suitable for standardization, but if that's the model people have in their heads, that would also be fine. another way to do it would be for p-to-p links to be configured with both their address as well as the address of their neighbor; this obviously has precedent, but it also (as you said) increases the amount of manaul config, thus increasing the likelihood of errors /jws At 06:32 PM 9/18/97 -0700, Steve Deering wrote: >At 6:02 PM -0700 9/18/97, John W Stewart III wrote: >> my concern is with numbered links. global-scope-unnumbered links >> don't concern me > >OK, now I understand. Thanks. > >I think what you are asking for is that the two ends of a point-to-point >link always be assigned interface IDs 1 and 2. Using a /30 prefix in >IPv4 guarantees that that will be the case, but you still need external >information to tell you that the prefix assigned to a given p2p link >is in fact a /30 (since it is not mandatory in IPv4 that the subnet prefix >of a p2p link be a /30). For those links under your own control you >presumably have that info, but for those links that you control you could >also simply impose the rule that the two ends are numbered 1 and 2, >regardless of the subnet prefix length. > >Now, in IPv6, we could require that any subnet prefix assigned to a p2p >link be a /127. But that would impose the burden of manual configuration >of the address of at least one end of every p2p link, i.e., it would take >away the ability to simply use stateless autoconfig to assign the addresses >of both ends of a link. So it looks like a tradeoff between configuration >convenience for some users vs. operational convenience for some other users. >Given that a link owner can always use his/her own addressing convention >within the non-globally-unique interface ID space (subject to avoiding >reserved anycast IDs, if we decide to do that), I don't see a justification >for denying to other link owners the ability to do stateless autoconfig of >their own p2p links. > >If the above is totally incoherent, please say so. It felt that way when >I wrote it. :-) > >Steve > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 13:56:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13882; Fri, 19 Sep 1997 13:22:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13869; Fri, 19 Sep 1997 13:22:18 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA17515; Fri, 19 Sep 1997 13:22:16 -0700 Received: from mailhost2.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA10665 for ; Fri, 19 Sep 1997 13:22:14 -0700 Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by mailhost2.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id NAA05850 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id QAA03000 Posted-Date: Fri, 19 Sep 1997 16:22:08 -0400 (EDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id QAA02824; Fri, 19 Sep 1997 16:22:09 -0400 for Message-Id: <3.0.32.19970919161831.0068fbe8@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 19 Sep 1997 16:18:31 -0400 To: Pedro Marques From: Dimitry Haskin Subject: (IPng 4461) Re: BGP and renumbering.. was Re: /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3720 At 11:06 AM 9/19/97 -0700, Pedro Marques wrote: > ... > Dimitry> 1) There is no conceptual relationship between Site and > Dimitry> AS. Therefore site and AS topologies can arbitrary > Dimitry> overlap and as the result site-local addresses can not be > Dimitry> generally used within AS. > > Dimitry> 2) We loose some functionality since "third party" > Dimitry> addresses can't be advertised in the NEXT_HOP and all > Dimitry> traffic will be forced through the border router that > Dimitry> does route re-advertisement. > >3) We loose the ability to include the metric of the interconnection link >in the BGP best path decision. > Why is that? > Dimitry> Under examination 1) does not appear to be a valid > Dimitry> concern. If site-local addresses are to be used for > Dimitry> communications within a site (as recommended), an AS must > Dimitry> be completely contained within a single site. > >No. An AS can potentially encompass several sites... If we define AS as an IGP cloud (I know there are exotic use of AS numbers which is irrelevant for purpose of this discursion) I don't really see how this can be accomplished with site-local prefixes. Example would help. > > Dimitry> Otherwise > Dimitry> site-local prefixes of one site can be flooded to other > Dimitry> sites of the same AS by a intra-AS routing protocol > Dimitry> (IGP). > >Running the same IGP instance across AS boundaries ? >Somehow that doesn't sound a realistic solution to me. I didn't say that, did I? I rather implied that it was not realistic to run IGP across site boundaries. This is why I concluded that an AS (or IGP domain if you wish) was always contained within a single site. > > Dimitry> For those sites that insist on advertising global-scope > Dimitry> next hop addresses across site boundaries, it may be > Dimitry> desirable to allocate prefixes from a single reserved > Dimitry> non-routable TLA which can be assigned to their DMZ links > Dimitry> (links connecting ASs). Assuming that such prefixes > Dimitry> never need to be renumbered, it takes re-numbering > Dimitry> concern away but will require administration. > >Like i told you in Munich, let's not break the protocol. If you really >want to you can still use site local addresses for all the addresses >you advertise into your IBGP... > As far as I remember it was required to advertise a global address in the NEXT_HOP attribute. In should be fixed not to require that. I don't think removing such a requirement would break the protocol -- just opposite, it will make it more flexible. The spec should also explain what to do if only link-local address is received in the NEXT_HOP attribute from EBGP peer. >As it is currently defined, IPv6's BGP can take any beating you want. >Restricting it to carry link locals in ebgp sessions would seriously >handicap the protocol. > I did not ask for such a restriction, did I? I said it would be a good approach for the vast majority cases but not *all* cases. >For instance you would completly loose the capability to do multihop ebgp. > >A very personal opinion: Is this dicussion really relevant ? Is this really >the major obstacle to automatic renumbering on the fly of entire confederations >of ASes without any manual intervention ? > > Pedro. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 13:59:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13915; Fri, 19 Sep 1997 13:25:22 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13908; Fri, 19 Sep 1997 13:25:03 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id NAA03081 for ; Fri, 19 Sep 1997 13:25:02 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26738; Fri, 19 Sep 1997 13:22:38 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA13802; Fri, 19 Sep 1997 12:45:56 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA09399; Fri, 19 Sep 1997 12:45:49 -0700 Received: from irp-view2.cisco.com (irp-view2.cisco.com [171.69.58.117]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA29705 for ; Fri, 19 Sep 1997 12:45:19 -0700 Received: from kraak.cisco.com (hsmit-isdn-home.cisco.com [171.68.167.70]) by irp-view2.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id MAA07432; Fri, 19 Sep 1997 12:39:44 -0700 (PDT) Received: (from hsmit@localhost) by kraak.cisco.com (8.8.4-Cisco.1/HSMIT190697) id VAA09159; Fri, 19 Sep 1997 21:40:31 +0200 (MET DST) From: Henk Smit Message-Id: <199709191940.VAA09159@kraak.cisco.com> Subject: (IPng 4464) Re: BGP and renumbering.. was Re: /126 or /127 -- neither! To: pst@juniper.net (Paul Traina) Date: Fri, 19 Sep 1997 21:40:31 +0200 (MET DST) Cc: vaf@valinor.barrnet.net, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <199709191850.LAA10063@base.juniper.net> from "Paul Traina" at Sep 19, 97 11:50:16 am X-Mailer: ELM [version 2.4 PL25 (uu)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1182 Paul wrote: > In a past life, I've seen "set next-hop-self" used on ibgp peers > in configs by Sprint, MCI, and UUNET to specificly avoid carrying > the "DMZ" network's routing information in their IGP. Just this week I got a request from one of those for a feature in our ISIS implementation, related to this. Supposedly they want to be able to influence IGP metrics to the BGP nexthops. This will enable them to fine-tune route selection when doing shortest-exit routing. I was told that because of the growth of private peerings between the large ISPs, there is more need for this kind of fine-tuning. So it might be that carrying original eBGP next-hop info inside the iBGP-mesh will be more important in the near future. Maybe one of the large ISPs can comment on this ? Henk. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 15:14:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14041; Fri, 19 Sep 1997 15:05:02 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14034; Fri, 19 Sep 1997 15:04:57 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id PAA17502 for ; Fri, 19 Sep 1997 15:04:55 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA26858; Fri, 19 Sep 1997 15:02:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA14019; Fri, 19 Sep 1997 14:55:22 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA11358; Fri, 19 Sep 1997 14:55:17 -0700 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA09203 for ; Fri, 19 Sep 1997 14:55:16 -0700 Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id OAA24815; Fri, 19 Sep 1997 14:54:43 -0700 (PDT) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id OAA11787; Fri, 19 Sep 1997 14:54:40 -0700 (PDT) Message-Id: <199709192154.OAA11787@base.juniper.net> To: Dimitry Haskin cc: Pedro Marques , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4466) Re: BGP and renumbering.. was Re: /126 or /127 -- neither! In-reply-to: Your message of "Fri, 19 Sep 1997 16:18:31 EDT." <3.0.32.19970919161831.0068fbe8@pobox> Date: Fri, 19 Sep 1997 14:54:40 -0700 From: Paul Traina Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2130 From: Dimitry Haskin Subject: Re: (IPng 4453) BGP and renumbering.. was Re: /126 or /127 -- neither! At 11:06 AM 9/19/97 -0700, Pedro Marques wrote: > ... > Dimitry> 1) There is no conceptual relationship between Site and > Dimitry> AS. Therefore site and AS topologies can arbitrary > Dimitry> overlap and as the result site-local addresses can not be > Dimitry> generally used within AS. > > Dimitry> 2) We loose some functionality since "third party" > Dimitry> addresses can't be advertised in the NEXT_HOP and all > Dimitry> traffic will be forced through the border router that > Dimitry> does route re-advertisement. > >3) We loose the ability to include the metric of the interconnection link >in the BGP best path decision. > Why is that? Please note the following terminology, I'm talking ingres/egress based on routing information flow, not packet forwarding flow: remote ---------> ingress -------------> egress AS router router router If you just use your IGP to determine the cost of reaching a particular point, any meansurement the egress router would make would be based on the metric of the path from the ingress router to the egress router, instead of the metric along the path from the remote router in the other AS to the egress router. A1 --- OC192 --- B1 --- OC192 --- >---- B3 A2 --- 9600b --- B2 --- OC192 --- This makes a big difference if you have a high speed internal backbone with two peer connections to a remote AS, one on a fast link, the other on a slow link. You really want to take into account the cost of reaching the remote AS, not just the cost of reaching the edge of your AS. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 15:51:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14089; Fri, 19 Sep 1997 15:39:58 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14082; Fri, 19 Sep 1997 15:39:52 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id PAA24272 for ; Fri, 19 Sep 1997 15:39:51 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA26969; Fri, 19 Sep 1997 15:37:27 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14068; Fri, 19 Sep 1997 15:37:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA24150; Fri, 19 Sep 1997 15:37:48 -0700 Received: from home.partan.com (home.partan.com [198.6.255.236]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA22225 for ; Fri, 19 Sep 1997 15:37:43 -0700 Received: (from asp@localhost) by home.partan.com (8.6.12/8.6.12) id SAA21526; Fri, 19 Sep 1997 18:37:26 -0400 From: Andrew Partan Message-Id: <199709192237.SAA21526@home.partan.com> Subject: (IPng 4468) Re: BGP and renumbering.. was Re: /126 or /127 -- neither! To: pst@juniper.net (Paul Traina) Date: Fri, 19 Sep 1997 18:37:26 -0400 (EDT) Cc: dhaskin@baynetworks.com, roque@cisco.com, ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <199709192154.OAA11787@base.juniper.net> from "Paul Traina" at Sep 19, 97 02:54:40 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 881 > This makes a big difference if you have a high speed internal backbone > with two peer connections to a remote AS, one on a fast link, the other > on a slow link. You really want to take into account the cost of reaching > the remote AS, not just the cost of reaching the edge of your AS. So I when I redistribute my connected routes into my IGP, I want to be able to set a metric (possibly per interface). And I don't use next-hop self for routes from this AS. --asp@partan.com (Andrew Partan) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 17:14:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14220; Fri, 19 Sep 1997 17:00:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14213; Fri, 19 Sep 1997 17:00:46 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA14152; Fri, 19 Sep 1997 17:00:43 -0700 Received: from spitz.cisco.com (spitz.cisco.com [171.69.1.212]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA13434 for ; Fri, 19 Sep 1997 17:00:43 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by spitz.cisco.com (8.6.12/8.6.5) with ESMTP id RAA18486; Fri, 19 Sep 1997 17:00:11 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id RAA05441; Fri, 19 Sep 1997 17:00:11 -0700 (PDT) Date: Fri, 19 Sep 1997 17:00:11 -0700 (PDT) Message-Id: <199709200000.RAA05441@pedrom-ultra.cisco.com> From: Pedro Marques To: Paul Traina Cc: Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4469) Re: BGP and renumbering.. was Re: /126 or /127 -- neither! In-Reply-To: <199709192154.OAA11787@base.juniper.net> References: <3.0.32.19970919161831.0068fbe8@pobox> <199709192154.OAA11787@base.juniper.net> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1188 >>>>> "Paul" == Paul Traina writes: >> 3) We loose the ability to include the metric of the >> interconnection link in the BGP best path decision. >> Dimitry> Why is that? [snip] Paul> This makes a big difference if you have a high speed Paul> internal backbone with two peer connections to a remote AS, Paul> one on a fast link, the other on a slow link. You really Paul> want to take into account the cost of reaching the remote Paul> AS, not just the cost of reaching the edge of your AS. Thanks for the explanation. So, i assume that you actually agree that not modifing the nexthop is useful in some situations and that removing bgp's ability to annouce the exterior peer's address as nexthop would be handicapping the protocol. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 17:18:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14236; Fri, 19 Sep 1997 17:03:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14229; Fri, 19 Sep 1997 17:03:42 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA14891; Fri, 19 Sep 1997 17:03:39 -0700 Received: from mailhost2.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id RAA14228 for ; Fri, 19 Sep 1997 17:03:37 -0700 Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by mailhost2.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id RAA12565 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id UAA13287 Posted-Date: Fri, 19 Sep 1997 20:02:59 -0400 (EDT) Received: from dhaskin.baynetworks.com ([192.32.95.178]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id UAA24107; Fri, 19 Sep 1997 20:02:46 -0400 for Message-Id: <3.0.1.32.19970919200111.006b1f60@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Sep 1997 20:01:11 -0400 To: Paul Traina , Dimitry Haskin From: Dimitry Haskin Subject: (IPng 4470) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <199709192154.OAA11787@base.juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1720 At 02:54 PM 9/19/97 -0700, Paul Traina wrote: > > > > >3) We loose the ability to include the metric of the interconnection link > >in the BGP best path decision. > > > Why is that? > >Please note the following terminology, I'm talking ingres/egress based >on routing information flow, not packet forwarding flow: > > remote ---------> ingress -------------> egress > AS router router > router > >If you just use your IGP to determine the cost of reaching a >particular point, any meansurement the egress router would make >would be based on the metric of the path from the ingress router >to the egress router, instead of the metric along the path from >the remote router in the other AS to the egress router. > > > A1 --- OC192 --- B1 --- OC192 --- > >---- B3 > A2 --- 9600b --- B2 --- OC192 --- > > >This makes a big difference if you have a high speed internal backbone >with two peer connections to a remote AS, one on a fast link, the other >on a slow link. You really want to take into account the cost of reaching >the remote AS, not just the cost of reaching the edge of your AS. > You extended IGP to include remote AS routers. I believe that a similar effect can be achieved if the cost of reaching the remote AS is included into the ASE metric when an external route is injected into IGP. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 17:24:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14247; Fri, 19 Sep 1997 17:11:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14240; Fri, 19 Sep 1997 17:11:30 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA16507; Fri, 19 Sep 1997 17:11:27 -0700 Received: from granola.cisco.com (granola.cisco.com [171.69.95.100]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA15915 for ; Fri, 19 Sep 1997 17:11:26 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by granola.cisco.com (8.6.12/8.6.5) with ESMTP id RAA24392; Fri, 19 Sep 1997 17:11:24 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id RAA05447; Fri, 19 Sep 1997 17:11:23 -0700 (PDT) Date: Fri, 19 Sep 1997 17:11:23 -0700 (PDT) Message-Id: <199709200011.RAA05447@pedrom-ultra.cisco.com> From: Pedro Marques To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4471) BGP and renumbering.. was Re: /126 or /127 -- neither! In-Reply-To: <199709191934.MAA00518@lookout.nsd.3com.com> References: <3.0.32.19970919123550.006c3658@pobox> <199709191806.LAA05297@pedrom-ultra.cisco.com> <199709191934.MAA00518@lookout.nsd.3com.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1481 >>>>> "Quaizar" == Quaizar Vohra writes: >> you advertise into your IBGP... >> >> As it is currently defined, IPv6's BGP can take any beating you >> want. Restricting it to carry link locals in ebgp sessions >> would seriously handicap the protocol. >> >> For instance you would completly loose the capability to do >> multihop ebgp. Quaizar> I think if we remove the restriction that the NEXT_HOP Quaizar> will either only carry link-local or global IPv6 address, Quaizar> i.e. allow either, then as per Dimitry's Proposal we can Quaizar> avoid propogating global IX addresses in the most usual Quaizar> case of single hop ebgp. IPv6 BGP carries a non-linklocal scope address as nexthop plus a link local scoped address if the two peers are directly connected. That does not prevent a peer from rewriting the nexthop when annoucing those routes to either ibgp or ebgp peers. I may start to sound like a broken record by now, but the above scheme permits all types of configuration without loosing bgp capabilities... Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 17:58:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14310; Fri, 19 Sep 1997 17:49:35 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14303; Fri, 19 Sep 1997 17:49:26 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA23258; Fri, 19 Sep 1997 17:49:25 -0700 Received: from pita.cisco.com (pita.Cisco.COM [161.44.132.3]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA23658 for ; Fri, 19 Sep 1997 17:49:25 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by pita.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA20071; Fri, 19 Sep 1997 17:49:22 -0700 (PDT) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id RAA05491; Fri, 19 Sep 1997 17:49:22 -0700 (PDT) Date: Fri, 19 Sep 1997 17:49:22 -0700 (PDT) Message-Id: <199709200049.RAA05491@pedrom-ultra.cisco.com> From: Pedro Marques To: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4473) Re: BGP and renumbering.. was /126 or /127 -- neither! In-Reply-To: <3.0.1.32.19970919200111.006b1f60@pobox> References: <199709192154.OAA11787@base.juniper.net> <3.0.1.32.19970919200111.006b1f60@pobox> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2629 >>>>> "Dimitry" == Dimitry Haskin writes: Dimitry> At 02:54 PM 9/19/97 -0700, Paul Traina wrote: >> > >3) We loose the ability to include the metric of the >> interconnection link >in the BGP best path decision. > Why is >> that? >> >> Please note the following terminology, I'm talking >> ingres/egress based on routing information flow, not packet >> forwarding flow: >> >> remote ---------> ingress -------------> egress AS router >> router router >> >> If you just use your IGP to determine the cost of reaching a >> particular point, any meansurement the egress router would make >> would be based on the metric of the path from the ingress >> router to the egress router, instead of the metric along the >> path from the remote router in the other AS to the egress >> router. >> >> >> A1 --- OC192 --- B1 --- OC192 --- >---- B3 A2 --- 9600b --- B2 >> --- OC192 --- >> >> >> This makes a big difference if you have a high speed internal >> backbone with two peer connections to a remote AS, one on a >> fast link, the other on a slow link. You really want to take >> into account the cost of reaching the remote AS, not just the >> cost of reaching the edge of your AS. >> Dimitry> You extended IGP to include remote AS routers. I believe Dimitry> that a similar effect can be achieved if the cost of Dimitry> reaching the remote AS is included into the ASE metric Dimitry> when an external route is injected into IGP. No... First "extending the IGP to include remote AS routers" is evil... the whole concept of AS is exactly where the IGP boundaries are. Also i sincerely doubt any reasonable network operator would accept to participate in someone else's IGP... Second, you don't inject exterior routes into IGP. It doesn't scale. Third, if what you want is to consider the path to the ingress point of the external AS, why do anything else that use today's solution: don't change the nexthop. There is absolutely no problem with what we do today. If you eliminate the ability of annoucing the unmodified nexthop into IBGP you do indeed create a problem. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 18:22:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14384; Fri, 19 Sep 1997 18:02:23 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14377; Fri, 19 Sep 1997 18:02:14 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id SAA21311 for ; Fri, 19 Sep 1997 18:02:14 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA27164; Fri, 19 Sep 1997 17:59:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14290; Fri, 19 Sep 1997 17:48:04 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA22992; Fri, 19 Sep 1997 17:48:02 -0700 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA23394 for ; Fri, 19 Sep 1997 17:48:04 -0700 Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id RAA27322; Fri, 19 Sep 1997 17:47:32 -0700 (PDT) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id RAA12526; Fri, 19 Sep 1997 17:47:29 -0700 (PDT) Message-Id: <199709200047.RAA12526@base.juniper.net> To: Andrew Partan cc: dhaskin@baynetworks.com, roque@cisco.com, ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4477) Re: BGP and renumbering.. was Re: /126 or /127 -- neither! In-reply-to: Your message of "Fri, 19 Sep 1997 18:37:26 EDT." <199709192237.SAA21526@home.partan.com> Date: Fri, 19 Sep 1997 17:47:29 -0700 From: Paul Traina Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 729 From: Andrew Partan Subject: Re: (IPng 4453) BGP and renumbering.. was Re: /126 or /127 -- neithe So I when I redistribute my connected routes into my IGP, I want to be able to set a metric (possibly per interface). And I don't use next-hop self for routes from this AS. --asp@partan.com (Andrew Partan) Exactly. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 18:32:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14397; Fri, 19 Sep 1997 18:03:04 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14390; Fri, 19 Sep 1997 18:02:52 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id SAA21329 for ; Fri, 19 Sep 1997 18:02:52 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA27195; Fri, 19 Sep 1997 18:00:28 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14334; Fri, 19 Sep 1997 17:53:39 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA23843; Fri, 19 Sep 1997 17:53:38 -0700 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA24475 for ; Fri, 19 Sep 1997 17:53:39 -0700 Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id RAA27401; Fri, 19 Sep 1997 17:53:07 -0700 (PDT) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id RAA12652; Fri, 19 Sep 1997 17:53:04 -0700 (PDT) Message-Id: <199709200053.RAA12652@base.juniper.net> To: Dimitry Haskin cc: ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4478) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Fri, 19 Sep 1997 20:01:11 EDT." <3.0.1.32.19970919200111.006b1f60@pobox> Date: Fri, 19 Sep 1997 17:53:04 -0700 From: Paul Traina Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1927 From: Dimitry Haskin Subject: Re: BGP and renumbering.. was /126 or /127 -- neither! At 02:54 PM 9/19/97 -0700, Paul Traina wrote: > > > > >3) We loose the ability to include the metric of the interconnection link > >in the BGP best path decision. > > > Why is that? > >Please note the following terminology, I'm talking ingres/egress based >on routing information flow, not packet forwarding flow: > > remote ---------> ingress -------------> egress > AS router router > router > >If you just use your IGP to determine the cost of reaching a >particular point, any meansurement the egress router would make >would be based on the metric of the path from the ingress router >to the egress router, instead of the metric along the path from >the remote router in the other AS to the egress router. > > > A1 --- OC192 --- B1 --- OC192 --- > >---- B3 > A2 --- 9600b --- B2 --- OC192 --- > > >This makes a big difference if you have a high speed internal backbone >with two peer connections to a remote AS, one on a fast link, the other >on a slow link. You really want to take into account the cost of reaching >the remote AS, not just the cost of reaching the edge of your AS. > You extended IGP to include remote AS routers. I believe that a similar effect can be achieved if the cost of reaching the remote AS is included into the ASE metric when an external route is injected into IGP. Agreed again. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 18:31:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14375; Fri, 19 Sep 1997 18:01:40 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14368; Fri, 19 Sep 1997 18:01:33 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id SAA21252 for ; Fri, 19 Sep 1997 18:01:34 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA27137; Fri, 19 Sep 1997 17:59:10 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14323; Fri, 19 Sep 1997 17:53:15 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA23792; Fri, 19 Sep 1997 17:53:13 -0700 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA24389 for ; Fri, 19 Sep 1997 17:53:14 -0700 Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id RAA27390; Fri, 19 Sep 1997 17:52:41 -0700 (PDT) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id RAA12633; Fri, 19 Sep 1997 17:52:39 -0700 (PDT) Message-Id: <199709200052.RAA12633@base.juniper.net> To: Pedro Marques cc: Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4476) Re: BGP and renumbering.. was Re: /126 or /127 -- neither! In-reply-to: Your message of "Fri, 19 Sep 1997 17:00:11 PDT." <199709200000.RAA05441@pedrom-ultra.cisco.com> Date: Fri, 19 Sep 1997 17:52:39 -0700 From: Paul Traina Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1893 From: Pedro Marques Subject: Re: (IPng 4453) BGP and renumbering.. was Re: /126 or /127 -- neithe >>r! >>>>> "Paul" == Paul Traina writes: >> 3) We loose the ability to include the metric of the >> interconnection link in the BGP best path decision. >> Dimitry> Why is that? [snip] Paul> This makes a big difference if you have a high speed Paul> internal backbone with two peer connections to a remote AS, Paul> one on a fast link, the other on a slow link. You really Paul> want to take into account the cost of reaching the remote Paul> AS, not just the cost of reaching the edge of your AS. Thanks for the explanation. So, i assume that you actually agree that not modifing the nexthop is useful in some situations and that removing bgp's ability to annouce the exterior peer's address as nexthop would be handicapping the protocol. It would handicap the ability for a BGP implementation to influence path selection based upon the IGP metric to a remote router. There are plenty of suitably clever ways to get the same information, so I really don't have a strong stance one way or another. I certainly don't think it ham-strings the protocol, it makes one way of determining this information less obvious, that's all. In BGP3 we always did the the moral equivelant of next-hop-self, and this change was specificly requested in BGP4 by Dennis for this reason, among others. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 18:35:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14435; Fri, 19 Sep 1997 18:06:39 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14428; Fri, 19 Sep 1997 18:06:24 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id SAA21533 for ; Fri, 19 Sep 1997 18:06:23 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA27225; Fri, 19 Sep 1997 18:02:59 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14399; Fri, 19 Sep 1997 18:03:06 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA25161; Fri, 19 Sep 1997 18:03:04 -0700 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA26151 for ; Fri, 19 Sep 1997 18:03:03 -0700 Received: from scooby-doo.cisco.com (herndon-dhcp-120.cisco.com [171.68.53.120]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id SAA18959; Fri, 19 Sep 1997 18:02:25 -0700 (PDT) Message-Id: <3.0.3.32.19970919210204.006bdbc8@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 19 Sep 1997 21:02:04 -0400 To: Pedro Marques From: Paul Ferguson Subject: (IPng 4480) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <199709200049.RAA05491@pedrom-ultra.cisco.com> References: <3.0.1.32.19970919200111.006b1f60@pobox> <199709192154.OAA11787@base.juniper.net> <3.0.1.32.19970919200111.006b1f60@pobox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 548 At 05:49 PM 9/19/97 -0700, Pedro Marques wrote: > >Second, you don't inject exterior routes into IGP. It doesn't scale. > Bingo. Best current practice. ;-) - paul -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 19:30:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA14573; Fri, 19 Sep 1997 19:22:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA14566; Fri, 19 Sep 1997 19:22:15 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA04153; Fri, 19 Sep 1997 19:22:13 -0700 Received: from mailhost2.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id TAA09068 for ; Fri, 19 Sep 1997 19:22:15 -0700 Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by mailhost2.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id TAA14812 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id WAA17835 Posted-Date: Fri, 19 Sep 1997 22:22:10 -0400 (EDT) Received: from dhaskin.baynetworks.com ([192.32.95.169]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id WAA29792; Fri, 19 Sep 1997 22:21:52 -0400 for Message-Id: <3.0.1.32.19970919222008.00763a24@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Sep 1997 22:20:08 -0400 To: Pedro Marques , Dimitry Haskin From: Dimitry Haskin Subject: (IPng 4481) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <199709200049.RAA05491@pedrom-ultra.cisco.com> References: <3.0.1.32.19970919200111.006b1f60@pobox> <199709192154.OAA11787@base.juniper.net> <3.0.1.32.19970919200111.006b1f60@pobox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2767 At 05:49 PM 9/19/97 -0700, Pedro Marques wrote: > >> > >> A1 --- OC192 --- B1 --- OC192 --- >---- B3 A2 --- 9600b --- B2 > >> --- OC192 --- > >> > >> > >> This makes a big difference if you have a high speed internal > >> backbone with two peer connections to a remote AS, one on a > >> fast link, the other on a slow link. You really want to take > >> into account the cost of reaching the remote AS, not just the > >> cost of reaching the edge of your AS. > >> > Dimitry> You extended IGP to include remote AS routers. I believe > Dimitry> that a similar effect can be achieved if the cost of > Dimitry> reaching the remote AS is included into the ASE metric > Dimitry> when an external route is injected into IGP. > >No... > >First "extending the IGP to include remote AS routers" is evil... the whole >concept of AS is exactly where the IGP boundaries are. Also i sincerely >doubt any reasonable network operator would accept to participate in >someone else's IGP... > First, I was not advocating "extending the IGP to include remote AS routers" but merely clarified the Paul's example. Contrarily, this is exactly what you are advocating since using a global address of remote AS as the next hop technically amounts to extending IGP to that AS. >Second, you don't inject exterior routes into IGP. It doesn't scale. > Second, I'm well aware of different ways of distributing external routes within AS and their merits. By far, not all ASs have to deal with 40K routes and hopefully it shell never be the case for v6 domains. In addition, injecting ASE routes into IGP is often the only way to deliver them to BGP-incapable routers. >Third, if what you want is to consider the path to the ingress point of >the external AS, why do anything else that use today's solution: don't >change the nexthop. There is absolutely no problem with what we do >today. If you eliminate the ability of annoucing the unmodified nexthop >into IBGP you do indeed create a problem. > Third, as it has been pointed out, changing the next hop *is* the prevailing today's solution at many ISP domains. Forth, I think that I've clearly stated that I'm not asking to eliminate the ability to advertise unmodified NEXT_HOP into IBGP but merely asking to remove the requirement to include global-scope address in the NEXT_HOP attribute. > Pedro. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 19 19:50:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA14594; Fri, 19 Sep 1997 19:42:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA14587; Fri, 19 Sep 1997 19:41:52 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA05451; Fri, 19 Sep 1997 19:41:51 -0700 Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA11739 for ; Fri, 19 Sep 1997 19:41:52 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with ESMTP id TAA00778; Fri, 19 Sep 1997 19:41:51 -0700 (PDT) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id TAA05528; Fri, 19 Sep 1997 19:41:50 -0700 (PDT) Date: Fri, 19 Sep 1997 19:41:50 -0700 (PDT) Message-Id: <199709200241.TAA05528@pedrom-ultra.cisco.com> From: Pedro Marques To: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4482) Re: BGP and renumbering.. was /126 or /127 -- neither! In-Reply-To: <3.0.1.32.19970919222008.00763a24@pobox> References: <3.0.1.32.19970919200111.006b1f60@pobox> <199709192154.OAA11787@base.juniper.net> <199709200049.RAA05491@pedrom-ultra.cisco.com> <3.0.1.32.19970919222008.00763a24@pobox> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1747 >>>>> "Dimitry" == Dimitry Haskin writes: Dimitry> Forth, I think that I've clearly stated that I'm not Dimitry> asking to eliminate the ability to advertise unmodified Dimitry> NEXT_HOP into IBGP but merely asking to remove the Dimitry> requirement to include global-scope address in the Dimitry> NEXT_HOP attribute. Which isn't, imho, reasonable. A given AS should not need to know the IBGP configuration of the ASes it peers with. If the remote AS choose to ignore the global and replace it with it's own "non-linklocal scoped address valid in it's entire AS" we end up with exactly the same functionality that you ask. If not it has to advertise into the IGP a route to the foreign next-hop. Note that a border router should insert the link local and not the global address on it's forwarding table when directly connected to another AS. Passing just *one* address in a direct ebgp peering makes you loose functionality compared to ipv4 bgp. You do need to pass *two* addresses: a link local that your peer can install in it's forwarding table and a non-link local that the other BGP capable routers of the foreign AS can route to. The non-locally scoped address can be completly ignore if the other AS is configured to do so, but a border router can not refrain from annoucing it. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Sep 20 09:54:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA14872; Sat, 20 Sep 1997 09:46:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA14865; Sat, 20 Sep 1997 09:46:00 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA08333; Sat, 20 Sep 1997 09:45:56 -0700 Received: from mailhost1.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA26801 for ; Sat, 20 Sep 1997 09:45:52 -0700 Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id JAA07797 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id MAA18768 Posted-Date: Sat, 20 Sep 1997 12:45:40 -0400 (EDT) Received: from dhaskin.baynetworks.com (eng_ppp27 [192.32.171.167]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id MAA04747; Sat, 20 Sep 1997 12:45:38 -0400 for Message-Id: <3.0.1.32.19970920124405.00a7378c@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 20 Sep 1997 12:44:05 -0400 To: Pedro Marques , Dimitry Haskin From: Dimitry Haskin Subject: (IPng 4483) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <199709200241.TAA05528@pedrom-ultra.cisco.com> References: <3.0.1.32.19970919222008.00763a24@pobox> <3.0.1.32.19970919200111.006b1f60@pobox> <199709192154.OAA11787@base.juniper.net> <199709200049.RAA05491@pedrom-ultra.cisco.com> <3.0.1.32.19970919222008.00763a24@pobox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2839 At 07:41 PM 9/19/97 -0700, Pedro Marques wrote: > Dimitry> Forth, I think that I've clearly stated that I'm not > Dimitry> asking to eliminate the ability to advertise unmodified > Dimitry> NEXT_HOP into IBGP but merely asking to remove the > Dimitry> requirement to include global-scope address in the > Dimitry> NEXT_HOP attribute. > >Which isn't, imho, reasonable. A given AS should not need to know the >IBGP configuration of the ASes it peers with. If the remote AS choose >to ignore the global and replace it with it's own "non-linklocal scoped >address valid in it's entire AS" we end up with exactly the same >functionality that you ask. If not it has to advertise into the IGP >a route to the foreign next-hop. > >Note that a border router should insert the link local and not the >global address on it's forwarding table when directly connected to >another AS. > >Passing just *one* address in a direct ebgp peering makes you loose >functionality compared to ipv4 bgp. You do need to pass *two* addresses: >a link local that your peer can install in it's forwarding table and >a non-link local that the other BGP capable routers of the foreign AS >can route to. The non-locally scoped address can be completly ignore >if the other AS is configured to do so, but a border router can not >refrain from annoucing it. > A given AS should not be forced to configure global-scope addresses to a border router DMZ interface and supply this address to its external peer if it does not want to. It should be completely a policy decision. BGP still can operate without global next hop addresses as long as the receiving peer implementation can handle it. In fact you are trying to impose some policy and administrative decisions on an AS even if it is not absolutely required for the BGP operation. Well, I may loose some functionality by not supplying a global-scope next hop but it should be my choice weighted against administrative and other gains that I may get instead. BGP peering is a consenting relationship. If my policy is not to supply a global next hop and you policy is to require a global next hop, so we don't peer until we reconcile our differences. But in no way it should be imposed by the protocol unless it is absolutely necessary for protocol operation. You can look at the MED attribute as a precedence, receiving peer may get some extra functionality if it gets it but it is not required to send it. > Pedro. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 22 00:57:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA15809; Mon, 22 Sep 1997 00:48:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA15802; Mon, 22 Sep 1997 00:48:41 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA27690; Mon, 22 Sep 1997 00:48:39 -0700 Received: from akita.cisco.com (akita.cisco.com [171.69.223.72]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA25162 for ; Mon, 22 Sep 1997 00:48:35 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by akita.cisco.com (8.6.12/8.6.5) with ESMTP id AAA27657; Mon, 22 Sep 1997 00:48:02 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id AAA06071; Mon, 22 Sep 1997 00:48:02 -0700 (PDT) Date: Mon, 22 Sep 1997 00:48:02 -0700 (PDT) Message-Id: <199709220748.AAA06071@pedrom-ultra.cisco.com> From: Pedro Marques To: Dennis Ferguson Cc: roque@cisco.com (Pedro Marques), Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4490) Re: BGP and renumbering.. was /126 or /127 -- neither! In-Reply-To: <199709220448.VAA01811@skank.juniper.net> References: <199709200241.TAA05528@pedrom-ultra.cisco.com> <199709220448.VAA01811@skank.juniper.net> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2039 >>>>> "Dennis" == Dennis Ferguson writes: Dennis> I'm having some difficulty figuring out the `need' for two Dennis> next hop addresses (and the near 40 bytes of next hop gorp Dennis> in every single eBGP advertisement) at all. The need for two addresses (a non-linklocal and a linklocal) on peering connections on a directly multi-acess connected link is that IPv6 requires link-local addresses for ICMP redirects and from exporting and importing into IGPs. Puting it in another way, what you should install in a IPv6 routing table as nexthops is: o for recursive routes: non-linklocal addresses. o for non-recursive routes: linklocal addresses. Having the destintion in the protocol between direct and non-direct connections is bad enought. I think we don't want to include in also the distintion between multiple access networks and non-multiple access networks. And yes, i do dislike this solution. But it is the only i got than can support all the corner cases. Dennis> If you are Dennis> advertising the global addresses via IBGP other routers of Dennis> yours attached to the same wire which learn the routes Dennis> third party will need to install the global addresses in Dennis> their forwarding tables as next hops, so the global Dennis> addresses must be usable as next hops. Agreed. [snip] Dennis> Sending Dennis> two next hops all the time only seems to ensure that you Dennis> maximize the trouble of making address changes in all Dennis> cases. The problem is that you need the linklocals when you are using the globals on a directly connected link. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 22 09:51:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16011; Mon, 22 Sep 1997 09:32:25 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16004; Mon, 22 Sep 1997 09:32:14 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA03607 for ; Mon, 22 Sep 1997 09:32:12 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA00891; Mon, 22 Sep 1997 09:29:47 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA15009; Sat, 20 Sep 1997 17:37:21 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA03650; Sat, 20 Sep 1997 17:37:19 -0700 Received: from cesium.clock.org (cesium.clock.org [140.174.97.8]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id RAA27785 for ; Sat, 20 Sep 1997 17:37:15 -0700 Received: from smd@localhost by cesium.clock.org id <77191-151>; Sat, 20 Sep 1997 17:36:52 -0700 To: Pedro Marques Cc: Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4491) Re: BGP and renumbering.. was /126 or /127 -- neither! References: <199709192154.OAA11787@base.juniper.net> <3.0.1.32.19970919200111.006b1f60@pobox> <199709200049.RAA05491@pedrom-ultra.cisco.com> From: "Sean M. Doran" Date: 20 Sep 1997 20:36:42 -0400 In-Reply-To: Pedro Marques's message of "Fri, 19 Sep 1997 17:49:22 -0700 (PDT)" Message-ID: Lines: 34 X-Mailer: Gnus v5.4.65/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1717 Pedro Marques writes: > First "extending the IGP to include remote AS routers" > is evil... the whole concept of AS is exactly where the > IGP boundaries are. Yes and no. You are forgetting confederations. > Also i sincerely doubt any reasonable network operator > would accept to participate in someone else's IGP... I may not be a reasonable network operator, but I would really like to have a sabotage-resistant means of carrying the same next-hop-addresses that another network carries in its IGP. If another network is doing the standard "each router gets a prefix, each such prefix is carried in the IGP" configuration, and metrics were both sufficiently rich and sufficiently useful, then a not-quite-a-confederation approach to carrying the other network's next-hops in my IGP and not requiring the translation of the other network's IBGP next-hops into the eBGP next-hop for some set of prefixes would be a nice way to help kill off the poor closest-exit vs MEDs choice for external path selection. One way to look at this would be something along the lines of having an IS-IS level 3, where the L3 ISes are those at the borders between two networks, with a confederation of ASes layered on top. L3 addresses, in effect, are the routing names describing the L2 ISes in two separate L2 areas. Sean. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 22 10:01:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16027; Mon, 22 Sep 1997 09:36:42 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16020; Mon, 22 Sep 1997 09:36:36 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA04123 for ; Mon, 22 Sep 1997 09:36:34 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA00918; Mon, 22 Sep 1997 09:34:09 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA15023; Sat, 20 Sep 1997 17:48:49 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA04666; Sat, 20 Sep 1997 17:48:47 -0700 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA29300 for ; Sat, 20 Sep 1997 17:48:42 -0700 Received: from scooby-doo.cisco.com (herndon-dhcp-120.cisco.com [171.68.53.120]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id RAA27431; Sat, 20 Sep 1997 17:43:05 -0700 (PDT) Message-Id: <3.0.3.32.19970920204248.006ae4c8@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 20 Sep 1997 20:42:48 -0400 To: "Sean M. Doran" From: Paul Ferguson Subject: (IPng 4492) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: References: <199709192154.OAA11787@base.juniper.net> <3.0.1.32.19970919200111.006b1f60@pobox> <199709200049.RAA05491@pedrom-ultra.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 780 At 08:36 PM 9/20/97 -0400, Sean M. Doran wrote: > >Yes and no. You are forgetting confederations. > But Sean, wouldn't you agree that confederations are of the implementation genre that is waning? By asking this, I in no way mean to imply that we should ignore it's existence, but rather, I do notice that the instance of confederations is one which is a path much less taken these days. - paul -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 22 10:04:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16039; Mon, 22 Sep 1997 09:37:59 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16032; Mon, 22 Sep 1997 09:37:52 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA04296 for ; Mon, 22 Sep 1997 09:37:50 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA00945; Mon, 22 Sep 1997 09:35:24 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA15034; Sat, 20 Sep 1997 18:01:29 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA05694; Sat, 20 Sep 1997 18:01:27 -0700 Received: from cesium.clock.org (cesium.clock.org [140.174.97.8]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id SAA00870 for ; Sat, 20 Sep 1997 18:01:23 -0700 Received: from smd@localhost by cesium.clock.org id <77191-150>; Sat, 20 Sep 1997 18:01:13 -0700 To: Henk Smit Cc: pst@juniper.net (Paul Traina), vaf@valinor.barrnet.net, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4493) Re: BGP and renumbering.. was Re: /126 or /127 -- neither! References: <199709191940.VAA09159@kraak.cisco.com> From: "Sean M. Doran" Date: 20 Sep 1997 21:01:05 -0400 In-Reply-To: Henk Smit's message of "Fri, 19 Sep 1997 21:40:31 +0200 (MET DST)" Message-ID: Lines: 33 X-Mailer: Gnus v5.4.65/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1661 Henk Smit writes: > I was told that because of the growth of private > peerings between the large ISPs, there is more need for > this kind of fine-tuning. The growth in the number of borders between any two ASes exposes the poverty of BGP in many ways; this is simply one of them. > So it might be that carrying original eBGP next-hop info inside > the iBGP-mesh will be more important in the near future. Maybe > one of the large ISPs can comment on this ? Right now you get this big blob of reachable things being advertised in eBGP, assuming MEDs aren't being exchanged. (If you are exchanging MEDs, you get a number from which you may be able to infer a map, since MEDs theoretically tell you some sort of closeness of a reachable thing to each BR). The obvious evolutionary path is towards seeing some level of connectivity information in one's peer so that one can send traffic towards the best IX. Propagating IX addresses really makes sense only when two connections are available between one BR and the next AS, and one of the two is a less desirable path than that available via another BR. This might happen when, for example, two peers are colocated around some sort of public infrastructure and also have a private connection. Sean. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 22 10:08:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16057; Mon, 22 Sep 1997 09:41:36 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16050; Mon, 22 Sep 1997 09:41:28 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA04675 for ; Mon, 22 Sep 1997 09:41:25 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01000; Mon, 22 Sep 1997 09:38:59 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA15732; Sun, 21 Sep 1997 21:44:21 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA15403; Sun, 21 Sep 1997 21:44:20 -0700 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA19468 for ; Sun, 21 Sep 1997 21:44:14 -0700 Received: from skank.juniper.net (skank.juniper.net [208.197.169.216]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id VAA28738; Sun, 21 Sep 1997 21:43:41 -0700 (PDT) Received: from skank.juniper.net (localhost.juniper.net [127.0.0.1]) by skank.juniper.net (8.8.4/8.7.3) with ESMTP id VAA01811; Sun, 21 Sep 1997 21:48:03 -0700 (PDT) Message-Id: <199709220448.VAA01811@skank.juniper.net> X-Mailer: exmh version 1.6.9 8/22/96 To: roque@cisco.com (Pedro Marques) cc: Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4495) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "20 Sep 1997 02:41:50 GMT." <199709200241.TAA05528@pedrom-ultra.cisco.com> Mime-Version: 1.0 Content-Type: text/plain Date: Sun, 21 Sep 1997 21:48:03 -0700 From: Dennis Ferguson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2841 > Passing just *one* address in a direct ebgp peering makes you loose > functionality compared to ipv4 bgp. You do need to pass *two* addresses: > a link local that your peer can install in it's forwarding table and > a non-link local that the other BGP capable routers of the foreign AS > can route to. The non-locally scoped address can be completly ignore > if the other AS is configured to do so, but a border router can not > refrain from annoucing it. I'm having some difficulty figuring out the `need' for two next hop addresses (and the near 40 bytes of next hop gorp in every single eBGP advertisement) at all. If you are advertising the global addresses via IBGP other routers of yours attached to the same wire which learn the routes third party will need to install the global addresses in their forwarding tables as next hops, so the global addresses must be usable as next hops. Furthermore, if the addresses on the wire are changed (and limiting the damage caused by address changes is the only reason I'm aware of for avoiding global addresses as next hops) then it is already required that (a) the peer readvertise every route he sent to you, listing the new global next hops, (b) if you've been readvertising the next hops via IBGP, that you reflood each and every one of these announcements to your internal peers after the appropriate adjustments to your IGP advertisement, and (c) if there are other routers on the same wire that were learning the routes third party via IBGP, that they readjust the next hops in their forwarding table. The additional effort of fixing your own forwarding table as well hardly seems to add much more pain to an already painful process, and might even be made up for somewhat by the opportunity of avoiding the pain of having to parse not one but two big ugly next hops out of every eBGP advertisement you receive forever more. It seems to me you can do everything you need with a single next hop. If you need to readvertise the third-party next hops into IBGP get him to send you global-scope next hops and you'll unavoidably have some work to do if his addresses change (almost all of which you would have had to do in any case), otherwise get him to send you link-local next hops and you and he won't have to do anything at all if the addresses change. Sending two next hops all the time only seems to ensure that you maximize the trouble of making address changes in all cases. Dennis Ferguson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 22 10:07:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16048; Mon, 22 Sep 1997 09:40:31 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA16041; Mon, 22 Sep 1997 09:40:20 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA04589 for ; Mon, 22 Sep 1997 09:40:16 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA00973; Mon, 22 Sep 1997 09:37:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA15049; Sat, 20 Sep 1997 18:34:26 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA08034; Sat, 20 Sep 1997 18:34:23 -0700 Received: from cesium.clock.org (cesium.clock.org [140.174.97.8]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id SAA04712 for ; Sat, 20 Sep 1997 18:34:20 -0700 Received: from smd@localhost by cesium.clock.org id <77191-151>; Sat, 20 Sep 1997 18:34:10 -0700 To: Paul Ferguson Cc: "Sean M. Doran" , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4494) Re: BGP and renumbering.. was /126 or /127 -- neither! References: <199709192154.OAA11787@base.juniper.net> <3.0.1.32.19970919200111.006b1f60@pobox> <199709200049.RAA05491@pedrom-ultra.cisco.com> <3.0.3.32.19970920204248.006ae4c8@lint.cisco.com> From: "Sean M. Doran" Date: 20 Sep 1997 21:33:58 -0400 In-Reply-To: Paul Ferguson's message of "Sat, 20 Sep 1997 20:42:48 -0400" Message-ID: Lines: 71 X-Mailer: Gnus v5.4.65/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2999 Paul Ferguson writes: > But Sean, wouldn't you agree that confederations are of > the implementation genre that is waning? By asking this, > I in no way mean to imply that we should ignore it's > existence, but rather, I do notice that the instance > of confederations is one which is a path much less taken > these days. Sure, but what's your point? One of the advantages never really used much wrt confederations was that it provided some additional information upon which one could make some sort of route selection. There were three reasons why I think this never got used: -- people are and were still used to AS path length as a primary metric for path selection -- people had objections to the extra information being visible (aesthetic or privacy minded objections principally) -- without a connectivity map to explain the relation of the confederated ASes to one another and to the BRs, there is no way to take advantage of the extra information, and hand-drawn ASCII maps designed to assist in manual configuration didn't seem to help much Moreover, as a consequence of the middle point, pst coded up AS-excising code which eliminated the extra information from the AS path, and this was deployed in most places (I had to fight with him to have a way to turn this AS-excising code off). In parallel, an easier-to-configure but vastly more complicated (and initially, very buggy) approach was deployed elsewhere. Since the route reflector code became stable, and the confederation scheme no longer made confederated ASes visible to the outside world, the principal diffentiator became ease of configuration and maintenance, and the reflector code wins there. I am not sure that the use of confederations is waning. Since there is no way of determining whether someone is using AS-excising confederation code except by giving them a release of IOS that breaks it, or by asking them more politely than that, the only evidence of "waning" is simply that SprintLink recently has cut over to the route reflector scheme, probably for the reasons outlined in the previous paragraph. However, returning to the reason I brought up confederations in the first place, remember that the original idea was simply not to rewrite the next-hops and MEDs when talking to an eBGP peer. This can be useful in cases where the non-rewritten next-hops can be resolved through an IGP. This would be useful in particular cases now, in fact, if one could share an IGP among two or more ASes under different administrative control. Sean. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 22 10:36:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16091; Mon, 22 Sep 1997 10:12:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16084; Mon, 22 Sep 1997 10:11:29 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA23051; Mon, 22 Sep 1997 10:11:26 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA05071 for ; Mon, 22 Sep 1997 10:11:03 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id KAA24237; Mon, 22 Sep 1997 10:10:59 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id JAA06438; Mon, 22 Sep 1997 09:58:14 -0700 (PDT) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id KAA05210; Mon, 22 Sep 1997 10:09:02 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id KAA01339; Mon, 22 Sep 1997 10:10:59 -0700 (PDT) Date: Mon, 22 Sep 1997 10:10:59 -0700 (PDT) Message-Id: <199709221710.KAA01339@lookout.nsd.3com.com> To: Pedro Marques Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4496) Re: BGP and renumbering.. was /126 or /127 -- neither! In-Reply-To: <199709220748.AAA06071@pedrom-ultra.cisco.com> References: <199709200241.TAA05528@pedrom-ultra.cisco.com> <199709220448.VAA01811@skank.juniper.net> <199709220748.AAA06071@pedrom-ultra.cisco.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 867 So Far the only use of Global addresses in the NEXT_HOP attribute in an ebgp update I have understood from all this discussion is to be able to readvertise it to the ibgp peer so that they could account for the cost of the IX link between the ASs thru the IGP metric for the route to that global nexthop. Is that right ? Can't you account for the cost of IX link in the local pref before readvertising the route into ibgp ? Please soneone clear up my ignorance ? Thanks, Quaizar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 22 10:50:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16141; Mon, 22 Sep 1997 10:29:53 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16134; Mon, 22 Sep 1997 10:29:45 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id KAA11658 for ; Mon, 22 Sep 1997 10:29:42 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA01155; Mon, 22 Sep 1997 10:27:16 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16111; Mon, 22 Sep 1997 10:25:05 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA27135; Mon, 22 Sep 1997 10:24:59 -0700 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA10353 for ; Mon, 22 Sep 1997 10:24:50 -0700 Received: from gen2.uu.net by relay5.UU.NET with ESMTP (peer crosschecked as: gen2.uu.net [153.39.50.136]) id QQdicz27983; Mon, 22 Sep 1997 13:24:53 -0400 (EDT) Received: from aotearoa.uu.net by gen2.uu.net with ESMTP (peer crosschecked as: aotearoa.UU.NET [153.39.253.124]) id QQdicz00228; Mon, 22 Sep 1997 13:24:35 -0400 (EDT) Received: from localhost by aotearoa.uu.net with SMTP (peer crosschecked as: sherk@localhost) id QQdicz08326; Mon, 22 Sep 1997 13:24:34 -0400 (EDT) Message-Id: To: "Sean M. Doran" cc: Paul Ferguson , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4498) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "20 Sep 1997 21:33:58 EDT." Date: Mon, 22 Sep 1997 13:24:34 -0400 From: Erik Sherk Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3531 > Paul Ferguson writes: > > > But Sean, wouldn't you agree that confederations are of > > the implementation genre that is waning? By asking this, > > I in no way mean to imply that we should ignore it's > > existence, but rather, I do notice that the instance > > of confederations is one which is a path much less taken > > these days. > > Sure, but what's your point? > > One of the advantages never really used much wrt > confederations was that it provided some additional > information upon which one could make some sort of route > selection. > > There were three reasons why I think this never got used: > > -- people are and were still used to AS path length > as a primary metric for path selection > > -- people had objections to the extra information > being visible (aesthetic or privacy minded > objections principally) > > -- without a connectivity map to explain the > relation of the confederated ASes to one > another and to the BRs, there is no way > to take advantage of the extra information, > and hand-drawn ASCII maps designed to assist > in manual configuration didn't seem to help much > > Moreover, as a consequence of the middle point, pst coded > up AS-excising code which eliminated the extra information > from the AS path, and this was deployed in most places (I > had to fight with him to have a way to turn this > AS-excising code off). > > In parallel, an easier-to-configure but vastly more > complicated (and initially, very buggy) approach was > deployed elsewhere. > > Since the route reflector code became stable, and the > confederation scheme no longer made confederated ASes > visible to the outside world, the principal diffentiator > became ease of configuration and maintenance, and the > reflector code wins there. > > I am not sure that the use of confederations is waning. > Since there is no way of determining whether someone is > using AS-excising confederation code except by giving them > a release of IOS that breaks it, or by asking them more > politely than that, the only evidence of "waning" is > simply that SprintLink recently has cut over to the route > reflector scheme, probably for the reasons outlined in the > previous paragraph. Right. UUNET still uses Confederations in AS701. Due to pressure from one of our vendors, we looked hard at moving to route reflection. We decided not to transition because confederations gave us much more topological flexibility. Route reflection imposes a fairly strict hierarchy on you. There have been some recent changes to the implementation that relax this a little, however. Erik > However, returning to the reason I brought up > confederations in the first place, remember that the > original idea was simply not to rewrite the next-hops and > MEDs when talking to an eBGP peer. This can be useful in > cases where the non-rewritten next-hops can be resolved > through an IGP. > > This would be useful in particular cases now, in fact, if > one could share an IGP among two or more ASes under > different administrative control. > > Sean. > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 22 10:53:59 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16177; Mon, 22 Sep 1997 10:34:49 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16170; Mon, 22 Sep 1997 10:34:41 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id KAA12449 for ; Mon, 22 Sep 1997 10:34:38 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA01187; Mon, 22 Sep 1997 10:32:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16143; Mon, 22 Sep 1997 10:30:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA28974; Mon, 22 Sep 1997 10:30:20 -0700 Received: from syzygy.ieng.com (syzygy.ieng.com [207.24.215.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA12363 for ; Mon, 22 Sep 1997 10:30:03 -0700 Received: (from jgs@localhost) by syzygy.ieng.com (8.8.5/8.7.3) id NAA26649; Mon, 22 Sep 1997 13:29:56 -0400 (EDT) From: "John G. Scudder" Message-Id: <199709221729.NAA26649@syzygy.ieng.com> Subject: (IPng 4500) Re: BGP and renumbering.. was /126 or /127 -- neither! To: qv@3com.com (Quaizar Vohra) Date: Mon, 22 Sep 1997 13:29:55 -0400 (EDT) Cc: roque@cisco.com, ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <199709221710.KAA01339@lookout.nsd.3com.com> from "Quaizar Vohra" at Sep 22, 97 10:10:59 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1258 Quaizar Vohra writes: ... > Can't you account for the cost of IX link in the local pref before > readvertising the route into ibgp ? ... Not if you want to be able to share load between the high-cost and low-cost links. If you use localpref to express your link preference, all traffic will be sucked to the better-cost link. If you use IGP cost, traffic will *tend* to be sucked to the better-cost link, but traffic which is topologically much further from the better-cost link than it is from the worse-cost link will go to the worse-cost one. Localpref is a much heavier hammer than IGP metric. Regards, --John -- John G. Scudder email: jgs@ieng.com Internet Engineering Group, LLC phone: (313) 213-4939 ext 14 122 S. Main, Suite 280 fax: (313) 669-8661 Ann Arbor, MI 48104 www: http://www.ieng.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 22 15:33:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA16643; Mon, 22 Sep 1997 15:20:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA16636; Mon, 22 Sep 1997 15:20:44 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA24251; Mon, 22 Sep 1997 15:20:41 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA25645 for ; Mon, 22 Sep 1997 15:20:40 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id RAA10461; Mon, 22 Sep 1997 17:20:39 -0500 Message-Id: <199709222220.RAA10461@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com, idr@merit.edu From: "Matt Crawford" Subject: (IPng 4501) Re: BGP and renumbering.. was /126 or /127 -- neither! Date: Mon, 22 Sep 1997 17:20:38 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1386 The situation so far: The Bates/Chandra/Katz/Rekhter BGP4+ draft of 7/97 dictates that an IPv6 BGP speaker puts both a global and a link-local address in the Next Hop field if & only if the peer, call it "P", shares a subnet with the entity so identified. I've suggested that point-to-point links not be assigned a subnet prefix, but that the endpoints be assigned their global addresses (if any, I suppose) independently by their respective operators. Some network operators would have that peer P rewrite the next-hop to point to itself. Others would rather keep the Next Hop unchanged, but there are concerns about what might have to be dragged into the IGP. Suppose that BGP on the IPv6 router P gives you the option of injecting the advertised global next-hop address as a host route as well as the option of rewriting it. Does that cover all the bases? Can IBGP carry this usefully (I suspect not, but I'm quite an inexpert BGP user), or does it need to go into the IGP of P's system? Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 22 16:21:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA16815; Mon, 22 Sep 1997 16:05:27 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA16808; Mon, 22 Sep 1997 16:05:17 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA08440; Mon, 22 Sep 1997 16:05:09 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA10380 for ; Mon, 22 Sep 1997 16:04:52 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id QAA12706; Mon, 22 Sep 1997 16:04:50 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id PAA26152; Mon, 22 Sep 1997 15:52:05 -0700 (PDT) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id QAA17627; Mon, 22 Sep 1997 16:02:54 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id QAA01453; Mon, 22 Sep 1997 16:04:51 -0700 (PDT) Date: Mon, 22 Sep 1997 16:04:51 -0700 (PDT) Message-Id: <199709222304.QAA01453@lookout.nsd.3com.com> To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4502) Re: BGP and renumbering.. was /126 or /127 -- neither! In-Reply-To: <199709221710.KAA01339@lookout.nsd.3com.com> References: <199709200241.TAA05528@pedrom-ultra.cisco.com> <199709220448.VAA01811@skank.juniper.net> <199709220748.AAA06071@pedrom-ultra.cisco.com> <199709221710.KAA01339@lookout.nsd.3com.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1029 > > So Far the only use of Global addresses in the NEXT_HOP attribute in > an ebgp update I have understood from all this discussion is to > be able to readvertise it to the ibgp peer so that they could > account for the cost of the IX link between the ASs thru the IGP > metric for the route to that global nexthop. Is that right ? > If this is right then why not introduce another attribute which carries the link cost of the IX link/path. For IPv6 this will atleast remove the need for administering assignment of global IPv6 subnet prefix to the DMZ links, or global IPv6 addresses to the ebgp peers on their IX interfaces. Quaizar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 22 16:25:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA16832; Mon, 22 Sep 1997 16:10:49 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA16825; Mon, 22 Sep 1997 16:10:25 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA10649; Mon, 22 Sep 1997 16:10:22 -0700 Received: from mailhost1.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA12124 for ; Mon, 22 Sep 1997 16:10:17 -0700 Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id QAA26196 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id TAA01113 Posted-Date: Mon, 22 Sep 1997 19:09:35 -0400 (EDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id TAA26456; Mon, 22 Sep 1997 19:09:35 -0400 for Message-Id: <3.0.32.19970922190604.006fcd44@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 22 Sep 1997 19:06:05 -0400 To: "Matt Crawford" From: Dimitry Haskin Subject: (IPng 4503) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1976 At 05:20 PM 9/22/97 -0500, Matt Crawford wrote: >The situation so far: > >The Bates/Chandra/Katz/Rekhter BGP4+ draft of 7/97 dictates that an >IPv6 BGP speaker puts both a global and a link-local address in the >Next Hop field if & only if the peer, call it "P", shares a subnet >with the entity so identified. > >I've suggested that point-to-point links not be assigned a subnet >prefix, but that the endpoints be assigned their global addresses (if >any, I suppose) independently by their respective operators. > >Some network operators would have that peer P rewrite the next-hop to >point to itself. Others would rather keep the Next Hop unchanged, >but there are concerns about what might have to be dragged into the >IGP. > >Suppose that BGP on the IPv6 router P gives you the option of >injecting the advertised global next-hop address as a host route as >well as the option of rewriting it. Does that cover all the bases? Major BGP implementations give you option of rewriting the advertised global next-hop when re-advertising routes to internal peers (even if it is not endorsed by the BGP RFC, as far as I remember). But the point is that it should be allowed for the advertising external peer not to advertise the global next-hop at all since it may not one assigned to its endpoint. A link-local next-hop should be sufficient if receiving peer rewrite the next-hop to point to itself (preferably with a site-local address). >Can IBGP carry this usefully (I suspect not, but I'm quite an >inexpert BGP user), or does it need to go into the IGP of P's system? > > Matt > Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 22 19:40:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA17097; Mon, 22 Sep 1997 19:30:28 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA17090; Mon, 22 Sep 1997 19:30:19 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA23373; Mon, 22 Sep 1997 19:30:19 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA03077 for ; Mon, 22 Sep 1997 19:30:19 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id WAA14765 for ; Mon, 22 Sep 1997 22:23:27 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA31683; Mon, 22 Sep 1997 22:23:26 -0400 Message-Id: <9709230223.AA31683@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4504) Update to RFC 2133 Date: Mon, 22 Sep 1997 22:23:26 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1493 Folks, At this point we need to move forward. Consenus is RES_USE_INET6 option is not the right answer. We also have consensus that we need the DNS APIs to be thread safe, and we want to define them here on theee IPng list and not be handed them via a BIND fix to RES_USE_INET6. I also think we have consensus that we don't want write wrappers to make RES_USE_INET6 or gethostbyname2() work. ALso I feel XNET will work with us to absorb the Thread Safety of the APIs on that tract too. I think the following from Erik will work: +struct dynhostent *gethostbynameafopt(char *name, int af, int options); +void freedynhostent(struct dynhostent *); +These interfaces are MT safe without introducing the notion of +a context to the programmer. What we need to define now is what is in the "int options" as a parameter for gethosbynameafopt(). ALso getaddrinfo() can still be used by calling gethostbynameafopt() and freedynhostent() so it is using a MT safe funtion which gethostbyname2 is not. But we are also saying that gethostbyname() will only return IPv4 addresses forever? Comments?? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 07:22:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA17509; Tue, 23 Sep 1997 07:12:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA17502; Tue, 23 Sep 1997 07:11:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA02929; Tue, 23 Sep 1997 07:11:49 -0700 Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA00898 for ; Tue, 23 Sep 1997 07:11:46 -0700 Received: from mailhost.BayNetworks.COM ([132.245.135.115] (may be forged)) by mailhost3.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id KAA12737 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id KAA06877 Posted-Date: Tue, 23 Sep 1997 10:11:35 -0400 (EDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id KAA06881; Tue, 23 Sep 1997 10:11:25 -0400 for Message-Id: <3.0.32.19970923100756.006921e8@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 23 Sep 1997 10:08:05 -0400 To: Quaizar Vohra From: Dimitry Haskin Subject: (IPng 4505) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1484 At 04:04 PM 9/22/97 -0700, Quaizar Vohra wrote: > > > > So Far the only use of Global addresses in the NEXT_HOP attribute in > > an ebgp update I have understood from all this discussion is to > > be able to readvertise it to the ibgp peer so that they could > > account for the cost of the IX link between the ASs thru the IGP > > metric for the route to that global nexthop. Is that right ? > > > >If this is right then why not introduce another attribute which >carries the link cost of the IX link/path. > This might be a sound idea assuming it is generated by border routers when routes are re-advertised to internal peers. For this to work, the route selection rules must provide for consistent use of this new metric by all IBGP peers, e.g. require to sum it with the internal IGP cost to the address provided in the NEXT_HOP attribute. If it is not done, forwarding loops may form. >For IPv6 this will atleast remove the need for administering >assignment of global IPv6 subnet prefix to the DMZ links, or global IPv6 >addresses to the ebgp peers on their IX interfaces. > >Quaizar Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 08:12:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17645; Tue, 23 Sep 1997 08:02:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17638; Tue, 23 Sep 1997 08:02:44 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA17954; Tue, 23 Sep 1997 08:02:42 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA20362 for ; Tue, 23 Sep 1997 08:02:39 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id LAA03643; Tue, 23 Sep 1997 11:02:29 -0400 (EDT) Message-Id: <199709231502.LAA03643@brookfield.ans.net> To: Dimitry Haskin cc: Pedro Marques , ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4506) Re: BGP and renumbering.. was Re: /126 or /127 -- neither! In-reply-to: Your message of "Fri, 19 Sep 1997 16:18:31 EDT." <3.0.32.19970919161831.0068fbe8@pobox> Date: Tue, 23 Sep 1997 11:02:28 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1117 In message <3.0.32.19970919161831.0068fbe8@pobox>, Dimitry Haskin writes: > > > >3) We loose the ability to include the metric of the interconnection link > >in the BGP best path decision. > > > Why is that? Peer A is off the FDDI, peer B is a T1 hop away. The BGP route to A needs to have a low metric and the route to B needs a high one. One mtric to the box doesn't do the job. I personally think that if you want to propogate a NEXT-HOP beyond an AS boundary (for example: take the next-hop from across your IBGP and paas that to EBGP and have that passed across an IBGP) for the purpose of level 2 shorcuts, you need to do this with an attribute rather than use the NEXT-HOP field. Keep the NEXT-HOP local to the IGP. Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 08:17:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17658; Tue, 23 Sep 1997 08:06:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17651; Tue, 23 Sep 1997 08:06:14 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA18915; Tue, 23 Sep 1997 08:06:11 -0700 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA21765 for ; Tue, 23 Sep 1997 08:06:06 -0700 Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Tue Sep 23 11:04:48 EDT 1997 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by research; Tue Sep 23 11:04:24 EDT 1997 Received: from dnrc.bell-labs.com ([135.74.16.83]) by zubin.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id LAA11444; Tue, 23 Sep 1997 11:04:15 -0400 (EDT) Message-ID: <3427DB39.D30E8969@dnrc.bell-labs.com> Date: Tue, 23 Sep 1997 11:07:37 -0400 From: Grenville Armitage Reply-To: gja@dnrc.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Kazu@mew.org, kjc@csl.sony.co.jp, shin@nd.net.fujitsu.co.jp, hiroshi@isl.rdc.toshiba.co.jp, atarashi@ebina.hitachi.co.jp, ahagiwar@baynetworks.co.jp CC: ion@nexen.com, ipng@sunroof.eng.sun.com Subject: (IPng 4507) Regarding draft-yamamoto-ipv6-over-p2p-atm-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1725 Hi guys, I noticed with interest your recent I-D titled: "IPv6 over Point-to-Point ATM Link" (draft-yamamoto-ipv6-over-p2p-atm-00.txt) A couple of things you might want to consider: - The ION WG has been working on this topic for awhile. I couldn't find reference to draft-ietf-ion-tn-01.txt in your I-D, so perhaps you are not aware of it? - draft-ietf-ion-tn-01.txt is currently being updated to cover the simple cases of NBMA networks used as p2p links (this came out of the Munich IETF as a desire from the IPng and ION groups). I expect you'll see it released in the next 2 weeks. - Your section 6 "Interface Identifier" could be replaced by a pointer to section 5 of draft-ietf-ion-tn-00.txt For URL-aware email readers, the ION ipv6 doc is: http://ds.internic.net/internet-drafts/draft-ietf-ion-tn-01.txt (My apologies for the imprecise title in this I-D, perhaps it is unecessarily confusing people as to its applicability. We are working to clear things up in the impending release. Also, thanks for reminding us that this topic is important and needs to be expedited.) cheers, gja ________________________________________________________________________ Grenville Armitage High Speed Networks Research http://nj5.injersey.com/~gja Bell Labs, Lucent Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 08:34:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17680; Tue, 23 Sep 1997 08:20:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17673; Tue, 23 Sep 1997 08:19:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA22716; Tue, 23 Sep 1997 08:19:48 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA26842 for ; Tue, 23 Sep 1997 08:19:45 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id LAA03702; Tue, 23 Sep 1997 11:19:31 -0400 (EDT) Message-Id: <199709231519.LAA03702@brookfield.ans.net> To: Dimitry Haskin cc: Paul Traina , ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4508) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Fri, 19 Sep 1997 20:01:11 EDT." <3.0.1.32.19970919200111.006b1f60@pobox> Date: Tue, 23 Sep 1997 11:19:31 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1633 In message <3.0.1.32.19970919200111.006b1f60@pobox>, Dimitry Haskin writes: > > > > A1 --- OC192 --- B1 --- OC192 --- > > >---- B3 > > A2 --- 9600b --- B2 --- OC192 --- > > > > > >This makes a big difference if you have a high speed internal backbone > >with two peer connections to a remote AS, one on a fast link, the other > >on a slow link. You really want to take into account the cost of reaching > >the remote AS, not just the cost of reaching the edge of your AS. > > > You extended IGP to include remote AS routers. I believe that a similar > effect can be achieved if the cost of reaching the remote AS is included > into the ASE metric when an external route is injected into IGP. > > Dimitry The remote AS routers are on direct interfaces of your own router and normally direct interfaces are included in the IGP. The only case where this gets a bit sticky is PTP links in BSD/gated style where the two ends of the PTP link are not restricted to the same subnet. This is still OK if the IGP includes both ends of the PTP link to be in the IGP. It only a problem for unnumbered PTP links (which don't see much use in this sort of application since other things like SNMP monitoring get unhappy with no address). Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 08:41:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17696; Tue, 23 Sep 1997 08:25:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17683; Tue, 23 Sep 1997 08:25:14 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA23982; Tue, 23 Sep 1997 08:25:11 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA28982 for ; Tue, 23 Sep 1997 08:25:08 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id LAA03737; Tue, 23 Sep 1997 11:25:00 -0400 (EDT) Message-Id: <199709231525.LAA03737@brookfield.ans.net> To: Pedro Marques cc: Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4509) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Fri, 19 Sep 1997 17:49:22 PDT." <199709200049.RAA05491@pedrom-ultra.cisco.com> Date: Tue, 23 Sep 1997 11:25:00 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1736 In message <199709200049.RAA05491@pedrom-ultra.cisco.com>, Pedro Marques writes : > >> > Dimitry> You extended IGP to include remote AS routers. I believe > Dimitry> that a similar effect can be achieved if the cost of > Dimitry> reaching the remote AS is included into the ASE metric > Dimitry> when an external route is injected into IGP. > > No... > > First "extending the IGP to include remote AS routers" is evil... the whole > concept of AS is exactly where the IGP boundaries are. Also i sincerely > doubt any reasonable network operator would accept to participate in > someone else's IGP... It is standard practice. I don't know of any provider who does not include the AS boundary interface in the IGP. > Second, you don't inject exterior routes into IGP. It doesn't scale. Just the subnet that your own interface is sitting on which includes the address of the peer router, not all routes announced by a peer. > Third, if what you want is to consider the path to the ingress point of > the external AS, why do anything else that use today's solution: don't > change the nexthop. There is absolutely no problem with what we do > today. If you eliminate the ability of annoucing the unmodified nexthop > into IBGP you do indeed create a problem. Unless I'm mistaken, you and Dimitry are in violent agreement. Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 08:52:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17715; Tue, 23 Sep 1997 08:38:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17708; Tue, 23 Sep 1997 08:38:21 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA27365; Tue, 23 Sep 1997 08:38:19 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA04167 for ; Tue, 23 Sep 1997 08:38:13 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id LAA03778; Tue, 23 Sep 1997 11:38:03 -0400 (EDT) Message-Id: <199709231538.LAA03778@brookfield.ans.net> To: Paul Ferguson cc: Pedro Marques , Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4510) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Fri, 19 Sep 1997 21:02:04 EDT." <3.0.3.32.19970919210204.006bdbc8@lint.cisco.com> Date: Tue, 23 Sep 1997 11:38:02 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1354 In message <3.0.3.32.19970919210204.006bdbc8@lint.cisco.com>, Paul Ferguson wri tes: > At 05:49 PM 9/19/97 -0700, Pedro Marques wrote: > > > > >Second, you don't inject exterior routes into IGP. It doesn't scale. > > > > Bingo. Best current practice. ;-) > > - paul It currently doesn't scale but I think this is a matter of IGP routing implementation quality. Flooding ASEs can be more efficient than full mesh BGP or the approximations of flooding like route reflectors. There is still an AS path truncation problem but that can be solved by the long since expired LSA type-8 idea of Dennis Fergusson which would today be done with an opaque LSA if anyone did it. It would also help to have better throttling on the flooding than is currently available in OSPF (or ISIS) though OSPF LSA flooding doing sliding window and slow start and congestion avoidance along with RTO, cwnd, ssthresh, and all that might still be overkill. (OSPF LSA SACK options? :) Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 09:54:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17907; Tue, 23 Sep 1997 09:38:22 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17900; Tue, 23 Sep 1997 09:38:11 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA14558; Tue, 23 Sep 1997 09:38:07 -0700 Received: from mailhost1.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA26989 for ; Tue, 23 Sep 1997 09:38:03 -0700 Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id JAA19885 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id MAA13952 Posted-Date: Tue, 23 Sep 1997 12:36:00 -0400 (EDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id MAA28267; Tue, 23 Sep 1997 12:35:46 -0400 for Message-Id: <3.0.32.19970923123217.0068b130@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 23 Sep 1997 12:32:30 -0400 To: curtis@ans.net From: Dimitry Haskin Subject: (IPng 4511) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1738 Curtis, > >The remote AS routers are on direct interfaces of your own router and >normally direct interfaces are included in the IGP. The only case >where this gets a bit sticky is PTP links in BSD/gated style where the >two ends of the PTP link are not restricted to the same subnet. This >is still OK if the IGP includes both ends of the PTP link to be in the >IGP. It only a problem for unnumbered PTP links (which don't see much >use in this sort of application since other things like SNMP >monitoring get unhappy with no address). > In IPv6 it becomes a bit sticky on all types of directs links due to the desire to reduce re-numbering impact of one V6 site on other V6 sites ("site" is a more appropriate term than "AS" here but you can mentally replace it with "AS" for the discussion at hand). The IPv6 addressing architecture allows two sites to have own independent subnets on the same link. If one site (AS) injects a subnet administrated by another site in its IGP, it becomes dependent on that site address administration. One solution would be to assign a separate DMZ address prefix that can't be renumbered by either site and is not globally advertised but it would require someone to administer such assignments. Another solution would be to refrain from injecting another site's address prefix into the local IGP. >Curtis > Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 10:18:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18069; Tue, 23 Sep 1997 10:07:10 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18057; Tue, 23 Sep 1997 10:06:55 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA22939; Tue, 23 Sep 1997 10:06:52 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA07530 for ; Tue, 23 Sep 1997 10:06:27 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id NAA04324; Tue, 23 Sep 1997 13:06:16 -0400 (EDT) Message-Id: <199709231706.NAA04324@brookfield.ans.net> To: Quaizar Vohra cc: Pedro Marques , ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4512) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Mon, 22 Sep 1997 10:10:59 PDT." <199709221710.KAA01339@lookout.nsd.3com.com> Date: Tue, 23 Sep 1997 13:06:16 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1262 In message <199709221710.KAA01339@lookout.nsd.3com.com>, Quaizar Vohra writes: > > So Far the only use of Global addresses in the NEXT_HOP attribute in > an ebgp update I have understood from all this discussion is to > be able to readvertise it to the ibgp peer so that they could > account for the cost of the IX link between the ASs thru the IGP > metric for the route to that global nexthop. Is that right ? > > Can't you account for the cost of IX link in the local pref before > readvertising the route into ibgp ? > > Please soneone clear up my ignorance ? > > Thanks, > Quaizar The IGP cost would have part of your network aiming at one IX and another aiming at another IX (ie: shortest out). Using local-pref would aim all the traffic at one IX. Local-pref is generally set per prefix per AS and IGP shortest path used to get to the nearest peering point. Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 10:40:06 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18106; Tue, 23 Sep 1997 10:25:06 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18099; Tue, 23 Sep 1997 10:24:49 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA28049; Tue, 23 Sep 1997 10:24:45 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA14198 for ; Tue, 23 Sep 1997 10:24:41 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id NAA04420; Tue, 23 Sep 1997 13:24:32 -0400 (EDT) Message-Id: <199709231724.NAA04420@brookfield.ans.net> To: Quaizar Vohra cc: ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4513) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Mon, 22 Sep 1997 16:04:51 PDT." <199709222304.QAA01453@lookout.nsd.3com.com> Date: Tue, 23 Sep 1997 13:24:32 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1671 In message <199709222304.QAA01453@lookout.nsd.3com.com>, Quaizar Vohra writes: > > > > So Far the only use of Global addresses in the NEXT_HOP attribute in > > an ebgp update I have understood from all this discussion is to > > be able to readvertise it to the ibgp peer so that they could > > account for the cost of the IX link between the ASs thru the IGP > > metric for the route to that global nexthop. Is that right ? > > > > If this is right then why not introduce another attribute which > carries the link cost of the IX link/path. Because the protocol already covers this case. Why remove the functionality and put it some other place. You would then have to determine the total cost by adding the IGP cost to the new BGP attribute. This would be true for all IGPs and a pain to implement. > For IPv6 this will atleast remove the need for administering > assignment of global IPv6 subnet prefix to the DMZ links, or global IPv6 > addresses to the ebgp peers on their IX interfaces. > > Quaizar BGP is not going to be used on dynamicly assigned subnets. Period. No matter how much the IPv6 research community loves the feature. Provider routers don't even run DNS so their reliability is not reduced by a dependency on something external to the router. Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 11:44:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA18223; Tue, 23 Sep 1997 11:32:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA18216; Tue, 23 Sep 1997 11:32:11 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA19282; Tue, 23 Sep 1997 11:32:07 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA08657 for ; Tue, 23 Sep 1997 11:32:07 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id LAA22529; Tue, 23 Sep 1997 11:32:04 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id LAA08332; Tue, 23 Sep 1997 11:19:10 -0700 (PDT) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id LAA08323; Tue, 23 Sep 1997 11:30:08 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id LAA01613; Tue, 23 Sep 1997 11:32:08 -0700 (PDT) Date: Tue, 23 Sep 1997 11:32:08 -0700 (PDT) Message-Id: <199709231832.LAA01613@lookout.nsd.3com.com> To: curtis@ans.net Cc: Quaizar Vohra , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4514) Re: BGP and renumbering.. was /126 or /127 -- neither! In-Reply-To: <199709231724.NAA04420@brookfield.ans.net> References: <199709222304.QAA01453@lookout.nsd.3com.com> <199709231724.NAA04420@brookfield.ans.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2768 Curtis Villamizar writes: > > In message <199709222304.QAA01453@lookout.nsd.3com.com>, Quaizar Vohra writes: > > > > > > So Far the only use of Global addresses in the NEXT_HOP attribute in > > > an ebgp update I have understood from all this discussion is to > > > be able to readvertise it to the ibgp peer so that they could > > > account for the cost of the IX link between the ASs thru the IGP > > > metric for the route to that global nexthop. Is that right ? > > > > > > > If this is right then why not introduce another attribute which > > Because the protocol already covers this case. Why remove the > functionality and put it some other place. You would then have to > determine the total cost by adding the IGP cost to the new BGP > attribute. This would be true for all IGPs and a pain to implement. > Well my point was to avoid passing remote peers address in the NEXT_HOP attr, into IBGP and IGP of the local AS. Which would mean loss of functionality, i.e. unable to account for the cost of the IX link. Hence I introduced this new attribute. Dimitry's previous mails explained why we want to avoid passing remote peer's global IPv6 address into IBGP and IGP of the local AS. > > For IPv6 this will atleast remove the need for administering > > assignment of global IPv6 subnet prefix to the DMZ links, or global IPv6 > > addresses to the ebgp peers on their IX interfaces. > > > > Quaizar > > BGP is not going to be used on dynamicly assigned subnets. Period. > No matter how much the IPv6 research community loves the feature. > > Provider routers don't even run DNS so their reliability is not > reduced by a dependency on something external to the router. > > Curtis My point was not at all to be able to run BGP using dynamically assigned subnets. >From your's and Dimitry's reason I now understand better why it is difficult to introduce this new attribute. We might still avoid passing the remote peer's global address into local AS by using Dimitry's proposal of using link-local addresses in EBGP NEXT_HOPs and rewriting the NEXT_HOPs with a AS-local IPV6 address before readvertising it in IBGP and ensuring that the cost of the IX link could also get accounted for. This could be done by using the AS-local IPV6 address assigned to the border router on the IX link in the NEXT_HOP attribute. Quaizar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 11:49:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA18232; Tue, 23 Sep 1997 11:35:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA18225; Tue, 23 Sep 1997 11:35:12 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA20118; Tue, 23 Sep 1997 11:35:07 -0700 Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA09712 for ; Tue, 23 Sep 1997 11:35:05 -0700 Received: from mailhost.BayNetworks.COM ([132.245.135.84] (may be forged)) by mailhost3.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id OAA22270 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id OAA28605 Posted-Date: Tue, 23 Sep 1997 14:33:55 -0400 (EDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id OAA13692; Tue, 23 Sep 1997 14:33:09 -0400 for Message-Id: <3.0.32.19970923142940.00714894@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 23 Sep 1997 14:30:28 -0400 To: curtis@ans.net From: Dimitry Haskin Subject: (IPng 4515) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2350 At 01:24 PM 9/23/97 -0400, Curtis Villamizar wrote: > >In message <199709222304.QAA01453@lookout.nsd.3com.com>, Quaizar Vohra writes: >> > >> > So Far the only use of Global addresses in the NEXT_HOP attribute in >> > an ebgp update I have understood from all this discussion is to >> > be able to readvertise it to the ibgp peer so that they could >> > account for the cost of the IX link between the ASs thru the IGP >> > metric for the route to that global nexthop. Is that right ? >> > >> >> If this is right then why not introduce another attribute which >> carries the link cost of the IX link/path. > >Because the protocol already covers this case. Why remove the >functionality and put it some other place. You would then have to >determine the total cost by adding the IGP cost to the new BGP >attribute. This would be true for all IGPs and a pain to implement. > I don't agree that it will be necessary to use the new BGP attribute in all IGPs -- at least no more that you'd used MED or LocPref outside of IBGP. This would be normally used for route selection when IBGP "hack" is on and external routes are not injected into IGP. >> For IPv6 this will atleast remove the need for administering >> assignment of global IPv6 subnet prefix to the DMZ links, or global IPv6 >> addresses to the ebgp peers on their IX interfaces. >> >> Quaizar > >BGP is not going to be used on dynamicly assigned subnets. Period. >No matter how much the IPv6 research community loves the feature. > >Provider routers don't even run DNS so their reliability is not >reduced by a dependency on something external to the router. > The point it that in many cases it would be beneficial not assign global-scope addresses to external BGP links at all. Unlike v4, v6 has different scope addresses that would be nice to take advantage of to reduce administrative and renumbering burdens. In case of EBGP, link-local addresses may be sufficient enough. >Curtis > Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 12:26:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA18288; Tue, 23 Sep 1997 12:13:42 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA18281; Tue, 23 Sep 1997 12:13:28 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA01207; Tue, 23 Sep 1997 12:13:24 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA22770 for ; Tue, 23 Sep 1997 12:13:23 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id PAA05147; Tue, 23 Sep 1997 15:13:13 -0400 (EDT) Message-Id: <199709231913.PAA05147@brookfield.ans.net> To: Dimitry Haskin cc: curtis@ans.net, ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4517) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Tue, 23 Sep 1997 12:32:30 EDT." <3.0.32.19970923123217.0068b130@pobox> Date: Tue, 23 Sep 1997 15:13:13 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2321 In message <3.0.32.19970923123217.0068b130@pobox>, Dimitry Haskin writes: > Curtis, > > > > >The remote AS routers are on direct interfaces of your own router and > >normally direct interfaces are included in the IGP. The only case > >where this gets a bit sticky is PTP links in BSD/gated style where the > >two ends of the PTP link are not restricted to the same subnet. This > >is still OK if the IGP includes both ends of the PTP link to be in the > >IGP. It only a problem for unnumbered PTP links (which don't see much > >use in this sort of application since other things like SNMP > >monitoring get unhappy with no address). > > > > In IPv6 it becomes a bit sticky on all types of directs links due to the > desire to reduce re-numbering impact of one V6 site on other V6 sites > ("site" is a more appropriate term than "AS" here but you can mentally > replace it with "AS" for the discussion at hand). The IPv6 addressing > architecture allows two sites to have own independent subnets on the same > link. If one site (AS) injects a subnet administrated by another site in > its IGP, it becomes dependent on that site address administration. One > solution would be to assign a separate DMZ address prefix that can't be > renumbered by either site and is not globally advertised but it would > require someone to administer such assignments. Another solution would be > to refrain from injecting another site's address prefix into the local IGP. Summarizing what you said, there are two cases: 1. two site addresses on the same media. BGP sender or receiver replaces next-hop. (not recommended for large provider exchanges) 2. fixed subnet same as IPv4. (strongly recommended) I added the stuff in parens. I don't see interprovider interconnects using dynamic assigned addresses. These things come up and to the extent possible they are not supposed to go down at all or change addresses. Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 13:32:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA18432; Tue, 23 Sep 1997 13:21:01 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA18425; Tue, 23 Sep 1997 13:20:43 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id NAA22992 for ; Tue, 23 Sep 1997 13:19:32 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA03446; Tue, 23 Sep 1997 13:14:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA18250; Tue, 23 Sep 1997 11:55:12 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA25983; Tue, 23 Sep 1997 11:55:08 -0700 Received: from syzygy.ieng.com (syzygy.ieng.com [207.24.215.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA16411 for ; Tue, 23 Sep 1997 11:55:05 -0700 Received: (from jgs@localhost) by syzygy.ieng.com (8.8.5/8.7.3) id OAA14146; Tue, 23 Sep 1997 14:54:56 -0400 (EDT) From: "John G. Scudder" Message-Id: <199709231854.OAA14146@syzygy.ieng.com> Subject: (IPng 4518) Re: BGP and renumbering.. was /126 or /127 -- To: dhaskin@baynetworks.com (Dimitry Haskin) Date: Tue, 23 Sep 1997 14:54:56 -0400 (EDT) Cc: curtis@ans.net, ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <3.0.32.19970923142940.00714894@pobox> from "Dimitry Haskin" at Sep 23, 97 02:30:28 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1927 Dimitry Haskin writes: ... > I don't agree that it will be necessary to use the new BGP attribute in all > IGPs -- at least no more that you'd used MED or LocPref outside of IBGP. > This would be normally used for route selection when IBGP "hack" is on and > external routes are not injected into IGP. ... Exactly. The proposed attribute would change the route selection procedure. Allow me to note that the IBGP route selection procedure is probably the biggest interoperability landmine in BGP. We've had enough problems with it already without putting yet *another* special case in. If such an attribute *were* to be introduced, I would have a large cow if it wasn't mandatory for all (IPv6) BGPs to handle it in an interoperable way (which probably means identically). Since there's no way that people are going to simultaneously mass-upgrade all their IPv4 BGPs to accomodate this new feature, that means we'd have to have two divergent selection procedures -- one for IPv4, one for IPv6. This is, at best, aesthetically unappealing. Furthermore, if the floor is open for modifying the IBGP selection procedure, I'd like to fix this problem in the general case rather than applying further special-case kludges. Do we really want to open this can of worms? Regards, --John -- John G. Scudder email: jgs@ieng.com Internet Engineering Group, LLC phone: (313) 213-4939 ext 14 122 S. Main, Suite 280 fax: (313) 669-8661 Ann Arbor, MI 48104 www: http://www.ieng.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 14:11:06 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA18501; Tue, 23 Sep 1997 14:02:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA18494; Tue, 23 Sep 1997 14:02:14 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA28826; Tue, 23 Sep 1997 14:02:11 -0700 Received: from mailhost2.BayNetworks.COM ([134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA29114 for ; Tue, 23 Sep 1997 14:02:05 -0700 Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by mailhost2.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id OAA20354 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id RAA29340 Posted-Date: Tue, 23 Sep 1997 17:00:27 -0400 (EDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id QAA01632; Tue, 23 Sep 1997 16:59:13 -0400 for Message-Id: <3.0.32.19970923165544.006d0c40@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 23 Sep 1997 16:56:59 -0400 To: Quaizar Vohra From: Dimitry Haskin Subject: (IPng 4519) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: curtis@ans.net, Quaizar Vohra , ipng@sunroof.eng.sun.com, idr@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2179 Quaizar, > >>From your's and Dimitry's reason I now understand better why >it is difficult to introduce this new attribute. > >We might still avoid passing the remote peer's global address >into local AS by using Dimitry's proposal of using link-local >addresses in EBGP NEXT_HOPs and rewriting the NEXT_HOPs with >a AS-local IPV6 address before readvertising it in IBGP and >ensuring that the cost of the IX link could also get accounted for. >This could be done by using the AS-local IPV6 address assigned to >the border router on the IX link in the NEXT_HOP attribute. > You just made a very important observation. You are right: we can account for the cost of an IX link without introducing a new attribute. Let me depict it so it is crisp and clear. 1 1 A1 -----s1 B1---------B4 IX | 5 1 |1 A2 -----s2 B2---------B3 IX Routers A* are in one AS, routers B* are in another AS. A1 and B1, and A2 and B2 exchange routes via EBGP respectively. When B1 readvertises A1's routes to its internal BGP peers it uses a site-local address of its interface on IX link to A1, say s1, as the NEXT_HOP, and B2 uses a site-local address of its interface on the IX link to A2, say s2, as the NEXT_HOP. If external BGP routes are injected into IGP as ASE routes, the same site-local addresses, s1 and s2, are specified as forwarding addresses. Both s1 and s2 are injected into IGP with the costs of their respective link, i.e. 1 and 5 respectively. Now costs of the IX link are fully accounted in route selection. In the above diagram, if the same external network is reachable via either border router, every B* sends packets to that external network via the B1/A1 link as a lower cost path. >Quaizar Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 16:06:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA18657; Tue, 23 Sep 1997 15:56:45 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA18650; Tue, 23 Sep 1997 15:56:36 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA04309; Tue, 23 Sep 1997 15:56:32 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA06536 for ; Tue, 23 Sep 1997 15:56:29 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id PAA26457; Tue, 23 Sep 1997 15:56:25 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id PAA13867; Tue, 23 Sep 1997 15:43:30 -0700 (PDT) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id PAA17538; Tue, 23 Sep 1997 15:54:29 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id PAA01659; Tue, 23 Sep 1997 15:56:30 -0700 (PDT) Date: Tue, 23 Sep 1997 15:56:30 -0700 (PDT) Message-Id: <199709232256.PAA01659@lookout.nsd.3com.com> To: Dimitry Haskin Cc: Quaizar Vohra , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4520) Re: BGP and renumbering.. was /126 or /127 -- neither! In-Reply-To: <3.0.32.19970923165544.006d0c40@pobox> References: <3.0.32.19970923165544.006d0c40@pobox> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2789 >From this whole excercise there seems to be another conclusion that in IPv6 global addresses should not be used anywhere within BGP's protocol machinary,i.e. as NEXT_HOPs, or for peering, if IPv6 addresses ever get used for peering. This will mean some amount of configuration on renumbering. If IPv6 addresses ever get used for peering then it should not use global IPv6 address because this will mean a lots of reconfiguration on renumbering within ebgp as well as ibgp. One should I guess use site-local addresses or some scoped form which is permanent with an AS. This brings up the issue whether an AS is composed of multiple sites (wrt to site-local addressing) or a single site ? Which suggests that either a) A set of geographically distinct sites in the same AS share a single instance of site-local addressing. b) Each site gets an AS. The sites join a higher level confederation AS. The NEXT_HOP attributes can be readvertised only within a site and changes as it changes as the route traverses to another site. c) We define another scope of IPv6 addresses. Quaizar > > You just made a very important observation. You are right: we can account > for the cost of an IX link without introducing a new attribute. Let me > depict it so it is crisp and clear. > > 1 1 > A1 -----s1 B1---------B4 > IX | > 5 1 |1 > A2 -----s2 B2---------B3 > IX > > Routers A* are in one AS, routers B* are in another AS. A1 and B1, and A2 > and B2 exchange routes via EBGP respectively. When B1 readvertises A1's > routes to its internal BGP peers it uses a site-local address of its > interface on IX link to A1, say s1, as the NEXT_HOP, and B2 uses a > site-local address of its interface on the IX link to A2, say s2, as the > NEXT_HOP. If external BGP routes are injected into IGP as ASE routes, the > same site-local addresses, s1 and s2, are specified as forwarding > addresses. Both s1 and s2 are injected into IGP with the costs of their > respective link, i.e. 1 and 5 respectively. Now costs of the IX link are > fully accounted in route selection. > > In the above diagram, if the same external network is reachable via either > border router, every B* sends packets to that external network via the > B1/A1 link as a lower cost path. > > >Quaizar > > Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 17:06:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA18831; Tue, 23 Sep 1997 16:57:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA18824; Tue, 23 Sep 1997 16:56:52 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA23615; Tue, 23 Sep 1997 16:56:49 -0700 Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA25418 for ; Tue, 23 Sep 1997 16:56:48 -0700 Received: from mailhost.BayNetworks.COM ([132.245.135.115] (may be forged)) by mailhost3.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id UAA04222 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id TAA07519 Posted-Date: Tue, 23 Sep 1997 19:56:12 -0400 (EDT) Received: from dhaskin.baynetworks.com (eng_ppp8 [192.32.171.148]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id TAA19577; Tue, 23 Sep 1997 19:56:10 -0400 for Message-Id: <3.0.1.32.19970923195431.0069fc20@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 23 Sep 1997 19:54:31 -0400 To: Quaizar Vohra , Dimitry Haskin From: Dimitry Haskin Subject: (IPng 4521) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <199709232256.PAA01659@lookout.nsd.3com.com> References: <3.0.32.19970923165544.006d0c40@pobox> <3.0.32.19970923165544.006d0c40@pobox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2200 At 03:56 PM 9/23/97 -0700, Quaizar Vohra wrote: > >>From this whole excercise there seems to be another conclusion that >in IPv6 global addresses should not be used anywhere within BGP's >protocol machinary,i.e. as NEXT_HOPs, or for peering, if IPv6 addresses >ever get used for peering. This will mean some amount of configuration >on renumbering. > >If IPv6 addresses ever get used for peering then it should not use >global IPv6 address because this will mean a lots of reconfiguration >on renumbering within ebgp as well as ibgp. One should I guess use >site-local addresses or some scoped form which is permanent with an >AS. > >This brings up the issue whether an AS is composed of multiple sites >(wrt to site-local addressing) or a single site ? Which suggests that >either > >a) A set of geographically distinct sites in the same AS share a single > instance of site-local addressing. >b) Each site gets an AS. The sites join a higher level confederation AS. > The NEXT_HOP attributes can be readvertised only within a site and > changes as it changes as the route traverses to another site. >c) We define another scope of IPv6 addresses. > Wow, I thought we were done with this Site vs AS confusion?! For purpose of our discussions, a site is a collection of v6 interfaces that get their addresses allocated from a single set (aggregate) of site local addresses (SLA). That has little to do with geography. [It is conceivable albeit probably unlikely for a site to consist from multiple ASs but not vise versa.] As I stated earlier in the discussion, I don't see how multiple sites can form a single IGP domain (aka AS). You need to run EGP (EBGP in this case) between sites. Naturally, since you running EBGP between sites, the NEXT_HOP changes as routes cross site boundaries. >Quaizar Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 17:26:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA18966; Tue, 23 Sep 1997 17:17:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA18959; Tue, 23 Sep 1997 17:17:02 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA00242; Tue, 23 Sep 1997 17:16:57 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id RAA01539 for ; Tue, 23 Sep 1997 17:16:56 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id RAA07280; Tue, 23 Sep 1997 17:16:55 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id RAA25146; Tue, 23 Sep 1997 17:03:59 -0700 (PDT) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id RAA20590; Tue, 23 Sep 1997 17:14:59 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id RAA01688; Tue, 23 Sep 1997 17:17:00 -0700 (PDT) Date: Tue, 23 Sep 1997 17:17:00 -0700 (PDT) Message-Id: <199709240017.RAA01688@lookout.nsd.3com.com> To: Dimitry Haskin Cc: Quaizar Vohra , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4522) Re: BGP and renumbering.. was /126 or /127 -- neither! In-Reply-To: <3.0.1.32.19970923195431.0069fc20@pobox> References: <3.0.32.19970923165544.006d0c40@pobox> <199709232256.PAA01659@lookout.nsd.3com.com> <3.0.1.32.19970923195431.0069fc20@pobox> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1898 > > > >This brings up the issue whether an AS is composed of multiple sites > >(wrt to site-local addressing) or a single site ? Which suggests that > >either > > > >a) A set of geographically distinct sites in the same AS share a single > > instance of site-local addressing. > >b) Each site gets an AS. The sites join a higher level confederation AS. > > The NEXT_HOP attributes can be readvertised only within a site and > > changes as it changes as the route traverses to another site. > >c) We define another scope of IPv6 addresses. > > > > Wow, I thought we were done with this Site vs AS confusion?! > > For purpose of our discussions, a site is a collection of v6 interfaces > that get their addresses allocated from a single set (aggregate) of site > local addresses (SLA). That has little to do with geography. [It is > conceivable albeit probably unlikely for a site to consist from multiple > ASs but not vise versa.] As I stated earlier in the discussion, I don't see > how multiple sites can form a single IGP domain (aka AS). You need to run > EGP (EBGP in this case) between sites. Naturally, since you running EBGP > between sites, the NEXT_HOP changes as routes cross site boundaries. > > >Quaizar > > Dimitry Dimitry, I think you are right. This might mean that we might see multiple levels of BGP running, i.e. confederations may become a common case in IPv6. This also naturally aligns with multiple levels of heirarchy within the IPv6 address. Quaizar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 17:44:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA19005; Tue, 23 Sep 1997 17:28:03 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA18994; Tue, 23 Sep 1997 17:27:54 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id RAA03300 for ; Tue, 23 Sep 1997 17:27:55 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA03950; Tue, 23 Sep 1997 17:25:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA18974; Tue, 23 Sep 1997 17:19:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA00883; Tue, 23 Sep 1997 17:19:41 -0700 Received: from syzygy.ieng.com (syzygy.ieng.com [207.24.215.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA02414 for ; Tue, 23 Sep 1997 17:19:39 -0700 Received: (from jgs@localhost) by syzygy.ieng.com (8.8.5/8.7.3) id UAA19210; Tue, 23 Sep 1997 20:17:12 -0400 (EDT) From: "John G. Scudder" Message-Id: <199709240017.UAA19210@syzygy.ieng.com> Subject: (IPng 4525) Re: BGP and renumbering.. was /126 or /127 -- To: dhaskin@baynetworks.com (Dimitry Haskin) Date: Tue, 23 Sep 1997 20:17:12 -0400 (EDT) Cc: qv@3com.com, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <3.0.1.32.19970923195431.0069fc20@pobox> from "Dimitry Haskin" at Sep 23, 97 07:54:31 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1260 Dimitry Haskin writes: > I don't see how multiple sites can form a single IGP domain (aka AS). This is at least the second time this misconception has come up. There's no law of nature that says that a single AS will necessarily run a single IGP. It would be awfully nice if this were always true in the real world, but sadly, it ain't. For better or for worse, IBGP can be, and is, made to work in an AS comprising multiple IGP domains. All that really needs to happen is for all the participating routers to know how to resolve the next hops they receive. The means for doing this can be quite messy. --John -- John G. Scudder email: jgs@ieng.com Internet Engineering Group, LLC phone: (313) 213-4939 ext 14 122 S. Main, Suite 280 fax: (313) 669-8661 Ann Arbor, MI 48104 www: http://www.ieng.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 23 17:44:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA19008; Tue, 23 Sep 1997 17:28:10 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA18990; Tue, 23 Sep 1997 17:27:07 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA02461; Tue, 23 Sep 1997 17:27:03 -0700 Received: from mailhost2.BayNetworks.COM ([134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id RAA04394 for ; Tue, 23 Sep 1997 17:27:01 -0700 Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by mailhost2.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id RAA26318 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id UAA07684 Posted-Date: Tue, 23 Sep 1997 20:25:38 -0400 (EDT) Received: from dhaskin.baynetworks.com (eng_ppp8 [192.32.171.148]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id UAA20835; Tue, 23 Sep 1997 20:25:36 -0400 for Message-Id: <3.0.1.32.19970923202359.006a9f20@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 23 Sep 1997 20:23:59 -0400 To: curtis@ans.net From: Dimitry Haskin Subject: (IPng 4524) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <199709231913.PAA05147@brookfield.ans.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1054 At 03:13 PM 9/23/97 -0400, Curtis Villamizar wrote: > >I don't see interprovider interconnects using dynamic assigned >addresses. These things come up and to the extent possible they are >not supposed to go down at all or change addresses. > I believe we agree on that. To boot, we'd like to achieve it without granting permanent ownership of global-scope addresses or imposing undue renumbering dependencies between independently administered sites. To this end, we try to utilize v6 local scope addresses -- something that is missing in the V4 addressing architecture (well.. except v4 private use addresses which are useless for the problem at hand). >Curtis Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 24 02:18:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA19492; Wed, 24 Sep 1997 02:09:37 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA19485; Wed, 24 Sep 1997 02:09:28 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA29209; Wed, 24 Sep 1997 02:09:27 -0700 Received: from scol.sco.com (scol.london.sco.COM [150.126.1.48]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA20297 for ; Wed, 24 Sep 1997 02:09:26 -0700 Received: from nowhere.london.sco.com by scol.sco.COM id aa02244; 24 Sep 97 9:51 BST X-Uri: X-Face: "Ht#9&2KEo;v0Jn!m[7V}D}F5>{KUiNw Date: Wed, 24 Sep 1997 09:51:37 +0100 Message-ID: <6506.875091097@sco.COM> From: Harvey Thompson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4909 > I think the following from Erik will work: > > +struct dynhostent *gethostbynameafopt(char *name, int af, int options); > > +void freedynhostent(struct dynhostent *); > > +These interfaces are MT safe without introducing the notion of > +a context to the programmer. > > What we need to define now is what is in the "int options" as a > parameter for gethosbynameafopt(). ALso getaddrinfo() can still be used > by calling gethostbynameafopt() and freedynhostent() so it is using a MT > safe funtion which gethostbyname2 is not. As Paul Vixie pointed out earlier... : someone else said that there was a freeaddrinfo() to go along with : the getaddrinfo(), so i'm now left wondering why any of us care about : gethostby*() at all. Lets assume that we do indeed want to have gethostbynameafopt() and freedynhostent(), and not force people to use getaddrinfo/getnameinfo if they're writing MT apps (ignoring implementation issues of these functions); 1. Why not call it "getdynhostent()" which is less of a mouthful and gives us an idea of what is really going on. I assume that dynhostent looks exactly like hostent except in name; struct dynhostent { char * h_name; char ** h_aliases; int h_addrtype; int h_length; char ** h_addr_list; #define h_addr h_addr_list[0] }; 2. The options might as well be the same as the ai_flags that getaddrinfo() uses, in which case we can have getaddrinfo() take the new options flags as well (makes the probable implementation easier); struct dynhostent *getdynhostent(const char *host, int af, int ai_opts); void freedynhostent(struct dynhostent *); /* if host is NULL, return bind()-able address */ #define AI_PASSIVE 0x01 /* has no effect (h_name is always canonical name) */ #define AI_CANONNAME 0x02 /* If af == AF_INET6 and host has no IPv6 addresses, return IPv4 mapped IPv6 addresses -- otherwise fail */ #define AI_INET6_V4MAP 0x04 Things to consider are that this extends POSIX, and that having the same AI_ prefix may be confusing but it doesn't mess up the namespace as much or involve keeping two sets of defines in sync. I don't see the use in having an option saying "if we ask for AF_INET give us AF_INET6". See below; > But we are also saying that gethostbyname() will only return IPv4 > addresses forever? 3. If we keep gethostbyname2() (I'm loathe to, but I'm not too sure how much use this function has seen), it would also just return what you ask for. gethostbyname(host) returns IPv4 address always gethostbyname2(host, af) returns af address always If af == AF_INET6 and the host has no IPv4 address we return (1)? (1) The choices are NULL or IPv4 mapped IPv6 address(es). Personally to me the latter is more useful, as we can then test with IN6_IS_ADDR_V4MAPPED() if we wanted to know if it had real IPv6 address(es) or not, ie. the equivalent of AI_INET6_V4MAP is set. Programs I've seen written with gethostbyname() tend to assume that it returns inaddr addresses (ie. they don't check h_length or h_addrtype). Having an option to make gethostbyname() or a similar function return non-IPV4 addresses, although it fits into the ethos, would probably break more things than it would help. So what have we ended up with; something similar to gethostbyname(), but disimilar enough such that applications would have to be rewritten anyway; chaning struct hostent to struct dynhostent, changing gethostbyname to the new function with the new arguments, adding freedynhostent() in the right place(s), rewriting the code which previously assumed IPv4 only addresses; so perhaps it's better if we force everyone to use getaddrinfo/getnameinfo which are much cleaner interfaces anyway, with a similar amount of pain (infact code often becomes simpler and clearer). This means less interfaces, which is less confusing to the developer, and less implementation to go wrong. KISS! So despite what I've said, my vote goes for; 1. gethostbyname() would only return AF_INET 2. NO gethostbyname2(). 3. NO getdynhostent/gethostentafopt 4. Add more AI_ options as required (AI_INET6_V4MAP?) 5. IPv6 and MT applications use getaddrinfo() Of course implementation of getaddrinfo() which uses gethostbyname() would be tricky -- but that's an implementation issue... with which we, wearing our IETF hats, shouldn't be concerned. --- Harvey Thompson harveyt@sco.com internet Engineering Group, SCO, London UK. +44 1923 813583 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 24 05:02:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA19782; Wed, 24 Sep 1997 04:54:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA19775; Wed, 24 Sep 1997 04:54:03 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA09320; Wed, 24 Sep 1997 04:54:01 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA18132 for ; Wed, 24 Sep 1997 04:54:01 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id HAA23975 for ; Wed, 24 Sep 1997 07:47:16 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA25441; Wed, 24 Sep 1997 07:47:15 -0400 Message-Id: <9709241147.AA25441@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4528) Addr Conf Denial of Service and Interact with DHCPv6 Date: Wed, 24 Sep 1997 07:47:14 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 10409 From: draft-ietf-ipngwg-addrconf-v2-00.txt Several issues and things to be resolved. >5.5.3. Router Advertisement Processing > On receipt of a valid Router Advertisement (as defined in > [DISCOVERY]), a host copies the value of the advertisement's M bit > into ManagedFlag. If the value of ManagedFlag changes from FALSE to > TRUE, the host should invoke the stateful address autoconfiguration > protocol, requesting address information. If the value of the > ManagedFlag changes from TRUE to FALSE, the host should terminate the > stateful address autoconfiguration protocol (i.e., stop requesting > addresses and ignore subsequent responses to in-progress > transactions). If the value of the flag stays unchanged, no special > action takes place. In particular, a host MUST NOT reinvoke stateful > address configuration if it is already participating in the stateful > protocol as a result of an earlier advertisement. I think we need words above that permit DHCPv6 to continue running if it is being used for Dyanmic Updates to DNS (DDNS) via a DHCPv6 server. So I object to the words that say "terminate" the stateful protocol. I propose the following: .................. If the value of the ManagedFlag changes from TRUE to FALSE, the host MUST terminate the use of the stateful address autoconfiguration protocol as a mechanism to obtain new addresses or update existing address lifetimes. If addr conf changes a stateless address the node still can use DHCPv6 for example to update the DNS, so we don't want to say kill the stateful protocol which MAY serve multiple purposes. Also if an address from stateful valid-life becomes zero via addr conf, in the case of DHCPv6 I would think we would want a DHCPv6 RELEASE to be sent to the DHCPv6 server as one example, rather than the default to time out at the server as an implementation choice. I think customers will want this done in an orderly manner. > An advertisement's O flag field is processed in an analogous manner. > A host copies the value of the O flag into OtherConfigFlag. If the > value of OtherConfigFlag changes from FALSE to TRUE, the host should > invoke the stateful autoconfiguration protocol, requesting > information (excluding addresses). If the value of the > OtherConfigFlag changes from TRUE to FALSE, any activity related to > stateful autoconfiguration for parameters other than addresses should > be halted. If the value of the flag stays unchanged, no special > action takes place. In particular, a host MUST NOT reinvoke stateful > configuration if it is already participating in the stateful protocol > as a result of an earlier advertisement. This is a problem too. If the "M" flag is set it should imply the client can accept OTHER configuration information as part of the DHCPv6 exts specification. Like DNS processing or the POSIX TIMEZONE variable. I propose the following: ..... If the value of the OtherConfigFlag changes from TRUE to FALSE any activity related to stateful autoconfiguration for paramters that would alter the value of the link as defined in this specification or Neighbor Discovery [ND-REF] MUST be halted. I think we need also to make it clear in this spec that: 1. M bit means you don't get to receive link parameters like from DHCPv6. 2. O bit must be set for a node to get link parameters like from DHCPv6. Sorry I did not see these two above issues sooner but it popped out at me as I started to implement DHCPv6 next to/integrated with Addr Conf. > For each Prefix-Information option in the Router Advertisement: > > a) If the Autonomous flag is not set, silently ignore the Prefix > Information option. > > b) If the prefix is the link-local prefix, silently ignore the > Prefix Information option. > > c) If the preferred lifetime is greater than the valid lifetime, > silently ignore the Prefix Information option. A node MAY wish to > log a system management error in this case. > > d) If the prefix advertised matches the prefix of an autoconfigured | > address (i.e., one obtained previously via stateless or stateful | > autoconfiguration) in the list of addresses associated with the | > interface, and the valid lifetime in the received RA is both less | > than 2 hours and less than the remaining valid Lifetime in the | > cached entry, ignore the Prefix Information option for the | > purpose of stateless address autoconfiguration. | This has now come up for DHCPv6 too as an issue too. I realize the Denial of Service issue but this fix is unacceptable to me as a vendor. I must be able to permit my customer sys admins to do three things: 1. Recover if a bogus address was given out (stateless or stateful). 2. Recover if they want to change the valid lifetime to 1 hour. 3. For some reason cause all connections to break by sending out a valid lifetime of zero or by some other mechanism. These are market requirements for IPv6 Autoconfiguration. Either we go back to the way it was and live with the denial of service issue or come up with a new answer. I think we have the answer at hand with IPSEC. If a user does not want to experience this denial of service attack they must use IPSEC Authentication at a minimum and Encryption as a maximum. If IPSEC can't do this in an environment like the IETF Terminal room then IPSEC needs to go back to the drawing board and figure it out. We as vendors are making a huge investment in IPSEC and it is costing us money and our customers want IPSEC. I would suggest we connect with the IPSEC group and get their input on how difficult and why it would not be possible to use IPSEC to distribute keys in an IETF terminal room environment. Before we make the above change to addr conf. ALso we should check with Bob Moskowitz if this has been an issue at the present IPSEC ANX bake-offs as other data before we adopt the above change too in addition to running this by IPSEC WG. > f) If the prefix advertised matches the prefix of an autoconfigured | > address (i.e., one obtained previously via stateless or stateful | > autoconfiguration) in the list of addresses associated with the | > interface, and the preferred lifetime in the received RA is both | > less than 2 hours and less than the remaining preferred Lifetime | > in the cached entry, ignore the Prefix Information option for the | > purpose of stateless address autoconfiguration. | Same issues essentially as stated for valid lifetime above. > In those cases where a site requires the use of longer prefixes > than can be accommodated by the interface identifier, stateful | > autoconfiguration can be used. | I think this should not be stated now per the new Addr Arch spec and use of TLAs, SLAs, etc. and IPv6 over FOO using EUI 64. All prefixes should not be greater than 64bits and should be the left most 64bits of an IPv6 address. So I suggest we just delete the above from the text. This will apply to both addr conf and stateful. > If an address is formed successfully, the host adds it to the > list of addresses assigned to the interface, initializing its > preferred and valid lifetime values from the Prefix Information > option. Note for next set of comments that this conceptual list will also contain addresses from DHCPv6. >5.6. Configuration Consistency > It is possible for hosts to obtain address information using both > stateless and stateful protocols since both may be enabled at the > same time. It is also possible that the values of other > configuration parameters such as MTU size and hop limit will be > learned from both Router Advertisements and the stateful > autoconfiguration protocol. If the same configuration information is > provided by multiple sources, the value of this information should be > information received from multiple sources is inconsistent. Hosts > accept the union of all information received via the stateless and > stateful protocols. If inconsistent information is learned from > different sources, the most recently obtained values always have > precedence over information learned earlier. There is an issue here for addresses and lifetimes. If stateless and stateful are in synch through system administration they could be using the same prefixes. If stateful is in process and addresses are assigned to the interface with lifetimes like: 4c6e::12 valid=2 days preferred=1 day Then addr conf says use stateless and: 4c6e::12 valid=1 day preferred= 5 hours We have an inconsistecy at the stateful server and I think we should RELEASE the address when this happens via DHCPv6 from the client node. But the words in addr conf in 5.5.3 do not permit me to send this message. The issue is to provide consistency and keep any stateful server databases up-to-date (kind of like garbage collection for network addresses in IPv6 addr conf). Suggestion: I think the fix is to permit releasing of addresses when a Router Advertisement shuts off stateful (M-bit clear), and an address or lifetime is altered via stateless that was last created or updated via Stateful mechanisms. If both A bit is set as prefix option and M bit is set in Router Advertisement. AND. Stateless overrides lifetimes or deletes an address the stateful processing module should release that address to the stateful server or process handling this (e.g. DHCPv6 server). For link configuration information the UNION and most recently used algorithm stated above in 5.6 will work. The only issue is for addresses and lifetimes. I think my suggestions for 5.5.3 and 5.6 are congruent but the WG should check out if my wording is in synch. Thanks............ Comments ???? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 24 07:05:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA19884; Wed, 24 Sep 1997 06:56:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA19877; Wed, 24 Sep 1997 06:56:30 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA26740; Wed, 24 Sep 1997 06:56:26 -0700 Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA18170 for ; Wed, 24 Sep 1997 06:56:25 -0700 Received: from mailhost.BayNetworks.COM ([132.245.135.115] (may be forged)) by mailhost3.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id KAA17689 Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id JAA10694 Posted-Date: Wed, 24 Sep 1997 09:55:47 -0400 (EDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id JAA25615; Wed, 24 Sep 1997 09:55:45 -0400 for Message-Id: <3.0.32.19970924095218.006d6d9c@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 24 Sep 1997 09:52:19 -0400 To: "John G. Scudder" From: Dimitry Haskin Subject: (IPng 4529) Re: BGP and renumbering.. was /126 or /127 -- Cc: dhaskin@baynetworks.com (Dimitry Haskin), qv@3com.com, dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com, idr@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1452 At 08:17 PM 9/23/97 -0400, John G. Scudder wrote: >Dimitry Haskin writes: >> I don't see how multiple sites can form a single IGP domain (aka AS). > >This is at least the second time this misconception has come up. >There's no law of nature that says that a single AS will necessarily >run a single IGP. It would be awfully nice if this were always >true in the real world, but sadly, it ain't. > Sorry that are confused you with AS in the parenthesis. I did it for the sake of simplicity in the contexts of this discussion and first hesitated to do that (this is why parenthesis) suspecting comments as yours. All is really important for this particular discussion that v6 sites need to be interconnected with EGP, i.e. a given IBGP mesh can't span more than one v6 site. >For better or for worse, IBGP can be, and is, made to work in an >AS comprising multiple IGP domains. All that really needs to happen >is for all the participating routers to know how to resolve the >next hops they receive. The means for doing this can be quite messy. > >--John > Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 24 07:24:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA19930; Wed, 24 Sep 1997 07:16:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA19923; Wed, 24 Sep 1997 07:16:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA02801; Wed, 24 Sep 1997 07:16:48 -0700 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA24169 for ; Wed, 24 Sep 1997 07:16:47 -0700 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id KAA03052; Wed, 24 Sep 1997 10:16:39 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.12) id KAA10591; Wed, 24 Sep 1997 10:16:38 -0400 Date: Wed, 24 Sep 1997 10:16:38 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <970924101638.ZM10589@seawind.bellcore.com> In-Reply-To: Quaizar Vohra "(IPng 4522) Re: BGP and renumbering.. was /126 or /127 -- neither!" (Sep 23, 5:17pm) References: <3.0.32.19970923165544.006d0c40@pobox> <199709232256.PAA01659@lookout.nsd.3com.com> <3.0.1.32.19970923195431.0069fc20@pobox> <199709240017.RAA01688@lookout.nsd.3com.com> X-Mailer: Z-Mail (4.0.1 13Jan97) To: Quaizar Vohra , Dimitry Haskin Subject: (IPng 4530) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1910 Dimitry, Quaizar, One of the point that was agreed during the Munich meeting of IPv6 is that Site Local addresses should not be used for EGP routing exchanges. One of the reasons is that nobody really knows what is a site, and that there is absolutely zero reason to think that an AS is a single site. (My personnal feeling is that site local addresses should not be used *at all*, at least in a connected site, because they have all the properties of Net 10 addresses). Think of what happens when a host or a router belongs to several sites, which would be very easy in mobile environments. There are two valid lines that can be pursued if we dump site local addresses. The short term solution is "non renumbered addresses", i.e. an address domain that is only used for interconnections, and is not renumbered at the same time as either AS. There are two costs to this solutions; one needs to allocate these specific domains, which is an administrative cost, and one needs to carry host routes within the IGP for the remote routers, which is an operational cost. Neither cost is unbearable. The longer term solution is to design renumbering support in the next EGP. Next-hop is a local parameter, which is not propagated in the global Internet. We should be able to update that parameter without triggering Internet wide route swaps. If we do that, the cost is some additional complexity in BGP, but we will not need special addresses and we will also not need to carry host routes in the IGP. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 24 07:58:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA19956; Wed, 24 Sep 1997 07:50:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA19949; Wed, 24 Sep 1997 07:50:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA13149; Wed, 24 Sep 1997 07:50:38 -0700 Received: from syzygy.ieng.com (syzygy.ieng.com [207.24.215.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA04679 for ; Wed, 24 Sep 1997 07:50:36 -0700 Received: (from jgs@localhost) by syzygy.ieng.com (8.8.5/8.7.3) id KAA21219; Wed, 24 Sep 1997 10:50:32 -0400 (EDT) From: "John G. Scudder" Message-Id: <199709241450.KAA21219@syzygy.ieng.com> Subject: (IPng 4531) Re: BGP and renumbering.. was /126 or /127 -- neither! To: huitema@bellcore.com (Christian Huitema) Date: Wed, 24 Sep 1997 10:50:32 -0400 (EDT) Cc: ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <970924101638.ZM10589@seawind.bellcore.com> from "Christian Huitema" at Sep 24, 97 10:16:38 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1774 Christian Huitema writes: ... > Next-hop is a local parameter, which is not propagated in the global > Internet. We should be able to update that parameter without triggering > Internet wide route swaps. If we do that, the cost is some additional > complexity in BGP, but we will not need special addresses and we will also > not need to carry host routes in the IGP. ... But this is how current BGP is specified, insofar as the NEXT_HOP is (or is supposed to be) rewritten at every AS boundary. An EBGP speaker is supposed to only advertise a NEXT_HOP to an external peer such that "...the interface associated with the IP address of this [NEXT_HOP] shares a common subnet with both the local and remote BGP speakers." This essentially mandates that the NEXT_HOP be an address on the IX. It seems pretty clear to me that this restricts renumbering information to only have to be propagated to the ASes immediately bordering a given IX, not to the big-I Internet. If some minimal level of operational care is taken, nobody else need see a single route hiccup as a result. So I think this is not a problem. Regards, --John -- John G. Scudder email: jgs@ieng.com Internet Engineering Group, LLC phone: (313) 213-4939 ext 14 122 S. Main, Suite 280 fax: (313) 669-8661 Ann Arbor, MI 48104 www: http://www.ieng.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 24 08:34:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA20122; Wed, 24 Sep 1997 08:23:27 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA20115; Wed, 24 Sep 1997 08:23:16 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA22568; Wed, 24 Sep 1997 08:23:14 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA15799 for ; Wed, 24 Sep 1997 08:22:25 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA13715; Wed, 24 Sep 1997 10:22:11 -0500 Message-Id: <199709241522.KAA13715@gungnir.fnal.gov> To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com, idr@merit.edu From: "Matt Crawford" Subject: (IPng 4532) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of Wed, 24 Sep 1997 10:16:38 EDT. <970924101638.ZM10589@seawind.bellcore.com> Date: Wed, 24 Sep 1997 10:22:11 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1112 > One of the point that was agreed during the Munich meeting of IPv6 is that > Site Local addresses should not be used for EGP routing exchanges. Christian, Once again, you make me wonder if we were at the same meeting. I find nothing remotely like your statement above in my memory, my notes, or the minutes of the meeting I attended. (That was in Munich, Bavaria, Germany. Perhaps there are two Munichs?) However, I think I agree with the above, but not with > (My personnal feeling is that site local addresses should not be > used *at all*, at least in a connected site, because they have all > the properties of Net 10 addresses). and what follows. However, that topic is out of scope for this thread. Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 24 09:20:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20176; Wed, 24 Sep 1997 09:06:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20169; Wed, 24 Sep 1997 09:06:46 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA03653; Wed, 24 Sep 1997 09:06:36 -0700 Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA28784 for ; Wed, 24 Sep 1997 09:06:24 -0700 Received: from mailhost.BayNetworks.COM (cloak.BayNetworks.COM [192.32.249.1]) by mailhost3.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id MAA22271 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id SAA12891 Posted-Date: Wed, 24 Sep 1997 18:01:15 +0200 (MET DST) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id MAA15904; Wed, 24 Sep 1997 12:04:52 -0400 for Message-Id: <3.0.32.19970924120126.006d5f64@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 24 Sep 1997 12:01:26 -0400 To: huitema@bellcore.com (Christian Huitema) From: Dimitry Haskin Subject: (IPng 4533) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2788 At 10:16 AM 9/24/97 -0400, Christian Huitema wrote: >Dimitry, Quaizar, > >One of the point that was agreed during the Munich meeting of IPv6 is that >Site Local addresses should not be used for EGP routing exchanges. The issue was not examined enough in Munich to beside one way or another. I for one, don't remember agreeing on this. >One of >the reasons is that nobody really knows what is a site, and that there is >absolutely zero reason to think that an AS is a single site. (My >personnal feeling is that site local addresses should not be used *at >all*, at least in a connected site, because they have all the properties >of Net 10 addresses). Think of what happens when a host or a router >belongs to several sites, which would be very easy in mobile environments. > I'm not ready to say (even if it has crossed my mind ;) that use of the local-scope addresses as the BGP next-hop will be sufficient in all possible cases. Nevertheless I clearly can see and have demonstrated how local-scope addresses can be used to our advantage in many non-exotic cases. At this point I'm just asking to relax the v6 BGP rules imposed on the NEXT_HOP address scope. This way we don't have to resolve philosophical or whatever dilemmas now but simply to experiment and see. Too much to ask? >There are two valid lines that can be pursued if we dump site local >addresses. The short term solution is "non renumbered addresses", i.e. an >address domain that is only used for interconnections, and is not >renumbered at the same time as either AS. There are two costs to this >solutions; one needs to allocate these specific domains, which is an >administrative cost, and one needs to carry host routes within the IGP for >the remote routers, which is an operational cost. Neither cost is >unbearable. Correct... Except that sites that can perfectly get away with the local-scope addresses don't have to bear that cost. Why to deny them that possibility? > >The longer term solution is to design renumbering support in the next EGP. > Next-hop is a local parameter, which is not propagated in the global >Internet. We should be able to update that parameter without triggering >Internet wide route swaps. If we do that, the cost is some additional >complexity in BGP, but we will not need special addresses and we will also >not need to carry host routes in the IGP. > > >-- >Christian Huitema Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 24 10:30:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA20277; Wed, 24 Sep 1997 10:19:23 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA20270; Wed, 24 Sep 1997 10:19:18 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id KAA12504 for ; Wed, 24 Sep 1997 10:19:17 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA04951; Wed, 24 Sep 1997 10:16:49 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA19578; Wed, 24 Sep 1997 03:04:27 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA02919; Wed, 24 Sep 1997 03:04:26 -0700 Received: from cesium.clock.org (cesium.clock.org [140.174.97.8]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id DAA29738 for ; Wed, 24 Sep 1997 03:04:25 -0700 Received: from smd@localhost by cesium.clock.org id <77211-150>; Wed, 24 Sep 1997 03:04:13 -0700 From: "Sean M. Doran" To: dhaskin@baynetworks.com, jgs@ieng.com Subject: (IPng 4534) Re: BGP and renumbering.. was /126 or /127 -- Cc: curtis@ans.net, idr@merit.edu, ipng@sunroof.eng.sun.com Message-Id: <19970924100413Z77211-150+3685@cesium.clock.org> Date: Wed, 24 Sep 1997 03:04:12 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1336 | Furthermore, if the floor is open for modifying the IBGP selection | procedure, I'd like to fix this problem in the general case rather | than applying further special-case kludges. Do we really want to | open this can of worms? Yes! The catharsis of the vendor-defined selection schemes is long overdue. Every iBGP implementation should allow people to configure precisely the type of bullet with which they will shoot themselves in the head when acquiring routes from iBGP, and from BGP in general. Nothing, including choosing the most specific available prefix, should be considered sacred in solving the general case. Then the only things wrong with BGP would be a/ terminology and b/ it's still a bag of vectors, no matter how you slice it. Sean. P.S., yes I am serious, and no I don't preclude people suggesting "appropriate" selection criteria or even "default" selection criteria in various places like standards documents or manuals. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 24 10:54:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA20323; Wed, 24 Sep 1997 10:39:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA20316; Wed, 24 Sep 1997 10:38:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA02372; Wed, 24 Sep 1997 10:38:46 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA05198 for ; Wed, 24 Sep 1997 10:38:25 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id KAA04695; Wed, 24 Sep 1997 10:37:45 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id KAA24457; Wed, 24 Sep 1997 10:24:43 -0700 (PDT) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id KAA09696; Wed, 24 Sep 1997 10:35:48 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id KAA01787; Wed, 24 Sep 1997 10:37:53 -0700 (PDT) Date: Wed, 24 Sep 1997 10:37:53 -0700 (PDT) Message-Id: <199709241737.KAA01787@lookout.nsd.3com.com> To: huitema@bellcore.com (Christian Huitema) Cc: Quaizar Vohra , Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4535) Re: BGP and renumbering.. was /126 or /127 -- neither! In-Reply-To: <970924101638.ZM10589@seawind.bellcore.com> References: <3.0.32.19970923165544.006d0c40@pobox> <199709232256.PAA01659@lookout.nsd.3com.com> <3.0.1.32.19970923195431.0069fc20@pobox> <199709240017.RAA01688@lookout.nsd.3com.com> <970924101638.ZM10589@seawind.bellcore.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3482 Christian, > Dimitry, Quaizar, > > One of the point that was agreed during the Munich meeting of IPv6 is that > Site Local addresses should not be used for EGP routing exchanges. One of > the reasons is that nobody really knows what is a site, and that there is > absolutely zero reason to think that an AS is a single site. (My > personnal feeling is that site local addresses should not be used *at > all*, at least in a connected site, because they have all the properties > of Net 10 addresses). Think of what happens when a host or a router > belongs to several sites, which would be very easy in mobile environments. > I would rather say that use site local addresses as long as you can. Use global addresses if you must. I fully agree with Dimitry that site local addresses are useful in some situations and one of them being BGP. I may not be fully aware of all the bad properties of site-local address, but one of them being pointed out is that an AS might be composed of multiple sites (i.e. multiple instances of site-local addressing). This happens for example when two organizations merge. In that case a good solution would be to run EBGP among such sites assigning a psuedo ASs to each such site and forming a confederation of pseudo ASs which is represented as a single AS outside. Administering the pseudo ASs is total an internal affair of the AS and is less impacting then renumbering. This does not imply that I am mandating this but I think that this will a cause for less pain. > There are two valid lines that can be pursued if we dump site local > addresses. The short term solution is "non renumbered addresses", i.e. an > address domain that is only used for interconnections, and is not > renumbered at the same time as either AS. There are two costs to this > solutions; one needs to allocate these specific domains, which is an > administrative cost, and one needs to carry host routes within the IGP for > the remote routers, which is an operational cost. Neither cost is > unbearable. I don't think there is a a great need for such "non renmbered addresses". As I have pointed out that all one needs is to propogate in the NEXT_HOP is the interface address of the local ebgp peer on the IX link without loosing any of the functionality provided by the NEXT_HOP attribute. This means that I can even use addresses from within the prefix assigned to the local ebgp speaker's AS. Since replacement of the NEXT_HOP can be done dynamically renumbering can at worst cause a black hole in the small period when the igp route to the new prefix of the IX link converges. > > The longer term solution is to design renumbering support in the next EGP. > Next-hop is a local parameter, which is not propagated in the global > Internet. We should be able to update that parameter without triggering > Internet wide route swaps. If we do that, the cost is some additional > complexity in BGP, but we will not need special addresses and we will also > not need to carry host routes in the IGP. > > > -- > Christian Huitema Quaizar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 24 11:05:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA20349; Wed, 24 Sep 1997 10:53:53 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA20342; Wed, 24 Sep 1997 10:53:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA07152; Wed, 24 Sep 1997 10:53:37 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA10582 for ; Wed, 24 Sep 1997 10:53:22 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA12830; Wed, 24 Sep 97 10:51:48 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id KAA02813; Wed, 24 Sep 1997 10:53:53 -0700 Date: Wed, 24 Sep 1997 10:53:53 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199709241753.KAA02813@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4536) Re: Update to RFC 2133 X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2121 Harvey, Jim, > > So what have we ended up with; something similar to gethostbyname(), but > disimilar enough such that applications would have to be rewritten > anyway; chaning struct hostent to struct dynhostent, changing gethostbyname > to the new function with the new arguments, adding freedynhostent() in the > right place(s), rewriting the code which previously assumed IPv4 only > addresses; so perhaps it's better if we force everyone to use > getaddrinfo/getnameinfo which are much cleaner interfaces anyway, with a > similar amount of pain (infact code often becomes simpler and clearer). > > This means less interfaces, which is less confusing to the developer, and > less implementation to go wrong. KISS! > > So despite what I've said, my vote goes for; > > 1. gethostbyname() would only return AF_INET > 2. NO gethostbyname2(). > 3. NO getdynhostent/gethostentafopt > 4. Add more AI_ options as required (AI_INET6_V4MAP?) > 5. IPv6 and MT applications use getaddrinfo() > Even though I am not a resolver library expert I tend to agree with this conclusion. The only reasonable counter argument would be that there are existing applications which are coded in such a way as to make it difficult to add the appropriate freeing of the storage associated with a getaddrinfo/ gethostentafopt/getdynhostent call. This would argue for gethostbyname return- ing AF_INET6 addresses or for having a gethostbyname2. Both these solutions have their problems. In looking through the current version of the X/Open documents I don't see documentation for getaddrinfo. Is it the case that X/Open has not adopted getaddrinfo? Will they be adopting getaddrinfo? Are they trying to create their own wheel? Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 24 14:48:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20592; Wed, 24 Sep 1997 14:36:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20585; Wed, 24 Sep 1997 14:36:35 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA07900; Wed, 24 Sep 1997 14:36:32 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA20874 for ; Wed, 24 Sep 1997 14:36:18 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id RAA29139; Wed, 24 Sep 1997 17:25:25 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA06659; Wed, 24 Sep 1997 17:25:24 -0400 Message-Id: <9709242125.AA06659@wasted.zk3.dec.com> X-Mailer: exmh version 1.6.7 5/3/96 To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com, masha@zk3.dec.com Subject: (IPng 4537) Re: Update to RFC 2133 In-Reply-To: Your message of "Wed, 24 Sep 1997 10:53:53 PDT." <199709241753.KAA02813@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Sep 1997 17:25:24 -0400 From: Maria Stanley X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1618 Tim, > In looking through the current version of the X/Open documents I don't >see documentation for getaddrinfo. Is it the case that X/Open has not adopted >getaddrinfo? Will they be adopting getaddrinfo? Are they trying to create >their own wheel? No. XNET (Networking Group at The Open Group) is aware that iping is still trying to work out the issues with address resolution functions in the base API. We are open to consider getaddrinfo() routine for inclusion into XNS, especially if it becomes part of the iping's solution for thread safe address resolution you are currently trying to find. Our intention is to adopt the spec and not to invent it, and therefore we will wait for your solution; if we have any comments, sugeestions or problems with it, we will communicate them to you. Regards, M. Stanley. ____________________________________________________________________________ Maria Stanley Digital Equipment Corporation IPv6 Development 110 Spit Brook Road Memeber of XNET at The Open Group Nashua, NH 03062, USA masha@zk3.dec.com +1 (603) 884-0382 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 11:29:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA21207; Thu, 25 Sep 1997 11:19:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA21200; Thu, 25 Sep 1997 11:19:18 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA07649; Thu, 25 Sep 1997 11:19:15 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA17671 for ; Thu, 25 Sep 1997 11:19:02 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id OAA00733; Thu, 25 Sep 1997 14:18:50 -0400 (EDT) Message-Id: <199709251818.OAA00733@brookfield.ans.net> To: Dimitry Haskin cc: curtis@ans.net, ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4539) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Tue, 23 Sep 1997 12:32:30 EDT." <3.0.32.19970923123217.0068b130@pobox> Date: Thu, 25 Sep 1997 14:18:50 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3165 In message <3.0.32.19970923123217.0068b130@pobox>, Dimitry Haskin writes: > Curtis, > > > > >The remote AS routers are on direct interfaces of your own router and > >normally direct interfaces are included in the IGP. The only case > >where this gets a bit sticky is PTP links in BSD/gated style where the > >two ends of the PTP link are not restricted to the same subnet. This > >is still OK if the IGP includes both ends of the PTP link to be in the > >IGP. It only a problem for unnumbered PTP links (which don't see much > >use in this sort of application since other things like SNMP > >monitoring get unhappy with no address). > > > > In IPv6 it becomes a bit sticky on all types of directs links due to the > desire to reduce re-numbering impact of one V6 site on other V6 sites > ("site" is a more appropriate term than "AS" here but you can mentally > replace it with "AS" for the discussion at hand). The IPv6 addressing > architecture allows two sites to have own independent subnets on the same > link. If one site (AS) injects a subnet administrated by another site in > its IGP, it becomes dependent on that site address administration. One > solution would be to assign a separate DMZ address prefix that can't be > renumbered by either site and is not globally advertised but it would > require someone to administer such assignments. Another solution would be > to refrain from injecting another site's address prefix into the local IGP. > > >Curtis > > > Dimitry Dimitry, I think what is missing is the concept of a border interface which is in neither "site". An IX does not below to any of the 50 or so AS that sit on that interface and would not be renumbered with the site. You cannot renumber one end of a BGP connection and keep the BGP connection up. Even if you did renumber a "site" you'd have to keep two sets of numbers and then reconfig one end to allow connections to/from either sets of numbers and then reconfig the other end to switch from the old address to the new. This would be minimally disruptive. We're not talking about renumbering the secretarial pool or a bunch of laptops here. Routers running BGP have different requirements to meet. [ semi-unrelated: BTW- If we wanted to make this non-diruptive you'd need some way to indicate a CEASE that would involve keeping the BGP routes on a timer so another establish can be made. I proposed something a while back and it was rejected. I see that now Cisco has implemented a soft reset on a BGP peer (which will be soft on one end only unless there is a delay before sending the cease long enough to hit return on two routers before either one sees a cease from the other). Maybe it's time to revisit that idea since the vendor that opposed it has implemented it. ] Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 11:53:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA21234; Thu, 25 Sep 1997 11:40:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA21227; Thu, 25 Sep 1997 11:40:16 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA13985; Thu, 25 Sep 1997 11:40:13 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA24644 for ; Thu, 25 Sep 1997 11:40:04 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id OAA00845; Thu, 25 Sep 1997 14:39:58 -0400 (EDT) Message-Id: <199709251839.OAA00845@brookfield.ans.net> To: Dimitry Haskin cc: curtis@ans.net, ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4540) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Tue, 23 Sep 1997 14:30:28 EDT." <3.0.32.19970923142940.00714894@pobox> Date: Thu, 25 Sep 1997 14:39:57 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3352 In message <3.0.32.19970923142940.00714894@pobox>, Dimitry Haskin writes: > >> > >> If this is right then why not introduce another attribute which > >> carries the link cost of the IX link/path. > > > >Because the protocol already covers this case. Why remove the > >functionality and put it some other place. You would then have to > >determine the total cost by adding the IGP cost to the new BGP > >attribute. This would be true for all IGPs and a pain to implement. > > > I don't agree that it will be necessary to use the new BGP attribute in all > IGPs -- at least no more that you'd used MED or LocPref outside of IBGP. > This would be normally used for route selection when IBGP "hack" is on and > external routes are not injected into IGP. The point is not to change things such that the computation that is made by a router which ignores that attribute could result in a route loop. If you add a value from a new BGP attribute to the IGP cost (which was the proposed "solution" to not having the IGP cost of the border interface if the near end router replaces the next-hop with its own address) then route loops can form. The protocol already accommodates that last hop cost so don't break the functionality and then fix it in a way that is incompatible with current practice. > >> For IPv6 this will atleast remove the need for administering > >> assignment of global IPv6 subnet prefix to the DMZ links, or global IPv6 > >> addresses to the ebgp peers on their IX interfaces. > >> > >> Quaizar > > > >BGP is not going to be used on dynamicly assigned subnets. Period. > >No matter how much the IPv6 research community loves the feature. > > > >Provider routers don't even run DNS so their reliability is not > >reduced by a dependency on something external to the router. > > > The point it that in many cases it would be beneficial not assign > global-scope addresses to external BGP links at all. Unlike v4, v6 has > different scope addresses that would be nice to take advantage of to reduce > administrative and renumbering burdens. In case of EBGP, link-local > addresses may be sufficient enough. This argument borders on being silly. Routers that are running EBGP are not going to be renumbered without a coordinated effort and are not going to be accepting a dynamically assigned address, whether IPv4 or IPv6. The very fact that a router is running EBGP means that it is sitting on an administrative boundary. Keeping the prefix at the boundary staticly allocated is no big deal. For example: we use subnet's of an MCI aggregate for private peerings. We have those subnets in our IGP (no big deal). If MCI ever renumbered (**not very likely**) we'd expect them to keep the DMZ addresses constant and renumber those independently. The same applies for a border with a small multihomed customer. They can renumber their site but they had better coordinate renumbering the DMZ because it is not theirs alone to renumber. Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 13:24:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21422; Thu, 25 Sep 1997 13:06:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21415; Thu, 25 Sep 1997 13:05:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA06187; Thu, 25 Sep 1997 13:05:47 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA21666 for ; Thu, 25 Sep 1997 13:05:10 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id QAA01130; Thu, 25 Sep 1997 16:04:34 -0400 (EDT) Message-Id: <199709252004.QAA01130@brookfield.ans.net> To: Dimitry Haskin cc: Quaizar Vohra , curtis@ans.net, ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4541) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Tue, 23 Sep 1997 16:56:59 EDT." <3.0.32.19970923165544.006d0c40@pobox> Date: Thu, 25 Sep 1997 16:04:33 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2891 In message <3.0.32.19970923165544.006d0c40@pobox>, Dimitry Haskin writes: > Quaizar, > > > > >>From your's and Dimitry's reason I now understand better why > >it is difficult to introduce this new attribute. > > > >We might still avoid passing the remote peer's global address > >into local AS by using Dimitry's proposal of using link-local > >addresses in EBGP NEXT_HOPs and rewriting the NEXT_HOPs with > >a AS-local IPV6 address before readvertising it in IBGP and > >ensuring that the cost of the IX link could also get accounted for. > >This could be done by using the AS-local IPV6 address assigned to > >the border router on the IX link in the NEXT_HOP attribute. > > > > You just made a very important observation. You are right: we can account > for the cost of an IX link without introducing a new attribute. Let me > depict it so it is crisp and clear. > > 1 1 > A1 -----s1 B1---------B4 > IX | > 5 1 |1 > A2 -----s2 B2---------B3 > IX > > Routers A* are in one AS, routers B* are in another AS. A1 and B1, and A2 > and B2 exchange routes via EBGP respectively. When B1 readvertises A1's > routes to its internal BGP peers it uses a site-local address of its > interface on IX link to A1, say s1, as the NEXT_HOP, and B2 uses a > site-local address of its interface on the IX link to A2, say s2, as the > NEXT_HOP. If external BGP routes are injected into IGP as ASE routes, the > same site-local addresses, s1 and s2, are specified as forwarding > addresses. Both s1 and s2 are injected into IGP with the costs of their > respective link, i.e. 1 and 5 respectively. Now costs of the IX link are > fully accounted in route selection. > > In the above diagram, if the same external network is reachable via either > border router, every B* sends packets to that external network via the > B1/A1 link as a lower cost path. AS-B injects BGP into OSPF ASEs? !!! Are we forgetting about the AS path truncation problems and the severe scaling problems with many implementations? Router A1 and B1 must have an inteface that shares a common subnet. If so that prefix is in both IGPs of A and B. The BGP routes are never injected into the IGP. A renumbering of the subnet containing A1 and B1 would have to involve both A1 and B1 having two addresses (aliases) during the transition. They would both end up on the same subnet when the process is done and again the subnet is in both IGPs. Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 13:29:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21431; Thu, 25 Sep 1997 13:10:37 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21424; Thu, 25 Sep 1997 13:10:27 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA07277; Thu, 25 Sep 1997 13:10:24 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA23267 for ; Thu, 25 Sep 1997 13:10:15 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id NAA08879; Thu, 25 Sep 1997 13:09:03 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id MAA05469; Thu, 25 Sep 1997 12:55:49 -0700 (PDT) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id NAA17143; Thu, 25 Sep 1997 13:07:07 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id NAA02031; Thu, 25 Sep 1997 13:09:14 -0700 (PDT) Date: Thu, 25 Sep 1997 13:09:14 -0700 (PDT) Message-Id: <199709252009.NAA02031@lookout.nsd.3com.com> To: curtis@ans.net Cc: Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4542) Re: BGP and renumbering.. was /126 or /127 -- neither! In-Reply-To: <199709251839.OAA00845@brookfield.ans.net> References: <3.0.32.19970923142940.00714894@pobox> <199709251839.OAA00845@brookfield.ans.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2221 > > The point is not to change things such that the computation that is > made by a router which ignores that attribute could result in a route > loop. > > If you add a value from a new BGP attribute to the IGP cost (which was > the proposed "solution" to not having the IGP cost of the border > interface if the near end router replaces the next-hop with its own > address) then route loops can form. The protocol already accommodates > that last hop cost so don't break the functionality and then fix it in > a way that is incompatible with current practice. I think we all agree on that > > This argument borders on being silly. > > Routers that are running EBGP are not going to be renumbered without a > coordinated effort and are not going to be accepting a dynamically > assigned address, whether IPv4 or IPv6. > > The very fact that a router is running EBGP means that it is sitting > on an administrative boundary. Keeping the prefix at the boundary > staticly allocated is no big deal. For example: we use subnet's of an > MCI aggregate for private peerings. We have those subnets in our IGP > (no big deal). If MCI ever renumbered (**not very likely**) we'd > expect them to keep the DMZ addresses constant and renumber those > independently. You are very much right. But in IPv6 renumbering being the very basis of scalable routing is expected for even a large ISP. So the DMZ addresses coming from a site's global IPv6 prefix are not going to be static as in IPv4. Dimitry suggested using link-local IPv6 addresses which are *NOT DYNAMIC* and are always static. Quaizar > > The same applies for a border with a small multihomed customer. They > can renumber their site but they had better coordinate renumbering the > DMZ because it is not theirs alone to renumber. > > Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 13:47:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21459; Thu, 25 Sep 1997 13:35:05 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21452; Thu, 25 Sep 1997 13:34:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA14034; Thu, 25 Sep 1997 13:34:44 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA00682 for ; Thu, 25 Sep 1997 13:34:19 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id NAA11676; Thu, 25 Sep 1997 13:33:41 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id NAA08410; Thu, 25 Sep 1997 13:20:27 -0700 (PDT) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id NAA17886; Thu, 25 Sep 1997 13:31:45 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id NAA02038; Thu, 25 Sep 1997 13:33:52 -0700 (PDT) Date: Thu, 25 Sep 1997 13:33:52 -0700 (PDT) Message-Id: <199709252033.NAA02038@lookout.nsd.3com.com> To: curtis@ans.net Cc: Dimitry Haskin , Quaizar Vohra , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4543) Re: BGP and renumbering.. was /126 or /127 -- neither! In-Reply-To: <199709252004.QAA01130@brookfield.ans.net> References: <3.0.32.19970923165544.006d0c40@pobox> <199709252004.QAA01130@brookfield.ans.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4248 Curtis Villamizar writes: > > In message <3.0.32.19970923165544.006d0c40@pobox>, Dimitry Haskin writes: > > Quaizar, > > > > > > > >>From your's and Dimitry's reason I now understand better why > > >it is difficult to introduce this new attribute. > > > > > >We might still avoid passing the remote peer's global address > > >into local AS by using Dimitry's proposal of using link-local > > >addresses in EBGP NEXT_HOPs and rewriting the NEXT_HOPs with > > >a AS-local IPV6 address before readvertising it in IBGP and > > >ensuring that the cost of the IX link could also get accounted for. > > >This could be done by using the AS-local IPV6 address assigned to > > >the border router on the IX link in the NEXT_HOP attribute. > > > > > > > You just made a very important observation. You are right: we can account > > for the cost of an IX link without introducing a new attribute. Let me > > depict it so it is crisp and clear. > > > > 1 1 > > A1 -----s1 B1---------B4 > > IX | > > 5 1 |1 > > A2 -----s2 B2---------B3 > > IX > > > > Routers A* are in one AS, routers B* are in another AS. A1 and B1, and A2 > > and B2 exchange routes via EBGP respectively. When B1 readvertises A1's > > routes to its internal BGP peers it uses a site-local address of its > > interface on IX link to A1, say s1, as the NEXT_HOP, and B2 uses a > > site-local address of its interface on the IX link to A2, say s2, as the > > NEXT_HOP. If external BGP routes are injected into IGP as ASE routes, the > > same site-local addresses, s1 and s2, are specified as forwarding > > addresses. Both s1 and s2 are injected into IGP with the costs of their > > respective link, i.e. 1 and 5 respectively. Now costs of the IX link are > > fully accounted in route selection. > > > > In the above diagram, if the same external network is reachable via either > > border router, every B* sends packets to that external network via the > > B1/A1 link as a lower cost path. > > > > AS-B injects BGP into OSPF ASEs? !!! Are we forgetting about the AS > path truncation problems and the severe scaling problems with many > implementations? > > Router A1 and B1 must have an inteface that shares a common subnet. > If so that prefix is in both IGPs of A and B. The BGP routes are > never injected into the IGP. > > A renumbering of the subnet containing A1 and B1 would have to involve > both A1 and B1 having two addresses (aliases) during the transition. > They would both end up on the same subnet when the process is done and > again the subnet is in both IGPs. > > Curtis Talking specifically about IPv6 (not applicable to IPv4): Routers A1 and B1 have an interface which is on a common layer 2 link. They need not share a global IPv6 prefix. They can do peering using their link-local IPv6 addresses (if BGP is run over TCP/IPv6). They can also assign their respective interfaces on the common link using their own site local prefixes. These site-local prefixes travel in the respective IGPs and hence allows accounting for the cost of the common link. The current proposal (Dimitry's) is to allow (not mandate) passing of just link-local IPv6 addresses in EBGP NEXT_HOP attribute which gets replaced by the site-local IPv6 address of the interface allocated by the local AS on the common ebgp link when readvertised in IBGP. Link local addresses have the property of being static forever (practically). This has the potential advantage of not assigning a global IPv6 prefix on the common ebgp link. Which would not be static if it comes from either ASs (as ASs are likely to renumber in IPv6 more often) OR would have to come from an administrtive body specially setup to allocate static global IPv6 address. Quaizar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 14:15:09 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA21529; Thu, 25 Sep 1997 14:03:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA21520; Thu, 25 Sep 1997 14:01:19 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA24685; Thu, 25 Sep 1997 14:01:11 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA08708 for ; Thu, 25 Sep 1997 14:01:04 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id OAA15379; Thu, 25 Sep 1997 14:00:19 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id NAA12228; Thu, 25 Sep 1997 13:47:06 -0700 (PDT) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id NAA18800; Thu, 25 Sep 1997 13:58:23 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id OAA02051; Thu, 25 Sep 1997 14:00:30 -0700 (PDT) Date: Thu, 25 Sep 1997 14:00:30 -0700 (PDT) Message-Id: <199709252100.OAA02051@lookout.nsd.3com.com> To: Pedro Marques Cc: Quaizar Vohra , curtis@ans.net, ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4544) Re: BGP and renumbering.. was /126 or /127 -- neither! In-Reply-To: <199709252040.NAA07549@pedrom-ultra.cisco.com> References: <3.0.32.19970923142940.00714894@pobox> <199709251839.OAA00845@brookfield.ans.net> <199709252009.NAA02031@lookout.nsd.3com.com> <199709252040.NAA07549@pedrom-ultra.cisco.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2296 > > Quaizar, > That is a religion that not everybody professes. And until it is proven that > it can be done and that it is actually a good idea some people will just > consider that "the very basis of scalable routing" is just wishful thinking. Maybe I had a religious tone :-). I would agree that I would try avoiding renumbering as long as it is possible. If it becomes necessary because I want something else more then I will accept it. > > Quaizar> So the DMZ addresses coming from a site's > Quaizar> global IPv6 prefix are not going to be static as in > Quaizar> IPv4. Dimitry suggested using link-local IPv6 addresses > Quaizar> which are *NOT DYNAMIC* and are always static. > > Until you have to upgrade your router or switch whatever piece of harwdware > that holds the MAC tokens... that would make hardware upgrades really fun. If I were an administrator I will use my EID part in such cases as fixed numbers (not MAC tokens). Even if global IPv6 prefixes were used on the subnet with MAC tokens you have the same problem. > > Link local address cannot be in DNS either... and since they all look > pretty much the same that will make looking into your 40 peer configuration > another interestening exercise. > > Fixed scope unicast addresses is something that IPv6 introduces that wasn't > present in IPv4. It is still to be seen if they really do solve more problems > than they do create. In IPv4 you have, presently, no strict relationship > between an address and it's routing scope... there are a couple of useful > address assigment conventions but as far as the protocols are concerned an > addresses is an address. Extremely simple... fixed scope addresses bring us > some rules on the necessary scope of addresses that actually make things > less flexible. > > Pedro. Well they might solve a problem here if you will allow. Quaizar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 15:02:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA21563; Thu, 25 Sep 1997 14:48:16 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA21556; Thu, 25 Sep 1997 14:48:03 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA10295; Thu, 25 Sep 1997 14:48:01 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA22526 for ; Thu, 25 Sep 1997 14:47:52 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id RAA01603; Thu, 25 Sep 1997 17:47:45 -0400 (EDT) Message-Id: <199709252147.RAA01603@brookfield.ans.net> To: Dimitry Haskin cc: Quaizar Vohra , ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4545) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Tue, 23 Sep 1997 19:54:31 EDT." <3.0.1.32.19970923195431.0069fc20@pobox> Date: Thu, 25 Sep 1997 17:47:45 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2789 In message <3.0.1.32.19970923195431.0069fc20@pobox>, Dimitry Haskin writes: > > For purpose of our discussions, a site is a collection of v6 interfaces > that get their addresses allocated from a single set (aggregate) of site > local addresses (SLA). That has little to do with geography. [It is > conceivable albeit probably unlikely for a site to consist from multiple > ASs but not vise versa.] As I stated earlier in the discussion, I don't see > how multiple sites can form a single IGP domain (aka AS). You need to run > EGP (EBGP in this case) between sites. Naturally, since you running EBGP > between sites, the NEXT_HOP changes as routes cross site boundaries. How about if we dispense with the acedemic nonsense and inject some reality into the discussion. BGP is used in situations where there are multiple administrative domains and multiple borders between those domains and/or where an IGP would no longer scale. These "sites" are beyond the size where anyone is willing to dynamicly reallocate and therefore trigger renumbering. For example, I would not expect a peer provider to take an address assignment from us through a dynamic protocol and trigger renumbering of their entire infrastruscture and all of their customers. I wouldn't expect most customers to ever agree to this. Providers infrastructure numbering is always fixed. A rule of thumb is to never have any dependency on a higher level service prevent a network element from doing its job. No dependency on DNS. No dependency on anything to get interface numbering. I really don't expect that to change. I'd be very surprised if within an organization more than perhaps a building or major department dynamicly numbered. In practice, this is a granularity much smaller than an AS. This is why the whole argument seems silly. If numbers are dynamicly assigned and EBGP peers do not share a common subnet on a direct interface then it should be OK for a replacement of next hop to be allowed in the BGP protocol. If there are N AS on a subnet and the local subnet cost was needed, then each border router on that subet would need N addresses, one for each "site". This is a non-issue since it won't ever be used. In practice that shared subnet would have a fixed prefix and that one fixed prefix would be injected in each IGP by virtue of being a subnet on a direct interface of a router in that IGP. Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 15:37:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA21759; Thu, 25 Sep 1997 15:20:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA21752; Thu, 25 Sep 1997 15:19:57 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA21670; Thu, 25 Sep 1997 15:19:54 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA02264 for ; Thu, 25 Sep 1997 15:19:46 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id SAA01671; Thu, 25 Sep 1997 18:19:41 -0400 (EDT) Message-Id: <199709252219.SAA01671@brookfield.ans.net> To: Dimitry Haskin cc: curtis@ans.net, ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4546) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Tue, 23 Sep 1997 20:23:59 EDT." <3.0.1.32.19970923202359.006a9f20@pobox> Date: Thu, 25 Sep 1997 18:19:40 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3007 In message <3.0.1.32.19970923202359.006a9f20@pobox>, Dimitry Haskin writes: > > > I believe we agree on that. To boot, we'd like to achieve it without > granting permanent ownership of global-scope addresses or imposing undue > renumbering dependencies between independently administered sites. To this > end, we try to utilize v6 local scope addresses -- something that is > missing in the V4 addressing architecture (well.. except v4 private use > addresses which are useless for the problem at hand). V4 private numbering at IX has come up as a real suggestion. If I want to reach another provider's address I'd have to do so using the loopback address (terminology varies with some using virtual). This would be fine when routing was up. Each provider would have the subnet address in the IGP but pass that no further. No two exchanges could use the same space, but there aren't that many exchanges to worry about. A potential failure here is that a provider's NOC may want to ping the far end interface to distinguish between a peering going down and a router disappearing completely. This is an important distinction if you are in network operations because it determines the next action of the NM software, the type of alert, and the action of the NOC personnel. [If a peering is down, you have to assume that it could be your own BGP. If a router is not pingable but all others on the interface are, for a while you can assume that the problem is in the other router but if it persists call the other provider and don't rule out the possibility of a hideous level 2 problem]. The same functionality is lost with IPv6 local scope addresses unless those addresses can be propogated all the way back to the NOC of every provider that participates at the exchange. My understanding is that IPv6 local scope addresses would no provide that. BTW- In both cases source routing to your own router or to within your own infrastructure and using the private address would work for the purpose of determining reachability. The addresses of IXs would still have to be non-unique and therefore still not truely local. Curtis ps- what century do you plan to start deploying IPv6 in? For real rather than 6bone? If I didn't think you were serious about renumbering an entire AS dynamically I'd ROTFL. Maybe in some future Internet that no longer vaguely resembles this one. For starters, you can only renumber an IPv4 free entity. I don't see there being very many IPv4 free entities as large as an AS is today. In fact, by the time that ever happens I'd expect BGP to be substantially different or historic. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 15:44:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA21790; Thu, 25 Sep 1997 15:26:05 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA21769; Thu, 25 Sep 1997 15:24:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA23429; Thu, 25 Sep 1997 15:24:14 -0700 Received: from mailhost1.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA03518 for ; Thu, 25 Sep 1997 15:24:06 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id PAA24143 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id PAA03146 Posted-Date: Thu, 25 Sep 1997 15:23:54 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id SAA13550; Thu, 25 Sep 1997 18:23:54 -0400 for Message-Id: <3.0.32.19970925182031.006dfec8@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 25 Sep 1997 18:20:32 -0400 To: Pedro Marques From: Dimitry Haskin Subject: (IPng 4547) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 791 At 02:14 PM 9/25/97 -0700, Pedro Marques wrote: >The discussion so far as been on what to carry on a EBGP peering on a direct >link and my proposal doesn't restrict anyone from doing anything they wish. I don't get why it so difficult to understand but you're forcing one to assign a global address to the IX interface. That hardly qualifies as "doesn't restrict anyone from doing anything they wish". Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 15:58:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA21861; Thu, 25 Sep 1997 15:42:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA21854; Thu, 25 Sep 1997 15:41:58 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA29217; Thu, 25 Sep 1997 15:41:51 -0700 Received: from brittany.cisco.com (brittany.cisco.com [171.69.1.168]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA08813 for ; Thu, 25 Sep 1997 15:41:23 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by brittany.cisco.com (8.6.12/8.6.5) with ESMTP id PAA21889; Thu, 25 Sep 1997 15:41:21 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA07654; Thu, 25 Sep 1997 15:41:21 -0700 (PDT) Date: Thu, 25 Sep 1997 15:41:21 -0700 (PDT) Message-Id: <199709252241.PAA07654@pedrom-ultra.cisco.com> From: Pedro Marques To: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4548) Re: BGP and renumbering.. was /126 or /127 -- neither! In-Reply-To: <3.0.32.19970925182031.006dfec8@pobox> References: <3.0.32.19970925182031.006dfec8@pobox> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1429 >>>>> "Dimitry" == Dimitry Haskin writes: Dimitry> At 02:14 PM 9/25/97 -0700, Pedro Marques wrote: >> The discussion so far as been on what to carry on a EBGP >> peering on a direct link and my proposal doesn't restrict >> anyone from doing anything they wish. Dimitry> I don't get why it so difficult to understand but you're Dimitry> forcing one to assign a global address to the IX Dimitry> interface. That hardly qualifies as "doesn't restrict Dimitry> anyone from doing anything they wish". That doesn't mean the peer or the interior routers of the peering AS have to actually be able to route to that address which seams to be your objection in the first place. In other words, the point your are trying to make about renumbering isn't in my opinion valid because you can configure things to do what you want. We have to proposals: one is a superset of the other. And i don't believe you have proven that the difference in capabilities you want to dismiss is not useful. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 16:28:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA21941; Thu, 25 Sep 1997 16:19:39 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA21934; Thu, 25 Sep 1997 16:19:26 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA14925; Thu, 25 Sep 1997 16:19:23 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA20193 for ; Thu, 25 Sep 1997 16:19:10 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id TAA01902; Thu, 25 Sep 1997 19:18:55 -0400 (EDT) Message-Id: <199709252318.TAA01902@brookfield.ans.net> To: huitema@bellcore.com (Christian Huitema) cc: Quaizar Vohra , Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4549) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Wed, 24 Sep 1997 10:16:38 EDT." <970924101638.ZM10589@seawind.bellcore.com> Date: Thu, 25 Sep 1997 19:18:55 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2657 In message <970924101638.ZM10589@seawind.bellcore.com>, Christian Huitema write s: > > The longer term solution is to design renumbering support in the next EGP. Not very tough if you can have two addresses during transition. All BGP needs is to allow a timer on routes after the CEASE. If after the CEASE the same peering came up with a different pair of addresses and announced all of the routes before the timer expired there would be no disruption of service. During the period when the shared interface has two prefixes there should be two IGP routes for the interface being renumbered, one for each address on the local interface. After the BGP transition, one number is removed from the interface and one IGP route goes away. Here's the whole procedure: 1. add inteface alias to both all peers. since there are multiple parties this could occur over days or longer. 2. some time passes after the address is added (something like 60 seconds). 3. the IGP route for the new interface address is propogated. 4. routers are reconfigured to accept BGP peerings on either interface (passive) but the old peering is still active. 5. One end of the BGP peering is "bumped" by configuring the old peering down and the new one active. AS long as routes are not withdrawn immediately on the cease this is OK. 6. The routes are reannounced on the new peering. The next hop is different. 7. The new next hop is propogated to IBGP peers. Since AS path and other attributes have not changed there is no need to propogate further unless there is a level 2 shortcut attribute that also changed with the address change. 8. Since the IGP reachability to either alias on the interface is the same, all decisions still come out the same and no FIB change is required. 9. The unused address can be removed some time after all of the peerings have been changed. With it goes the IGP route. This could be done with IPv4 as long as there is a way to send a CEASE that results in putting the routes on a withdrawl timer rather than immmediately withdrawing them. You could even static configure the BGP peering for this behavior and not change the protocol at all. Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 16:55:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA22007; Thu, 25 Sep 1997 16:44:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA22000; Thu, 25 Sep 1997 16:44:37 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA25373; Thu, 25 Sep 1997 16:44:33 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA27713 for ; Thu, 25 Sep 1997 16:44:14 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id TAA02018; Thu, 25 Sep 1997 19:44:07 -0400 (EDT) Message-Id: <199709252344.TAA02018@brookfield.ans.net> To: Dimitry Haskin cc: huitema@bellcore.com (Christian Huitema), ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4550) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Wed, 24 Sep 1997 12:01:26 EDT." <3.0.32.19970924120126.006d5f64@pobox> Date: Thu, 25 Sep 1997 19:44:07 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2070 In message <3.0.32.19970924120126.006d5f64@pobox>, Dimitry Haskin writes: > > I'm not ready to say (even if it has crossed my mind ;) that use of the > local-scope addresses as the BGP next-hop will be sufficient in all > possible cases. Nevertheless I clearly can see and have demonstrated how > local-scope addresses can be used to our advantage in many non-exotic > cases. At this point I'm just asking to relax the v6 BGP rules imposed on > the NEXT_HOP address scope. This way we don't have to resolve > philosophical or whatever dilemmas now but simply to experiment and see. > Too much to ask? Yes! You need another attribute if you want to put an address in that is off subnet. Routing protocol features which are semantically identical for IPv4 and IPv6 are a good thing where possible and backward compatibility with existing BGP4 implementations is needed for IPv4. The harder you make the transition the longer it will be before IPv6 deployment is anything more than a toy. It makes sense to avoid complicating the transition if you don't have a really good reason to do so and IMHO you don't have any good reason at all to use NEXT_HOP rather than another attribute. BTW- In paractice, this rule is already relaxed for multihop EBGP with non-local addresses and a TTL applied to the peering, but multihop EBGP is considered a hack for research peerings (test out routing code) and to work around level 2 brain damage (when routers must be sort of bridged when they don't support a common media and encapsulation - for example RFC1490 and RFC1483 encapsulation on ATM requiring a intermediate router that supports both). It can also be a very problematic hack. Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 17:25:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA22116; Thu, 25 Sep 1997 17:12:40 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA22103; Thu, 25 Sep 1997 17:12:24 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA07495; Thu, 25 Sep 1997 17:12:18 -0700 Received: from mailhost2.BayNetworks.COM ([134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id RAA05855 for ; Thu, 25 Sep 1997 17:12:16 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost2.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id RAA11554 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id RAA08040 Posted-Date: Thu, 25 Sep 1997 17:12:09 -0700 (PDT) Received: from dhaskin.baynetworks.com ([192.32.95.176]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id UAA18606; Thu, 25 Sep 1997 20:12:09 -0400 for Message-Id: <3.0.1.32.19970925201034.006abda4@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 25 Sep 1997 20:10:34 -0400 To: Pedro Marques From: Dimitry Haskin Subject: (IPng 4551) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <199709252241.PAA07654@pedrom-ultra.cisco.com> References: <3.0.32.19970925182031.006dfec8@pobox> <3.0.32.19970925182031.006dfec8@pobox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2019 At 03:41 PM 9/25/97 -0700, Pedro Marques wrote: >>>>>> "Dimitry" == Dimitry Haskin writes: > > Dimitry> At 02:14 PM 9/25/97 -0700, Pedro Marques wrote: > >> The discussion so far as been on what to carry on a EBGP > >> peering on a direct link and my proposal doesn't restrict > >> anyone from doing anything they wish. > > Dimitry> I don't get why it so difficult to understand but you're > Dimitry> forcing one to assign a global address to the IX > Dimitry> interface. That hardly qualifies as "doesn't restrict > Dimitry> anyone from doing anything they wish". > >That doesn't mean the peer or the interior routers of the peering AS have >to actually be able to route to that address which seams to be your objection >in the first place. Yes, I've pointed out that the global-scope nexthop is unnecessary in many cases. In such a case I would like to be spared from the burden of configuring and administering global addresses on my IX interfaces. This addresses have no value to me. > >In other words, the point your are trying to make about renumbering isn't >in my opinion valid because you can configure things to do what you want. > >We have to proposals: one is a superset of the other. And i don't believe you >have proven that the difference in capabilities you want to dismiss is not >useful. > And what capability do I dismiss? You still can advertise you global addresses all you want. I assume that you view my proposal as a superset of yours, don't you? It addition to your set it requires less address administration effort in most typical cases. > Pedro. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 17:25:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA22117; Thu, 25 Sep 1997 17:12:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA22101; Thu, 25 Sep 1997 17:12:13 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA07311; Thu, 25 Sep 1997 17:11:44 -0700 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA05698 for ; Thu, 25 Sep 1997 17:11:31 -0700 Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id RAA18008; Thu, 25 Sep 1997 17:10:51 -0700 (PDT) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id RAA05909; Thu, 25 Sep 1997 17:10:44 -0700 (PDT) Message-Id: <199709260010.RAA05909@base.juniper.net> To: curtis@ans.net cc: huitema@bellcore.com (Christian Huitema), Quaizar Vohra , Dimitry Haskin , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4552) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Thu, 25 Sep 1997 19:18:55 EDT." <199709252318.TAA01902@brookfield.ans.net> Date: Thu, 25 Sep 1997 17:10:44 -0700 From: Paul Traina Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 942 From: Curtis Villamizar Subject: Re: (IPng 4522) Re: BGP and renumbering.. was /126 or /127 -- neithe >>r! This could be done with IPv4 as long as there is a way to send a CEASE that results in putting the routes on a withdrawl timer rather than immmediately withdrawing them. You could even static configure the BGP peering for this behavior and not change the protocol at all. A cease with a sanely limited short timer is a damn fine swiss-army knife for solving a lot of problems. I feel an ID coming on. :-) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 17:55:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA22205; Thu, 25 Sep 1997 17:44:30 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA22198; Thu, 25 Sep 1997 17:43:48 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA17692; Thu, 25 Sep 1997 17:42:50 -0700 Received: from mailhost1.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id RAA14007 for ; Thu, 25 Sep 1997 17:42:50 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id RAA28779 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id RAA09528 Posted-Date: Thu, 25 Sep 1997 17:42:13 -0700 (PDT) Received: from dhaskin.baynetworks.com ([192.32.95.176]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id UAA20562; Thu, 25 Sep 1997 20:42:08 -0400 for Message-Id: <3.0.1.32.19970925204033.006abda4@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 25 Sep 1997 20:40:33 -0400 To: curtis@ans.net, Dimitry Haskin From: Dimitry Haskin Subject: (IPng 4553) Re: BGP and renumbering.. was /126 or /127 -- neither! Cc: ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: <199709252344.TAA02018@brookfield.ans.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2923 Curtis, With all my respect, I'm not sure what you are talking about. I feel that you comments are out of context of the argument at hand. We are discussing the use of the nexthop that is specified in the MP_REACH_NLRI attribute in the IPv6 context. Is it what you're talking about too? Dimitry P.S. BTW, no one has proposed to use off subnet address as the nexthop. At 07:44 PM 9/25/97 -0400, Curtis Villamizar wrote: > >In message <3.0.32.19970924120126.006d5f64@pobox>, Dimitry Haskin writes: >> >> I'm not ready to say (even if it has crossed my mind ;) that use of the >> local-scope addresses as the BGP next-hop will be sufficient in all >> possible cases. Nevertheless I clearly can see and have demonstrated how >> local-scope addresses can be used to our advantage in many non-exotic >> cases. At this point I'm just asking to relax the v6 BGP rules imposed on >> the NEXT_HOP address scope. This way we don't have to resolve >> philosophical or whatever dilemmas now but simply to experiment and see. > >> Too much to ask? >Yes! > >You need another attribute if you want to put an address in that is >off subnet. > >Routing protocol features which are semantically identical for IPv4 >and IPv6 are a good thing where possible and backward compatibility >with existing BGP4 implementations is needed for IPv4. > >The harder you make the transition the longer it will be before IPv6 >deployment is anything more than a toy. It makes sense to avoid >complicating the transition if you don't have a really good reason to >do so and IMHO you don't have any good reason at all to use NEXT_HOP >rather than another attribute. > >BTW- In paractice, this rule is already relaxed for multihop EBGP with >non-local addresses and a TTL applied to the peering, but multihop >EBGP is considered a hack for research peerings (test out routing >code) and to work around level 2 brain damage (when routers must be >sort of bridged when they don't support a common media and >encapsulation - for example RFC1490 and RFC1483 encapsulation on ATM >requiring a intermediate router that supports both). It can also be a >very problematic hack. > >Curtis >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 18:54:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA22314; Thu, 25 Sep 1997 18:46:23 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA22307; Thu, 25 Sep 1997 18:46:10 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA00419; Thu, 25 Sep 1997 18:46:03 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id SAA29271 for ; Thu, 25 Sep 1997 18:45:40 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id VAA02965; Thu, 25 Sep 1997 21:45:35 -0400 (EDT) Message-Id: <199709260145.VAA02965@brookfield.ans.net> To: Dimitry Haskin cc: curtis@ans.net, ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4554) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Thu, 25 Sep 1997 20:40:33 EDT." <3.0.1.32.19970925204033.006abda4@pobox> Date: Thu, 25 Sep 1997 21:45:34 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2271 In message <3.0.1.32.19970925204033.006abda4@pobox>, Dimitry Haskin writes: > Curtis, > > With all my respect, I'm not sure what you are talking about. I feel that > you comments are out of context of the argument at hand. We are discussing > the use of the nexthop that is specified in the MP_REACH_NLRI attribute in > the IPv6 context. Is it what you're talking about too? > > Dimitry The MP_REACH_NLRI Next Hop and BGP4 NEXT_HOP are semantic equivalents and in practice the IPv4 and IPv6 networks routing may overlay each other in what could be a very long transition. The functionality for IPv4 and IPv6 should mirror each other. This avoids an iteration of BGP where MP_REACH_NLRI Next Hop is sorta-like NEXT_HOP except for a few rules where they are unnessecarily different. Worse yet the route computation could come out differently for Ipv4 and IPv6 networks overlaying each other. This is strictly a matter of avoiding operational headaches and making it easier on a transition. It could make coding a bit easier too (and its not like bugs in BGP code haven't been a serious problem in practice). Its a new attribute so in principle you could throw out any IPv4 preconceptions but IMHO it would be wise to minimize differences unless there is good reason for change and I don't see that. I still think of MP_REACH_NLRI Next Hop as IPv6 equivalent to BGP4 NEXT_HOP. The list of SNPAs is similar to what was going to be a new attribute in BGP in ancient times (that suggestion dates back to before the first NHRP was proposed to ROLC) to accomodate shortcuts. Other than the SNPA which previously was suggested as a separate attribute, MP_REACH_NLRI is the old BGP4 NLRI and a next hop rolled into a new attribute. What you are telling us is that the Next Hop is no longer quite the same as NEXT_HOP and I'm objecting. Did that make more sense or less sense? Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 19:24:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA22346; Thu, 25 Sep 1997 19:16:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA22339; Thu, 25 Sep 1997 19:16:03 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA05294; Thu, 25 Sep 1997 19:16:01 -0700 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA06027 for ; Thu, 25 Sep 1997 19:16:03 -0700 Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Thu Sep 25 22:15:21 EDT 1997 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by research; Thu Sep 25 22:15:21 EDT 1997 Received: from dnrc.bell-labs.com ([135.17.248.76]) by zubin.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id WAA01926; Thu, 25 Sep 1997 22:15:41 -0400 (EDT) Message-ID: <342B1B8F.A7844C31@dnrc.bell-labs.com> Date: Thu, 25 Sep 1997 22:18:55 -0400 From: Grenville Armitage Reply-To: gja@dnrc.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Kazu@mew.org CC: ipng@sunroof.eng.sun.com, ion@nexen.com Subject: (IPng 4556) Re: Regarding draft-yamamoto-ipv6-over-p2p-atm-00.txt References: <3427DB39.D30E8969@dnrc.bell-labs.com> <19970926014813E.kazu@Mew.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3046 Hi Kazu, (note, I've added the ION list back on the cc line, since this topic is under its purview too.) > Hello Grenville, > > Thank you for your interest. My pleasure :-) [..] > I participated in IPng wg meetings in Munich. I don't think IPng wg > achieved any consensus to provide a spec for such cases. Sorry but I > did not participate in ION meeting. Okay. The situation is that in Munich the IPng WG was not being asked to achieve consensus on any given IPv6 over ATM approach, since this topic had been delegated to the ION WG as far back as the end of 1995. I presented the current work to the IPng group as a status update. There was quite animated discussion of the right approach for IPv6/ATM(NBMA) during all of 1996 in the ION group. You are right to observe that we've not explicitly addressed ATM in pt-pt mode in the current document (issued before the Munich IETF). This is being rectified. > Our draft does NOT talk about the simple cases of NBMA. (That's why we > think we don't need to refer ION draft.) It covers ONLY p2p link. In an ATM network, p2p (nailed up PVCs) _is_ a simple use of NBMA. The ATM network is NBMA - the fact that you only use PVCs doesn't change this. > We strongly believe that p2p spec should be separated from NBMA > spec. Do you agree? Since using an NBMA network in PVC mode is a subset of the more general case, I don't agree on technical grounds. On pragmatic grounds, I think if there's a substantial delay in getting the overall IPv6/NBMA work onto the standards track, then yes, we should consider breaking out a small IPv6/PVC document. But that problem does not yet exist. Wait until a month before the March 98 IETF :-) The real problem that currently exists is that we (the authors of the curent draft-ietf-ion-tn-01.txt document) had not gotten around to actually writing the fairly simple additional text for ATM PVCs as pt-pt links. It was planned, and is now in existence (we're sanity checking the revised docs now). The current ION/IPv6 architecture has been accepted for awhile now, and is expected to go to Last Call by the Dec.97 meeting. It's next iteration (expected in a week or so) will include the use of NBMA networks (including ATM) in simple "pt-pt pipes between IPv6 nodes" mode. [..] > I remember that one guy suggested that this draft should have the word > "ipv6" in its title. I agree with him. :) Yes, and we've taken note of that :-) cheers, gja ________________________________________________________________________ Grenville Armitage High Speed Networks Research http://nj5.injersey.com/~gja Bell Labs, Lucent Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 19:38:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA22379; Thu, 25 Sep 1997 19:30:16 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA22372; Thu, 25 Sep 1997 19:30:03 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA07040; Thu, 25 Sep 1997 19:30:01 -0700 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA08889 for ; Thu, 25 Sep 1997 19:30:02 -0700 Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Thu Sep 25 22:28:41 EDT 1997 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by research; Thu Sep 25 22:28:40 EDT 1997 Received: from dnrc.bell-labs.com ([135.17.248.76]) by zubin.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id WAA02177; Thu, 25 Sep 1997 22:29:01 -0400 (EDT) Message-ID: <342B1EAF.A19921F4@dnrc.bell-labs.com> Date: Thu, 25 Sep 1997 22:32:15 -0400 From: Grenville Armitage Reply-To: gja@dnrc.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: kazu@mew.org CC: ipng@sunroof.eng.sun.com, ion@nexen.com Subject: (IPng 4557) Re: Regarding draft-yamamoto-ipv6-over-p2p-atm-00.txt References: <3427DB39.D30E8969@dnrc.bell-labs.com> <19970926014813E.kazu@Mew.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3060 Hi Kazu, (note, I've added the ION list back on the cc line, since this topic is under its purview too.) > Hello Grenville, > > Thank you for your interest. My pleasure :-) [..] > I participated in IPng wg meetings in Munich. I don't think IPng wg > achieved any consensus to provide a spec for such cases. Sorry but I > did not participate in ION meeting. Okay. The situation is that in Munich the IPng WG was not being asked to achieve consensus on any given IPv6 over ATM approach, since this topic had been delegated to the ION WG as far back as the end of 1995. I presented the current work to the IPng group as a status update. There was quite animated discussion of the right approach for IPv6/ATM(NBMA) during all of 1996 in the ION group. You are right to observe that we've not explicitly addressed ATM in pt-pt mode in the current document (issued before the Munich IETF). This is being rectified. > Our draft does NOT talk about the simple cases of NBMA. (That's why we > think we don't need to refer ION draft.) It covers ONLY p2p link. In an ATM network, p2p (nailed up PVCs) _is_ a simple use of NBMA. The ATM network is NBMA - the fact that you only use PVCs doesn't change this. > We strongly believe that p2p spec should be separated from NBMA > spec. Do you agree? Since using an NBMA network in PVC mode is a subset of the more general case, I don't agree on technical grounds. On pragmatic grounds, I think if there's a substantial delay in getting the overall IPv6/NBMA work onto the standards track, then yes, we should consider breaking out a small IPv6/PVC document. But that problem does not yet exist. Wait until a month before the March 98 IETF :-) The real problem that currently exists is that we (the authors of the curent draft-ietf-ion-tn-01.txt document) had not gotten around to actually writing the fairly simple additional text for ATM PVCs as pt-pt links. It was planned, and is now in existence (we're sanity checking the revised docs now). The current ION/IPv6 architecture has been accepted for awhile now, and is expected to go to Last Call by the Dec.97 meeting. It's next iteration (expected in a week or so) will include the use of NBMA networks (including ATM) in simple "pt-pt pipes between IPv6 nodes" mode. [..] > I remember that one guy suggested that this draft should have the word > "ipv6" in its title. I agree with him. :) Yes, and we've taken note of that :-) cheers, gja ________________________________________________________________________ Grenville Armitage High Speed Networks Research http://nj5.injersey.com/~gja Bell Labs, Lucent Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 21:10:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA22490; Thu, 25 Sep 1997 21:02:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA22483; Thu, 25 Sep 1997 21:02:06 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA17312; Thu, 25 Sep 1997 21:02:05 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA26727 for ; Thu, 25 Sep 1997 21:02:04 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id XAA02769; Thu, 25 Sep 1997 23:58:15 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA27678; Thu, 25 Sep 1997 23:58:13 -0400 Message-Id: <9709260358.AA27678@wasted.zk3.dec.com> To: Harvey Thompson Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 4558) Re: Update to RFC 2133 In-Reply-To: Your message of "Wed, 24 Sep 1997 09:51:37 BST." <6506.875091097@sco.COM> Date: Thu, 25 Sep 1997 23:58:12 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2457 Harvey, >So despite what I've said, my vote goes for; Good job on parsing all that above I like your new name proposal if we go that route too. > 1. gethostbyname() would only return AF_INET Though this causes me pain and others I have to agree. > 2. NO gethostbyname2(). > 3. NO getdynhostent/gethostentafopt > 4. Add more AI_ options as required (AI_INET6_V4MAP?) > 5. IPv6 and MT applications use getaddrinfo() I agree we need more AI_ options Yes. >Of course implementation of getaddrinfo() which uses gethostbyname() would >be tricky -- but that's an implementation issue... with which we, wearing our >IETF hats, shouldn't be concerned. If we wear our IETF hats we should not care about APIs at all but we are here and most implementors on this list think we should be here. I still think we need gethostbyname?() that is MT safe that can be used by getaddrinfo() and applications that do not want to use getaddrinfo() from three variances in products: 1. We do not want this defined by the public domain implementation of BIND and then have to re-write that code each time we get a kit. I think this is unacceptable for IPv6/IPv4 interoperation. I feel very very strongly about this issue. I think many other vendors besides me on this list feel the same way. I also don't want pub domain code defining MT safeness in my products, without some direction. I think that direction is being defined on this list. 2. ISVs (this is recursive from above) want to do a simple add/replace operation to initially support IPv6/IPv4 interoperation and not buy into the entire function of getaddrinfo() for existing apps. 3. But ISVs need new IP routines to be MT safe and this is why we are revisiting RFC 2133 because the RES_USE_INET6 is not, otherwise we would be done. The other issue is if we want to change getaddrinfo() thats fine but then we are altering a POSIX std here. Whats the result of that needs some thought. But we do need some new options. More comments please???? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 25 21:49:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA22519; Thu, 25 Sep 1997 21:41:07 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA22512; Thu, 25 Sep 1997 21:40:56 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA21392; Thu, 25 Sep 1997 21:40:56 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA05058 for ; Thu, 25 Sep 1997 21:40:56 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id AAA17822; Fri, 26 Sep 1997 00:35:20 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA26292; Fri, 26 Sep 1997 00:35:15 -0400 Message-Id: <9709260435.AA26292@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 4559) Re: Update to RFC 2133 In-Reply-To: Your message of "Wed, 24 Sep 1997 10:53:53 PDT." <199709241753.KAA02813@feller.mentat.com> Date: Fri, 26 Sep 1997 00:35:14 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4975 Tim, > 1. gethostbyname() would only return AF_INET > 2. NO gethostbyname2(). > 3. NO getdynhostent/gethostentafopt > 4. Add more AI_ options as required (AI_INET6_V4MAP?) > 5. IPv6 and MT applications use getaddrinfo() > Even though I am not a resolver library expert I tend to agree with >this conclusion. The only reasonable counter argument would be that there are >existing applications which are coded in such a way as to make it difficult >to add the appropriate freeing of the storage associated with a getaddrinfo/ >gethostentafopt/getdynhostent call. This would argue for gethostbyname return- >ing AF_INET6 addresses or for having a gethostbyname2. Both these solutions >have their problems. I know those applications do exist. So I may be able to absorb this conclusion too if we have an MT safe gethostbyname2() as I said in previous mail and for the reasons I already stated. I essentially want some control over whats in the resolver library specified and that can be used by those who don't want all getaddrinfo() has to offer. > In looking through the current version of the X/Open documents I don't >see documentation for getaddrinfo. Is it the case that X/Open has not adopted >getaddrinfo? Will they be adopting getaddrinfo? Are they trying to create >their own wheel? I have asked the same question and all I got was it just fell off the plate. I have been given no "technical reason" what is wrong with getaddrinfo. I think this can be done and on XNET list of todo's. So I am not to worried about this one. If its in RFC 2133 or a new version of RFC 2133 that I would think clinch it as being part of XNET with proper technical evaluation of course. I do think we need to add AI_ options to getaddrinfo() so it might be good that it has not been adopted in its present form????? I am hoping likewise for our support of MT safe API to support getaddrinfo(). A bit of History here for all. When Bob Gilligan, Sue Thomson, and I were first approached about adding getaddrinfo(), we balked and said no way and that should be done in a separate draft or by POSIX (which was not complete for getaddrinfo() at this time - IETF Stockholm Meeting I think July 1995). Our fears are being born out right now on this mail thread. When we first evisioned this API it was to provide a very simple update to gethostbyname() to support the ability to: 1. get ipv4 addresses 2. get ipv4 mapped addresses 3. get ipv6 addresses This is still a need and we need a simple API to do just that and getaddrinfo() was added to the spec to appease those new applications that might want to use the capabilities of getaddrinfo() that does alot more than the standard BSD mechanisms do today via get****(). IT WAS NOT TO REPLACE THE ORIGINAL IDEA OF THIS API from the authors. Some how this history seems to be lost. The historical logic model I believe is still valid for this API. But now we do have a new and real req that Erik Nordmark brought up and that I am sure any IPv4/IPv6 implementor felt (I know we did) and that is it would be nice if this new API was MT Safe. The way we did RFC 2133 this is not possible (unless you really want to mess around and I don't think we do is consensus). Another new req that appeared from within our "community" (not really one person) was that it would be nice to be able to support some new options. What Harvey proposed as his outcome supports the new options being added to getaddrinfo() and to me that makes sense to put them there. But I think we also need the orginal purpose of the API but we need to make it MT safe. I want to ask now why would anyone have a problem with this strategy? I think it gives all of us what we want and provides us a choice to use what we want (or should I say our customers). All we would have to do is alter gethostbyname2 to support &buffer parameter and permit the rule set above for IPv4/IPv6 Interoperation, which also support RFC 1933 (transition spec). We could define the additional options we want for getaddrinfo() and update gethostbyname2() to be thread safe with a new rule set in RFC 2133 and we would be done. Those of us that have folks using RFC 2133 today could be given a porting cheat sheet to update their apps supporting IPv4/IPv6 RFC 2133+ which would not be that nasty. And also we would have put some input to the resolver lib for pub BIND. We could probably get a new draft out and present it at D.C. at December 1997 IETF meeting and we would be done if no objections with the basic API for IPv6 before 1998. Comments???? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 26 10:35:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA22957; Fri, 26 Sep 1997 10:24:52 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA22950; Fri, 26 Sep 1997 10:24:47 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id KAA15174 for ; Fri, 26 Sep 1997 10:24:46 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA08637; Fri, 26 Sep 1997 10:22:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA22316; Thu, 25 Sep 1997 18:48:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA01088; Thu, 25 Sep 1997 18:48:49 -0700 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id SAA29957 for ; Thu, 25 Sep 1997 18:48:49 -0700 Received: from localhost (kazu@localhost [127.0.0.1]) by mine.aist-nara.ac.jp (8.8.5/8.8.5) with ESMTP id BAA03644; Fri, 26 Sep 1997 01:48:15 +0900 (JST) To: gja@dnrc.bell-labs.com, ipng@sunroof.eng.sun.com Subject: (IPng 4560) Re: Regarding draft-yamamoto-ipv6-over-p2p-atm-00.txt From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: Your message of "Tue, 23 Sep 1997 11:07:37 -0400" <3427DB39.D30E8969@dnrc.bell-labs.com> References: <3427DB39.D30E8969@dnrc.bell-labs.com> X-Mailer: Mew version 1.91 on XEmacs 20.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19970926014813E.kazu@Mew.org> Date: Fri, 26 Sep 1997 01:48:13 +0900 X-Dispatcher: imput version 970918 Lines: 53 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2352 Hello Grenville, Thank you for your interest. From: Grenville Armitage Subject: Regarding draft-yamamoto-ipv6-over-p2p-atm-00.txt Date: Tue, 23 Sep 1997 11:07:37 -0400 > - The ION WG has been working on this topic for awhile. > I couldn't find reference to draft-ietf-ion-tn-01.txt > in your I-D, so perhaps you are not aware of it? We know it. Actually we refereed it in old versions of the draft, however, some guys arose objections. Since ATM issues sometime fall into politics, we decided not to refer it. > - draft-ietf-ion-tn-01.txt is currently being updated > to cover the simple cases of NBMA networks used as p2p > links (this came out of the Munich IETF as a desire > from the IPng and ION groups). I expect you'll see it > released in the next 2 weeks. Let me clarify. I participated in IPng wg meetings in Munich. I don't think IPng wg achieved any consensus to provide a spec for such cases. Sorry but I did not participate in ION meeting. Our draft does NOT talk about the simple cases of NBMA. (That's why we think we don't need to refer ION draft.) It covers ONLY p2p link. We strongly believe that p2p spec should be separated from NBMA spec. Do you agree? > - Your section 6 "Interface Identifier" could be > replaced by a pointer to section 5 of > draft-ietf-ion-tn-00.txt That might be a good idea. But as of writing our draft, we think this section is necessary because PPP, Ethernet, and FDDI drafts have one secton to discuss IF ID. We hoped that our draft should be self-composite. > (My apologies for the imprecise title in this I-D, perhaps > it is unecessarily confusing people as to its applicability. > We are working to clear things up in the impending release. > Also, thanks for reminding us that this topic is important > and needs to be expedited.) I remember that one guy suggested that this draft should have the word "ipv6" in its title. I agree with him. :) --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 26 11:38:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA22995; Fri, 26 Sep 1997 11:26:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA22987; Fri, 26 Sep 1997 11:26:34 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA23273; Fri, 26 Sep 1997 11:26:29 -0700 Received: from ietf.org ([132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA11689 for ; Fri, 26 Sep 1997 11:26:05 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA07312; Fri, 26 Sep 1997 14:25:56 -0400 (EDT) Message-Id: <199709261825.OAA07312@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4561) I-D ACTION:draft-ietf-ipngwg-tokenring-01.txt Date: Fri, 26 Sep 1997 14:25:55 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3186 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over Token Ring Networks Author(s) : S. Thomas Filename : draft-ietf-ipngwg-tokenring-01.txt Pages : 10 Date : 1997-09-23 This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-tokenring-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-tokenring-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-tokenring-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970926141346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-tokenring-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-tokenring-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970926141346.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 26 11:45:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA23007; Fri, 26 Sep 1997 11:33:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA23000; Fri, 26 Sep 1997 11:33:42 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA25245; Fri, 26 Sep 1997 11:33:38 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA13735 for ; Fri, 26 Sep 1997 11:33:33 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id OAA07937; Fri, 26 Sep 1997 14:33:26 -0400 (EDT) Message-Id: <199709261833.OAA07937@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4562) I-D ACTION:draft-ietf-ipngwg-esd-analysis-01.txt Date: Fri, 26 Sep 1997 14:33:25 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4986 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 Author(s) : L. Zhang, A. Mankin, J. Stewart, T. Narten, M. Crawford Filename : draft-ietf-ipngwg-esd-analysis-01.txt Pages : 52 Date : 1997-09-16 On February 27-28, 1997, the IPng Working Group held an interim meeting in Palo Alto, California to consider adopting Mike O'Dell's 'GSE - An Alternate Addressing Architecture for IPv6' proposal [GSE]. In GSE, 16-byte IPv6 addresses are split into three portions: a globally unique End System Designator (ESD), a Site Topology Partition (STP) and a Routing Goop (RG) portion. The STP corresponds (roughly) to a site's subnet portion of an IPv4 address, whereas the RG identifies the attachment point to the public Internet. Routers use the RG+STP portions of addresses (called 'Routing Stuff' in this document) to route packets to the link to which the destination is directly attached; the ESD is used to deliver the packet across the last hop link. An important idea in GSE is that nodes within a site do not know the RG portion of their addresses. A border router at the site's Internet connect point would dynamically replace the RG part of source addresses of all outgoing IP datagrams and the RG part of destination addresses on incoming traffic. This document provides a detailed analysis of the GSE plan. Much of the analysis presented here is an expansion of official meeting minutes, though it also includes issues uncovered by the authors in the process of fully fleshing out the analysis. In summary, the working group eventually decided that the full addresses of nodes within a site should not be hidden from those nodes, so as a result it is not necessary for routers to rewrite the Routing Goop portion of addresses. However, other parts of the GSE plan were adopted (e.g., having 64-bit interface identifiers with an option for specifying them as globally unique and easing the renumbering of the high-order portion of addresses within DNS). In addition to analyzing the GSE proposal in particular, the document also studies the general issue of separating network layer addresses into two separate values satisfying location and identification purposes, respectively. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-esd-analysis-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-esd-analysis-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970926142455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-esd-analysis-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970926142455.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 26 12:10:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA23055; Fri, 26 Sep 1997 12:01:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA23048; Fri, 26 Sep 1997 12:01:17 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA02271; Fri, 26 Sep 1997 12:01:13 -0700 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA19083 for ; Fri, 26 Sep 1997 11:52:03 -0700 Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Sep 26 14:50:39 EDT 1997 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by research; Fri Sep 26 14:50:36 EDT 1997 Received: from dnrc.bell-labs.com (gjapc [135.180.130.101]) by zubin.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id OAA13877; Fri, 26 Sep 1997 14:50:45 -0400 (EDT) Message-ID: <342C03E7.DD2293CD@dnrc.bell-labs.com> Date: Fri, 26 Sep 1997 14:50:15 -0400 From: Grenville Armitage Reply-To: gja@dnrc.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Masataka Ohta CC: ipng@sunroof.eng.sun.com, ion@nexen.com Subject: (IPng 4564) Re: Regarding draft-yamamoto-ipv6-over-p2p-atm-00.txt References: <199709261041.TAA14807@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1132 Masataka, [..] > If PPP over point-to-point AAL5 is defined (I'll not be surprised > if commercial routers already support it), can you forbid people > use IPv6 over PPP over point-to-point ATM? Yes, since we have IPv6 over PPP, and then PPP over AAL5/PVCs, the concatenation of these two provides a functional IPv6 over ATM (pt-pt mode) solution. We were not planning on forbidding it. It will be a "MAY" option in addition to the default approach of just shoving LLC/SNAP encapsulated IPv6 packets over an AAL5 PVC. cheers, gja ________________________________________________________________________ Grenville Armitage High Speed Networks Research http://nj5.injersey.com/~gja Bell Labs, Lucent Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 26 13:50:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA23226; Fri, 26 Sep 1997 13:39:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA23219; Fri, 26 Sep 1997 13:39:10 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA25059; Fri, 26 Sep 1997 13:39:07 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA18374 for ; Fri, 26 Sep 1997 13:39:07 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id PAA25125; Fri, 26 Sep 1997 15:38:59 -0500 Message-Id: <199709262038.PAA25125@gungnir.fnal.gov> To: Paul Traina , Curtis Villamizar Cc: ipng@sunroof.eng.sun.com, idr@merit.edu From: "Matt Crawford" Subject: (IPng 4565) Re: BGP and renumbering In-reply-to: Your message of Thu, 25 Sep 1997 17:10:44 PDT. <199709260010.RAA05909@base.juniper.net> Date: Fri, 26 Sep 1997 15:38:59 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1436 > > The longer term solution is to design renumbering support in the next EGP. > > Not very tough if you can have two addresses during transition. All > BGP needs is to allow a timer on routes after the CEASE. If after the > CEASE the same peering came up with a different pair of addresses and > announced all of the routes before the timer expired there would be no > disruption of service. Hold on a second ... if your (non-multihop) EBGP connections at an IX or on a private link run between link-local addresses, your BGP peerings are immune to renumberings by your peer. And if your own IBGP connections run between site-local addresses, those peerings are immune to renumbering of YOUR OWN system. Topology changes will probably be likened someday to tectonic motions -- they introduce stress in the routing which can be relieved by renumbering. If you let it go too long, you get a Richter 8.0. Or you can grease up the fault lines with little 1.0 shocks and not break a teacup. Matt (Hey, at least I didn't use the s10y metaphor!) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 26 14:08:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA23278; Fri, 26 Sep 1997 13:58:47 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA23271; Fri, 26 Sep 1997 13:58:42 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id NAA12111 for ; Fri, 26 Sep 1997 13:58:41 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09153; Fri, 26 Sep 1997 13:56:13 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA23037; Fri, 26 Sep 1997 11:57:49 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA01397; Fri, 26 Sep 1997 11:57:45 -0700 Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA20552 for ; Fri, 26 Sep 1997 11:57:45 -0700 Received: from abfab.juniper.net (abfab.juniper.net [208.197.169.86]) by red.juniper.net (8.8.5/8.8.5) with SMTP id LAA00337 for ; Fri, 26 Sep 1997 11:57:40 -0700 (PDT) Message-Id: <3.0.1.32.19970926115753.006a088c@pobox.juniper.net> X-Sender: jstewart@pobox.juniper.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 26 Sep 1997 11:57:53 -0700 To: ipng@sunroof.eng.sun.com From: John W Stewart III Subject: (IPng 4567) Re: I-D ACTION:draft-ietf-ipngwg-esd-analysis-01.txt In-Reply-To: <199709261833.OAA07937@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4934 fyi, this document announcement should be ignored. the document being announced (the -01 version) has been available in the on-line directories since before munich even though it was never announced. we're working on an update to it right now, so don't interpret this announcement as encouragement to read it... sorry for the confusion, /jws At 02:33 PM 9/26/97 -0400, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IPNG Working Group of the IETF. > > Title : Separating Identifiers and Locators in > Addresses: An Analysis of the GSE Proposal > for IPv6 > Author(s) : L. Zhang, A. Mankin, J. Stewart, > T. Narten, M. Crawford > Filename : draft-ietf-ipngwg-esd-analysis-01.txt > Pages : 52 > Date : 1997-09-16 > > On February 27-28, 1997, the IPng Working Group held an interim > meeting in Palo Alto, California to consider adopting Mike O'Dell's > 'GSE - An Alternate Addressing Architecture for IPv6' proposal [GSE]. > In GSE, 16-byte IPv6 addresses are split into three portions: a > globally unique End System Designator (ESD), a Site Topology Partition (STP) and a Routing Goop (RG) portion. The STP corresponds > (roughly) to a site's subnet portion of an IPv4 address, whereas the > RG identifies the attachment point to the public Internet. Routers > use the RG+STP portions of addresses (called 'Routing Stuff' in this > document) to route packets to the link to which the destination is > directly attached; the ESD is used to deliver the packet across the > last hop link. An important idea in GSE is that nodes within a site > do not know the RG portion of their addresses. A border router at the > site's Internet connect point would dynamically replace the RG part > of source addresses of all outgoing IP datagrams and the RG part of > destination addresses on incoming traffic. > > This document provides a detailed analysis of the GSE plan. Much of > the analysis presented here is an expansion of official meeting > minutes, though it also includes issues uncovered by the authors in > the process of fully fleshing out the analysis. In summary, the > working group eventually decided that the full addresses of nodes > within a site should not be hidden from those nodes, so as a result > it is not necessary for routers to rewrite the Routing Goop portion > of addresses. However, other parts of the GSE plan were adopted > (e.g., having 64-bit interface identifiers with an option for > specifying them as globally unique and easing the renumbering of the > high-order portion of addresses within DNS). > > In addition to analyzing the GSE proposal in particular, the document > also studies the general issue of separating network layer addresses > into two separate values satisfying location and identification > purposes, respectively. > >Internet-Drafts are available by anonymous FTP. Login wih the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ipngwg-esd-analysis-01.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-esd-analysis-01.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ds.internic.net > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-01.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 26 16:09:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA23427; Fri, 26 Sep 1997 16:00:20 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA23420; Fri, 26 Sep 1997 16:00:15 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id QAA29823 for ; Fri, 26 Sep 1997 16:00:14 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA09868; Fri, 26 Sep 1997 15:57:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA23340; Fri, 26 Sep 1997 14:49:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA14613; Fri, 26 Sep 1997 14:49:47 -0700 Received: from ds1.gl.umbc.edu (ds1.gl.umbc.edu [130.85.3.11]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA07506 for ; Fri, 26 Sep 1997 14:49:26 -0700 Received: from collie.cs.umbc.edu (kodeswar@collie.cs.umbc.edu [130.85.100.171]) by ds1.gl.umbc.edu (8.8.7/8.8.7) with ESMTP id RAA25411; Fri, 26 Sep 1997 17:49:20 -0400 (EDT) Received: (kodeswar@localhost) by collie.cs.umbc.edu (8.8.6/8.6.9) id RAA10868; Fri, 26 Sep 1997 17:49:18 -0400 (EDT) Date: Fri, 26 Sep 1997 17:49:17 -0400 (EDT) From: Sethurambalaji Kodeswaran To: Matt Crawford cc: Paul Traina , Curtis Villamizar , ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4569) Where to start????? In-Reply-To: <199709262038.PAA25125@gungnir.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 604 hi, I am new graduate student and i would like to know more about IPv6. Can you tell me where to start. I have worked a lot with TCP/IP but am not too familiar with the intricasies of IPv4.Thanx in advance Bye, Balaji. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 26 16:17:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA23444; Fri, 26 Sep 1997 16:07:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA23437; Fri, 26 Sep 1997 16:07:03 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA14207; Fri, 26 Sep 1997 16:06:59 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA07552 for ; Fri, 26 Sep 1997 16:06:52 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA00996; Fri, 26 Sep 97 16:05:10 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id QAA04495; Fri, 26 Sep 1997 16:07:17 -0700 Date: Fri, 26 Sep 1997 16:07:17 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199709262307.QAA04495@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4570) Re: Update to RFC 2133 X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2591 Jim, > > I know those applications do exist. So I may be able to absorb this > conclusion too if we have an MT safe gethostbyname2() as I said in > previous mail and for the reasons I already stated. I essentially want > some control over whats in the resolver library specified and that can > be used by those who don't want all getaddrinfo() has to offer. > Yes I am fairly certain that there are old pieces of code laying around that do longjmps without having a easy way to add the memory clean-up. Unfortunately I don't see how you get to a MT safe gethostbyname[2] type facility without inventing a new set of API's in addition to getaddrinfo which is MT safe and the existing non MT safe gethostbyname. That would mean something like Erik's or Harvey's suggestion. That is doable but it means inventing another wheel. In one of your previous notes you indicated that ISV's want a simple replacement for the existing gethostbyname facilities. Simple would imply that at least initially they don't care about nor do they want to spend time worrying about MT safety. Given that I would propose the following. 1) We define a non MT safe version of gethostbyname[2] which can be used by ISV who are looking for the quick fix. The simplest thing to do here is simply use gethostbyname2 as it has been defined in the current BIND distribution. I believe this would satisfy the original requirements of the API. > > 1. get ipv4 addresses > 2. get ipv4 mapped addresses > 3. get ipv6 addresses > 2) We add whatever options we believe are necessary to getaddrinfo to make it a complete solution for IPv6 addressing and call that the MT safe API. The problems with this include: 1) Some folks believe that gethostbyname2 is a kludge. 2) We do not have an IPv4/IPv6 MT safe API on which to base an implementation of getaddrinfo. These might be showstoppers. I don't know. It would be nice to limit ourselves to at most two ways to get the job done. An MT safe way and a non MT safe way. If we could get it down to one (getaddrinfo) that would probably be ideal from an implementation point of view but maybe not so ideal from the perspective of ISV's. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 26 17:04:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA23478; Fri, 26 Sep 1997 16:55:45 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA23471; Fri, 26 Sep 1997 16:55:36 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA26856; Fri, 26 Sep 1997 16:55:32 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA10262 for ; Fri, 26 Sep 1997 16:55:30 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id QAA07437; Fri, 26 Sep 1997 16:54:57 -0700 Message-Id: <3.0.3.32.19970926165425.007f9320@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 26 Sep 1997 16:54:25 -0700 To: Sethurambalaji Kodeswaran From: Bob Hinden Subject: (IPng 4571) Re: Where to start????? Cc: ipng@sunroof.eng.sun.com, idr@merit.edu In-Reply-To: References: <199709262038.PAA25125@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 641 Balaji, >I am new graduate student and i would like to know more about IPv6. Can >you tell me where to start. I have worked a lot with TCP/IP but am not >too familiar with the intricasies of IPv4. Thanx in advance See http://playground.sun.com/ipng Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Sep 27 05:45:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA23834; Sat, 27 Sep 1997 05:36:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA23827; Sat, 27 Sep 1997 05:36:22 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA25174; Sat, 27 Sep 1997 05:36:20 -0700 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id FAA07718 for ; Sat, 27 Sep 1997 05:36:21 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id OAA24274; Sat, 27 Sep 1997 14:36:07 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id OAA06302; Sat, 27 Sep 1997 14:36:05 +0200 (MET DST) Message-Id: <199709271236.OAA06302@givry.inria.fr> From: Francis Dupont To: "Matt Crawford" cc: huitema@bellcore.com (Christian Huitema), ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4572) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of Wed, 24 Sep 1997 10:22:11 CDT. <199709241522.KAA13715@gungnir.fnal.gov> Date: Sat, 27 Sep 1997 14:36:04 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1672 In your previous mail you wrote: > One of the point that was agreed during the Munich meeting of IPv6 is that > Site Local addresses should not be used for EGP routing exchanges. Once again, you make me wonder if we were at the same meeting. I find nothing remotely like your statement above in my memory, my notes, or the minutes of the meeting I attended. (That was in Munich, Bavaria, Germany. Perhaps there are two Munichs?) => there is no formal agreement but I believe many persons in the room shared this idea. Christian was closer to the micro... However, I think I agree with the above, but not with > (My personnal feeling is that site local addresses should not be > used *at all*, at least in a connected site, because they have all > the properties of Net 10 addresses). and what follows. However, that topic is out of scope for this thread. => but we should talk about it (in the ipng mailing list for instance). Personnally I think the same thing than Christian but obviously it is not the case for everybody. The (un)usage of site-local addresses has a real impact on many things, for instance will there be a monster named a multi-sited node? Then it is out of scope but important! Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Sep 27 12:25:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24078; Sat, 27 Sep 1997 12:13:06 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24071; Sat, 27 Sep 1997 12:12:56 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA04134; Sat, 27 Sep 1997 12:12:53 -0700 Received: from brickbat9.mindspring.com (brickbat9.mindspring.com [207.69.200.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA15338 for ; Sat, 27 Sep 1997 12:12:54 -0700 Received: from desktop (user-38lc80j.dialup.mindspring.com [209.86.32.19]) by brickbat9.mindspring.com (8.8.5/8.8.5) with SMTP id PAA25318; Sat, 27 Sep 1997 15:12:46 -0400 (EDT) Message-Id: <2.2.32.19970927192212.0092ce10@mindspring.com> X-Sender: sthomas@mindspring.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_875402532==_" Date: Sat, 27 Sep 1997 15:22:12 -0400 To: Internet-Drafts@cnri.reston.va.us From: Stephen Thomas Subject: (IPng 4573) IPng over Token Ring I-D Cc: hinden@ipsilon.com, ipng@sunroof.eng.sun.com, narten@raleigh.ibm.com X-Attachments: D:\IPng\draft-ietf-ipngwg-trans-tokenring-02.txt; Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 21222 --=====================_875402532==_ Content-Type: text/plain; charset="us-ascii" Sorry to copy the whole list on this, but I'm seriously confused. The latest official Internet Draft for IPng over Token Ring is NOT the one I submitted. I've checked my mail logs to make sure. The attached file is the true, latest and greatest, and I'm asking the I-D editor to re-issue the corrected draft. In the past, the ID editor (or someone other than me, at least) has made two other changes to the draft, both of which I've restored in the attached version. o Name of the draft. The "-trans-" part of the name was removed. To be consistent with Ethernet and FDDI drafts I've added it back. o Expiration date. The expiration date was changed to December 15, well short of the usual 6 month period. I've set the expiration to March 1998, which is six months from the date of issue. --Stephen --=====================_875402532==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-ipngwg-trans-tokenring-02.txt" IPng Working Group Stephen Thomas Internet Draft TransNexus September 27, 1997 Transmission of IPv6 Packets over Token Ring Networks 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). This Internet Draft expires March 27, 1998. 1. Introduction This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network. Expires March 1998 Thomas [Page 1] Internet Draft IPv6 over Token Ring September 27, 1997 2. Maximum Transmission Unit IEEE 802.5 networks have a maximum frame size based on the maximum time a node may hold the token. This time depends on many factors including the data signaling rate and the number of nodes on the ring. Because the maximum frame size varies, implementations must rely on manual configuration or router advertisements [DISC] to determine actual MTU sizes. Common default values include approximately 2000, 4000, and 8000 octets. In the absence of any other information, an implementation should use a default MTU of 1500 octets. This size offers compatibility with all common 802.5 defaults, as well as with Ethernet LANs in an environment using transparent bridging. In an environment using source route bridging, the process of discovering the MAC-level path to a neighbor can yield the MTU for the path to that neighbor. The information is contained in the largest frame (LF) subfield of the routing information field. This field limits the size of the information field of frames to that destination, and that information field includes both the LLC [LLC] header and the IPv6 datagram. Since, for IPv6, the LLC header is always 8 octets in length, the IPv6 MTU can be found by subtracting 8 from the maximum frame size defined by the LF subfield. If an implementation uses this information to determine MTU sizes, it must maintain separate MTU values for each neighbor. A detailed list of the LF values and the resulting maximum frame size can be found in [BRIDGE]. To illustrate the calculation of IPv6 MTU, the following table lists several common values. Note that some of the 802.1D LF values would result in an IP MTU less than 576 bytes. This size is less than the IPv6 minimum, and communication across paths with those MTUs is generally not possible using IPv6. LF (base) LF (extension) MAC MTU IP MTU 001 000 1470 1462 010 000 2052 2044 011 000 4399 4391 100 000 8130 8122 101 000 11407 11399 110 000 17749 17741 111 000 41600 41592 Expires March 1998 Thomas [Page 2] Internet Draft IPv6 over Token Ring September 27, 1997 When presented with conflicting MTU values from several sources, an implementation should choose from those sources according to the following priorities: 1. Largest Frame values from source route bridging (only for specific, unicast destinations) 2. Router advertisements 3. Manual configuration (including DHCP) 4. Default of 1500 3. Frame Format IPv6 packets are transmitted in LLC/SNAP frames. The data field contains the IPv6 header and payload. The following figure shows a complete 802.5 frame containing an IPv6 datagram. +-------+-------+-------+-------+ | SD | AC | FC | | +-----------------------+ | | Destination Address | | +-----------------------+ | | Source | +-------+ Address +-------+ | | DSAP | +-------+-------+-------+-------+ | SSAP | CTL | OUI | +-------+-------+-------+-------+ | OUI | EtherType | | +-------+---------------+ | | | ~ IPv6 header and payload... ~ | | +-------------------------------+ | FCS | +-------+-------+---------------+ | ED | FS | +-------+-------+ Expires March 1998 Thomas [Page 3] Internet Draft IPv6 over Token Ring September 27, 1997 Token Ring Header Fields SD: Starting Delimiter AC: Access Control FC: Frame Control Destination Address: 48-bit IEEE address of destination station Source Address: 48-bit IEEE address of source station DSAP: Destination Service Access Point (for LLC/SNAP format, shall always contain the value 0xAA) SSAP: Source Service Access Point (for LLC/SNAP format, shall always contain the value 0xAA) CTL: Control Field (for Unnumbered Information, shall always contain the value 0x03) OUI: Organizationally Unique Identifier (for EtherType encoding, shall always contain the value 0x000000) EtherType: Protocol type of encapsulated payload (for IPv6, shall always contain the value 0x86DD) FCS: Frame Check Sequence ED: Ending Delimiter FS: Frame Status In the presence of source route bridges, a routing information field (RIF) may appear immediately after the source address. A RIF is present in frames when the most significant bit of the source address is set to one. (This is the bit whose position corresponds to that of the Individual/Group bit in the Destination Address.) The RIF is a variable-length field that (when present) contains a two-octet Routing Control (RC) header, followed by zero or more two-octet Route Designator fields: Expires March 1998 Thomas [Page 4] Internet Draft IPv6 over Token Ring September 27, 1997 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Routing Control: |Bcast| Length |D| LF |rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Route Designator 1: | Segment 1 |Bridge1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Route Designator N: | Segment N |BridgeN| (0 <= N <= 7) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Route Designator Fields: Bcast: Broadcast Indicator, Defined values: 10x: All Routes Explorer 11x: Spanning Tree Explorer 0xx: Specifically Routed Frame Length: Total length of RIF field in octets D: Direction of source route. A value of 0 means that the left-to-right sequence of Route Designators provides the path from the sender to recipient. A value of 0 indicates the sequence goes from recipient to sender. LF: Largest Frame rsvd: Reserved On transmission, the Route Designator fields give the sequence of (bridge, LAN segment) numbers the packet is to traverse. It is the responsibility of the sender to provide this sequence for Specifically Routed Frames, i.e., unicast IP datagrams. 4. Stateless Autoconfiguration The interface identifier [CONF] for a Token Ring interface is the EUI-64 identifier [EUI64] derived from the interface's built- in 48-bit IEEE 802 address. The OUI of the Token Ring address (the first three octets) becomes the company_id of the EUI-64 (the first three octets). The fourth and fifth octets of the EUI are set to the fixed value FFFE hexadecimal. The last Expires March 1998 Thomas [Page 5] Internet Draft IPv6 over Token Ring September 27, 1997 three octets of the Token Ring address become the last three octets of the EUI-64. The Interface Identifier is then formed from the EUI-64 by complementing the "Universal/Local" (U/L) bit, which is the next- to-lowest order bit of the first octet of the EUI-64. Complementing this bit will generally change a 0 value to a 1, since an interface's built-in address is expected to be from a universally administered address space and hence have a globally unique value. A universally administered IEEE 802 address or an EUI-64 is signified by a 0 in the U/L bit position, while a globally unique IPv6 Interface Identifier is signified by a 1 in the corresponding position. For further discussion on this point, see [AARCH]. For example, the interface identifier for a Token Ring interface whose built-in address is, in hexadecimal and in canonical bit order, 34-56-78-9A-BC-DE would be 36-56-78-FF-FE-9A-BC-DE. A different MAC address set manually or by software should not be used to derive the interface identifier. If such a MAC address must be used, its global uniqueness property should be reflected in the value of the U/L bit. An IPv6 address prefix used for stateless autoconfiguration of a Token Ring interface must have a length of 64 bits. 5. Link Local Address The IPv6 link-local address [AARCH] for a Token Ring interface is formed by appending the interface identifer, as defined above, to the prefix FE80::/64. 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) | Interface Identifier | +----------+-----------------------+----------------------------+ 6. Address Mapping -- Unicast The procedure for mapping IPv6 addresses into Token Ring link-layer addresses is described in [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is Token Ring. Expires March 1998 Thomas [Page 6] Internet Draft IPv6 over Token Ring September 27, 1997 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- Token Ring -+ | | +- Address -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option fields: Type: 1 for Source Link-layer address. 2 for Target Link-layer address. Length: 1 (in units of 8 octets). Token Ring Address: The 48 bit Token Ring IEEE 802 address, in canonical bit order. This is the address the interface currently responds to, and may be different from the built-in address used as the interface identifier. When source routing bridges are used, the source route for the path to a destination can be extracted from the RIF field of received Neighbor Advertisement messages. Note that the RIF field of received packets can be reversed into a source route suitable for transmitting return traffic by toggling the value of the 'D' bit and insuring that the Bcast field is set to indicate a Specifically Routed Frame. 7. Address Mapping -- Multicast All IPv6 packets with multicast destination addresses are transmitted to Token Ring functional addresses. The following table shows the specific mapping between the IPv6 addresses and Token Ring functional addresses (in canonical form). Note that protocols other than IPv6 may use these same functional addresses, so all Token Ring frames destined to these functional addresses are not guaranteed to be IPv6 datagrams. Expires March 1998 Thomas [Page 7] Internet Draft IPv6 over Token Ring September 27, 1997 MAC Addr (canonical) IPv6 Multicast Addresses 03-00-80-00-00-00 all nodes (FF01::1 and FF02::1) and solicited node (FF02:0:0:0:0:1:FFXX:XXXX) addresses 03-00-40-00-00-00 all routers addresses (FF0X::2) 03-00-00-80-00-00 any other multicast address with three least significant bits = 000 03-00-00-40-00-00 any other multicast address with three least significant bits = 001 03-00-00-20-00-00 any other multicast address with three least significant bits = 010 03-00-00-10-00-00 any other multicast address with three least significant bits = 011 03-00-00-08-00-00 any other multicast address with three least significant bits = 100 03-00-00-04-00-00 any other multicast address with three least significant bits = 101 03-00-00-02-00-00 any other multicast address with three least significant bits = 110 03-00-00-01-00-00 any other multicast address with three least significant bits = 111 In a bridged token ring network, all multicast packets SHOULD be sent with a RIF header specifying the use of the Spanning Tree Explorer. Note: it is believed that some (very) old bridge implementations do not properly support the Spanning Tree Explorer mechanism. In such environments, multicast traffic sent through bridges must use a RIF with the All Routes Explorer. Consequently, an implementation MAY wish to allow the sending of IP multicast traffic using an All Routes Explorer. However, such an ability must be configurable by a system administrator and the default setting of the switch MUST be to use the Spanning Tree Explorer. Expires March 1998 Thomas [Page 8] Internet Draft IPv6 over Token Ring September 27, 1997 8. Security Considerations Token Ring, like most broadcast LAN technologies, has inherent security vulnerabilities. For example, any sender can claim the identity of another and forge traffic. It is the responsibility of higher layers to take appropriate steps in those environments where such vulnerabilities are unacceptable. 9. Acknowledgments Several members of the IEEE 802.5 Working Group contributed their knowledge and experience to the drafting of this specification, including Jim, Andrew Draper, George Lin, John Messenger, Kirk Preiss, and Trevor Warwick. The author would also like to thank many members of the IPng working group for their advice and suggestions, including Ran Atkinson, Scott Bradner, Matt Crawford, Steve Deering, Francis Dupont, Robert Elz, Thomas Narten, and Matt Thomas. A special thanks is due Steve Wise, who gave the most relevant advice of all by actually trying to implement this specification while it was in progress. 10. References [802.5] 8802-5 : 1995 (ISO/IEC) [ANSI/IEEE 802.5, 1995 Edition] Information technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements-- Part 5: Token ring access method and physical layer specification. [AARCH] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", draft-ietf-ipngwg-addr-arch-v2-01.txt. [BRIDGE] 10038: 1993 (ISO/IEC) [ANSI/IEEE Std 802.1D, 1993 Edition] Information technology--Telecommunications and information exchange between systems--Local area networks--Media access control (MAC) bridges. [CONF] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971. [DISC] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 1970. Expires March 1998 Thomas [Page 9] Internet Draft IPv6 over Token Ring September 27, 1997 [EUI64] "64-Bit Global Identifier Format Tutorial", http: //standards.ieee.org/db/oui/tutorials/EUI64.html. [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883. [LLC] 8802-2 : 1994 (ISO/IEC) [ANSI/IEEE 802.2, 1994 Edition] Information technology--Telecommunications and information exchange between systems--Local and Metropolitan area networks--Specific requirements-- Part 2: Logical link control. 11. Author's Address Stephen Thomas TransNexus 430 Tenth Street NW Suite N204 Atlanta, GA 30318 US Email: stephen.thomas@transnexus.com Phone: +1 404 872 4745 Fax: +1 404 872 9515 Expires March 1998 Thomas [Page 10] --=====================_875402532==_ Content-Type: text/plain; charset="us-ascii" ________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: s.thomas@acm.org --=====================_875402532==_-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Sep 27 20:36:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA24323; Sat, 27 Sep 1997 20:28:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA24316; Sat, 27 Sep 1997 20:28:03 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA07492; Sat, 27 Sep 1997 20:28:03 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id UAA10808 for ; Sat, 27 Sep 1997 20:28:02 -0700 From: Masataka Ohta Message-Id: <199709280322.MAA02089@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA02089; Sun, 28 Sep 1997 12:22:20 +0900 Subject: (IPng 4574) Re: Regarding draft-yamamoto-ipv6-over-p2p-atm-00.txt To: gja@dnrc.bell-labs.com Date: Sun, 28 Sep 97 12:22:19 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com, ion@nexen.com In-Reply-To: <342C03E7.DD2293CD@dnrc.bell-labs.com>; from "Grenville Armitage" at Sep 26, 97 2:50 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1161 Grenville; > Yes, since we have IPv6 over PPP, and then PPP over AAL5/PVCs, the > concatenation of these two provides a functional IPv6 over ATM > (pt-pt mode) solution. > > We were not planning on forbidding it. It will be a "MAY" > option in addition to the default approach of just shoving > LLC/SNAP encapsulated IPv6 packets over an AAL5 PVC. You misunderstand one thing. PPP is the way to trasmit IP over point-to-point links, including, but, not limited to, ATM PVC. Your opinion that use of PPP must be optional for ATM cases will be ignored by PPP related WGs. But they are just formality. In the real world, anything simpler will survive. That is, ATM will disappear, while ATM with PPP or LANE will live a little longer than ATM with ATMARP. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Sep 28 11:19:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA24551; Sun, 28 Sep 1997 11:11:30 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA24544; Sun, 28 Sep 1997 11:11:21 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA10761; Sun, 28 Sep 1997 11:11:18 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA16660 for ; Sun, 28 Sep 1997 11:11:19 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id OAA27377 for ; Sun, 28 Sep 1997 14:05:46 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA11298; Sun, 28 Sep 1997 14:05:45 -0400 Message-Id: <9709281805.AA11298@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4575) UPDATE for RFC 1885 ICMP PS Date: Sun, 28 Sep 1997 14:05:45 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 502 Alex/Steve, For PMTU please reference RFC 1981 for PMTU not 1191 on updates to this spec for Draft Standard. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Sep 28 15:45:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA24637; Sun, 28 Sep 1997 15:37:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA24630; Sun, 28 Sep 1997 15:36:55 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA25420; Sun, 28 Sep 1997 15:36:50 -0700 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA15864 for ; Sun, 28 Sep 1997 15:36:50 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id AAA13679; Mon, 29 Sep 1997 00:36:45 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id AAA10323; Mon, 29 Sep 1997 00:36:45 +0200 (MET DST) Message-Id: <199709282236.AAA10323@givry.inria.fr> From: Francis Dupont To: gja@dnrc.bell-labs.com cc: Kazu@mew.org, ipng@sunroof.eng.sun.com, ion@nexen.com Subject: (IPng 4576) Re: Regarding draft-yamamoto-ipv6-over-p2p-atm-00.txt In-reply-to: Your message of Thu, 25 Sep 1997 22:18:55 EDT. <342B1B8F.A7844C31@dnrc.bell-labs.com> Date: Mon, 29 Sep 1997 00:36:43 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 826 The reason Kazu published this draft is rather simple: yesterday ther was *no* document about IPv6 over P2P ATM whereas it was used and worked well. He just wanted to fill an hole and when he asked us what we thought about it at the Munich meeting we answered it was a good idea... Regards Francis.Dupont@inria.fr PS: I believe it should be merged with Alex Conta's proposal for inverse neighbor discovery (draft-conta-ipv6-inv-nd-tun-00.txt). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 29 06:58:59 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA24973; Mon, 29 Sep 1997 06:48:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA24958; Mon, 29 Sep 1997 06:48:36 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA19292; Mon, 29 Sep 1997 06:48:33 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA10589 for ; Mon, 29 Sep 1997 06:48:34 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA04013; Mon, 29 Sep 1997 09:48:28 -0400 (EDT) Message-Id: <199709291348.JAA04013@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4577) I-D ACTION:draft-ietf-ipngwg-trans-ethernet-03.txt Date: Mon, 29 Sep 1997 09:48:27 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3386 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over Ethernet Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-ethernet-03.txt Pages : 6 Date : 1997-09-26 This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. This document replaces RFC 1972, 'A Method for the Transmission of IPv6 Packets over Ethernet Networks', which will become historic. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-trans-ethernet-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-ethernet-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-trans-ethernet-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970926170748.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-ethernet-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-ethernet-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970926170748.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 29 06:59:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA24974; Mon, 29 Sep 1997 06:49:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA24966; Mon, 29 Sep 1997 06:48:43 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA19307; Mon, 29 Sep 1997 06:48:40 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA10607 for ; Mon, 29 Sep 1997 06:48:39 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA04031; Mon, 29 Sep 1997 09:48:33 -0400 (EDT) Message-Id: <199709291348.JAA04031@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4578) I-D ACTION:draft-ietf-ipngwg-trans-fddi-net-03.txt Date: Mon, 29 Sep 1997 09:48:32 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3325 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-fddi-net-03.txt Pages : 7 Date : 1997-09-26 This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an FDDI network. This document replaces RFC 2019, 'Transmission of IPv6 Packets Over FDDI', which will become historic. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-trans-fddi-net-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-fddi-net-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-trans-fddi-net-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970926171152.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-fddi-net-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-fddi-net-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970926171152.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 29 10:07:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA25199; Mon, 29 Sep 1997 09:57:14 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA25192; Mon, 29 Sep 1997 09:57:08 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA15903 for ; Mon, 29 Sep 1997 09:57:08 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13668; Mon, 29 Sep 1997 09:54:39 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA24470; Sun, 28 Sep 1997 04:56:46 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA08983; Sun, 28 Sep 1997 04:56:44 -0700 Received: from hotmail.com (F104.hotmail.com [207.82.250.223]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA07789 for ; Sun, 28 Sep 1997 04:56:45 -0700 Received: (qmail 28297 invoked by uid 0); 28 Sep 1997 11:56:34 -0000 Message-ID: <19970928115634.28296.qmail@hotmail.com> Received: from 193.227.19.66 by www.hotmail.com with HTTP; Sun, 28 Sep 1997 04:56:32 PDT X-Originating-IP: [193.227.19.66] From: "sameh kilnay" To: ipng@sunroof.eng.sun.com Content-Type: text/plain Date: Sun, 28 Sep 1997 04:56:32 PDT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 869 Dear sir : I am a student in computer engineering and i need to simulate IPV6 and IPV4 in my research . If you have an idea about this s.w. in the net or to be sold and can be installed on Win95 please tell me because i 'am tired in searching in this topic . This will be a great favor from you thanks bye SAMEH ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 29 10:31:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA25246; Mon, 29 Sep 1997 10:20:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA25239; Mon, 29 Sep 1997 10:19:59 -0700 Received: from fstop. by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA08922; Mon, 29 Sep 1997 10:19:55 -0700 Received: from fstop by fstop. (SMI-8.6/SMI-SVR4) id KAA14891; Mon, 29 Sep 1997 10:19:53 -0700 Message-Id: <199709291719.KAA14891@fstop.> From: sparker@Eng To: ipng@sunroof Subject: (IPng 4579) List Administrivia... Date: Mon, 29 Sep 1997 10:19:53 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 593 Subscription addresses from coppermountain.com and cmtn.com were deleted from the IPng mailing list. They failed to indicate the envelope address, and pleas to the postmaster went unanswered. Cheers, ~sparker -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 29 10:56:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA25340; Mon, 29 Sep 1997 10:46:53 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA25333; Mon, 29 Sep 1997 10:46:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA24728; Mon, 29 Sep 1997 10:46:37 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA26189 for ; Mon, 29 Sep 1997 10:46:31 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id NAA25935; Mon, 29 Sep 1997 13:46:02 -0400 (EDT) Message-Id: <199709291746.NAA25935@brookfield.ans.net> To: "Matt Crawford" cc: Paul Traina , Curtis Villamizar , ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4580) Re: BGP and renumbering In-reply-to: Your message of "Fri, 26 Sep 1997 15:38:59 CDT." <199709262038.PAA25125@gungnir.fnal.gov> Date: Mon, 29 Sep 1997 13:46:02 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1257 In message <199709262038.PAA25125@gungnir.fnal.gov>, "Matt Crawford" writes: > > Topology changes will probably be likened someday to tectonic > motions -- they introduce stress in the routing which can be > relieved by renumbering. If you let it go too long, you get a > Richter 8.0. Or you can grease up the fault lines with little 1.0 > shocks and not break a teacup. > > Matt > (Hey, at least I didn't use the s10y metaphor!) With IPv4 there is no significant barrier to renumbering at the ISP level other than the customers can't really do it. Renumbering the routers is a cinche by comparison to renumbering the customers served by an ISP (who in most cases simply refuse). What I'm getting at is that IPv6 needs to solve the end system problems and don't worry so much about renumbering the intrastructure because that's not where the problem is. Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 29 11:47:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA25451; Mon, 29 Sep 1997 11:38:38 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA25444; Mon, 29 Sep 1997 11:37:56 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA09927; Mon, 29 Sep 1997 11:37:52 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA13757 for ; Mon, 29 Sep 1997 11:37:48 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id NAA29373; Mon, 29 Sep 1997 13:37:30 -0500 Message-Id: <199709291837.NAA29373@gungnir.fnal.gov> To: curtis@ans.net Cc: Curtis Villamizar , ipng@sunroof.eng.sun.com, idr@merit.edu From: "Matt Crawford" Subject: (IPng 4581) Re: BGP and renumbering In-reply-to: Your message of Mon, 29 Sep 1997 13:46:02 EDT. <199709291746.NAA25935@brookfield.ans.net> Date: Mon, 29 Sep 1997 13:37:29 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 875 > Renumbering the routers is a cinche by comparison to renumbering > the customers served by an ISP (who in most cases simply refuse). > > What I'm getting at is that IPv6 needs to solve the end system > problems and don't worry so much about renumbering the intrastructure > because that's not where the problem is. > > Curtis I believe that the IPNG WG collectively feel that we have that one pretty much licked. Deployment experience will prove it, or will shatter the illusion. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 29 14:33:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA25710; Mon, 29 Sep 1997 14:22:59 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA25703; Mon, 29 Sep 1997 14:22:49 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA23643; Mon, 29 Sep 1997 14:22:46 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA07763 for ; Mon, 29 Sep 1997 14:22:43 -0700 Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id OAA04294; Mon, 29 Sep 1997 14:21:42 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id OAA17566; Mon, 29 Sep 1997 14:21:41 -0700 (MST) Message-Id: <199709292121.OAA17566@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Mon, 29 Sep 1997 14:21:40 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: ipng@sunroof.eng.sun.com Subject: (IPng 4582) Re: Update to RFC 2133 Cc: bound@zk3.dec.com, Harvey Thompson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4255 I am trying to sort out all the discussions about RFC 2133 and hostnmae lookups, going back through the email to the list starting in July, and am quickly getting confused. [In Jim Bound's message of Sep 25, 11:58pm he writes:] > 2. ISVs (this is recursive from above) want to do a simple add/replace > operation to initially support IPv6/IPv4 interoperation and not > buy into the entire function of getaddrinfo() for existing apps. I don't agree with this. Let me first step back and assume I want to port an existing application that runs with IPv4 to IPv6. Let's assume that the application does not do really wierd things like source routing, embedding IP addresses within its data (e.g., FTP), raw sockets, or datalink access (BPF/DLPI). I can do a straightforward conversion of all sockaddr_in{} to sockaddr_in6{}, all AF_INET to AF_INET6, all sin_family to sin6_family, all sin_port to sin6_port, and so on. In fact, one could write a script that does 95% of this. If I call inet_addr(), inet_aton(), or inet_ntoa(), I need to convert these by hand to inet_pton() and inet_ntop(). Assuming I call gethostbyname(), I leave it as is, preceded by res_init(); _res.options |= RES_USE_INET6; (Ignore for just a moment all the known problems with this that have been discussed on the list.) I must also check any uses of the returned h_addr or h_addr_list, and make certain the length used is h_length, and not "4" or "sizeof(in_addr)". I also need to grep for any references to the generic sockaddr{}, as these are sometimes used to hold sockaddr_in{}, but this will not work with sockaddr_in6{}. I am done *but* now my application only compiles on systems that support IPv6, since I now use all the IPv6-specific structures and constants. It still communicates with IPv4-only peers, using IPv4-mapped IPv6 addresses. But what if I want to compile my application on a system without any IPv6 support? Do I leave in all the IPv4 structures and constants, add the IPv6 stuff, and put in dozens of #ifdefs and run-time tests? Yuck. How to create unmaintainable code. Let's first separate the programmers into (1) users (what Jim calls ISVs) who write applications that operate on many flavors of Unix or other operating systems, and (2) vendors who write code just for their own operating system (Sun, Digital, IBM, Microsoft, etc.). I contend that for many years to come, we *users* will all *have to* write applications that compile on both IPv4-only and dual-stack hosts, or our code will not be very portable. Computer vendors can avoid this problem, because they know if and when their OS will provide IPv6 by default, and they only have to worry about their OS. Computer vendors normally don't release source code for users to port to other OSs. But the only way for an application developer (ISV or whatever) to approach the IPv6 world is to modify their application to be protocol- independent, working with either IPv4 or IPv6 (compile time and run time). And the way to do this is to use getaddrinfo(). And if you want to port your code to an OS that doesn't even support IPv6 and/or getaddrinfo(), carry along the sources for getaddrinfo() yourself--there are at least two publicly-available implementations that I know of. But, I can say after porting IPv4 applications to IPv6--TCP, UDP, and even UDP multicast applications--that even getaddrinfo() itself should be avoided. It's too low-level: you have to allocate structures, walk through a linked list, free the structures, etc. You need about six higher-level functions (tcp_connect(), tcp_server(), and some for udp; each about a page of code) to hide the details. Let these functions go through a list of addresses, trying each one until success. That takes care of code that is compiled with IPv6 support but running on a host without an IPv6 stack. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 29 14:50:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA25759; Mon, 29 Sep 1997 14:37:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA25749; Mon, 29 Sep 1997 14:36:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA27137; Mon, 29 Sep 1997 14:36:47 -0700 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA12271 for ; Mon, 29 Sep 1997 14:36:32 -0700 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id RAA26936; Mon, 29 Sep 1997 17:35:51 -0400 (EDT) Message-Id: <199709292135.RAA26936@brookfield.ans.net> To: "Matt Crawford" cc: curtis@ans.net, Curtis Villamizar , ipng@sunroof.eng.sun.com, idr@merit.edu Reply-To: curtis@ans.net Subject: (IPng 4583) Re: BGP and renumbering In-reply-to: Your message of "Mon, 29 Sep 1997 13:37:29 CDT." <199709291837.NAA29373@gungnir.fnal.gov> Date: Mon, 29 Sep 1997 17:35:51 -0400 From: Curtis Villamizar Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1525 In message <199709291837.NAA29373@gungnir.fnal.gov>, "Matt Crawford" writes: > > Renumbering the routers is a cinche by comparison to renumbering > > the customers served by an ISP (who in most cases simply refuse). > > > > What I'm getting at is that IPv6 needs to solve the end system > > problems and don't worry so much about renumbering the intrastructure > > because that's not where the problem is. > > > > Curtis > > I believe that the IPNG WG collectively feel that we have that one > pretty much licked. Deployment experience will prove it, or will > shatter the illusion. > Matt I'm aware of what IPv6 has to offer and I agree on the end system renumbering point. I think you are wasting your time considering implications of dynamicly allocating the AS border (DMZ) addresses to BGP speaking routers and changing these addresses. If the "fix" to make thing more dynamic renumbering friendly takes functionality away from BGP then its counterproductive since you're solving a non-problem in the first place. So please leave the draft-ietf-idr-bgp4-multiprotocol-01.txt draft as is regarding rewriting next hop. Curtis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 29 15:13:06 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA25828; Mon, 29 Sep 1997 15:03:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA25821; Mon, 29 Sep 1997 15:03:19 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA04701; Mon, 29 Sep 1997 15:03:16 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA21039 for ; Mon, 29 Sep 1997 15:03:08 -0700 Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id PAA04386; Mon, 29 Sep 1997 15:02:32 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id PAA17658; Mon, 29 Sep 1997 15:02:31 -0700 (MST) Message-Id: <199709292202.PAA17658@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Mon, 29 Sep 1997 15:02:31 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: ipng@sunroof.eng.sun.com Subject: (IPng 4584) Re: Update to RFC 2133 Cc: bound@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3809 [In Jim Bound's message of Sep 22, 10:23pm he writes:] > > At this point we need to move forward. > Consenus is RES_USE_INET6 option is not the right answer. I agree with this, with regard to the existing kludge to set this option. But I am still not convinced that the functionality provided by RES_USE_INET6 and the gethostbyname() and gethostbyname2() functions is inadequate (i.e., the table on p. 21 of RFC 2133). I was able to implement getaddrinfo() using the existing APIs, returning both IPv6 and IPv4 addresses when AF_UNSPEC was specified, or only one type of address when either AF_INET or AF_INET6 was specified. And if you really don't want IPv4-mapped addresses, just call IN6_IS_ADDR_V4MAPPED() on the result and ignore the address if the macro is true. > We also have consensus that we need the DNS APIs to be thread safe, > and we want to define them here on theee IPng > list and not be handed them via a BIND fix to RES_USE_INET6. I do not agree that we have consensus here. I think everyone would like the DNS APIs to be MT-safe, but I do not think that this list is the place to require this. I think this list is the place to define a new API that handles IPv6 (see below) and require that it be MT-safe. > I also think we have consensus that we don't want write wrappers to make > RES_USE_INET6 or gethostbyname2() work. I'm not sure I agree with this. The first email that started this thread was from Erik on July 23rd, proposing a sethostent_inet6() function that hid the res_init() call and the setting of RES_USE_INET6 option in a wrapper. Erik noted that what this did not address was the MT-safety issue. > ALso I feel XNET will work with us to absorb the Thread Safety of the > APIs on that tract too. I agree. > I think the following from Erik will work: > > struct dynhostent *gethostbynameafopt(char *name, int af, int options); > void freedynhostent(struct dynhostent *); > > These interfaces are MT safe without introducing the notion of > a context to the programmer. I like these functions, other than the name (I'd opt for getdynhostent()). I also wonder why the structure name changes, when the email from Harvey Thompson on Sept. 24th showed this structure as identical to the existing hostent{}? Just leave the structure as the existing hostent{}, and the term "dyn" in the two function names indicates that the storage is dynamically allocated. > What we need to define now is what is in the "int options" as a > parameter for gethosbynameafopt(). Correct. And the semantics of this function for the two "af" values of AF_INET and AF_INET6, along with the various options. > ALso getaddrinfo() can still be used > by calling gethostbynameafopt() and freedynhostent() so it is using a MT > safe funtion which gethostbyname2 is not. That sounds fine too. I think the assumption all along for getaddrinfo() has been that it is only MT-safe if the underlying functions are MT-safe. (I say "assumption" because I don't think either Posix.1g or RFC 2133 address this.) > But we are also saying that gethostbyname() will only return IPv4 > addresses forever? No. I think we should leave gethostbyname() and gethostbyname2() *alone*, that is, leave them as defined in RFC 2133, and as implemented in BIND 4.9.4, 4.9.5, 4.9.6, and 8.1. Perhaps make them deprecated as soon as the new getdynhostent()/freedynhostent() are defined and implemented. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 29 20:27:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA26066; Mon, 29 Sep 1997 20:20:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA26059; Mon, 29 Sep 1997 20:19:52 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA07976; Mon, 29 Sep 1997 20:19:52 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA16493 for ; Mon, 29 Sep 1997 20:19:48 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id XAA27900; Mon, 29 Sep 1997 23:11:08 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA32044; Mon, 29 Sep 1997 23:11:06 -0400 Message-Id: <9709300311.AA32044@wasted.zk3.dec.com> To: "W. Richard Stevens" Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com, Harvey Thompson Subject: (IPng 4585) Re: Update to RFC 2133 In-Reply-To: Your message of "Mon, 29 Sep 1997 14:21:40 PDT." <199709292121.OAA17566@kohala.kohala.com> Date: Mon, 29 Sep 1997 23:11:06 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1500 Richard, I agree with all your sentiments, except about ISVs. I have ported code to support IPv4 and IPv6. I even ported something this weekend with getaddrinfo(). I am glad you pointed that out about getaddrinfo() too. But I have two ISVs that are porting now their apps using our IPv4/IPv6 stack. First complaint was res_init etc.. So I won't beat a dead horse, but that MUST GO AWAY. These apps are significant and not minor ISVs, but major players. We gave both these ISVs a cheat sheet and what you said can't be done is being done. So I have data that says counter to what your saying. Granted if RFC 2133 or BIND 8.1.1 did not do something needed we made it work. I'd rather not keep doing this as a product engineer. Please read Tim Hartricks last mail on this subject. I think Tim is pretty close to where we need to go and I will be flexible here. But RFC 2133 needs to be fixed a.s.a.p. its UNACCEPTABLE in its present form for the DNS API parts. The rest is fine for now. I am doing some testing and will respond to Tim's mail Thursday but I think Tim has hit a nice chord in that mail. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 29 21:05:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA26100; Mon, 29 Sep 1997 20:56:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA26093; Mon, 29 Sep 1997 20:56:47 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA14150; Mon, 29 Sep 1997 20:56:46 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA26104 for ; Mon, 29 Sep 1997 20:56:42 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id XAA30471; Mon, 29 Sep 1997 23:45:23 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA32709; Mon, 29 Sep 1997 23:45:22 -0400 Message-Id: <9709300345.AA32709@wasted.zk3.dec.com> To: "W. Richard Stevens" Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 4586) Re: Update to RFC 2133 In-Reply-To: Your message of "Mon, 29 Sep 1997 15:02:31 PDT." <199709292202.PAA17658@kohala.kohala.com> Date: Mon, 29 Sep 1997 23:45:22 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4530 Richard, >But I am still not convinced that the functionality provided by >RES_USE_INET6 and the gethostbyname() and gethostbyname2() functions >is inadequate (i.e., the table on p. 21 of RFC 2133). I was able to >implement getaddrinfo() using the existing APIs, returning both IPv6 >and IPv4 addresses when AF_UNSPEC was specified, or only one type of >address when either AF_INET or AF_INET6 was specified. And if you >really don't want IPv4-mapped addresses, just call IN6_IS_ADDR_V4MAPPED() >on the result and ignore the address if the macro is true. I saw this too. The issue is that RES_USE_INET6 if used cannot be thread safe. >> We also have consensus that we need the DNS APIs to be thread safe, >> and we want to define them here on theee IPng >> list and not be handed them via a BIND fix to RES_USE_INET6. >I do not agree that we have consensus here. I think everyone would like >the DNS APIs to be MT-safe, but I do not think that this list is the place >to require this. I think this list is the place to define a new API that >handles IPv6 (see below) and require that it be MT-safe. WHAT??? I 100% don't agree with you on both counts. Folks do want MT safe and doing it here makes compelete sense to me. In addition it is the right thing to do to address the MT safe issue as engineers working on this spec to fix it with an RFC 2133 + UPDATE. >> I also think we have consensus that we don't want write wrappers to make >> RES_USE_INET6 or gethostbyname2() work. >I'm not sure I agree with this. The first email that started this thread >was from Erik on July 23rd, proposing a sethostent_inet6() function that >hid the res_init() call and the setting of RES_USE_INET6 option in a wrapper. >Erik noted that what this did not address was the MT-safety issue. Exactly. >> ALso I feel XNET will work with us to absorb the Thread Safety of the >> APIs on that tract too. >I agree. Thats why I think we can to it here. In fact I think XNET would like us to do all the work here where the experts for IPv6 exist. >> I think the following from Erik will work: >> >> struct dynhostent *gethostbynameafopt(char *name, int af, int options); >> void freedynhostent(struct dynhostent *); >> >> These interfaces are MT safe without introducing the notion of >> a context to the programmer. >I like these functions, other than the name (I'd opt for getdynhostent()). >I also wonder why the structure name changes, when the email from Harvey >Thompson on Sept. 24th showed this structure as identical to the existing >hostent{}? Just leave the structure as the existing hostent{}, and the >term "dyn" in the two function names indicates that the storage is >dynamically allocated. That is an idea I want to think about. >> What we need to define now is what is in the "int options" as a >> parameter for gethosbynameafopt(). >Correct. And the semantics of this function for the two "af" values of >AF_INET and AF_INET6, along with the various options. Yes. >> ALso getaddrinfo() can still be used >> by calling gethostbynameafopt() and freedynhostent() so it is using a MT >> safe funtion which gethostbyname2 is not. >That sounds fine too. I think the assumption all along for getaddrinfo() >has been that it is only MT-safe if the underlying functions are MT-safe. >(I say "assumption" because I don't think either Posix.1g or RFC 2133 >address this.) I think that RFC 2133 updated should address this... >> But we are also saying that gethostbyname() will only return IPv4 >> addresses forever? >No. I think we should leave gethostbyname() and gethostbyname2() *alone*, >that is, leave them as defined in RFC 2133, and as implemented in BIND >4.9.4, 4.9.5, 4.9.6, and 8.1. Perhaps make them deprecated as soon as >the new getdynhostent()/freedynhostent() are defined and implemented. Well first of all I think RFC 2133 will be obsoleted by the next revision of our API update. If we define what we want here we can try to get it implemented by the next IPv6 bake-off which is Dec 97. As far as BIND. I don't care. We have to fix it as IPv6 progresses anyway and so will other vendors. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 29 21:33:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA26150; Mon, 29 Sep 1997 21:25:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA26143; Mon, 29 Sep 1997 21:25:08 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA18057; Mon, 29 Sep 1997 21:25:07 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA02525 for ; Mon, 29 Sep 1997 21:25:05 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id AAA32067; Tue, 30 Sep 1997 00:16:13 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA20873; Tue, 30 Sep 1997 00:16:12 -0400 Message-Id: <9709300416.AA20873@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 4587) Re: Update to RFC 2133 In-Reply-To: Your message of "Fri, 26 Sep 1997 16:07:17 PDT." <199709262307.QAA04495@feller.mentat.com> Date: Tue, 30 Sep 1997 00:16:11 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5422 Tim, I think your attached mail makes a lot of sense. I want to do somethings over the next few days and I think your close to a compromise of sorts, but here is some more thoughts and a response for now. > I know those applications do exist. So I may be able to absorb this > conclusion too if we have an MT safe gethostbyname2() as I said in > previous mail and for the reasons I already stated. I essentially want > some control over whats in the resolver library specified and that can > be used by those who don't want all getaddrinfo() has to offer. >Yes I am fairly certain that there are old pieces of code laying around >that do longjmps without having a easy way to add the memory clean-up. Its not that Tim. Here is the situation. An early adopter of IPv6 that is an ISV has no budget right now for additional heads to get IPv6 ported. But some ISVs know to do this now and get thru the learning curve to ship products to support IPv4 and IPv6 needs to be done now as counter to some views many of us have customers asking for IPv6 right now in the market. What they want to do is port quickly with "spare heads" without investing a lot of time. RFC 2133 is very close and we have them using RES_USE_INET6 and some are using compile time options and some runtime options to not have to maintain two code bases v4 and v6. But many ISVs are using threads and have gotten this to work for the DNS APIs via the vendors. I know Digital and Sun support this for sure. So they want a simple API and MT safety. They have bitten using Threads (as Richard called them users but I call them engineers who build system applications over a stack). From this perspective RES_USE_INET6 is of no use for MT Safety and in fact by definition not safe. >Unfortunately I don't see how you get to a MT safe gethostbyname[2] type >facility without inventing a new set of API's in addition to getaddrinfo >which is MT safe and the existing non MT safe gethostbyname. Well there are a few solutions. >That would mean something like Erik's or Harvey's suggestion. That is >doable but it means inventing another wheel. Yep. But I think it much simpler than those solutions now I propose below. >In one of your previous notes you indicated that ISV's want a simple >replacement for the existing gethostbyname facilities. Simple would imply >that at least initially they don't care about nor do they want to spend >time worrying about MT safety. Thats is only because some vendors hide it from them and make it thread safe without using gethostbyname_r() type calls. They do want it to be thread safe. >Given that I would propose the following. >1) We define a non MT safe version of gethostbyname[2] which can be used > by ISV who are looking for the quick fix. The simplest thing to do here > is simply use gethostbyname2 as it has been defined in the current BIND > distribution. > I believe this would satisfy the original requirements of the API. I am beginning to think we need to leave gethostbyname[2] alone here too ???? but.... >> >> 1. get ipv4 addresses >> 2. get ipv4 mapped addresses >> 3. get ipv6 addresses >> >2) We add whatever options we believe are necessary to getaddrinfo to make > it a complete solution for IPv6 addressing and call that the MT safe > API. I agree. Though if all we need is v4-map test for AI_ opts that can be done as Richard pointed out with a macro defined already. >The problems with this include: >1) Some folks believe that gethostbyname2 is a kludge. Per your argument and others I am hearing here and offline it seems leaving it alone is a good idea. But it is not MT safe. >2) We do not have an IPv4/IPv6 MT safe API on which to base an implementation > of getaddrinfo. True. >These might be showstoppers. I don't know. It would be nice to limit >ourselves to at most two ways to get the job done. An MT safe way and >a non MT safe way. If we could get it down to one (getaddrinfo) that >would probably be ideal from an implementation point of view but maybe >not so ideal from the perspective of ISV's. gethostbyname3(AF_TYPE, NAME, **DYN_BUFFER, BUF_LEN) Parameters 3 and 4 could be NULL and ZERO, if folks don't need MT safety. This also assumes allocation at gethostbyname3() is done in that API routine so the caller does not have to guess at the buffer size. This also could be used by getaddrinfo() function. So all we have to do is determine if we want to keep RES_USE_INET6 and introduce one more api gethostbyname[3]. We can keep gethostbyname[2] but are we polluting the function space for what reason. gethostbyname[3] will do the same thing. Or we could update gethostbyname[2] to do [3] and folks don't have to use the MT safety. gethostbyname2(AF_FAMILY, host, NULL, 0) and it does what it does today, but has the option of thread safety. I guess I strongly want to have MT safety in the IPv6 API it makes no sense to me to not do this in 1997-1998 when most ISVs are moving to support threads quickly. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 06:48:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA26557; Tue, 30 Sep 1997 06:39:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA26550; Tue, 30 Sep 1997 06:39:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA12947; Tue, 30 Sep 1997 06:39:27 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA01029 for ; Tue, 30 Sep 1997 06:39:22 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA03401; Tue, 30 Sep 1997 09:39:13 -0400 (EDT) Message-Id: <199709301339.JAA03401@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4589) I-D ACTION:draft-ietf-ipngwg-trans-tokenring-02.txt Date: Tue, 30 Sep 1997 09:39:13 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3248 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over Token Ring Networks Author(s) : S. Thomas Filename : draft-ietf-ipngwg-trans-tokenring-02.txt Pages : 10 Date : 27-Sep-97 This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-trans-tokenring-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-tokenring-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-trans-tokenring-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970929110405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-tokenring-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-tokenring-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970929110405.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 10:15:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA26775; Tue, 30 Sep 1997 10:04:37 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA26768; Tue, 30 Sep 1997 10:04:32 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id KAA25841 for ; Tue, 30 Sep 1997 10:04:31 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA15843; Tue, 30 Sep 1997 10:02:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA26439; Tue, 30 Sep 1997 03:36:16 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA22484; Tue, 30 Sep 1997 03:36:14 -0700 Received: from zero.aec.at (zero.aec.at [193.170.192.102]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA18170 for ; Tue, 30 Sep 1997 03:36:13 -0700 Received: (qmail 10708 invoked by uid 573); 30 Sep 1997 09:26:41 -0000 To: ipng@sunroof.eng.sun.com Subject: (IPng 4590) Extension header processing in ICMPv6 packets. From: Andi Kleen Date: 30 Sep 1997 11:26:41 +0200 Message-ID: Lines: 46 X-Mailer: Gnus v5.4.41/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2617 [I'm not sure if this is the correct mailing list for this. If not, or when the problem was already discussed please point me to a better place]. Hello, RFC1885 seems to allow extension headers between the IPv6 header and the ICMPv6 header. When an implementation processes the TLV encoded lists in a destopt or hop-by-hop option and it finds an option with the highest bit set it has to send back a ICMP error message. RFC1885 explicitely forbids sending ICMP messages in answer to another ICMP message. Now when my implementation wants to send an ICMP PARAM_PROB message because of an extension header, it doesn't know yet if the message ends with a ICMP header or not. The obvious fix for this would be to skip over all extension headers in the ICMP send routine, and when a ICMP header is found to not send it. Unfortunately this seems to be against the spirit of RFC1883 4.: "... The contents and semantics of each extension header determine whether or not to proceed to the next header. Therefore, extension headers must be processed strictly in the order they appear in the packet; a receiver must not, for example, scan through a packet looking for a particular kind of extension header and process that header prior to processing all preceding ones." I imagine that the obvious solution may break in case of a ESP header. It gets more difficult when the implementation doesn't support ESP. A simple fix would be to never send an ICMP when the original packets has an ESP header, but this doesn't seem to be right neither. The ESP specification doesn't offer any hints on this problem. I looked at two other IPv6 implementations: unh-ipv6 and inria-ipv6 and they both seem to get it wrong. They just don't consider the more extension header case in the 'is-it-a-icmp' test, so they'll send always the ICMP. I imagine this can cause nice ICMP storms, only slowed down a little bit by the ICMP rate limiting. I fixed the implementation I'm playing with (the standard Linux 2.1 IPv6 code) to just skip over the extension headers, and to never send the ICMP when a ESP header was found (Linux doesn't support ESP yet). But I'm not sure if this is correct. Comments? I looks like a bug in the specification for me. -Andi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 11:26:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA26829; Tue, 30 Sep 1997 11:14:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA26822; Tue, 30 Sep 1997 11:13:52 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA02213; Tue, 30 Sep 1997 11:13:47 -0700 Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA17362 for ; Tue, 30 Sep 1997 11:13:35 -0700 Received: (from richier@localhost) by horus.imag.fr (8.8.5/8.8.5) id UAA21261; Tue, 30 Sep 1997 20:12:41 +0200 (MET DST) Date: Tue, 30 Sep 1997 20:12:41 +0200 (MET DST) From: Jean-Luc Richier Message-Id: <199709301812.UAA21261@horus.imag.fr> In-Reply-To: W. Richard Stevens's message as of Sep 29, 15:02. Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "W. Richard Stevens" , ipng@sunroof.eng.sun.com Subject: (IPng 4591) Re: Update to RFC 2133 Cc: bound@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4090 In W. Richard Stevens's message of Sep 29, 15:02, he writes: >[In Jim Bound's message of Sep 22, 10:23pm he writes:] >> >> At this point we need to move forward. >> Consenus is RES_USE_INET6 option is not the right answer. > >I agree with this, with regard to the existing kludge to set this option. > >But I am still not convinced that the functionality provided by >RES_USE_INET6 and the gethostbyname() and gethostbyname2() functions >is inadequate (i.e., the table on p. 21 of RFC 2133). Even if I aggree that using the RES_USE_INET6 flag is not ideal, due to thread problems, I think that we need to keep the solution of having some general global method to know if the preferred network family is AF_INET or AF_INET6. Putting one more argument in all the functions is not the simplest solution for porting. I am working on the Net/FreeBSD INRIA implementation. My experience is that setting the global USE_INET6 flag at the beginning and changing by one editor pass all sockaddr_in into sockaddr_in6 works well. Also there are libraries which include inet functionalities, and using global state simplifies the porting. For exemple I have ported the rpc library and rpc related applications : Some functions use sockaddr input arguments, and therefore it is easy to make an version for both IPv4/IPv6. But other functions have only names as input arguments (or even no input argument, as the function clnt_broadcast). For these functions I had 3 choices: - Add an af argument. This means modifying the interfaces and all the calling programs. - Use a global ``preferred mode flag'' to interpret the names I choosed this solution, For the flag, as RES_USE_INET6 was avalaible, I used it. The effect is that for porting rpc applications, I have do the same thing that for other network applcation : set the RES_USE_INET6 option, change all sockaddr_in to sockaddr_in6. I do not have to look to all the rpc functions calls. It is much simpler that converting the inet_ntoa calls. On the opposite, I also ported the rcmd library. The port was done last year, before the introduction of RES_USE_INET6. I converted all functions to equivalent af-independant functions (rresvport2, later rresvport_af). (In fact I made two successive versions; in the first one every argument had a family and length -- It was the time of the name2addr functions-- The result was highly af-independant, but not very efficient.) The conversion of the calling programs (rsh, rlogin, rmt, ...) was also simple, but the number of lines changed was greater : I had to convert all sockaddr_in to sockaddr_in6, and also all the function calls. Therefore I like this ``global flag'' approach. Also I claims that this discussion on how to make the choice AF_INET/AF_INET6 and how to make the libc functions ``thread-safe'' must not be limited to the gethostby* family. There is a lot of other functions in Unix libraries with the same problems : rpc library, rcmd library, inet libraries in perl, Java (in Java or perl there is the simplification addr == int !!) If we wish to have a smooth transition, we should define a general preferred method to simply port libraries from INET to INET6 : - Use global option ? - add family argument ? address length arguments ? where : first arument, last, after each name/address ? - Throw away the inet functions and redefine a complete af-independant interface (such as saying : use getaddrinfo). Any comments ? jean-Luc Richier -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex Tel : (33) 4 76 82 72 32 Fax : (33) 4 76 82 72 87 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 11:49:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA26871; Tue, 30 Sep 1997 11:39:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA26864; Tue, 30 Sep 1997 11:39:16 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA09500; Tue, 30 Sep 1997 11:39:13 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA24434 for ; Tue, 30 Sep 1997 11:39:08 -0700 Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id LAA07670; Tue, 30 Sep 1997 11:38:19 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id LAA19745; Tue, 30 Sep 1997 11:38:18 -0700 (MST) Message-Id: <199709301838.LAA19745@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 30 Sep 1997 11:38:18 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Jean-Luc Richier , ipng@sunroof.eng.sun.com Subject: (IPng 4592) Re: Update to RFC 2133 Cc: bound@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1493 [In your message of Sep 30, 8:12pm you write:] > > I am working on the Net/FreeBSD INRIA implementation. > ... > For exemple I have ported the rpc library and rpc related applications : > ... > On the opposite, I also ported the rcmd library. I assume this porting that you did was such that the code now compiles under an IPv6 environment only, correct? That's one point I was trying to make yesterday. If this is the goal, then life is simpler. But if we are dealing with "ISVs" who need to compile their code under both IPv4 and IPv6, it's harder. > Also I claims that this discussion on how to make the choice AF_INET/AF_INET6 > and how to make the libc functions ``thread-safe'' must not be limited to > the gethostby* family. That's another point I was trying to make. IMHO this is an IPv6 group and our goal should not be to make the world and BIND thread-safe. We should define new functions that are thread-safe that are needed by IPv6 applications (e.g., getaddrinfo, getnameinfo, getdynhostent), but that's it. Thanks for sharing the information on your porting experiences. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 12:20:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA26907; Tue, 30 Sep 1997 12:02:25 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA26900; Tue, 30 Sep 1997 12:02:05 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA15777; Tue, 30 Sep 1997 12:02:02 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA10217 for ; Tue, 30 Sep 1997 12:01:56 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA01660; Tue, 30 Sep 1997 14:01:45 -0500 Message-Id: <199709301901.OAA01660@gungnir.fnal.gov> To: Francis Dupont Cc: huitema@bellcore.com (Christian Huitema), ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4594) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of Sat, 27 Sep 1997 14:36:04 +0200. <199709271236.OAA06302@givry.inria.fr> Date: Tue, 30 Sep 1997 14:01:45 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1275 > > One of the point that was agreed during the Munich meeting of IPv6 is that > > Site Local addresses should not be used for EGP routing exchanges. > > > > Once again, you make me wonder if we were at the same meeting. I > > find nothing remotely like your statement above in my memory, my > > notes, or the minutes of the meeting I attended. (That was in > > Munich, Bavaria, Germany. Perhaps there are two Munichs?) > > there is no formal agreement but I believe many persons in > the room shared this idea. Christian was closer to the micro... I just replayed the audio. Christian raised the point, the speaker (Erik) rebutted briefly, and the chair cut off the topic. Now Christian declares that it "was agreed during the Munich meeting of IPv6." I can conceive only two explanations for the discrepancy, and since neither is technically relevant, I won't offer them. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 12:21:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA26898; Tue, 30 Sep 1997 12:01:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA26891; Tue, 30 Sep 1997 12:00:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA15394; Tue, 30 Sep 1997 12:00:50 -0700 Received: from fleck. (fleck.iol.unh.edu [132.177.118.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA00348 for ; Tue, 30 Sep 1997 12:00:15 -0700 Received: by fleck. (SMI-8.6/SMI-SVR4) id OAA06024; Tue, 30 Sep 1997 14:54:47 -0400 Date: Tue, 30 Sep 1997 14:54:47 -0400 Message-Id: <199709301854.OAA06024@fleck.> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Andi Kleen Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4593) Extension header processing in ICMPv6 packets. In-Reply-To: References: X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremy McCooey Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1608 Andi, > message. RFC1885 explicitely forbids sending ICMP messages in answer > to another ICMP message. Now when my implementation wants to send First, to clarify, the prohibition is only against the sending of an ICMP error in response to an ICMP _error_ message. Also, the situation you describe with the ESP header can be generalized to any "unknown next header" before the ICMP header, as a node would not know how to proceed to the following header. I think that the nicest solution would be some usage restriction on extension headers in ICMP error messages, like: only those extension headers required of a "full" implementation may be used in ICMP errors, and extension headers may only be used in an ICMP error if the sending node supports all extension headers required of a "full" implementation. Likewise, perhaps a "discard with error" flavor option should not be allowed in an ICMP error packet. In any event, I personally understand the spec to mean "do not generate an ICMP error as the result of processing the ICMP portion of an ICMP error packet." For instance, I wouldn't expect a router to process a packet in its entirety before sending a destination unreachable or time exceeded message.. Jeremy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 12:46:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA26933; Tue, 30 Sep 1997 12:30:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA26926; Tue, 30 Sep 1997 12:28:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA22339; Tue, 30 Sep 1997 12:28:12 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA07739 for ; Tue, 30 Sep 1997 12:27:17 -0700 Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id MAA07802; Tue, 30 Sep 1997 12:27:12 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id MAA19862; Tue, 30 Sep 1997 12:27:12 -0700 (MST) Message-Id: <199709301927.MAA19862@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 30 Sep 1997 12:27:12 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com Subject: (IPng 4595) Re: Update to RFC 2133 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1570 > Date: Fri, 26 Sep 1997 16:07:17 -0700 > From: thartric@mentat.com (Tim Hartrick) > To: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 4570) Re: Update to RFC 2133 > > ... > > The problems with this include: > > 2) We do not have an IPv4/IPv6 MT safe API on which to base an implementation > of getaddrinfo. But if the underlying gethostbyname() is MT-safe, then so is getaddrinfo(), which is why all of the memory returned by getaddrinfo() is dynamically allocated. RFC 2133 does not spell this out explicitly, but if all that's needed is to say this, that's easy to fix. I know that both Digital Unix 4.0 and HP-UX 10.30 state that gethostbyname() is MT-safe and both say they do this using thread-specific data. Solaris 2.6 explicitly says its gethostbyname() is not MT-safe. But you can still write an MT-safe getaddrinfo() for Solaris using gethostbyname_r(), and I have done this. So I think it's trivial to specify that getaddrinfo() and getnameinfo() be MT-safe, and leave it up to the implementation as to how that's done. You could even just have getaddrinfo() allocate its own mutex to protect itself, if nothing better is provided by the underlying system. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 14:17:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA27106; Tue, 30 Sep 1997 14:04:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA27099; Tue, 30 Sep 1997 14:04:33 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA13216; Tue, 30 Sep 1997 14:04:30 -0700 Received: from hq.freegate.net (isdn.freegate.net [205.178.36.9]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA24979 for ; Tue, 30 Sep 1997 14:04:20 -0700 Received: (qmail 15305 invoked by alias); 30 Sep 1997 21:04:13 -0000 Received: from ws206.hq.freegate.net (HELO freegate.com) (205.178.20.206) by ns.hq.freegate.net with SMTP; 30 Sep 1997 21:04:13 -0000 Message-ID: <343169B8.185E6FC3@freegate.com> Date: Tue, 30 Sep 1997 14:06:00 -0700 From: Bob Gilligan Reply-To: gilligan@freegate.com Organization: FreeGate Corporation X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: "W. Richard Stevens" , ipng@sunroof.eng.sun.com Subject: (IPng 4596) Re: Update to RFC 2133 References: <199709301838.LAA19745@kohala.kohala.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1827 W. Richard Stevens wrote: > [In your message of Sep 30, 8:12pm you write:] > > > > I am working on the Net/FreeBSD INRIA implementation. > > ... > > For exemple I have ported the rpc library and rpc related applications : > > ... > > On the opposite, I also ported the rcmd library. > > I assume this porting that you did was such that the code now compiles > under an IPv6 environment only, correct? > > That's one point I was trying to make yesterday. If this is the goal, > then life is simpler. But if we are dealing with "ISVs" who need to > compile their code under both IPv4 and IPv6, it's harder. You are quite correct that ISVs who need to develop code that is portable to multiple pre-IPv6 systems have a harder job than those writing exclusively for new dual-mode systems. The latter can simply change their programs to use the new API. But the ISVs have lots of problems completely unrelated to IPv6 in maintaining code that is portable across platform. Becuase of different OS features and subtle differences in the socket interface, these programs are usually full of #ifdefs for each platform. The smart ISVs already have implemented abstraction layers that keep the OS-specific details hidden from the main application. By requiring just one new #ifdef for IPv6, we are really offering them the minimal amount of change necessary to support IPv6. I don't think we need to try to do any better than this. Bob. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 14:59:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA27156; Tue, 30 Sep 1997 14:49:22 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA27149; Tue, 30 Sep 1997 14:49:13 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA25111; Tue, 30 Sep 1997 14:49:11 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA16124 for ; Tue, 30 Sep 1997 14:46:23 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA26219; Tue, 30 Sep 97 14:44:21 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id OAA02383; Tue, 30 Sep 1997 14:46:31 -0700 Date: Tue, 30 Sep 1997 14:46:31 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199709302146.OAA02383@feller.mentat.com> To: rstevens@kohala.com Subject: (IPng 4597) Re: Update to RFC 2133 Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1980 Richard, > > But if the underlying gethostbyname() is MT-safe, then so is getaddrinfo(), > which is why all of the memory returned by getaddrinfo() is dynamically > allocated. RFC 2133 does not spell this out explicitly, but if all that's > needed is to say this, that's easy to fix. > Possibly. I think my problem in this case is that I have been operating under some false assumptions with respect to how MT safety needs to be implemented. > I know that both Digital Unix 4.0 and HP-UX 10.30 state that gethostbyname() > is MT-safe and both say they do this using thread-specific data. Solaris 2.6 > explicitly says its gethostbyname() is not MT-safe. But you can still write > an MT-safe getaddrinfo() for Solaris using gethostbyname_r(), and I have > done this. > Specifically, I was assuming that thread-specifc data was not something that was broadly available and that the existing resolver API's (gethostbyname, etc) would need to be extended ala gethostbyname_r to become MT safe. Clearly that is not the case on all platforms. Given that some platforms already support MT safe implementations of the get- hostbyname API's I see even less reason to event another wheel to deal with MT safety. The existing getaddrinfo/getnameinfo entry points should be sufficient. > So I think it's trivial to specify that getaddrinfo() and getnameinfo() > be MT-safe, and leave it up to the implementation as to how that's done. > You could even just have getaddrinfo() allocate its own mutex to protect > itself, if nothing better is provided by the underlying system. > Agreed. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 17:28:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA27376; Tue, 30 Sep 1997 17:16:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA27365; Tue, 30 Sep 1997 17:15:08 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA03912; Tue, 30 Sep 1997 17:15:04 -0700 Received: from granola.cisco.com (granola.cisco.com [171.69.95.100]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA16514 for ; Tue, 30 Sep 1997 12:59:03 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by granola.cisco.com (8.6.12/8.6.5) with ESMTP id MAA08753; Tue, 30 Sep 1997 12:58:30 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA22488; Tue, 30 Sep 1997 12:58:30 -0700 (PDT) Date: Tue, 30 Sep 1997 12:58:30 -0700 (PDT) Message-Id: <199709301958.MAA22488@pedrom-ultra.cisco.com> From: Pedro Marques To: "Matt Crawford" Cc: curtis@ans.net, ipng@sunroof.eng.sun.com, idr@merit.edu Subject: (IPng 4599) Re: BGP and renumbering In-Reply-To: <199709291837.NAA29373@gungnir.fnal.gov> References: <199709291746.NAA25935@brookfield.ans.net> <199709291837.NAA29373@gungnir.fnal.gov> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3526 >>>>> "Matt" == Matt Crawford writes: >> Renumbering the routers is a cinche by comparison to >> renumbering the customers served by an ISP (who in most cases >> simply refuse). >> >> What I'm getting at is that IPv6 needs to solve the end system >> problems and don't worry so much about renumbering the >> intrastructure because that's not where the problem is. >> >> Curtis Matt> I believe that the IPNG WG collectively feel that we have Matt> that one pretty much licked. >From the Munich meeting i'd the impression that we still don't know how to solve the problem of renumbering hosts. If i remember correctly Erik Nordmark's site-prefixes draft wasn't fully discussed in the meeting due to lack of time and some of the issues it raises didn't seam close to be settled. But regardless of the actual solution, one thing the draft clearly points out is that simply being able to dynamic learn and reconfigure the addresses that an host is using is not enought. Also, talking about renumbering in the IPv6 context is a difficult problem since everybody seams to have it's own definition of what renumbering means. It would be nice if the IPng WG could agree on a definition. One could probably obtain a clear one by answering the questions: "what renumbers ?", "how often ?" and "why ?". Maybe it would be useful if we actually step back for a bit and try to list the problems we must solve in term of address visibility (i.e. what causes the routing table explosion problem). Assume for a while that the following list is the smallest list that covers the problems that really must be solved: 1) Leaf site changing providers. 2) Multihoming of leaf sites. If we look at multihoming, the requirements are ability to do load-balancing and fallback. I would argue that this really has nothing to do with renumbering. Fallback can be accomplished by either injecting the failing prefix temporarily via the working paths or by changing the addresses in use by the connection, which are pretty different cenarios from renumbering a site. So from the list above, and eliminating multihoming from the problems renumbering must solve we end up with a pretty simple definition of renumbering: readdressing of leaf sites when they change provider. Which is tipically an infrequent operation and can accomodate grace periods of weeks. There are several conclusion we can take from this hypothesis: . Renumbeing eBGP connections is not a problem since changing the eBGP peering is the reason for renumbering in the first place. . Operations like off-line resigning all DNS records for a site are pretty acceptable. . The focus should pretty much be on being able to perform the real problem at hands... Of course none of the above holds if the list of problems to solve is really much different from what i enumerated but i do believe people should think twice before adding things to that list. Needless to say that trying to solve world hunger is not always productive. Matt> Deployment experience will Matt> prove it, or will shatter the illusion. Indeed. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 17:29:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA27363; Tue, 30 Sep 1997 17:15:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA27354; Tue, 30 Sep 1997 17:12:59 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA03328; Tue, 30 Sep 1997 17:12:55 -0700 Received: from mailhost2.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA16132 for ; Tue, 30 Sep 1997 12:57:37 -0700 Received: from mailhost.BayNetworks.COM ([141.251.211.49] (may be forged)) by mailhost2.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id MAA17674 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id VAA26789 Posted-Date: Tue, 30 Sep 1997 21:53:09 +0200 (MET DST) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id PAA16510; Tue, 30 Sep 1997 15:56:44 -0400 for Message-Id: <3.0.32.19970930155311.006dd8c4@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 30 Sep 1997 15:53:16 -0400 To: Andi Kleen From: Dimitry Haskin Subject: (IPng 4598) Re: Extension header processing in ICMPv6 packets. Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2974 At 11:26 AM 9/30/97 +0200, Andi Kleen wrote: >[I'm not sure if this is the correct mailing list for this. >If not, or when the problem was already discussed please >point me to a better place]. > >Hello, > >RFC1885 seems to allow extension headers between the IPv6 header >and the ICMPv6 header. When an implementation processes the TLV >encoded lists in a destopt or hop-by-hop option and it finds an >option with the highest bit set it has to send back a ICMP error >message. RFC1885 explicitely forbids sending ICMP messages in answer >to another ICMP message. Now when my implementation wants to send >an ICMP PARAM_PROB message because of an extension header, it doesn't >know yet if the message ends with a ICMP header or not. > Actually, it is forbidden to send ICMP *error* messages in response to ICMP *error* messages. Is it necessary to allow extension headers in ICMP error messages? It seems that if we disallow extension headers in that messages it would solve the problem. Dimitry >The obvious fix for this would be to skip over all extension headers >in the ICMP send routine, and when a ICMP header is found to not send >it. Unfortunately this seems to be against the spirit of RFC1883 4.: > >"... The contents and semantics of each extension header determine >whether or not to proceed to the next header. Therefore, extension >headers must be processed strictly in the order they appear in the >packet; a receiver must not, for example, scan through a packet >looking for a particular kind of extension header and process that >header prior to processing all preceding ones." > >I imagine that the obvious solution may break in case of a ESP header. >It gets more difficult when the implementation doesn't support ESP. >A simple fix would be to never send an ICMP when the original packets >has an ESP header, but this doesn't seem to be right neither. The ESP >specification doesn't offer any hints on this problem. > >I looked at two other IPv6 implementations: unh-ipv6 and inria-ipv6 >and they both seem to get it wrong. They just don't consider the >more extension header case in the 'is-it-a-icmp' test, so they'll >send always the ICMP. I imagine this can cause nice ICMP storms, >only slowed down a little bit by the ICMP rate limiting. > >I fixed the implementation I'm playing with (the standard Linux 2.1 >IPv6 code) to just skip over the extension headers, and to never >send the ICMP when a ESP header was found (Linux doesn't support ESP yet). >But I'm not sure if this is correct. > >Comments? I looks like a bug in the specification for me. > >-Andi > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 18:42:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA27471; Tue, 30 Sep 1997 18:31:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA27464; Tue, 30 Sep 1997 18:31:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA19380; Tue, 30 Sep 1997 18:31:37 -0700 Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA13492 for ; Tue, 30 Sep 1997 18:31:37 -0700 Received: from duplo.sm.sony.co.jp (root@duplo.sm.sony.co.jp [133.138.10.3]) by onoe2.sm.sony.co.jp (8.8.5/Sony6.1MX) with ESMTP id KAA29262; Wed, 1 Oct 1997 10:31:24 +0900 (JST) Received: from sm.sony.co.jp (onoe@localhost [127.0.0.1]) by duplo.sm.sony.co.jp (8.8.5/8.8.5) with ESMTP id KAA14382; Wed, 1 Oct 1997 10:31:22 +0900 (JST) Message-Id: <199710010131.KAA14382@duplo.sm.sony.co.jp> To: dhaskin@baynetworks.com Cc: ak@muc.de, ipng@sunroof.eng.sun.com Subject: (IPng 4600) Re: Extension header processing in ICMPv6 packets. In-Reply-To: Your message of "Tue, 30 Sep 1997 15:53:16 -0400" References: <3.0.32.19970930155311.006dd8c4@pobox> X-Mailer: Mew version 1.52 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 01 Oct 1997 10:31:12 +0900 From: Atsushi Onoe Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 722 > Actually, it is forbidden to send ICMP *error* messages in response to ICMP > *error* messages. Is it necessary to allow extension headers in ICMP error > messages? It seems that if we disallow extension headers in that messages > it would solve the problem. At least, AH would be necessary to protect against ICMP unreach attack. Atsushi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 19:39:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA27522; Tue, 30 Sep 1997 19:30:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA27515; Tue, 30 Sep 1997 19:30:47 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA27823; Tue, 30 Sep 1997 19:30:45 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA26308 for ; Tue, 30 Sep 1997 19:30:47 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id WAA10440; Tue, 30 Sep 1997 22:24:52 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA19378; Tue, 30 Sep 1997 22:24:48 -0400 Message-Id: <9710010224.AA19378@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: rstevens@kohala.com, ipng@sunroof.eng.sun.com Subject: (IPng 4601) Re: Update to RFC 2133 In-Reply-To: Your message of "Tue, 30 Sep 1997 14:46:31 PDT." <199709302146.OAA02383@feller.mentat.com> Date: Tue, 30 Sep 1997 22:24:48 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3058 Tim, >Given that some platforms already support MT safe implementations of the get- >hostbyname API's I see even less reason to event another wheel to deal with >MT safety. The existing getaddrinfo/getnameinfo entry points should be >sufficient. Not. There are two issues at hand: 1. Vendor - Each of us have to merge our threads strategy into each new resolver BIND release. This can be avoided if the underlying APIs are by definiition MT Safe via the IPv6 APIs. It saves cost for each vendor. And if anyone who is not a vendor doing this tells me it doesn't I will say you don't know what your talking about and speaking from a perceived opinion not a real one. 2. ISVs have an actual gurantee that the API is thread safe in a uniform manner across all platforms. I would rather use the same MT safe API on each platform for IPv6, than have to assume the same behavior on each platform. getaddrinfo() is a red herring. It has nothing to do with whether we have a MT safe API that is a simple replacement for gethostbyname(). Lets not loose site of that discussion either. >> So I think it's trivial to specify that getaddrinfo() and getnameinfo() >> be MT-safe, and leave it up to the implementation as to how that's done. >> You could even just have getaddrinfo() allocate its own mutex to protect > itself, if nothing better is provided by the underlying system. Excuse me but what is trivial as an academic excercise or for a one time program as an example is far different than "shipping" a complete operating system that must support APIs as a "product", which today should support multiplatform interoperability for ISVs. And when that API supports 100,000's of users whose business depends on its use. For one thing Richard and I are coming from a completely different set of needs, hence, we may never agree on what is required. We hopefully can resolve it here. I hope none of this push back is because folks don't want to change RFC 2133 because its an info RFC, or because they have some implementations developed or some other absurd reason. That right now is not a good reason to not fix the core issue which is we need a simple replacement for gethostbyname() for IPv6 that is MT safe. I don't take to well to folks pushing getaddrinfo() down ours or the ISVs throat, who are not vendors shipping products. So far (except for Tim ??) I have not seen one major vendor on this list say they don't think we need this feature. I think that says something too. I also have not seen one ISV say they don't need this either, or say they will use getaddrinfo(). /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 19:55:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA27533; Tue, 30 Sep 1997 19:46:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA27526; Tue, 30 Sep 1997 19:46:24 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA29523; Tue, 30 Sep 1997 19:46:24 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA29928 for ; Tue, 30 Sep 1997 19:46:14 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id WAA17525; Tue, 30 Sep 1997 22:37:48 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA21303; Tue, 30 Sep 1997 22:37:36 -0400 Message-Id: <9710010237.AA21303@wasted.zk3.dec.com> To: gilligan@freegate.com Cc: "W. Richard Stevens" , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 4602) Re: Update to RFC 2133 In-Reply-To: Your message of "Tue, 30 Sep 1997 14:06:00 PDT." <343169B8.185E6FC3@freegate.com> Date: Tue, 30 Sep 1997 22:37:36 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2737 >> I assume this porting that you did was such that the code now compiles >> under an IPv6 environment only, correct? >> That's one point I was trying to make yesterday. If this is the goal, >> then life is simpler. But if we are dealing with "ISVs" who need to >> compile their code under both IPv4 and IPv6, it's harder. >You are quite correct that ISVs who need to develop code that is portable to >multiple pre-IPv6 systems have a harder job than those writing exclusively for new >dual-mode systems. The latter can simply change their programs to use the new >API. This is true. >But the ISVs have lots of problems completely unrelated to IPv6 in >maintaining code that is portable across platform. Becuase of different OS >features and subtle differences in the socket interface, these programs are usually >full of #ifdefs for each platform. The smart ISVs already have implemented >abstraction layers that keep the OS-specific details hidden from the main >application. By requiring just one new #ifdef for IPv6, we are really offering >them the minimal amount of change necessary to support IPv6. I don't think we need >to try to do any better than this. Agreed. The ISVs we are working with are doing exactly this and we have made RFC 2133 work, but not because it works from the spec because we fixed it. Most ISVs also have moved to support threads when they did this too, with a combination of pthreads and dealing with vendor extensions. Whats broke is gethostbyname2() is not MT safe and RES_USE_INET6 is not either. I don't see how your mail helps here? RES_USE_INET6 is not MT safe even before we discuss the API issue. By your reasoning above the ISV does not want all systems shipping with IPv6 ON or OFF, but by a compile or run time symbolic constant (and it does not have to be a #ifdef, but if anyone thinks #ifdefs can be totally avoided that is not reality) so the implementation knows if a dual stack is present. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 30 22:45:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA27696; Tue, 30 Sep 1997 22:36:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA27689; Tue, 30 Sep 1997 22:36:07 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA18434; Tue, 30 Sep 1997 22:36:00 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA05959 for ; Tue, 30 Sep 1997 22:35:58 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA28624; Tue, 30 Sep 97 22:34:13 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id WAA02565; Tue, 30 Sep 1997 22:36:23 -0700 Date: Tue, 30 Sep 1997 22:36:23 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199710010536.WAA02565@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 4603) Re: Update to RFC 2133 Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3842 Jim, > > 1. Vendor - Each of us have to merge our threads strategy into each > new resolver BIND release. This can be avoided if the underlying > APIs are by definiition MT Safe via the IPv6 APIs. It saves > cost for each vendor. And if anyone who is not a vendor doing > this tells me it doesn't I will say you don't know what > your talking about and speaking from a perceived opinion > not a real one. > I feel your pain. I understand the problem of trying make a product out of public domain code. However, isn't this really an issue that can get worked out between the ISC/Paul Vixie and the contributors to that development effort. Wouldn't it be more appropriate to simply push the BIND implementation toward a threads model on which Digital, HP, Sun and the other ISC contributors can agree. I would find it pretty tragic if the threads model on all these platforms were sufficiently incompatible as to make this an impossibility. Once again I have never seen any of this code so it is entirely possible (actually probable) that I am completely off base. > getaddrinfo() is a red herring. It has nothing to do with whether we > have a MT safe API that is a simple replacement for gethostbyname(). > Lets not loose site of that discussion either. > I guess the problem that I see is that everyone of the proposals for an MT safe replacement of gethostbyname that I have seen have not been particularly simple. They have all required a matching free function to deal with the freeing of the storage. The exception is the gethostby- name_r variants of the traditional functions which require that the user pass in the storage. Once you have reconciled yourself to the need for the free function then the difference between using getaddrinfo/getnameinfo and one of the MT safe gethostbyname variants which have been proposed on this list is pretty slim. Approximately the same amount of code needs to be moved around in the application to deal with the free'ing of the storage. The rest seems like window dressing to me. > > I hope none of this push back is because folks don't want to change RFC > 2133 because its an info RFC, or because they have some implementations > developed or some other absurd reason. That right now is not a good > reason to not fix the core issue which is we need a simple replacement > for gethostbyname() for IPv6 that is MT safe. I don't take to well to > folks pushing getaddrinfo() down ours or the ISVs throat, who are > not vendors shipping products. So far (except for Tim ??) I have > not seen one major vendor on this list say they don't think we need this > feature. I think that says something too. I also have not seen one ISV > say they don't need this either, or say they will use getaddrinfo(). > I certainly am not wedded to RFC 2133. If it is broken we should fix it. My only point is that we only need one set of MT safe API's. Currently, getaddrinfo/getnameinfo can fill that need. If those are viewed as too complicated or have other faults then they should be punted out of the document entirely and replaced with an appropriate set of MT safe API's. There have been a couple of reasonable proposals put forth for an MT safe gethostbyname[2] API which I believe will work. If there is consensus that one of them is necessary then I would say that getaddrinfo/getnameinfo are not necessary and should be removed. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------