From owner-ipng@sunroof.eng.sun.com Mon Apr 2 03:11:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32ABFIm018475 for ; Mon, 2 Apr 2001 03:11:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32ABFag018474 for ipng-dist; Mon, 2 Apr 2001 03:11:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32AB6Im018467 for ; Mon, 2 Apr 2001 03:11:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12012 for ; Mon, 2 Apr 2001 03:11:05 -0700 (PDT) Received: from burp (burp.tkv.asdf.org [212.16.99.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA22442 for ; Mon, 2 Apr 2001 03:11:04 -0700 (PDT) Received: (from msa@localhost) by burp (8.9.3/8.9.3/Debian 8.9.3-21) id NAA30803; Mon, 2 Apr 2001 13:16:09 +0300 Date: Mon, 2 Apr 2001 13:16:09 +0300 Message-Id: <200104021016.NAA30803@burp> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: Can we have id part for host address unique on link? Reply-to: Markku.Savela@iki.fi References: <20010317174559.069AC7E73@starfruit.itojun.org> <200103182005.WAA22497@burp> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A while back on this list I said > Why cannot id's on link be simply defined as: > > - Any active normal id on the link can be assigned only to one host at > at a time. > > - in ADDRCOF, DAD would simply reduce to a question: is the id part of > the address same as one of my assigned ids? It would not matter > which prefix you use to do the DAD. > > - neighbor discovery would not need any changes. That would still use > full addresses. > > What are the objections against above simple fix? What breaks? Can we please have this change? Other solutions seem extremely messy (multiple DAD's, and other complexities). Mostly, RFC-2462 change... What I have experimentally coded as "defending of my id" - if system sees DAD for an address, only ID part is compared (prefix ingored). If id is tentative, declare it as duplicate. If id is already assigned to me with some prefix, I send NA as a reply (regardles whether the prefix in DAD is actually used by me or not). - if I see a valid NA, which matches my id: 1) if my id is tentative, declare it duplace. 2) if NA is for my assigned address (prefix+id), ignore it (obviously, two hosts have have same address on link, bad situation) 3) if NA is not for my assigned address (id matches, but prefix does not), process it as normal NA. => as long as I never see this prefix in RA (with A=1), things work fine. To make it easier for configuring manual permanent IPv6 addresses for some known servers, it might be good to put some range of values in the ID part aside for that purpose? prefix::[1-1023]? (And change rules of randomly generated id's to avoid this range). -------------------------------------------------------------------- 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 Apr 2 06:25:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32DPZIm018710 for ; Mon, 2 Apr 2001 06:25:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f32DPYpf018709 for ipng-dist; Mon, 2 Apr 2001 06:25:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f32DPMIm018699 for ; Mon, 2 Apr 2001 06:25:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11548 for ; Mon, 2 Apr 2001 06:25:22 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28127 for ; Mon, 2 Apr 2001 06:25:21 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA23303; Mon, 2 Apr 2001 08:25:18 -0500 (CDT) Message-Id: <200104021325.IAA23303@gungnir.fnal.gov> To: Stig =?UNKNOWN?Q?Ven=E5s?= Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: an unplanned benefit of IPv6 In-reply-to: Your message of Sat, 31 Mar 2001 10:07:17 +0200. <20010331100717.A2250@itea.ntnu.no> Date: Mon, 02 Apr 2001 08:25:18 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think one somehow could make router renumbering actually change > prefixes in filter addresses in the filters, something like that > must be implemented with great care, if it is possible. That was always my expectation, but I didn't want to try to take that big a step right away. -------------------------------------------------------------------- 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 Apr 2 19:57:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f332vmIm020591 for ; Mon, 2 Apr 2001 19:57:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f332vmPe020590 for ipng-dist; Mon, 2 Apr 2001 19:57:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f332vdIm020583 for ; Mon, 2 Apr 2001 19:57:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27899 for ; Mon, 2 Apr 2001 19:57:38 -0700 (PDT) Received: from mx2.itb.ac.id (mx2.itb.ac.id [202.249.47.37]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA02565 for ; Mon, 2 Apr 2001 19:57:29 -0700 (PDT) Received: (qmail 4209 invoked by uid 1003); 3 Apr 2001 02:57:11 -0000 Received: from unknown (HELO students.itb.ac.id) (167.205.22.114) by mx2.itb.ac.id with SMTP; 3 Apr 2001 02:57:11 -0000 Received: (qmail 24227 invoked by uid 1516); 3 Apr 2001 02:57:11 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Apr 2001 02:57:11 -0000 Date: Tue, 3 Apr 2001 09:57:11 +0700 (JAVT) From: Sahatma NP Hasibuan To: ipng@sunroof.eng.sun.com cc: 6bone@ISI.EDU Subject: Implementation Routing IPv6 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a final project (as a requirement to pass my Bachelor degree) about implementation IPv6 in my Telematic Lab. (LAN) at Bandung Institute of Technology (Indonesia) majoring in Routing by using FreeBSD (v4.2) paltform. 1. But, first I have no idea what I should do first. Please, help me to know the step-by-step or tips and tricks. 2. I have no experience in IPv6 especially at socket programming. Do I have to learn and use it to implement routing IPv6? 3. I have read some articel/presentation/publication about overview IPv6 from internet. I think it's not enough to get acknowledge in IPv6. 4. I have no book reference about IPv6. It needs too much money to buy IPv6 book from Internet because of economic crisis in my country. Anyone can tell me how to get it with a low price or maybe free :)? 5. If I have to use routing protocol what kind of routing protocol I can use (RIP, OSPF, IGRP, BGP, IS-IS) and where I can get the source code/software related to it. 6. Does DNS or Multihoming have realtion to Routing aspect? If yes, can you tell me what does DNS and Multihoming mean specially with Routing? The World is Full of Beauty When The Heart is Full of Love Stop Violence and Discrimination Save Our Earth & Re-Foresting Start Here ***************************************** ( * God Bless Us ! * ) ( ** () () ** ) ( * :> ATMA Hs_BUANA Jr.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 Tue Apr 3 02:07:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f3397mIm020917 for ; Tue, 3 Apr 2001 02:07:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f3397lV8020916 for ipng-dist; Tue, 3 Apr 2001 02:07:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f3397cIm020909 for ; Tue, 3 Apr 2001 02:07:38 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16360 for ; Tue, 3 Apr 2001 02:07:38 -0700 (PDT) Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.42]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29315 for ; Tue, 3 Apr 2001 02:07:37 -0700 (PDT) Received: from rami (root@varis.cs.tut.fi [130.230.4.42]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id MAA29798 for ; Tue, 3 Apr 2001 12:07:31 +0300 (EET DST) From: "Rami Lehtonen" To: Subject: AAA for IPv6 draft Date: Tue, 3 Apr 2001 12:08:53 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I was reading through the draft, didn't find any information how the attendant can decode the host-attendant key, if the key was encoded by the AAAH (AAAH SPI). Could someone of you help me with this? Other point is that Section 4.2.3 says that client may request termination by sending an AAA Request message with a zero lifetime. So it seems that the AAA Request message should also list the lifetime option in the 4.2.1 chapter, where all possible options are listed. Regards, Rami Lehtonen -------------------------------------------------------------------- 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 Apr 3 06:13:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33DDMIm021356 for ; Tue, 3 Apr 2001 06:13:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33DDM97021355 for ipng-dist; Tue, 3 Apr 2001 06:13:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33DDCIm021348 for ; Tue, 3 Apr 2001 06:13:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06404 for ; Tue, 3 Apr 2001 06:13:13 -0700 (PDT) Received: from Yellow.japan-telecom.co.jp (Yellow.japan-telecom.co.jp [210.146.35.35]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12886 for ; Tue, 3 Apr 2001 07:13:11 -0600 (MDT) Received: from japan-telecom.co.jp (localhost [127.0.0.1]) by Yellow.japan-telecom.co.jp (3.7W-Yellow) with ESMTP id WAA01890; Tue, 3 Apr 2001 22:05:18 +0900 (JST) Received: (from root@localhost) by japan-telecom.co.jp (3.7W-SP340201) id WAA16794; Tue, 3 Apr 2001 22:11:31 +0900 (JST) Received: from unknown [172.18.82.245] by SP340201.japan-telecom.co.jp with SMTP id YAA16792 ; Tue, 3 Apr 2001 22:11:30 +0900 To: joris.dobbelsteen@mail.com, dab@bsdi.com, deering@cisco.com, francis@tahoenetworks.com, kwang1@email.mot.com Cc: ipng@sunroof.eng.sun.com Subject: RE: what is a site? X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010403220934E.tomohide@japan-telecom.co.jp> Date: Tue, 03 Apr 2001 22:09:34 +0900 From: Tomohide Nagashima X-Dispatcher: imput version 20000228(IM140) Lines: 56 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Form David Borman; >> "N" is a integer set N = { n | n is integer , 0=< n =< 2^16 }. > ~~~~ >Why an upper limit? > ... N = {n | n is integer, 0=As long as Site-Local addresses are routable over Link 1, 2 and 3, this >would be OK for me... I think so too. We need to add this for site definition... >I don't see why we should use 'sub-sites'. From my point, this would be >quite a stupid move to use sub-sites, it can cause networks to get quite >messy. So actually, for me, the definition site, would be enough... What I think important is not sub-sites, but the concept of "Full-Site". Please forget "sub-site". With current definition of site, site can inculde site. this is logical matter. Asuume there is one site that has 100 links. If we pick 10 links which are routable each. All node in this network is off-cause routable with site-local address so that network is still site. If we would define Site with only topological matter , site can include site. (but off cause, we would not like to add any other definition for Site.) So, We need to separate two site with another word. Full-Site is what we can do that. Full-Site is vertual concept that has 2^16 links in itself. ISP will allocate prefix not to Site but to Full-Site. (Because Site is too ambiguous thing to allocate prefix) ---- Tomohide Nagashima tomohide@japan-telecom.co.jp -------------------------------------------------------------------- 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 Apr 3 07:08:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33E8OIm021467 for ; Tue, 3 Apr 2001 07:08:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33E8NsJ021466 for ipng-dist; Tue, 3 Apr 2001 07:08:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33E8EIm021459 for ; Tue, 3 Apr 2001 07:08:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12047 for ; Tue, 3 Apr 2001 07:08:14 -0700 (PDT) From: Ivan.Arias-Rodriguez@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11248 for ; Tue, 3 Apr 2001 08:08:13 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f33E8FS07550 for ; Tue, 3 Apr 2001 17:08:15 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 3 Apr 2001 17:08:12 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 17:08:11 +0300 Message-ID: To: ipng@sunroof.eng.sun.com Subject: Retrieving my IPv6 addresses Date: Tue, 3 Apr 2001 17:08:08 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f33E8FIm021460 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all! I'm coding one application in W2000 that needs to know its own IP addresses to send that information to the peer (if anybody knows SCTP, that's what I'm coding). I thought that the function that should do this is getipnodebyname, passing it the hostname of my machine, but that function is not supported by Windows 2000. I'm not sure, but I guess that getaddrinfo does more or less the same... This is the code that prints on the screen the IP addresses: #include #include #include #include #include #include #define IPPROTO_SCTP 132; void main () { char buffer[256], *port = "10000"; WSADATA wsaData; int order; struct addrinfo hints, *addrInfo, *auxAddrInfo; WSAStartup(MAKEWORD(2, 2), &wsaData); gethostname(buffer, sizeof(buffer)); memset(&hints, 0, sizeof(hints)); hints.ai_flags = AI_PASSIVE; hints.ai_family = PF_UNSPEC; hints.ai_socktype = SOCK_DGRAM; hints.ai_protocol = IPPROTO_SCTP; getaddrinfo(buffer, port, &hints, &addrInfo); for (auxAddrInfo = addrInfo; auxAddrInfo != NULL; auxAddrInfo = auxAddrInfo->ai_next) { if (auxAddrInfo->ai_family == PF_INET) printf("IPv4 address: %s.\n", inet_ntoa(((struct sockaddr_in *) auxAddrInfo->ai_addr)->sin_addr)); if (auxAddrInfo->ai_family == PF_INET6) { printf("IPv6 address: "); for (order = 0; order < 16; order = order + 2) { printf("%x", ntohs(*((unsigned short *) &(((struct sockaddr_in6 *) auxAddrInfo->ai_addr)->sin6_addr.s6_addr[order])))); printf((order < 14) ? ":" : ".\n"); } } } return; } When I use ipv6 if, I can see several IPv6 addresses, but using this program I only retrieve IPv4 addresses... What is more, if I modify hints.ai_family = PF_UNSPEC; with hints.ai_family = PF_INET6; I receive the EAI_NONAME error ("No such host is known"). The hostname is the one that gethostname gives me, a real one, so, does this maybe have to do with the DNS server? I really don't know why this happens, but in any case, how can I retrieve the IP address of my machine (and having any which is of IPv6 type)? Also, I'm afraid that there is not yet any support for SOCK_RAW. If I modify hints.ai_socktype = SOCK_DGRAM; with hints.ai_socktype = SOCK_RAW; I receive the EAI_SOCKTYPE error ("The support for the specified socket type does not exist in this address family."). Using raw sockets is vital for my program... is it true that there isn't any support for them yet? Thanks in advance! BR Iván Arias Rodríguez -------------------------------------------------------------------- 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 Apr 3 08:07:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33F7UIm021722 for ; Tue, 3 Apr 2001 08:07:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33F7UVS021721 for ipng-dist; Tue, 3 Apr 2001 08:07:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33F7DIm021714 for ; Tue, 3 Apr 2001 08:07:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09670 for ; Tue, 3 Apr 2001 08:07:13 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16078 for ; Tue, 3 Apr 2001 09:07:11 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id KAA03254 for ; Tue, 3 Apr 2001 10:07:10 -0500 (CDT) Message-Id: <200104031507.KAA03254@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: I-D ACTION:draft-francis-ipngwg-site-def-00.txt In-reply-to: Your message of Tue, 03 Apr 2001 07:51:19 EDT. <200104031151.HAA26917@ietf.org> Date: Tue, 03 Apr 2001 10:07:10 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Since my site is 7 km wide, corner-to-corner, I'm going to choose to regard this draft as indirectly supporting my own cherished opinion that the definition of "site" must be independent of physical space. -------------------------------------------------------------------- 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 Apr 3 12:04:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33J45Im022676 for ; Tue, 3 Apr 2001 12:04:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33J44Mi022675 for ipng-dist; Tue, 3 Apr 2001 12:04:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33J3mIm022668 for ; Tue, 3 Apr 2001 12:03:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07517 for ; Tue, 3 Apr 2001 12:03:47 -0700 (PDT) Received: from quern.epilogue.com (quern.epilogue.com [128.224.1.136]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15365 for ; Tue, 3 Apr 2001 12:03:47 -0700 (PDT) Received: from [128.224.4.111] ([128.224.4.111]:26642 "EHLO kenawang" ident: "IDENT-NOT-QUERIED [port 26642]") by newquern.epilogue.com with ESMTP id <211-175>; Tue, 3 Apr 2001 15:03:31 -0400 Message-Id: <4.2.2.20010403140713.01bd9140@pop.epilogue.com> X-Sender: mrw@pop.epilogue.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 03 Apr 2001 14:07:28 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Fwd: RE: what is a site? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Date: Tue, 03 Apr 2001 09:21:22 -0400 >To: Tomohide Nagashima >From: Margaret Wasserman >Subject: RE: what is a site? >Cc: joris.dobbelsteen@mail.com, dab@bsdi.com, deering@cisco.com, francis@tahoenetworks.com, kwang1@email.mot.com, ipng@sunroof.eng.sun.com > > >I think that this conversation is getting rather far afield... > >>With current definition of site, site can inculde site. this is logical >>matter. Asuume there is one site that has 100 links. If we pick 10 links >>which are routable each. All node in this network is off-cause routable >>with site-local address so that network is still site. If we would >>define Site with only topological matter , site can include site. >>(but off cause, we would not like to add any other definition for Site.) > >All theoretical definitions aside, it is up to the customer, in >cooperation with the ISP to define what a "site" will be. There >will be only one "level" of site (no sub-site or full-site) >because the IPv6 routing architecture does not allow for nested >sites. This is covered by the restriction that sites cannot >overlap (sub-sites would completely overlap full-sites). > >Given the current definitions in the addressing architecture, we >can define a "site" to be a group of nodes whose global addresses >contain the same 48-bit prefix, but this is meaningless. Nodes >are not allowed to know about the boundaries in the IPv6 addressing >architecture, and they may change or be eliminated in the future. > >More importantly, the practical definition of a site is: > >"A group of links between which routers are configured to forward >packets addressed to or from site-local addresses." > >The routers will be explicitly configured by their administrators >to forward (or not forward) site-local information between any >two connected links. In most implementations, this will probably >be accomplished by setting site identifiers to the same value for >links in the same site. Whenever any router is configured to forward >site-local packets between two links, those links are in the same >site. Period. > >It is up to administrators to configure their routers with >consistent prefix information, site identifiers, etc. to produce >well-formed sites that are "convex" and do not overlap. > >Margaret -------------------------------------------------------------------- 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 Apr 3 14:27:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33LRLIm023605 for ; Tue, 3 Apr 2001 14:27:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33LRKc7023604 for ipng-dist; Tue, 3 Apr 2001 14:27:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33LRDIm023590 for ; Tue, 3 Apr 2001 14:27:13 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f33LODT15210 for ipng@sunroof.eng.sun.com; Tue, 3 Apr 2001 14:24:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33B4OIm021123 for ; Tue, 3 Apr 2001 04:04:25 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA25115 for ; Tue, 3 Apr 2001 04:04:24 -0700 (PDT) From: Peter.White@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07843 for ; Tue, 3 Apr 2001 04:04:22 -0700 (PDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f33B4PS13434 for ; Tue, 3 Apr 2001 14:04:25 +0300 (EET DST) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 3 Apr 2001 14:04:21 +0300 Received: by esebh01nok.ntc.nokia.com with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Apr 2001 14:04:20 +0300 Message-ID: <1D1620A986E0D21184210008C7089AEAC1A5F5@hueis02nok> To: sahatma@students.itb.ac.id, ipng@sunroof.eng.sun.com Cc: 6bone@ISI.EDU Subject: RE: Implementation Routing IPv6 Date: Tue, 3 Apr 2001 14:04:19 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Try http://hs247.com , http://www.bieringer.de/linux/IPv6/index.html or one of the many howto's as described earlier. Get a good understanding of IPv6, install it on your machine and create a tunnel, possibly to http://www.freenet6.net and try it out. There are any free routers which can be run under FreeBSD such as zebra (http://www.zebra.org) and mrtd (http://www.mrtd.net. For articles and info, try the RFCs or google for IPv6, whitepapers or whatever. Try them out, if they don't work, post a question on here. PW > -----Original Message----- > From: ext Sahatma NP Hasibuan [mailto:sahatma@students.itb.ac.id] > Sent: 03 April, 2001 3:57 > To: ipng@sunroof.eng.sun.com > Cc: 6bone@ISI.EDU > Subject: Implementation Routing IPv6 > > > > I have a final project (as a requirement to pass my Bachelor > degree) about > implementation IPv6 in my Telematic Lab. (LAN) at Bandung Institute of > Technology (Indonesia) majoring in Routing by using FreeBSD (v4.2) > paltform. > > 1. But, first I have no idea what I should do first. > Please, help me to know the step-by-step or tips and tricks. > > 2. I have no experience in IPv6 especially at socket > programming. > Do I have to learn and use it to implement routing IPv6? > > 3. I have read some articel/presentation/publication about > overview IPv6 > from internet. I think it's not enough to get acknowledge in IPv6. > > 4. I have no book reference about IPv6. It needs too much money to buy > IPv6 book from Internet because of economic crisis in my country. > Anyone can tell me how to get it with a low price or maybe > free :)? > > 5. If I have to use routing protocol what kind of routing > protocol I can > use (RIP, OSPF, IGRP, BGP, IS-IS) and where I can get the source > code/software related to it. > > 6. Does DNS or Multihoming have realtion to Routing aspect? > If yes, can you tell me what does DNS and Multihoming mean > specially > with Routing? > > > The World is Full of Beauty > When > The Heart is Full of Love > > Stop Violence and Discrimination > Save Our Earth & > Re-Foresting Start Here > > ***************************************** > ( * God Bless Us ! * ) > ( ** () () ** ) > ( * :> ATMA Hs_BUANA Jr.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 Tue Apr 3 14:28:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33LS0Im023618 for ; Tue, 3 Apr 2001 14:28:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33LRxL3023617 for ipng-dist; Tue, 3 Apr 2001 14:27:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33LRoIm023610 for ; Tue, 3 Apr 2001 14:27:50 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f33LOod15241 for ipng@sunroof.eng.sun.com; Tue, 3 Apr 2001 14:24:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33EHhIm021509 for ; Tue, 3 Apr 2001 07:17:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25668 for ; Tue, 3 Apr 2001 07:17:43 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16779 for ; Tue, 3 Apr 2001 08:17:42 -0600 (MDT) Received: from kenawang ([192.168.1.66]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA03754; Tue, 3 Apr 2001 07:16:41 -0700 (PDT) Message-Id: <4.2.2.20010403084825.01bd0f00@localhost> X-Sender: mrfpop@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 03 Apr 2001 09:21:22 -0400 To: Tomohide Nagashima From: Margaret Wasserman Subject: RE: what is a site? Cc: joris.dobbelsteen@mail.com, dab@bsdi.com, deering@cisco.com, francis@tahoenetworks.com, kwang1@email.mot.com, ipng@sunroof.eng.sun.com In-Reply-To: <20010403220934E.tomohide@japan-telecom.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that this conversation is getting rather far afield... >With current definition of site, site can inculde site. this is logical >matter. Asuume there is one site that has 100 links. If we pick 10 links >which are routable each. All node in this network is off-cause routable >with site-local address so that network is still site. If we would >define Site with only topological matter , site can include site. >(but off cause, we would not like to add any other definition for Site.) All theoretical definitions aside, it is up to the customer, in cooperation with the ISP to define what a "site" will be. There will be only one "level" of site (no sub-site or full-site) because the IPv6 routing architecture does not allow for nested sites. This is covered by the restriction that sites cannot overlap (sub-sites would completely overlap full-sites). Given the current definitions in the addressing architecture, we can define a "site" to be a group of nodes whose global addresses contain the same 48-bit prefix, but this is meaningless. Nodes are not allowed to know about the boundaries in the IPv6 addressing architecture, and they may change or be eliminated in the future. More importantly, the practical definition of a site is: "A group of links between which routers are configured to forward packets addressed to or from site-local addresses." The routers will be explicitly configured by their administrators to forward (or not forward) site-local information between any two connected links. In most implementations, this will probably be accomplished by setting site identifiers to the same value for links in the same site. Whenever any router is configured to forward site-local packets between two links, those links are in the same site. Period. It is up to administrators to configure their routers with consistent prefix information, site identifiers, etc. to produce well-formed sites that are "convex" and do not overlap. Margaret Margaret Wasserman Director, Device Management Wind River Networks 10 Tara Blvd, Suite 330 Nashua, NH 03062 (603) 897-2067 FAX: (603) 897-2050 mrw@windriver.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 Apr 3 14:28:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33LSWIm023628 for ; Tue, 3 Apr 2001 14:28:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33LSV0s023627 for ipng-dist; Tue, 3 Apr 2001 14:28:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33LSLIm023620 for ; Tue, 3 Apr 2001 14:28:22 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f33LPLa15271 for ipng@sunroof.eng.sun.com; Tue, 3 Apr 2001 14:25:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33Fm3Im021994 for ; Tue, 3 Apr 2001 08:48:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07539 for ; Tue, 3 Apr 2001 08:48:02 -0700 (PDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13940 for ; Tue, 3 Apr 2001 09:48:01 -0600 (MDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id IAA37752 for ; Tue, 3 Apr 2001 08:47:54 -0700 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id IAA26136 for ; Tue, 3 Apr 2001 08:48:00 -0700 Message-ID: <3AC9F058.2B09F735@hursley.ibm.com> Date: Tue, 03 Apr 2001 10:46:32 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipng Subject: Re: I-D ACTION:draft-francis-ipngwg-site-def-00.txt References: <200104031151.HAA26917@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul, > http://www.ietf.org/internet-drafts/draft-francis-ipngwg-site-def-00.txt > This draft proposes the following rigorous definition of a site: > A site is defined as the set of routers that fit inside a hexagonal > shape with a distance of one kilometer between opposite corners. > Any hosts sharing a link with a router in a given site are > considered part of the site. The hexagonal shape is chosen because > it can be tiled while still approximating a circle. > > The administrator is free to decide exactly where to lay the > hexagons. However, they MUST not overlap, and every router MUST be > within the boundary of one and only one hexagon. All stories of a > multi-story building are considered to be in the site covered by the > hexagon. Won't work, can't work. An organisation that happens to span 1.1 of these hexagons, or even 20 of them, is not going to contort itself to meet such a definition. I can't imagine why any campus style organisation would even dream of defining a single campus as more than one site, and what about slightly split campuses? Or campuses with 5 km between their two halves, but running a single network? I think your "north bank/south bank" example shows exactly why any attempt to define a site rigorously is doomed. I think a site is whatever a site network manager says is a site. The scope of site-local is whatever the site network manager says it is. Tell me a good reason why we couldn't run the whole of IBM world-wide as a single site-local scope, if we wanted to? Brian -------------------------------------------------------------------- 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 Apr 3 14:51:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33LpCIm024057 for ; Tue, 3 Apr 2001 14:51:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33LpBXN024056 for ipng-dist; Tue, 3 Apr 2001 14:51:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33LosIm024041 for ; Tue, 3 Apr 2001 14:50:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15549 for ; Tue, 3 Apr 2001 14:50:54 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22593 for ; Tue, 3 Apr 2001 14:50:31 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 3 Apr 2001 14:51:17 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 03 Apr 2001 13:51:33 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 3 Apr 2001 14:51:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4678.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-francis-ipngwg-site-def-00.txt Date: Tue, 3 Apr 2001 14:51:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-francis-ipngwg-site-def-00.txt Thread-Index: AcC8hbX6EsEozRTaSPSOOkeM8MJ9AAAAikGQ From: "Christian Huitema" To: "Brian E Carpenter" , "ipng" X-OriginalArrivalTime: 03 Apr 2001 21:51:33.0609 (UTC) FILETIME=[3FAA8D90:01C0BC88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f33LotIm024042 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Tell me a good reason why we couldn't run the whole of IBM world-wide > as a single site-local scope, if we wanted to? Well, one good reason: you probably need more than 16 bits for numbering your subnets. -------------------------------------------------------------------- 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 Apr 3 15:47:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33MlgIm024330 for ; Tue, 3 Apr 2001 15:47:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33Mlf96024329 for ipng-dist; Tue, 3 Apr 2001 15:47:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33MlVIm024322 for ; Tue, 3 Apr 2001 15:47:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00515 for ; Tue, 3 Apr 2001 15:47:31 -0700 (PDT) Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA21999 for ; Tue, 3 Apr 2001 15:47:30 -0700 (PDT) Received: (cpmta 2202 invoked from network); 3 Apr 2001 15:47:30 -0700 Received: from unknown (HELO dellchan) (208.135.49.132) by smtp.francis.com (209.228.32.71) with SMTP; 3 Apr 2001 15:47:30 -0700 X-Sent: 3 Apr 2001 22:47:30 GMT Message-ID: <001101c0bc8f$ff956560$2000a8c0@dellchan> Reply-To: "Paul Francis" From: "Paul Francis" To: "Tomohide Nagashima" , "Margaret Wasserman" Cc: , , , , , References: <4.2.2.20010403084825.01bd0f00@localhost> Subject: Re: what is a site? Date: Tue, 3 Apr 2001 15:47:01 -0700 Organization: TAHOE Networks MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > More importantly, the practical definition of a site is: > > "A group of links between which routers are configured to forward > packets addressed to or from site-local addresses." > One of the things that confused me about the definition of site is that the first thing I read about it was in the context of the SLA "field" of the IPv6 globally aggregatable address. So I thought that "site" meant "A group of continuous (convex, whatever) links whose address prefixes are identical up to and including the SLA field". This is a different definition from that based on site-local addresses, and I find that confusing. PF -------------------------------------------------------------------- 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 Apr 3 16:46:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33NkNIm024394 for ; Tue, 3 Apr 2001 16:46:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33NkNCS024393 for ipng-dist; Tue, 3 Apr 2001 16:46:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33NkHIm024386 for ; Tue, 3 Apr 2001 16:46:17 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f33NhF015538 for ipng@sunroof.eng.sun.com; Tue, 3 Apr 2001 16:43:15 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33MUJIm024170 for ; Tue, 3 Apr 2001 15:30:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25907 for ; Tue, 3 Apr 2001 15:30:20 -0700 (PDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13840 for ; Tue, 3 Apr 2001 15:30:19 -0700 (PDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id PAA30944; Tue, 3 Apr 2001 15:30:17 -0700 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id PAA18750; Tue, 3 Apr 2001 15:30:17 -0700 Message-ID: <3ACA4DEE.51D7702E@hursley.ibm.com> Date: Tue, 03 Apr 2001 17:25:50 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Christian Huitema CC: ipng Subject: Re: I-D ACTION:draft-francis-ipngwg-site-def-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema wrote: > > > Tell me a good reason why we couldn't run the whole of IBM world-wide > > as a single site-local scope, if we wanted to? > > Well, one good reason: you probably need more than 16 bits for numbering > your subnets. If I knew the answer to that, I probably wouldn't be allowed to tell you, but if that's the only problem I am reassured. The date on Paul's draft has been pointed out to me. Thank you. Good night. Brian -------------------------------------------------------------------- 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 Apr 3 16:45:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33NjtIm024384 for ; Tue, 3 Apr 2001 16:45:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f33Njtom024383 for ipng-dist; Tue, 3 Apr 2001 16:45:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33NjoIm024376 for ; Tue, 3 Apr 2001 16:45:51 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f33NgmY15508 for ipng@sunroof.eng.sun.com; Tue, 3 Apr 2001 16:42:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f33MUCIm024156 for ; Tue, 3 Apr 2001 15:30:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17210 for ; Tue, 3 Apr 2001 15:30:12 -0700 (PDT) Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02662 for ; Tue, 3 Apr 2001 15:30:11 -0700 (PDT) Received: from eagleswings (ssh-sj1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA17081; Tue, 3 Apr 2001 15:29:26 -0700 (PDT) From: "Tony Hain" To: "Margaret Wasserman" , "Tomohide Nagashima" Cc: , , , , , Subject: RE: what is a site? Date: Tue, 3 Apr 2001 15:29:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.2.2.20010403084825.01bd0f00@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would normally let this go, but there has been enough confusion on this subject that it needs to be very clear. Both Margaret and KRE are correct, a site is defined by the boundary of a contiguous routing domain configured by the network administrator (I assume the ISP in Margaret's definition is providing a managed private network or just defensively filtering non-global addresses). It is nothing more, and has no other constraints. If someone were creating documentation and wanted to show a 'typical example' of a site, using a building or campus would be a reasonable way to describe the concept. But there should not be any language in the standards restricting it more than Margaret has here. Tony -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Margaret Wasserman Sent: Tuesday, April 03, 2001 6:21 AM To: Tomohide Nagashima Cc: joris.dobbelsteen@mail.com; dab@bsdi.com; deering@cisco.com; francis@tahoenetworks.com; kwang1@email.mot.com; ipng@sunroof.eng.sun.com Subject: RE: what is a site? I think that this conversation is getting rather far afield... >With current definition of site, site can inculde site. this is logical >matter. Asuume there is one site that has 100 links. If we pick 10 links >which are routable each. All node in this network is off-cause routable >with site-local address so that network is still site. If we would >define Site with only topological matter , site can include site. >(but off cause, we would not like to add any other definition for Site.) All theoretical definitions aside, it is up to the customer, in cooperation with the ISP to define what a "site" will be. There will be only one "level" of site (no sub-site or full-site) because the IPv6 routing architecture does not allow for nested sites. This is covered by the restriction that sites cannot overlap (sub-sites would completely overlap full-sites). Given the current definitions in the addressing architecture, we can define a "site" to be a group of nodes whose global addresses contain the same 48-bit prefix, but this is meaningless. Nodes are not allowed to know about the boundaries in the IPv6 addressing architecture, and they may change or be eliminated in the future. More importantly, the practical definition of a site is: "A group of links between which routers are configured to forward packets addressed to or from site-local addresses." The routers will be explicitly configured by their administrators to forward (or not forward) site-local information between any two connected links. In most implementations, this will probably be accomplished by setting site identifiers to the same value for links in the same site. Whenever any router is configured to forward site-local packets between two links, those links are in the same site. Period. It is up to administrators to configure their routers with consistent prefix information, site identifiers, etc. to produce well-formed sites that are "convex" and do not overlap. Margaret Margaret Wasserman Director, Device Management Wind River Networks 10 Tara Blvd, Suite 330 Nashua, NH 03062 (603) 897-2067 FAX: (603) 897-2050 mrw@windriver.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 -------------------------------------------------------------------- -------------------------------------------------------------------- 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 Apr 3 18:22:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f341M2Im024699 for ; Tue, 3 Apr 2001 18:22:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) id f341M1Y2024698 for ipng-dist; Tue, 3 Apr 2001 18:22:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta5+Sun/8.12.0.Beta5) with ESMTP id f341LqIm024691 for ; Tue, 3 Apr 2001 18:21:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25054 for ; Tue, 3 Apr 2001 18:21:52 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA19124 for ; Tue, 3 Apr 2001 18:21:50 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id BA02846; Wed, 4 Apr 2001 11:21:42 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: "Paul Francis" Cc: ipng@sunroof.eng.sun.com Subject: Re: what is a site? In-Reply-To: Your message of "Tue, 03 Apr 2001 15:47:01 MST." <001101c0bc8f$ff956560$2000a8c0@dellchan> Date: Wed, 04 Apr 2001 11:21:39 +1000 Message-Id: <21686.986347299@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 3 Apr 2001 15:47:01 -0700 From: "Paul Francis" Message-ID: <001101c0bc8f$ff956560$2000a8c0@dellchan> | One of the things that confused me about the definition of site is that the | first thing I read about it was in the context of the SLA "field" of the | IPv6 globally aggregatable address. | | This is a different definition from that based on site-local addresses, and | I find that confusing. Yes, it is a pity that the same word is used in those two ways - they're different without doubt, but often similar enough to seem as if they ought represent the same thing. 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 Fri Apr 6 07:50:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36Eo9K9029936 for ; Fri, 6 Apr 2001 07:50:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36Eo8Od029935 for ipng-dist; Fri, 6 Apr 2001 07:50:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36EnuK9029928 for ; Fri, 6 Apr 2001 07:49:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17198 for ; Fri, 6 Apr 2001 07:49:57 -0700 (PDT) Received: from lepidachrosite.lion-access.net (lepidachrosite.lion-access.net [212.19.217.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06058 for ; Fri, 6 Apr 2001 07:49:56 -0700 (PDT) Received: from xtreme (1Cust66.tnt28.rtm1.nl.uu.net [213.116.150.66]) by lepidachrosite.lion-access.net (I-Lab) with SMTP id 4F7AECB8BE for ; Fri, 6 Apr 2001 14:49:14 +0000 (GMT) From: "Joris Dobbelsteen" To: "IPng WG (E-mail)" Subject: RE: what is a site? Date: Wed, 4 Apr 2001 14:54:31 +0200 Message-ID: <000001c0bea9$2e047b50$0d0ca8c0@Joris2K.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Site-local are simply comparable with the private IP-addresses of IPv4 (10.x.x.x,...), where the Network Administrator bans all internal transports from going out. Only here the config is implemented into the router... There are no big changes that impact higher-level software (e.g. authentication servers), so selection of these servers can be done using IPv6, but still we need something else (e.g. DNS as MS-Win2k-Domain uses).... It simply has nothing to do with this and won't interfere with it in any way... - Joris >-----Original Message----- >From: owner-ipng@sunroof.eng.sun.com >[mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Tony Hain >Sent: Wednesday, 04 April 2001 0:30 >To: Margaret Wasserman; Tomohide Nagashima >Cc: joris.dobbelsteen@mail.com; dab@bsdi.com; deering@cisco.com; >francis@tahoenetworks.com; kwang1@email.mot.com; >ipng@sunroof.eng.sun.com >Subject: RE: what is a site? > > >I would normally let this go, but there has been enough >confusion on this >subject that it needs to be very clear. Both Margaret and KRE >are correct, a >site is defined by the boundary of a contiguous routing domain >configured by >the network administrator (I assume the ISP in Margaret's definition is >providing a managed private network or just defensively >filtering non-global >addresses). It is nothing more, and has no other constraints. > >If someone were creating documentation and wanted to show a 'typical >example' of a site, using a building or campus would be a >reasonable way to >describe the concept. But there should not be any language in >the standards >restricting it more than Margaret has here. > >Tony -------------------------------------------------------------------- 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 Apr 6 12:31:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36JVZK9001177 for ; Fri, 6 Apr 2001 12:31:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36JVVwE001176 for ipng-dist; Fri, 6 Apr 2001 12:31:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36JVJK9001169 for ; Fri, 6 Apr 2001 12:31:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14581 for ; Fri, 6 Apr 2001 12:31:14 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14071 for ; Fri, 6 Apr 2001 12:31:13 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18291; Fri, 6 Apr 2001 15:31:02 -0400 (EDT) Message-Id: <200104061931.PAA18291@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification to Proposed Standard Date: Fri, 06 Apr 2001 15:31:02 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This protocol describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. The extensions are called Inverse Neighbor Discovery. They were originally developed for Frame Relay networks but may also apply to other networks with similar behavior. Working Group Summary This document was originally developed within the ION WG but was moved to the IPng WG because it extended IPv6's Neighbor Discovery. There was concensus in the WG for the extensions defined in this document. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. Note to RFC Editor: In the "References" section, there is a work in progress that needs to be updated: [IPv6-FR] citation needs to have the title change: "Transmission of IPv6 Packets over Frame Relay", and update with its RFC number - RFC 2590, May 1999. -------------------------------------------------------------------- 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 Apr 6 15:18:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36MIEK9001918 for ; Fri, 6 Apr 2001 15:18:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f36MID8T001917 for ipng-dist; Fri, 6 Apr 2001 15:18:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36MI8K9001910 for ; Fri, 6 Apr 2001 15:18:08 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f36MF4Y20848 for ipng@sunroof.eng.sun.com; Fri, 6 Apr 2001 15:15:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f36C00K9029028 for ; Fri, 6 Apr 2001 05:00:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22369 for ; Fri, 6 Apr 2001 05:00:00 -0700 (PDT) Received: from mailrelay1.chek.com (plotnick.chek.com [208.197.227.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA25481 for ; Fri, 6 Apr 2001 04:59:58 -0700 (PDT) Received: (qmail 12705 invoked from network); 6 Apr 2001 11:59:57 -0000 Received: from fancyfeast.chek.com (208.197.227.100) by mailrelay1.chek.com with SMTP; 6 Apr 2001 11:59:57 -0000 Received: (qmail 21556 invoked by uid 99); 6 Apr 2001 11:59:31 -0000 Date: 6 Apr 2001 11:59:31 -0000 Message-ID: <20010406115931.21555.qmail@fancyfeast.chek.com> From: "Emanuel Moreira" To: bzill@microsoft.com, ipng@sunroof.eng.sun.com, marcfiu@yahoo.com, msripv6-users@list.research.microsoft.com, users@ipv6.org X-MASSMAIL: 1.0 X-Originating-IP: [193.137.173.132] Subject: NAPT - dynamic allocation Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Would'nt it be useful to have dinamical alocation of translation addresses in NAPT (Microsoft)? Then LAN's that don't need to be entirely connected to the IPv4 world would only have some IPv4 global addresses for translation and so save a lot of money. Thanks Emanuel Moreira _____________________________________________________________ O e-mail preferido dos portugueses http://www.portugalmail.pt -------------------------------------------------------------------- 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 Apr 6 18:16:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371FTK9002268 for ; Fri, 6 Apr 2001 18:15:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f371FTbk002267 for ipng-dist; Fri, 6 Apr 2001 18:15:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f371FDK9002257 for ; Fri, 6 Apr 2001 18:15:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13175 for ; Fri, 6 Apr 2001 18:15:14 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA23428 for ; Fri, 6 Apr 2001 18:15:13 -0700 (PDT) Received: from 157.54.9.101 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 06 Apr 2001 16:26:40 -0700 (Pacific Daylight Time) Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 6 Apr 2001 17:25:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: NAPT - dynamic allocation Date: Fri, 6 Apr 2001 17:25:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NAPT - dynamic allocation Thread-Index: AcC+lNcrOPD9vW6MQZaJBhqW7MzM6gAYpEOA From: "Brian Zill" To: "Emanuel Moreira" , , , , X-OriginalArrivalTime: 07 Apr 2001 00:25:57.0656 (UTC) FILETIME=[50B53180:01C0BEF9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f371FEK9002258 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Emanuel, > Would'nt it be useful to have dinamical alocation of > translation addresses in NAPT (Microsoft)? Then LAN's that > don't need to be entirely connected to the IPv4 world would > only have some IPv4 global addresses for translation and so > save a lot of money. Yes, that would be a nice feature. The NAT-PT box would then behave more like a traditional NAT, in that you could save external addresses in exchange for diminished inbound connectivity. Our NAPT implementation is a pure research project, and we haven't had the time to really do anything with it for over a year. It was a proof-of-concept more than anything else. So it's unlikely that we'll be adding dynamic allocation of translation addresses anytime soon. But the source is included in the download, so if you want to add that capability, go ahead! --Brian > -----Original Message----- > From: Emanuel Moreira [mailto:emanramor@portugalmail.com] > Sent: Friday, 06 April, 2001 05:00 > To: Brian Zill; ipng@sunroof.eng.sun.com; marcfiu@yahoo.com; > msripv6-users@list.research.microsoft.com; users@ipv6.org > Subject: NAPT - dynamic allocation > > > Would'nt it be useful to have dinamical alocation of > translation addresses in NAPT (Microsoft)? Then LAN's that > don't need to be entirely connected to the IPv4 world would > only have some IPv4 global addresses for translation and so > save a lot of money. > > Thanks > > Emanuel Moreira > > _____________________________________________________________ > > O e-mail preferido dos portugueses http://www.portugalmail.pt > -------------------------------------------------------------------- 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 Apr 6 19:10:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f372AbK9002473 for ; Fri, 6 Apr 2001 19:10:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f372AaDq002472 for ipng-dist; Fri, 6 Apr 2001 19:10:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f372ARK9002465 for ; Fri, 6 Apr 2001 19:10:28 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA23238 for ; Fri, 6 Apr 2001 19:10:27 -0700 (PDT) Received: from sina.com ([202.106.187.166]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA06482 for ; Fri, 6 Apr 2001 19:10:27 -0700 (PDT) Received: (qmail 28607 invoked by uid 99); 7 Apr 2001 02:15:32 -0000 Message-ID: <20010407021532.28606.qmail@sina.com> From: jiping_xiong To: ngtrans@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: about Ngtrans's implementions Date: Sat, 07 Apr 2001 10:15:32 +0800 X-Mailer: SinaMail 3.0Beta (FireToad) X-Priority: 3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi,everyone! I am interesting in the implementions of all kinds of transitions. eg.TB,NAT-PT,6to4,DSTM. Can u tell me how can i download those implemation(run under linux). great appreciate! 3xs ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn) ÍøÀïÑ°Ëýǧ°Ù¶È!ûÓÐ"ÁÄÓÑËÙÅä",ÔõÄÜ"³ÉË«³É¶Ô"? (http://newchat.sina.com.cn) -------------------------------------------------------------------- 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 Apr 8 19:09:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3929FK9005473 for ; Sun, 8 Apr 2001 19:09:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3929FOB005472 for ipng-dist; Sun, 8 Apr 2001 19:09:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3928nK9005457; Sun, 8 Apr 2001 19:08:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA26735; Sun, 8 Apr 2001 19:08:48 -0700 (PDT) Received: from ns.opicom.co.kr ([211.181.218.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA15339; Sun, 8 Apr 2001 19:08:46 -0700 (PDT) Received: from opicom3 (unverified [129.254.165.143]) by ns.opicom.co.kr (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 09 Apr 2001 10:56:47 +0900 Message-ID: <00f401c0c09a$02569860$8fa5fe81@etri.re.kr> From: "soohong PARK" To: "jiping_xiong" , Cc: References: <20010407021532.28606.qmail@sina.com> Subject: Re: about Ngtrans's implementions Date: Mon, 9 Apr 2001 11:08:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f3928sK9005458 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "jiping_xiong" To: Cc: Sent: Saturday, April 07, 2001 11:15 AM Subject: about Ngtrans's implementions > hi,everyone! > I am interesting in the implementions of all kinds of transitions. > eg.TB,NAT-PT,6to4,DSTM. we are developing NAT-PT based on Linux 2.4.0 and completed by end of this year. in addition, we have a plan to expanding of function of NAT-PT. > Can u tell me how can i download those implemation(run under linux). but it is not GPL License. > great appreciate! > 3xs > > ______________________________________ > > =================================================================== > ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn) > ÍøÀïÑ°Ëýǧ°Ù¶È!ûÓÐ"ÁÄÓÑËÙÅä",ÔõÄÜ"³ÉË«³É¶Ô"? (http://newchat.sina.com.cn) > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- +-------------------------------------------------------- + soohong PARK + Engineer/OPICOM Inc. + OPtical Integrated COMmunication + 5F,Rose Dale Bldg.,724 Suseo-Dong, + Kangnam-Ku, Seoul, KOREA 135-220 + TEL:+82-42-860-1062 || FAX:+82-42-861-5404 + UMS:+0303-1509-9209 || MOBILE:+016-221-9209 + E-mail:sh_park@opicom.co.kr || URL:www.opicom.co.kr +--------------------------------------------------------- -------------------------------------------------------------------- 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 Apr 9 09:47:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GlFK9007765 for ; Mon, 9 Apr 2001 09:47:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39GlFZI007764 for ipng-dist; Mon, 9 Apr 2001 09:47:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39GkhK9007738; Mon, 9 Apr 2001 09:46:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01739; Mon, 9 Apr 2001 09:46:43 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29854; Mon, 9 Apr 2001 09:46:35 -0700 (PDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 9 Apr 2001 10:28:31 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Apr 2001 10:28:27 -0500 Message-ID: From: "Sandeep Kalal" To: "'jiping_xiong'" , ngtrans@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: Date: Mon, 9 Apr 2001 10:28:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C109.B5EF7710" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C109.B5EF7710 Content-Type: text/plain; charset="iso-8859-1" Hi, I am a novice in the field of IPv6. I have recently joined this forum. I have following questions: 1. What is the use of having separate Link-Local Unicast address and Site-Local Unicast address, when nodes can communicate ( on a link or in a site) by using Aggregatable Global Unicast Addresses. 2. What is the use of IPv4-mapped IPv6 addresses and IPv4-compatible IPv6 addresses? Where can I get information about this? Please let me know if there is any other way of posting query. Thanks, Sandeep Kalal ------_=_NextPart_001_01C0C109.B5EF7710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,
 
I am a novice in the field of IPv6. I have recently = joined this forum. I have following questions:

1. What is the use of having separate Link-Local = Unicast address and Site-Local Unicast address, when nodes can = communicate ( on a link or in a site) by using Aggregatable Global = Unicast Addresses.

2. What is the use of IPv4-mapped IPv6 addresses and = IPv4-compatible IPv6 addresses? Where can I get information about = this?

Please let me know if there is any other way of = posting query.

Thanks,

Sandeep Kalal

------_=_NextPart_001_01C0C109.B5EF7710-- -------------------------------------------------------------------- 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 Apr 9 13:55:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39KthK9008893 for ; Mon, 9 Apr 2001 13:55:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f39KtgUa008892 for ipng-dist; Mon, 9 Apr 2001 13:55:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39KtcK9008885 for ; Mon, 9 Apr 2001 13:55:38 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f39KqTA21760 for ipng@sunroof.eng.sun.com; Mon, 9 Apr 2001 13:52:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39I72K9008307; Mon, 9 Apr 2001 11:07:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20891; Mon, 9 Apr 2001 11:07:01 -0700 (PDT) Received: from sea-av1.zama.net (smtp1.zama.net [203.142.132.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07099; Mon, 9 Apr 2001 11:07:00 -0700 (PDT) Received: from sea-av1.zama.net (localhost [127.0.0.1]) by sea-av1.zama.net (8.9.3+Sun/8.9.3) with ESMTP id LAA10232; Mon, 9 Apr 2001 11:06:59 -0700 (PDT) Received: from postoff1.zama.net (sea-postoff1.zama.net [172.16.100.20]) by sea-av1.zama.net (8.9.3+Sun/8.9.3) with ESMTP id LAA10211; Mon, 9 Apr 2001 11:06:58 -0700 (PDT) Received: from WHIPPLE ([203.142.132.5]) by postoff1.zama.net (Netscape Messaging Server 4.15) with ESMTP id GBJEBM00.A0K; Mon, 9 Apr 2001 11:06:58 -0700 Message-ID: <000f01c0c11f$de24bb30$160c10ac@zama.net> Reply-To: "Todd Whipple" From: "Todd Whipple" To: <6bone@ISI.EDU>, , , , , Subject: IPv6 mail archives -- version 1 Date: Mon, 9 Apr 2001 11:06:57 -0700 Organization: Zama Networks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Zama has just put a web based mail archive of several of the IPv6 mailing lists on our website (www.zamanetworks.com). Follow the link to Mail Archives. These lists are: 6 Bone Participants 6 Bone Users Next Generation Transition IPfilter IETF DNS Operations We will be adding more lists to this as time goes on. Also, if anyone has any suggestions or would like to see a list archived here (as long as it is related to IPv6), please send me any comments and suggestions. The archives only go back to March 2001. We will be trying to get as much archives from the list owners and get historic data in place. Hope all find this useful. Todd Whipple VP of IPv6 Technologies Zama Networks, Inc Seattle, Wa. -------------------------------------------------------------------- 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 Apr 10 06:00:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AD0SK9013552 for ; Tue, 10 Apr 2001 06:00:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AD0RdQ013551 for ipng-dist; Tue, 10 Apr 2001 06:00:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AD0IK9013544 for ; Tue, 10 Apr 2001 06:00:18 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14470 for ; Tue, 10 Apr 2001 06:00:18 -0700 (PDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21116 for ; Tue, 10 Apr 2001 06:00:17 -0700 (PDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA28513 for ; Tue, 10 Apr 2001 15:00:16 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA14523 for ; Tue, 10 Apr 2001 14:59:55 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id <2TAH9WPB>; Tue, 10 Apr 2001 14:59:54 +0200 Message-ID: <158669A6D0F5D3119B940060086D94F550080F@ULML202E> From: Metzler Jochen To: ipng@sunroof.eng.sun.com Subject: flow label Date: Tue, 10 Apr 2001 14:59:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I couldn't attend last WG Meeting and from the Minutes I didn't see an outcome of the flow label discussion. Principally, I see similar options as Steve: - complete standardization in either of the three directions (mutable label, e-t-e-label or the combination of both) that enables people to make use of it in the original sense (as flow identification) - rename the field to "unspecified" and enable people to find new L3 enhancements beyond the scope of flow identification. - leave it as it is. That prevents people from using the field or coming up with new ideas. Is there a conclusion taken on that issue ? cheers jochen -------------------------------------------------------------------- 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 Apr 10 06:39:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ADdgK9013669 for ; Tue, 10 Apr 2001 06:39:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3ADdgYa013668 for ipng-dist; Tue, 10 Apr 2001 06:39:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ADdWK9013661 for ; Tue, 10 Apr 2001 06:39:32 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27727 for ; Tue, 10 Apr 2001 06:39:33 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA04545 for ; Tue, 10 Apr 2001 06:39:32 -0700 (PDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id <2SZQJPZW>; Tue, 10 Apr 2001 15:39:28 +0200 Message-ID: <31A473DBB655D21180850008C71E251A0442CA2D@mail.kebne.se> From: Thomas Eklund To: "'Glenn Morrow'" , "'Pekka Nikander'" , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Tue, 10 Apr 2001 15:39:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, It is an interesting topic you raise. I think though that our AAA v6 draft is a big step forward and would like to stress at a few points. > here we go anyway. This message is divided in three parts: > A. Discussion about source address filtering > B. A comparison between source and destination addresses > C. My thoughts what should be done instead > > A. Discussion about source address filtering > > Now, according to my analysis, currently there are basically three > functional reasons for including the source address into IPv6 > packets. > > 1. Source addresses are needed to be able to reply to > packets, such as unconnected UDP queries or TCP SYN packets. > 2. Source addresses are needed to be able to report > back error conditions, e.g., ICMP Packet Too Big. > 3. Source addresses are used for identifying upper layer > endpoints, e.g., to differentiate between TCP sockets. > > It is instructive to note that in the two first cases the > source address is really needed, but in the last case it > is merely a convenient piece of information that could be > easily replaced with something else identifying the remote > endpoint (compare e.g. to HIP). > > Now, mandating source address filtering attempts to add another > purpose for the source address; a purpose that I don't believe > could ever be really reliable. It could though be combined with the access control that we explain in the draft > 4. Source addresses identify the interface through > which the packet was originated. (FALSE) > > Maybe this was the original intention of the source address, > but to me it seems like the infrastructure has never really > supported this allusion. Furthermore, it is instructive to > note that even with honest nodes the source addess does not > always identify the sender. For example, some neighbour > solicitation packets carry the unspecified source address, etc. > Furthermore, even strict and mandatory ingress filtering does > not quite achieve the maxim -- if the filtering was perfect, it > would at most lead to a situation where the source address > identifies the source link of the packet, not the specific > interface at the link. I agree and this is how it is more or less solved in the draft where the authenticated address becomes a temporary link identifier with a chance to update the ACL filter in the router based on the authentication and authorazation phase with the home AAA server. In other words it does not mean so much if we use the CoA or Home Adress in respective to the protocol, but in the draft the CoA could be seen as the authenticated "link identifier" and my belief is that it solves a lot of the issues you raise, perhaps not all, but a lot of them. And then you have to bear in mind that it is very easy to implement with existing policy manager/ACL rule managers in existing routers. > > Even further, I think that there are several reasons why > even trying to achieve this illusion is a bad idea. > > a) Since source address filtering would be a piece of > functionality whose malfunction does not have any immediate > local effects, I have hard time believing that we would > ever get even 90% coverage. What do you mean here? In my view it is the easiest way to secure the access and combine it with the AAA draft where you do you authentication and authorazation in the AAA infrastructure, and you could reuse a lot of the software that is already running inside the routers for handling ACL rules. > b) Taking the trend described at the open plenary on > Wednesday evening, i.e. internet turning more and more > into a densely connected mesh instead of being more-or-less > hierarchical tree, employing source address filtering in > any other place but the ingress router would be quite hard > operationally, and hard even at the ingress routers. We have > already seen this in the various multihoming discussions. Not if you have an option to update the ACL rules automatically that could be done as it is described in the draft... > c) Being mandated (but not working properly), it would > encourage people to trust the source address even more > that they do today. Nothing strange. It is the same thing today in the mobile networks for instance wher your identifier is an IMSI which could be compared to something similar as a HA in case of mobile ipv6 with AAA. > > B. Comparison between source and destination addresses > > IMHO, on instructive point of view is to compare the functions > of the source and destination addresses. Most people seem to > believe, perhaps even unconsciously, that source and destination > addresses are functionally equivalent. That is, it seems to be > common thinking that the destination address identifies the > destination interface(s) of the packet and the source address > identifies the source interface of the packet. As we know, > this is not true. Now, the question is whether we should aim > to make it true again (if it ever was) or should we abandon > that thinking altogether. It is already split today. The HA is the identifier of the user. But your're right, the identifier could have several semantical meanings, some might argue that it is a "home interface" or something else. And I would like to see the CoA as a link identifier. > The source address does not (currently) have any such semantics. > It is just set by the sender, and used by the receiver. The only > case when an intermediate router cares about it is when it wants > to send an error report back. However, this latter practice does > not seem to be such a good idea, since the source address does not > necessarily carry information about the real sender of the packet. > In short, the practise greatly eases reflection DDoS attacks, since > you can fairly easily employ many of the routers in the > infrastructure > to act as reflectors. (Just mix routing headers and hop-by-hop > options.) Thats why a architechure base on filtering is so easy and in the short perspective make sense, the access lists are enforced at the access where the aggregated amount of traffic is not overhelming. > C. My thoughts what should be done instead > > I know this is a radical idea and that it is probably too late to > propose this, but I think that we should deprecate the source > address in the IPv6 header altogether. Instead, we should use > a separate destination option, perhaps "Reply-To Address Destination > Option", whenever we assume that the recipient may not know where > to send the replies. Please note that if we use end-to-end IPsec, > we never need to use this option, and that any other TCP packets > but the first SYN packet would not need to carry it either. > > Depracating the source address field from it current use would > free it for other purposes. My suggestion is that the main function > would be to use it for _recording_ the path of the packet. That is, > each router that touches the packet would (perhaps probabilistically) > somehow record its identity into the source address field. Thus, > the source address field would no longer be a source address field > but a source path field. To be frank, this sounds like a weaker proposal than the existing ones. You open up the routers to allow them to write into the packet (the source path). The problem with this approach is that it scales poorly and put more demand on the routers not only in the access but even further up in the aggregation, edge, core etc. Maybe I missed your point. Remember that I talk about packet filtering together with somthing like our AAA v6 draft to enforce access control. > > This would have several benefits. First, those that believe > in ingress > filtering would perhaps be happy with the recorded packet path > information. > Second, those not believing in ingress filtering would be happy, too, > since packets would not have to be dropped. Third, one could easily > make the reply-to address private by including the destination option > within an ESP header. Fourth, ICMP error reports generated by > intermediate > routers would be sent along the source path instead of relying on the > perhaps false source address. (This might require some modifications > to the error reporting functionality, but I think that wouldn't be > that hard.) > Best Regards Thomas Eklund -------------------------------------------------------------------- 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 Apr 10 07:12:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AECcK9013751 for ; Tue, 10 Apr 2001 07:12:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3AECchp013750 for ipng-dist; Tue, 10 Apr 2001 07:12:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AECGK9013733; Tue, 10 Apr 2001 07:12:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00308; Tue, 10 Apr 2001 07:12:16 -0700 (PDT) Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25168; Tue, 10 Apr 2001 07:12:11 -0700 (PDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id OAA05691; Tue, 10 Apr 2001 14:57:37 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id QAA17085; Tue, 10 Apr 2001 16:05:53 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id PAA05760; Tue, 10 Apr 2001 15:11:28 +0200 (MET DST) Received: from ms.alcatel.fr (spip [188.9.249.125]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id PAA03844; Tue, 10 Apr 2001 15:11:35 +0200 (MET DST) Message-ID: <3AD3054B.114047DD@ms.alcatel.fr> Date: Tue, 10 Apr 2001 15:06:20 +0200 From: Gilles Diribarne Organization: Alcatel CRC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.3 i686) X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: Sandeep Kalal CC: "'jiping_xiong'" , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, > 1. What is the use of having separate Link-Local Unicast address and > Site-Local Unicast address, when nodes can communicate ( on a link or > in a site) by using Aggregatable Global Unicast Addresses. Your question is about the scope. - The link-local address is valid only on a link. But it's an address which is autoconfigurable (First step of Stateless Autoconfguration). It allows a host to determine an address and have at least one. For example, DHCP client uses only link-local addresses to get another address. - Site-local are like 'private IPv4 address'. They can be used if you want to have private addresses. You have to use NAT for example to toggle public addresses and site-local addresses. - Aggregatable global adrresses are global adresses. They contain TLA, SLA, ... It's a public addresses which will be given by an ISPs for example. >> 2. What is the use of IPv4-mapped IPv6 addresses and IPv4-compatible IPv6 addresses? Where can I get information about this? Generally, IPv4-mapped IPv6 address is used when a V6 node wants to communicate with a V4-only node. I think you can look at ngtrans rfc and drafts that talks about translator. SIIT is a good example. The use of IPv4-compatible IPv6 addresses are used to establish tunnels. When a IPv6 node wants to communicate over IPv4, it uses IPv4-compatibke addresses. This address type is usefull to indicate for example the tunnel endpoint. Ex under Linux: $> route -Ainet6 3ffe:/16 gw ::192.168.52.1 To reach 3ffe:/16, you have to encapsulate your packet into a IPv4 one. For all the previous question, have a look at RFC 2373 and NGTRANS RFC and draft. Regards, Gilles Diribarne -- Gilles Diribarne Alcatel Research & Innovation Gilles.Diribarne@alcatel.fr Tel: +33 (0)1 69 63 46 45 Fax: +33 (0)1 69 63 11 69 -------------------------------------------------------------------- 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 Apr 11 16:56:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BNu8K9017881 for ; Wed, 11 Apr 2001 16:56:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3BNu7QW017880 for ipng-dist; Wed, 11 Apr 2001 16:56:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3BNtwK9017873 for ; Wed, 11 Apr 2001 16:55:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20440 for ; Wed, 11 Apr 2001 16:55:59 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22993 for ; Wed, 11 Apr 2001 16:55:58 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 94A1C1E0C9 for ; Wed, 11 Apr 2001 19:55:57 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA12334 for ; Wed, 11 Apr 2001 19:55:55 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA14378; Wed, 11 Apr 2001 16:55:54 -0700 (PDT) Message-Id: <200104112355.QAA14378@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ipng@sunroof.eng.sun.com Subject: IPv6 MIB revisions: comments solicited Date: Wed, 11 Apr 2001 16:55:54 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 11 Apr 2001 16:55:54 -0700 Versions: dmail (solaris) 2.2g The IPv6 MIB design team has published the following I-D's: draft-ops-rfc2011-update-00.txt -- revising IP-MIB draft-ops-rfc2012-update-00.txt -- revising TCP-MIB draft-ops-rfc2013-update-00.txt -- revising UDP-MIB draft-ops-rfc2096-update-00.txt -- revising IP-FORWARD-MIB We would like feedback on these updates, especially from implementors. We're particularly curious about several of the objects in RFC 2465's ipv6IfTable, along with the use of ipv6InterfaceIndex, since many or most of them can be now be implemented in terms of the IF-MIB. In addition, each draft has an "Open Issues" section, along with some other open issues scattered in the documents. We'd like to get feedback from the community as quickly as possible so that we can move forward with these documents. Thanks, 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 Thu Apr 12 00:02:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3C72GK9018481 for ; Thu, 12 Apr 2001 00:02:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3C72F5o018480 for ipng-dist; Thu, 12 Apr 2001 00:02:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3C726K9018473 for ; Thu, 12 Apr 2001 00:02:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23319 for ; Thu, 12 Apr 2001 00:02:05 -0700 (PDT) Received: from linux.aquila ([193.171.1.222]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25168 for ; Thu, 12 Apr 2001 00:02:03 -0700 (PDT) Received: from mm1 ([192.168.10.2]) by linux.aquila (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with SMTP id f3C71w310190 for ; Thu, 12 Apr 2001 09:02:02 +0200 X-Authentication-Warning: linux.aquila: Host [192.168.10.2] claimed to be mm1 From: "Alexander Abl" To: "Ipng" Subject: Quality of Service and IPng Date: Thu, 12 Apr 2001 09:01:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! What I'm missing concerning information and experiences about IPv6 is the Quality of Service aspect. Currently I'm involved in a project that deals with end to end QoS within ISP networks. During this project we are gaining experiences regarding QoS and IPv4 and the possible implementations with this IP version. What I'm interested in, is information about Intserv respectively Diffserv experiences with IPv6. What's about the portability of technologies developed for IPv4 (RSVP, Diffserv queuing mechanism,...)? Does anybody have some hints for me? Thanks and kind regards, Alexander Abl Telekom Austria AG Headquarters Department ND / EN Arsenal Objekt 22 1103 Vienna Austria Voice: +43 (1) 797111622 E-Mail : alexander.abl@aon.at E-Mail 2: alexander.abl@telekom.at -------------------------------------------------------------------- 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 Apr 12 02:01:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3C91UK9018695 for ; Thu, 12 Apr 2001 02:01:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3C91T7U018694 for ipng-dist; Thu, 12 Apr 2001 02:01:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3C91KK9018687 for ; Thu, 12 Apr 2001 02:01:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18965 for ; Thu, 12 Apr 2001 02:01:20 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA00666 for ; Thu, 12 Apr 2001 02:01:19 -0700 (PDT) Received: from TWARWICK-W2K.cisco.com (lon-sto4-lan-vlan133-dhcp45.cisco.com [144.254.108.112]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA22838; Thu, 12 Apr 2001 10:01:15 +0100 (BST) Message-Id: <4.3.2.7.2.20010412095759.00b23830@jaws.cisco.com> X-Sender: twarwick@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Apr 2001 09:58:53 +0100 To: Bill Fenner From: Trevor Warwick Subject: Re: IPv6 MIB revisions: comments solicited Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200104112355.QAA14378@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Where do you want comments to be sent ? To ipng, directly to the draft editors, or to some other list ? At 12/04/2001, Bill Fenner wrote: >Date: Wed, 11 Apr 2001 16:55:54 -0700 >Versions: dmail (solaris) 2.2g > > >The IPv6 MIB design team has published the following I-D's: > >draft-ops-rfc2011-update-00.txt -- revising IP-MIB >draft-ops-rfc2012-update-00.txt -- revising TCP-MIB >draft-ops-rfc2013-update-00.txt -- revising UDP-MIB >draft-ops-rfc2096-update-00.txt -- revising IP-FORWARD-MIB > >We would like feedback on these updates, especially from implementors. >We're particularly curious about several of the objects in >RFC 2465's ipv6IfTable, along with the use of ipv6InterfaceIndex, >since many or most of them can be now be implemented in terms of >the IF-MIB. -------------------------------------------------------------------- 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 Apr 12 08:31:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CFVdK9019402 for ; Thu, 12 Apr 2001 08:31:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CFVcq3019401 for ipng-dist; Thu, 12 Apr 2001 08:31:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CFVTK9019394 for ; Thu, 12 Apr 2001 08:31:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15586 for ; Thu, 12 Apr 2001 08:31:29 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06105 for ; Thu, 12 Apr 2001 08:31:26 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id BA04A4CEF5; Thu, 12 Apr 2001 11:31:05 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA24899; Thu, 12 Apr 2001 11:31:04 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id IAA20700; Thu, 12 Apr 2001 08:31:03 -0700 (PDT) Message-Id: <200104121531.IAA20700@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: twarwick@cisco.com Subject: Re: IPv6 MIB revisions: comments solicited Cc: ipng@sunroof.eng.sun.com Date: Thu, 12 Apr 2001 08:31:03 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for not specifying in the original email. We should have the discussion on the IPNG list. 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 Thu Apr 12 11:14:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CIEMK9020035 for ; Thu, 12 Apr 2001 11:14:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CIELPU020034 for ipng-dist; Thu, 12 Apr 2001 11:14:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CIEFK9020027 for ; Thu, 12 Apr 2001 11:14:15 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f3CIB4v26812 for ipng@sunroof.eng.sun.com; Thu, 12 Apr 2001 11:11:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3A8ULK9013036 for ; Tue, 10 Apr 2001 01:30:21 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02739 for ; Tue, 10 Apr 2001 01:30:20 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA22400 for ; Tue, 10 Apr 2001 01:30:19 -0700 (PDT) Received: from 157.54.7.67 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Apr 2001 01:23:27 -0700 (Pacific Daylight Time) Received: from na-hub-04.redmond.corp.microsoft.com ([157.54.1.18]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 10 Apr 2001 01:23:02 -0700 Received: from corp-hub-02.redmond.corp.microsoft.com ([157.54.2.43]) by na-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 10 Apr 2001 01:23:01 -0700 Received: from tvp-pfs-01.europe.corp.microsoft.com ([157.58.32.223]) by corp-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 10 Apr 2001 01:23:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: NAPT - dynamic allocation Date: Tue, 10 Apr 2001 09:22:57 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NAPT - dynamic allocation Thread-Index: AcC+lNcrOPD9vW6MQZaJBhqW7MzM6gAYpEOAAKe+83A= From: "Tom Vivian" To: "Brian Zill" , "Emanuel Moreira" , , , , X-OriginalArrivalTime: 10 Apr 2001 08:23:01.0270 (UTC) FILETIME=[74F35360:01C0C197] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3A8UMK9013037 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Anything that reduces dependence on Ipv4 seems like a good idea. It always struck me as an anomaly that Ipv4 is relied on by any IPv6 implementation. Here in the group developing Microsoft Mobile Explorer for Feature Phones, we have an IPv4 stack that will be changed to IPv6 at some point and it is far from certain that any IPv4 will be present in the networks it will have to operate in, so dependency on IPv4 may restrict the amount of existing Microsoft code we can re-use from other groups. Tom Vivian Wireless Telephony Group Europe. > -----Original Message----- > From: Brian Zill > Sent: Saturday, April 07, 2001 1:26 AM > To: Emanuel Moreira; ipng@sunroof.eng.sun.com; marcfiu@yahoo.com; > msripv6-users@list.research.microsoft.com; users@ipv6.org > Subject: RE: NAPT - dynamic allocation > > > Hi Emanuel, > > > Would'nt it be useful to have dinamical alocation of > > translation addresses in NAPT (Microsoft)? Then LAN's that > > don't need to be entirely connected to the IPv4 world would > > only have some IPv4 global addresses for translation and so > > save a lot of money. > > Yes, that would be a nice feature. The NAT-PT box would then behave > more like a traditional NAT, in that you could save external addresses > in exchange for diminished inbound connectivity. > > Our NAPT implementation is a pure research project, and we haven't had > the time to really do anything with it for over a year. It was a > proof-of-concept more than anything else. So it's unlikely that we'll > be adding dynamic allocation of translation addresses anytime > soon. But > the source is included in the download, so if you want to add that > capability, go ahead! > > --Brian > > > -----Original Message----- > > From: Emanuel Moreira [mailto:emanramor@portugalmail.com] > > Sent: Friday, 06 April, 2001 05:00 > > To: Brian Zill; ipng@sunroof.eng.sun.com; marcfiu@yahoo.com; > > msripv6-users@list.research.microsoft.com; users@ipv6.org > > Subject: NAPT - dynamic allocation > > > > > > Would'nt it be useful to have dinamical alocation of > > translation addresses in NAPT (Microsoft)? Then LAN's that > > don't need to be entirely connected to the IPv4 world would > > only have some IPv4 global addresses for translation and so > > save a lot of money. > > > > Thanks > > > > Emanuel Moreira > > > > _____________________________________________________________ > > > > O e-mail preferido dos portugueses http://www.portugalmail.pt > > > > --- > You are currently subscribed to msripv6-users as: > tvivian@microsoft.com > To unsubscribe send a blank email to > leave-msripv6-users-1046R@list.research.microsoft.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 Apr 12 11:13:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CIDqK9020025 for ; Thu, 12 Apr 2001 11:13:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CIDqlu020024 for ipng-dist; Thu, 12 Apr 2001 11:13:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CIDlK9020017 for ; Thu, 12 Apr 2001 11:13:47 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f3CIAbp26782 for ipng@sunroof.eng.sun.com; Thu, 12 Apr 2001 11:10:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f39MbEK9010247; Mon, 9 Apr 2001 15:37:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25215; Mon, 9 Apr 2001 15:37:14 -0700 (PDT) Received: from mail-nb00s0.nbnet.nb.ca (smtp1.nbnet.nb.ca [198.164.200.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA15394; Mon, 9 Apr 2001 16:37:12 -0600 (MDT) Received: from ranman.nbtel.net ([198.164.220.140]) by mail-nb00s0.nbnet.nb.ca (Post.Office MTA v3.5.3 release 223 ID# 0-68911U130000L130000S0V35) with ESMTP id ca; Mon, 9 Apr 2001 19:37:12 -0300 Date: Mon, 9 Apr 2001 19:37:11 -0300 (ADT) From: Thomas Keats X-Sender: tkeats@ranman.nbtel.net To: Todd Whipple cc: 6bone@ISI.EDU, members@ipv6forum.com, users@ipv6.org, linux-ipv6@list.f00f.org, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: Re: IPv6 mail archives -- version 1 In-Reply-To: <000f01c0c11f$de24bb30$160c10ac@zama.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am in the midst of learning all this and it seems a little foreboding. Is there a 'SIMPLE' step by step guide in what i need to download in order to be able to ping ipv6 etc...? i Do already have bind 9.1.x .. although i have yet to set it up slackware 7.1 is my OS/linux Many thanks in advance. Thomas Keats Rainbow Computer Systems http://www.rainbowcomputersystems.com Your source for Linux Compatible Hardware. -------- Compatibility Statement. -------- We read formats created in .txt wordperfect, and MSWord97 or earlier, all other communications will be filtered out and 'misplaced' Thank you for your co-operation. -------------------------------------------------------------------- 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 Apr 12 11:14:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CIEqK9020045 for ; Thu, 12 Apr 2001 11:14:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CIEq0B020044 for ipng-dist; Thu, 12 Apr 2001 11:14:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CIEhK9020037 for ; Thu, 12 Apr 2001 11:14:44 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f3CIBXO26843 for ipng@sunroof.eng.sun.com; Thu, 12 Apr 2001 11:11:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3AK0IK9015191 for ; Tue, 10 Apr 2001 13:00:18 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05878 for ; Tue, 10 Apr 2001 13:00:16 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29686 for ; Tue, 10 Apr 2001 13:00:16 -0700 (PDT) Received: from dinaras.cnri.reston.va.us (host-4-141.cnri.reston.va.us [10.27.4.141]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25124 for ; Tue, 10 Apr 2001 16:00:13 -0400 (EDT) Message-Id: <5.0.0.25.0.20010410155816.022722d0@odin> X-Sender: dinaras@odin X-Mailer: QUALCOMM Windows Eudora Version 5.0 X-Priority: 2 (High) Date: Tue, 10 Apr 2001 16:00:17 -0700 To: ipng@sunroof.eng.sun.com From: Dinara Suleymanova Subject: Global IPv6 Summit in Canada Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Title: Global IPv6 Summit in Canada URL: http://www.foretec.com/IPv6-index.htm Dates: May 14-16, 2001 City: Ottawa, Canada Venue: Fairmont Chateau Laurier 1, Rideau Street Ottawa, Ontario K1N 8S7 Canada Telephone: +1 613 241 1414 Global Reservations Centre: +1 800 441 1414 Fax: +1 613 562 7031 Description: A world-wide consortium of leading Internet vendors, Research & Education Networks are shaping the IPv6 FORUM, with a clear mission to promote IPv6 by dramatically improving the market and user awareness of IPv6, creating a quality and secure Next Generation Internet and allowing world-wide equitable access to knowledge and technology, embracing a moral responsibility to the world. To this end the IPv6 FORUM will: Establish an open, international FORUM of IPv6 expertise Share IPv6 knowledge and experience among members Promote new IPv6-based applications and global solutions Promote interoperable implementations of Ipv6 standards Co-operate to achieve end-to-end quality of service Resolve issues that create barriers to IPv6 deployment Contact: Joya Subudhi Foretec Seminars, Inc 1895 Preston White Drive, Suite 100 Reston, VA 20191 Phone (703) 620 9053 Fax: (703) 620 9071 E-mail: joya@ipv6summit.com URL: www.foretec.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 Apr 12 14:56:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CLugK9021396 for ; Thu, 12 Apr 2001 14:56:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3CLuffu021395 for ipng-dist; Thu, 12 Apr 2001 14:56:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3CLuVK9021388 for ; Thu, 12 Apr 2001 14:56:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15897 for ; Thu, 12 Apr 2001 14:56:32 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA24727 for ; Thu, 12 Apr 2001 16:00:10 -0600 (MDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA25470 for ; Thu, 12 Apr 2001 16:56:37 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 12 Apr 2001 16:56:21 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Apr 2001 16:56:15 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301E164FA@crchy271.us.nortel.com> From: "Glenn Morrow" To: "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Thu, 12 Apr 2001 16:56:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C39B.64531E90" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C39B.64531E90 Content-Type: text/plain; charset="iso-8859-1" Thomas, Again I wish to bring up that if a slave has been infected and a root kit installed, any credentials on that node will likely be available to be used by the virus; therefore, any credentials used to pass any AAA and have the ACL filter set up will be available to the root kit. So I still think we should mandate, at least as a BCP, topological correctness on the source. Does this make sense to you both? Thanks, Glenn -----Original Message----- From: Thomas Eklund [mailto:thomas.eklund@xelerated.com] Sent: Tuesday, April 10, 2001 8:39 AM To: Morrow, Glenn [RICH2:C330:EXCH]; 'Pekka Nikander'; 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Subject: RE: Source addresses, DDoS prevention and ingress filtering Hi Pekka, It is an interesting topic you raise. I think though that our AAA v6 draft is a big step forward and would like to stress at a few points. ------_=_NextPart_001_01C0C39B.64531E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Source addresses, DDoS prevention and ingress = filtering

Thomas,

Again I wish to bring up that if a slave has been = infected and a root kit installed, any credentials on that node will = likely be available to be used by the virus; therefore, any credentials = used to pass any AAA and have the ACL filter set up will be available = to the root kit.

So I still think we should mandate, at least as a = BCP, topological correctness on the source.

Does this make sense to you both?

Thanks,

Glenn


-----Original Message-----
From: Thomas Eklund [mailto:thomas.eklund@xelerat= ed.com]
Sent: Tuesday, April 10, 2001 8:39 AM
To: Morrow, Glenn [RICH2:C330:EXCH]; 'Pekka = Nikander';
'ipng@sunroof.eng.sun.com'; = 'ietf-itrace@research.att.com'
Subject: RE: Source addresses, DDoS prevention and = ingress filtering


Hi Pekka,
It is an interesting topic you raise.

I think though that our AAA v6 draft is a big step = forward and would like to
stress at a few points.

------_=_NextPart_001_01C0C39B.64531E90-- -------------------------------------------------------------------- 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 Apr 13 04:16:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DBG0K9024093 for ; Fri, 13 Apr 2001 04:16:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3DBFxI6024092 for ipng-dist; Fri, 13 Apr 2001 04:15:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DBFXK9024085 for ; Fri, 13 Apr 2001 04:15:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19394 for ; Fri, 13 Apr 2001 04:15:31 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00809 for ; Fri, 13 Apr 2001 04:15:31 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04877; Fri, 13 Apr 2001 07:15:30 -0400 (EDT) Message-Id: <200104131115.HAA04877@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-2260-01.txt Date: Fri, 13 Apr 2001 07:15:29 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --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 : IPv6 multihoming support at site exit routers Author(s) : J. Hagino Filename : draft-ietf-ipngwg-ipv6-2260-01.txt Pages : 9 Date : 12-Apr-01 The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC2260 [Bates, 1998] by Tony Bates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-2260-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-2260-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-2260-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010412132930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-2260-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-2260-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010412132930.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 Apr 16 05:38:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GCcOK9000158 for ; Mon, 16 Apr 2001 05:38:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3GCcNHk000156 for ipng-dist; Mon, 16 Apr 2001 05:38:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GCcCK9000148 for ; Mon, 16 Apr 2001 05:38:13 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10160 for ; Mon, 16 Apr 2001 05:38:08 -0700 (PDT) Received: from quicksilver.ukc.ac.uk (quicksilver.ukc.ac.uk [129.12.21.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA08267 for ; Mon, 16 Apr 2001 05:38:07 -0700 (PDT) Received: from pelican.ukc.ac.uk ([129.12.200.26]) by quicksilver.ukc.ac.uk with esmtp (Exim 3.16 #1) id 14p8GS-0001nr-00 for ipng@sunroof.eng.sun.com; Mon, 16 Apr 2001 13:37:56 +0100 Received: from pccomm4.ukc.ac.uk ([129.12.50.119] helo=ukc.ac.uk) by pelican.ukc.ac.uk with esmtp (Exim 1.92 #1) for ipng@sunroof.eng.sun.com id 14p8Ge-0000eF-00; Mon, 16 Apr 2001 13:38:08 +0100 Message-ID: <3ADAE7AE.1684D1E5@ukc.ac.uk> Date: Mon, 16 Apr 2001 13:38:06 +0100 From: Kumarendra Sivarajah X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: 3G License Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Does anyone know where I can find information on the auction value of the 3G license all over the world for countries that have auctioned them already, especially in Europe or if anyone has it, can you mail it to me. Thanks, INdran -- ################################################# Kumarendra Sivarajah (INdran) Electronics Engineering Laboratory University of Kent at Canterbury Canterbury, Kent CT2 7NT United Kingdom Telephone(Office): +44 (0)1227 823257 Telephone(Mobile): +44 (0)7765 007016 Fax: +44 (0)7902 181526 ################################################# -------------------------------------------------------------------- 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 Apr 17 04:23:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HBN4K9002377 for ; Tue, 17 Apr 2001 04:23:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HBN40J002376 for ipng-dist; Tue, 17 Apr 2001 04:23:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HBMsK9002369 for ; Tue, 17 Apr 2001 04:22:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA14972 for ; Tue, 17 Apr 2001 04:22:53 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05853 for ; Tue, 17 Apr 2001 04:22:52 -0700 (PDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id <2SZQKJ10>; Tue, 17 Apr 2001 13:22:55 +0200 Message-ID: <31A473DBB655D21180850008C71E251A0442CB5B@mail.kebne.se> From: Thomas Eklund To: "'Glenn Morrow'" , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Tue, 17 Apr 2001 13:22:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Glenn, > Again I wish to bring up that if a slave has been infected and a root > kit installed, any credentials on that node will likely be > available to > be used by the virus; therefore, any credentials used to pass any AAA > and have the ACL filter set up will be available to the root kit. Yes. > > So I still think we should mandate, at least as a BCP, topological > correctness on the source. This is how it is today with the home address option and a topological correct IPv6 src address. > > Does this make sense to you both? Yes. -- thomas > > Thanks, > > Glenn > > > -----Original Message----- > From: Thomas Eklund [ mailto:thomas.eklund@xelerated.com > ] > Sent: Tuesday, April 10, 2001 8:39 AM > To: Morrow, Glenn [RICH2:C330:EXCH]; 'Pekka Nikander'; > 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Hi Pekka, > It is an interesting topic you raise. > > I think though that our AAA v6 draft is a big step forward and would > like to > stress at a few points. > -------------------------------------------------------------------- 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 Apr 17 08:59:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HFxZK9002890 for ; Tue, 17 Apr 2001 08:59:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3HFxYvM002889 for ipng-dist; Tue, 17 Apr 2001 08:59:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3HFxPK9002882 for ; Tue, 17 Apr 2001 08:59:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29122 for ; Tue, 17 Apr 2001 08:59:24 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06769 for ; Tue, 17 Apr 2001 08:59:22 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id IAA26032; Tue, 17 Apr 2001 08:57:57 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AED09145; Tue, 17 Apr 2001 08:59:15 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA09390; Tue, 17 Apr 2001 08:59:15 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15068.26707.643879.547620@thomasm-u1.cisco.com> Date: Tue, 17 Apr 2001 08:59:15 -0700 (PDT) To: Thomas Eklund Cc: "'Glenn Morrow'" , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering In-Reply-To: <31A473DBB655D21180850008C71E251A0442CB5B@mail.kebne.se> References: <31A473DBB655D21180850008C71E251A0442CB5B@mail.kebne.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So I have a question about all of this: What IP address does a stationary host behind a mobile router put in the source address and how did it come to know that address if it's not its home address? Mike Thomas Eklund writes: > Hi Glenn, > > > Again I wish to bring up that if a slave has been infected and a root > > kit installed, any credentials on that node will likely be > > available to > > be used by the virus; therefore, any credentials used to pass any AAA > > and have the ACL filter set up will be available to the root kit. > > Yes. > > > > > So I still think we should mandate, at least as a BCP, topological > > correctness on the source. > This is how it is today with the home address option and a topological > correct IPv6 src address. > > > > > Does this make sense to you both? > > Yes. > > -- thomas > > > > Thanks, > > > > Glenn > > > > > > -----Original Message----- > > From: Thomas Eklund [ mailto:thomas.eklund@xelerated.com > > ] > > Sent: Tuesday, April 10, 2001 8:39 AM > > To: Morrow, Glenn [RICH2:C330:EXCH]; 'Pekka Nikander'; > > 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > Hi Pekka, > > It is an interesting topic you raise. > > > > I think though that our AAA v6 draft is a big step forward and would > > like to > > stress at a few points. > > > -------------------------------------------------------------------- > 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 Wed Apr 18 04:37:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IBb1K9004413 for ; Wed, 18 Apr 2001 04:37:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IBb0bN004412 for ipng-dist; Wed, 18 Apr 2001 04:37:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IBapK9004405 for ; Wed, 18 Apr 2001 04:36:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA16097 for ; Wed, 18 Apr 2001 04:36:50 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA06094 for ; Wed, 18 Apr 2001 06:14:02 -0600 (MDT) Received: from cisco.com (adario@lon-sto4-lan-vlan133-dhcp13.cisco.com [144.254.108.80]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA28256 for ; Wed, 18 Apr 2001 12:36:47 +0100 (BST) Message-ID: <3ADD7C4E.65E406E2@cisco.com> Date: Wed, 18 Apr 2001 12:36:46 +0100 From: Dario Accornero Organization: Cisco Systems X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: IPv6 MIBS: Internet Drafts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I am new to the list. I am responsible of supporting the IPv6 MIBs for Cisco IOS and would like to know whether the RFC2011 and 2096 Internet Drafts written by Bill Fenner and his team have changed since their introduction at the end of February... Thank you, -- Dario Accornero - IOS Europe Development - IPv6 Team Stockley Park, Uxbridge, UK - voice +44 20 8756 6268 -------------------------------------------------------------------- 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 Apr 18 07:44:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IEiSK9004633 for ; Wed, 18 Apr 2001 07:44:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IEiRrE004632 for ipng-dist; Wed, 18 Apr 2001 07:44:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IEiIK9004625 for ; Wed, 18 Apr 2001 07:44:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04299 for ; Wed, 18 Apr 2001 07:44:18 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16484 for ; Wed, 18 Apr 2001 07:44:17 -0700 (PDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA12367 for ; Wed, 18 Apr 2001 09:44:32 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 18 Apr 2001 09:43:59 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 09:43:50 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301E8A1D6@crchy271.us.nortel.com> From: "Glenn Morrow" To: Michael Thomas , Thomas Eklund Cc: "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Wed, 18 Apr 2001 09:43:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C815.FA0628F0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C815.FA0628F0 Content-Type: text/plain; charset="iso-8859-1" If the node behind the MR obtained its home address from the the mobile router's subnet, then the MN will use this as the source i.e. the MN's home subnet is the MR's subnet. If the MN is homed from another subnet and is visiting MR's subnet and obtained a COA from the MR's subnet, then the MN will use the COA as the source. Do you want to discuss care of subnets and address translation or do you want to just assume tunneling to the MRs? With IPv6's plethora of addresses, I believe you could take your pick; though some might argue that the address translation is "immoral". I honestly do not feel that way. Machines have no morality only abilities. It seems to me that routing machines could easily and should swap addresses when there is no need for ALG functionality. Either way (tunneling or subnet translation), the topological correctness is still maintained. Hope this helps. Glenn -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Tuesday, April 17, 2001 10:59 AM To: Thomas Eklund Cc: Morrow, Glenn [RICH2:C330:EXCH]; 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Subject: RE: Source addresses, DDoS prevention and ingress filtering So I have a question about all of this: What IP address does a stationary host behind a mobile router put in the source address and how did it come to know that address if it's not its home address? Mike Thomas Eklund writes: > Hi Glenn, > > > Again I wish to bring up that if a slave has been infected and a root > > kit installed, any credentials on that node will likely be > > available to > > be used by the virus; therefore, any credentials used to pass any AAA > > and have the ACL filter set up will be available to the root kit. > > Yes. > > > > > So I still think we should mandate, at least as a BCP, topological > > correctness on the source. > This is how it is today with the home address option and a topological > correct IPv6 src address. > > > > > Does this make sense to you both? > > Yes. > > -- thomas > > > > Thanks, > > > > Glenn > > > > > > -----Original Message----- > > From: Thomas Eklund [ mailto:thomas.eklund@xelerated.com > > ] > > Sent: Tuesday, April 10, 2001 8:39 AM > > To: Morrow, Glenn [RICH2:C330:EXCH]; 'Pekka Nikander'; > > 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > Hi Pekka, > > It is an interesting topic you raise. > > > > I think though that our AAA v6 draft is a big step forward and would > > like to > > stress at a few points. > > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- ------_=_NextPart_001_01C0C815.FA0628F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Source addresses, DDoS prevention and ingress = filtering

If the node behind the MR obtained its home address = from the  the mobile router's subnet, then the MN will use this as = the source i.e. the MN's home subnet is the MR's subnet.

If the MN is homed from another subnet and is = visiting MR's subnet and obtained a COA from the MR's subnet, then the = MN will use the COA as the source.

Do you want to discuss care of subnets and address = translation or do you want to just assume tunneling to the MRs?

With IPv6's plethora of addresses, I believe you = could take your pick; though some might argue that the address = translation is "immoral".

I honestly do not feel that way. Machines have no = morality only abilities. It seems to me that routing machines could = easily and should swap addresses when there is no need for ALG = functionality.

Either way (tunneling or subnet translation), the = topological correctness is still maintained.

Hope this helps.

Glenn

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Tuesday, April 17, 2001 10:59 AM
To: Thomas Eklund
Cc: Morrow, Glenn [RICH2:C330:EXCH]; = 'ipng@sunroof.eng.sun.com';
'ietf-itrace@research.att.com'
Subject: RE: Source addresses, DDoS prevention and = ingress filtering



So I have a question about all of this:

What IP address does a stationary host behind = a
mobile router put in the source address and = how
did it come to know that address if it's not = its
home address?

        =         Mike

Thomas Eklund writes:
 > Hi Glenn,
 >
 > > Again I wish to bring up that if a = slave has been infected and a root
 > > kit installed, any credentials on = that node will likely be
 > > available to
 > > be used by the virus; therefore, any = credentials used to pass any AAA
 > > and have the ACL filter set up will = be available to the root kit.
 >
 > Yes.
 >
 > >
 > > So I still think we should mandate, = at least as a BCP, topological
 > > correctness on the source.
 > This is how it is today with the home = address option and a topological
 > correct IPv6 src address.
 >
 > >
 > > Does this make sense to you both? =
 >
 > Yes.
 >
 > -- thomas
 > >
 > > Thanks,
 > >
 > > Glenn
 > >
 > >
 > > -----Original Message-----
 > > From: Thomas Eklund [ mailto:thomas.eklund@xelerat= ed.com
 > > <mailto:thomas.eklund@xelerat= ed.com> ]
 > > Sent: Tuesday, April 10, 2001 8:39 = AM
 > > To: Morrow, Glenn [RICH2:C330:EXCH]; = 'Pekka Nikander';
 > > 'ipng@sunroof.eng.sun.com'; = 'ietf-itrace@research.att.com'
 > > Subject: RE: Source addresses, DDoS = prevention and ingress filtering
 > >
 > >
 > > Hi Pekka,
 > > It is an interesting topic you = raise.
 > >
 > > I think though that our AAA v6 draft = is a big step forward and would
 > > like to
 > > stress at a few points.
 > >
 > = --------------------------------------------------------------------
 > IETF IPng Working Group Mailing = List
 > IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
 > FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
 > Direct all administrative requests to = majordomo@sunroof.eng.sun.com
 > = --------------------------------------------------------------------

------_=_NextPart_001_01C0C815.FA0628F0-- -------------------------------------------------------------------- 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 Apr 18 08:12:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IFCgK9004699 for ; Wed, 18 Apr 2001 08:12:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IFCgYk004698 for ipng-dist; Wed, 18 Apr 2001 08:12:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IFCWK9004691 for ; Wed, 18 Apr 2001 08:12:32 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27283 for ; Wed, 18 Apr 2001 08:12:32 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15244 for ; Wed, 18 Apr 2001 08:12:32 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id HAA04770; Wed, 18 Apr 2001 07:49:08 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AEF03293; Wed, 18 Apr 2001 07:49:01 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA09734; Wed, 18 Apr 2001 07:49:01 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15069.43357.633190.968919@thomasm-u1.cisco.com> Date: Wed, 18 Apr 2001 07:49:01 -0700 (PDT) To: "Glenn Morrow" Cc: Michael Thomas , Thomas Eklund , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering In-Reply-To: <85AA7486A2C1D411BCA20000F8073E4301E8A1D6@crchy271.us.nortel.com> References: <85AA7486A2C1D411BCA20000F8073E4301E8A1D6@crchy271.us.nortel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Glenn Morrow writes: > If the node behind the MR obtained its home address from the the mobile > router's subnet, then the MN will use this as the source i.e. the MN's home > subnet is the MR's subnet. Right, but when the MR's upstream router does an RPF check... it will drop the SN's packets. > Either way (tunneling or subnet translation), the topological correctness is > still maintained. Well, that's sort of the problem. The SN doesn't know that it's putting topologically incorrect source address in the IP header. Mike -------------------------------------------------------------------- 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 Apr 18 08:55:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IFthK9004868 for ; Wed, 18 Apr 2001 08:55:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IFth8W004867 for ipng-dist; Wed, 18 Apr 2001 08:55:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IFtYK9004860 for ; Wed, 18 Apr 2001 08:55:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20725 for ; Wed, 18 Apr 2001 08:55:33 -0700 (PDT) Received: from lolo.logina.lt (logina.lt [195.22.177.68]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA07291 for ; Wed, 18 Apr 2001 10:33:57 -0600 (MDT) Received: by lolo.logina.lt (Postfix+IPv6, from userid 1001) id E15F6396B; Wed, 18 Apr 2001 17:55:10 +0200 (GMT-2) Received: from localhost (localhost [127.0.0.1]) by lolo.logina.lt (Postfix+IPv6) with ESMTP id B55231F05E; Wed, 18 Apr 2001 17:55:10 +0200 (GMT-2) Date: Wed, 18 Apr 2001 17:55:10 +0200 (GMT-2) From: Andrius Kasparavicius X-Sender: and@lolo.logina.lt To: users@ipv6.org, ipng@sunroof.eng.sun.com, 6bone@isi.edu Cc: netfilter@lists.samba.org Subject: Re: what happened to netfilter.kernelnotes.org? In-Reply-To: <20010418120808.B27210@corellia.laforge.distro.conectiva> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk maybe somenone can drop me URL ip6tables? THANKS. On Wed, 18 Apr 2001, Harald Welte wrote: > On Wed, Apr 18, 2001 at 03:02:10PM +0100, Chris Howells wrote: > > > > I don't know whether this is particularly helpful or relevant any more, > > but when I was downloading iptables 1.2.0 a while back, the package was > > corrupted from one of the mirror sites was corrupted -- it wouldn't > > de-compress, and it was smaller by quite a few bytes than the package I > > eventually downloaded from a mirror. > > > > Unfortunately I can't remember which mirror site the corrupted package > > was from, but if the pages are being updated automatically (presume via > > CVS?), then the problem may not have been fixed yet. > > > maybe you just downloaded it at the moment we were uploading it? > > don't have any other explanation, as we use rsync for all files...so > either it is broken everywhere or nowhere. ------------------------- Kasparavicius Andrius ________________________________________________________________________ http://www.andrius.org ICQ:17701001 tel.: +370 87 25630 nick: Casper AND-RIPE AND-6BONE KA6010 -------------------------------------------------------------------- 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 Apr 18 10:04:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IH4KK9004975 for ; Wed, 18 Apr 2001 10:04:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IH4KxA004974 for ipng-dist; Wed, 18 Apr 2001 10:04:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IH4AK9004967 for ; Wed, 18 Apr 2001 10:04:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07121 for ; Wed, 18 Apr 2001 10:04:10 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07429 for ; Wed, 18 Apr 2001 10:04:08 -0700 (PDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA17330 for ; Wed, 18 Apr 2001 12:01:36 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 18 Apr 2001 11:55:42 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 12:01:00 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301EEFCBC@crchy271.us.nortel.com> From: "Glenn Morrow" To: Michael Thomas Cc: Michael Thomas , Thomas Eklund , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Wed, 18 Apr 2001 12:00:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C829.21535E60" X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C829.21535E60 Content-Type: text/plain; charset="iso-8859-1" Oh, I see what you were concerned about. It seems to me that an MR will have to tunnel or subnet translate unless it is on it's home subnet. -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Wednesday, April 18, 2001 9:49 AM To: Morrow, Glenn [RICH2:C330:EXCH] Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Subject: RE: Source addresses, DDoS prevention and ingress filtering Glenn Morrow writes: > If the node behind the MR obtained its home address from the the mobile > router's subnet, then the MN will use this as the source i.e. the MN's home > subnet is the MR's subnet. Right, but when the MR's upstream router does an RPF check... it will drop the SN's packets. > Either way (tunneling or subnet translation), the topological correctness is > still maintained. Well, that's sort of the problem. The SN doesn't know that it's putting topologically incorrect source address in the IP header. Mike ------_=_NextPart_001_01C0C829.21535E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Source addresses, DDoS prevention and ingress = filtering

Oh, I see what you were concerned about. It seems to = me that an MR will have to tunnel or subnet translate unless it is on = it's home subnet.

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Wednesday, April 18, 2001 9:49 AM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: Michael Thomas; Thomas Eklund; = 'ipng@sunroof.eng.sun.com';
'ietf-itrace@research.att.com'
Subject: RE: Source addresses, DDoS prevention and = ingress filtering


Glenn Morrow writes:
 > If the node behind the MR obtained its = home address from the  the mobile
 > router's subnet, then the MN will use = this as the source i.e. the MN's home
 > subnet is the MR's subnet.

   Right, but when the MR's upstream router = does an
   RPF check... it will drop the SN's = packets.

 > Either way (tunneling or subnet = translation), the topological correctness is
 > still maintained.

   Well, that's sort of the problem. The SN = doesn't
   know that it's putting topologically = incorrect
   source address in the IP header.

        =           = Mike

------_=_NextPart_001_01C0C829.21535E60-- -------------------------------------------------------------------- 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 Apr 18 10:23:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IHNtK9005014 for ; Wed, 18 Apr 2001 10:23:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IHNtpr005013 for ipng-dist; Wed, 18 Apr 2001 10:23:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IHNjK9005006 for ; Wed, 18 Apr 2001 10:23:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25992 for ; Wed, 18 Apr 2001 10:23:40 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14494 for ; Wed, 18 Apr 2001 10:23:39 -0700 (PDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA22721 for ; Wed, 18 Apr 2001 12:23:40 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 18 Apr 2001 12:23:22 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 12:23:12 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301EEFCFF@crchy271.us.nortel.com> From: "Glenn Morrow" To: Michael Thomas Cc: Michael Thomas , Thomas Eklund , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Wed, 18 Apr 2001 12:23:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C82C.3B9F8480" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C82C.3B9F8480 Content-Type: text/plain; charset="iso-8859-1" Then again if source filtering is mandated on the first hop this might eliminate the need to do filtering on other hops and this would eliminate the need to do subnet translation or tunneling by either the MN or the MR. -----Original Message----- From: Morrow, Glenn [RICH2:C330:EXCH] Sent: Wednesday, April 18, 2001 11:56 AM To: 'Michael Thomas' Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Subject: RE: Source addresses, DDoS prevention and ingress filtering Oh, I see what you were concerned about. It seems to me that an MR will have to tunnel or subnet translate unless it is on it's home subnet. -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Wednesday, April 18, 2001 9:49 AM To: Morrow, Glenn [RICH2:C330:EXCH] Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Subject: RE: Source addresses, DDoS prevention and ingress filtering Glenn Morrow writes: > If the node behind the MR obtained its home address from the the mobile > router's subnet, then the MN will use this as the source i.e. the MN's home > subnet is the MR's subnet. Right, but when the MR's upstream router does an RPF check... it will drop the SN's packets. > Either way (tunneling or subnet translation), the topological correctness is > still maintained. Well, that's sort of the problem. The SN doesn't know that it's putting topologically incorrect source address in the IP header. Mike ------_=_NextPart_001_01C0C82C.3B9F8480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Source addresses, DDoS prevention and ingress = filtering

Then again if source filtering is mandated on the = first hop this might eliminate the need to do filtering on other hops = and this would eliminate the need to do subnet translation or tunneling = by either the MN or the MR.

-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH]
Sent: Wednesday, April 18, 2001 11:56 AM
To: 'Michael Thomas'
Cc: Michael Thomas; Thomas Eklund; = 'ipng@sunroof.eng.sun.com';
'ietf-itrace@research.att.com'
Subject: RE: Source addresses, DDoS prevention and = ingress filtering


Oh, I see what you were concerned about. It seems to = me that an MR will have to tunnel or subnet translate unless it is on = it's home subnet.

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Wednesday, April 18, 2001 9:49 AM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: Michael Thomas; Thomas Eklund; = 'ipng@sunroof.eng.sun.com';
'ietf-itrace@research.att.com'
Subject: RE: Source addresses, DDoS prevention and = ingress filtering


Glenn Morrow writes:
 > If the node behind the MR obtained its = home address from the  the mobile
 > router's subnet, then the MN will use = this as the source i.e. the MN's home
 > subnet is the MR's subnet.

   Right, but when the MR's upstream router = does an
   RPF check... it will drop the SN's = packets.

 > Either way (tunneling or subnet = translation), the topological correctness is
 > still maintained.

   Well, that's sort of the problem. The SN = doesn't
   know that it's putting topologically = incorrect
   source address in the IP header.

        =           = Mike

------_=_NextPart_001_01C0C82C.3B9F8480-- -------------------------------------------------------------------- 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 Apr 18 11:47:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IIlGK9005140 for ; Wed, 18 Apr 2001 11:47:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IIlFII005139 for ipng-dist; Wed, 18 Apr 2001 11:47:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IIl6K9005132 for ; Wed, 18 Apr 2001 11:47:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20212 for ; Wed, 18 Apr 2001 11:47:06 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07359 for ; Wed, 18 Apr 2001 11:47:02 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 59A304CF2D; Wed, 18 Apr 2001 14:45:45 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA27418; Wed, 18 Apr 2001 14:45:44 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA03235; Wed, 18 Apr 2001 11:45:44 -0700 (PDT) Message-Id: <200104181845.LAA03235@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: daccorne@cisco.com Subject: Re: IPv6 MIBS: Internet Drafts Cc: ipng@sunroof.eng.sun.com Date: Wed, 18 Apr 2001 11:45:43 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dario and IPNG list, The drafts have not changed, and we have no major changes pending. We'd encourage comments on the -00 versions of the drafts. Thanks, 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 Wed Apr 18 12:37:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IJbrK9005347 for ; Wed, 18 Apr 2001 12:37:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IJbqra005346 for ipng-dist; Wed, 18 Apr 2001 12:37:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IJbgK9005339 for ; Wed, 18 Apr 2001 12:37:42 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19993 for ; Wed, 18 Apr 2001 12:37:35 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16668 for ; Wed, 18 Apr 2001 12:37:34 -0700 (PDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA26775 for ; Wed, 18 Apr 2001 14:37:50 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 18 Apr 2001 14:37:30 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 14:37:20 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301EEFEDE@crchy271.us.nortel.com> From: "Glenn Morrow" To: Edward Vielmetti Cc: Michael Thomas , Thomas Eklund , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Wed, 18 Apr 2001 14:37:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C83E.FB281710" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C83E.FB281710 Content-Type: text/plain; charset="iso-8859-1" Definitely not for IPv4 due to its deployed base but perhaps it could be done for IPv6 - it is an idea - why not? -----Original Message----- From: Edward Vielmetti [mailto:evielmet@cisco.com] Sent: Wednesday, April 18, 2001 12:41 PM To: Morrow, Glenn [RICH2:C330:EXCH] Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Subject: RE: Source addresses, DDoS prevention and ingress filtering And you're going to mandate source filtering on the first hop across the entire internet, how? It's a great idea and a best common practice but not something that can be set by fiat. Ed On Wed, 18 Apr 2001, Glenn Morrow wrote: > Then again if source filtering is mandated on the first hop this might > eliminate the need to do filtering on other hops and this would eliminate > the need to do subnet translation or tunneling by either the MN or the MR. > > -----Original Message----- > From: Morrow, Glenn [RICH2:C330:EXCH] > Sent: Wednesday, April 18, 2001 11:56 AM > To: 'Michael Thomas' > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Oh, I see what you were concerned about. It seems to me that an MR will have > to tunnel or subnet translate unless it is on it's home subnet. > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, April 18, 2001 9:49 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Glenn Morrow writes: > > If the node behind the MR obtained its home address from the the mobile > > router's subnet, then the MN will use this as the source i.e. the MN's > home > > subnet is the MR's subnet. > > Right, but when the MR's upstream router does an > RPF check... it will drop the SN's packets. > > > Either way (tunneling or subnet translation), the topological correctness > is > > still maintained. > > Well, that's sort of the problem. The SN doesn't > know that it's putting topologically incorrect > source address in the IP header. > > Mike > ------_=_NextPart_001_01C0C83E.FB281710 Content-Type: text/html; charset="iso-8859-1" RE: Source addresses, DDoS prevention and ingress filtering

Definitely not for IPv4 due to its deployed base but perhaps it could be done for IPv6 - it is an idea - why not?

-----Original Message-----
From: Edward Vielmetti [mailto:evielmet@cisco.com]
Sent: Wednesday, April 18, 2001 12:41 PM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com';
'ietf-itrace@research.att.com'
Subject: RE: Source addresses, DDoS prevention and ingress filtering


And you're going to mandate source filtering on the first hop across the
entire internet, how?  It's a great idea and a best common practice but
not something that can be set by fiat.

Ed

On Wed, 18 Apr 2001, Glenn Morrow wrote:

> Then again if source filtering is mandated on the first hop this might
> eliminate the need to do filtering on other hops and this would eliminate
> the need to do subnet translation or tunneling by either the MN or the MR.
>
> -----Original Message-----
> From: Morrow, Glenn [RICH2:C330:EXCH]
> Sent: Wednesday, April 18, 2001 11:56 AM
> To: 'Michael Thomas'
> Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com';
> 'ietf-itrace@research.att.com'
> Subject: RE: Source addresses, DDoS prevention and ingress filtering
>
>
> Oh, I see what you were concerned about. It seems to me that an MR will have
> to tunnel or subnet translate unless it is on it's home subnet.
>
> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, April 18, 2001 9:49 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com';
> 'ietf-itrace@research.att.com'
> Subject: RE: Source addresses, DDoS prevention and ingress filtering
>
>
> Glenn Morrow writes:
>  > If the node behind the MR obtained its home address from the  the mobile
>  > router's subnet, then the MN will use this as the source i.e. the MN's
> home
>  > subnet is the MR's subnet.
>
>    Right, but when the MR's upstream router does an
>    RPF check... it will drop the SN's packets.
>
>  > Either way (tunneling or subnet translation), the topological correctness
> is
>  > still maintained.
>
>    Well, that's sort of the problem. The SN doesn't
>    know that it's putting topologically incorrect
>    source address in the IP header.
>
>                 Mike
>

------_=_NextPart_001_01C0C83E.FB281710-- -------------------------------------------------------------------- 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 Apr 18 12:43:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IJhEK9005365 for ; Wed, 18 Apr 2001 12:43:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IJhENb005364 for ipng-dist; Wed, 18 Apr 2001 12:43:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IJh4K9005356 for ; Wed, 18 Apr 2001 12:43:04 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26652 for ; Wed, 18 Apr 2001 12:43:03 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21085 for ; Wed, 18 Apr 2001 12:43:02 -0700 (PDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA28187 for ; Wed, 18 Apr 2001 14:43:13 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 18 Apr 2001 14:42:28 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 14:42:18 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301EEFEEC@crchy271.us.nortel.com> From: "Glenn Morrow" To: Edward Vielmetti Cc: Michael Thomas , Thomas Eklund , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Wed, 18 Apr 2001 14:42:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C83F.AD184E40" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C83F.AD184E40 Content-Type: text/plain; charset="iso-8859-1" If the standard mandates it - vendors must build it in the routing products just as they have to support ICMP etc.. -----Original Message----- From: Morrow, Glenn [RICH2:C330:EXCH] Sent: Wednesday, April 18, 2001 2:33 PM To: 'Edward Vielmetti' Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Subject: RE: Source addresses, DDoS prevention and ingress filtering Definitely not for IPv4 due to its deployed base but perhaps it could be done for IPv6 - it is an idea - why not? -----Original Message----- From: Edward Vielmetti [mailto:evielmet@cisco.com] Sent: Wednesday, April 18, 2001 12:41 PM To: Morrow, Glenn [RICH2:C330:EXCH] Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Subject: RE: Source addresses, DDoS prevention and ingress filtering And you're going to mandate source filtering on the first hop across the entire internet, how? It's a great idea and a best common practice but not something that can be set by fiat. Ed On Wed, 18 Apr 2001, Glenn Morrow wrote: > Then again if source filtering is mandated on the first hop this might > eliminate the need to do filtering on other hops and this would eliminate > the need to do subnet translation or tunneling by either the MN or the MR. > > -----Original Message----- > From: Morrow, Glenn [RICH2:C330:EXCH] > Sent: Wednesday, April 18, 2001 11:56 AM > To: 'Michael Thomas' > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Oh, I see what you were concerned about. It seems to me that an MR will have > to tunnel or subnet translate unless it is on it's home subnet. > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, April 18, 2001 9:49 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Glenn Morrow writes: > > If the node behind the MR obtained its home address from the the mobile > > router's subnet, then the MN will use this as the source i.e. the MN's > home > > subnet is the MR's subnet. > > Right, but when the MR's upstream router does an > RPF check... it will drop the SN's packets. > > > Either way (tunneling or subnet translation), the topological correctness > is > > still maintained. > > Well, that's sort of the problem. The SN doesn't > know that it's putting topologically incorrect > source address in the IP header. > > Mike > ------_=_NextPart_001_01C0C83F.AD184E40 Content-Type: text/html; charset="iso-8859-1" RE: Source addresses, DDoS prevention and ingress filtering

If the standard mandates it - vendors must build it in the routing products just as they have to support ICMP etc..

-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH]
Sent: Wednesday, April 18, 2001 2:33 PM
To: 'Edward Vielmetti'
Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com';
'ietf-itrace@research.att.com'
Subject: RE: Source addresses, DDoS prevention and ingress filtering


Definitely not for IPv4 due to its deployed base but perhaps it could be done for IPv6 - it is an idea - why not?

-----Original Message-----
From: Edward Vielmetti [mailto:evielmet@cisco.com]
Sent: Wednesday, April 18, 2001 12:41 PM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com';
'ietf-itrace@research.att.com'
Subject: RE: Source addresses, DDoS prevention and ingress filtering


And you're going to mandate source filtering on the first hop across the
entire internet, how?  It's a great idea and a best common practice but
not something that can be set by fiat.

Ed

On Wed, 18 Apr 2001, Glenn Morrow wrote:

> Then again if source filtering is mandated on the first hop this might
> eliminate the need to do filtering on other hops and this would eliminate
> the need to do subnet translation or tunneling by either the MN or the MR.
>
> -----Original Message-----
> From: Morrow, Glenn [RICH2:C330:EXCH]
> Sent: Wednesday, April 18, 2001 11:56 AM
> To: 'Michael Thomas'
> Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com';
> 'ietf-itrace@research.att.com'
> Subject: RE: Source addresses, DDoS prevention and ingress filtering
>
>
> Oh, I see what you were concerned about. It seems to me that an MR will have
> to tunnel or subnet translate unless it is on it's home subnet.
>
> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, April 18, 2001 9:49 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com';
> 'ietf-itrace@research.att.com'
> Subject: RE: Source addresses, DDoS prevention and ingress filtering
>
>
> Glenn Morrow writes:
>  > If the node behind the MR obtained its home address from the  the mobile
>  > router's subnet, then the MN will use this as the source i.e. the MN's
> home
>  > subnet is the MR's subnet.
>
>    Right, but when the MR's upstream router does an
>    RPF check... it will drop the SN's packets.
>
>  > Either way (tunneling or subnet translation), the topological correctness
> is
>  > still maintained.
>
>    Well, that's sort of the problem. The SN doesn't
>    know that it's putting topologically incorrect
>    source address in the IP header.
>
>                 Mike
>

------_=_NextPart_001_01C0C83F.AD184E40-- -------------------------------------------------------------------- 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 Apr 18 12:50:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IJoXK9005383 for ; Wed, 18 Apr 2001 12:50:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IJoXAJ005382 for ipng-dist; Wed, 18 Apr 2001 12:50:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IJoIK9005375 for ; Wed, 18 Apr 2001 12:50:18 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04287 for ; Wed, 18 Apr 2001 12:50:12 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26720 for ; Wed, 18 Apr 2001 12:50:12 -0700 (PDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA00356 for ; Wed, 18 Apr 2001 14:50:28 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 18 Apr 2001 14:49:58 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Apr 2001 14:49:47 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301EEFF13@crchy271.us.nortel.com> From: "Glenn Morrow" To: Edward Vielmetti Cc: Michael Thomas , Thomas Eklund , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Wed, 18 Apr 2001 14:49:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C840.B8249040" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C840.B8249040 Content-Type: text/plain; charset="iso-8859-1" If something is not configurable, it IS essentially equivalent to a fiat in an analogous sense. -----Original Message----- From: Morrow, Glenn [RICH2:C330:EXCH] Sent: Wednesday, April 18, 2001 2:38 PM To: 'Edward Vielmetti' Cc: 'Michael Thomas'; 'Thomas Eklund'; 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Subject: RE: Source addresses, DDoS prevention and ingress filtering If the standard mandates it - vendors must build it in the routing products just as they have to support ICMP etc.. -----Original Message----- From: Morrow, Glenn [RICH2:C330:EXCH] Sent: Wednesday, April 18, 2001 2:33 PM To: 'Edward Vielmetti' Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Subject: RE: Source addresses, DDoS prevention and ingress filtering Definitely not for IPv4 due to its deployed base but perhaps it could be done for IPv6 - it is an idea - why not? -----Original Message----- From: Edward Vielmetti [mailto:evielmet@cisco.com] Sent: Wednesday, April 18, 2001 12:41 PM To: Morrow, Glenn [RICH2:C330:EXCH] Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Subject: RE: Source addresses, DDoS prevention and ingress filtering And you're going to mandate source filtering on the first hop across the entire internet, how? It's a great idea and a best common practice but not something that can be set by fiat. Ed On Wed, 18 Apr 2001, Glenn Morrow wrote: > Then again if source filtering is mandated on the first hop this might > eliminate the need to do filtering on other hops and this would eliminate > the need to do subnet translation or tunneling by either the MN or the MR. > > -----Original Message----- > From: Morrow, Glenn [RICH2:C330:EXCH] > Sent: Wednesday, April 18, 2001 11:56 AM > To: 'Michael Thomas' > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Oh, I see what you were concerned about. It seems to me that an MR will have > to tunnel or subnet translate unless it is on it's home subnet. > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, April 18, 2001 9:49 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Glenn Morrow writes: > > If the node behind the MR obtained its home address from the the mobile > > router's subnet, then the MN will use this as the source i.e. the MN's > home > > subnet is the MR's subnet. > > Right, but when the MR's upstream router does an > RPF check... it will drop the SN's packets. > > > Either way (tunneling or subnet translation), the topological correctness > is > > still maintained. > > Well, that's sort of the problem. The SN doesn't > know that it's putting topologically incorrect > source address in the IP header. > > Mike > ------_=_NextPart_001_01C0C840.B8249040 Content-Type: text/html; charset="iso-8859-1" RE: Source addresses, DDoS prevention and ingress filtering

If something is not configurable, it IS essentially equivalent to a fiat in an analogous sense.

-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH]
Sent: Wednesday, April 18, 2001 2:38 PM
To: 'Edward Vielmetti'
Cc: 'Michael Thomas'; 'Thomas Eklund'; 'ipng@sunroof.eng.sun.com';
'ietf-itrace@research.att.com'
Subject: RE: Source addresses, DDoS prevention and ingress filtering


If the standard mandates it - vendors must build it in the routing products just as they have to support ICMP etc..

-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH]
Sent: Wednesday, April 18, 2001 2:33 PM
To: 'Edward Vielmetti'
Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com';
'ietf-itrace@research.att.com'
Subject: RE: Source addresses, DDoS prevention and ingress filtering


Definitely not for IPv4 due to its deployed base but perhaps it could be done for IPv6 - it is an idea - why not?

-----Original Message-----
From: Edward Vielmetti [mailto:evielmet@cisco.com]
Sent: Wednesday, April 18, 2001 12:41 PM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com';
'ietf-itrace@research.att.com'
Subject: RE: Source addresses, DDoS prevention and ingress filtering


And you're going to mandate source filtering on the first hop across the
entire internet, how?  It's a great idea and a best common practice but
not something that can be set by fiat.

Ed

On Wed, 18 Apr 2001, Glenn Morrow wrote:

> Then again if source filtering is mandated on the first hop this might
> eliminate the need to do filtering on other hops and this would eliminate
> the need to do subnet translation or tunneling by either the MN or the MR.
>
> -----Original Message-----
> From: Morrow, Glenn [RICH2:C330:EXCH]
> Sent: Wednesday, April 18, 2001 11:56 AM
> To: 'Michael Thomas'
> Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com';
> 'ietf-itrace@research.att.com'
> Subject: RE: Source addresses, DDoS prevention and ingress filtering
>
>
> Oh, I see what you were concerned about. It seems to me that an MR will have
> to tunnel or subnet translate unless it is on it's home subnet.
>
> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, April 18, 2001 9:49 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com';
> 'ietf-itrace@research.att.com'
> Subject: RE: Source addresses, DDoS prevention and ingress filtering
>
>
> Glenn Morrow writes:
>  > If the node behind the MR obtained its home address from the  the mobile
>  > router's subnet, then the MN will use this as the source i.e. the MN's
> home
>  > subnet is the MR's subnet.
>
>    Right, but when the MR's upstream router does an
>    RPF check... it will drop the SN's packets.
>
>  > Either way (tunneling or subnet translation), the topological correctness
> is
>  > still maintained.
>
>    Well, that's sort of the problem. The SN doesn't
>    know that it's putting topologically incorrect
>    source address in the IP header.
>
>                 Mike
>

------_=_NextPart_001_01C0C840.B8249040-- -------------------------------------------------------------------- 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 Apr 18 15:30:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IMU0K9005551 for ; Wed, 18 Apr 2001 15:30:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3IMU0cP005550 for ipng-dist; Wed, 18 Apr 2001 15:30:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3IMToK9005543 for ; Wed, 18 Apr 2001 15:29:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07996 for ; Wed, 18 Apr 2001 15:29:51 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13968 for ; Wed, 18 Apr 2001 15:29:49 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id PAA19421; Wed, 18 Apr 2001 15:15:02 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AEF15386; Wed, 18 Apr 2001 15:16:22 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA09782; Wed, 18 Apr 2001 15:16:22 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15070.4662.562709.197201@thomasm-u1.cisco.com> Date: Wed, 18 Apr 2001 15:16:22 -0700 (PDT) To: "Glenn Morrow" Cc: Edward Vielmetti , Michael Thomas , Thomas Eklund , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering In-Reply-To: <85AA7486A2C1D411BCA20000F8073E4301EEFEDE@crchy271.us.nortel.com> References: <85AA7486A2C1D411BCA20000F8073E4301EEFEDE@crchy271.us.nortel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Note that RPF checks aren't foolproof; asymmetric routes can cause them to kill off traffic that shouldn't be killed. My best guess of why RPF checks have become popular is that they're really trivial for routers to perform and enforce (just a FIB lookup). The same protection could be provided via L3+ filtering, though the configuration and performance is more problematic (though not overly so, IMO). Just as a note: RPF needs to be done at the edges of the trust boundary, not the first hop router. Mike Glenn Morrow writes: > Definitely not for IPv4 due to its deployed base but perhaps it could be > done for IPv6 - it is an idea - why not? > > -----Original Message----- > From: Edward Vielmetti [mailto:evielmet@cisco.com] > Sent: Wednesday, April 18, 2001 12:41 PM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > And you're going to mandate source filtering on the first hop across the > entire internet, how? It's a great idea and a best common practice but > not something that can be set by fiat. > > Ed > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > Then again if source filtering is mandated on the first hop this might > > eliminate the need to do filtering on other hops and this would eliminate > > the need to do subnet translation or tunneling by either the MN or the MR. > > > > -----Original Message----- > > From: Morrow, Glenn [RICH2:C330:EXCH] > > Sent: Wednesday, April 18, 2001 11:56 AM > > To: 'Michael Thomas' > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > 'ietf-itrace@research.att.com' > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > Oh, I see what you were concerned about. It seems to me that an MR will > have > > to tunnel or subnet translate unless it is on it's home subnet. > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Wednesday, April 18, 2001 9:49 AM > > To: Morrow, Glenn [RICH2:C330:EXCH] > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > 'ietf-itrace@research.att.com' > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > Glenn Morrow writes: > > > If the node behind the MR obtained its home address from the the > mobile > > > router's subnet, then the MN will use this as the source i.e. the MN's > > home > > > subnet is the MR's subnet. > > > > Right, but when the MR's upstream router does an > > RPF check... it will drop the SN's packets. > > > > > Either way (tunneling or subnet translation), the topological > correctness > > is > > > still maintained. > > > > Well, that's sort of the problem. The SN doesn't > > know that it's putting topologically incorrect > > source address in the IP header. > > > > Mike > > > > > > > > > RE: Source addresses, DDoS prevention and ingress filtering > > > >

Definitely not for IPv4 due to its deployed base but perhaps it could be done for IPv6 - it is an idea - why not? >

> >

-----Original Message----- >
From: Edward Vielmetti [mailto:evielmet@cisco.com] >
Sent: Wednesday, April 18, 2001 12:41 PM >
To: Morrow, Glenn [RICH2:C330:EXCH] >
Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; >
'ietf-itrace@research.att.com' >
Subject: RE: Source addresses, DDoS prevention and ingress filtering >

>
> >

And you're going to mandate source filtering on the first hop across the >
entire internet, how?  It's a great idea and a best common practice but >
not something that can be set by fiat. >

> >

Ed >

> >

On Wed, 18 Apr 2001, Glenn Morrow wrote: >

> >

> Then again if source filtering is mandated on the first hop this might >
> eliminate the need to do filtering on other hops and this would eliminate >
> the need to do subnet translation or tunneling by either the MN or the MR. >
> >
> -----Original Message----- >
> From: Morrow, Glenn [RICH2:C330:EXCH] >
> Sent: Wednesday, April 18, 2001 11:56 AM >
> To: 'Michael Thomas' >
> Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; >
> 'ietf-itrace@research.att.com' >
> Subject: RE: Source addresses, DDoS prevention and ingress filtering >
> >
> >
> Oh, I see what you were concerned about. It seems to me that an MR will have >
> to tunnel or subnet translate unless it is on it's home subnet. >
> >
> -----Original Message----- >
> From: Michael Thomas [mailto:mat@cisco.com] >
> Sent: Wednesday, April 18, 2001 9:49 AM >
> To: Morrow, Glenn [RICH2:C330:EXCH] >
> Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; >
> 'ietf-itrace@research.att.com' >
> Subject: RE: Source addresses, DDoS prevention and ingress filtering >
> >
> >
> Glenn Morrow writes: >
>  > If the node behind the MR obtained its home address from the  the mobile >
>  > router's subnet, then the MN will use this as the source i.e. the MN's >
> home >
>  > subnet is the MR's subnet. >
> >
>    Right, but when the MR's upstream router does an >
>    RPF check... it will drop the SN's packets. >
> >
>  > Either way (tunneling or subnet translation), the topological correctness >
> is >
>  > still maintained. >
> >
>    Well, that's sort of the problem. The SN doesn't >
>    know that it's putting topologically incorrect >
>    source address in the IP header. >
> >
>                 Mike >
> >

> > > -------------------------------------------------------------------- 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 Apr 19 01:07:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J87IK9005988 for ; Thu, 19 Apr 2001 01:07:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3J87IIa005987 for ipng-dist; Thu, 19 Apr 2001 01:07:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J878K9005980 for ; Thu, 19 Apr 2001 01:07:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA18370 for ; Thu, 19 Apr 2001 01:07:08 -0700 (PDT) Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA12326 for ; Thu, 19 Apr 2001 02:50:39 -0600 (MDT) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA25677 for ; Thu, 19 Apr 2001 04:07:06 -0400 (EDT) Received: from ci1093exch001p.wins.lucent.com (h135-252-12-239.lucent.com [135.252.12.239]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA25672 for ; Thu, 19 Apr 2001 04:07:05 -0400 (EDT) Received: by CI1093EXCH001P with Internet Mail Service (5.5.2650.21) id <2K5A56Z2>; Thu, 19 Apr 2001 16:07:03 +0800 Message-ID: <31C0F08B0D18D511ACC800508BAE7B47031C74@CI0026EXCH001U> From: "Li, Ke Qin (Peter)" To: "'ospf@discuss.microsoft.com'" , "'ipng@sunroof.eng.sun.com'" Subject: Questions about OSPF for IPv6 Date: Thu, 19 Apr 2001 16:07:01 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="gb2312" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I have two questions about OSPF for IPv6: 1. How should Router IDs be assigned while they can no longer be assigned as addresses? 2. In section 2.8, "Router interface information may be spread across multiple Router LSAs." I think it's a tradeoff between packet size and LSD size. Why do we perfer smaller packet size in OSPF for IPv6 instead of smaller LSD size in OSPF for IPv4? Thanks a lot. Li, Keqin (Peter) Tel: 86 10 6874 8088x8438 Fax: 86 10 6874 8225 Email: keqinli@lucent.com Add: 3th /F, Aero Space Great Wall Building No. 30, Hai Dian Nan Lu Beijing, 100080 China -------------------------------------------------------------------- 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 Apr 19 01:55:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J8tRK9006115 for ; Thu, 19 Apr 2001 01:55:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3J8tQRI006114 for ipng-dist; Thu, 19 Apr 2001 01:55:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J8tHK9006107 for ; Thu, 19 Apr 2001 01:55:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04374 for ; Thu, 19 Apr 2001 01:55:17 -0700 (PDT) Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA00594 for ; Thu, 19 Apr 2001 03:37:47 -0600 (MDT) Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (8.9.3+3.2W/3.7Wpl2-shonan) with ESMTP id RAA06584; Thu, 19 Apr 2001 17:55:04 +0900 (JST) (envelope-from yasu@sfc.wide.ad.jp) To: keqinli@lucent.com Cc: ospf@discuss.microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: Questions about OSPF for IPv6 From: Yasuhiro Ohara In-Reply-To: <31C0F08B0D18D511ACC800508BAE7B47031C74@CI0026EXCH001U> References: <31C0F08B0D18D511ACC800508BAE7B47031C74@CI0026EXCH001U> X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-URL: http://www.sfc.wide.ad.jp/~yasu/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010419175503J.yasu@sfc.wide.ad.jp> Date: Thu, 19 Apr 2001 17:55:03 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 56 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk keqinli> Hi all, keqinli> keqinli> I have two questions about OSPF for IPv6: keqinli> keqinli> 1. How should Router IDs be assigned while they can no longer keqinli> be assigned as addresses? It is left configurable. For example, WIDE Project took one of the IPv4 addresses as Router-ID since the router trying to speak OSPFv3 actually speaks IPv4 too. ospf6d@pc3.nezu> show ipv6 ospf6 neighbor RouterID Pri State DR BDR I/F[State] 203.178.140.204 1 Full 0.0.0.0 0.0.0.0 pvc2[PointToPoint] 203.178.140.236 1 Full 0.0.0.0 0.0.0.0 pvc3[PointToPoint] 203.178.137.103 1 Full 0.0.0.0 0.0.0.0 pvc4[PointToPoint] 203.178.138.235 1 Full 203.178.142.198 203.178.138.235 fxp0[DR] 203.178.141.202 1 Full 0.0.0.0 0.0.0.0 pvc0[PointToPoint] keqinli> 2. In section 2.8, "Router interface information may be spread across keqinli> multiple Router LSAs." I think it's a tradeoff between packet size and LSD keqinli> size. Why do we perfer smaller packet size in OSPF for IPv6 instead of keqinli> smaller LSD size in OSPF for IPv4? I don't think it's a tradeoff. It is a intension to support the case if the LSD size is larger than the Maximum LSA size which is due to the Maximum OSPF packet size (65,535 bytes). >From RFC2740: A.1 Encapsulation of OSPF packets OSPF runs directly over the IPv6's network layer. OSPF packets are therefore encapsulated solely by IPv6 and local data-link headers. OSPF does not define a way to fragment its protocol packets, and depends on IPv6 fragmentation when transmitting packets larger than the link MTU. If necessary, the length of OSPF packets can be up to 65,535 bytes. The OSPF packet types that are likely to be large (Database Description Packets, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several separate protocol packets, without loss of functionality. This is recommended; IPv6 fragmentation should be avoided whenever possible. Using this reasoning, an attempt should be made to limit the sizes of OSPF packets sent over virtual links to 1280 bytes unless Path MTU Discovery is being performed [Ref14]. yasu -------------------------------------------------------------------- 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 Apr 19 02:15:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J9FNK9006153 for ; Thu, 19 Apr 2001 02:15:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3J9FMfa006152 for ipng-dist; Thu, 19 Apr 2001 02:15:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J9FDK9006145 for ; Thu, 19 Apr 2001 02:15:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05943 for ; Thu, 19 Apr 2001 02:15:12 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA08200 for ; Thu, 19 Apr 2001 03:58:30 -0600 (MDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id LAA13215; Thu, 19 Apr 2001 11:14:37 +0200 (MEST) Message-ID: <3ADEAC6C.8E5DEA26@inrialpes.fr> Date: Thu, 19 Apr 2001 11:14:20 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: Re: Source addresses, DDoS prevention and ingress filtering References: <85AA7486A2C1D411BCA20000F8073E4301EEFCBC@crchy271.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, About this issue regarding nodes behind a MR, I would like to tell interested people that we (MOTOROLA Labs and INRIA) have started to tackle the problems associated with this issue in my draft "Mobile Networks Support in Mobile IPv6" that I presented to the Mobile IP working group last year (http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt) The draft needs revisions following the recent discussions in the Mobile IP and Seamoby WG. I will submit a revision prior to next IETF meeting. The current version only addresses some of the issues. In fact, there are many issues to address, and I think the right place to discuss it is the Mobile IP WG. In my draft, I propose that mobility of the mobile network be hidden to nodes behind the MR (the MR operates Mobile IPv6). in this case the source address will always be an address topologically correct with respect of the MR's network prefix on its home link, but not with respect to the point of attachment of the MR. In face of ingress filtering, the solution is to tunnel the packet from the MR. Thierry. > Oh, I see what you were concerned about. It seems to me that an MR > will have to tunnel or subnet translate unless it is on it's home > subnet. > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, April 18, 2001 9:49 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > Glenn Morrow writes: > > If the node behind the MR obtained its home address from the the > mobile > > router's subnet, then the MN will use this as the source i.e. the > MN's home > > subnet is the MR's subnet. > > Right, but when the MR's upstream router does an > RPF check... it will drop the SN's packets. > > > Either way (tunneling or subnet translation), the topological > correctness is > > still maintained. > > Well, that's sort of the problem. The SN doesn't > know that it's putting topologically incorrect > source address in the IP header. > > Mike -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html -------------------------------------------------------------------- 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 Apr 19 02:43:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J9hUK9006308 for ; Thu, 19 Apr 2001 02:43:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3J9hTgt006307 for ipng-dist; Thu, 19 Apr 2001 02:43:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3J9hKK9006299 for ; Thu, 19 Apr 2001 02:43:20 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08106 for ; Thu, 19 Apr 2001 02:43:19 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16002 for ; Thu, 19 Apr 2001 02:43:19 -0700 (PDT) Received: from cisco.com (adario@lon-sto4-lan-vlan133-dhcp19.cisco.com [144.254.108.86]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA01158; Thu, 19 Apr 2001 10:43:15 +0100 (BST) Message-ID: <3ADEB332.A25DBE8C@cisco.com> Date: Thu, 19 Apr 2001 10:43:14 +0100 From: Dario Accornero Organization: Cisco Systems X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 MIBS: Internet Drafts References: <200104181845.LAA03235@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Fenner wrote: > > Dario and IPNG list, > > The drafts have not changed, and we have no major changes pending. > We'd encourage comments on the -00 versions of the drafts. > > Thanks, > Bill I will post my comments next week. In the meanwhile, what I can say from an implementation point of view is that the new MIBs are nicer. :-) Ciao, -- Dario Accornero - IOS Europe Development - IPv6 Team Stockley Park, Uxbridge, UK - voice +44 20 8756 6268 -------------------------------------------------------------------- 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 Apr 19 09:09:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JG9IK9006917 for ; Thu, 19 Apr 2001 09:09:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JG9H2v006916 for ipng-dist; Thu, 19 Apr 2001 09:09:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JG98K9006909 for ; Thu, 19 Apr 2001 09:09:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17405 for ; Thu, 19 Apr 2001 09:09:08 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17912 for ; Thu, 19 Apr 2001 09:09:07 -0700 (PDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA14729 for ; Thu, 19 Apr 2001 11:09:24 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 19 Apr 2001 11:08:54 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Apr 2001 11:08:43 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301EF0582@crchy271.us.nortel.com> From: "Glenn Morrow" To: Thierry Ernst Cc: "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Thu, 19 Apr 2001 11:08:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C8EA.FDCAC240" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C8EA.FDCAC240 Content-Type: text/plain; charset="iso-8859-1" Thierry, Thanks for bringing up your draft. I have read it. Have they made it a WG draft in the MIP WG - if not - why not? Politics or is there something technical? Was there ever a hmmm on it? -----Original Message----- From: Thierry Ernst [mailto:thierry.ernst@inrialpes.fr] Sent: Thursday, April 19, 2001 4:14 AM Cc: 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Subject: Re: Source addresses, DDoS prevention and ingress filtering Hi all, About this issue regarding nodes behind a MR, I would like to tell interested people that we (MOTOROLA Labs and INRIA) have started to tackle the problems associated with this issue in my draft "Mobile Networks Support in Mobile IPv6" that I presented to the Mobile IP working group last year (http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip -v6-network.txt) The draft needs revisions following the recent discussions in the Mobile IP and Seamoby WG. I will submit a revision prior to next IETF meeting. The current version only addresses some of the issues. In fact, there are many issues to address, and I think the right place to discuss it is the Mobile IP WG. In my draft, I propose that mobility of the mobile network be hidden to nodes behind the MR (the MR operates Mobile IPv6). in this case the source address will always be an address topologically correct with respect of the MR's network prefix on its home link, but not with respect to the point of attachment of the MR. In face of ingress filtering, the solution is to tunnel the packet from the MR. Thierry. > Oh, I see what you were concerned about. It seems to me that an MR > will have to tunnel or subnet translate unless it is on it's home > subnet. > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, April 18, 2001 9:49 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > Glenn Morrow writes: > > If the node behind the MR obtained its home address from the the > mobile > > router's subnet, then the MN will use this as the source i.e. the > MN's home > > subnet is the MR's subnet. > > Right, but when the MR's upstream router does an > RPF check... it will drop the SN's packets. > > > Either way (tunneling or subnet translation), the topological > correctness is > > still maintained. > > Well, that's sort of the problem. The SN doesn't > know that it's putting topologically incorrect > source address in the IP header. > > Mike -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html -------------------------------------------------------------------- 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 -------------------------------------------------------------------- ------_=_NextPart_001_01C0C8EA.FDCAC240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Source addresses, DDoS prevention and ingress = filtering

Thierry,

Thanks for bringing up your draft. I have read it. = Have they made it a WG draft in the MIP WG - if not - why not? Politics = or is there something technical? Was there ever a hmmm on = it?

-----Original Message-----
From: Thierry Ernst [mailto:thierry.ernst@inrialpe= s.fr]
Sent: Thursday, April 19, 2001 4:14 AM
Cc: 'ipng@sunroof.eng.sun.com'; = 'ietf-itrace@research.att.com'
Subject: Re: Source addresses, DDoS prevention and = ingress filtering


Hi all,

About this issue regarding nodes behind a MR, I would = like to tell
interested people that we (MOTOROLA Labs and INRIA) = have started to
tackle the problems associated with this issue in my = draft  "Mobile
Networks Support in Mobile IPv6" that I = presented to the Mobile IP
working group last year
(http://www.inrialpes.fr/planete/people/ernst/Documents= /draft-ernst-mobileip-v6-network.txt)

The draft needs revisions following the recent = discussions in the Mobile
IP and Seamoby WG.  I  will submit a = revision prior to next IETF
meeting.   The current version only = addresses some of the issues.  In
fact, there are many issues to address, and I think = the right place to
discuss it is the Mobile IP WG.

In my draft, I propose that mobility of the mobile = network be hidden to
nodes behind the MR (the MR operates Mobile = IPv6).  in this case the
source address will always be an address = topologically correct with
respect of the MR's network prefix on its home link, = but not with
respect to the point of attachment of the = MR.   In face of ingress
filtering, the solution is to tunnel the packet from = the MR.

Thierry.


> Oh, I see what you were concerned about. It = seems to me that an MR
> will have to tunnel or subnet translate unless = it is on it's home
> subnet.
>
> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, April 18, 2001 9:49 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: Michael Thomas; Thomas Eklund; = 'ipng@sunroof.eng.sun.com';
> 'ietf-itrace@research.att.com'
> Subject: RE: Source addresses, DDoS prevention = and ingress filtering
>
> Glenn Morrow writes:
>  > If the node behind the MR obtained = its home address from the  the
> mobile
>  > router's subnet, then the MN will = use this as the source i.e. the
> MN's home
>  > subnet is the MR's subnet.
>
>    Right, but when the MR's = upstream router does an
>    RPF check... it will drop the = SN's packets.
>
>  > Either way (tunneling or subnet = translation), the topological
> correctness is
>  > still maintained.
>
>    Well, that's sort of the = problem. The SN doesn't
>    know that it's putting = topologically incorrect
>    source address in the IP = header.
>
>          = ;         Mike

--
* mailto:Thierry.Ernst@inrialpe= s.fr  Tel +33 (0) 4 76 61 52 69
* INRIA Rhone-Alpes Projet = PLANETE       (fax 52 52)
* and MOTOROLA Labs Paris
* http://www.inrialpes.fr/planete/people/ernst/Welcome.h= tml
---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C0C8EA.FDCAC240-- -------------------------------------------------------------------- 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 Apr 19 10:23:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JHNdK9007085 for ; Thu, 19 Apr 2001 10:23:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JHNcDA007084 for ipng-dist; Thu, 19 Apr 2001 10:23:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JHNTK9007077 for ; Thu, 19 Apr 2001 10:23:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06604 for ; Thu, 19 Apr 2001 10:23:29 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29869 for ; Thu, 19 Apr 2001 10:23:27 -0700 (PDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id SAA24911; Thu, 19 Apr 2001 18:30:27 +0200 (MEST) Message-ID: <3ADF1292.BA759A38@inrialpes.fr> Date: Thu, 19 Apr 2001 18:30:11 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Morrow , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: Re: Source addresses, DDoS prevention and ingress filtering References: <85AA7486A2C1D411BCA20000F8073E4301EF0582@crchy271.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Glenn Morrow wrote: > > Thanks for bringing up your draft. I have read it. Have they made it a > WG draft in the MIP WG - if not - why not? Politics or is there > something technical? Was there ever a hmmm on it? Hi Glenn, Looks like it's time to push for it to become a working group item ... It's not yet a working group item because nobody explicitly asked for it, neither I (but a few people have raised the question). I first need to find some time to revise my draft (prior to July) and then I think it would be the right time to claim it should be a Mobile IP WG draft... Thanks for your support anyway, Thierry. > -----Original Message----- > From: Thierry Ernst [mailto:thierry.ernst@inrialpes.fr] > Sent: Thursday, April 19, 2001 4:14 AM > Cc: 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' > Subject: Re: Source addresses, DDoS prevention and ingress filtering > > Hi all, > > About this issue regarding nodes behind a MR, I would like to tell > interested people that we (MOTOROLA Labs and INRIA) have started to > tackle the problems associated with this issue in my draft "Mobile > Networks Support in Mobile IPv6" that I presented to the Mobile IP > working group last year > (http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt) > > The draft needs revisions following the recent discussions in the > Mobile > IP and Seamoby WG. I will submit a revision prior to next IETF > meeting. The current version only addresses some of the issues. In > fact, there are many issues to address, and I think the right place to > > discuss it is the Mobile IP WG. > > In my draft, I propose that mobility of the mobile network be hidden > to > nodes behind the MR (the MR operates Mobile IPv6). in this case the > source address will always be an address topologically correct with > respect of the MR's network prefix on its home link, but not with > respect to the point of attachment of the MR. In face of ingress > filtering, the solution is to tunnel the packet from the MR. > > Thierry. > -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html -------------------------------------------------------------------- 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 Apr 19 10:31:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JHVeK9007114 for ; Thu, 19 Apr 2001 10:31:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JHVduU007113 for ipng-dist; Thu, 19 Apr 2001 10:31:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JHVQK9007106 for ; Thu, 19 Apr 2001 10:31:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26034 for ; Thu, 19 Apr 2001 10:31:26 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14993 for ; Thu, 19 Apr 2001 12:16:29 -0600 (MDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA03583 for ; Thu, 19 Apr 2001 12:31:39 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 19 Apr 2001 12:31:07 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Apr 2001 12:30:57 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301EF06A9@crchy271.us.nortel.com> From: "Glenn Morrow" To: Michael Thomas Cc: Edward Vielmetti , Michael Thomas , Thomas Eklund , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Thu, 19 Apr 2001 12:30:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C8F6.7C7227E0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C8F6.7C7227E0 Content-Type: text/plain; charset="iso-8859-1" Mike, Usually when routing policy is set up to do assymetric routing, the special subnet exceptions are handled as part of any filtering on the first hop - are they not? On your note, why would this need to be done in IPv6 if filtering is mandated on the first hop. --------previous excerpt --------- Note that RPF checks aren't foolproof; asymmetric routes can cause them to kill off traffic that shouldn't be killed. My best guess of why RPF checks have become popular is that they're really trivial for routers to perform and enforce (just a FIB lookup). The same protection could be provided via L3+ filtering, though the configuration and performance is more problematic (though not overly so, IMO). Just as a note: RPF needs to be done at the edges of the trust boundary, not the first hop router. ------_=_NextPart_001_01C0C8F6.7C7227E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Source addresses, DDoS prevention and ingress = filtering

Mike,

 Usually when routing policy is set up to do = assymetric routing, the special subnet exceptions are handled as part = of any filtering on the first hop - are they not?

On your note, why would this need to be done in IPv6 = if filtering is mandated on the first hop.

--------previous excerpt ---------
Note that RPF checks aren't foolproof; = asymmetric
routes can cause them to kill off traffic = that
shouldn't be killed. My best guess of why RPF
checks have become popular is that they're = really
trivial for routers to perform and enforce (just = a
FIB lookup). The same protection could be = provided
via L3+ filtering, though the configuration = and
performance is more problematic (though not = overly
so, IMO).


Just as a note: RPF needs to be done at the = edges
of the trust boundary, not the first hop router. =

            

------_=_NextPart_001_01C0C8F6.7C7227E0-- -------------------------------------------------------------------- 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 Apr 19 12:06:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJ6ZK9007364 for ; Thu, 19 Apr 2001 12:06:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JJ6Zqm007363 for ipng-dist; Thu, 19 Apr 2001 12:06:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJ6QK9007356 for ; Thu, 19 Apr 2001 12:06:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22527 for ; Thu, 19 Apr 2001 12:06:25 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14680 for ; Thu, 19 Apr 2001 12:06:24 -0700 (PDT) Received: from localhost ([3ffe:8050:201:1860:7c66:7bfb:9f1f:b7f7]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id EAA06105; Fri, 20 Apr 2001 04:08:23 +0900 (JST) Date: Fri, 20 Apr 2001 04:05:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: Resend: more comments (questions) about draft-draves-ipngwg-router-selection-01.txt References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Fri_Apr_20_04:05:22_2001-1" X-Dispatcher: imput version 980905(IM100) Lines: 73 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Fri_Apr_20_04:05:22_2001-1 Content-Type: text/plain; charset=US-ASCII Sorry for bothering you again, but I don't think I've ever seen any responses to my question...could you please answer them? Or, if I miss something foundamental, please kindly say so. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Fri_Apr_20_04:05:22_2001-1 Content-Type: message/rfc822 X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Wed, 21 Mar 2001 15:00:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: more comments (questions) about draft-draves-ipngwg-router-selection-01.txt User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a couple of questions on the draft: 1. what should a host do when it receives an RA with the preference field being set to 10 (i.e. reserved)? - ignore the entire RA. - accept the RA, but consider the preference value as another value? if so, high/medium/low? - other option? 2. if the preference value for a router changes, does/should it affect existing destination cache entries? For example, consider the following scenario: - a host H receives an RA from a router R1 with the medium preference. - H sends a packet to an off-link destination D. H uses R as the next hop, and records H in the destination cache. - a host A then receives an RA from another router R2 with the high preference. now, what should happen on the destination cache for D in H? Should it be removed once, prompting H to do next hop determination again (and to choose the more preferred router R2). Or, should H just keep the old cache and its next hop until it becomes unreachable? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 -------------------------------------------------------------------- --Multipart_Fri_Apr_20_04:05:22_2001-1-- -------------------------------------------------------------------- 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 Apr 19 12:22:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJMYK9007396 for ; Thu, 19 Apr 2001 12:22:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JJMXp6007395 for ipng-dist; Thu, 19 Apr 2001 12:22:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJMOK9007388 for ; Thu, 19 Apr 2001 12:22:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12438 for ; Thu, 19 Apr 2001 12:22:18 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25212 for ; Thu, 19 Apr 2001 14:08:59 -0600 (MDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id <2SZQK00R>; Thu, 19 Apr 2001 21:22:20 +0200 Message-ID: <31A473DBB655D21180850008C71E251A0344DA39@mail.kebne.se> From: Thomas Eklund To: "'Michael Thomas '" , "'Glenn Morrow '" Cc: "''ipng@sunroof.eng.sun.com' '" , "''ietf-itrace@research.att.com' '" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Thu, 19 Apr 2001 21:22:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mike, Right, but when the MR's upstream router does an RPF check... it will drop the SN's packets. --> I assume you mean the reverse path forwading check in multicasting. If so, it is the same way as for v4, you must join a multicast group in your access network with your local/topological correct IP adress, which in case would be the CoA (not HA). If you would like to do it with security then you talking about secure multicast which is very pre mature but then I assume you would like to have done it with your HA (unless you did not use the AAA v6 draft of course then you could have used the CoA )and tunnel he traffic from your home subnet..:-) > Either way (tunneling or subnet translation), the topological correctness is > still maintained. Well, that's sort of the problem. The SN doesn't know that it's putting topologically incorrect source address in the IP header. Agreed, but IF the enterprise or service provider would haver used something like the AAAv6 draft then they would have known that the src address would be the same as the link identifier.... -- 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 Apr 19 12:24:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJOVK9007406 for ; Thu, 19 Apr 2001 12:24:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JJOUSh007405 for ipng-dist; Thu, 19 Apr 2001 12:24:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJOIK9007398 for ; Thu, 19 Apr 2001 12:24:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24017 for ; Thu, 19 Apr 2001 12:24:18 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28749 for ; Thu, 19 Apr 2001 12:24:17 -0700 (PDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id <2SZQK004>; Thu, 19 Apr 2001 21:24:21 +0200 Message-ID: <31A473DBB655D21180850008C71E251A0344DA3A@mail.kebne.se> From: Thomas Eklund To: "'Glenn Morrow '" , "'Edward Vielmetti '" Cc: "'Michael Thomas '" , "''ipng@sunroof.eng.sun.com' '" , "''ietf-itrace@research.att.com' '" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Thu, 19 Apr 2001 21:24:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree, and in fact using something like AAAv6 in combination with src filtering is a good start to reduce the DoS attacks... -- thomas -----Original Message----- From: Glenn Morrow To: Edward Vielmetti Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Sent: 2001-04-18 21:37 Subject: RE: Source addresses, DDoS prevention and ingress filtering Definitely not for IPv4 due to its deployed base but perhaps it could be done for IPv6 - it is an idea - why not? -----Original Message----- From: Edward Vielmetti [ mailto:evielmet@cisco.com ] Sent: Wednesday, April 18, 2001 12:41 PM To: Morrow, Glenn [RICH2:C330:EXCH] Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf-itrace@research.att.com' Subject: RE: Source addresses, DDoS prevention and ingress filtering And you're going to mandate source filtering on the first hop across the entire internet, how? It's a great idea and a best common practice but not something that can be set by fiat. Ed On Wed, 18 Apr 2001, Glenn Morrow wrote: > Then again if source filtering is mandated on the first hop this might > eliminate the need to do filtering on other hops and this would eliminate > the need to do subnet translation or tunneling by either the MN or the MR. > > -----Original Message----- > From: Morrow, Glenn [RICH2:C330:EXCH] > Sent: Wednesday, April 18, 2001 11:56 AM > To: 'Michael Thomas' > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Oh, I see what you were concerned about. It seems to me that an MR will have > to tunnel or subnet translate unless it is on it's home subnet. > > -----Original Message----- > From: Michael Thomas [ mailto:mat@cisco.com ] > Sent: Wednesday, April 18, 2001 9:49 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Glenn Morrow writes: > > If the node behind the MR obtained its home address from the the mobile > > router's subnet, then the MN will use this as the source i.e. the MN's > home > > subnet is the MR's subnet. > > Right, but when the MR's upstream router does an > RPF check... it will drop the SN's packets. > > > Either way (tunneling or subnet translation), the topological correctness > is > > still maintained. > > Well, that's sort of the problem. The SN doesn't > know that it's putting topologically incorrect > source address in the IP header. > > Mike > -------------------------------------------------------------------- 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 Apr 19 12:49:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJnpK9007498 for ; Thu, 19 Apr 2001 12:49:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JJno4c007497 for ipng-dist; Thu, 19 Apr 2001 12:49:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJniK9007490 for ; Thu, 19 Apr 2001 12:49:45 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f3JJkTH11277 for ipng@sunroof.eng.sun.com; Thu, 19 Apr 2001 12:46:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3GETsK9000288 for ; Mon, 16 Apr 2001 07:29:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21071 for ; Mon, 16 Apr 2001 07:29:52 -0700 (PDT) Received: from zmailer.org (mail.zmailer.org [194.252.70.162]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06592 for ; Mon, 16 Apr 2001 08:54:26 -0600 (MDT) Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org)) by mail.zmailer.org id ; Mon, 16 Apr 2001 17:29:39 +0300 Date: Mon, 16 Apr 2001 17:29:39 +0300 From: Matti Aarnio To: Kumarendra Sivarajah Cc: ipng@sunroof.eng.sun.com Subject: Re: 3G License Message-ID: <20010416172939.C805@mea-ext.zmailer.org> References: <3ADAE7AE.1684D1E5@ukc.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ADAE7AE.1684D1E5@ukc.ac.uk>; from ks51@ukc.ac.uk on Mon, Apr 16, 2001 at 01:38:06PM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I presume the question has been presented at this forum because one suggested key technology for 3G mobile networking is IPv6. On Mon, Apr 16, 2001 at 01:38:06PM +0100, Kumarendra Sivarajah wrote: > Hello > Does anyone know where I can find information on the auction value of > the 3G license all over the world for countries that have auctioned them > already, especially in Europe or if anyone has it, can you mail it to > me. Depending on country the prices have been: zero ( 0 ) few million ( 10^6 ) (up to 0.1 billion) few billion ( 10^9 ) (maybe tens of billion) UK has been record setting in greed (tens of billions per license), germany is close second (billions). Some incredible insanity had perveaded the participants. Soon afterwards were auctions at Spain and Italy, which collected in total around one billion euros for all licenses; a lot less than 1/10th of UK or Ger. Apparently highly expensive shock-treatment was needed... Finland, Sweden, and Norway gave out the licenses at essentially zero price. What happened elsewere, I stopped following. With license price of in order of 10 000 euros per capita in UK the prices of services will be astronomical... Profitability predictions have been presented as anything as early as 2003, and as late as 2020 .. Somehow I am inclined towards the late profitability... > Thanks, > INdran > -- > ################################################# > Kumarendra Sivarajah (INdran) > University of Kent at Canterbury > United Kingdom /Matti Aarnio -------------------------------------------------------------------- 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 Apr 19 12:49:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJnEK9007488 for ; Thu, 19 Apr 2001 12:49:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JJnESZ007487 for ipng-dist; Thu, 19 Apr 2001 12:49:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJnAK9007480 for ; Thu, 19 Apr 2001 12:49:10 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f3JJjsn11247 for ipng@sunroof.eng.sun.com; Thu, 19 Apr 2001 12:45:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3DDtoK9024391 for ; Fri, 13 Apr 2001 06:55:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01421 for ; Fri, 13 Apr 2001 06:55:50 -0700 (PDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11399 for ; Fri, 13 Apr 2001 06:55:49 -0700 (PDT) Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA53770 for ; Fri, 13 Apr 2001 09:56:02 -0500 Received: from d04nm300.raleigh.ibm.com (d04nm300.raleigh.ibm.com [9.67.228.165]) by southrelay01.raleigh.ibm.com (8.8.8m3/NCO v4.96) with ESMTP id JAA142440 for ; Fri, 13 Apr 2001 09:54:29 -0400 Importance: Normal Subject: Basic Socket Interface Extensions for IPv6, To: ipng@sunroof.eng.sun.com Cc: "Sue Huang" , "Roy Brabson" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Steve Hawley" Date: Fri, 13 Apr 2001 09:54:00 -0400 X-MIMETrack: Serialize by Router on D04NM300/04/M/IBM(Beta 1 M8_03292001|March 29, 2001) at 04/13/2001 09:54:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some questions have arisen from examination of section 6, the getnameinfo sub-section of the draft. This sub-section describes flags controlling the actions to be taken by the function: - If the flag bit NI_NUMERICSCOPE is set, the numeric form of the scope identifier is returned (for example, interface index) instead of its name. This flag is ignored if the sa argument is not an IPv6 address. - If the flag bit NI_DGRAM is set, this indicates that the service is a datagram service (SOCK_DGRAM). The default behavior is to assume that the service is a stream service (SOCK_STREAM). NI_NUMERICSCOPE is confusing. The draft does not mention NI_WITHSCOPEID. Earlier implementations of getnameinfo contain reference to NI_WITHSCOPEID which specifies that scope is to be returned. If NI_WITHSCOPEID is specified in flags then NI_NUMERICSCOPE makes sense. The scope is to be returned in numeric form. In the draft's current form, NI_NUMERICSCOPE seems to be a vestige, something that should have been removed but wasn't. At the moment IBM does not plan to include NI_NUMERICSCOPE in our implementation of getnameinfo. Comments on this interpretation of the draft would be appreciated. Further, can anyone elaborate on the meaning of NI_DGRAM. The draft does not provide an explanation of what this flag means. Again thanks for any comments. Steve Hawley cs/390 development, IBM shawley2@us.ibm.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 Apr 19 12:50:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJoWK9007508 for ; Thu, 19 Apr 2001 12:50:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JJoW6X007507 for ipng-dist; Thu, 19 Apr 2001 12:50:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJoOK9007500 for ; Thu, 19 Apr 2001 12:50:24 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f3JJl8k11307 for ipng@sunroof.eng.sun.com; Thu, 19 Apr 2001 12:47:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3II46K9005085 for ; Wed, 18 Apr 2001 11:04:06 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15150 for ; Wed, 18 Apr 2001 11:04:06 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00246 for ; Wed, 18 Apr 2001 11:04:05 -0700 (PDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA00152; Wed, 18 Apr 2001 10:40:40 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f3IHedp15796; Wed, 18 Apr 2001 10:40:39 -0700 (PDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id KAA25780; Wed, 18 Apr 2001 10:40:34 -0700 (PDT) Date: Wed, 18 Apr 2001 10:40:34 -0700 (PDT) From: Edward Vielmetti To: Glenn Morrow cc: Michael Thomas , Thomas Eklund , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering In-Reply-To: <85AA7486A2C1D411BCA20000F8073E4301EEFCFF@crchy271.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk And you're going to mandate source filtering on the first hop across the entire internet, how? It's a great idea and a best common practice but not something that can be set by fiat. Ed On Wed, 18 Apr 2001, Glenn Morrow wrote: > Then again if source filtering is mandated on the first hop this might > eliminate the need to do filtering on other hops and this would eliminate > the need to do subnet translation or tunneling by either the MN or the MR. > > -----Original Message----- > From: Morrow, Glenn [RICH2:C330:EXCH] > Sent: Wednesday, April 18, 2001 11:56 AM > To: 'Michael Thomas' > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Oh, I see what you were concerned about. It seems to me that an MR will have > to tunnel or subnet translate unless it is on it's home subnet. > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, April 18, 2001 9:49 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Glenn Morrow writes: > > If the node behind the MR obtained its home address from the the mobile > > router's subnet, then the MN will use this as the source i.e. the MN's > home > > subnet is the MR's subnet. > > Right, but when the MR's upstream router does an > RPF check... it will drop the SN's packets. > > > Either way (tunneling or subnet translation), the topological correctness > is > > still maintained. > > Well, that's sort of the problem. The SN doesn't > know that it's putting topologically incorrect > source address in the IP header. > > Mike > -------------------------------------------------------------------- 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 Apr 19 13:50:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JKoMK9007772 for ; Thu, 19 Apr 2001 13:50:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JKoLRq007771 for ipng-dist; Thu, 19 Apr 2001 13:50:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JKoCK9007764 for ; Thu, 19 Apr 2001 13:50:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14250 for ; Thu, 19 Apr 2001 13:50:10 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04543 for ; Thu, 19 Apr 2001 13:50:10 -0700 (PDT) Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345) id B0C40366; Thu, 19 Apr 2001 13:51:43 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 7435122C; Thu, 19 Apr 2001 13:51:43 -0700 (PDT) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 1D3CB20A; Thu, 19 Apr 2001 15:50:09 -0500 (CDT) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 7C2B4245; Thu, 19 Apr 2001 15:50:08 -0500 (CDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id QAA0000016717; Thu, 19 Apr 2001 16:50:07 -0400 (EDT) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/12Mar01-1127AM) id QAA0000001923; Thu, 19 Apr 2001 16:50:06 -0400 (EDT) Message-ID: <3ADF4F7E.5D74A53D@zk3.dec.com> Date: Thu, 19 Apr 2001 16:50:06 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 X5.1 alpha) X-Accept-Language: ru, en MIME-Version: 1.0 To: Steve Hawley Cc: ipng@sunroof.eng.sun.com, Sue Huang , Roy Brabson Subject: Re: Basic Socket Interface Extensions for IPv6, References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Steve The way I understand it, NI_NUMERICSCOPE applies to sin6_scope_id the same way as NI_NUMERICHOST applies to sin6_addr. By specifying NI_NUMERICSCOPE flag, the conversion of sin6_scope_id to the 'zone[scope] name' will not take place and a numeric scope id will be returned with the name. ex: sin6_addr = fe80::1 sin6_scope_id = 1; return values: some-name%link = NI_NUMERICSCOPE is not set some-name%1 = NI_NUMERICSCOPE is set This flag should not have any effect if the sin6_scope_id is not set. NI_DGRAM flag is used to distinguish between datagram/UDP and stream/TCP services. Since different services may reside on the same port (one UDP and one TCP), it is necessary when doing a port-to-service mapping to know the transport protocol. So, by default getnaminfo() assumes that transport is TCP, but if you specify NI_DGRAM, it will use UDP to figure out the name for the service. I am not sure, but I think NI_WITHSCOPEID was never in the draft. It was proposed at least on the apifolks list, but not incorporated. I believe BSD and Linux implement this flag. -vlad Steve Hawley wrote: > > Some questions have arisen from examination of section 6, the getnameinfo > sub-section > of the draft. This sub-section describes flags controlling the actions to > be taken by the > function: > > - If the flag bit NI_NUMERICSCOPE is set, the numeric form of the > scope identifier is returned (for example, interface index) > instead of its name. This flag is ignored if the sa argument is > not an IPv6 address. > > - If the flag bit NI_DGRAM is set, this indicates that the service is > a datagram service (SOCK_DGRAM). The default behavior is to assume > that > the service is a stream service (SOCK_STREAM). > > NI_NUMERICSCOPE is confusing. The draft does not mention NI_WITHSCOPEID. > Earlier > implementations of getnameinfo contain reference to NI_WITHSCOPEID which > specifies > that scope is to be returned. If NI_WITHSCOPEID is specified in flags then > NI_NUMERICSCOPE > makes sense. The scope is to be returned in numeric form. In the draft's > current form, > NI_NUMERICSCOPE seems to be a vestige, something that should have been > removed but > wasn't. At the moment IBM does not plan to include NI_NUMERICSCOPE in our > implementation > of getnameinfo. Comments on this interpretation of the draft would be > appreciated. > > Further, can anyone elaborate on the meaning of NI_DGRAM. The draft does > not provide an > explanation of what this flag means. Again thanks for any comments. > > Steve Hawley > cs/390 development, IBM > shawley2@us.ibm.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 > -------------------------------------------------------------------- -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- 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 Apr 19 13:59:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JKxPK9007846 for ; Thu, 19 Apr 2001 13:59:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JKxPkh007845 for ipng-dist; Thu, 19 Apr 2001 13:59:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JKxFK9007838 for ; Thu, 19 Apr 2001 13:59:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15586 for ; Thu, 19 Apr 2001 13:59:14 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11286 for ; Thu, 19 Apr 2001 13:59:13 -0700 (PDT) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id 536004F40; Thu, 19 Apr 2001 16:59:13 -0400 (EDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 39D694DAD; Thu, 19 Apr 2001 16:59:13 -0400 (EDT) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id EEBA82EF; Thu, 19 Apr 2001 15:59:12 -0500 (CDT) Received: from anw.zk3.dec.com (and.zk3.dec.com [16.140.64.3]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 6ABC9227; Thu, 19 Apr 2001 15:59:12 -0500 (CDT) Received: by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id QAA0001680900; Thu, 19 Apr 2001 16:59:12 -0400 (EDT) Date: Thu, 19 Apr 2001 16:59:12 -0400 (EDT) From: Jack McCann Message-Id: <200104192059.QAA0001680900@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com, shawley2@us.ibm.com Subject: Re: Basic Socket Interface Extensions for IPv6, Cc: huangsl@us.ibm.com, rbrabson@us.ibm.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > At the moment IBM does not plan to include NI_NUMERICSCOPE in our > implementation of getnameinfo. Comments on this interpretation of > the draft would be appreciated. I think the idea is that getnameinfo() will attempt to translate the value in the sin6_scope_id field into a text string. See section 12 in draft-ietf-ipngwg-scoping-arch-02.txt. The NI_NUMERICSCOPE flag says don't bother trying to lookup the zone name (e.g. "fe80::abc%link1"), just display the numeric form of the sin6_scope_id (e.g. "fe80::abc%1"). [As an aside, NI_NUMERICSCOPE seems like a bit of overkill, I wonder why we didn't just extend NI_NUMERICHOST to cover the scope id...] >Further, can anyone elaborate on the meaning of NI_DGRAM. The draft does >not provide an >explanation of what this flag means. Again thanks for any comments. Did you see this text in the draft, just a few lines below the NI_DGRAM definition? 2. The NI_DGRAM flag is required for the new AF_INET/AF_INET6 port numbers (for example, 512-514) that represent different services for UDP and TCP. Without the flag, what value do you return for port 512: biff or exec? - Jack McCann Compaq Tru64 UNIX Networking -------------------------------------------------------------------- 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 Apr 19 16:11:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JNBQK9007965 for ; Thu, 19 Apr 2001 16:11:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JNBQF7007964 for ipng-dist; Thu, 19 Apr 2001 16:11:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JNBEK9007957 for ; Thu, 19 Apr 2001 16:11:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17948 for ; Thu, 19 Apr 2001 16:11:14 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA01217 for ; Thu, 19 Apr 2001 16:11:14 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Thu, 19 Apr 2001 16:11:55 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Apr 2001 16:11:05 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Thu, 19 Apr 2001 16:11:04 -0700 content-class: urn:content-classes:message Subject: RE: Source addresses, DDoS prevention and ingress filtering MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.4693.0 Date: Thu, 19 Apr 2001 16:11:04 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Source addresses, DDoS prevention and ingress filtering Thread-Index: AcDJCsI3IHKGN4/rR5KiU8x3klCT2QAGkwgA From: "Christian Huitema" To: "Edward Vielmetti" , "Glenn Morrow" Cc: "Michael Thomas" , "Thomas Eklund" , , X-OriginalArrivalTime: 19 Apr 2001 23:11:04.0946 (UTC) FILETIME=[0236CD20:01C0C926] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3JNBHK9007958 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am not sure it is such a good idea. >From a security stand point, it is very weak. You are trusting that some third party, at the other end of the network, will do the right thing. What happens if the "first hop" is compromised? And, by the way, what exactly is the first hop? The wireless LAN in my home? The Ethernet backbone in the same home? If you want any form of security, you really have to build it yourself, e.g. by using IPSEC. The only form of source address control that has a prayer of working is local, i.e. refuse to accept inbound packets in your domain that pretend to already come from an inside address. It is also very weak from a routing stand point. Internet routing is anything but symmetric. The exit path from a domain depends only on the destination address, not the source address; insisting on strict control of the source address basically breaks multi-homing. It also breaks several forms of mobility... > -----Original Message----- > From: Edward Vielmetti [mailto:evielmet@cisco.com] > Sent: Wednesday, April 18, 2001 10:41 AM > To: Glenn Morrow > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf- > itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > And you're going to mandate source filtering on the first hop across the > entire internet, how? It's a great idea and a best common practice but > not something that can be set by fiat. > > Ed > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > Then again if source filtering is mandated on the first hop this might > > eliminate the need to do filtering on other hops and this would > eliminate > > the need to do subnet translation or tunneling by either the MN or the > MR. > > > > -----Original Message----- > > From: Morrow, Glenn [RICH2:C330:EXCH] > > Sent: Wednesday, April 18, 2001 11:56 AM > > To: 'Michael Thomas' > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > 'ietf-itrace@research.att.com' > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > Oh, I see what you were concerned about. It seems to me that an MR will > have > > to tunnel or subnet translate unless it is on it's home subnet. > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Wednesday, April 18, 2001 9:49 AM > > To: Morrow, Glenn [RICH2:C330:EXCH] > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > 'ietf-itrace@research.att.com' > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > Glenn Morrow writes: > > > If the node behind the MR obtained its home address from the the > mobile > > > router's subnet, then the MN will use this as the source i.e. the > MN's > > home > > > subnet is the MR's subnet. > > > > Right, but when the MR's upstream router does an > > RPF check... it will drop the SN's packets. > > > > > Either way (tunneling or subnet translation), the topological > correctness > > is > > > still maintained. > > > > Well, that's sort of the problem. The SN doesn't > > know that it's putting topologically incorrect > > source address in the IP header. > > > > Mike > > > > > -------------------------------------------------------------------- > 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 Apr 19 16:23:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JNNMK9007986 for ; Thu, 19 Apr 2001 16:23:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JNNLBC007985 for ipng-dist; Thu, 19 Apr 2001 16:23:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JNNAK9007978 for ; Thu, 19 Apr 2001 16:23:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20392 for ; Thu, 19 Apr 2001 16:23:08 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06806 for ; Thu, 19 Apr 2001 18:10:18 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D93A94B10; Fri, 20 Apr 2001 08:22:45 +0900 (JST) To: "Steve Hawley" Cc: ipng@sunroof.eng.sun.com, "Sue Huang" , "Roy Brabson" In-reply-to: shawley2's message of Fri, 13 Apr 2001 09:54:00 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Basic Socket Interface Extensions for IPv6, From: itojun@iijlab.net Date: Fri, 20 Apr 2001 08:22:45 +0900 Message-ID: <28000.987722565@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >NI_NUMERICSCOPE is confusing. The draft does not mention >NI_WITHSCOPEID. Earlier implementations of getnameinfo contain >reference to NI_WITHSCOPEID which specifies that scope is to be >returned. If NI_WITHSCOPEID is specified in flags then NI_NUMERICSCOPE >makes sense. The scope is to be returned in numeric form. In the >draft's current form, NI_NUMERICSCOPE seems to be a vestige, >something that should have been removed but wasn't. At the moment >IBM does not plan to include NI_NUMERICSCOPE in our implementation >of getnameinfo. Comments on this interpretation of the draft would >be appreciated. NI_NUMERICSCOPE is introduced as there can be systems which use symbolic representation for scopeid. for example, notations like the following is acceptable: fe80::1%loopback fe80::1%ether0 in such case, you will want to selectively get numeric representation in scopeid portion, or textual representation, depending on NI_NUMERICSCOPE. draft-ietf-ipngwg-scoping-arch-02.txt has more details on this topic. >Further, can anyone elaborate on the meaning of NI_DGRAM. The draft does >not provide an explanation of what this flag means. Again thanks for any >comments. with NI_DGRAM: getservbyname(foo, "udp") without NI_DGRAM: getservbyname(foo, "tcp") itojun -------------------------------------------------------------------- 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 Apr 19 16:26:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JNQSK9008003 for ; Thu, 19 Apr 2001 16:26:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3JNQSPj008002 for ipng-dist; Thu, 19 Apr 2001 16:26:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JNQHK9007995 for ; Thu, 19 Apr 2001 16:26:17 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20728 for ; Thu, 19 Apr 2001 16:26:17 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05406 for ; Thu, 19 Apr 2001 16:26:13 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8DDCD4B0B; Fri, 20 Apr 2001 08:25:53 +0900 (JST) To: "Steve Hawley" , ipng@sunroof.eng.sun.com, "Sue Huang" , "Roy Brabson" In-reply-to: itojun's message of Fri, 20 Apr 2001 08:22:45 +0900. <28000.987722565@itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Basic Socket Interface Extensions for IPv6, From: itojun@iijlab.net Date: Fri, 20 Apr 2001 08:25:53 +0900 Message-ID: <28050.987722753@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Further, can anyone elaborate on the meaning of NI_DGRAM. The draft does >>not provide an explanation of what this flag means. Again thanks for any >>comments. > with NI_DGRAM: getservbyname(foo, "udp") > without NI_DGRAM: getservbyname(foo, "tcp") oops, getservbyport. itojun -------------------------------------------------------------------- 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 Apr 19 22:40:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K5eXK9008399 for ; Thu, 19 Apr 2001 22:40:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3K5eXgt008398 for ipng-dist; Thu, 19 Apr 2001 22:40:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K5eMK9008391 for ; Thu, 19 Apr 2001 22:40:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA02337 for ; Thu, 19 Apr 2001 22:40:21 -0700 (PDT) Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA05445 for ; Thu, 19 Apr 2001 22:40:20 -0700 (PDT) Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 19 Apr 2001 23:40:17 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Thu, 19 Apr 2001 23:40:04 -0600 From: "Alex R N" To: , Cc: "<" Subject: Address Prefix Ranges Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_97CC7FD1.91F03A53" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_97CC7FD1.91F03A53 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable =20 In section 2.4 Address Type Representation of IPv6 Addressing RFC=20 =20 I see a pattern in the address prefixes. Many of them have their equivalent= bitwise nots as other prefixes. Is there some reason behind assigning it = this way. I am curious to know how these prefix ranges were chosen and why = they are, the way they are currently assigned.=20 =20 Thanks Alex =20 --=_97CC7FD1.91F03A53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
 
In section 2.4 Address Type Representation  = of  IPv6=20 Addressing RFC
 
I see a pattern in the address prefixes. Many = of them=20 have their equivalent "bitwise nots" as other prefixes. Is there = some=20 reason behind assigning it this way. I am curious to know = how these=20 prefix ranges were chosen and why they are, the way they are currently = assigned.=20
 
Thanks
Alex
 
--=_97CC7FD1.91F03A53-- -------------------------------------------------------------------- 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 Apr 20 04:26:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KBQ8K9008800 for ; Fri, 20 Apr 2001 04:26:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KBQ7x6008799 for ipng-dist; Fri, 20 Apr 2001 04:26:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KBPtK9008792 for ; Fri, 20 Apr 2001 04:25:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28529 for ; Fri, 20 Apr 2001 04:25:53 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA02731 for ; Fri, 20 Apr 2001 04:25:51 -0700 (PDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id <2SZQL1SM>; Fri, 20 Apr 2001 13:25:55 +0200 Message-ID: <31A473DBB655D21180850008C71E251A0442CCD2@mail.kebne.se> From: Thomas Eklund To: "'Christian Huitema'" , "'Edward Vielmetti'" , "'Glenn Morrow'" Cc: "'Michael Thomas'" , "'ipng@sunroof.eng.sun.com'" , "'ietf-itrace@research.att.com'" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Fri, 20 Apr 2001 13:25:53 +0200 X-MS-TNEF-Correlator: <31A473DBB655D21180850008C71E251A0442CCD2@mail.kebne.se> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0C98C.A9265540" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0C98C.A9265540 Content-Type: text/plain Hi Christian, I hope you not referring to the AAAv6 ideas? Because that is just a way to do access control and possibly combine it with the packet filters that in most cases already sit in the router. It tells nothing about mandating it everywhere - this is of course up to the service provider/enterprise to use, but in the mobile systems there is a demand for AAA and this AAA draft could be a good start. And it does not break multihoming, mobility! Of course you can still use end-to end IPsec if you want that and at the same time enforce authentication and authorazation towards the AAA server and if the authentication suceeds, and then the router could update the packet filter with the "authenticated" host's IP address (which could be the CoA). -- thomas > -----Original Message----- > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > Sent: den 20 april 2001 01:11 > To: Edward Vielmetti; Glenn Morrow > Cc: Michael Thomas; Thomas Eklund; ipng@sunroof.eng.sun.com; > ietf-itrace@research.att.com > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > I am not sure it is such a good idea. > > From a security stand point, it is very weak. You are > trusting that some > third party, at the other end of the network, will do the right thing. > What happens if the "first hop" is compromised? And, by the way, what > exactly is the first hop? The wireless LAN in my home? The Ethernet > backbone in the same home? If you want any form of security, > you really > have to build it yourself, e.g. by using IPSEC. The only form > of source > address control that has a prayer of working is local, i.e. refuse to > accept inbound packets in your domain that pretend to already > come from > an inside address. > > It is also very weak from a routing stand point. Internet routing is > anything but symmetric. The exit path from a domain depends > only on the > destination address, not the source address; insisting on > strict control > of the source address basically breaks multi-homing. It also breaks > several forms of mobility... > > > > -----Original Message----- > > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > Sent: Wednesday, April 18, 2001 10:41 AM > > To: Glenn Morrow > > Cc: Michael Thomas; Thomas Eklund; > 'ipng@sunroof.eng.sun.com'; 'ietf- > > itrace@research.att.com' > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > And you're going to mandate source filtering on the first hop across > the > > entire internet, how? It's a great idea and a best common practice > but > > not something that can be set by fiat. > > > > Ed > > > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > > > Then again if source filtering is mandated on the first hop this > might > > > eliminate the need to do filtering on other hops and this would > > eliminate > > > the need to do subnet translation or tunneling by either the MN or > the > > MR. > > > > > > -----Original Message----- > > > From: Morrow, Glenn [RICH2:C330:EXCH] > > > Sent: Wednesday, April 18, 2001 11:56 AM > > > To: 'Michael Thomas' > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > 'ietf-itrace@research.att.com' > > > Subject: RE: Source addresses, DDoS prevention and > ingress filtering > > > > > > > > > Oh, I see what you were concerned about. It seems to me that an MR > will > > have > > > to tunnel or subnet translate unless it is on it's home subnet. > > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Wednesday, April 18, 2001 9:49 AM > > > To: Morrow, Glenn [RICH2:C330:EXCH] > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > 'ietf-itrace@research.att.com' > > > Subject: RE: Source addresses, DDoS prevention and > ingress filtering > > > > > > > > > Glenn Morrow writes: > > > > If the node behind the MR obtained its home address > from the the > > mobile > > > > router's subnet, then the MN will use this as the > source i.e. the > > MN's > > > home > > > > subnet is the MR's subnet. > > > > > > Right, but when the MR's upstream router does an > > > RPF check... it will drop the SN's packets. > > > > > > > Either way (tunneling or subnet translation), the topological > > correctness > > > is > > > > still maintained. > > > > > > Well, that's sort of the problem. The SN doesn't > > > know that it's putting topologically incorrect > > > source address in the IP header. > > > > > > Mike > > > > > > > > > -------------------------------------------------------------------- > > 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 > > -------------------------------------------------------------------- > ------_=_NextPart_000_01C0C98C.A9265540 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjgLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0QcEABQADQAZADUABQBQAQEggAMADgAAANEHBAAU AA0AGQA2AAUAUQEBCYABACEAAABENDAyQ0EyNzZCMzVENTExOTA5OTAwMDhDNzFFNDU5MwDqBgEE gAEAPAAAAFJFOiBTb3VyY2UgYWRkcmVzc2VzLCBERG9TIHByZXZlbnRpb24gYW5kIGluZ3Jlc3Mg ZmlsdGVyaW5nAJIVAQ2ABAACAAAAAgACAAEDkAYAVA8AACwAAAADAAlZAQAAAAIBcQABAAAAFgAA AAHAyYxok+r06grx5UxovJqcSrhIcncAAAMA3j+fTgAAAwAAgAggBgAAAAAAwAAAAAAAAEYAAAAA UoUAAH1uAQAeAAGACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAACwAMgAggBgAA AAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsA A4AIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAACwAEgAggBgAAAAAAwAAAAAAAAEYAAAAADoUA AAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABoAIIAYAAAAAAMAAAAAAAABG AAAAABGFAAAAAAAAAwAIgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAACAQkQAQAAAKIKAACe CgAAyhYAAExaRnWeKiQGAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/ CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAz CwkBZDM2FlALpiBISmkSIGgFEHN0BzBuBiwKogqASSBob3CIZSB5CGAgbm8FQA0YIGYEkAUQbmcg dCpvH6BoHnBBICB2NgQgaQEAYXM/IELZBZBhdRQQH9FhBUAEABggIGohMAVAYSB3tGF5H6JkH8AA 0GMHkD8EIAWgAjADYAMgAHBkIPRwbwQQaQJgIpAFoAbQ+wuAHnBpBUAD8B/gH9MKsORjaxQgIGYD EA6wFAD/IWUDoARgIiEhEBQQBCAHQPkYIGFkIpAAkCczH+IDYGJ1JrEuIEkFQA6wbPZsBCAe0Wgf cgGgKXEncE8kASGQH3IlUWV2BJB55ncf8BggIC0f0SHBIcGcb2YjcQhwIUF1cB+m+RQQcnYN4CXx A2Au4ASB/i8J8CaxLzAEACFRH8AhMXgsIGIrISj1BGAlAGzlLpF5HWBlbSbiLJIhwf8iUAEAK1Im cAWxICEj8yzzsTPyZHJhAYAtkmwkIOZiHnAiUGdvBHAooAGQ+wAgKcBBJBElUSLgB5Ee0npiKFFr J3A1gB1wHkBtzx9xMNAxoyVQeSEdxB3E/k8thx6SIRADoB1hKjAwkrssECQQLR+xPBEp0FAUEP5j IHAtgB6SInACMCFkJAL7IZEuc2EHgB+gB3E8ATOx/y8BISAf4QIwDeArkQIgPiTzQBEFsGF6QJQf sCJwCyD/MnMz4y6yEoEkAj0hH+JADf5zGtAJ4EJgMNA0NAnwKRm/NVUuECuBIVIl/SV4IkAJ7QmA Ih4xHWAnBCA8wCJA9mQ1ACNCKCxwDeAlsDVnox/iCFBBKS45mi0s0rUDcXM5mj4swE9STwUQHmcL gAdABdAjQWFnZWtPU07WRgNhOh0YHOB1MyVQM1EgWwDAJpFvOjpoUoRADsAT0R+AZS6/OKAFACRQ LXA2oCTRXU7WvwZgAjBRsAEAA6AcwWEwESMDIAHQMDEgVzA6MYsa808SVFNQIEVkQjI0IFYIkGwH gAJAaTvUIEcx4G4DoE0FsANgUndO1kNjUbBNS8FhvyogWCBOI1lwW5RYYGsKQK8kEFlwBSAfgEBF IG4DYOUtcC4J8GcuXVFVEhkwd07lCJAAMC0lUDUQIzBA50tBIKA/wGguIZBVA1VnmHViagWQVhFS RVGwPlMIYT/SSyQHkDDQRET+bwXwLzAsIUBRQMUfcUtD/yaEH3FO1mWeHiA+8B7DRSD/MsIho0Uh JbA19SCCTRVl+P9RciJBPOEIcTlgNlIkEwuAfnQw0Gf0LDIiYDfxKcBZ/x6hCsAecE7WI7AiER9z IYL/VNAHgG3HKqBYsQqxOWBFkX8+hCqBEoE8gi1xH+IlIHT6dwWwazDQA/A7oSLhKSPdT8BoPcIf cWlXVyGCE+DucB5gBjFDxSImgBQAdPF/HlBKUCHBJNEvMTigFBBk/yDQNtEw0SKRH/EicXKhIYH3 TtYOwADQdCShIcEf4nYXPyDQW5B4YXAAKiAjQkxBrk4nQyKQOIFlexRFMpL7cjFO1mImIQbgJSIp BD7j/XykST05AHAikDOxZ0Atcb9q1jDQTtYekihRKjB5Ttb/E+AsMB+iMPADEDbzHpEUAfxsZjDQ VGBd8HgCITAfcvE8wFNFQynAezICICSh/4DzTtaBQmIzTtZLFiOGIXP/E+AzAi8wIoASgS1xcmIr s/cEIBewIRBsbBFdwCnAHxH9ITNviKcjIQUxC4ArASQS/yYjLSEDoITCItFTASkCIZH/Y5EOsDRC IvEoRU7WJNF6Yf8DYYinA6ALgACQAQBLBmlf/ynhMvIqQB/AbJeSkyJBKWL/H3JraSnBL9JyMZc3 BACS6G55KpQw8jIQbVkhBRBj/4aUDsAlUQqwJaGW1Y/lAQD/dUFCYYeXhwJB4h/wTtYBAP9uckCV SyQw0B7SLnNiO1zh/wCBbnRAwU7WHWCbcTVCI6P/h5mhTwQgfkAN0YLyN8QEIP04My04hCnDleOn NKNXLCLvUAGA8i1TOQYuq3Bln07l/08/UE+tAlF0WH5S5ywgWPS8QGMEAAWgVRtVxlcJgC0lIHMr gHCBQVbDMThDMNBXEzEwOjRXQEH+TayoWDJZn6zzWt9b76wX9iddD14VJ1lwurBfIqyo+19vYHQn sqlhb2J/Y49kn++st6yoNtIekScsoTYQH3X/K1ShZ8NHnsV6eCMBVLGZt3+fCXlxQFEywpilMNAe QHf/INAp0UqxNfEoUSGhIJE+JP81sSeiA3AEYAOgitG/4C7x/33HKYCsqGdjbzEqlCFzOzL/NcEU EXgCJoAhkKuXrIpYcPvSj60RTwOgs6Ew0LSwtEK/VwMw0LaqImADYA6wOtPv/60RWBFGAlBwkBI9 IcbfIcH/xlVxocf+LPJO1jigc6HYSv8qIAdwn/JHpCUg24EitMdL/3EkHkEoETRGcmA1gcoJ3qb3 2ErfPUUgYpjivYEAgAtg+0CjBbF0XLAlIDlAmqIikO5lJZESgR/iTXwgBbDJX+mtAk1S0nk+2Eqt T65fB69IWfTWVltSSUNIIDI6QzMztVBFWJ/vULKZsy+0P1eQOjUgYPu1qlgUJ7hMvum377j/XNH/ ur+7yNhKvHS9f76Pv3/Ajz/BnyQgXpfC3+ov6o5PaP8w0B4gFBB4YSGCPVMskiOB/yMwfYE+USsC KcMEsTJixjH/IVXRYengTtZywqyog7Lju/8fwebT5oLlbS3xhwAjQmf0/0DBJVBKsXyi5VXqD+sf 7C//7T/2fFLnsQCx7/CP8Z9XE/o5tWA580/uL+8/9Y/2n//3r/i/+c/63/vv/P/+D/8fvwAvAT8O 3w8+1n1SkXPXmf8goBABf/Fx8zYwTLA1wJqB90XT6dGqsGJrcBDA24GEkP8N5UsWTtaW00ySycw5 A+Or/xABRoRKseVkd/BF9+hBcsP/jRPh8lxRTJKjVyREjJPpHP5OSrDYSnyiK43lZXoV6eDvM1cO vyvWy/BSc5J38Zrh/0ugNCY7QkdQo9HMoGdARoXP3/AlEEWhPK5QRomQTKB/jwCrcYSCcsR3MNyi TLBT7zgxjtY77yvYReekeIFLgPfmyAt/wjIpM+MKwWvAjCD/ELCMQayoTADW8COhFpE4W/+ZqDnm zpA04ZACLjRELzz4/xZgpvAz4pBwM1LmkKiQccV1dyFiKlBtm6RDYEATbvYn3ctBQWvQINcgkFMN s/5wmUBuhEkIeeIF8EpUPK3/pa1+1YZA4UCRgQYQTc/Ylfpca3BiWpTL8BxgjxBZP3/EPKytXn9f j2CfYWqsqElcRVRBoIZAmqFXi4VH25khyNBNsRGGAkyisWJ59WNySJJiUBFRr8Bm70FCgXOwdHA6 Ly9wDGBueScwjpK7xi8eYq7pVLtYoCHSaYPQZt9r1GZob+tpdVRQYmndRMrRpBGm4X8kkaghorGq IM6Qg9GM4HFmdZ/BB1RhauaQnRFv/x6vvBFdn3TPdd9272HfuiUCfXmQAAAeAHAAAQAAADgAAABT b3VyY2UgYWRkcmVzc2VzLCBERG9TIHByZXZlbnRpb24gYW5kIGluZ3Jlc3MgZmlsdGVyaW5nAAMA LgAAAAAACwACAAEAAAAeAEIQAQAAADkAAAA8MzFBNDczREJCNjU1RDIxMTgwODUwMDA4QzcxRTI1 MUEwNDczMTg3NkBtYWlsLmtlYm5lLnNlPgAAAAADAP0/5AQAAEAAOQBAVSapjMnAAQMA8T8JBAAA HgAxQAEAAAANAAAAWEVMLVRIT01BU0VLAAAAAAMAGkAAAAAAHgAwQAEAAAANAAAAWEVMLVRIT01B U0VLAAAAAAMAGUAAAAAAAwAmAAAAAAADADYAAAAAAAMAgBD/////CwDyEAEAAAACAUcAAQAAADkA AABjPVVTO2E9IDtwPUlUIEtvbnN1bHQgQUI7bD1TV0VNQUlMMS0wMTA0MjAxMTI1NTNaLTIzMzYz MwAAAAAeADhAAQAAAA0AAABYRUwtVEhPTUFTRUsAAAAAHgA5QAEAAAANAAAAWEVMLVRIT01BU0VL AAAAAEAABzBAgPiojMnAAUAACDDQOqipjMnAAR4APQABAAAABQAAAFJFOiAAAAAAHgAdDgEAAAA4 AAAAU291cmNlIGFkZHJlc3NlcywgRERvUyBwcmV2ZW50aW9uIGFuZCBpbmdyZXNzIGZpbHRlcmlu ZwAeADUQAQAAADkAAAA8MzFBNDczREJCNjU1RDIxMTgwODUwMDA4QzcxRTI1MUEwNDQyQ0NEMkBt YWlsLmtlYm5lLnNlPgAAAAALACkAAAAAAAsAIwAAAAAAAwAGEKtoskADAAcQDw4AAAMAEBAAAAAA AwAREAEAAAAeAAgQAQAAAGUAAABISUNIUklTVElBTixJSE9QRVlPVU5PVFJFRkVSUklOR1RPVEhF QUFBVjZJREVBUz9CRUNBVVNFVEhBVElTSlVTVEFXQVlUT0RPQUNDRVNTQ09OVFJPTEFORFBPU1NJ QkxZQ09NAAAAAAIBfwABAAAAOQAAADwzMUE0NzNEQkI2NTVEMjExODA4NTAwMDhDNzFFMjUxQTA0 NDJDQ0QyQG1haWwua2VibmUuc2U+AAAAADYh ------_=_NextPart_000_01C0C98C.A9265540-- -------------------------------------------------------------------- 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 Apr 20 08:33:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KFXVK9008974 for ; Fri, 20 Apr 2001 08:33:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KFXVNl008973 for ipng-dist; Fri, 20 Apr 2001 08:33:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KFXJK9008966 for ; Fri, 20 Apr 2001 08:33:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03922 for ; Fri, 20 Apr 2001 08:33:18 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00025 for ; Fri, 20 Apr 2001 08:33:16 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Fri, 20 Apr 2001 08:33:57 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 20 Apr 2001 08:33:06 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Fri, 20 Apr 2001 08:33:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4693.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Source addresses, DDoS prevention and ingress filtering Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Apr 2001 08:33:05 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Source addresses, DDoS prevention and ingress filtering Thread-Index: AcDJVYXaBT0NZrTyTUKckL+omrvkYAAVYb/Q From: "Christian Huitema" To: "Edward Vielmetti" Cc: , X-OriginalArrivalTime: 20 Apr 2001 15:33:06.0138 (UTC) FILETIME=[31FB33A0:01C0C9AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3KFXMK9008967 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ed, I have seen over the past years many knee-jerk reactions to attacks that essentially followed the model you are describing. An example is to cut ICMP because it is used in some attacks; the proposal to "verify unicast reverse-path" is another. The problem is that a number of these defenses amount to cutting your nose in order to cure the common cold. For example, cutting ICMP also suppresses efficient path MTU discovery; random reverse path verification kills multi-homing and makes mobility much harder. This is compelled by the evolutionary nature of the attacks: many of the ICMP attacks can be replicated over UDP, and thus you find sites cutting UDP as well -- and here goes voice over IP; in fact, I could also mount attacks by sending TCP packets outside the context of connections -- think of the consequences of various router protections for that... The "verify unicast" defense looks good on paper, but if you analyze it, it requires quasi universal deployment to make a difference. This is not simpler than deploying protection against forged addresses in the potential targets, mostly large web servers. In fact, the number of targets is probably lower than the number of "ingress routers" that would have to be upgraded. But then, there are three important differences. First, modern servers actually include protection against the forged address attacks that you mention -- proper handling of TCP context creation and verification of the plausibility of sequence numbers provide a first line of defense; SSL or IPSEC provide further protection for critical systems. Routers don't include such protections today; they would require modification to routing protocols to describe the authorized source address in parallel to the allowed destinations, possibly additional fast-path hardware, and certainly an increased management load. Second, the protection only works if it is implemented everywhere, and is in any case partial. As long as I cannot be sure that all Internet routers perform the filtering, I still have to implement adequate server side protections. If the router can be hacked, the protection is obviously ineffective. If the egress filtering operates on broad ranges, say a university network, the hacker can stop using random addresses, and instead pretend that all packets come from a single machine, e.g. the university's web site. Third, and most important, the network based defense places the defense burden at the wrong side of the problem. The local network is not really suffering from the attack; its administrators have only minor incentives to fix it. The one who is suffering is a remote server; there, you have a lot of incentives to fix the problem, fix the TCP stack, deploy IPSEC. All in all, I wish we would not cut the node of our face. As servers get hardened, the mode of attack will change. We don't want to maim the network today to protect against an attack that will not be in much use tomorrow. -- Christian Huitema > -----Original Message----- > From: Edward Vielmetti [mailto:evielmet@cisco.com] > Sent: Thursday, April 19, 2001 9:24 PM > To: Christian Huitema > Cc: Glenn Morrow; Michael Thomas; Thomas Eklund; ipng@sunroof.eng.sun.com; > ietf-itrace@research.att.com > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > Christian, > > The specific threat model is a compromised host being directed under > remote control to send a spray of packets with randomly forged source > addresses to a victim host far away. Intelligently throwing your local > equivalent of "ip verify unicast reverse-path" as a check in at logical > choke points on the network will *in actual practice* drop a whole lot of > traffic that should be dropped. This has important implications for > network operators. > > This is not a security or confidentiality problem, and thus IPSEC is > irrelevant. It is a network integrity problem. > > Ed > > On Thu, 19 Apr 2001, Christian Huitema wrote: > > > I am not sure it is such a good idea. > > > > >From a security stand point, it is very weak. You are trusting that > some > > third party, at the other end of the network, will do the right thing. > > What happens if the "first hop" is compromised? And, by the way, what > > exactly is the first hop? The wireless LAN in my home? The Ethernet > > backbone in the same home? If you want any form of security, you really > > have to build it yourself, e.g. by using IPSEC. The only form of source > > address control that has a prayer of working is local, i.e. refuse to > > accept inbound packets in your domain that pretend to already come from > > an inside address. > > > > It is also very weak from a routing stand point. Internet routing is > > anything but symmetric. The exit path from a domain depends only on the > > destination address, not the source address; insisting on strict control > > of the source address basically breaks multi-homing. It also breaks > > several forms of mobility... > > > > > > > -----Original Message----- > > > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > > Sent: Wednesday, April 18, 2001 10:41 AM > > > To: Glenn Morrow > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf- > > > itrace@research.att.com' > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > And you're going to mandate source filtering on the first hop across > > the > > > entire internet, how? It's a great idea and a best common practice > > but > > > not something that can be set by fiat. > > > > > > Ed > > > > > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > > > > > Then again if source filtering is mandated on the first hop this > > might > > > > eliminate the need to do filtering on other hops and this would > > > eliminate > > > > the need to do subnet translation or tunneling by either the MN or > > the > > > MR. > > > > > > > > -----Original Message----- > > > > From: Morrow, Glenn [RICH2:C330:EXCH] > > > > Sent: Wednesday, April 18, 2001 11:56 AM > > > > To: 'Michael Thomas' > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > 'ietf-itrace@research.att.com' > > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > > > > > > > Oh, I see what you were concerned about. It seems to me that an MR > > will > > > have > > > > to tunnel or subnet translate unless it is on it's home subnet. > > > > > > > > -----Original Message----- > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > Sent: Wednesday, April 18, 2001 9:49 AM > > > > To: Morrow, Glenn [RICH2:C330:EXCH] > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > 'ietf-itrace@research.att.com' > > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > > > > > > > Glenn Morrow writes: > > > > > If the node behind the MR obtained its home address from the the > > > mobile > > > > > router's subnet, then the MN will use this as the source i.e. the > > > MN's > > > > home > > > > > subnet is the MR's subnet. > > > > > > > > Right, but when the MR's upstream router does an > > > > RPF check... it will drop the SN's packets. > > > > > > > > > Either way (tunneling or subnet translation), the topological > > > correctness > > > > is > > > > > still maintained. > > > > > > > > Well, that's sort of the problem. The SN doesn't > > > > know that it's putting topologically incorrect > > > > source address in the IP header. > > > > > > > > Mike > > > > > > > > > > > > > -------------------------------------------------------------------- > > > 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 Fri Apr 20 08:41:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KFfZK9008991 for ; Fri, 20 Apr 2001 08:41:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KFfZ6h008990 for ipng-dist; Fri, 20 Apr 2001 08:41:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KFfOK9008983 for ; Fri, 20 Apr 2001 08:41:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05778 for ; Fri, 20 Apr 2001 08:41:24 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04920 for ; Fri, 20 Apr 2001 08:41:15 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Fri, 20 Apr 2001 08:42:01 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 20 Apr 2001 08:41:10 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Fri, 20 Apr 2001 08:41:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4693.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Source addresses, DDoS prevention and ingress filtering Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Apr 2001 08:41:09 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Source addresses, DDoS prevention and ingress filtering Thread-Index: AcDJjGiT6vTqCvHlTGi8mpxKuEhydwAItU0Q From: "Christian Huitema" To: "Thomas Eklund" Cc: , X-OriginalArrivalTime: 20 Apr 2001 15:41:10.0238 (UTC) FILETIME=[5286FFE0:01C0C9B0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3KFfQK9008984 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk No, I am not referring to AAA solutions. I am referring to server side defenses. These defenses are effective against most DoS attacks. They may not be effective against a complete saturation attack that floods the server's access link, but I doubt that source address verification would be the solution to that one; after all, activists can swamp a phone bank today without hiding their calling numbers. Replicated server at a number of diverse location is probably more effective than source address verification. By the way, most "server flooding" today is caused by "flash-crowd" phenomena with plain bona-fide clients. -- Christian Huitema > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com [mailto:owner- > ipng@sunroof.eng.sun.com] On Behalf Of Thomas Eklund > Sent: Friday, April 20, 2001 4:26 AM > To: Christian Huitema; 'Edward Vielmetti'; 'Glenn Morrow' > Cc: 'Michael Thomas'; 'ipng@sunroof.eng.sun.com'; 'ietf- > itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > Hi Christian, > I hope you not referring to the AAAv6 ideas? Because that is just a way > to do access control and possibly combine it with the packet filters that > in most cases already sit in the router. It tells nothing about mandating > it everywhere - this is of course up to the service provider/enterprise to > use, but in the mobile systems there is a demand for AAA and this AAA > draft could be a good start. And it does not break multihoming, mobility! > > Of course you can still use end-to end IPsec if you want that and at the > same time enforce authentication and authorazation towards the AAA server > and if the authentication suceeds, and then the router could update the > packet filter with the "authenticated" host's IP address (which could be > the CoA). > > -- thomas > > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > > Sent: den 20 april 2001 01:11 > > To: Edward Vielmetti; Glenn Morrow > > Cc: Michael Thomas; Thomas Eklund; ipng@sunroof.eng.sun.com; > > ietf-itrace@research.att.com > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > I am not sure it is such a good idea. > > > > From a security stand point, it is very weak. You are > > trusting that some > > third party, at the other end of the network, will do the right thing. > > What happens if the "first hop" is compromised? And, by the way, what > > exactly is the first hop? The wireless LAN in my home? The Ethernet > > backbone in the same home? If you want any form of security, > > you really > > have to build it yourself, e.g. by using IPSEC. The only form > > of source > > address control that has a prayer of working is local, i.e. refuse to > > accept inbound packets in your domain that pretend to already > > come from > > an inside address. > > > > It is also very weak from a routing stand point. Internet routing is > > anything but symmetric. The exit path from a domain depends > > only on the > > destination address, not the source address; insisting on > > strict control > > of the source address basically breaks multi-homing. It also breaks > > several forms of mobility... > > > > > > > -----Original Message----- > > > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > > Sent: Wednesday, April 18, 2001 10:41 AM > > > To: Glenn Morrow > > > Cc: Michael Thomas; Thomas Eklund; > > 'ipng@sunroof.eng.sun.com'; 'ietf- > > > itrace@research.att.com' > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > And you're going to mandate source filtering on the first hop across > > the > > > entire internet, how? It's a great idea and a best common practice > > but > > > not something that can be set by fiat. > > > > > > Ed > > > > > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > > > > > Then again if source filtering is mandated on the first hop this > > might > > > > eliminate the need to do filtering on other hops and this would > > > eliminate > > > > the need to do subnet translation or tunneling by either the MN or > > the > > > MR. > > > > > > > > -----Original Message----- > > > > From: Morrow, Glenn [RICH2:C330:EXCH] > > > > Sent: Wednesday, April 18, 2001 11:56 AM > > > > To: 'Michael Thomas' > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > 'ietf-itrace@research.att.com' > > > > Subject: RE: Source addresses, DDoS prevention and > > ingress filtering > > > > > > > > > > > > Oh, I see what you were concerned about. It seems to me that an MR > > will > > > have > > > > to tunnel or subnet translate unless it is on it's home subnet. > > > > > > > > -----Original Message----- > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > Sent: Wednesday, April 18, 2001 9:49 AM > > > > To: Morrow, Glenn [RICH2:C330:EXCH] > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > 'ietf-itrace@research.att.com' > > > > Subject: RE: Source addresses, DDoS prevention and > > ingress filtering > > > > > > > > > > > > Glenn Morrow writes: > > > > > If the node behind the MR obtained its home address > > from the the > > > mobile > > > > > router's subnet, then the MN will use this as the > > source i.e. the > > > MN's > > > > home > > > > > subnet is the MR's subnet. > > > > > > > > Right, but when the MR's upstream router does an > > > > RPF check... it will drop the SN's packets. > > > > > > > > > Either way (tunneling or subnet translation), the topological > > > correctness > > > > is > > > > > still maintained. > > > > > > > > Well, that's sort of the problem. The SN doesn't > > > > know that it's putting topologically incorrect > > > > source address in the IP header. > > > > > > > > Mike > > > > > > > > > > > > > -------------------------------------------------------------------- > > > 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 Fri Apr 20 08:53:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KFroK9009010 for ; Fri, 20 Apr 2001 08:53:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KFroqI009009 for ipng-dist; Fri, 20 Apr 2001 08:53:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KFreK9009002 for ; Fri, 20 Apr 2001 08:53:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28092 for ; Fri, 20 Apr 2001 08:53:39 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12582 for ; Fri, 20 Apr 2001 08:53:32 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA15016; Fri, 20 Apr 2001 08:53:40 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AEL02223; Fri, 20 Apr 2001 08:53:07 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA10357; Fri, 20 Apr 2001 08:53:07 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15072.23395.378227.152136@thomasm-u1.cisco.com> Date: Fri, 20 Apr 2001 08:53:07 -0700 (PDT) To: "Christian Huitema" Cc: "Edward Vielmetti" , , Subject: RE: Source addresses, DDoS prevention and ingress filtering In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, So what is your opinion of using the topologically "incorrect" IP address as the source when, say, a mobile node is away from home? It is still, after all, return routable via its home address, so it's not completely bogus on its face. In fact, it's no different than the multihomed case. However, right now as currently constituted in mobileipv6 two things will be extremely problematic: 1) The stationary host behind a mobile router I brought up before (no way to know what is "correct") 2) RSVP reservations upon change of CoA will need to create a completely new reservation since the filterspec must change. If the classifier used the home address, the reservation could converge locally which would be beneficial. There may well be other things which break because of the expectation of a fixed source address. Mike Christian Huitema writes: > Ed, > > I have seen over the past years many knee-jerk reactions to attacks that > essentially followed the model you are describing. An example is to cut > ICMP because it is used in some attacks; the proposal to "verify unicast > reverse-path" is another. The problem is that a number of these defenses > amount to cutting your nose in order to cure the common cold. For > example, cutting ICMP also suppresses efficient path MTU discovery; > random reverse path verification kills multi-homing and makes mobility > much harder. This is compelled by the evolutionary nature of the > attacks: many of the ICMP attacks can be replicated over UDP, and thus > you find sites cutting UDP as well -- and here goes voice over IP; in > fact, I could also mount attacks by sending TCP packets outside the > context of connections -- think of the consequences of various router > protections for that... > > The "verify unicast" defense looks good on paper, but if you analyze it, > it requires quasi universal deployment to make a difference. This is not > simpler than deploying protection against forged addresses in the > potential targets, mostly large web servers. In fact, the number of > targets is probably lower than the number of "ingress routers" that > would have to be upgraded. But then, there are three important > differences. > > First, modern servers actually include protection against the forged > address attacks that you mention -- proper handling of TCP context > creation and verification of the plausibility of sequence numbers > provide a first line of defense; SSL or IPSEC provide further protection > for critical systems. Routers don't include such protections today; they > would require modification to routing protocols to describe the > authorized source address in parallel to the allowed destinations, > possibly additional fast-path hardware, and certainly an increased > management load. > > Second, the protection only works if it is implemented everywhere, and > is in any case partial. As long as I cannot be sure that all Internet > routers perform the filtering, I still have to implement adequate server > side protections. If the router can be hacked, the protection is > obviously ineffective. If the egress filtering operates on broad ranges, > say a university network, the hacker can stop using random addresses, > and instead pretend that all packets come from a single machine, e.g. > the university's web site. > > Third, and most important, the network based defense places the defense > burden at the wrong side of the problem. The local network is not really > suffering from the attack; its administrators have only minor incentives > to fix it. The one who is suffering is a remote server; there, you have > a lot of incentives to fix the problem, fix the TCP stack, deploy IPSEC. > > All in all, I wish we would not cut the node of our face. As servers get > hardened, the mode of attack will change. We don't want to maim the > network today to protect against an attack that will not be in much use > tomorrow. > > -- Christian Huitema > > > > > -----Original Message----- > > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > Sent: Thursday, April 19, 2001 9:24 PM > > To: Christian Huitema > > Cc: Glenn Morrow; Michael Thomas; Thomas Eklund; > ipng@sunroof.eng.sun.com; > > ietf-itrace@research.att.com > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > Christian, > > > > The specific threat model is a compromised host being directed under > > remote control to send a spray of packets with randomly forged source > > addresses to a victim host far away. Intelligently throwing your > local > > equivalent of "ip verify unicast reverse-path" as a check in at > logical > > choke points on the network will *in actual practice* drop a whole lot > of > > traffic that should be dropped. This has important implications for > > network operators. > > > > This is not a security or confidentiality problem, and thus IPSEC is > > irrelevant. It is a network integrity problem. > > > > Ed > > > > On Thu, 19 Apr 2001, Christian Huitema wrote: > > > > > I am not sure it is such a good idea. > > > > > > >From a security stand point, it is very weak. You are trusting that > > some > > > third party, at the other end of the network, will do the right > thing. > > > What happens if the "first hop" is compromised? And, by the way, > what > > > exactly is the first hop? The wireless LAN in my home? The Ethernet > > > backbone in the same home? If you want any form of security, you > really > > > have to build it yourself, e.g. by using IPSEC. The only form of > source > > > address control that has a prayer of working is local, i.e. refuse > to > > > accept inbound packets in your domain that pretend to already come > from > > > an inside address. > > > > > > It is also very weak from a routing stand point. Internet routing is > > > anything but symmetric. The exit path from a domain depends only on > the > > > destination address, not the source address; insisting on strict > control > > > of the source address basically breaks multi-homing. It also breaks > > > several forms of mobility... > > > > > > > > > > -----Original Message----- > > > > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > > > Sent: Wednesday, April 18, 2001 10:41 AM > > > > To: Glenn Morrow > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf- > > > > itrace@research.att.com' > > > > Subject: RE: Source addresses, DDoS prevention and ingress > filtering > > > > > > > > And you're going to mandate source filtering on the first hop > across > > > the > > > > entire internet, how? It's a great idea and a best common > practice > > > but > > > > not something that can be set by fiat. > > > > > > > > Ed > > > > > > > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > > > > > > > Then again if source filtering is mandated on the first hop this > > > might > > > > > eliminate the need to do filtering on other hops and this would > > > > eliminate > > > > > the need to do subnet translation or tunneling by either the MN > or > > > the > > > > MR. > > > > > > > > > > -----Original Message----- > > > > > From: Morrow, Glenn [RICH2:C330:EXCH] > > > > > Sent: Wednesday, April 18, 2001 11:56 AM > > > > > To: 'Michael Thomas' > > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > > 'ietf-itrace@research.att.com' > > > > > Subject: RE: Source addresses, DDoS prevention and ingress > filtering > > > > > > > > > > > > > > > Oh, I see what you were concerned about. It seems to me that an > MR > > > will > > > > have > > > > > to tunnel or subnet translate unless it is on it's home subnet. > > > > > > > > > > -----Original Message----- > > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > > Sent: Wednesday, April 18, 2001 9:49 AM > > > > > To: Morrow, Glenn [RICH2:C330:EXCH] > > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > > 'ietf-itrace@research.att.com' > > > > > Subject: RE: Source addresses, DDoS prevention and ingress > filtering > > > > > > > > > > > > > > > Glenn Morrow writes: > > > > > > If the node behind the MR obtained its home address from the > the > > > > mobile > > > > > > router's subnet, then the MN will use this as the source i.e. > the > > > > MN's > > > > > home > > > > > > subnet is the MR's subnet. > > > > > > > > > > Right, but when the MR's upstream router does an > > > > > RPF check... it will drop the SN's packets. > > > > > > > > > > > Either way (tunneling or subnet translation), the topological > > > > correctness > > > > > is > > > > > > still maintained. > > > > > > > > > > Well, that's sort of the problem. The SN doesn't > > > > > know that it's putting topologically incorrect > > > > > source address in the IP header. > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 Apr 20 09:39:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KGdBK9009118 for ; Fri, 20 Apr 2001 09:39:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KGdANX009117 for ipng-dist; Fri, 20 Apr 2001 09:39:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KGd1K9009110 for ; Fri, 20 Apr 2001 09:39:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15121 for ; Fri, 20 Apr 2001 09:39:00 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10200 for ; Fri, 20 Apr 2001 09:38:48 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Fri, 20 Apr 2001 09:39:28 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 20 Apr 2001 09:38:37 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Fri, 20 Apr 2001 09:38:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4693.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Source addresses, DDoS prevention and ingress filtering Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Apr 2001 09:38:34 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Source addresses, DDoS prevention and ingress filtering Thread-Index: AcDJsx+ikJ806Gu1Q8mkPGC8HB9CvgAA81qQ From: "Christian Huitema" To: "Michael Thomas" Cc: , X-OriginalArrivalTime: 20 Apr 2001 16:38:37.0015 (UTC) FILETIME=[58F76E70:01C0C9B8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3KGd2K9009111 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe that the source address should be defined as "the address at which the source would like to receive replies to this message." In the case of a mobile host, there is value in getting replies either at your transient address or at the permanent address -- it basically depends on the circumstance, just like multi-homing, and things would be simpler if both were allowed. Mobile networks could also be thought off as multi-homed networks. The mobile router could in theory advertise two prefixes, one based on a "permanent" connection maintain via some tunneling mechanism and one based on the "transient" connection. Indeed, this can also be thought off as an exercise in fast network renumbering. Say a car is traveling at 180 km/h on a freeway, and a cell is 1 km wide -- it stays in any given cell for 20 seconds; you may have to renumber the network every 20 seconds. That seems a more interesting problem to solve than source address filtering, and I would in fact rather not make it even more complex by throwing in mandatory source address filtering... -- Christian Huitema > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 20, 2001 8:53 AM > To: Christian Huitema > Cc: Edward Vielmetti; ipng@sunroof.eng.sun.com; ietf- > itrace@research.att.com > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Christian, > > So what is your opinion of using the topologically > "incorrect" IP address as the source when, say, a > mobile node is away from home? It is still, after > all, return routable via its home address, so it's > not completely bogus on its face. In fact, it's no > different than the multihomed case. However, right > now as currently constituted in mobileipv6 two > things will be extremely problematic: > > 1) The stationary host behind a mobile router I brought > up before (no way to know what is "correct") > > 2) RSVP reservations upon change of CoA will need > to create a completely new reservation since > the filterspec must change. If the classifier > used the home address, the reservation could > converge locally which would be beneficial. > > There may well be other things which break because > of the expectation of a fixed source address. > > Mike > > Christian Huitema writes: > > Ed, > > > > I have seen over the past years many knee-jerk reactions to attacks > that > > essentially followed the model you are describing. An example is to cut > > ICMP because it is used in some attacks; the proposal to "verify > unicast > > reverse-path" is another. The problem is that a number of these > defenses > > amount to cutting your nose in order to cure the common cold. For > > example, cutting ICMP also suppresses efficient path MTU discovery; > > random reverse path verification kills multi-homing and makes mobility > > much harder. This is compelled by the evolutionary nature of the > > attacks: many of the ICMP attacks can be replicated over UDP, and thus > > you find sites cutting UDP as well -- and here goes voice over IP; in > > fact, I could also mount attacks by sending TCP packets outside the > > context of connections -- think of the consequences of various router > > protections for that... > > > > The "verify unicast" defense looks good on paper, but if you analyze > it, > > it requires quasi universal deployment to make a difference. This is > not > > simpler than deploying protection against forged addresses in the > > potential targets, mostly large web servers. In fact, the number of > > targets is probably lower than the number of "ingress routers" that > > would have to be upgraded. But then, there are three important > > differences. > > > > First, modern servers actually include protection against the forged > > address attacks that you mention -- proper handling of TCP context > > creation and verification of the plausibility of sequence numbers > > provide a first line of defense; SSL or IPSEC provide further > protection > > for critical systems. Routers don't include such protections today; > they > > would require modification to routing protocols to describe the > > authorized source address in parallel to the allowed destinations, > > possibly additional fast-path hardware, and certainly an increased > > management load. > > > > Second, the protection only works if it is implemented everywhere, and > > is in any case partial. As long as I cannot be sure that all Internet > > routers perform the filtering, I still have to implement adequate > server > > side protections. If the router can be hacked, the protection is > > obviously ineffective. If the egress filtering operates on broad > ranges, > > say a university network, the hacker can stop using random addresses, > > and instead pretend that all packets come from a single machine, e.g. > > the university's web site. > > > > Third, and most important, the network based defense places the defense > > burden at the wrong side of the problem. The local network is not > really > > suffering from the attack; its administrators have only minor > incentives > > to fix it. The one who is suffering is a remote server; there, you have > > a lot of incentives to fix the problem, fix the TCP stack, deploy > IPSEC. > > > > All in all, I wish we would not cut the node of our face. As servers > get > > hardened, the mode of attack will change. We don't want to maim the > > network today to protect against an attack that will not be in much use > > tomorrow. > > > > -- Christian Huitema > > > > > > > > > -----Original Message----- > > > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > > Sent: Thursday, April 19, 2001 9:24 PM > > > To: Christian Huitema > > > Cc: Glenn Morrow; Michael Thomas; Thomas Eklund; > > ipng@sunroof.eng.sun.com; > > > ietf-itrace@research.att.com > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > Christian, > > > > > > The specific threat model is a compromised host being directed under > > > remote control to send a spray of packets with randomly forged source > > > addresses to a victim host far away. Intelligently throwing your > > local > > > equivalent of "ip verify unicast reverse-path" as a check in at > > logical > > > choke points on the network will *in actual practice* drop a whole > lot > > of > > > traffic that should be dropped. This has important implications for > > > network operators. > > > > > > This is not a security or confidentiality problem, and thus IPSEC is > > > irrelevant. It is a network integrity problem. > > > > > > Ed > > > > > > On Thu, 19 Apr 2001, Christian Huitema wrote: > > > > > > > I am not sure it is such a good idea. > > > > > > > > >From a security stand point, it is very weak. You are trusting > that > > > some > > > > third party, at the other end of the network, will do the right > > thing. > > > > What happens if the "first hop" is compromised? And, by the way, > > what > > > > exactly is the first hop? The wireless LAN in my home? The Ethernet > > > > backbone in the same home? If you want any form of security, you > > really > > > > have to build it yourself, e.g. by using IPSEC. The only form of > > source > > > > address control that has a prayer of working is local, i.e. refuse > > to > > > > accept inbound packets in your domain that pretend to already come > > from > > > > an inside address. > > > > > > > > It is also very weak from a routing stand point. Internet routing > is > > > > anything but symmetric. The exit path from a domain depends only on > > the > > > > destination address, not the source address; insisting on strict > > control > > > > of the source address basically breaks multi-homing. It also breaks > > > > several forms of mobility... > > > > > > > > > > > > > -----Original Message----- > > > > > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > > > > Sent: Wednesday, April 18, 2001 10:41 AM > > > > > To: Glenn Morrow > > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > 'ietf- > > > > > itrace@research.att.com' > > > > > Subject: RE: Source addresses, DDoS prevention and ingress > > filtering > > > > > > > > > > And you're going to mandate source filtering on the first hop > > across > > > > the > > > > > entire internet, how? It's a great idea and a best common > > practice > > > > but > > > > > not something that can be set by fiat. > > > > > > > > > > Ed > > > > > > > > > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > > > > > > > > > Then again if source filtering is mandated on the first hop > this > > > > might > > > > > > eliminate the need to do filtering on other hops and this would > > > > > eliminate > > > > > > the need to do subnet translation or tunneling by either the MN > > or > > > > the > > > > > MR. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Morrow, Glenn [RICH2:C330:EXCH] > > > > > > Sent: Wednesday, April 18, 2001 11:56 AM > > > > > > To: 'Michael Thomas' > > > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > > > 'ietf-itrace@research.att.com' > > > > > > Subject: RE: Source addresses, DDoS prevention and ingress > > filtering > > > > > > > > > > > > > > > > > > Oh, I see what you were concerned about. It seems to me that an > > MR > > > > will > > > > > have > > > > > > to tunnel or subnet translate unless it is on it's home subnet. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > > > Sent: Wednesday, April 18, 2001 9:49 AM > > > > > > To: Morrow, Glenn [RICH2:C330:EXCH] > > > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > > > 'ietf-itrace@research.att.com' > > > > > > Subject: RE: Source addresses, DDoS prevention and ingress > > filtering > > > > > > > > > > > > > > > > > > Glenn Morrow writes: > > > > > > > If the node behind the MR obtained its home address from the > > the > > > > > mobile > > > > > > > router's subnet, then the MN will use this as the source > i.e. > > the > > > > > MN's > > > > > > home > > > > > > > subnet is the MR's subnet. > > > > > > > > > > > > Right, but when the MR's upstream router does an > > > > > > RPF check... it will drop the SN's packets. > > > > > > > > > > > > > Either way (tunneling or subnet translation), the > topological > > > > > correctness > > > > > > is > > > > > > > still maintained. > > > > > > > > > > > > Well, that's sort of the problem. The SN doesn't > > > > > > know that it's putting topologically incorrect > > > > > > source address in the IP header. > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > 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 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > 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 Fri Apr 20 09:48:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KGmMK9009140 for ; Fri, 20 Apr 2001 09:48:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KGmL7f009139 for ipng-dist; Fri, 20 Apr 2001 09:48:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KGmAK9009132 for ; Fri, 20 Apr 2001 09:48:12 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18361 for ; Fri, 20 Apr 2001 09:48:09 -0700 (PDT) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10540 for ; Fri, 20 Apr 2001 09:48:09 -0700 (PDT) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.11.0/jtpda-5.3.2) with ESMTP id f3KGlug31636 ; Fri, 20 Apr 2001 18:47:56 +0200 Received: from lip6.fr (otos.lip6.fr [132.227.61.47]) by tibre.lip6.fr (8.11.3/8.11.3) with ESMTP id f3KGlkD22603; Fri, 20 Apr 2001 18:47:46 +0200 (CEST) Message-ID: <3AE0683B.75C90CB6@lip6.fr> Date: Fri, 20 Apr 2001 18:47:55 +0200 From: Rolland Vida Organization: Laboratoire Lip6 X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: idmr@cs.ucl.ac.uk, ipng@sunroof.eng.sun.com CC: iana@iana.org, icann@icann.org, Luis Costa Subject: address allocation for MLDv2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have a question about the procedure to follow in order to request the allocation of a special multicast address and a protocol message type number. We've already contacted IANA (at iana@iana.org) and ICANN (at icann@icann.org), but we haven't received any answer yet. We are working on the specification of the MLDv2 protocol draft, the IPv6 version of IGMPv3. (http://www.ietf.org/internet-drafts/draft-vida-mld-v2-00.txt) In the specification of the protocol we need the followings: 1. the allocation of a special IPv6 multicast address called "all mldv2-capable routers". For IGMPv3 IANA already allocated the IPv4 multicast address 224.0.0.22 for "all igmpv3-capable routers". As normally there is a correspondence between specially assigned IPv4 and IPv6 addresses, we think FF02::16 is the suitable address for all-mldv2-routers. But the only document that we found listing already assigned IPv6 multicast addresses is RFC2375, dated July 1998. So we are not sure that this proposed address is not already allocated. For IPv4 there's a much more recent document available at (http://www.isi.edu/in-notes/iana/assignments/multicast-addresses - March 2001) 2. the allocation of an ICMPv6 message type for MLDv2 Report messages. In the first version of the draft we mistakenly considered the value of 136 for this message type, but this value is already allocated to Neighbor Advertisment messages. As far as we know, the first available message type value is 143 (141 and 142 are experimental assignments for mtrace messages). But before releasing a new, corrected version of the draft, we would like to officially request the assignment of this value (143) for MLDv2 reports. We would appreciate if you could give us a hint on how to proceed in order to do these allocations. Maybe you've already faced a similar situation. Or can we just release the new version of the draft, with the considered values, and hope that IANA will confirm our assignments? Thanks in advance, Best regards, Rolland Vida Luis Costa -- ______________________________________________________ Make everything as simple as possible, but not simpler - Albert Einstein Rolland VIDA - Ph.D. student Universite Pierre et Marie Curie Laboratoire LIP6-CNRS, 8, rue du Capitaine Scott Tel: +33 (0) 1 44 27 71 26 Fax: +33 (0) 1 44 27 74 95 E-mail: Rolland.Vida@lip6.fr Web: http://www-rp.lip6.fr/~vida ______________________________________________________ -------------------------------------------------------------------- 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 Apr 20 10:23:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KHNwK9009196 for ; Fri, 20 Apr 2001 10:23:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KHNvm1009195 for ipng-dist; Fri, 20 Apr 2001 10:23:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KHNlK9009188 for ; Fri, 20 Apr 2001 10:23:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25070 for ; Fri, 20 Apr 2001 10:23:46 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00667 for ; Fri, 20 Apr 2001 12:17:01 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA17271; Fri, 20 Apr 2001 10:24:05 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AEL04310; Fri, 20 Apr 2001 10:23:38 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA10378; Fri, 20 Apr 2001 10:23:38 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15072.28825.881948.125942@thomasm-u1.cisco.com> Date: Fri, 20 Apr 2001 10:23:37 -0700 (PDT) To: "Christian Huitema" Cc: "Michael Thomas" , , Subject: A reply-via dst option? (was: Source addresses, DDoS prevention and ingress filtering) In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema writes: > I believe that the source address should be defined as "the address at > which the source would like to receive replies to this message." In the > case of a mobile host, there is value in getting replies either at your > transient address or at the permanent address -- it basically depends on > the circumstance, just like multi-homing, and things would be simpler if > both were allowed. Christian, This is an excellent piece of insight. As it stands right now in MIPv6, the mobile node sending toward the correspondent node is supposed to put in a Home Address destination option. This at its base causes a number of problems, such as the ones I've already pointed out, but also there are yet more problems when you start to consider mobile nodes behind mobile routers. Consider a CN which got multiple binding updates from both the MN and the MR: how would it know how to assemble the routing headers in the proper order? Perhaps we should take a lesson from SMTP and/or SIP here. When I send a mail message, my From: address is essentially constant. If I want the return mail routed differently, I insert a Reply-to: header. SIP extends this a bit more and allows Proxies to add Record-Route to force return signaling through intermediate nodes. There is a very analogous situation with basic IP routing, it seems, where routers are similar to proxies. This should hardly be surprising. What I'm thinking is that maybe we should consider flipping the sense of current MIPv6 thinking: instead of placing the CoA in the IP header, you instead place your home address in the IP header because it is, in fact, the way to reach you. If you're away from home, however, or for any other reason such as the case for multihoming, you would place a Reply-via destination option into the packet. The Reply-via is, in fact, the ordered set of IP addresses that should be visited before the home address; in other words, it's nothing more than the explicit routing header stack. If intermediate nodes, such as mobile routers, could push their addresses onto the routing header stack, then we will have solved the other nettlesome problem and have done it in such a way that we can keep unwitting stationary nodes behind a mobile router unaware of their mobility. I believe that the security considerations are the same, however: if we use return routability as our basic test for correspondent nodes, this has the same considerations, I believe. Mike -------------------------------------------------------------------- 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 Apr 20 12:53:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KJrVK9009481 for ; Fri, 20 Apr 2001 12:53:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KJrUxp009480 for ipng-dist; Fri, 20 Apr 2001 12:53:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KJr0K9009473 for ; Fri, 20 Apr 2001 12:53:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27330 for ; Fri, 20 Apr 2001 12:52:58 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24988 for ; Fri, 20 Apr 2001 12:52:54 -0700 (PDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA13680 for ; Fri, 20 Apr 2001 14:53:06 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Fri, 20 Apr 2001 14:47:09 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Apr 2001 14:52:28 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301F4B038@crchy271.us.nortel.com> From: "Glenn Morrow" To: Michael Thomas , Christian Huitema Cc: Edward Vielmetti , ipng , ietf-itrace Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Fri, 20 Apr 2001 14:52:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C9D3.69F2DBE0" X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C9D3.69F2DBE0 Content-Type: text/plain; charset="iso-8859-1" I agree we probably shouldn't have a double standard - one for multihoming and one for node mobility. On Christian's point about trusting some foreign node to do something, I think we already trust these foreign routers to route packets to the right point which is along the same lines of trust, IMO. I believe there is an installed base of older IPv4-only routers out there that people still want to use and leverage their investment as long as they can. This is a reason to not do it in IPv4 but I don't really see why not for IPv6. I do believe that server pods are definitely needed too. It is no skin off my back if we don't mandate it on the first hop in IPv6. I just thought it might make things easier for tracing down the slaves. It seems to me that if you are going to do it - really do it and take advantage of it. If topological correctness of any sort, were mandated on the first hop, it might negate the need to do it in other parts of the network. I don't think we are going to get people to mandate that the checks are not done on interior hops, though. Please understand that I'm not trying to sell some solution here or elsewhere that depends on this functionality. I think we should consider it to help out the DDoS problem in IPv6 if we can. So I floated the idea. That is all. It seems to me that there are many types of filter implementations that all enforce some sort of topological correctness. If we ever did put it in as a BCP or the spec itself, topological correctness at the subnet level is about all we could say. I'm not sure if it should say subnet and interface level. Was this your concern in reference to the server farms, Christian? Thanks to everyone for the insightful discussion, Glenn -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Friday, April 20, 2001 10:53 AM To: Christian Huitema Cc: Edward Vielmetti; ipng; ietf-itrace Subject: RE: Source addresses, DDoS prevention and ingress filtering Christian, So what is your opinion of using the topologically "incorrect" IP address as the source when, say, a mobile node is away from home? It is still, after all, return routable via its home address, so it's not completely bogus on its face. In fact, it's no different than the multihomed case. However, right now as currently constituted in mobileipv6 two things will be extremely problematic: 1) The stationary host behind a mobile router I brought up before (no way to know what is "correct") 2) RSVP reservations upon change of CoA will need to create a completely new reservation since the filterspec must change. If the classifier used the home address, the reservation could converge locally which would be beneficial. There may well be other things which break because of the expectation of a fixed source address. Mike Christian Huitema writes: > Ed, > > I have seen over the past years many knee-jerk reactions to attacks that > essentially followed the model you are describing. An example is to cut > ICMP because it is used in some attacks; the proposal to "verify unicast > reverse-path" is another. The problem is that a number of these defenses > amount to cutting your nose in order to cure the common cold. For > example, cutting ICMP also suppresses efficient path MTU discovery; > random reverse path verification kills multi-homing and makes mobility > much harder. This is compelled by the evolutionary nature of the > attacks: many of the ICMP attacks can be replicated over UDP, and thus > you find sites cutting UDP as well -- and here goes voice over IP; in > fact, I could also mount attacks by sending TCP packets outside the > context of connections -- think of the consequences of various router > protections for that... > > The "verify unicast" defense looks good on paper, but if you analyze it, > it requires quasi universal deployment to make a difference. This is not > simpler than deploying protection against forged addresses in the > potential targets, mostly large web servers. In fact, the number of > targets is probably lower than the number of "ingress routers" that > would have to be upgraded. But then, there are three important > differences. > > First, modern servers actually include protection against the forged > address attacks that you mention -- proper handling of TCP context > creation and verification of the plausibility of sequence numbers > provide a first line of defense; SSL or IPSEC provide further protection > for critical systems. Routers don't include such protections today; they > would require modification to routing protocols to describe the > authorized source address in parallel to the allowed destinations, > possibly additional fast-path hardware, and certainly an increased > management load. > > Second, the protection only works if it is implemented everywhere, and > is in any case partial. As long as I cannot be sure that all Internet > routers perform the filtering, I still have to implement adequate server > side protections. If the router can be hacked, the protection is > obviously ineffective. If the egress filtering operates on broad ranges, > say a university network, the hacker can stop using random addresses, > and instead pretend that all packets come from a single machine, e.g. > the university's web site. > > Third, and most important, the network based defense places the defense > burden at the wrong side of the problem. The local network is not really > suffering from the attack; its administrators have only minor incentives > to fix it. The one who is suffering is a remote server; there, you have > a lot of incentives to fix the problem, fix the TCP stack, deploy IPSEC. > > All in all, I wish we would not cut the node of our face. As servers get > hardened, the mode of attack will change. We don't want to maim the > network today to protect against an attack that will not be in much use > tomorrow. > > -- Christian Huitema > > > > > -----Original Message----- > > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > Sent: Thursday, April 19, 2001 9:24 PM > > To: Christian Huitema > > Cc: Glenn Morrow; Michael Thomas; Thomas Eklund; > ipng@sunroof.eng.sun.com; > > ietf-itrace@research.att.com > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > Christian, > > > > The specific threat model is a compromised host being directed under > > remote control to send a spray of packets with randomly forged source > > addresses to a victim host far away. Intelligently throwing your > local > > equivalent of "ip verify unicast reverse-path" as a check in at > logical > > choke points on the network will *in actual practice* drop a whole lot > of > > traffic that should be dropped. This has important implications for > > network operators. > > > > This is not a security or confidentiality problem, and thus IPSEC is > > irrelevant. It is a network integrity problem. > > > > Ed > > > > On Thu, 19 Apr 2001, Christian Huitema wrote: > > > > > I am not sure it is such a good idea. > > > > > > >From a security stand point, it is very weak. You are trusting that > > some > > > third party, at the other end of the network, will do the right > thing. > > > What happens if the "first hop" is compromised? And, by the way, > what > > > exactly is the first hop? The wireless LAN in my home? The Ethernet > > > backbone in the same home? If you want any form of security, you > really > > > have to build it yourself, e.g. by using IPSEC. The only form of > source > > > address control that has a prayer of working is local, i.e. refuse > to > > > accept inbound packets in your domain that pretend to already come > from > > > an inside address. > > > > > > It is also very weak from a routing stand point. Internet routing is > > > anything but symmetric. The exit path from a domain depends only on > the > > > destination address, not the source address; insisting on strict > control > > > of the source address basically breaks multi-homing. It also breaks > > > several forms of mobility... > > > > > > > > > > -----Original Message----- > > > > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > > > Sent: Wednesday, April 18, 2001 10:41 AM > > > > To: Glenn Morrow > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf- > > > > itrace@research.att.com' > > > > Subject: RE: Source addresses, DDoS prevention and ingress > filtering > > > > > > > > And you're going to mandate source filtering on the first hop > across > > > the > > > > entire internet, how? It's a great idea and a best common > practice > > > but > > > > not something that can be set by fiat. > > > > > > > > Ed > > > > > > > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > > > > > > > Then again if source filtering is mandated on the first hop this > > > might > > > > > eliminate the need to do filtering on other hops and this would > > > > eliminate > > > > > the need to do subnet translation or tunneling by either the MN > or > > > the > > > > MR. > > > > > > > > > > -----Original Message----- > > > > > From: Morrow, Glenn [RICH2:C330:EXCH] > > > > > Sent: Wednesday, April 18, 2001 11:56 AM > > > > > To: 'Michael Thomas' > > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > > 'ietf-itrace@research.att.com' > > > > > Subject: RE: Source addresses, DDoS prevention and ingress > filtering > > > > > > > > > > > > > > > Oh, I see what you were concerned about. It seems to me that an > MR > > > will > > > > have > > > > > to tunnel or subnet translate unless it is on it's home subnet. > > > > > > > > > > -----Original Message----- > > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > > Sent: Wednesday, April 18, 2001 9:49 AM > > > > > To: Morrow, Glenn [RICH2:C330:EXCH] > > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > > 'ietf-itrace@research.att.com' > > > > > Subject: RE: Source addresses, DDoS prevention and ingress > filtering > > > > > > > > > > > > > > > Glenn Morrow writes: > > > > > > If the node behind the MR obtained its home address from the > the > > > > mobile > > > > > > router's subnet, then the MN will use this as the source i.e. > the > > > > MN's > > > > > home > > > > > > subnet is the MR's subnet. > > > > > > > > > > Right, but when the MR's upstream router does an > > > > > RPF check... it will drop the SN's packets. > > > > > > > > > > > Either way (tunneling or subnet translation), the topological > > > > correctness > > > > > is > > > > > > still maintained. > > > > > > > > > > Well, that's sort of the problem. The SN doesn't > > > > > know that it's putting topologically incorrect > > > > > source address in the IP header. > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > 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 > -------------------------------------------------------------------- ------_=_NextPart_001_01C0C9D3.69F2DBE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Source addresses, DDoS prevention and ingress = filtering

I agree we probably shouldn't have a double standard = - one for multihoming and one for node mobility.

On Christian's point about trusting some foreign node = to do something, I think we already trust these foreign routers to = route packets to the right point which is along the same lines of = trust, IMO. I believe there is an installed base of older IPv4-only = routers out there that people still want to use and leverage their = investment as long as they can. This is a reason to not do it in IPv4 = but I don't really see why not for IPv6. I do believe that server pods = are definitely needed too.

It is no skin off my back if we don't mandate it on = the first hop in IPv6. I just thought it might make things easier for = tracing down the slaves. It seems to me that if you are going to do it = - really do it and take advantage of it.

If topological correctness of any sort, were mandated = on the first hop, it might negate the need to do it in other parts of = the network. I don't think we are going to get people to mandate that = the checks are not done on interior hops, though.

Please understand that I'm not trying to sell some = solution here or elsewhere that depends on this functionality. I think = we should consider it to help out the DDoS problem in IPv6 if we can. = So I floated the idea. That is all.

It seems to me that there are many types of filter = implementations that all enforce some sort of topological correctness. = If we ever did put it in as a BCP or the spec itself, topological = correctness at the subnet level is about all we could say. I'm not sure = if it should say subnet and interface level. Was this your concern in = reference to the server farms, Christian?

Thanks to everyone for the insightful = discussion,

Glenn



-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Friday, April 20, 2001 10:53 AM
To: Christian Huitema
Cc: Edward Vielmetti; ipng; ietf-itrace
Subject: RE: Source addresses, DDoS prevention and = ingress filtering



Christian,

So what is your opinion of using the = topologically
"incorrect" IP address as the source when, = say, a
mobile node is away from home? It is still, = after
all, return routable via its home address, so = it's
not completely bogus on its face. In fact, it's = no
different than the multihomed case. However, = right
now as currently constituted in mobileipv6 = two
things will be extremely problematic:

1) The stationary host behind a mobile router I = brought
   up before (no way to know what is = "correct")

2) RSVP reservations upon change of CoA will = need
   to create a completely new reservation = since
   the filterspec must change. If the = classifier
   used the home address, the reservation = could
   converge locally which would be = beneficial.

There may well be other things which break = because
of the expectation of a fixed source address.

        =             Mike

Christian Huitema writes:
 > Ed,
 >
 > I have seen over the past years many = knee-jerk reactions to attacks that
 > essentially followed the model you are = describing. An example is to cut
 > ICMP because it is used in some attacks; = the proposal to "verify unicast
 > reverse-path" is another. The = problem is that a number of these defenses
 > amount to cutting your nose in order to = cure the common cold. For
 > example, cutting ICMP also suppresses = efficient path MTU discovery;
 > random reverse path verification kills = multi-homing and makes mobility
 > much harder. This is compelled by the = evolutionary nature of the
 > attacks: many of the ICMP attacks can be = replicated over UDP, and thus
 > you find sites cutting UDP as well -- and = here goes voice over IP; in
 > fact, I could also mount attacks by = sending TCP packets outside the
 > context of connections -- think of the = consequences of various router
 > protections for that...
 >
 > The "verify unicast" defense = looks good on paper, but if you analyze it,
 > it requires quasi universal deployment to = make a difference. This is not
 > simpler than deploying protection against = forged addresses in the
 > potential targets, mostly large web = servers. In fact, the number of
 > targets is probably lower than the number = of "ingress routers" that
 > would have to be upgraded. But then, = there are three important
 > differences.
 >
 > First, modern servers actually include = protection against the forged
 > address attacks that you mention -- = proper handling of TCP context
 > creation and verification of the = plausibility of sequence numbers
 > provide a first line of defense; SSL or = IPSEC provide further protection
 > for critical systems. Routers don't = include such protections today; they
 > would require modification to routing = protocols to describe the
 > authorized source address in parallel to = the allowed destinations,
 > possibly additional fast-path hardware, = and certainly an increased
 > management load.
 >
 > Second, the protection only works if it = is implemented everywhere, and
 > is in any case partial. As long as I = cannot be sure that all Internet
 > routers perform the filtering, I still = have to implement adequate server
 > side protections. If the router can be = hacked, the protection is
 > obviously ineffective. If the egress = filtering operates on broad ranges,
 > say a university network, the hacker can = stop using random addresses,
 > and instead pretend that all packets come = from a single machine, e.g.
 > the university's web site.
 >
 > Third, and most important, the network = based defense places the defense
 > burden at the wrong side of the problem. = The local network is not really
 > suffering from the attack; its = administrators have only minor incentives
 > to fix it. The one who is suffering is a = remote server; there, you have
 > a lot of incentives to fix the problem, = fix the TCP stack, deploy IPSEC.
 >
 > All in all, I wish we would not cut the = node of our face. As servers get
 > hardened, the mode of attack will change. = We don't want to maim the
 > network today to protect against an = attack that will not be in much use
 > tomorrow.
 >
 > -- Christian Huitema
 >
 >
 >
 > > -----Original Message-----
 > > From: Edward Vielmetti [mailto:evielmet@cisco.com]=
 > > Sent: Thursday, April 19, 2001 9:24 = PM
 > > To: Christian Huitema
 > > Cc: Glenn Morrow; Michael Thomas; = Thomas Eklund;
 > ipng@sunroof.eng.sun.com;
 > > ietf-itrace@research.att.com
 > > Subject: RE: Source addresses, DDoS = prevention and ingress filtering
 > >
 > > Christian,
 > >
 > > The specific threat model is a = compromised host being directed under
 > > remote control to send a spray of = packets with randomly forged source
 > > addresses to a victim host far = away.  Intelligently throwing your
 > local
 > > equivalent of "ip verify = unicast reverse-path" as a check in at
 > logical
 > > choke points on the network will *in = actual practice* drop a whole lot
 > of
 > > traffic that should be = dropped.  This has important implications for
 > > network operators.
 > >
 > > This is not a security or = confidentiality problem, and thus IPSEC is
 > > irrelevant.  It is a network = integrity problem.
 > >
 > > Ed
 > >
 > > On Thu, 19 Apr 2001, Christian = Huitema wrote:
 > >
 > > > I am not sure it is such a good = idea.
 > > >
 > > > >From a security stand = point, it is very weak. You are trusting that
 > > some
 > > > third party, at the other end = of the network, will do the right
 > thing.
 > > > What happens if the "first = hop" is compromised? And, by the way,
 > what
 > > > exactly is the first hop? The = wireless LAN in my home? The Ethernet
 > > > backbone in the same home? If = you want any form of security, you
 > really
 > > > have to build it yourself, e.g. = by using IPSEC. The only form of
 > source
 > > > address control that has a = prayer of working is local, i.e. refuse
 > to
 > > > accept inbound packets in your = domain that pretend to already come
 > from
 > > > an inside address.
 > > >
 > > > It is also very weak from a = routing stand point. Internet routing is
 > > > anything but symmetric. The = exit path from a domain depends only on
 > the
 > > > destination address, not the = source address; insisting on strict
 > control
 > > > of the source address basically = breaks multi-homing. It also breaks
 > > > several forms of = mobility...
 > > >
 > > >
 > > > > -----Original = Message-----
 > > > > From: Edward Vielmetti [mailto:evielmet@cisco.com]=
 > > > > Sent: Wednesday, April 18, = 2001 10:41 AM
 > > > > To: Glenn Morrow
 > > > > Cc: Michael Thomas; Thomas = Eklund; 'ipng@sunroof.eng.sun.com';
 > 'ietf-
 > > > > = itrace@research.att.com'
 > > > > Subject: RE: Source = addresses, DDoS prevention and ingress
 > filtering
 > > > >
 > > > > And you're going to = mandate source filtering on the first hop
 > across
 > > > the
 > > > > entire internet, = how?  It's a great idea and a best common
 > practice
 > > > but
 > > > > not something that can be = set by fiat.
 > > > >
 > > > > Ed
 > > > >
 > > > > On Wed, 18 Apr 2001, Glenn = Morrow wrote:
 > > > >
 > > > > > Then again if source = filtering is mandated on the first hop this
 > > > might
 > > > > > eliminate the need to = do filtering on other hops and this would
 > > > > eliminate
 > > > > > the need to do subnet = translation or tunneling by either the MN
 > or
 > > > the
 > > > > MR.
 > > > > >
 > > > > > -----Original = Message-----
 > > > > > From: Morrow, Glenn = [RICH2:C330:EXCH]
 > > > > > Sent: Wednesday, = April 18, 2001 11:56 AM
 > > > > > To: 'Michael = Thomas'
 > > > > > Cc: Michael Thomas; = Thomas Eklund; 'ipng@sunroof.eng.sun.com';
 > > > > > = 'ietf-itrace@research.att.com'
 > > > > > Subject: RE: Source = addresses, DDoS prevention and ingress
 > filtering
 > > > > >
 > > > > >
 > > > > > Oh, I see what you = were concerned about. It seems to me that an
 > MR
 > > > will
 > > > > have
 > > > > > to tunnel or subnet = translate unless it is on it's home subnet.
 > > > > >
 > > > > > -----Original = Message-----
 > > > > > From: Michael Thomas = [mailto:mat@cisco.com]
 > > > > > Sent: Wednesday, = April 18, 2001 9:49 AM
 > > > > > To: Morrow, Glenn = [RICH2:C330:EXCH]
 > > > > > Cc: Michael Thomas; = Thomas Eklund; 'ipng@sunroof.eng.sun.com';
 > > > > > = 'ietf-itrace@research.att.com'
 > > > > > Subject: RE: Source = addresses, DDoS prevention and ingress
 > filtering
 > > > > >
 > > > > >
 > > > > > Glenn Morrow = writes:
 > > > > >  > If the = node behind the MR obtained its home address from the
 > the
 > > > > mobile
 > > > > >  > router's = subnet, then the MN will use this as the source i.e.
 > the
 > > > > MN's
 > > > > > home
 > > > > >  > subnet is = the MR's subnet.
 > > > > >
 > > > > >    = Right, but when the MR's upstream router does an
 > > > > >    RPF = check... it will drop the SN's packets.
 > > > > >
 > > > > >  > Either way = (tunneling or subnet translation), the topological
 > > > > correctness
 > > > > > is
 > > > > >  > still = maintained.
 > > > > >
 > > > > >    = Well, that's sort of the problem. The SN doesn't
 > > > > >    = know that it's putting topologically incorrect
 > > > > >    = source address in the IP header.
 > > > > >
 > > > > > =              =   Mike
 > > > > >
 > > > >
 > > > >
 > > > >
 > = --------------------------------------------------------------------
 > > > > 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:           &= nbsp;          http://playground.sun.com/ipng
 > FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
 > Direct all administrative requests to = majordomo@sunroof.eng.sun.com
 > = --------------------------------------------------------------------

------_=_NextPart_001_01C0C9D3.69F2DBE0-- -------------------------------------------------------------------- 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 Apr 20 12:57:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KJvUK9009491 for ; Fri, 20 Apr 2001 12:57:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3KJvUai009490 for ipng-dist; Fri, 20 Apr 2001 12:57:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3KJvDK9009483 for ; Fri, 20 Apr 2001 12:57:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28054 for ; Fri, 20 Apr 2001 12:57:11 -0700 (PDT) Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15208 for ; Fri, 20 Apr 2001 12:57:10 -0700 (PDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA14835 for ; Fri, 20 Apr 2001 14:57:28 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Fri, 20 Apr 2001 14:51:28 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Apr 2001 14:56:47 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E4301F4B048@crchy271.us.nortel.com> From: "Glenn Morrow" To: Christian Huitema , Michael Thomas Cc: ipng , ietf-itrace Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Fri, 20 Apr 2001 14:56:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0C9D4.05B658E0" X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0C9D4.05B658E0 Content-Type: text/plain; charset="iso-8859-1" Christian, The same problem is already thrown in even now as an option. This is why MIP and other solutions have been forced to use their COA as the source. If they don't, these routers in the middle may or may not drop their packets. Filtering right now is kind of a pariah - you don't know if it is there or not. Thanks, Glenn -----Original Message----- From: Christian Huitema [mailto:huitema@Exchange.Microsoft.com] Sent: Friday, April 20, 2001 11:39 AM To: Michael Thomas Cc: ipng; ietf-itrace Subject: RE: Source addresses, DDoS prevention and ingress filtering I believe that the source address should be defined as "the address at which the source would like to receive replies to this message." In the case of a mobile host, there is value in getting replies either at your transient address or at the permanent address -- it basically depends on the circumstance, just like multi-homing, and things would be simpler if both were allowed. Mobile networks could also be thought off as multi-homed networks. The mobile router could in theory advertise two prefixes, one based on a "permanent" connection maintain via some tunneling mechanism and one based on the "transient" connection. Indeed, this can also be thought off as an exercise in fast network renumbering. Say a car is traveling at 180 km/h on a freeway, and a cell is 1 km wide -- it stays in any given cell for 20 seconds; you may have to renumber the network every 20 seconds. That seems a more interesting problem to solve than source address filtering, and I would in fact rather not make it even more complex by throwing in mandatory source address filtering... -- Christian Huitema > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, April 20, 2001 8:53 AM > To: Christian Huitema > Cc: Edward Vielmetti; ipng@sunroof.eng.sun.com; ietf- > itrace@research.att.com > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Christian, > > So what is your opinion of using the topologically > "incorrect" IP address as the source when, say, a > mobile node is away from home? It is still, after > all, return routable via its home address, so it's > not completely bogus on its face. In fact, it's no > different than the multihomed case. However, right > now as currently constituted in mobileipv6 two > things will be extremely problematic: > > 1) The stationary host behind a mobile router I brought > up before (no way to know what is "correct") > > 2) RSVP reservations upon change of CoA will need > to create a completely new reservation since > the filterspec must change. If the classifier > used the home address, the reservation could > converge locally which would be beneficial. > > There may well be other things which break because > of the expectation of a fixed source address. > > Mike > > Christian Huitema writes: > > Ed, > > > > I have seen over the past years many knee-jerk reactions to attacks > that > > essentially followed the model you are describing. An example is to cut > > ICMP because it is used in some attacks; the proposal to "verify > unicast > > reverse-path" is another. The problem is that a number of these > defenses > > amount to cutting your nose in order to cure the common cold. For > > example, cutting ICMP also suppresses efficient path MTU discovery; > > random reverse path verification kills multi-homing and makes mobility > > much harder. This is compelled by the evolutionary nature of the > > attacks: many of the ICMP attacks can be replicated over UDP, and thus > > you find sites cutting UDP as well -- and here goes voice over IP; in > > fact, I could also mount attacks by sending TCP packets outside the > > context of connections -- think of the consequences of various router > > protections for that... > > > > The "verify unicast" defense looks good on paper, but if you analyze > it, > > it requires quasi universal deployment to make a difference. This is > not > > simpler than deploying protection against forged addresses in the > > potential targets, mostly large web servers. In fact, the number of > > targets is probably lower than the number of "ingress routers" that > > would have to be upgraded. But then, there are three important > > differences. > > > > First, modern servers actually include protection against the forged > > address attacks that you mention -- proper handling of TCP context > > creation and verification of the plausibility of sequence numbers > > provide a first line of defense; SSL or IPSEC provide further > protection > > for critical systems. Routers don't include such protections today; > they > > would require modification to routing protocols to describe the > > authorized source address in parallel to the allowed destinations, > > possibly additional fast-path hardware, and certainly an increased > > management load. > > > > Second, the protection only works if it is implemented everywhere, and > > is in any case partial. As long as I cannot be sure that all Internet > > routers perform the filtering, I still have to implement adequate > server > > side protections. If the router can be hacked, the protection is > > obviously ineffective. If the egress filtering operates on broad > ranges, > > say a university network, the hacker can stop using random addresses, > > and instead pretend that all packets come from a single machine, e.g. > > the university's web site. > > > > Third, and most important, the network based defense places the defense > > burden at the wrong side of the problem. The local network is not > really > > suffering from the attack; its administrators have only minor > incentives > > to fix it. The one who is suffering is a remote server; there, you have > > a lot of incentives to fix the problem, fix the TCP stack, deploy > IPSEC. > > > > All in all, I wish we would not cut the node of our face. As servers > get > > hardened, the mode of attack will change. We don't want to maim the > > network today to protect against an attack that will not be in much use > > tomorrow. > > > > -- Christian Huitema > > > > > > > > > -----Original Message----- > > > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > > Sent: Thursday, April 19, 2001 9:24 PM > > > To: Christian Huitema > > > Cc: Glenn Morrow; Michael Thomas; Thomas Eklund; > > ipng@sunroof.eng.sun.com; > > > ietf-itrace@research.att.com > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > Christian, > > > > > > The specific threat model is a compromised host being directed under > > > remote control to send a spray of packets with randomly forged source > > > addresses to a victim host far away. Intelligently throwing your > > local > > > equivalent of "ip verify unicast reverse-path" as a check in at > > logical > > > choke points on the network will *in actual practice* drop a whole > lot > > of > > > traffic that should be dropped. This has important implications for > > > network operators. > > > > > > This is not a security or confidentiality problem, and thus IPSEC is > > > irrelevant. It is a network integrity problem. > > > > > > Ed > > > > > > On Thu, 19 Apr 2001, Christian Huitema wrote: > > > > > > > I am not sure it is such a good idea. > > > > > > > > >From a security stand point, it is very weak. You are trusting > that > > > some > > > > third party, at the other end of the network, will do the right > > thing. > > > > What happens if the "first hop" is compromised? And, by the way, > > what > > > > exactly is the first hop? The wireless LAN in my home? The Ethernet > > > > backbone in the same home? If you want any form of security, you > > really > > > > have to build it yourself, e.g. by using IPSEC. The only form of > > source > > > > address control that has a prayer of working is local, i.e. refuse > > to > > > > accept inbound packets in your domain that pretend to already come > > from > > > > an inside address. > > > > > > > > It is also very weak from a routing stand point. Internet routing > is > > > > anything but symmetric. The exit path from a domain depends only on > > the > > > > destination address, not the source address; insisting on strict > > control > > > > of the source address basically breaks multi-homing. It also breaks > > > > several forms of mobility... > > > > > > > > > > > > > -----Original Message----- > > > > > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > > > > Sent: Wednesday, April 18, 2001 10:41 AM > > > > > To: Glenn Morrow > > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > 'ietf- > > > > > itrace@research.att.com' > > > > > Subject: RE: Source addresses, DDoS prevention and ingress > > filtering > > > > > > > > > > And you're going to mandate source filtering on the first hop > > across > > > > the > > > > > entire internet, how? It's a great idea and a best common > > practice > > > > but > > > > > not something that can be set by fiat. > > > > > > > > > > Ed > > > > > > > > > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > > > > > > > > > Then again if source filtering is mandated on the first hop > this > > > > might > > > > > > eliminate the need to do filtering on other hops and this would > > > > > eliminate > > > > > > the need to do subnet translation or tunneling by either the MN > > or > > > > the > > > > > MR. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Morrow, Glenn [RICH2:C330:EXCH] > > > > > > Sent: Wednesday, April 18, 2001 11:56 AM > > > > > > To: 'Michael Thomas' > > > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > > > 'ietf-itrace@research.att.com' > > > > > > Subject: RE: Source addresses, DDoS prevention and ingress > > filtering > > > > > > > > > > > > > > > > > > Oh, I see what you were concerned about. It seems to me that an > > MR > > > > will > > > > > have > > > > > > to tunnel or subnet translate unless it is on it's home subnet. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > > > Sent: Wednesday, April 18, 2001 9:49 AM > > > > > > To: Morrow, Glenn [RICH2:C330:EXCH] > > > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > > > 'ietf-itrace@research.att.com' > > > > > > Subject: RE: Source addresses, DDoS prevention and ingress > > filtering > > > > > > > > > > > > > > > > > > Glenn Morrow writes: > > > > > > > If the node behind the MR obtained its home address from the > > the > > > > > mobile > > > > > > > router's subnet, then the MN will use this as the source > i.e. > > the > > > > > MN's > > > > > > home > > > > > > > subnet is the MR's subnet. > > > > > > > > > > > > Right, but when the MR's upstream router does an > > > > > > RPF check... it will drop the SN's packets. > > > > > > > > > > > > > Either way (tunneling or subnet translation), the > topological > > > > > correctness > > > > > > is > > > > > > > still maintained. > > > > > > > > > > > > Well, that's sort of the problem. The SN doesn't > > > > > > know that it's putting topologically incorrect > > > > > > source address in the IP header. > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > 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 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- ------_=_NextPart_001_01C0C9D4.05B658E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Source addresses, DDoS prevention and ingress = filtering

Christian,

The same problem is already thrown in even now as an = option. This is why MIP and other solutions have been forced to use = their COA as the source. If they don't, these routers in the middle may = or may not drop their packets. Filtering right now is kind of a pariah = - you don't know if it is there or not.

Thanks,

Glenn

-----Original Message-----
From: Christian Huitema [mailto:huitema@Exchange.M= icrosoft.com]
Sent: Friday, April 20, 2001 11:39 AM
To: Michael Thomas
Cc: ipng; ietf-itrace
Subject: RE: Source addresses, DDoS prevention and = ingress filtering


I believe that the source address should be defined = as "the address at
which the source would like to receive replies to = this message." In the
case of a mobile host, there is value in getting = replies either at your
transient address or at the permanent address -- it = basically depends on
the circumstance, just like multi-homing, and things = would be simpler if
both were allowed.

Mobile networks could also be thought off as = multi-homed networks. The
mobile router could in theory advertise two = prefixes, one based on a
"permanent" connection maintain via some = tunneling mechanism and one
based on the "transient" connection. = Indeed, this can also be thought
off as an exercise in fast network renumbering. Say = a car is traveling
at 180 km/h on a freeway, and a cell is 1 km wide -- = it stays in any
given cell for 20 seconds; you may have to renumber = the network every 20
seconds. That seems a more interesting problem to = solve than source
address filtering, and I would in fact rather not = make it even more
complex by throwing in mandatory source address = filtering...

-- Christian Huitema

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Friday, April 20, 2001 8:53 AM
> To: Christian Huitema
> Cc: Edward Vielmetti; ipng@sunroof.eng.sun.com; = ietf-
> itrace@research.att.com
> Subject: RE: Source addresses, DDoS prevention = and ingress filtering
>
>
> Christian,
>
> So what is your opinion of using the = topologically
> "incorrect" IP address as the source = when, say, a
> mobile node is away from home? It is still, = after
> all, return routable via its home address, so = it's
> not completely bogus on its face. In fact, it's = no
> different than the multihomed case. However, = right
> now as currently constituted in mobileipv6 = two
> things will be extremely problematic:
>
> 1) The stationary host behind a mobile router I = brought
>    up before (no way to know = what is "correct")
>
> 2) RSVP reservations upon change of CoA will = need
>    to create a completely new = reservation since
>    the filterspec must change. = If the classifier
>    used the home address, the = reservation could
>    converge locally which would = be beneficial.
>
> There may well be other things which break = because
> of the expectation of a fixed source = address.
>
>       =             = Mike
>
> Christian Huitema writes:
>  > Ed,
>  >
>  > I have seen over the past years many = knee-jerk reactions to attacks
> that
>  > essentially followed the model you = are describing. An example is to
cut
>  > ICMP because it is used in some = attacks; the proposal to "verify
> unicast
>  > reverse-path" is another. The = problem is that a number of these
> defenses
>  > amount to cutting your nose in order = to cure the common cold. For
>  > example, cutting ICMP also = suppresses efficient path MTU discovery;
>  > random reverse path verification = kills multi-homing and makes
mobility
>  > much harder. This is compelled by = the evolutionary nature of the
>  > attacks: many of the ICMP attacks = can be replicated over UDP, and
thus
>  > you find sites cutting UDP as well = -- and here goes voice over IP;
in
>  > fact, I could also mount attacks by = sending TCP packets outside the
>  > context of connections -- think of = the consequences of various
router
>  > protections for that...
>  >
>  > The "verify unicast" = defense looks good on paper, but if you
analyze
> it,
>  > it requires quasi universal = deployment to make a difference. This
is
> not
>  > simpler than deploying protection = against forged addresses in the
>  > potential targets, mostly large web = servers. In fact, the number of
>  > targets is probably lower than the = number of "ingress routers" that
>  > would have to be upgraded. But then, = there are three important
>  > differences.
>  >
>  > First, modern servers actually = include protection against the
forged
>  > address attacks that you mention -- = proper handling of TCP context
>  > creation and verification of the = plausibility of sequence numbers
>  > provide a first line of defense; SSL = or IPSEC provide further
> protection
>  > for critical systems. Routers don't = include such protections today;
> they
>  > would require modification to = routing protocols to describe the
>  > authorized source address in = parallel to the allowed destinations,
>  > possibly additional fast-path = hardware, and certainly an increased
>  > management load.
>  >
>  > Second, the protection only works if = it is implemented everywhere,
and
>  > is in any case partial. As long as I = cannot be sure that all
Internet
>  > routers perform the filtering, I = still have to implement adequate
> server
>  > side protections. If the router can = be hacked, the protection is
>  > obviously ineffective. If the egress = filtering operates on broad
> ranges,
>  > say a university network, the hacker = can stop using random
addresses,
>  > and instead pretend that all packets = come from a single machine,
e.g.
>  > the university's web site.
>  >
>  > Third, and most important, the = network based defense places the
defense
>  > burden at the wrong side of the = problem. The local network is not
> really
>  > suffering from the attack; its = administrators have only minor
> incentives
>  > to fix it. The one who is suffering = is a remote server; there, you
have
>  > a lot of incentives to fix the = problem, fix the TCP stack, deploy
> IPSEC.
>  >
>  > All in all, I wish we would not cut = the node of our face. As
servers
> get
>  > hardened, the mode of attack will = change. We don't want to maim the
>  > network today to protect against an = attack that will not be in much
use
>  > tomorrow.
>  >
>  > -- Christian Huitema
>  >
>  >
>  >
>  > > -----Original = Message-----
>  > > From: Edward Vielmetti [mailto:evielmet@cisco.com]=
>  > > Sent: Thursday, April 19, 2001 = 9:24 PM
>  > > To: Christian Huitema
>  > > Cc: Glenn Morrow; Michael = Thomas; Thomas Eklund;
>  > ipng@sunroof.eng.sun.com;
>  > > = ietf-itrace@research.att.com
>  > > Subject: RE: Source addresses, = DDoS prevention and ingress
filtering
>  > >
>  > > Christian,
>  > >
>  > > The specific threat model is a = compromised host being directed
under
>  > > remote control to send a spray = of packets with randomly forged
source
>  > > addresses to a victim host far = away.  Intelligently throwing your
>  > local
>  > > equivalent of "ip verify = unicast reverse-path" as a check in at
>  > logical
>  > > choke points on the network = will *in actual practice* drop a
whole
> lot
>  > of
>  > > traffic that should be = dropped.  This has important implications
for
>  > > network operators.
>  > >
>  > > This is not a security or = confidentiality problem, and thus IPSEC
is
>  > > irrelevant.  It is a = network integrity problem.
>  > >
>  > > Ed
>  > >
>  > > On Thu, 19 Apr 2001, Christian = Huitema wrote:
>  > >
>  > > > I am not sure it is such a = good idea.
>  > > >
>  > > > >From a security stand = point, it is very weak. You are trusting
> that
>  > > some
>  > > > third party, at the other = end of the network, will do the right
>  > thing.
>  > > > What happens if the = "first hop" is compromised? And, by the
way,
>  > what
>  > > > exactly is the first hop? = The wireless LAN in my home? The
Ethernet
>  > > > backbone in the same home? = If you want any form of security,
you
>  > really
>  > > > have to build it yourself, = e.g. by using IPSEC. The only form
of
>  > source
>  > > > address control that has a = prayer of working is local, i.e.
refuse
>  > to
>  > > > accept inbound packets in = your domain that pretend to already
come
>  > from
>  > > > an inside address.
>  > > >
>  > > > It is also very weak from = a routing stand point. Internet
routing
> is
>  > > > anything but symmetric. = The exit path from a domain depends
only on
>  > the
>  > > > destination address, not = the source address; insisting on
strict
>  > control
>  > > > of the source address = basically breaks multi-homing. It also
breaks
>  > > > several forms of = mobility...
>  > > >
>  > > >
>  > > > > -----Original = Message-----
>  > > > > From: Edward = Vielmetti [mailto:evielmet@cisco.com]=
>  > > > > Sent: Wednesday, = April 18, 2001 10:41 AM
>  > > > > To: Glenn = Morrow
>  > > > > Cc: Michael Thomas; = Thomas Eklund;
'ipng@sunroof.eng.sun.com';
>  > 'ietf-
>  > > > > = itrace@research.att.com'
>  > > > > Subject: RE: Source = addresses, DDoS prevention and ingress
>  > filtering
>  > > > >
>  > > > > And you're going to = mandate source filtering on the first hop
>  > across
>  > > > the
>  > > > > entire internet, = how?  It's a great idea and a best common
>  > practice
>  > > > but
>  > > > > not something that = can be set by fiat.
>  > > > >
>  > > > > Ed
>  > > > >
>  > > > > On Wed, 18 Apr 2001, = Glenn Morrow wrote:
>  > > > >
>  > > > > > Then again if = source filtering is mandated on the first hop
> this
>  > > > might
>  > > > > > eliminate the = need to do filtering on other hops and this
would
>  > > > > eliminate
>  > > > > > the need to do = subnet translation or tunneling by either
the MN
>  > or
>  > > > the
>  > > > > MR.
>  > > > > >
>  > > > > > -----Original = Message-----
>  > > > > > From: Morrow, = Glenn [RICH2:C330:EXCH]
>  > > > > > Sent: Wednesday, = April 18, 2001 11:56 AM
>  > > > > > To: 'Michael = Thomas'
>  > > > > > Cc: Michael = Thomas; Thomas Eklund;
'ipng@sunroof.eng.sun.com';
>  > > > > > = 'ietf-itrace@research.att.com'
>  > > > > > Subject: RE: = Source addresses, DDoS prevention and ingress
>  > filtering
>  > > > > >
>  > > > > >
>  > > > > > Oh, I see what = you were concerned about. It seems to me
that an
>  > MR
>  > > > will
>  > > > > have
>  > > > > > to tunnel or = subnet translate unless it is on it's home
subnet.
>  > > > > >
>  > > > > > -----Original = Message-----
>  > > > > > From: Michael = Thomas [mailto:mat@cisco.com]
>  > > > > > Sent: Wednesday, = April 18, 2001 9:49 AM
>  > > > > > To: Morrow, = Glenn [RICH2:C330:EXCH]
>  > > > > > Cc: Michael = Thomas; Thomas Eklund;
'ipng@sunroof.eng.sun.com';
>  > > > > > = 'ietf-itrace@research.att.com'
>  > > > > > Subject: RE: = Source addresses, DDoS prevention and ingress
>  > filtering
>  > > > > >
>  > > > > >
>  > > > > > Glenn Morrow = writes:
>  > > > > >  > If = the node behind the MR obtained its home address from
the
>  > the
>  > > > > mobile
>  > > > > >  > = router's subnet, then the MN will use this as the source
> i.e.
>  > the
>  > > > > MN's
>  > > > > > home
>  > > > > >  > = subnet is the MR's subnet.
>  > > > > >
>  > > > > = >    Right, but when the MR's upstream router does = an
>  > > > > = >    RPF check... it will drop the SN's = packets.
>  > > > > >
>  > > > > >  > = Either way (tunneling or subnet translation), the
> topological
>  > > > > correctness
>  > > > > > is
>  > > > > >  > still = maintained.
>  > > > > >
>  > > > > = >    Well, that's sort of the problem. The SN = doesn't
>  > > > > = >    know that it's putting topologically = incorrect
>  > > > > = >    source address in the IP header.
>  > > > > >
>  > > > > >    =           Mike
>  > > > > >
>  > > > >
>  > > > >
>  > > > >
>  >
---------------------------------------------------------------= -----
>  > > > > 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:           &= nbsp;          http://playground.sun.com/ipng
>  > FTP = archive:          &nbs= p;           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:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------

------_=_NextPart_001_01C0C9D4.05B658E0-- -------------------------------------------------------------------- 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 Apr 20 17:40:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3L0e2K9009884 for ; Fri, 20 Apr 2001 17:40:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3L0e1W1009883 for ipng-dist; Fri, 20 Apr 2001 17:40:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3L0doK9009876 for ; Fri, 20 Apr 2001 17:39:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15183 for ; Fri, 20 Apr 2001 17:39:50 -0700 (PDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA11368 for ; Fri, 20 Apr 2001 19:34:04 -0600 (MDT) Received: from mordor.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id RAA14261; Fri, 20 Apr 2001 17:39:45 -0700 (PDT) Received: by mordor.yagosys.com (SMI-8.6/SMI-SVR4) id RAA04046; Fri, 20 Apr 2001 17:39:44 -0700 Date: Fri, 20 Apr 2001 17:39:44 -0700 Message-Id: <200104210039.RAA04046@mordor.yagosys.com> From: Mike MacFaden To: fenner@research.att.com cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 MIB revisions: comments solicited Reply-to: mrm@riverstonenet.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, Here are 36 items on draft-ops-rfc2011-update-00.txt Regards, Mike 1. This MIB module has read-write objects, please define the persistence of a set operation for ipForward, ipDefaultTTL, etc. See section 3.1.12 of draft-ietf-snmpconf-bcp-04.txt 2. There is no support for multi-stack/same Address Family implementations. Please consider support and if not, then please state reasoning in front matter. See section 3.1.20 of draft-ietf-snmpconf-bcp-04.txt 3. I suggest liberal use of REFERENCE clause for objects that represent fields exactly as defined in an underlying protocol specification. For example ipv6DefaultHopLimit as specified in 2460 sec 3, 8.2). For a well developed example, see RFC 2674. http://www.nanog.org/mtg-0102/ppt/mibs/sld010.htm 4. ipv6Forwarding: The DESCRIPTION is not appropriate. An agent caps document would define the implementation limitations. The recommendation as to what to return 'wrongValue' is protocol specific. A future version of the SNMP may prefer a different way to indicate the lack of a capability. "Note that for some managed nodes, this object may take on only a subset of the values possible. Accordingly, it is appropriate for an agent to return a `wrongValue' response if a management station attempts to change this object to an inappropriate value." 5. "what about SIIT object saying whether an IPv4 address? describe SIIT mapped or natively mapped on a dual-stack system?" Based on this statement in rfc2765, section 1: "Note that SIIT is not likely to be useful later during transition when most of the Internet is IPv6 and there are only small islands of IPv4 nodes,..." I suggest any such objects be placed in a new SIIT MIB module and not defined here. 6. Please define an explicit object(s) to express capability of an implementation. See the object dot1dDeviceCapabilities as defined in rfc 2674. Section 4 of rfc 2460 provides the list of extension headers, it is probably that some implementations may not implement all features or if future extensions headers are added, it will be useful to identify what a given implementation supports. For IPv6, it might includes handling of various headers, flow label, traffic class, .. 7. I like the ipv4IfTable as it makes more sense to organize some IP attributes by ifIndex. You might also consider the following: - directed broadcast (T/F) - proxy-arp (T/F) - tcp header compression (T/F) - broadcast address --> ipAddressv4BcastAddr - arp cache timeout (NUM/UNIT secs) For an example of existing IPv4 implementation that allows per interface configuration, see ip sub-interface CLI command on a Cisco IOS(tm). 8. General request: Please add *LastChange and *Number objects for all tables to allow mgmt apps to maintain caches. 9. ipv6InterfaceTable - ipv6InterfaceEffectiveMtu - like you said, can be easily computed. ipv6InterfaceReasmMaxSize - my experience is this is not per interface. "ipv6InterfaceAdminStatus: does it make sense to enable/disable IPv6 on its own on the interface?" One will want to enable/disable a given Address Family on a interface shared by multiple address families. I've seen implemented systems where there are entries in the ifTable for IP Interfaces that provide the functionality. I'd prefer a single table to enable/disable an IP Interface(struct ifnet) as opposed to a port. See: http://www.nanog.org/mtg-0102/ppt/mibs/sld051.htm "ipv6InterfaceOperStatus: other than the above, noIfIdentifier(3) is this one's only useful state, which can be determined from the Address table if DAD failed or there is no v6 address on this interface. [not efficiently, though]" I prefer we have an OperStatus if an admin status is included. It would be useful even in IPv4 to see what else might fail such as dhcp assigned addresses or in a particular implementation some lack of resources, etc. ipv6InterfaceIdentifier Ipv6AddressIfIdentifier, ipv6InterfaceIdentifierLength INTEGER, ipv6InterfacePhysicalAddress PhysAddress I suggest the compliance section state it is acceptable that MIN-ACCESS be read only. Most interfaces for will compute these and even for interfaces which may not be straight forward like serial, the current drafts stil provide a way to have an implementation generate acceptable values. "When can this be different from the address of the interface's protocol sub-layer, and why?"" I am aware of at least one IP router that ships with a cache of operator assignable IEEE MAC addresses to provide to user define IP interface. All physical ports in the system have one hardwired MAC, hence the ifPhysAddr of the port != ipNetToMediaPhysAddress of the given IP Address. 10. ipIfStatsTable - "A row with an ipIfStatsIfIndex value of zero indicates a system-wide value; a row with a non-zero ipIfStatsIfIndex" Using 0 in an index is not recommended. Please see section 3.1.7 of draft-ietf-snmpconf-bcp-04.txt. 11. ipIfStatsTable counters - Most of these counters are so weakly defined such that two implementations may not count the same thing. Please fix these counters so they are derived from the underlying protocol specs. Then use a REFERENCE clause in the MIB module to link to the value (See RFC 1493 for example). This will help ensure two different implementations have some verifiable consistency for these counters. Also, these counters are subject to discontinuity. For all counters, please specify which discontinuity object to use. Some background info here: http://www.nanog.org/mtg-0102/ppt/mibs/sld030.htm 12. Since ipIfStatsInTooBigErrors is only valid for IPv6, please state what to do for IPv4 in compliance stmts such that this object may or may not exist. 13. I started to wonder if ipIfStatsTable will need two separate counter sets by address family. Then I realized it isn't necessary as rfc2011/1213 are not going to go disappear from any new implementation any time soon. 14. ipIfStatsTable counters - refresh rate different implementations often have different refresh rates for snmp counters. It might be useful to have an read-only object to express the implementations refersh rate on such counter in milliseconds to minutes. See http://www.nanog.org/mtg-0102/ppt/mibs/sld036.htm 15. Internet Address Prefix table - I suggest ipAddressPrefixOrigin enum be a TC Also suggest "wellknown" be better defined as to what document defines the well known addresses (iana?) 16. I can't see how ipAddressPrefixTable is useful for IPv4. Why can't this jut remaing an ipv6 table with references to rfc2461/draft-ietf-ipngwg-site-prefixes-05.txt ipAddressPrefixOnLinkFlag ipAddressPrefixAutonomousFlag ipAddressPrefixAdvPreferredLifetime ipAddressPrefixAdvValidLifetime 17. ipAddressIfIndex description should just refer to IF-MIB and not rfc2863. 18. ipAddressType, maybe reiterate that broadcast isn't valid option for IPv6 w/reference to draft-ietf-ipngwg-addr-arch-v3-05.txt 19. ipAddressPrefix value "0.0" is good. 20. ipAddressOrigin should be a TC (see item 15) I prefer dhcp (v6 or v6 if need be) over some general string such as "assignedByServer" anyone using bootp? I don't know what is "random" - how does this differ from manual? 21. There should be an object ipAddressOriginCreationTime which is the sysUpTime when the assignment was made. 22. ipAddressStatus should be a TC if it needs to exist at all. I am not sure how useful all these states are and if two implementations will even come close in terms of using them the same way. a) If I assign an interface to a port, it goes preferred, then I delete the assignment, the state goes either to deprecated and at some time, the row is aged out or the row simply will fail to exist. b) The inaccessible(4) value is unnecessary. It is simple to scan the ifTable corresponding to ipAddressIfIndex and determine state. c) I doubt invalid(3) would ever be used. d) duplicate() - this is interesting idea, but not sure how useful it is and at what time the status of this object would transfer out of duplicate state once entered. e) is tentative only applicable to IPv6? 23. If ipAddressStatus survives the next edit, it needs the equivalent of ifLastChanged. 24. inetNetToMediaTable - might want to reference ARP protocol specifications. 25. inetNetToMediaType - Adding 'local' value is redundant. It provides no addtional value I can see. 'static' works just fine for this case. 26. "inetNetToMediaState - why no value for incomplete?" I agree it would be useful to add text to a) describe if these should be in the table b) if so how to represent it (ie use 0 for PhysAddress). The past implementations I'm familar with have not listed unresolved entries. I think a separate table might exist for these though along with some stats/counts/high-watermarks, etc. Table description should state what it expects. 27. "inetNetToMediaState - what values for !ipv6? noNUD(7) or unknown(6)?" The description states use unknown(6) which is fine by me. If Neighbor Unreachability Detection is not in use (e.g. for IPv4), this object is always unknown(6) XXX ?noNUD(8)?." 28. ScopeIdentifier - remove reference to rfc2233 in description. 29. "Should there be associated objects to provide a scope description, similar to ipMRouteScopeNameString?" I don't think so. I can see that it might be useful for diagostics, but I don't think the admin overhead of setting it up is reasonable? 30. inetIcmpTable - Use of value 0 is not recommended. see item #10 above. 31. The summary counters might not be all that useful in the form presented. Especially if the number interfaces are large in a given network element. As an alternative to a summary, maybe provide a "top N" style view of icmp errors by interface to answer the question, which interfaces have the most errors? 32. inetIcmpTable should reference underlying spec for counters. See item #11 above. 33. inetIcmpMsgTable - same indexing problems as #30 inetIcmpMsgEntry, if you remove the summary indexing the table's values make implementation more likely to be correct. I don't see what the summary really buys anyway when getting such detailed information. I think this table should be optional on a per interface basis too. 34. inetIcmpMsgTable - special value 256. A different implementation would simply provide the counts in some scalars of the "others" category. Current model seems needlessly convoluted. 35. inetIcmpMsgTable - it may be that operators only want to see certain icmp messages and not all? 36. inetIcmpMsgType - should be a TC and include a reference to underlying spec. Other MIB modules should able to use the same definition. -------------------------------------------------------------------- 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 Apr 20 18:43:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3L1h0K9010039 for ; Fri, 20 Apr 2001 18:43:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3L1h0xL010038 for ipng-dist; Fri, 20 Apr 2001 18:43:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3L1gmK9010031 for ; Fri, 20 Apr 2001 18:42:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA21645 for ; Fri, 20 Apr 2001 18:42:48 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA09054 for ; Fri, 20 Apr 2001 18:42:47 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Fri, 20 Apr 2001 18:43:29 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 20 Apr 2001 18:42:38 -0700 (Pacific Daylight Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Fri, 20 Apr 2001 18:42:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4693.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 MIB revisions: comments solicited Date: Fri, 20 Apr 2001 18:42:37 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C076265740878F57A@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 MIB revisions: comments solicited Thread-Index: AcDJ/t9YjDBTHchkQU6XJEbwBi1oVAAAfePQ From: "Dave Thaler" To: Cc: X-OriginalArrivalTime: 21 Apr 2001 01:42:38.0548 (UTC) FILETIME=[58D61940:01C0CA04] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3L1gpK9010032 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One quick answer: > 20. ipAddressOrigin should be a TC (see item 15) > I don't know what is "random" - > how does this differ from manual? Random is very different from manual, and means the system randomly generated the host id. Two examples of addresses that use random today: * RFC 3041 privacy addresses * draft-ietf-zeroconf-ipv4-linklocal-02.txt autonet addresses > e) is tentative only applicable to IPv6? No. Most stacks do gratuitous ARP for duplicate Address detection when adding a new IPv4 address. Hence, the same tentative state exists. -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 Mon Apr 23 04:51:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NBpLK9012115 for ; Mon, 23 Apr 2001 04:51:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NBpKrK012114 for ipng-dist; Mon, 23 Apr 2001 04:51:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NBpAK9012107 for ; Mon, 23 Apr 2001 04:51:12 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18437 for ; Mon, 23 Apr 2001 04:51:09 -0700 (PDT) From: EXT-Faycal.Hadjiat@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA00827 for ; Mon, 23 Apr 2001 04:51:08 -0700 (PDT) Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3NBpZH03379 for ; Mon, 23 Apr 2001 14:51:36 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 23 Apr 2001 14:51:04 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 23 Apr 2001 14:50:27 +0300 Message-ID: <153121DE53E8D211A52E0008C72B65FC030C1DB6@paeis01nok> To: ipng@sunroof.eng.sun.com Subject: Flow Label Field of IPv6 Date: Mon, 23 Apr 2001 14:50:24 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3NBpCK9012108 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, Do you know when a decision about flow label specification will be taken? Because, now, it seems there are no really benefits with using IPv6 than IPv4 to improve QoS mecanisms. BR, Fayçal. -------------------------------------------------------------------- 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 Apr 23 13:48:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NKmLK9013177 for ; Mon, 23 Apr 2001 13:48:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NKmKce013176 for ipng-dist; Mon, 23 Apr 2001 13:48:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NKmFK9013168 for ; Mon, 23 Apr 2001 13:48:15 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f3NKitu20200 for ipng@sunroof.eng.sun.com; Mon, 23 Apr 2001 13:44:55 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3JJswK9007551 for ; Thu, 19 Apr 2001 12:54:58 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19394 for ; Thu, 19 Apr 2001 12:54:57 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00066 for ; Thu, 19 Apr 2001 12:54:57 -0700 (PDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id MAA07235; Thu, 19 Apr 2001 12:29:05 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f3JJUUm16931; Thu, 19 Apr 2001 12:30:30 -0700 (PDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id MAA28644; Thu, 19 Apr 2001 12:30:26 -0700 (PDT) Date: Thu, 19 Apr 2001 12:30:25 -0700 (PDT) From: Edward Vielmetti To: Thomas Eklund cc: "'Glenn Morrow '" , "'Michael Thomas '" , "''ipng@sunroof.eng.sun.com' '" , "''ietf-itrace@research.att.com' '" Subject: RE: Source addresses, DDoS prevention and ingress filtering In-Reply-To: <31A473DBB655D21180850008C71E251A0344DA3A@mail.kebne.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Remember, DOS attacks are going to also come from hosts that have been broken into and compromised at the root level. So you will get attacks sourced from systems that can use all of the priveleges and rights that legit users of that system will have. Network filters do not protect from host compromise. all your base are belong to us, Ed On Thu, 19 Apr 2001, Thomas Eklund wrote: > I agree, and in fact using something like AAAv6 in combination with src > filtering is a good start to reduce the DoS attacks... > > -- thomas > > -----Original Message----- > From: Glenn Morrow > To: Edward Vielmetti > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Sent: 2001-04-18 21:37 > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > Definitely not for IPv4 due to its deployed base but perhaps it could be > done for IPv6 - it is an idea - why not? > > -----Original Message----- > From: Edward Vielmetti [ mailto:evielmet@cisco.com > ] > Sent: Wednesday, April 18, 2001 12:41 PM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > 'ietf-itrace@research.att.com' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > And you're going to mandate source filtering on the first hop across the > > entire internet, how? It's a great idea and a best common practice but > not something that can be set by fiat. > > Ed > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > Then again if source filtering is mandated on the first hop this might > > > eliminate the need to do filtering on other hops and this would > eliminate > > the need to do subnet translation or tunneling by either the MN or the > MR. > > > > -----Original Message----- > > From: Morrow, Glenn [RICH2:C330:EXCH] > > Sent: Wednesday, April 18, 2001 11:56 AM > > To: 'Michael Thomas' > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > 'ietf-itrace@research.att.com' > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > Oh, I see what you were concerned about. It seems to me that an MR > will have > > to tunnel or subnet translate unless it is on it's home subnet. > > > > -----Original Message----- > > From: Michael Thomas [ mailto:mat@cisco.com ] > > Sent: Wednesday, April 18, 2001 9:49 AM > > To: Morrow, Glenn [RICH2:C330:EXCH] > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > 'ietf-itrace@research.att.com' > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > Glenn Morrow writes: > > > If the node behind the MR obtained its home address from the the > mobile > > > router's subnet, then the MN will use this as the source i.e. the > MN's > > home > > > subnet is the MR's subnet. > > > > Right, but when the MR's upstream router does an > > RPF check... it will drop the SN's packets. > > > > > Either way (tunneling or subnet translation), the topological > correctness > > is > > > still maintained. > > > > Well, that's sort of the problem. The SN doesn't > > know that it's putting topologically incorrect > > source address in the IP header. > > > > Mike > > > -------------------------------------------------------------------- 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 Apr 23 13:49:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NKn2K9013189 for ; Mon, 23 Apr 2001 13:49:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3NKn2ee013188 for ipng-dist; Mon, 23 Apr 2001 13:49:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3NKmuK9013181 for ; Mon, 23 Apr 2001 13:48:56 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f3NKjbi20230 for ipng@sunroof.eng.sun.com; Mon, 23 Apr 2001 13:45:37 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3K4mtK9008370 for ; Thu, 19 Apr 2001 21:48:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28235 for ; Thu, 19 Apr 2001 21:48:54 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03089 for ; Thu, 19 Apr 2001 21:48:53 -0700 (PDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id VAA01157; Thu, 19 Apr 2001 21:24:57 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f3K4OYb15119; Thu, 19 Apr 2001 21:24:34 -0700 (PDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id VAA12360; Thu, 19 Apr 2001 21:24:29 -0700 (PDT) Date: Thu, 19 Apr 2001 21:24:29 -0700 (PDT) From: Edward Vielmetti Reply-To: Edward Vielmetti To: Christian Huitema cc: Glenn Morrow , Michael Thomas , Thomas Eklund , ipng@sunroof.eng.sun.com, ietf-itrace@research.att.com Subject: RE: Source addresses, DDoS prevention and ingress filtering In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, The specific threat model is a compromised host being directed under remote control to send a spray of packets with randomly forged source addresses to a victim host far away. Intelligently throwing your local equivalent of "ip verify unicast reverse-path" as a check in at logical choke points on the network will *in actual practice* drop a whole lot of traffic that should be dropped. This has important implications for network operators. This is not a security or confidentiality problem, and thus IPSEC is irrelevant. It is a network integrity problem. Ed On Thu, 19 Apr 2001, Christian Huitema wrote: > I am not sure it is such a good idea. > > From a security stand point, it is very weak. You are trusting that some > third party, at the other end of the network, will do the right thing. > What happens if the "first hop" is compromised? And, by the way, what > exactly is the first hop? The wireless LAN in my home? The Ethernet > backbone in the same home? If you want any form of security, you really > have to build it yourself, e.g. by using IPSEC. The only form of source > address control that has a prayer of working is local, i.e. refuse to > accept inbound packets in your domain that pretend to already come from > an inside address. > > It is also very weak from a routing stand point. Internet routing is > anything but symmetric. The exit path from a domain depends only on the > destination address, not the source address; insisting on strict control > of the source address basically breaks multi-homing. It also breaks > several forms of mobility... > > > > -----Original Message----- > > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > Sent: Wednesday, April 18, 2001 10:41 AM > > To: Glenn Morrow > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf- > > itrace@research.att.com' > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > And you're going to mandate source filtering on the first hop across > the > > entire internet, how? It's a great idea and a best common practice > but > > not something that can be set by fiat. > > > > Ed > > > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > > > Then again if source filtering is mandated on the first hop this > might > > > eliminate the need to do filtering on other hops and this would > > eliminate > > > the need to do subnet translation or tunneling by either the MN or > the > > MR. > > > > > > -----Original Message----- > > > From: Morrow, Glenn [RICH2:C330:EXCH] > > > Sent: Wednesday, April 18, 2001 11:56 AM > > > To: 'Michael Thomas' > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > 'ietf-itrace@research.att.com' > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > > > > Oh, I see what you were concerned about. It seems to me that an MR > will > > have > > > to tunnel or subnet translate unless it is on it's home subnet. > > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Wednesday, April 18, 2001 9:49 AM > > > To: Morrow, Glenn [RICH2:C330:EXCH] > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > 'ietf-itrace@research.att.com' > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > > > > Glenn Morrow writes: > > > > If the node behind the MR obtained its home address from the the > > mobile > > > > router's subnet, then the MN will use this as the source i.e. the > > MN's > > > home > > > > subnet is the MR's subnet. > > > > > > Right, but when the MR's upstream router does an > > > RPF check... it will drop the SN's packets. > > > > > > > Either way (tunneling or subnet translation), the topological > > correctness > > > is > > > > still maintained. > > > > > > Well, that's sort of the problem. The SN doesn't > > > know that it's putting topologically incorrect > > > source address in the IP header. > > > > > > Mike > > > > > > > > > -------------------------------------------------------------------- > > 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 Apr 24 07:59:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OExHK9014259 for ; Tue, 24 Apr 2001 07:59:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OExHic014258 for ipng-dist; Tue, 24 Apr 2001 07:59:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OEx4K9014248 for ; Tue, 24 Apr 2001 07:59:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14748 for ; Tue, 24 Apr 2001 07:59:04 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00136 for ; Tue, 24 Apr 2001 07:59:03 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Tue, 24 Apr 2001 07:59:49 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Apr 2001 07:58:58 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Tue, 24 Apr 2001 07:55:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4693.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Source addresses, DDoS prevention and ingress filtering Date: Tue, 24 Apr 2001 07:50:18 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Source addresses, DDoS prevention and ingress filtering Thread-Index: AcDMN3eIwhkQQhVISAuRjqaGhF7ULQAlFRGA From: "Christian Huitema" To: "Edward Vielmetti" Cc: "Glenn Morrow" , "Michael Thomas" , "Thomas Eklund" , , X-OriginalArrivalTime: 24 Apr 2001 14:55:44.0031 (UTC) FILETIME=[A33BD2F0:01C0CCCE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3OEx7K9014249 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am well aware of the threat model. I still believe that we have to find a solution that does not "cut our nose to cure the cold." I have specifically discussed how the attack can be fought by other means, and how the attacker can in fact move from "spray" to other disguises and still continue causing the problem. We have to find a solution that does not prohibit mobile IP or multihoming. -- Christian Huitema > -----Original Message----- > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > Christian, > > The specific threat model is a compromised host being directed under > remote control to send a spray of packets with randomly forged source > addresses to a victim host far away. Intelligently throwing your local > equivalent of "ip verify unicast reverse-path" as a check in at logical > choke points on the network will *in actual practice* drop a whole lot of > traffic that should be dropped. This has important implications for > network operators. > > This is not a security or confidentiality problem, and thus IPSEC is > irrelevant. It is a network integrity problem. > > Ed > > On Thu, 19 Apr 2001, Christian Huitema wrote: > > > I am not sure it is such a good idea. > > > > From a security stand point, it is very weak. You are trusting that some > > third party, at the other end of the network, will do the right thing. > > What happens if the "first hop" is compromised? And, by the way, what > > exactly is the first hop? The wireless LAN in my home? The Ethernet > > backbone in the same home? If you want any form of security, you really > > have to build it yourself, e.g. by using IPSEC. The only form of source > > address control that has a prayer of working is local, i.e. refuse to > > accept inbound packets in your domain that pretend to already come from > > an inside address. > > > > It is also very weak from a routing stand point. Internet routing is > > anything but symmetric. The exit path from a domain depends only on the > > destination address, not the source address; insisting on strict control > > of the source address basically breaks multi-homing. It also breaks > > several forms of mobility... > > > > > > > -----Original Message----- > > > From: Edward Vielmetti [mailto:evielmet@cisco.com] > > > Sent: Wednesday, April 18, 2001 10:41 AM > > > To: Glenn Morrow > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; 'ietf- > > > itrace@research.att.com' > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > And you're going to mandate source filtering on the first hop across > > the > > > entire internet, how? It's a great idea and a best common practice > > but > > > not something that can be set by fiat. > > > > > > Ed > > > > > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > > > > > Then again if source filtering is mandated on the first hop this > > might > > > > eliminate the need to do filtering on other hops and this would > > > eliminate > > > > the need to do subnet translation or tunneling by either the MN or > > the > > > MR. > > > > > > > > -----Original Message----- > > > > From: Morrow, Glenn [RICH2:C330:EXCH] > > > > Sent: Wednesday, April 18, 2001 11:56 AM > > > > To: 'Michael Thomas' > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > 'ietf-itrace@research.att.com' > > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > > > > > > > Oh, I see what you were concerned about. It seems to me that an MR > > will > > > have > > > > to tunnel or subnet translate unless it is on it's home subnet. > > > > > > > > -----Original Message----- > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > Sent: Wednesday, April 18, 2001 9:49 AM > > > > To: Morrow, Glenn [RICH2:C330:EXCH] > > > > Cc: Michael Thomas; Thomas Eklund; 'ipng@sunroof.eng.sun.com'; > > > > 'ietf-itrace@research.att.com' > > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > > > > > > > Glenn Morrow writes: > > > > > If the node behind the MR obtained its home address from the the > > > mobile > > > > > router's subnet, then the MN will use this as the source i.e. the > > > MN's > > > > home > > > > > subnet is the MR's subnet. > > > > > > > > Right, but when the MR's upstream router does an > > > > RPF check... it will drop the SN's packets. > > > > > > > > > Either way (tunneling or subnet translation), the topological > > > correctness > > > > is > > > > > still maintained. > > > > > > > > Well, that's sort of the problem. The SN doesn't > > > > know that it's putting topologically incorrect > > > > source address in the IP header. > > > > > > > > Mike > > > > > > > > > > > > > -------------------------------------------------------------------- > > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 Apr 24 14:57:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OLvBK9014761 for ; Tue, 24 Apr 2001 14:57:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3OLvBQI014760 for ipng-dist; Tue, 24 Apr 2001 14:57:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3OLuqK9014745; Tue, 24 Apr 2001 14:56:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23843; Tue, 24 Apr 2001 14:56:52 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA04712; Tue, 24 Apr 2001 17:06:34 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA03108; Tue, 24 Apr 2001 14:56:47 -0700 (PDT) Received: from [171.70.84.50] (deering-office-mac.cisco.com [171.70.84.50]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAM12076; Tue, 24 Apr 2001 14:56:18 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4 Message-Id: Date: Tue, 24 Apr 2001 14:56:20 -0700 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Steve Deering Subject: ipngwg / ngtrans interim meeting Cc: ietf@ietf.org Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Information about the interim meeting of the IPv6 working groups on May 30, 31, and June 1 is now available at http://research.microsoft.com/ietf-ipv6-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 Tue Apr 24 18:44:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P1iXK9015614 for ; Tue, 24 Apr 2001 18:44:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3P1iXKf015613 for ipng-dist; Tue, 24 Apr 2001 18:44:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P1iDK9015598; Tue, 24 Apr 2001 18:44:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19314; Tue, 24 Apr 2001 18:44:12 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24625; Tue, 24 Apr 2001 18:44:11 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA02160; Tue, 24 Apr 2001 18:44:38 -0700 (PDT) Received: from [171.70.84.50] (deering-office-mac.cisco.com [171.70.84.50]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAM16411; Tue, 24 Apr 2001 18:44:10 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4 Message-Id: In-Reply-To: References: Date: Tue, 24 Apr 2001 18:44:13 -0700 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Steve Deering Subject: Re: ipngwg / ngtrans interim meeting Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Further regarding the interim meeting, here's the rough outline of the planned use of the three days: Wednesday, May 30 9:00 - 9:30 Introductions, Local Arrangements, Etc. 9:30 - 17:00 Joint meeting with 3GPP community, to discuss details of the use of IPv6 in forthcoming 3GPP Standards. Thursday, May 31 9:00 - 17:00 IPv6 working group meeting Friday, June 1 9:00 - 12:00 IPv6 working group meeting 13:00 - 17:00 NGtrans working group meeting If necessary to provide sufficient discussion time, the meetings may be extended into the evenings of Wednesday and/or Thursday. IPv6 Working Group topics will include: - Follow-up from 3GPP discussions - Flow Label definition - Scoped Address Architecture - Updates to Addressing Architecture and Unicast Aggregation specs - Site renumbering guidelines - DNS discovery - (other topics to-be-determined) NGtrans Working Group topics will include: - Intra-site tunneling techniques - review of the different tunneling mechanisms in the context of intra-site communications - resolution of issues around the isatap proposal - Transition tool combination matrix - scoping the mechanisms to break the matrix into smaller components - reviewing the compatibility issues - (other topics to-be-determined) Please send requests for additional agenda topics to the chairs of the appropriate working group. 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 Tue Apr 24 20:15:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P3FmK9015772 for ; Tue, 24 Apr 2001 20:15:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3P3FlT1015771 for ipng-dist; Tue, 24 Apr 2001 20:15:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3P3F5K9015764 for ; Tue, 24 Apr 2001 20:15:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA25759 for ; Tue, 24 Apr 2001 20:15:04 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA04221 for ; Tue, 24 Apr 2001 22:25:48 -0600 (MDT) Received: from localhost ([3ffe:8050:201:1860:c8bd:4c94:4dc0:c7fc]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id MAA12359 for ; Wed, 25 Apr 2001 12:17:16 +0900 (JST) Date: Wed, 25 Apr 2001 12:14:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: a tiny comment on getnameinfo (rfc2553bis-03) User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 42 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (Probably someone has already raised the issues...) Section 6.2 of draft-ietf-ipngwg-rfc2553bis-03.txt has the following text: If the argument node is non-NULL and the argument nodelen is nonzero, then the argument node points to a buffer able to contain up to nodelen characters that will receive the node name as a null-terminated string. If the argument node is NULL or the argument nodelen is zero, the node name will not be returned. If the node's name cannot be located, the numeric form of the nodes address is returned instead of its name. If the sa argument is an IPv6 address the returned nodename may be in the format as defined in [5]. However, the corresponding function prototype just described before the paragraph does not contain the arguments "node" and "nodelen": int getnameinfo(const struct sockaddr *sa, socklen_t salen, char *host, socklen_t hostlen, char *serv, socklen_t servlen, int flags); I think the notation should be consistent; if we leave the function prototype as is, then the text should be rewritten using "host" instead of "node", and "hostlen" instead of "nodelen". Similarly, a succeeding paragraph has a same kind of problem: If the argument service is non-NULL and the argument servicelen is nonzero, then the argument service points to a buffer able to contain up to servicelen characters that will receive the service name as a null- terminated string. If the argument service is NULL or the argument servicelen is zero, the service name will not be returned. If the service name cannot be located, the numeric form of the service address (for example, its port number) is returned instead of its name. there are no variables "service" and "servicelen" in the prototype. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Apr 25 06:07:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PD76K9016594 for ; Wed, 25 Apr 2001 06:07:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PD76D7016593 for ipng-dist; Wed, 25 Apr 2001 06:07:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PD6tK9016586 for ; Wed, 25 Apr 2001 06:06:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17027 for ; Wed, 25 Apr 2001 06:06:56 -0700 (PDT) From: EXT-Faycal.Hadjiat@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA06585 for ; Wed, 25 Apr 2001 06:06:55 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3PD80813807 for ; Wed, 25 Apr 2001 16:08:00 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 25 Apr 2001 16:06:47 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Wed, 25 Apr 2001 16:06:05 +0300 Message-ID: <153121DE53E8D211A52E0008C72B65FC030C1DC1@paeis01nok> To: ipng@sunroof.eng.sun.com Subject: Rsvp & IPv6? Date: Tue, 24 Apr 2001 15:15:35 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3PD6wK9016587 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello everybody, How can we use RSVP with IPv6? It seems flow label is not well defined so send me, please, all informations about the future of this field. Thanks. BR, Fayçal. -------------------------------------------------------------------- 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 Apr 25 09:12:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PGCQK9017085 for ; Wed, 25 Apr 2001 09:12:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PGCPkd017084 for ipng-dist; Wed, 25 Apr 2001 09:12:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PGCDK9017068 for ; Wed, 25 Apr 2001 09:12:14 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22068 for ; Wed, 25 Apr 2001 09:12:14 -0700 (PDT) Received: from goofy.inrialpes.fr (goofy.inrialpes.fr [194.199.24.107]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07331 for ; Wed, 25 Apr 2001 09:12:12 -0700 (PDT) Received: from wells by goofy.inrialpes.fr with local (Exim 3.22 #1 (Debian)) id 14sRti-0003OI-00 for ; Wed, 25 Apr 2001 18:12:10 +0200 Date: Wed, 25 Apr 2001 18:12:10 +0200 From: John Wells To: ipng@sunroof.eng.sun.com Subject: Anycast address implementations Message-ID: <20010425181210.A12966@goofy.inrialpes.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.15i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi- I'd like to know if anyone can shed light on this matter. RFC 2373 (IPv6 Addressing Architecture) defines IPv6 anycast addresses and notes that a "packet sent to an anycast address is routed to the 'nearest' interface having that address, according to the routing protocols' measure of distance". Who defines nearest and how is it defined? Do the anycast routers communicate with each other and elect a router to perform the metrics? I assume these metrics are measured with respect to the source address? I'd also be interested in hearing any real world experiences with anycast addresses, such as inefficiencies, etc., and how anycast addresses are limited in practice, such as if anycast address participants must be defined on a router a priori elected to serve as the address coordinator, etc. Best regards, John Wells -- John WELLS ENSIMAG/3A Télécomm/Réseaux - INRIA Rhône-Alpes Virginia Tech MS/Computer Engineering - Networking and Visualization Lab -------------------------------------------------------------------- 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 Apr 25 11:43:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PIhCK9017351 for ; Wed, 25 Apr 2001 11:43:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PIhCZC017350 for ipng-dist; Wed, 25 Apr 2001 11:43:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PIh1K9017343 for ; Wed, 25 Apr 2001 11:43:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29111 for ; Wed, 25 Apr 2001 11:42:57 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27910 for ; Wed, 25 Apr 2001 11:42:56 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 331445CD4; Wed, 25 Apr 2001 14:42:56 -0400 (EDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D4A485F27; Wed, 25 Apr 2001 14:42:55 -0400 (EDT) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id 853D3323; Wed, 25 Apr 2001 11:42:55 -0700 (PDT) Received: from anw.zk3.dec.com (and.zk3.dec.com [16.140.64.3]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 11F7013E; Wed, 25 Apr 2001 11:42:55 -0700 (PDT) Received: by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id OAA0001596237; Wed, 25 Apr 2001 14:42:54 -0400 (EDT) Date: Wed, 25 Apr 2001 14:42:54 -0400 (EDT) From: Jack McCann Message-Id: <200104251842.OAA0001596237@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com, jinmei@isl.rdc.toshiba.co.jp Subject: Re: a tiny comment on getnameinfo (rfc2553bis-03) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is fixed in the Austin spec (http://www.opengroup.org/austin) and so should get folded back into rfc2553bis when the two specs are aligned. >Section 6.2 of draft-ietf-ipngwg-rfc2553bis-03.txt has the following >text: > > If the argument node is non-NULL and the argument nodelen is nonzero, > then the argument node points to a buffer able to contain up to nodelen > characters that will receive the node name as a null-terminated string. > If the argument node is NULL or the argument nodelen is zero, the node > name will not be returned. If the node's name cannot be located, the > numeric form of the nodes address is returned instead of its name. If > the sa argument is an IPv6 address the returned nodename may be in the > format as defined in [5]. > >However, the corresponding function prototype just described before >the paragraph does not contain the arguments "node" and "nodelen": > > int getnameinfo(const struct sockaddr *sa, socklen_t salen, > char *host, socklen_t hostlen, > char *serv, socklen_t servlen, > int flags); > >I think the notation should be consistent; if we leave the function >prototype as is, then the text should be rewritten using "host" >instead of "node", and "hostlen" instead of "nodelen". > >Similarly, a succeeding paragraph has a same kind of problem: > > If the argument service is non-NULL and the argument servicelen is > nonzero, then the argument service points to a buffer able to contain up > to servicelen characters that will receive the service name as a null- > terminated string. If the argument service is NULL or the argument > servicelen is zero, the service name will not be returned. If the > service name cannot be located, the numeric form of the service address > (for example, its port number) is returned instead of its name. > >there are no variables "service" and "servicelen" in the prototype. -------------------------------------------------------------------- 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 Apr 25 16:05:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PN5lK9017835 for ; Wed, 25 Apr 2001 16:05:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PN5kMl017834 for ipng-dist; Wed, 25 Apr 2001 16:05:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PN5bK9017827 for ; Wed, 25 Apr 2001 16:05:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA25354 for ; Wed, 25 Apr 2001 16:05:38 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net [4.60.68.77]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA25093 for ; Wed, 25 Apr 2001 16:05:33 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 25 Apr 2001 16:05:12 -0700 Received: from eagleswings [4.60.69.105] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 4C6277A1023B4F1689DFFE3230EA8679 for plus 1 more; Wed, 25 Apr 2001 16:05:12 -0700 Reply-To: From: "Tony Hain" To: "John Wells" , Subject: RE: Anycast address implementations Date: Wed, 25 Apr 2001 16:05:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010425181210.A12966@goofy.inrialpes.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-SLUIDL: D64F7C38-D9CF4E37-938607EE-9D5F9A4C Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Anycast is implemented as a host route, and as such the anycast routers don't communicate anything other than their normal routing updates. The distance is not measured, and is strictly a matter of normal routing finding the closest router that has some host behind it willing to answer to the anycast address. As you might guess any long running connection with one of these hosts is subject to routing flaps, with the resulting connection reset when packets appear at a different host than the previous ones did. As such it is much better suited to transaction applications like DNS than long lived applications like FTP. -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of John Wells Sent: Wednesday, April 25, 2001 9:12 AM To: ipng@sunroof.eng.sun.com Subject: Anycast address implementations Hi- I'd like to know if anyone can shed light on this matter. RFC 2373 (IPv6 Addressing Architecture) defines IPv6 anycast addresses and notes that a "packet sent to an anycast address is routed to the 'nearest' interface having that address, according to the routing protocols' measure of distance". Who defines nearest and how is it defined? Do the anycast routers communicate with each other and elect a router to perform the metrics? I assume these metrics are measured with respect to the source address? I'd also be interested in hearing any real world experiences with anycast addresses, such as inefficiencies, etc., and how anycast addresses are limited in practice, such as if anycast address participants must be defined on a router a priori elected to serve as the address coordinator, etc. Best regards, John Wells -- John WELLS ENSIMAG/3A Tilicomm/Riseaux - INRIA Rhtne-Alpes Virginia Tech MS/Computer Engineering - Networking and Visualization Lab -------------------------------------------------------------------- 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 Wed Apr 25 16:46:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PNk0K9017885 for ; Wed, 25 Apr 2001 16:46:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3PNjxHB017884 for ipng-dist; Wed, 25 Apr 2001 16:45:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3PNjlK9017877 for ; Wed, 25 Apr 2001 16:45:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06531 for ; Wed, 25 Apr 2001 16:45:48 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA14934 for ; Wed, 25 Apr 2001 19:00:35 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id ADE9E4B0B for ; Thu, 26 Apr 2001 08:45:43 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: nonexisting destination on p2p link From: itojun@iijlab.net Date: Thu, 26 Apr 2001 08:45:43 +0900 Message-ID: <10506.988242343@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk we observed certain packets goes ping-pong on p2p link. it depends on: - how p2p links are implemented on the stack - how routes to p2p links are configured (this highly is implementation dependent) but anyway, i would like to have your second opinion. KAME code has a special code (disabled by default) for this case, like - suppose I am a router. if the packet comes in from interface Ix, and goes out again to Ix, and interface Ix is a p2p link, I do not forward the packet. instead, I'd emit ICMPv6 no route to host. questions: - is my scenario make sense? or do we have some implementation mistake? - is the KAME special behavior look legal? - are there any implementation that chokes with it? for example, are there implementation that do not check the local address on p2p link, and expect the packet to come back again? - if it looks legal, what ICMPv6 type/code should be used? timexceeded? - how should we document? (if you are curious about the source, see #ifdef PROHIBIT_P2PREDIRECT in sys/netinet6/ip6_forward.c in KAME tree). itojun scenario: suppose we have routers "A" and "B", and they are connected by some p2p link (tunnel, ATM, whatever). case 1: consider link local address (La and Lb). A (La) --- (Lb) B A has fe80::/10 (or fe80::/64 depending on your implementation) route pointed to the p2p link. if A emits a packet with Lx (!= Lb) as a destination, it will reach B. then B forwards it back to A. then A forwards it back to B, ... until hoplimit field goes 0. also, they would emit ICMPv6 redirect to the peer, since the packet gets forwarded back again to the incoming interface. case 2: consider non-link local address (Ga and Gb). Ga and Gb shares a single /64 prefix, P::/64. A (Ga) --- (Gb) B A has P::/64 route pointed to the p2p link. if A emits a packet with Gx (P::x, and Gx != Gb) as a destination, it will reach B. now, the same story as above. note that, as P::/64 is global or sitelocal prefix, remote node can generate the ping-pong packet and chew up the bandwidth on the p2p link (so it may be a security issue). NOTE: gated models p2p links differently. -------------------------------------------------------------------- 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 Apr 25 23:09:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q69RK9018305 for ; Wed, 25 Apr 2001 23:09:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3Q69Q78018304 for ipng-dist; Wed, 25 Apr 2001 23:09:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q69FK9018297 for ; Wed, 25 Apr 2001 23:09:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA08234 for ; Wed, 25 Apr 2001 23:09:16 -0700 (PDT) Received: from givenchy (mailhost.6wind.com [212.234.238.114]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA05979 for ; Wed, 25 Apr 2001 23:09:13 -0700 (PDT) Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy (Postfix) with ESMTP id A08CAB91; Thu, 26 Apr 2001 09:13:50 +0200 (CEST) Received: from 6wind.com (unknown [10.16.0.123]) by intranet.6wind.com (Postfix) with ESMTP id 1F999B478; Thu, 26 Apr 2001 08:12:23 +0200 (CEST) Message-ID: <3AE7BCBA.FB497772@6wind.com> Date: Thu, 26 Apr 2001 08:14:18 +0200 From: Alain Ritoux X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link References: <10506.988242343@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I think theorically REDIRECT should be sent over the p2p link, but dropping the packet is a better sanity check !! > > suppose we have routers "A" and "B", and they are connected by some > p2p link (tunnel, ATM, whatever). > > case 1: consider link local address (La and Lb). > > A (La) --- (Lb) B > > A has fe80::/10 (or fe80::/64 depending on your implementation) > route pointed to the p2p link. if A emits a packet with Lx (!= Lb) as a > destination, it will reach B. then B forwards it back to A. then A forwards > it back to B, ... until hoplimit field goes 0. also, they would emit > ICMPv6 redirect to the peer, since the packet gets forwarded back again to the > incoming interface. Well if Lx is link-local, it should not bie forwarded at all ? > case 2: consider non-link local address (Ga and Gb). Ga and Gb shares a > single /64 prefix, P::/64. > > A (Ga) --- (Gb) B > > A has P::/64 route pointed to the p2p link. if A emits a packet with > Gx (P::x, and Gx != Gb) as a destination, it will reach B. now, the same > story as above. note that, as P::/64 is global or sitelocal prefix, > remote node can generate the ping-pong packet and chew up the bandwidth > on the p2p link (so it may be a security issue). A way to avoid this may be to have only /128 prefixes for non-local adresses for p2p interfaces, on A, p2p interface dump will have something like p2p_if: (La) / 64 (Ga)/128 --> (Gb) so only Gb will be reachable through the link. Is it considered too restrictive ? or what is the use of a P::/6' on a p2p link ? Alain. -- -------------------------------------------------------- Alain RITOUX Tel +33-1-39-30-92-32 Fax +33-1-39-30-92-11 Address : 6WIND 1 place Charles de Gaulle Immeuble Central Gare 78180 MONTIGNY LE BRETONNEUX FRANCE web site : www.6wind.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 Apr 25 23:16:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q6FxK9018333 for ; Wed, 25 Apr 2001 23:15:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3Q6Fxff018332 for ipng-dist; Wed, 25 Apr 2001 23:15:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q6FeK9018325 for ; Wed, 25 Apr 2001 23:15:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29828 for ; Wed, 25 Apr 2001 23:15:41 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA02054 for ; Wed, 25 Apr 2001 23:15:39 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E0DCB4B10; Thu, 26 Apr 2001 15:15:30 +0900 (JST) To: Alain Ritoux Cc: ipng@sunroof.eng.sun.com In-reply-to: alain.ritoux's message of Thu, 26 Apr 2001 08:14:18 +0200. <3AE7BCBA.FB497772@6wind.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: nonexisting destination on p2p link From: itojun@iijlab.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <1817.988265726.0@itojun.org> Date: Thu, 26 Apr 2001 15:15:30 +0900 Message-ID: <1824.988265730@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1817.988265726.1@itojun.org> >> case 1: consider link local address (La and Lb). >> >> A (La) --- (Lb) B >> >> A has fe80::/10 (or fe80::/64 depending on your implementation) >> route pointed to the p2p link. if A emits a packet with Lx (!= Lb) as a >> destination, it will reach B. then B forwards it back to A. then A forwards >> it back to B, ... until hoplimit field goes 0. also, they would emit >> ICMPv6 redirect to the peer, since the packet gets forwarded back again to the >> incoming interface. >Well if Lx is link-local, it should not bie forwarded at all ? in the existing RFCs, there's no wording that forbids forwarding packets to link local address, **given that we forward it back to the same link**. A and B are forwarding packets back to the same link. we cannot forward packets with linklocal address across different links. this part is clear but we are not talking about this. attached is hypothetical example I made to bill. >> case 2: consider non-link local address (Ga and Gb). Ga and Gb shares a >> single /64 prefix, P::/64. >> >> A (Ga) --- (Gb) B >> >> A has P::/64 route pointed to the p2p link. if A emits a packet with >> Gx (P::x, and Gx != Gb) as a destination, it will reach B. now, the same >> story as above. note that, as P::/64 is global or sitelocal prefix, >> remote node can generate the ping-pong packet and chew up the bandwidth >> on the p2p link (so it may be a security issue). >A way to avoid this may be to have only /128 prefixes for non-local >adresses for p2p interfaces, on A, p2p interface dump will have >something like > p2p_if: > (La) / 64 > (Ga)/128 --> (Gb) >so only Gb will be reachable through the link. >Is it considered too restrictive ? or what is the use of a P::/6' on a >p2p link ? as mentioned earlier on the email, this really depends on how you model p2p interfaces. from IPv4 practice, gated uses /128 (err, /32) routes to p2p interfaces. cisco uses /64 (err, /24 or whatever) routes to p2p interfaces. we cannot say which one is right and which one is wrong. my original queestion is, "if we are taking cisco model, (P::/64 points to p2p interfaces), what is the right behavior for us?" itojun ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-ID: <1817.988265726.2@itojun.org> To: sommerfeld@east.sun.com In-reply-to: sommerfeld's message of Wed, 25 Apr 2001 19:52:38 -0400. <200104252352.f3PNqc906725@thunk.east.sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: nonexisting destination on p2p link From: itojun@iijlab.net Date: Thu, 26 Apr 2001 08:58:34 +0900 Message-ID: <10610.988243114@itojun.org> Sender: itojun@itojun.org >Why would you ever want to forward a packet with a link-local >destination address? A | ==+=======+== | | B C hypothetical example - if B has misconfigured and throws packets toward C's link local address to A, A may want to forward it to C and throw icmp6 redirect. (yes, B is broken) was there any spefic wording that we shouldn't? i guess not, so we do not have any special "forbid from forwarding" rule yet. if the packet is addressed to someone else, we forward it. itojun ------- =_aaaaaaaaaa0-- -------------------------------------------------------------------- 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 Apr 26 02:15:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q9EwK9018584 for ; Thu, 26 Apr 2001 02:14:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3Q9EwbV018583 for ipng-dist; Thu, 26 Apr 2001 02:14:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q9EkK9018576 for ; Thu, 26 Apr 2001 02:14:49 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04927 for ; Thu, 26 Apr 2001 02:14:45 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA24132 for ; Thu, 26 Apr 2001 02:14:43 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (sw11.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id QAA26697; Thu, 26 Apr 2001 16:14:40 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f3Q9EaH01653; Thu, 26 Apr 2001 16:14:37 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: Alain Ritoux , ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link In-reply-to: Your message of "Thu, 26 Apr 2001 15:15:30 +0900." <1824.988265730@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Apr 2001 16:14:36 +0700 Message-ID: <1651.988276476@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 26 Apr 2001 15:15:30 +0900 From: itojun@iijlab.net Message-ID: <1824.988265730@itojun.org> | which one is wrong. my original queestion is, "if we are taking | cisco model, (P::/64 points to p2p interfaces), what is the right | behavior for us?" Just forward the packet. If there is a mis-config, and a routing loop happens, the packet will ping pong till the hop count expires, then be trashed. Other than deliberate DoS attacks, there shouldn't be many of these. Where there's no response, apps will try again for a short while, then generally they give up, and eventually some human debugs .. seeing the ping pong from a traceroute is a dead easy way to identify the problem - much easier than having to try to figure out why that other router over there is claiming there's no route (especially when I can see the route in its routing table when I look). Further, forwarding the packet allows the behaviour of nodes that deliberately send packets to themselves in order to test correct functioning of the link. It's relatively harmless, eliminates the need for a special case test, and actually easier to diagnose. So, just send the packet (send a redirect if you want as well). 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 Apr 26 02:23:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q9NrK9018607 for ; Thu, 26 Apr 2001 02:23:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3Q9Nr9C018606 for ipng-dist; Thu, 26 Apr 2001 02:23:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3Q9NdK9018599 for ; Thu, 26 Apr 2001 02:23:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02357 for ; Thu, 26 Apr 2001 02:23:38 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA24053 for ; Thu, 26 Apr 2001 04:41:25 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 91FF44B10; Thu, 26 Apr 2001 18:23:28 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Thu, 26 Apr 2001 16:14:36 +0700. <1651.988276476@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: nonexisting destination on p2p link From: itojun@iijlab.net Date: Thu, 26 Apr 2001 18:23:28 +0900 Message-ID: <4798.988277008@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Just forward the packet. >If there is a mis-config, and a routing loop happens, the packet will >ping pong till the hop count expires, then be trashed. Other than >deliberate DoS attacks, there shouldn't be many of these. Where there's oops, I was not clear enough. I'm asking this because there are a lot of these, because of some applications that specifies wrong outgoing interface for linklocal address. once we have a neighbor cache entry for nonexisting peer, NUD packets will be emitted repeatedly (NUD is mandatory for p2p too) and chew traffic. DoS attack is also our concern. itojun -------------------------------------------------------------------- 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 Apr 26 06:35:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QDZjK9018780 for ; Thu, 26 Apr 2001 06:35:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QDZj2M018779 for ipng-dist; Thu, 26 Apr 2001 06:35:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QDZXK9018772 for ; Thu, 26 Apr 2001 06:35:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14072 for ; Thu, 26 Apr 2001 06:35:34 -0700 (PDT) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA06533 for ; Thu, 26 Apr 2001 06:35:31 -0700 (PDT) Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by arpa.it.uc3m.es (8.9.3/8.9.3) with SMTP id PAA05523 for ; Thu, 26 Apr 2001 15:35:26 +0200 From: "marcelo" To: Subject: ping6 -R Date: Thu, 26 Apr 2001 15:35:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is there any way to implement a -R option (record route) in ping6, as it was in IPv4? Thanks, marcelo bagnulo -------------------------------------------------------------------- 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 Apr 26 07:37:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEb0K9018937 for ; Thu, 26 Apr 2001 07:37:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QEb0mh018936 for ipng-dist; Thu, 26 Apr 2001 07:37:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEajK9018922 for ; Thu, 26 Apr 2001 07:36:45 -0700 (PDT) Received: from hogwart.Central.Sun.COM (hogwart.Central.Sun.COM [129.153.128.110]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24985 for ; Thu, 26 Apr 2001 08:36:45 -0600 (MDT) Received: (from davemq@localhost) by hogwart.Central.Sun.COM (8.11.3+Sun/8.11.3) id f3QEaeP88249; Thu, 26 Apr 2001 09:36:40 -0500 (CDT) X-Authentication-Warning: hogwart.Central.Sun.COM: davemq set sender to Dave.Marquardt@Sun.COM using -f To: ipng@sunroof.eng.sun.com Subject: Re: ping6 -R References: From: Dave Marquardt Date: 26 Apr 2001 09:36:40 -0500 In-Reply-To: Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "marcelo" == marcelo writes: marcelo> Is there any way to implement a -R option (record route) in marcelo> ping6, as it was in IPv4? Thanks, marcelo bagnulo IPv6 doesn't have the record route option, AFAIK. -- Dave Marquardt Sun Microsystems, Inc. Austin, TX +1 512 401-1077 -------------------------------------------------------------------- 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 Apr 26 07:47:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEluK9019039 for ; Thu, 26 Apr 2001 07:47:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QEltN8019038 for ipng-dist; Thu, 26 Apr 2001 07:47:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QEliK9019031 for ; Thu, 26 Apr 2001 07:47:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07797 for ; Thu, 26 Apr 2001 07:47:44 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14416 for ; Thu, 26 Apr 2001 07:47:43 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (sw11.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id VAA20554; Thu, 26 Apr 2001 21:47:41 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f3QEldH02539; Thu, 26 Apr 2001 21:47:40 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link In-reply-to: Your message of "Thu, 26 Apr 2001 18:23:28 +0900." <4798.988277008@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Apr 2001 21:47:39 +0700 Message-ID: <2537.988296459@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 26 Apr 2001 18:23:28 +0900 From: itojun@iijlab.net Message-ID: <4798.988277008@itojun.org> | I'm asking this because there are a lot of these, because of some | applications that specifies wrong outgoing interface for linklocal | address. once we have a neighbor cache entry for nonexisting peer, | NUD packets will be emitted repeatedly (NUD is mandatory for p2p too) | and chew traffic. DoS attack is also our concern. Oh, you mean where the address you're sending to on the P2P link is bad? In that case you'll never get an answer from an NS, so you'll never be transmitting the data packets in the first place, right? That is, you should never get to the stage of needing to start NUD, which doesn't make sense until after you have initial reachability. While you're in that state, packets that arrive are normally just dropped (retaining one in the queue to send if the NS receives a response). I see no problem in generating an ICMPv6 (no route) once you have determined that the address is bad (no-one ever responds to the NS). This is also just what I'd do on an ethernet, or fddi, or anything else. In general, I don't think you should special case link types, unless there's a very good reason. 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 Apr 26 08:11:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QFBIK9019141 for ; Thu, 26 Apr 2001 08:11:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QFBI0k019140 for ipng-dist; Thu, 26 Apr 2001 08:11:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QFB5K9019126 for ; Thu, 26 Apr 2001 08:11:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11235 for ; Thu, 26 Apr 2001 08:11:05 -0700 (PDT) Received: from sea-av1.zama.net (smtp1.zama.net [203.142.132.13]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06270 for ; Thu, 26 Apr 2001 08:10:58 -0700 (PDT) Received: from sea-av1.zama.net (localhost [127.0.0.1]) by sea-av1.zama.net (8.9.3+Sun/8.9.3) with ESMTP id IAA04655 for ; Thu, 26 Apr 2001 08:10:44 -0700 (PDT) Received: from postoff1.zama.net (sea-postoff1.zama.net [172.16.100.20]) by sea-av1.zama.net (8.9.3+Sun/8.9.3) with ESMTP id IAA04649 for ; Thu, 26 Apr 2001 08:10:44 -0700 (PDT) Received: from 7436 ([65.0.1.74]) by postoff1.zama.net (Netscape Messaging Server 4.15) with ESMTP id GCENHW00.21V; Thu, 26 Apr 2001 08:10:44 -0700 Message-ID: <001501c0ce62$d69cefe0$4a010041@home.com> From: "John Spence" To: "marcelo" , References: Subject: Re: ping6 -R Date: Thu, 26 Apr 2001 08:09:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You can also give your xterm a title. That usually looks like -T "my title here" in the xterm command. It might be a little nicer to have ipfstat display the hostname, but this gives you a pretty good solution as well. Spence ----- Original Message ----- From: "marcelo" To: Sent: Thursday, April 26, 2001 6:35 AM Subject: ping6 -R > Is there any way to implement a -R option (record route) in ping6, as it was > in IPv4? > Thanks, > marcelo bagnulo > > -------------------------------------------------------------------- > 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 Apr 26 12:04:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QJ4wK9020065 for ; Thu, 26 Apr 2001 12:04:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QJ4wob020064 for ipng-dist; Thu, 26 Apr 2001 12:04:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QJ4qK9020057 for ; Thu, 26 Apr 2001 12:04:52 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f3QJ1VL28688 for ipng@sunroof.eng.sun.com; Thu, 26 Apr 2001 12:01:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QGD2K9019303 for ; Thu, 26 Apr 2001 09:13:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01072 for ; Thu, 26 Apr 2001 09:13:02 -0700 (PDT) Received: from sea-av1.zama.net (smtp1.zama.net [203.142.132.13]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13336 for ; Thu, 26 Apr 2001 09:12:57 -0700 (PDT) Received: from sea-av1.zama.net (localhost [127.0.0.1]) by sea-av1.zama.net (8.9.3+Sun/8.9.3) with ESMTP id JAA05581 for ; Thu, 26 Apr 2001 09:12:39 -0700 (PDT) Received: from postoff1.zama.net (sea-postoff1.zama.net [172.16.100.20]) by sea-av1.zama.net (8.9.3+Sun/8.9.3) with ESMTP id JAA05573 for ; Thu, 26 Apr 2001 09:12:39 -0700 (PDT) Received: from spence ([203.142.132.5]) by postoff1.zama.net (Netscape Messaging Server 4.15) with ESMTP id GCEQD300.31L; Thu, 26 Apr 2001 09:12:39 -0700 Message-ID: <001301c0ce6b$b70d2b50$150c10ac@zama.net> From: "John Spence" To: "John Spence" , "marcelo" , References: <001501c0ce62$d69cefe0$4a010041@home.com> Subject: Re: ping6 -R Date: Thu, 26 Apr 2001 09:12:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My apologies. My comments were a response to another list (ipfilter) I subscribe to that appeared in the eMail right above yours in my mail client - I mis-clicked. My bad. Spence ----- Original Message ----- From: "John Spence" To: "marcelo" ; Sent: Thursday, April 26, 2001 8:09 AM Subject: Re: ping6 -R > You can also give your xterm a title. That usually looks like -T "my title > here" in the xterm command. It might be a little nicer to have ipfstat > display the hostname, but this gives you a pretty good solution as well. > > Spence > ----- Original Message ----- > From: "marcelo" > To: > Sent: Thursday, April 26, 2001 6:35 AM > Subject: ping6 -R > > > > Is there any way to implement a -R option (record route) in ping6, as it > was > > in IPv4? > > Thanks, > > marcelo bagnulo > > > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Apr 26 12:04:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QJ4JK9020055 for ; Thu, 26 Apr 2001 12:04:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3QJ4IR2020054 for ipng-dist; Thu, 26 Apr 2001 12:04:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3QJ4EK9020047 for ; Thu, 26 Apr 2001 12:04:14 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f3QJ0qp28658 for ipng@sunroof.eng.sun.com; Thu, 26 Apr 2001 12:00:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3ODdZK9014108 for ; Tue, 24 Apr 2001 06:39:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04765 for ; Tue, 24 Apr 2001 06:39:36 -0700 (PDT) Received: from arla.rsn.hk-r.se (arla.rsn.hk-r.se [194.47.143.223]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06944 for ; Tue, 24 Apr 2001 06:39:35 -0700 (PDT) Received: from localhost (is98lho@localhost) by arla.rsn.hk-r.se (8.9.3/8.9.1) with ESMTP id PAA07056 for ; Tue, 24 Apr 2001 15:49:07 GMT X-Authentication-Warning: arla.rsn.hk-r.se: is98lho owned process doing -bs Date: Tue, 24 Apr 2001 15:49:06 +0000 (GMT) From: Linda Olofsson Hoff X-Sender: is98lho@arla.rsn.hk-r.se To: ipng@sunroof.eng.sun.com Subject: IPv4-addresses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! My name is Linda and I am writing a thesis about IPv6 and I am wondering if you've made some investigation/estimation about when we are out of IPv4 addresses? Magazines report different numbers but do not tell why and they doesn't direct to any examination. Can you help me? Grateful for answers! Linda from Sweden -------------------------------------------------------------------- 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 Apr 26 17:25:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3R0P4K9021192 for ; Thu, 26 Apr 2001 17:25:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) id f3R0P3lM021191 for ipng-dist; Thu, 26 Apr 2001 17:25:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f3R0OpK9021184 for ; Thu, 26 Apr 2001 17:24:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13472 for ; Thu, 26 Apr 2001 17:24:50 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA03558 for ; Thu, 26 Apr 2001 18:26:36 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 49FA94B19; Fri, 27 Apr 2001 09:24:42 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Thu, 26 Apr 2001 21:47:39 +0700. <2537.988296459@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: nonexisting destination on p2p link From: itojun@iijlab.net Date: Fri, 27 Apr 2001 09:24:42 +0900 Message-ID: <4548.988331082@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Oh, you mean where the address you're sending to on the P2P link is bad? > >In that case you'll never get an answer from an NS, so you'll never be >transmitting the data packets in the first place, right? That is, you >should never get to the stage of needing to start NUD, which doesn't make >sense until after you have initial reachability. when there's no link layer address (imagine tunnel interfaces), there's no proper NS (packets go out without NS-NA exchange), however, NUD hapens. is my understanding right? itojun -------------------------------------------------------------------- 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 Apr 26 21:42:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3R4gwIM022129 for ; Thu, 26 Apr 2001 21:42:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3R4gwn7022128 for ipng-dist; Thu, 26 Apr 2001 21:42:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3R4glIM022121 for ; Thu, 26 Apr 2001 21:42:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06978 for ; Thu, 26 Apr 2001 21:42:45 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA21169 for ; Thu, 26 Apr 2001 22:45:21 -0600 (MDT) Received: from 157.54.9.104 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Apr 2001 21:10:03 -0700 (Pacific Daylight Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 26 Apr 2001 21:10:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: more comments (questions) aboutdraft-draves-ipngwg-router-selection-01.txt Date: Thu, 26 Apr 2001 21:10:03 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9CC0@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: more comments (questions) aboutdraft-draves-ipngwg-router-selection-01.txt Thread-Index: AcCxzGofUCTmRkuZRXSc6EnXuLmANwdApL+g From: "Richard Draves" To: "JINMEI Tatuya / ????" Cc: X-OriginalArrivalTime: 27 Apr 2001 04:10:04.0008 (UTC) FILETIME=[EF9EAE80:01C0CECF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3R4gnIM022122 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have a couple of questions on the draft: Sorry for the delay... These are good questions. > 1. what should a host do when it receives an RA with the preference > field being set to 10 (i.e. reserved)? > - ignore the entire RA. > - accept the RA, but consider the preference value as > another value? > if so, high/medium/low? > - other option? How about, treat the RA as if the RouterLifetime field is zero. I think this will produce the best compatibility with future use of the reserved preference value. > 2. if the preference value for a router changes, does/should it > affect existing destination cache entries? For example, consider > the following scenario: > - a host H receives an RA from a router R1 with the medium > preference. > - H sends a packet to an off-link destination D. H uses R as the > next hop, and records H in the destination cache. > - a host A then receives an RA from another router R2 with the high > preference. > now, what should happen on the destination cache for D in H? > Should it be removed once, prompting H to do next hop determination > again (and to choose the more preferred router R2). Or, should H > just keep the old cache and its next hop until it becomes > unreachable? I think this is a quality of implementation issue that can be left unspecified. My implementation will invalidate the destination cache appropriately when the routing table changes. Rich -------------------------------------------------------------------- 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 Apr 26 21:52:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3R4qRIM022162 for ; Thu, 26 Apr 2001 21:52:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3R4qRRi022161 for ipng-dist; Thu, 26 Apr 2001 21:52:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3R4q2IM022146; Thu, 26 Apr 2001 21:52:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA23401; Thu, 26 Apr 2001 21:52:01 -0700 (PDT) Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.164.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA04639; Thu, 26 Apr 2001 21:51:59 -0700 (PDT) Received: from ns (kimyj.etri.re.kr [129.254.164.113]) by pec.etri.re.kr (8.10.0/8.10.0) with SMTP id f3R4quV19159; Fri, 27 Apr 2001 13:52:58 +0900 (KST) Message-ID: <01cb01c0cecd$ed188ac0$71a4fe81@etri.re.kr> Reply-To: "Dr. Yong Jin Kim" From: "Dr. Yong Jin Kim" To: , , Subject: Global IPv6 Summit in Korea (July 3 - 6) Date: Fri, 27 Apr 2001 12:54:06 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello ! My name is Yong-Jin Kim, the chair of Korean IPv6 Forum. I¡¯m very pleased to inform you that another global IPv6 summit will be held in Seoul on July for 4 days (July 3 - 6) (http://www.ipv6.or.kr/ipv6summit) after the Canadian Summit on May (http://www.foretec.com/IPv6-index.htm). Asian countries are in very high demand of IPv6 according to the rapid increase of Internet, cellular, and wireless mobile Internet users. Governments of Japan and Korea already announced their strong intentions of IPv6 deployment. China is also very interested in the deployment of IPv6. I believe this IPv6 summit can provide you with an opportunity to understand the current status and future plans of national and regional IPv6 development and deployment in the world, especially the Asian countries. Overall program is focused on transition and deployment towards IPv6 to make IPv6 real ! The program consists of 2 tutorials (IPv6 and Mobile IP) and 6 keynote speeches, and 8 technical sessions. The program is scheduled to be fixed around the mid of May. If you are interested in the presentation or sponsorship, please inform us what you want. (ipv6-sec@ipv6.or.kr) Yours Sincerely, Yong-Jin Kim -------------------------------------------------------------------- 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 Apr 26 22:45:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3R5jnIM022207 for ; Thu, 26 Apr 2001 22:45:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3R5jmqW022206 for ipng-dist; Thu, 26 Apr 2001 22:45:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3R5jbIM022199 for ; Thu, 26 Apr 2001 22:45:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA13492 for ; Thu, 26 Apr 2001 22:45:35 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA10521 for ; Thu, 26 Apr 2001 23:48:22 -0600 (MDT) Received: from 157.54.1.52 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Apr 2001 21:21:00 -0700 (Pacific Daylight Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 26 Apr 2001 21:21:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: comment to draft-draves-ipngwg-router-selection-00.txt Date: Thu, 26 Apr 2001 21:21:00 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8024EF516@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comment to draft-draves-ipngwg-router-selection-00.txt Thread-Index: AcCwjxN6n9cVNXQ8Sx2AMymgB3SljgeQgliA From: "Richard Draves" To: "Jun-ichiro itojun Hagino" Cc: X-OriginalArrivalTime: 27 Apr 2001 04:21:01.0051 (UTC) FILETIME=[773F7CB0:01C0CED1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3R5jeIM022200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > RA preference is very useful in the following very > simple situations. > your slide did not cover this, i believe this scenario > is the most > popular case. itojun, yes the router selection mechanisms will definitely help your scenario. I didn't focus on this scenario in my discussion because I feel the most challenging scenarios have different administrators for the routers, and your scenario most likely involves a single administrator who can coordinate the configuration. Thanks, Rich > a host is on a non-leaf network. > - if we throw RA from router A only, we will lose > connectivity to "leaf" > if router A goes down. > - if we throw RA from both router A and B, we have lots of > icmp6 redirect > if router B is picked as the default outgoing router for host C. > > so what you will want to do is: > - set RA preference as router A > router B, advert from both. > > upstream > | > router A > | > ==+===============+== > | | > router B host C > | > leaf > > -------------------------------------------------------------------- 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 Apr 26 23:49:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3R6nwIM022283 for ; Thu, 26 Apr 2001 23:49:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3R6nwii022282 for ipng-dist; Thu, 26 Apr 2001 23:49:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3R6nkIM022275 for ; Thu, 26 Apr 2001 23:49:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25942 for ; Thu, 26 Apr 2001 23:49:46 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA29242 for ; Fri, 27 Apr 2001 00:52:32 -0600 (MDT) Received: from 157.54.9.100 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Apr 2001 23:14:00 -0700 (Pacific Daylight Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 26 Apr 2001 23:14:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: nonexisting destination on p2p link Date: Thu, 26 Apr 2001 23:14:00 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9CC4@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: nonexisting destination on p2p link Thread-Index: AcDOsMioZcRBuylMRq2J6jEx25LOnwAL5tpQ From: "Richard Draves" To: , "Robert Elz" Cc: X-OriginalArrivalTime: 27 Apr 2001 06:14:01.0159 (UTC) FILETIME=[4081DD70:01C0CEE1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3R6nnIM022276 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > when there's no link layer address (imagine tunnel interfaces), > there's no proper NS (packets go out without NS-NA > exchange), however, > NUD hapens. is my understanding right? The MS implementation works that way. For a p2p interface, we create the neighbor cache entry in the stale state (since we know the link-layer address a priori), but then NUD can operate. Here's another scenario along these lines: assign a /64 to a p2p link between two routers. Now someone sends a packet to an address in the /64, but the address is not assigned to either router. The routers will forward the packet back & forth until the hop limit hits zero. This will happen before NUD has a chance to kick in. I agree with itojun, better to generate a destination-unreachable/address-unreachable error instead of forwarding a packet back out the p2p interface from which it arrived. Rich -------------------------------------------------------------------- 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 Apr 27 01:26:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3R8QhIM022443 for ; Fri, 27 Apr 2001 01:26:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3R8QgWK022442 for ipng-dist; Fri, 27 Apr 2001 01:26:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3R8QVIM022435 for ; Fri, 27 Apr 2001 01:26:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04145 for ; Fri, 27 Apr 2001 01:26:31 -0700 (PDT) Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA02634 for ; Fri, 27 Apr 2001 02:29:58 -0600 (MDT) Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.9.3/3.7W01041220) with ESMTP id RAA29078; Fri, 27 Apr 2001 17:26:28 +0900 (JST) Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.9.3/3.7W-MAILGATE-NEC) with ESMTP id RAA14315; Fri, 27 Apr 2001 17:25:43 +0900 (JST) Received: from mgw1.netlab.nec.co.jp (mgw1.netlab.nec.co.jp [133.201.4.10]) by mailsv.nec.co.jp (8.11.3/3.7W-MAILSV-NEC) with ESMTP id f3R8P2v14002; Fri, 27 Apr 2001 17:25:02 +0900 (JST) Received: from mail.netlab.nec.co.jp (mail.netlab.nec.co.jp [172.16.3.22]) by mgw1.netlab.nec.co.jp (8.9.3/3.7W-MGW1_NETLAB) with ESMTP id QAA07599; Fri, 27 Apr 2001 16:28:26 +0900 (JST) Received: from splnx102.netlab.nec.co.jp (splnx102.netlab.nec.co.jp [172.16.5.210]) by mail.netlab.nec.co.jp (8.9.3/3.7W-MAIL.NETLAB) with ESMTP id QAA06134; Fri, 27 Apr 2001 16:28:25 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by splnx102.netlab.nec.co.jp (8.9.3/3.7W20000912HK) with ESMTP id QAA09357; Fri, 27 Apr 2001 16:25:55 +0900 (JST) To: marcelo@it.uc3m.es Cc: ipng@sunroof.eng.sun.com From: kitamura@da.jp.nec.com Subject: Re: ping6 -R In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010427162555K.kitamura@netlab.nec.co.jp> Date: Fri, 27 Apr 2001 16:25:55 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is there any way to implement a -R option (record route) in ping6, as it was > in IPv4? > Thanks, > marcelo bagnulo An idea "Record Route for IPv6 (RR6)" has been proposed. #This idea was presented at the 49th San Diego meeting. Please see http://www.ietf.org/internet-drafts/draft-kitamura-ipv6-record-route-00.txt And, I have implemented and verified this idea. Of course, "ping6 -R" has been implemented. If you would like to try my implementation. Please let me know. Regards, Hiroshi -------------------------------------------------------------------- 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 Apr 28 22:37:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3T5bnIM026700 for ; Sat, 28 Apr 2001 22:37:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3T5bnge026699 for ipng-dist; Sat, 28 Apr 2001 22:37:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3T5bWIM026692 for ; Sat, 28 Apr 2001 22:37:34 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA09559 for ; Sat, 28 Apr 2001 22:37:31 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA05534 for ; Sat, 28 Apr 2001 22:37:31 -0700 (PDT) Received: (qmail 22433 invoked by uid 1001); 29 Apr 2001 05:37:52 -0000 Date: 29 Apr 2001 05:37:52 -0000 Message-ID: <20010429053752.15731.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing References: <2604.988394701@brandenburg.cs.mu.OZ.AU> <14687.988387432@itojun.org> <2604.988394701@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm cc'ing this to IPNG. It's up to IPNG to deprecate A6. Furthermore, standardization activities should not be carried out on namedroppers, for reasons discussed in http://cr.yp.to/djbdns/namedroppers.html. Robert Elz writes: > undisputed extra flexibility We all agree that A6 is an extension to the DNS protocol. This does not mean that it adds flexibility to DNS. Server-side indirection provides the same functions with no protocol changes. Paul Vixie writes: > Hint to whoever is in charge: the time to debate A6's merits at this level > was: before it got put on the standards track, That would have been a good time, but now is a good time too. There is no guarantee that a protocol put on the standards track will move along that track, or that it will stay on the track. In fact, under IETF rules, protocols that want to advance are subject to more scrutiny, not less. The proponents of A6-everywhere think that they have the right to deprecate AAAA. So why don't the proponents of AAAA-everywhere have the right to deprecate A6? > before a lot of code got written, and before a lot of operational > deployment was put into various long and expensive pipelines. So, because you and Microsoft have wasted time on a bad extension, every other DNS implementor is required to waste time too? Including all future DNS implementors? ---Dan -------------------------------------------------------------------- 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 Apr 29 19:05:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U25dIM027363 for ; Sun, 29 Apr 2001 19:05:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3U25dvn027362 for ipng-dist; Sun, 29 Apr 2001 19:05:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U25RIM027355 for ; Sun, 29 Apr 2001 19:05:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05013 for ; Sun, 29 Apr 2001 19:05:26 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06899 for ; Sun, 29 Apr 2001 20:20:08 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D3F704B10; Mon, 30 Apr 2001 11:05:14 +0900 (JST) To: Paul A Vixie Cc: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org In-reply-to: vixie's message of Sat, 28 Apr 2001 22:14:16 MST. <200104290514.WAA55084@redpaul.mfnx.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: AAAA/A6 thing From: itojun@iijlab.net Date: Mon, 30 Apr 2001 11:05:14 +0900 Message-ID: <10857.988596314@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >but the thing that propped up the rapid adoption of IPv6 -- in spite of the >fact that it solves absolutely none of the known problems in the routing >system -- was rapid renumbering. A6 was then set forth as the means by >which this would be achieved, and moreover, the means by which the routing >system's pain would be eased since multihoming would be a first order effect >and it would cease to matter who owned the address space you used day-to-day. > >if we're going to abandon A6 then i for one am ready to listen to tony li's >"too little, too soon" comment, through IPv6 itself into the waste bin, and >go back to the whiteboard and solve more of the problems we actually have. >there is NO justification for the rapid and early adoption of IPv6 in its >present form unless A6 or something very much like A6 is made a part of it. sorry, i cannot follow your logic here. as far as i understand rapid renumbering was not the sole reason to pursue IPv6. for me, bigger address space is the most important concern. i have checked all IPng requirement documents (rfc17xx and 16xx) and i found no text that says "renumbering is the biggest concern". is there really a large consensus on this? on the contrary, there are wording for routing table size. as far as i understand IPv6 addressing plan as well as 6bone routing guideline solves this portion of the problem. itojun -------------------------------------------------------------------- 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 Apr 29 20:57:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U3vBIM027551 for ; Sun, 29 Apr 2001 20:57:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3U3vBPj027550 for ipng-dist; Sun, 29 Apr 2001 20:57:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U3uxIM027543 for ; Sun, 29 Apr 2001 20:56:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11345 for ; Sun, 29 Apr 2001 20:56:57 -0700 (PDT) Received: from roam.psg.com ([206.163.43.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA28452 for ; Sun, 29 Apr 2001 22:12:12 -0600 (MDT) Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14u4ko-0000k2-00; Mon, 30 Apr 2001 05:53:42 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing References: <200104290514.WAA55084@redpaul.mfnx.net> <10857.988596314@itojun.org> Message-Id: Date: Mon, 30 Apr 2001 05:53:42 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [ namedroppers removed from cc: ] > on the contrary, there are wording for routing table size. > as far as i understand IPv6 addressing plan as well as 6bone routing > guideline solves this portion of the problem. unfortunately, operators seem unable to realize this. if there is the same amount and trend of multi-homing, and the same routing protocols, and the same mass of multiply-connected providers, their lack of perception would seem to be understandable. randy -------------------------------------------------------------------- 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 Apr 29 21:14:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U4ESIM027582 for ; Sun, 29 Apr 2001 21:14:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3U4ESjC027581 for ipng-dist; Sun, 29 Apr 2001 21:14:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U4EIIM027574 for ; Sun, 29 Apr 2001 21:14:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA25394 for ; Sun, 29 Apr 2001 21:14:18 -0700 (PDT) Received: from infbosvw.inf.com ([216.52.49.35]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA11749 for ; Sun, 29 Apr 2001 22:29:35 -0600 (MDT) Received: from 204.4.54.41 by infbosvw.inf.com (InterScan E-Mail VirusWall NT); Mon, 30 Apr 2001 00:09:50 -0400 (Eastern Daylight Time) Received: from kecmsg05.ad.infosys.com ([192.168.117.11]) by kec-01-msg.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 30 Apr 2001 09:41:01 +0530 content-class: urn:content-classes:message Subject: a query... Date: Mon, 30 Apr 2001 09:41:01 +0530 Message-ID: <9DB6357440BAD411A6A00050BA8CA56B05844D0E@kecmsg05.ad.infosys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a query... X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 Thread-Index: AcDRK5CeJBPRrMk4T/W4lHe5/lH0vQ== From: "Kumar Gaurava" To: X-OriginalArrivalTime: 30 Apr 2001 04:11:01.0291 (UTC) FILETIME=[91009FB0:01C0D12B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3U4EJIM027575 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi! all... i am new to this field of ipv6 and hence don't know much about it. i know it seems stupid to pose such a question to experts like u..but i have to. "what is the basic differences between ipv4 and ipv6 apart from the enlarged addressing space we get....?" differences in terms of new protocols...enhanced protocol features...security etc? also any suggestions of sites where i can get a comprehensive reading material starting from scratch...? ofcourse i know ipv4. thankx a lot... Kumar Gaurava Software Engineer Infosys-Bangalore. -------------------------------------------------------------------- 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 Apr 29 23:07:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U676IM027674 for ; Sun, 29 Apr 2001 23:07:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3U676NE027673 for ipng-dist; Sun, 29 Apr 2001 23:07:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U66rIM027666 for ; Sun, 29 Apr 2001 23:06:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12463 for ; Sun, 29 Apr 2001 23:06:54 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA15203 for ; Sun, 29 Apr 2001 23:06:53 -0700 (PDT) Received: (qmail 24055 invoked by uid 1001); 30 Apr 2001 06:07:10 -0000 Date: 30 Apr 2001 06:07:10 -0000 Message-ID: <20010430060710.18274.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing References: <2406.988517701@itojun.org> <200104290514.WAA55084@redpaul.mfnx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul A Vixie writes: > i have not, yet, heard anything new against A6 in this round of the debate. http://cr.yp.to/djbdns/killa6.html In January, Elz claimed that these issues were already covered in the ``IPNG, and perhaps DNSIND'' archives. I commented that I didn't see server-side indirection discussed anywhere in the IPNG archives; I asked when the discussion happened, and what benefits were attributed to client-side indirection. Elz dodged both questions. Now we have Vixie trying to pull a similar stunt. Legitimate standards organizations never have any trouble showing people the justifications for their decisions. ---Dan -------------------------------------------------------------------- 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 Apr 29 23:16:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U6GqIM027706 for ; Sun, 29 Apr 2001 23:16:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3U6GpdS027705 for ipng-dist; Sun, 29 Apr 2001 23:16:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U6GgIM027698 for ; Sun, 29 Apr 2001 23:16:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA19984 for ; Sun, 29 Apr 2001 23:16:42 -0700 (PDT) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA17558 for ; Sun, 29 Apr 2001 23:16:41 -0700 (PDT) Received: from vaio (as1-52.chi.il.dial.anet.com [198.92.156.52]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id BAA21738; Mon, 30 Apr 2001 01:16:32 -0500 (CDT) Message-ID: <003501c0d13c$94f4fba0$df00a8c0@vaio> From: "JIM FLEMING" To: Cc: , References: <10857.988596314@itojun.org> Subject: Re: AAAA/A6 thing Date: Mon, 30 Apr 2001 01:12:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I thought the main reason for IPv6 was so that people could write RFCs and get paid to travel all around the world, imposing their complexity on others... Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp ----- Original Message ----- From: To: "Paul A Vixie" Cc: ; Sent: Sunday, April 29, 2001 9:05 PM Subject: Re: AAAA/A6 thing > >but the thing that propped up the rapid adoption of IPv6 -- in spite of the > >fact that it solves absolutely none of the known problems in the routing > >system -- was rapid renumbering. A6 was then set forth as the means by > >which this would be achieved, and moreover, the means by which the routing > >system's pain would be eased since multihoming would be a first order effect > >and it would cease to matter who owned the address space you used day-to-day. > > > >if we're going to abandon A6 then i for one am ready to listen to tony li's > >"too little, too soon" comment, through IPv6 itself into the waste bin, and > >go back to the whiteboard and solve more of the problems we actually have. > >there is NO justification for the rapid and early adoption of IPv6 in its > >present form unless A6 or something very much like A6 is made a part of it. > > sorry, i cannot follow your logic here. as far as i understand rapid > renumbering was not the sole reason to pursue IPv6. for me, bigger > address space is the most important concern. i have checked all > IPng requirement documents (rfc17xx and 16xx) and i found no text > that says "renumbering is the biggest concern". is there really a > large consensus on this? > > on the contrary, there are wording for routing table size. > as far as i understand IPv6 addressing plan as well as 6bone routing > guideline solves this portion of the problem. > > itojun > -------------------------------------------------------------------- > 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 Mon Apr 30 02:06:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U966IM027818 for ; Mon, 30 Apr 2001 02:06:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3U966dg027817 for ipng-dist; Mon, 30 Apr 2001 02:06:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U95sIM027810 for ; Mon, 30 Apr 2001 02:05:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27399 for ; Mon, 30 Apr 2001 02:05:54 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA22658 for ; Mon, 30 Apr 2001 03:22:13 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA06727; Mon, 30 Apr 2001 11:05:44 +0200 (MET DST) Date: Mon, 30 Apr 2001 11:05:44 +0200 From: Ignatios Souvatzis To: Linda Olofsson Hoff Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv4-addresses Message-ID: <20010430110544.B6664@theory.cs.uni-bonn.de> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from is98lho@student.hk-r.se on Tue, Apr 24, 2001 at 03:49:06PM +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 24, 2001 at 03:49:06PM +0000, Linda Olofsson Hoff wrote: > My name is Linda and I am writing a thesis about IPv6 and I am wondering > if you've made some investigation/estimation about when we are out of IPv4 > addresses? >=20 > Magazines report different numbers but do not tell why and they doesn't > direct to any examination. The traditional estimates are all in the 2003 to 2007 range, I think, but vary. E.g., http://www.pcin.net/archive/2001/20010124.shtml estimate 20= 05. However, although not all possible address blocks are allocated yet, lots of the connected machines already don't connect through real addresses, but either through "socks" or "proxy" style gateways or through "Network Address Translation" boxes. These methods only allow for a few applications to work, but don't provide a truly transparent general purpose network, so in my opinion we're effectively at the 110% mark already. About the transparency issue, read Brian Carpenters talk at http://www.hursley.ibm.com/~bc/transp/transp.htm Regards, -is --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOu0q5TCn4om+4LhpAQGraQf/XRx7KkWqS3+YLlkzntTr5FKYTvcscLTc tETHmKt66ohqHVu+YXRvbtlFU53+tqf0KU75qRiwwED1pRxwmywiS4DhHSIR2JUc 2xFixUdzbhECIBB48w2xvEasp6XyFU6emR7AJbS03AlLqMdUZyNehd1zMFq+xurV aRqq5aza6MTeZ+He7GS7wxRj9SBZjHP8lbR9BPMmzLoWF1uvwNiDP4bDFMU4XPOT oiqug6hLjvFxPULUMI7I0lIjM5QFqprqVX7U9mPoWpn4xPQYvc1wmnm72z/8HWtO 5AILfapbHtDgu5GEsUksAXj8sGolUtUAooN+i+YUmkgB+DwAzExZow== =er47 -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F-- -------------------------------------------------------------------- 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 Apr 30 02:28:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U9SNIM027850 for ; Mon, 30 Apr 2001 02:28:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3U9SNBG027849 for ipng-dist; Mon, 30 Apr 2001 02:28:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3U9SBIM027842 for ; Mon, 30 Apr 2001 02:28:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28638 for ; Mon, 30 Apr 2001 02:28:11 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA12956 for ; Mon, 30 Apr 2001 02:28:10 -0700 (PDT) From: Masataka Ohta Message-Id: <200104300916.SAA06619@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA06619; Mon, 30 Apr 2001 18:16:21 +0900 Subject: Re: AAAA/A6 thing In-Reply-To: <20010430060710.18274.qmail@cr.yp.to> from "D. J. Bernstein" at "Apr 30, 2001 06:07:10 am" To: "D. J. Bernstein" Date: Mon, 30 Apr 2001 18:16:21 +0859 () CC: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan; It's your problem. > Paul A Vixie writes: > > i have not, yet, heard anything new against A6 in this round of the debate. > > http://cr.yp.to/djbdns/killa6.html How about: aol.com. NS ns0.aol.net. aol.com. NS ns1.aol.net. aol.net. NS ns0.aol.com. aol.net. NS ns1.aol.com. ? > Legitimate standards organizations never have any trouble showing people > the justifications for their decisions. As we already discussed with AXFR, you must put glue information in a separate cache local to a zone (or, better, a referral). RFC 1034 does not prohibit to do so. I thought you had already fixed your broken implementation. 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 Mon Apr 30 03:33:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UAXaIM027916 for ; Mon, 30 Apr 2001 03:33:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UAXadj027915 for ipng-dist; Mon, 30 Apr 2001 03:33:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UAXQIM027908 for ; Mon, 30 Apr 2001 03:33:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02290 for ; Mon, 30 Apr 2001 03:33:25 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA02607 for ; Mon, 30 Apr 2001 03:33:24 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id MAA27029; Mon, 30 Apr 2001 12:32:33 +0200 (MEST) Message-ID: <3AED3F71.B8981F55@inrialpes.fr> Date: Mon, 30 Apr 2001 12:33:22 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Linda Olofsson Hoff CC: ipng@sunroof.eng.sun.com Subject: Re: IPv4-addresses References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, > Linda Olofsson Hoff wrote: > My name is Linda and I am writing a thesis about IPv6 and I am wondering > if you've made some investigation/estimation about when we are out of IPv4 > addresses? > > Magazines report different numbers but do not tell why and they doesn't > direct to any examination. It depends where and who you are. Most addresses have been allocated to large organizations, mainly in the US, much less in Europe, and even much less in Asia, and I don't even dare thinking about Africa. Then, from a Noth-East Asia perspective, which is an important groving market, we are close to running out of IPv4 addresses. If every Chinese would ever use a mobile phone with an IP stack, there is not enough IPv4 addresses for them. It is therefore clear that some countries are more pushing for IPv6 than the others. Thus, any estimation should take into consideration more political and "geographic" criterias and not only be based on the allowable number of address vs to the number of addresses currently in use. Hope this helps. Thierry. -------------------------------------------------------------------- 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 Apr 30 04:02:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UB2LIM027970 for ; Mon, 30 Apr 2001 04:02:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UB2LqG027969 for ipng-dist; Mon, 30 Apr 2001 04:02:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UB2BIM027962 for ; Mon, 30 Apr 2001 04:02:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29283 for ; Mon, 30 Apr 2001 04:02:10 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA27143 for ; Mon, 30 Apr 2001 04:02:07 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id SAA19946; Mon, 30 Apr 2001 18:02:04 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f3UB22d01791; Mon, 30 Apr 2001 18:02:03 +0700 (ICT) From: Robert Elz To: Randy Bush cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-reply-to: Your message of "Mon, 30 Apr 2001 05:53:42 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Apr 2001 18:02:02 +0700 Message-ID: <1789.988628522@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 30 Apr 2001 05:53:42 +0200 From: Randy Bush Message-ID: | > on the contrary, there are wording for routing table size. | > as far as i understand IPv6 addressing plan as well as 6bone routing | > guideline solves this portion of the problem. | | unfortunately, operators seem unable to realize this. if there is the same | amount and trend of multi-homing, and the same routing protocols, and the | same mass of multiply-connected providers, their lack of perception would | seem to be understandable. Yes - we also need renumbering to work under IPv6 for the (current only) routing table growth size problem to be helped by IPv6. (That is, aside from the one time transitional help caused by everyone doing an initial renumber into a topologically sane address when they first start running IPv6). I have been trying to fathom what is going on with renumbering - there seems recently to have been some kind of "well, it turns out that we can't renumber an IPv6 network every day, and if we think about it, we'll never actually need to anyway, so we can stop worrying about renumbering". That's nonsense. Renumbering is still important, and still needs to become one of the main features of v6 - that we haven't actually achieved a lot yet just makes it even more urgent. We started real well, with autoconfiguration, so we don't have to go sticking a host's IPv6 addresses in a config file on every host (or DHCP server). That's all implemented everywhere I know of, works fine, ... Then we went a bit further with router renumbering, to provide a mechanism to get a renumbering event distributed to the routers of an organisation more seamlessly - that's newer, but is still not a lot implemented that I'm aware of (though unless we're all unlucky, it should be coming). Then we have giant setbacks, like the "embedding IPv6 literals in URLs" nonsense, that is 100% the wrong thing to be doing if we want to be able to change the addresses in any kind of reasonable way. It seems that some people have looked at the renumbering problem, decided that it is still real hard (it is), and thought "if I just get a stable IPv6 address and keep it forever, I'll never have to worry about that". Hence we're still occasionally seeing calls for portable IPv6 addresses. If that was to be the result, then we need (very very quickly) some entirely new routing methodology which will solve the routing table growth problems (for which "buy more RAM" is not even half a solution of course). Or, we need to keep working on the renumbering problem - keep finding little pieces of what makes it difficult, and fixing them, until it is no longer so difficult. One step at a time... Intrinsically it can't be difficult after all, we can take a network with no number, and give it one, and start using the thing very easily. So the problems that exist cannot be intractable, provided we're willing to take a pragmatic approach, and be willing to change some of our current behaviour (like embedding literal addresses all over the place - including in URLs). Of course, whatever solutions we find for this for IPv6 would also be applicable to IPv4 in most cases - except that IPv4 still has the address size limitations. Finally, everyone please recall to pieces of ancient history. First, rfc1900 (from 1996, which remains as true today as it did then). And second, that before IPngwg, before the SIP PIP and TUBA wg's, was the ROAD wg - that which set all of this in motion. ROAD was "Routing and Addressing" - the two problems that needed solving. We haven't finished until both of those have been ticked off. kre ps: A6 is just one more minor step in making renumbering just that little bit easier - or will be, once we demonstrate that it really does work, and start deploying it in some form or other. -------------------------------------------------------------------- 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 Apr 30 05:21:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UCL7IM028113 for ; Mon, 30 Apr 2001 05:21:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UCL7Ih028112 for ipng-dist; Mon, 30 Apr 2001 05:21:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UCKwIM028105 for ; Mon, 30 Apr 2001 05:20:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23871 for ; Mon, 30 Apr 2001 05:20:57 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27788 for ; Mon, 30 Apr 2001 05:20:55 -0700 (PDT) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA05423 for ; Mon, 30 Apr 2001 13:20:54 +0100 (BST) Received: from penelope (penelope.ecs.soton.ac.uk [152.78.68.135]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA11429 for ; Mon, 30 Apr 2001 13:20:54 +0100 (BST) Date: Mon, 30 Apr 2001 13:20:54 +0100 (BST) From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: <1789.988628522@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 30 Apr 2001, Robert Elz wrote: > Then we have giant setbacks, like the "embedding IPv6 literals in URLs" > nonsense, that is 100% the wrong thing to be doing if we want to be able > to change the addresses in any kind of reasonable way. In some cases, a site's IP numbering is likely to remain quite static for significant periods of time. My University has been on the same 16-bit network (152.78.0.0) for at least ten years, and I don't see that that will change in the foreseeable future. That's a site with ~10K IP-connected devices, using pretty much every host OS you could imagine. The biggest problem with renumbering comes with the subtle, yet large, number of places that IP addresses are hard coded in various config files on Unix/NT systems. That's a significant problem to overcome. But luckily it's not a problem we're likely to face. Aside from the little issue of IPv6 migration :-) As a side-line I run a small ISP, and that's where the renumbering problem kicks in, because I want to get the best leased line deal that I can on an annual basis, but I don't have the leverage to demand to take my Class C with me to a new provider (nor should I) as I probably could with a Class B size address. The providers know that the cost of moving to a new provider is high, because of renumbering. As a result, I get quite tempted to run 1:1 NAT, simply to make moving to a new provider easier. I haven't done that, but I expect many small ISPs do. If application (and firewall) developers don't reduce the dependency on hard-coded IP addresses, then it's probable that some form of IPv6 NAT will be used to map site-locals when IPv6 comes into common usage, as horrific as that may sound to some. And if a University-scale site did renumber, I shudder to think of the number of places that IPs would be embedded, and the manpower cost of renumbering, even with A6, autoconfiguration and secure router renumbering. 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 Mon Apr 30 05:44:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UCi9IM028178 for ; Mon, 30 Apr 2001 05:44:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UCi9X2028177 for ipng-dist; Mon, 30 Apr 2001 05:44:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UChxIM028170 for ; Mon, 30 Apr 2001 05:44:00 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13492 for ; Mon, 30 Apr 2001 05:44:01 -0700 (PDT) Received: from TWNT01.teleware.fi (mail.teleware.fi [193.65.76.33]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23788 for ; Mon, 30 Apr 2001 05:43:59 -0700 (PDT) Received: by TWNT01.teleware.fi with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Apr 2001 15:43:58 +0300 Message-ID: <20E5886B5437D511A2AC005004992A710356B9@twnt0.teleware.fi> From: Anssi Porttikivi To: "'Linda Olofsson Hoff'" Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv4-addresses Date: Mon, 30 Apr 2001 16:44:53 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Linsda, start with this excellent article: BGP-system usage of 32 bit Internet address space http://moat.nlanr.net/IPaddrocc/ And here is an informative and insightful mail message which speaks on the subject: John Gilmore: "IP address space allocation: not a crisis, let's lighten up" http://www.icann.org/comments-mail/comment-aso/msg00027.html Ceterum censeo we need a higher level (transport level / socket level) binary protocol which runs transparently on top of different network level standards. Thus we get rid of the requirement for a one and only low level (network level) standard. See Plan 9 and Inferno 9P/2000P protocols for how to do this right (essentially UUCP as the next millennium version). They have a perfect candidate of a protocol that would work both as a high level distributed object access standard (including file access) AND as link layer abstraction standard. Network layer would not be needed, we would use what would be essentially "source routing", maybe combined with a distributed UUCP pathalias like "router server" mechanism. See http://plan9.bell-labs.com/magic/man2html/5/0intro -----Original Message----- From: Linda Olofsson Hoff [mailto:is98lho@student.hk-r.se] Sent: 24. huhtikuuta 2001 18:49 To: ipng@sunroof.eng.sun.com Subject: IPv4-addresses Hi! My name is Linda and I am writing a thesis about IPv6 and I am wondering if you've made some investigation/estimation about when we are out of IPv4 addresses? Magazines report different numbers but do not tell why and they doesn't direct to any examination. Can you help me? Grateful for answers! Linda from Sweden -------------------------------------------------------------------- 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 Mon Apr 30 05:55:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UCthIM028206 for ; Mon, 30 Apr 2001 05:55:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UCthWK028205 for ipng-dist; Mon, 30 Apr 2001 05:55:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UCtXIM028198 for ; Mon, 30 Apr 2001 05:55:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10635 for ; Mon, 30 Apr 2001 05:55:35 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26058 for ; Mon, 30 Apr 2001 05:55:32 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id TAA23467; Mon, 30 Apr 2001 19:55:30 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f3UCtRd02200; Mon, 30 Apr 2001 19:55:30 +0700 (ICT) From: Robert Elz To: Tim Chown cc: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-reply-to: Your message of "Mon, 30 Apr 2001 13:20:54 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Apr 2001 19:55:27 +0700 Message-ID: <2198.988635327@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 30 Apr 2001 13:20:54 +0100 (BST) From: Tim Chown Message-ID: | In some cases, a site's IP numbering is likely to remain quite static for | significant periods of time. Yes, it is. | My University has been on the same 16-bit network (152.78.0.0) for | at least ten years, My (home) university has been using its class B for longer than that (it is a 128.x number ...) and it will never change while IPv4 remains. Yet we have altered providers several times through history, and will do so again for sure. That means that the whole rest of the Internet universe (except those who use default routes for most routing) have to carry around a route to our network (and yours), and then go and recompute the routing table every time some glitch drops one of us off the network for a few minutes (or just changes the path by which we're reached). I'm not sure that it is reasonable for even a large university to impose that kind of burden on the rest of the world. With IPv4 it is never going to change of course, but IPv4 simply has to die sometime (it doesn't have enough addresses even if everyone was using NAT for their networks, 2^32 isn't sufficient just to number all the NAT boxes that the world will need sometime in the future). | The biggest problem with renumbering comes | with the subtle, yet large, number of places that IP addresses are hard | coded in various config files on Unix/NT systems. No, that's the small problem. It is a nuisance, and a lot of work, but is comparatively easy to fix ... you just renumber each box, one at a time, and keep working at it until it works - then go on to the next. Costly, but possible. The big problem is that it is entirely possible that I have either your old, or your new, IP address in my router filter lists, or e-mail anti-spam lists, or ... When you renumber your network, I have to adjust the configuration at my end - and you know nothing about that at all (so you can't tell me it is time to update my config) and I of course have no rational way to find out that you have renumbered (there are plenty of numbers in my router config lists that I never knew who they belonged to, so I can't just look and see if they have changed owners). I have already seen an experience from one user who found their IP address was one one of (the more incompetent of) the anti-spam lists. They had no idea why, having only just recently connected to the net, and never having run an open relay or anything like that. Never thought that perhaps the number had been used by someone else in the past. (This case turned out to be worse than that - turned out the ISP was doing NAT without telling anyone, so the number that was being blocked wasn't the actual number the user thought he was using (which wasn't a 1918 number), but the public side of the NAT box - which was also doing port remapping, so the IP address being blocked was being shared by who knows how many users). | As a side-line I run a small ISP, and that's where the renumbering problem | kicks in, because I want to get the best leased line deal that I can on | an annual basis, but I don't have the leverage to demand to take my | Class C with me to a new provider (nor should I) as I probably could with | a Class B size address. The providers know that the cost of moving to a | new provider is high, because of renumbering. Yes. | As a result, I get quite tempted to run 1:1 NAT, simply to make moving to a | new provider easier. A lot of people do exactly that. Of course they can also justify it on the grounds of insufficient available address space. It is truly unfortunate that (I suspect) perhaps a majority of the current internet users have never used a NAT free connection. | If application (and firewall) developers don't reduce the dependency on | hard-coded IP addresses, then it's probable that some form of IPv6 NAT will | be used to map site-locals when IPv6 comes into common usage, as horrific | as that may sound to some. Yes, it is a frightening but real prospect - though I doubt site-locals would turn out to be useful for that (nodes will only use them when sending to other site locals). More likely that sites would simply invent a private global address for themselves, then remap it into their provider supplied address. Horrible thought. Unfortunately, it is likely to happen (probably has already happened) - people have become so used to NAT that it is often seen as a feature, rather than the crude hack that breaks things which it is. Of course, none of this NAT renumbering solves the difficult problem I mentioned above - even if all you have to renumber is your NAT box, my config files still contain addresses that should be changed, that you don't know about. So your cost might decrease a bit (or a lot), but the renumbering isn't really finished. | And if a University-scale site did renumber, I shudder to think of the | number of places that IPs would be embedded, and the manpower cost of | renumbering, even with A6, autoconfiguration and secure router renumbering. Yes - we really need string pressure on implementors at all levels of the stack to avoid using literal addresses anyplace they can possibly be avoided, and instead use a dynamic translation mechanism - for everything, with perhaps the sole exception of an address that a human has actually typed immediately before it is used, and of course, the assignment of TLAs. 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 Mon Apr 30 07:52:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UEqZIM028670 for ; Mon, 30 Apr 2001 07:52:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UEqZV6028669 for ipng-dist; Mon, 30 Apr 2001 07:52:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UEqPIM028662 for ; Mon, 30 Apr 2001 07:52:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27079 for ; Mon, 30 Apr 2001 07:52:26 -0700 (PDT) Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11251 for ; Mon, 30 Apr 2001 07:52:24 -0700 (PDT) Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uF1L-00019X-00; Mon, 30 Apr 2001 16:51:27 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing References: <1789.988628522@brandenburg.cs.mu.OZ.AU> Message-Id: Date: Mon, 30 Apr 2001 16:51:27 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> on the contrary, there are wording for routing table size. >>> as far as i understand IPv6 addressing plan as well as 6bone routing >>> guideline solves this portion of the problem. >>unfortunately, operators seem unable to realize this. if there is the same >>amount and trend of multi-homing, and the same routing protocols, and the >>same mass of multiply-connected providers, their lack of perception would >>seem to be understandable. > Yes - we also need renumbering to work under IPv6 for the (current only) > routing table growth size problem to be helped by IPv6. renumbering? did i say renumbering? i sure did not mean to. as far as i can tell, ipv6 gives us more address bits, and not a lot else, in fact some regressive limits. but we could need more address bits very badly. and we don't have a better plan. randy -------------------------------------------------------------------- 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 Apr 30 08:10:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UFAIIM028713 for ; Mon, 30 Apr 2001 08:10:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UFAIH0028712 for ipng-dist; Mon, 30 Apr 2001 08:10:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UFA8IM028705 for ; Mon, 30 Apr 2001 08:10:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00634 for ; Mon, 30 Apr 2001 08:10:04 -0700 (PDT) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01670 for ; Mon, 30 Apr 2001 09:26:59 -0600 (MDT) Received: from localhost (orange.kame.net [203.178.141.194]) by orange.kame.net (8.9.3+3.2W/3.7W) with ESMTP id AAA89375; Tue, 1 May 2001 00:08:18 +0900 (JST) Date: Sat, 28 Apr 2001 15:26:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Richard Draves" Cc: Subject: Re: more comments (questions) aboutdraft-draves-ipngwg-router-selection-01.txt In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA81C9CC0@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA81C9CC0@red-msg-06.redmond.corp.microsoft.com> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 39 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 26 Apr 2001 21:10:03 -0700, >>>>> "Richard Draves" said: >> 1. what should a host do when it receives an RA with the preference >> field being set to 10 (i.e. reserved)? >> - ignore the entire RA. >> - accept the RA, but consider the preference value as >> another value? >> if so, high/medium/low? >> - other option? > How about, treat the RA as if the RouterLifetime field is zero. I think > this will produce the best compatibility with future use of the reserved > preference value. Hmm, but, if all routers in a segment specify the reserved value, then a host (which supports the router preference field, but does not understand the reserved value yet) would never be able to make off-link communications. I don't think it's a happy story. (Ignoring the RA would also be a bad choice for the same reason.) >> 2. if the preference value for a router changes, does/should it >> affect existing destination cache entries? > I think this is a quality of implementation issue that can be left > unspecified. > My implementation will invalidate the destination cache appropriately > when the routing table changes. Okay, I don't mind to leave it unspecified, but it would be better to mention the issue in the draft anyway. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Apr 30 09:25:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UGPSIM028873 for ; Mon, 30 Apr 2001 09:25:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UGPRD9028872 for ipng-dist; Mon, 30 Apr 2001 09:25:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UGPIIM028865 for ; Mon, 30 Apr 2001 09:25:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18415 for ; Mon, 30 Apr 2001 09:25:15 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12147 for ; Mon, 30 Apr 2001 09:25:12 -0700 (PDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 30C271774; Mon, 30 Apr 2001 09:25:12 -0700 (PDT) Date: Mon, 30 Apr 2001 09:25:12 -0700 From: David Terrell To: Masataka Ohta Cc: "D. J. Bernstein" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing Message-ID: <20010430092511.A591@pianosa.catch22.org> Reply-To: David Terrell References: <20010430060710.18274.qmail@cr.yp.to> <200104300916.SAA06619@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200104300916.SAA06619@necom830.hpcl.titech.ac.jp>; from mohta@necom830.hpcl.titech.ac.jp on Mon, Apr 30, 2001 at 06:16:21PM +0859 X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 9:21AM up 49 days, 8:26, 21 users, load averages: 0.34, 0.25, 0.17 X-Baby: Theodore Marvin Wolpinsky Terrell born 61 days, 18 hours, 35 minutes, 44 seconds ago Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Apr 30, 2001 at 06:16:21PM +0859, Masataka Ohta wrote: > Dan; > > It's your problem. > > > Paul A Vixie writes: > > > i have not, yet, heard anything new against A6 in this round of the debate. > > > > http://cr.yp.to/djbdns/killa6.html > > How about: > > aol.com. NS ns0.aol.net. > aol.com. NS ns1.aol.net. > > aol.net. NS ns0.aol.com. > aol.net. NS ns1.aol.com. > > ? In this case, ns[01].aol.{net,com} will be in the {net,com} zones as glue. I think the question that I have yet to see answered that Dan is not articulating well is "how the hell is DNS glue supposed to work sanely with A6?" I can't find an answer to that myself. Everybody's talking about no full IP addresses written anywhere, and DNS delegation is one place where that just doesn't work. You need the full 128 bit address in there, and glue registry is the one place that these addresses can't change frequently, because of the bulk of TLD zones and complicated, time consuming procedures registrars use to update those records... -- David Terrell | "I went into Barnes and Noble to look for a Prime Minister, Nebcorp | book on A.D.D., but I got bored and left." dbt@meat.net | - Benjy Feen http://wwn.nebcorp.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 Apr 30 09:50:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UGoFIM028946 for ; Mon, 30 Apr 2001 09:50:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UGoFun028945 for ipng-dist; Mon, 30 Apr 2001 09:50:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UGo2IM028938 for ; Mon, 30 Apr 2001 09:50:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21839 for ; Mon, 30 Apr 2001 09:50:02 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06920 for ; Mon, 30 Apr 2001 09:50:02 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id LAA13142; Mon, 30 Apr 2001 11:49:51 -0500 (CDT) Message-Id: <200104301649.LAA13142@gungnir.fnal.gov> To: David Terrell Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: AAAA/A6 thing In-reply-to: Your message of Mon, 30 Apr 2001 09:25:12 PDT. <20010430092511.A591@pianosa.catch22.org> Date: Mon, 30 Apr 2001 11:49:51 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think the question that I have yet to see answered that Dan is > not articulating well is "how the hell is DNS glue supposed to work > sanely with A6?" I can't find an answer to that myself. Everybody's > talking about no full IP addresses written anywhere, Whoa! Who is this "everybody"? > and DNS delegation is one place where that just doesn't work. You > need the full 128 bit address in there, and glue registry is the > one place that these addresses can't change frequently, because of > the bulk of TLD zones and complicated, time consuming procedures > registrars use to update those records... I think you aren't intending to make a case in favor of well- segemented A6 chains, but your ellipsis could be completed in exactly that way. Then if you the end site choose to renumber, you're responsible for coordinating the TLD's glue. If renumbering is thrust upon you because your ISP is renumbering, they are responsible for it. And if the glue record of concern is the very same one they use for their own DNS infrastructure, the right sort of motivations are in place. But never mind that, because the world isn't ready to play that way and it isn't what RFC 2874, section 5.1.2 suggests: 5.1.2. Glue When, as is common, some or all DNS servers for X.EXAMPLE are within the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry enough "glue" information to enable DNS clients to reach those nameservers. This is true in IPv6 just as in IPv4. However, the A6 record affords the DNS administrator some choices. The glue could be any of o a minimal set of A6 records duplicated from the X.EXAMPLE zone, o a (possibly smaller) set of records which collapse the structure of that minimal set, o or a set of A6 records with prefix length zero, giving the entire global addresses of the servers. The trade-off is ease of maintenance against robustness. The best and worst of both may be had together by implementing either the first or second option together with the third. To illustrate the ... If the EXAMPLE zone includes redundant glue, for instance the union of the A6 records of the first and third options, then under normal circumstances duplicate IPv6 addresses will be derived by DNS clients. But if provider DNS fails, addresses will still be obtained from the zero-prefix-length records, while if the EXAMPLE zone lags behind a renumbering of X.EXAMPLE, half of the addresses obtained by DNS clients will still be up-to-date. The zero-prefix-length glue records can of course be automatically generated and/or checked in practice. -------------------------------------------------------------------- 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 Apr 30 10:19:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UHJSIM029042 for ; Mon, 30 Apr 2001 10:19:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UHJS2K029041 for ipng-dist; Mon, 30 Apr 2001 10:19:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UHJNIM029034 for ; Mon, 30 Apr 2001 10:19:24 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f3UHFxX01121 for ipng@sunroof.eng.sun.com; Mon, 30 Apr 2001 10:15:59 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3RDr7IM023800 for ; Fri, 27 Apr 2001 06:53:08 -0700 (PDT) Received: from quasimodo.east.sun.com (quasimodo.East.Sun.COM [129.148.174.94]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07931; Fri, 27 Apr 2001 09:52:56 -0400 (EDT) From: sowmini@quasimodo.east.sun.com Received: (from sowmini@localhost) by quasimodo.east.sun.com (8.9.3+Sun/8.9.3) id JAA06088; Fri, 27 Apr 2001 09:52:52 -0400 (EDT) Date: Fri, 27 Apr 2001 09:52:52 -0400 (EDT) Message-Id: <200104271352.JAA06088@quasimodo.east.sun.com> To: alain.ritoux@6wind.com, itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> case 1: consider link local address (La and Lb). > >> > >> A (La) --- (Lb) B > >> > >> A has fe80::/10 (or fe80::/64 depending on your implementation) > >> route pointed to the p2p link. if A emits a packet with Lx (!= Lb) as a > >> destination, it will reach B. then B forwards it back to A. then A forwards > >> it back to B, ... until hoplimit field goes 0. also, they would emit > >> ICMPv6 redirect to the peer, since the packet gets forwarded back again to the > >> incoming interface. > >Well if Lx is link-local, it should not bie forwarded at all ? > > in the existing RFCs, there's no wording that forbids forwarding > packets to link local address, **given that we forward it back to the > same link**. A and B are forwarding packets back to the same link. > > we cannot forward packets with linklocal address across different > links. this part is clear but we are not talking about this. In the case of link-local addresses, I think that the packet should only be forwarded once across the p2p link- when the hop limit goes below 255, it shouldn't get forwarded back? However, I think the bouncing-back-and-forth situation could still occur if there were 2 routers connected by a p2p link, each advertising its own onlink prefix for the link, e.g., R1 advertising P1::/64, R2 advertising P2::/64, and then R2 sends a packet to ip6_dst P1::1 to be forwarded by R1.. --Sowmini -------------------------------------------------------------------- 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 Apr 30 10:43:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UHhXIM029194 for ; Mon, 30 Apr 2001 10:43:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UHhXGk029193 for ipng-dist; Mon, 30 Apr 2001 10:43:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UHhNIM029186 for ; Mon, 30 Apr 2001 10:43:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05930 for ; Mon, 30 Apr 2001 10:43:23 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA14385 for ; Mon, 30 Apr 2001 10:43:18 -0700 (PDT) Received: from 157.54.9.104 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 30 Apr 2001 10:22:18 -0700 (Pacific Daylight Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 30 Apr 2001 10:21:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: more comments (questions)aboutdraft-draves-ipngwg-router-selection-01.txt Date: Mon, 30 Apr 2001 10:21:34 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9CCB@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: more comments (questions)aboutdraft-draves-ipngwg-router-selection-01.txt Thread-Index: AcDRh2vP+DYGhp+PQCGkrmJGclUfyQAEhRuA From: "Richard Draves" To: "JINMEI Tatuya / ????" Cc: X-OriginalArrivalTime: 30 Apr 2001 17:21:34.0634 (UTC) FILETIME=[017A60A0:01C0D19A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3UHhOIM029187 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> 1. what should a host do when it receives an RA with the > preference > >> field being set to 10 (i.e. reserved)? > >> - ignore the entire RA. > >> - accept the RA, but consider the preference value as > >> another value? > >> if so, high/medium/low? > >> - other option? > > > How about, treat the RA as if the RouterLifetime field is zero. I > > think this will produce the best compatibility with future > use of the > > reserved preference value. > > Hmm, but, if all routers in a segment specify the reserved > value, then a host (which supports the router preference > field, but does not understand the reserved value yet) would > never be able to make off-link communications. I don't think > it's a happy story. (Ignoring the RA would also be a bad > choice for the same reason.) My assumption is that if the reserved value is ever used, it will be to define a "black-hole" preference value that means "do not send packets to me". (I believe it was Robert Elz who suggested this.) So then for the default route, there isn't too much difference between a zero RouterLifetime and the "black hole" preference value. Do you have some other possible future use in mind for the reserved value? Thanks, Rich -------------------------------------------------------------------- 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 Apr 30 10:53:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UHrYIM029235 for ; Mon, 30 Apr 2001 10:53:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UHrY0h029234 for ipng-dist; Mon, 30 Apr 2001 10:53:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UHrOIM029227 for ; Mon, 30 Apr 2001 10:53:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23136 for ; Mon, 30 Apr 2001 10:53:19 -0700 (PDT) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14218 for ; Mon, 30 Apr 2001 12:12:28 -0600 (MDT) Received: from localhost (orange.kame.net [203.178.141.194]) by orange.kame.net (8.9.3+3.2W/3.7W) with ESMTP id CAA19069; Tue, 1 May 2001 02:53:04 +0900 (JST) Date: Tue, 01 May 2001 02:52:11 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Richard Draves" Cc: Subject: Re: more comments (questions)aboutdraft-draves-ipngwg-router-selection-01.txt In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA81C9CCB@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA81C9CCB@red-msg-06.redmond.corp.microsoft.com> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 32 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 30 Apr 2001 10:21:34 -0700, >>>>> "Richard Draves" said: >> > How about, treat the RA as if the RouterLifetime field is zero. I >> > think this will produce the best compatibility with future >> use of the >> > reserved preference value. >> >> Hmm, but, if all routers in a segment specify the reserved >> value, then a host (which supports the router preference >> field, but does not understand the reserved value yet) would >> never be able to make off-link communications. I don't think >> it's a happy story. (Ignoring the RA would also be a bad >> choice for the same reason.) > My assumption is that if the reserved value is ever used, it will be to > define a "black-hole" preference value that means "do not send packets > to me". (I believe it was Robert Elz who suggested this.) So then for > the default route, there isn't too much difference between a zero > RouterLifetime and the "black hole" preference value. > Do you have some other possible future use in mind for the reserved > value? I don't know, but if this (i.e. a "black-hole" preference) is the only possibility, why don't you just define it in the (next revision of) the draft? It would ensure the best (future) interoperability. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Apr 30 11:31:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UIVcIM029432 for ; Mon, 30 Apr 2001 11:31:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UIVYc5029431 for ipng-dist; Mon, 30 Apr 2001 11:31:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UIVIIM029424 for ; Mon, 30 Apr 2001 11:31:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03107 for ; Mon, 30 Apr 2001 11:31:15 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA10784 for ; Mon, 30 Apr 2001 11:31:11 -0700 (PDT) Received: from 157.54.9.100 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 30 Apr 2001 11:30:24 -0700 (Pacific Daylight Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 30 Apr 2001 11:30:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: more comments(questions)aboutdraft-draves-ipngwg-router-selection-01.txt Date: Mon, 30 Apr 2001 11:30:25 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8024EF541@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: more comments(questions)aboutdraft-draves-ipngwg-router-selection-01.txt Thread-Index: AcDRnnI6T+DfSao9QCKc39lBsKtkigABR5mg From: "Richard Draves" To: "JINMEI Tatuya / ????" Cc: X-OriginalArrivalTime: 30 Apr 2001 18:30:26.0218 (UTC) FILETIME=[A01810A0:01C0D1A3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f3UIVMIM029425 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't know, but if this (i.e. a "black-hole" preference) is > the only possibility, why don't you just define it in the > (next revision of) the draft? It would ensure the best > (future) interoperability. Because defining and implementing it properly is complicated, and it's not clear if it's worth the trouble. Rich -------------------------------------------------------------------- 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 Apr 30 11:45:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UIjvIM029461 for ; Mon, 30 Apr 2001 11:45:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UIjuIl029460 for ipng-dist; Mon, 30 Apr 2001 11:45:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UIjkIM029453 for ; Mon, 30 Apr 2001 11:45:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23242 for ; Mon, 30 Apr 2001 11:45:46 -0700 (PDT) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18510 for ; Mon, 30 Apr 2001 11:45:44 -0700 (PDT) Received: from localhost (orange.kame.net [203.178.141.194]) by orange.kame.net (8.9.3+3.2W/3.7W) with ESMTP id DAA19657; Tue, 1 May 2001 03:45:39 +0900 (JST) Date: Tue, 01 May 2001 03:44:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Richard Draves" Cc: Subject: Re: more comments(questions)aboutdraft-draves-ipngwg-router-selection-01.txt In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA8024EF541@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA8024EF541@red-msg-06.redmond.corp.microsoft.com> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 30 Apr 2001 11:30:25 -0700, >>>>> "Richard Draves" said: >> I don't know, but if this (i.e. a "black-hole" preference) is >> the only possibility, why don't you just define it in the >> (next revision of) the draft? It would ensure the best >> (future) interoperability. > Because defining and implementing it properly is complicated, and it's > not clear if it's worth the trouble. Then I'd suggest to add the following logic to the draft. a host should treat an RA with the reserved preference as if it has the 0 router lifetime field, because the only known possibility of the usage of the reserved value is a "black-hole" preference. but the current draft does not specify the semantics, because ... (your rationale). To insure future interoperability, the reserved value should not be used with other semantics than a kind of the "black-hole" preference. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Apr 30 11:53:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UIrgIM029486 for ; Mon, 30 Apr 2001 11:53:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UIrfin029485 for ipng-dist; Mon, 30 Apr 2001 11:53:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UIrVIM029478 for ; Mon, 30 Apr 2001 11:53:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09347 for ; Mon, 30 Apr 2001 11:53:25 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA00269 for ; Mon, 30 Apr 2001 13:11:54 -0600 (MDT) Received: from drc-toshiba.nominum.com (shell.nominum.com [204.152.187.59]) by shell.nominum.com (Postfix) with ESMTP id 445F83190C; Mon, 30 Apr 2001 11:51:42 -0700 (PDT) Message-Id: <5.0.2.1.2.20010430113834.030a9578@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 30 Apr 2001 11:51:45 -0700 To: itojun@iijlab.net, Paul A Vixie From: "David R. Conrad" Subject: Re: AAAA/A6 thing Cc: ipng@sunroof.eng.sun.com In-Reply-To: <10857.988596314@itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, At 11:05 AM 4/30/2001 +0900, itojun@iijlab.net wrote: > on the contrary, there are wording for routing table size. Renumbering is a means to address the routing table size problem (of course, renumbering doesn't help the multi-homing problem). > as far as i understand IPv6 addressing plan as well as 6bone routing > guideline solves this portion of the problem. My understanding is that IPv6 uses the same routing technology as IPv4 and is only marginally easier to renumber than IPv4, hence the routing table problem is not addressed. Rgds, -drc -------------------------------------------------------------------- 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 Apr 30 12:09:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UJ9hIM029510 for ; Mon, 30 Apr 2001 12:09:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3UJ9g9S029509 for ipng-dist; Mon, 30 Apr 2001 12:09:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UJ9UIM029502 for ; Mon, 30 Apr 2001 12:09:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29606 for ; Mon, 30 Apr 2001 12:09:29 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA10730 for ; Mon, 30 Apr 2001 12:09:27 -0700 (PDT) Received: (qmail 6887 invoked by uid 1001); 30 Apr 2001 19:09:48 -0000 Date: 30 Apr 2001 19:09:48 -0000 Message-ID: <20010430190948.19724.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <20010430060710.18274.qmail@cr.yp.to> <200104300916.SAA06619@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ohta is wrong. This is a bug in the protocol, not in any particular implementation. All of my comments apply to BIND's A6 implementation; BIND discards out-of-bailiwick records for security, just as djbdns does. Ohta's ``fix'' comments are nonsense. As for non-A6 examples: http://cr.yp.to/djbdns/killa6.html already covers this, and explains why A6 and DNAME make the problem much worse. See the ``DNS reliability problems'' section. ---Dan -------------------------------------------------------------------- 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 Apr 30 14:20:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3ULKLIM029613 for ; Mon, 30 Apr 2001 14:20:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f3ULKLU4029612 for ipng-dist; Mon, 30 Apr 2001 14:20:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3ULKBIM029605 for ; Mon, 30 Apr 2001 14:20:12 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08488 for ; Mon, 30 Apr 2001 14:20:13 -0700 (PDT) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA04105 for ; Mon, 30 Apr 2001 14:20:11 -0700 (PDT) Received: from vaio (as1-52.chi.il.dial.anet.com [198.92.156.52]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id QAA05175; Mon, 30 Apr 2001 16:20:07 -0500 (CDT) Message-ID: <01b301c0d1ba$cde60520$df00a8c0@vaio> From: "JIM FLEMING" To: Cc: References: <5.0.2.1.2.20010430113834.030a9578@localhost> Subject: Re: AAAA/A6 thing Date: Mon, 30 Apr 2001 16:16:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "David R. Conrad" > > My understanding is that IPv6 uses the same routing technology as IPv4 IPv4 and IPv6 do not do "routing" they do "forwarding"... ...some people know the difference... Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp -------------------------------------------------------------------- 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 Apr 30 17:24:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f410OtIM029891 for ; Mon, 30 Apr 2001 17:24:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f410OtxS029890 for ipng-dist; Mon, 30 Apr 2001 17:24:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f410OSIM029883 for ; Mon, 30 Apr 2001 17:24:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22935 for ; Mon, 30 Apr 2001 17:24:27 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19494 for ; Mon, 30 Apr 2001 17:24:25 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E231F4B0B; Tue, 1 May 2001 09:24:18 +0900 (JST) To: "Richard Draves" Cc: "Robert Elz" , ipng@sunroof.eng.sun.com In-reply-to: richdr's message of Thu, 26 Apr 2001 23:14:00 MST. <7695E2F6903F7A41961F8CF888D87EA81C9CC4@red-msg-06.redmond.corp.microsoft.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: nonexisting destination on p2p link From: itojun@iijlab.net Date: Tue, 01 May 2001 09:24:18 +0900 Message-ID: <21234.988676658@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> when there's no link layer address (imagine tunnel interfaces), >> there's no proper NS (packets go out without NS-NA exchange), however, >> NUD hapens. is my understanding right? >The MS implementation works that way. For a p2p interface, we create the >neighbor cache entry in the stale state (since we know the link-layer >address a priori), but then NUD can operate. > >Here's another scenario along these lines: assign a /64 to a p2p link >between two routers. Now someone sends a packet to an address in the >/64, but the address is not assigned to either router. The routers will >forward the packet back & forth until the hop limit hits zero. This will >happen before NUD has a chance to kick in. > >I agree with itojun, better to generate a >destination-unreachable/address-unreachable error instead of forwarding >a packet back out the p2p interface from which it arrived. once we can make some agreement on the error code, i can write up a draft/a fragment to be added to the existing draft. at this moment kame test code uses ICMP6_DST_UNREACH/ ICMP6_DST_UNREACH_NOROUTE, but i think ICMP6_DST_UNREACH_ADDR is better. itojun -------------------------------------------------------------------- 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 Apr 30 17:38:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f410ckIM029913 for ; Mon, 30 Apr 2001 17:38:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f410cj73029912 for ipng-dist; Mon, 30 Apr 2001 17:38:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f410cLIM029902 for ; Mon, 30 Apr 2001 17:38:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15873 for ; Mon, 30 Apr 2001 17:38:19 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25450 for ; Mon, 30 Apr 2001 17:38:18 -0700 (PDT) From: Masataka Ohta Message-Id: <200105010032.JAA08512@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA08512; Tue, 1 May 2001 09:32:16 +0900 Subject: Re: AAAA/A6 thing In-Reply-To: from "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" at "Apr 30, 2001 05:08:40 pm" To: "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" Date: Tue, 1 May 2001 09:32:15 +0859 () CC: "'David Terrell'" , "D. J. Bernstein" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ebi; > hi, > > Is there any alternate solution to A6 record > being looked at ? Something which lies somewhere > in between AAAA and A6. A6 is as good as NS. All you need is an alternative implementation. Dan's one is broken. Paul's one was and may still be broken. 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 Mon Apr 30 19:06:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4126gIM029950 for ; Mon, 30 Apr 2001 19:06:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4126fU2029949 for ipng-dist; Mon, 30 Apr 2001 19:06:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4126TIM029942 for ; Mon, 30 Apr 2001 19:06:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12586 for ; Mon, 30 Apr 2001 19:06:30 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA25912 for ; Mon, 30 Apr 2001 19:06:29 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA13100; Mon, 30 Apr 2001 22:06:27 -0400 Date: Mon, 30 Apr 2001 22:06:27 -0400 (EDT) From: Jim Bound To: Tim Chown Cc: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, Good points. We have renumbering for the LAN. We have a way to renumber from the border routers within a domain. This will get us started for deployment. Baby steps are all we can take. If the IETF can extend these to grown-up steps great. But we will start deployment now with what we got and its already better than IPv4. I would think someone should put out a draft on all this and state whats missing and what needs to be done. What will not get done here is to get users to not embed addresses in configs and there is no incentive for vendors to prevent them from doing it. regards, /jim On Mon, 30 Apr 2001, Tim Chown wrote: > On Mon, 30 Apr 2001, Robert Elz wrote: > > > Then we have giant setbacks, like the "embedding IPv6 literals in URLs" > > nonsense, that is 100% the wrong thing to be doing if we want to be able > > to change the addresses in any kind of reasonable way. > > In some cases, a site's IP numbering is likely to remain quite static for > significant periods of time. My University has been on the same 16-bit > network (152.78.0.0) for at least ten years, and I don't see that that > will change in the foreseeable future. > > That's a site with ~10K IP-connected devices, using pretty much every > host OS you could imagine. The biggest problem with renumbering comes > with the subtle, yet large, number of places that IP addresses are hard > coded in various config files on Unix/NT systems. That's a significant > problem to overcome. But luckily it's not a problem we're likely to face. > Aside from the little issue of IPv6 migration :-) > > As a side-line I run a small ISP, and that's where the renumbering problem > kicks in, because I want to get the best leased line deal that I can on > an annual basis, but I don't have the leverage to demand to take my > Class C with me to a new provider (nor should I) as I probably could with > a Class B size address. The providers know that the cost of moving to a > new provider is high, because of renumbering. > > As a result, I get quite tempted to run 1:1 NAT, simply to make moving to a > new provider easier. I haven't done that, but I expect many small ISPs do. > If application (and firewall) developers don't reduce the dependency on > hard-coded IP addresses, then it's probable that some form of IPv6 NAT will > be used to map site-locals when IPv6 comes into common usage, as horrific > as that may sound to some. > > And if a University-scale site did renumber, I shudder to think of the > number of places that IPs would be embedded, and the manpower cost of > renumbering, even with A6, autoconfiguration and secure router renumbering. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Apr 30 19:07:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4127oIM029962 for ; Mon, 30 Apr 2001 19:07:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4127ob6029961 for ipng-dist; Mon, 30 Apr 2001 19:07:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4127dIM029954 for ; Mon, 30 Apr 2001 19:07:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27728 for ; Mon, 30 Apr 2001 19:07:39 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28875 for ; Mon, 30 Apr 2001 19:07:39 -0700 (PDT) Received: from onatopp.cisco.com (onatopp.cisco.com [198.135.0.157]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f41205j13096; Mon, 30 Apr 2001 19:00:05 -0700 (PDT) Received: (otroan@localhost) by onatopp.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA25829; Tue, 1 May 2001 03:00:00 +0100 (BST) X-Authentication-Warning: onatopp.cisco.com: otroan set sender to ot@cisco.com using -f To: "Richard Draves" Cc: , "Robert Elz" , Subject: Re: nonexisting destination on p2p link References: <7695E2F6903F7A41961F8CF888D87EA81C9CC4@red-msg-06.redmond.corp.microsoft.com> From: Ole Troan Date: 01 May 2001 03:00:00 +0100 In-Reply-To: "Richard Draves"'s message of "Thu, 26 Apr 2001 23:14:00 -0700" Message-ID: <7t5d79tomlb.fsf@onatopp.cisco.com> Lines: 30 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > when there's no link layer address (imagine tunnel interfaces), > > there's no proper NS (packets go out without NS-NA > > exchange), however, > > NUD hapens. is my understanding right? > > The MS implementation works that way. For a p2p interface, we create the > neighbor cache entry in the stale state (since we know the link-layer > address a priori), but then NUD can operate. > > Here's another scenario along these lines: assign a /64 to a p2p link > between two routers. Now someone sends a packet to an address in the > /64, but the address is not assigned to either router. The routers will > forward the packet back & forth until the hop limit hits zero. This will > happen before NUD has a chance to kick in. > > I agree with itojun, better to generate a > destination-unreachable/address-unreachable error instead of forwarding > a packet back out the p2p interface from which it arrived. I'm inclined to disagree. when pinging a local interface address for a p2p link, some IPv4 implementations send the ping out the link, and gets it back from the remote router, as a way of verifying connectivity. implementing your suggestion prevents the option of doing something similar for IPv6. let the packets bounce between the two routers for a while, in the end you'll get a time exceeded message anyway. /ot -------------------------------------------------------------------- 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 Apr 30 19:11:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412BhIM029975 for ; Mon, 30 Apr 2001 19:11:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f412BgUJ029974 for ipng-dist; Mon, 30 Apr 2001 19:11:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412BUIM029965 for ; Mon, 30 Apr 2001 19:11:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA07307 for ; Mon, 30 Apr 2001 19:11:30 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA23710 for ; Mon, 30 Apr 2001 20:32:20 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA20513; Mon, 30 Apr 2001 22:08:47 -0400 Date: Mon, 30 Apr 2001 22:08:47 -0400 (EDT) From: Jim Bound To: Randy Bush Cc: Robert Elz , itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy, You may be right you may be wrong. But IPv6 is going to start being deployed so we will find all this out real soon. Should be fun. I think we will be fine. You should come to one of the IPv6 summits and hear the Advantage discussion of IPv6 sometime. /jim On Mon, 30 Apr 2001, Randy Bush wrote: > >>> on the contrary, there are wording for routing table size. > >>> as far as i understand IPv6 addressing plan as well as 6bone routing > >>> guideline solves this portion of the problem. > >>unfortunately, operators seem unable to realize this. if there is the same > >>amount and trend of multi-homing, and the same routing protocols, and the > >>same mass of multiply-connected providers, their lack of perception would > >>seem to be understandable. > > Yes - we also need renumbering to work under IPv6 for the (current only) > > routing table growth size problem to be helped by IPv6. > > renumbering? did i say renumbering? i sure did not mean to. > > as far as i can tell, ipv6 gives us more address bits, and not a lot else, > in fact some regressive limits. but we could need more address bits very > badly. and we don't have a better plan. > > randy > -------------------------------------------------------------------- > 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 Mon Apr 30 19:15:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412FAIM000014 for ; Mon, 30 Apr 2001 19:15:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f412F9YY000013 for ipng-dist; Mon, 30 Apr 2001 19:15:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412F0IM000006 for ; Mon, 30 Apr 2001 19:15:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA07578 for ; Mon, 30 Apr 2001 19:15:00 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA28558 for ; Mon, 30 Apr 2001 19:14:59 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA15709; Mon, 30 Apr 2001 22:14:39 -0400 Date: Mon, 30 Apr 2001 22:14:39 -0400 (EDT) From: Jim Bound To: David Terrell Cc: Masataka Ohta , "D. J. Bernstein" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: <20010430092511.A591@pianosa.catch22.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Right or wrong. Paul's comment is valid. A6 will be deployed at least on BIND (well it is now actually) and on Microsofts DNS is my read. As one of the people to fund BIND future development and with others we believe it should not be implemented for greater than 3 levels of hierarchy till more testing and experimentation is done. But A6 will be shipped on the street and its a done deal. Do I like A6 no. Do I think a better solution exists yes. But do I advocate deployment of A6 yes. Why because its time to move forward. I also thought continuing private address space was a bad idea in v6. I still do. KNow what I hope to help build that feature in our products. The Internet is crumbling under to many NAT and VPN peek-a-boo packets and we need to get IPv6 on the street. It is happening now. Will happen a lot by the end of this year. U.S. may be last to do it but thats ok they will do it too eventually. The real work we can do is elsewhere now like Multihoming and MIPv6. regards, /jim On Mon, 30 Apr 2001, David Terrell wrote: > On Mon, Apr 30, 2001 at 06:16:21PM +0859, Masataka Ohta wrote: > > Dan; > > > > It's your problem. > > > > > Paul A Vixie writes: > > > > i have not, yet, heard anything new against A6 in this round of the debate. > > > > > > http://cr.yp.to/djbdns/killa6.html > > > > How about: > > > > aol.com. NS ns0.aol.net. > > aol.com. NS ns1.aol.net. > > > > aol.net. NS ns0.aol.com. > > aol.net. NS ns1.aol.com. > > > > ? > > In this case, ns[01].aol.{net,com} will be in the {net,com} zones as > glue. > > I think the question that I have yet to see answered that Dan is > not articulating well is "how the hell is DNS glue supposed to work > sanely with A6?" I can't find an answer to that myself. Everybody's > talking about no full IP addresses written anywhere, and DNS > delegation is one place where that just doesn't work. You need the > full 128 bit address in there, and glue registry is the one place > that these addresses can't change frequently, because of the bulk > of TLD zones and complicated, time consuming procedures registrars > use to update those records... > > -- > David Terrell | "I went into Barnes and Noble to look for a > Prime Minister, Nebcorp | book on A.D.D., but I got bored and left." > dbt@meat.net | - Benjy Feen > http://wwn.nebcorp.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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Apr 30 19:19:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412JeIM000042 for ; Mon, 30 Apr 2001 19:19:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f412Je0d000041 for ipng-dist; Mon, 30 Apr 2001 19:19:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412JMIM000030 for ; Mon, 30 Apr 2001 19:19:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA08209 for ; Mon, 30 Apr 2001 19:19:22 -0700 (PDT) Received: from davin.ottawa.on.ca (mdarwin.magma.ca [209.217.122.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA26469 for ; Mon, 30 Apr 2001 19:19:21 -0700 (PDT) Received: (qmail 6359 invoked by uid 0); 30 Apr 2001 22:19:18 -0400 Received: from mdarwin.magma.ca (209.217.122.211) by mdarwin.magma.ca with SMTP; 30 Apr 2001 22:19:18 -0400 Date: Mon, 30 Apr 2001 22:19:18 -0400 (EDT) From: Matthew Darwin To: Subject: Re: AAAA/A6 thing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 30 Apr 2001, Jim Bound wrote: > What will not get done here is to get users to not embed addresses in > configs and there is no incentive for vendors to prevent them from doing > it. Does anyone know that the network management platforms are planning to do with this renumbering concept? I would expect that most of them key devices by IP address, or am I wrong? -------------------------------------------------------------------- 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 Apr 30 19:19:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412JgIM000045 for ; Mon, 30 Apr 2001 19:19:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f412JgSe000044 for ipng-dist; Mon, 30 Apr 2001 19:19:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412JKIM000027 for ; Mon, 30 Apr 2001 19:19:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA08195 for ; Mon, 30 Apr 2001 19:19:21 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA27979 for ; Mon, 30 Apr 2001 20:40:10 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 579674B0B; Tue, 1 May 2001 11:19:11 +0900 (JST) To: Ole Troan Cc: ipng@sunroof.eng.sun.com In-reply-to: ot's message of 01 May 2001 03:00:00 +0100. <7t5d79tomlb.fsf@onatopp.cisco.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: nonexisting destination on p2p link From: itojun@iijlab.net Date: Tue, 01 May 2001 11:19:11 +0900 Message-ID: <22619.988683551@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I'm inclined to disagree. >when pinging a local interface address for a p2p link, some IPv4 >implementations send the ping out the link, and gets it back from the >remote router, as a way of verifying connectivity. i mentioned this in very early message on this thread. my question is, (1) is it really a good idea to do it, and (2) are there IPv6 implementation doing this. >implementing your suggestion prevents the option of doing something >similar for IPv6. >let the packets bounce between the two routers for a while, in the end >you'll get a time exceeded message anyway. do you think it okay even if outsiders (bad guys) can chew your bandwidth? i think not. itojun -------------------------------------------------------------------- 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 Apr 30 19:23:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412N3IM000065 for ; Mon, 30 Apr 2001 19:23:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f412N35b000064 for ipng-dist; Mon, 30 Apr 2001 19:23:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412MoIM000057 for ; Mon, 30 Apr 2001 19:22:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14017 for ; Mon, 30 Apr 2001 19:22:51 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA27406 for ; Mon, 30 Apr 2001 19:22:50 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA12156; Mon, 30 Apr 2001 22:22:44 -0400 Date: Mon, 30 Apr 2001 22:22:44 -0400 (EDT) From: Jim Bound To: "David R. Conrad" Cc: itojun@iijlab.net, Paul A Vixie , ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: <5.0.2.1.2.20010430113834.030a9578@localhost> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave, With all due respect IPv6 is far superior to IPv4 for renumbering. Have you looked in depth at Neighbor Discovery, Stateless Autoconfiguration, and Router Renumbering RFCs. Then put them all together. Nothing I mean Nothing exists like this in IPv4. We have never said we solved all the renumbering problems. Nor did we say we would. Steve Deering has sent a few mails to this list and to the IPv6 Forum on this and it appears no one listens. We are far better off than IPv4 though. Also Itojun is 100% correct. The reason IPv6 will be and has begun deployment is because of "address space". Its the primary motivator. Then all the other stuff we have some don't seem to see is icing on the cake. /jim On Mon, 30 Apr 2001, David R. Conrad wrote: > Itojun, > > At 11:05 AM 4/30/2001 +0900, itojun@iijlab.net wrote: > > on the contrary, there are wording for routing table size. > > Renumbering is a means to address the routing table size problem (of > course, renumbering doesn't help the multi-homing problem). > > > as far as i understand IPv6 addressing plan as well as 6bone routing > > guideline solves this portion of the problem. > > My understanding is that IPv6 uses the same routing technology as IPv4 and > is only marginally easier to renumber than IPv4, hence the routing table > problem is not addressed. > > Rgds, > -drc > > > > -------------------------------------------------------------------- > 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 Mon Apr 30 19:26:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412QxIM000102 for ; Mon, 30 Apr 2001 19:26:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f412QwPB000100 for ipng-dist; Mon, 30 Apr 2001 19:26:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412QlIM000093 for ; Mon, 30 Apr 2001 19:26:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03288 for ; Mon, 30 Apr 2001 19:26:48 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA01827 for ; Mon, 30 Apr 2001 20:47:36 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C3AF34B0B; Tue, 1 May 2001 11:26:38 +0900 (JST) To: Jim Bound Cc: ipng@sunroof.eng.sun.com In-reply-to: seamus's message of Mon, 30 Apr 2001 22:06:27 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: AAAA/A6 thing From: itojun@iijlab.net Date: Tue, 01 May 2001 11:26:38 +0900 Message-ID: <22720.988683998@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Good points. We have renumbering for the LAN. We have a way to renumber >from the border routers within a domain. This will get us started for >deployment. Baby steps are all we can take. If the IETF can extend these >to grown-up steps great. But we will start deployment now with what we >got and its already better than IPv4. > >I would think someone should put out a draft on all this and state whats >missing and what needs to be done. regarding to renumbering, there was a draft by Fred Baker (was it on i-d repository?), as well as a presentation by jinmei (IETF49?). the draft/presentation describes timing constraints and steps necessary for renumbering a leaf site. yes, it is far better than IPv4 case, but... >What will not get done here is to get users to not embed addresses in >configs and there is no incentive for vendors to prevent them from doing >it. it is very hard to ensure it, and there are wacky timing constraints (specifically interactions with DNS cache TTL). itojun -------------------------------------------------------------------- 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 Apr 30 19:33:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412XbIM000170 for ; Mon, 30 Apr 2001 19:33:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f412Xb7P000168 for ipng-dist; Mon, 30 Apr 2001 19:33:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412XQIM000161 for ; Mon, 30 Apr 2001 19:33:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA00343 for ; Mon, 30 Apr 2001 19:33:26 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA04988 for ; Mon, 30 Apr 2001 20:54:17 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8C3064B0B; Tue, 1 May 2001 11:33:21 +0900 (JST) To: Jim Bound Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: seamus's message of Mon, 30 Apr 2001 22:14:39 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: AAAA/A6 thing From: itojun@iijlab.net Date: Tue, 01 May 2001 11:33:21 +0900 Message-ID: <22795.988684401@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Right or wrong. Paul's comment is valid. A6 will be deployed at least on >BIND (well it is now actually) and on Microsofts DNS is my read. > >As one of the people to fund BIND future development and with others we >believe it should not be implemented for greater than 3 levels of >hierarchy till more testing and experimentation is done. But A6 will be >shipped on the street and its a done deal. > >Do I like A6 no. >Do I think a better solution exists yes. >But do I advocate deployment of A6 yes. >Why because its time to move forward. > >I also thought continuing private address space was a bad idea in v6. I >still do. KNow what I hope to help build that feature in our products. what I am worrying is that A6 is contributing negatively to the deployment of IPv6, due to less availability in code. it may have a positive impact if it gets deployed worldwide (less signing cost on renumber), but i guess the negative impact (to deployment) is bigger than the benefits from less signing cost. today there's no commercial/free software OS (i know of) that ships with A6-chasing resolver. not sure they will ever migrate to BIND9 resolvers, many of them are still stuck with BIND4 resolver (with security fixes, of course) because of binary backward compatibility issues and local changes they have made. maybe this feeling is because I'm from very IPv6-deployment-aggressive region. i really would like to see IPv6 NS records to be available everywhere, including root, and A6 is one of the obstacles for IPv6 NS record deployment. anyway, i'll shut up and write up a draft. itojun -------------------------------------------------------------------- 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 Apr 30 19:37:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412bwIM000192 for ; Mon, 30 Apr 2001 19:37:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f412bwax000191 for ipng-dist; Mon, 30 Apr 2001 19:37:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412bmIM000180 for ; Mon, 30 Apr 2001 19:37:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04351 for ; Mon, 30 Apr 2001 19:37:48 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA06913 for ; Mon, 30 Apr 2001 19:37:47 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA30749; Mon, 30 Apr 2001 22:37:43 -0400 Date: Mon, 30 Apr 2001 22:37:43 -0400 (EDT) From: Jim Bound To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: <22720.988683998@itojun.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, Good point. I saw Fred's draft and reviewed it before it came out. It is very good. I did not know if it actually got sent out? Hmm. I could not find it. It is very good and also gives very good technical and scientfic analysis of the problem? Fred if your still with us on IPng is the ID still available? /jim On Tue, 1 May 2001 itojun@iijlab.net wrote: > >Good points. We have renumbering for the LAN. We have a way to renumber > >from the border routers within a domain. This will get us started for > >deployment. Baby steps are all we can take. If the IETF can extend these > >to grown-up steps great. But we will start deployment now with what we > >got and its already better than IPv4. > > > >I would think someone should put out a draft on all this and state whats > >missing and what needs to be done. > > regarding to renumbering, there was a draft by Fred Baker (was it on > i-d repository?), as well as a presentation by jinmei (IETF49?). > the draft/presentation describes timing constraints and steps > necessary for renumbering a leaf site. > yes, it is far better than IPv4 case, but... > > >What will not get done here is to get users to not embed addresses in > >configs and there is no incentive for vendors to prevent them from doing > >it. > > it is very hard to ensure it, and there are wacky timing constraints > (specifically interactions with DNS cache TTL). > > itojun > -------------------------------------------------------------------- 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 Apr 30 19:40:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412eMIM000211 for ; Mon, 30 Apr 2001 19:40:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f412eMog000210 for ipng-dist; Mon, 30 Apr 2001 19:40:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412eBIM000199 for ; Mon, 30 Apr 2001 19:40:11 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA10004 for ; Mon, 30 Apr 2001 19:40:11 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA06267 for ; Mon, 30 Apr 2001 19:40:10 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA12573; Mon, 30 Apr 2001 22:40:07 -0400 Date: Mon, 30 Apr 2001 22:40:06 -0400 (EDT) From: Jim Bound To: itojun@iijlab.net Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: <22795.988684401@itojun.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, My take as implementor and deployer champion is I don't care anymore. No one is going to use it till it works and thats a coding and performance of implementation issue. We are working on the BIND issues of performance now in the deployment community for IPv6. If necessary we will pay the highest bidder to get it done and perform. But until then I tell users to just use AAAA. Cause it works now. /jim On Tue, 1 May 2001 itojun@iijlab.net wrote: > > >Right or wrong. Paul's comment is valid. A6 will be deployed at least on > >BIND (well it is now actually) and on Microsofts DNS is my read. > > > >As one of the people to fund BIND future development and with others we > >believe it should not be implemented for greater than 3 levels of > >hierarchy till more testing and experimentation is done. But A6 will be > >shipped on the street and its a done deal. > > > >Do I like A6 no. > >Do I think a better solution exists yes. > >But do I advocate deployment of A6 yes. > >Why because its time to move forward. > > > >I also thought continuing private address space was a bad idea in v6. I > >still do. KNow what I hope to help build that feature in our products. > > what I am worrying is that A6 is contributing negatively to the > deployment of IPv6, due to less availability in code. it may have a > positive impact if it gets deployed worldwide (less signing cost on > renumber), but i guess the negative impact (to deployment) is bigger > than the benefits from less signing cost. > today there's no commercial/free software OS (i know of) that ships > with A6-chasing resolver. not sure they will ever migrate to BIND9 > resolvers, many of them are still stuck with BIND4 resolver (with > security fixes, of course) because of binary backward compatibility > issues and local changes they have made. > > maybe this feeling is because I'm from very IPv6-deployment-aggressive > region. i really would like to see IPv6 NS records to be available > everywhere, including root, and A6 is one of the obstacles for IPv6 > NS record deployment. > > anyway, i'll shut up and write up a draft. > > itojun > -------------------------------------------------------------------- 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 Apr 30 19:49:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412n7IM000253 for ; Mon, 30 Apr 2001 19:49:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f412n7Ev000252 for ipng-dist; Mon, 30 Apr 2001 19:49:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f412muIM000243 for ; Mon, 30 Apr 2001 19:48:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05224 for ; Mon, 30 Apr 2001 19:48:56 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09908 for ; Mon, 30 Apr 2001 19:48:55 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 618D34B0B; Tue, 1 May 2001 11:48:52 +0900 (JST) To: Robert Elz Cc: Randy Bush , ipng@sunroof.eng.sun.com In-reply-to: kre's message of Mon, 30 Apr 2001 18:02:02 +0700. <1789.988628522@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: AAAA/A6 thing From: itojun@iijlab.net Date: Tue, 01 May 2001 11:48:52 +0900 Message-ID: <23064.988685332@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Then we have giant setbacks, like the "embedding IPv6 literals in URLs" >nonsense, that is 100% the wrong thing to be doing if we want to be able >to change the addresses in any kind of reasonable way. my understanding is that there are needs only when we debug web servers. maybe we should put some wording into RFC2732+, that says "it is not recommended for daily use, use FQDN". itojun -------------------------------------------------------------------- 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 Apr 30 20:11:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f413B8IM000300 for ; Mon, 30 Apr 2001 20:11:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f413B7Iw000299 for ipng-dist; Mon, 30 Apr 2001 20:11:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f413AuIM000292 for ; Mon, 30 Apr 2001 20:10:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA18497 for ; Mon, 30 Apr 2001 20:10:56 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA09937 for ; Mon, 30 Apr 2001 20:10:55 -0700 (PDT) Received: (qmail 16753 invoked by uid 1001); 1 May 2001 03:11:12 -0000 Date: 1 May 2001 03:11:12 -0000 Message-ID: <20010501031112.8471.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <20010430092511.A591@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound writes: > But A6 will be shipped on the street and its a done deal. No, it is not. IPNG can terminate the A6/DNAME proposals right now. Users will continue to rely on AAAA, not on A6 and DNAME. > we believe it should not be implemented for greater than 3 levels of > hierarchy Even a single level of A6 indirection is dangerous. See my example of AOL committing suicide at the top of http://cr.yp.to/djbdns/killa6.html. I can't imagine what you think a 3-level limit would accomplish. > As one of the people to fund BIND future development Thank you for disclosing your financial interests. Did you know that United States antitrust law prohibits packing standards committees? ---Dan -------------------------------------------------------------------- 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 Apr 30 20:26:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f413Q4IM000337 for ; Mon, 30 Apr 2001 20:26:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f413Q3FL000336 for ipng-dist; Mon, 30 Apr 2001 20:26:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f413PsIM000329 for ; Mon, 30 Apr 2001 20:25:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA19947 for ; Mon, 30 Apr 2001 20:25:54 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA13619 for ; Mon, 30 Apr 2001 20:25:54 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA22995; Mon, 30 Apr 2001 23:25:53 -0400 Date: Mon, 30 Apr 2001 23:25:52 -0400 (EDT) From: Jim Bound To: "D. J. Bernstein" Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <20010501031112.8471.qmail@cr.yp.to> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bind is not a standard. its a public domain implementation funded by public money. /jim On 1 May 2001, D. J. Bernstein wrote: > Jim Bound writes: > > But A6 will be shipped on the street and its a done deal. > > No, it is not. IPNG can terminate the A6/DNAME proposals right now. > Users will continue to rely on AAAA, not on A6 and DNAME. > > > we believe it should not be implemented for greater than 3 levels of > > hierarchy > > Even a single level of A6 indirection is dangerous. See my example of > AOL committing suicide at the top of http://cr.yp.to/djbdns/killa6.html. > I can't imagine what you think a 3-level limit would accomplish. > > > As one of the people to fund BIND future development > > Thank you for disclosing your financial interests. Did you know that > United States antitrust law prohibits packing standards committees? > > ---Dan > -------------------------------------------------------------------- > 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 Mon Apr 30 20:30:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f413UGIM000354 for ; Mon, 30 Apr 2001 20:30:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f413UFGg000353 for ipng-dist; Mon, 30 Apr 2001 20:30:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f413U6IM000346 for ; Mon, 30 Apr 2001 20:30:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA05060 for ; Mon, 30 Apr 2001 20:30:06 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA22673 for ; Mon, 30 Apr 2001 20:30:05 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA30920; Mon, 30 Apr 2001 23:30:05 -0400 Date: Mon, 30 Apr 2001 23:30:05 -0400 (EDT) From: Jim Bound To: "D. J. Bernstein" Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <20010501031112.8471.qmail@cr.yp.to> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk dan, I will not argue against you or for you. Last I will say your correct. But they are not going to listen to you here. I am out of it. Everyones using AAAA anyway. If you can change the minds of these here best of luck to you. But I bet I hear this debate again a year from now with no resolution. Its too bad but that is the way it is and why I try to reduce the work I have to do here. I am not pro bind or pro bernstein or pro microsoft DNS I am pro IPv6 deployment thats all. bind is just what most have deployed. Its just good enough but can be made better I think. /jim On 1 May 2001, D. J. Bernstein wrote: > Jim Bound writes: > > But A6 will be shipped on the street and its a done deal. > > No, it is not. IPNG can terminate the A6/DNAME proposals right now. > Users will continue to rely on AAAA, not on A6 and DNAME. > > > we believe it should not be implemented for greater than 3 levels of > > hierarchy > > Even a single level of A6 indirection is dangerous. See my example of > AOL committing suicide at the top of http://cr.yp.to/djbdns/killa6.html. > I can't imagine what you think a 3-level limit would accomplish. > > > As one of the people to fund BIND future development > > Thank you for disclosing your financial interests. Did you know that > United States antitrust law prohibits packing standards committees? > > ---Dan > -------------------------------------------------------------------- > 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 Mon Apr 30 21:04:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4144LIM000379 for ; Mon, 30 Apr 2001 21:04:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4144LQA000378 for ipng-dist; Mon, 30 Apr 2001 21:04:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4144BIM000371 for ; Mon, 30 Apr 2001 21:04:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12257 for ; Mon, 30 Apr 2001 21:04:11 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA24384 for ; Mon, 30 Apr 2001 22:25:47 -0600 (MDT) Received: from drc-toshiba.nominum.com (shell.nominum.com [204.152.187.59]) by shell.nominum.com (Postfix) with ESMTP id 6AFC53190D; Mon, 30 Apr 2001 21:04:03 -0700 (PDT) Message-Id: <5.0.2.1.2.20010430195415.0314f788@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 30 Apr 2001 21:04:07 -0700 To: Jim Bound From: "David R. Conrad" Subject: Re: AAAA/A6 thing Cc: itojun@iijlab.net, Paul A Vixie , ipng@sunroof.eng.sun.com In-Reply-To: References: <5.0.2.1.2.20010430113834.030a9578@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, At 10:22 PM 4/30/2001 -0400, Jim Bound wrote: >With all due respect IPv6 is far superior to IPv4 for renumbering. >Have you looked in depth at Neighbor Discovery, Stateless >Autoconfiguration, and Router Renumbering RFCs. Then put them all >together. My understanding that all of these were in a significant state of flux with no significant deployment even possible at this time. I'm glad to hear my understanding was mistaken. Need more time to read... >Nothing I mean Nothing exists like this in IPv4. True. However, IPv4 does, at least, have deployed DHCP which seems to be of more interest to larger sites than stateless autoconf. >We have never said we solved all the renumbering problems. I don't believe anyone has claimed the problems have been solved. They are difficult problems. I was under the impression, however, that A6 was considered a significant portion of the answer to the renumbering problem. If it is not considered such, then it should be dropped immediately as the additional complexity it imposes on the DNS is far too high to justify its deployment. >Nor did we say we would. For what it is worth (not much, I know), my personal belief is that trivial renumbering is key to IPv6's success. Without it, NAT will have a significant advantage, despite NAT's acknowledged problems (no intention of sparking yet another NAT flamefest, yes NAT is a blecherous hack). >The reason IPv6 will be and has begun >deployment is because of "address space". Its the primary motivator. This is worrisome. By and large, I believe the main reason people are unhappy with the current situation with IPv4 is end user sites are normally rejected for address allocations of provider independent address space, forcing those sites to be dependent on their service provider for address space. The reason for rejection is typically _not_ a lack of address space, but rather the RIRs have been put into the position of trying to limit the number of provider independent prefixes which enter the routing system. Given the current IPv6 addressing and routing architectures (as I understand them -- I'm sure I'll be "gently" corrected if I'm wrong), those same end user sites should get rejected for IPv6 space as well -- they should go to their service provider for their address space. Without trivial renumbering, those sites that transition to IPv6 will find themselves in _exactly_ the same place they are with IPv4, if not worse. They must renumber their site to their new provider's address space. All IPv6's bigger addresses would mean is that they have more to renumber. At that point, why fight the IPv4 inertia? Why not simply go with IPv4 NAT solutions, despite their warts (yes, I know what those warts are, but note that I can go down to Office Depot and buy a 56Kbps asynch NAT router off the shelf _today_)? I believe A6 provides a useful generalization that can support greatly simplified renumbering. I also believe a significant amount of operational deployment experience is necessary to determine whether or not the complexity it imposes on the DNS is justified by the benefits it brings. At least at this point, there are implementations that will permit experimentation. Those experiments should be the focus of efforts, not attempts to derail the existence of A6 without supporting evidence. Rgds, -drc -------------------------------------------------------------------- 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 Apr 30 21:07:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4146xIM000396 for ; Mon, 30 Apr 2001 21:06:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4146wOq000393 for ipng-dist; Mon, 30 Apr 2001 21:06:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4146kIM000381 for ; Mon, 30 Apr 2001 21:06:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA24086 for ; Mon, 30 Apr 2001 21:06:46 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA23844 for ; Mon, 30 Apr 2001 21:06:45 -0700 (PDT) Received: from 157.54.7.67 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 30 Apr 2001 21:04:15 -0700 (Pacific Daylight Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 30 Apr 2001 21:02:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: nonexisting destination on p2p link Date: Mon, 30 Apr 2001 21:02:57 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9CCE@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: nonexisting destination on p2p link Thread-Index: AcDR44SLi6yKbfywTG6K552/LG+77gAD3J0g From: "Richard Draves" To: "Ole Troan" Cc: , "Robert Elz" , X-OriginalArrivalTime: 01 May 2001 04:02:58.0427 (UTC) FILETIME=[9B9B2CB0:01C0D1F3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f4146lIM000382 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm inclined to disagree. > when pinging a local interface address for a p2p link, some > IPv4 implementations send the ping out the link, and gets it > back from the remote router, as a way of verifying connectivity. > > implementing your suggestion prevents the option of doing > something similar for IPv6. let the packets bounce between > the two routers for a while, in the end you'll get a time > exceeded message anyway. Hmm. I'm not familiar with that IPv4 practice. itojun already mentioned the DoS concern. When it's an innocent error, I also think that it will be difficult to diagnose the time exceeded and realize the problem is a typo in the destination address instead of a routing loop. Rich -------------------------------------------------------------------- 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 Apr 30 22:58:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f415wqIM000478 for ; Mon, 30 Apr 2001 22:58:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f415wqh2000477 for ipng-dist; Mon, 30 Apr 2001 22:58:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f415wfIM000470 for ; Mon, 30 Apr 2001 22:58:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA02984 for ; Mon, 30 Apr 2001 22:58:42 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA26046 for ; Tue, 1 May 2001 00:20:21 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A9C0B4B0B; Tue, 1 May 2001 14:58:31 +0900 (JST) To: sowmini@quasimodo.east.sun.com Cc: ipng@sunroof.eng.sun.com In-reply-to: sowmini's message of Fri, 27 Apr 2001 09:52:52 -0400. <200104271352.JAA06088@quasimodo.east.sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: nonexisting destination on p2p link From: itojun@iijlab.net Date: Tue, 01 May 2001 14:58:31 +0900 Message-ID: <25189.988696711@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >In the case of link-local addresses, I think that the packet should >only be forwarded once across the p2p link- when the hop limit goes >below 255, it shouldn't get forwarded back? unfortunately there's no such rule (as far as i know). if you find any mention in RFC/draft, please let me know. itojun -------------------------------------------------------------------- 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 Apr 30 23:07:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4167hIM000500 for ; Mon, 30 Apr 2001 23:07:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4167hAm000499 for ipng-dist; Mon, 30 Apr 2001 23:07:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4167YIM000492 for ; Mon, 30 Apr 2001 23:07:34 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28632 for ; Mon, 30 Apr 2001 23:07:35 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26283 for ; Mon, 30 Apr 2001 23:07:32 -0700 (PDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id B7C191967D7; Tue, 1 May 2001 03:07:29 -0300 (ART) Date: Tue, 1 May 2001 03:07:29 -0300 To: itojun@iijlab.net Cc: Ole Troan , ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link Message-ID: <20010501030729.A7485@tinuviel.compendium.net.ar> References: <7t5d79tomlb.fsf@onatopp.cisco.com> <22619.988683551@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <22619.988683551@itojun.org>; from itojun@iijlab.net on Tue, May 01, 2001 at 11:19:11AM +0900 x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f4167ZIM000493 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > >implementing your suggestion prevents the option of doing something > >similar for IPv6. > >let the packets bounce between the two routers for a while, in the end > >you'll get a time exceeded message anyway. > do you think it okay even if outsiders (bad guys) can chew your > bandwidth? i think not. And while we have so many tunnels over the IPv4 internet, that means chewing bandwidth in all the way between the end points of the tunnel, not just in a private link as would be with a physical connection... > itojun HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- 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 Apr 30 23:38:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f416cgIM000555 for ; Mon, 30 Apr 2001 23:38:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f416cggK000554 for ipng-dist; Mon, 30 Apr 2001 23:38:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f416cWIM000547 for ; Mon, 30 Apr 2001 23:38:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05935 for ; Mon, 30 Apr 2001 23:38:33 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA20301 for ; Tue, 1 May 2001 00:59:32 -0600 (MDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f416cVP11605; Mon, 30 Apr 2001 23:38:31 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f416cVJ17319; Mon, 30 Apr 2001 23:38:31 -0700 Message-Id: <200105010638.f416cVJ17319@zed.isi.edu> Subject: was a6/aaaa - RA/ND & exchanges To: seamus@bit-net.com (Jim Bound) Date: Mon, 30 Apr 2001 23:38:31 -0700 (PDT) Cc: david.conrad@nominum.com (David R. Conrad), itojun@iijlab.net, vixie@mfnx.net (Paul A Vixie), ipng@sunroof.eng.sun.com In-Reply-To: from "Jim Bound" at Apr 30, 2001 10:22:44 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % Dave, % % With all due respect IPv6 is far superior to IPv4 for renumbering. % Have you looked in depth at Neighbor Discovery, Stateless % Autoconfiguration, and Router Renumbering RFCs. Then put them all % together. Nothing I mean Nothing exists like this in IPv4. And it was hell to fix. Six routers sharing a broadcast domain. All running ND & all running RA. Which Address do the BGP peer on? The Fix? Turn off ND & RA and statically configure the interfaces. -- --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 Mon Apr 30 23:40:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f416erIM000565 for ; Mon, 30 Apr 2001 23:40:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f416erji000564 for ipng-dist; Mon, 30 Apr 2001 23:40:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f416egIM000557 for ; Mon, 30 Apr 2001 23:40:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28297 for ; Mon, 30 Apr 2001 23:40:44 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA07371 for ; Mon, 30 Apr 2001 23:40:43 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f416ehP11708; Mon, 30 Apr 2001 23:40:43 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f416eg117329; Mon, 30 Apr 2001 23:40:42 -0700 Message-Id: <200105010640.f416eg117329@zed.isi.edu> Subject: Re: AAAA/A6 thing To: itojun@iijlab.net Date: Mon, 30 Apr 2001 23:40:42 -0700 (PDT) Cc: seamus@bit-net.com (Jim Bound), ipng@sunroof.eng.sun.com In-Reply-To: <22720.988683998@itojun.org> from "itojun@iijlab.net" at May 01, 2001 11:26:38 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % >What will not get done here is to get users to not embed addresses in % >configs and there is no incentive for vendors to prevent them from doing % >it. % % it is very hard to ensure it, and there are wacky timing constraints % (specifically interactions with DNS cache TTL). % % itojun With RA/ND running & multiple egress paths, which IP address will the DNS server have that folks need to talk to? -- --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 --------------------------------------------------------------------