From owner-v6ops@ops.ietf.org Tue Oct 1 01:16:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07494 for ; Tue, 1 Oct 2002 01:16:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wFNp-0001F5-00 for v6ops-data@psg.com; Mon, 30 Sep 2002 22:15:45 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17wFNm-0001Eu-00 for v6ops@ops.ietf.org; Mon, 30 Sep 2002 22:15:42 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 89B3D4B22; Tue, 1 Oct 2002 14:15:39 +0900 (JST) To: Keith Moore Cc: Rob Austein , v6ops@ops.ietf.org In-reply-to: moore's message of Fri, 27 Sep 2002 14:11:18 -0400. <200209271811.g8RIBI028421@astro.cs.utk.edu> 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: IPv6 tunnel over NAT From: itojun@iijlab.net Date: Tue, 01 Oct 2002 14:15:39 +0900 Message-Id: <20021001051539.89B3D4B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> The question is whether IPv6/PPP/xyz/TCP is good enough for the >> particular case of hosts stuck behind a NAT that they cannot remove or >> upgrade. I think that the answer in this case may well be "yes". > >well, obviously it depends on the applications being run and the >quality of the underlying links. if you're running real time apps >over UDP over PPP over TCP over a lossy IP link, you'd probably >be much happier using Teredo. do we really want to say, for instance, >that it's okay for the generic solution to break streaming audio? the use of TCP doesn't really change the situation to streaming audio. if you see how many layers of encapsulations we are using for DSL services (take a look at diagrams in draft-mickles-v6ops-isp-cases-01) i think you will agree with me. it's a horrible world. itojun From owner-v6ops@ops.ietf.org Tue Oct 1 01:40:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07856 for ; Tue, 1 Oct 2002 01:40:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wFnP-0002FW-00 for v6ops-data@psg.com; Mon, 30 Sep 2002 22:42:11 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17wFnM-0002FL-00 for v6ops@ops.ietf.org; Mon, 30 Sep 2002 22:42:08 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g915fqR15339; Tue, 1 Oct 2002 08:41:52 +0300 Date: Tue, 1 Oct 2002 08:41:52 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: Keith Moore , Rob Austein , Subject: Re: IPv6 tunnel over NAT In-Reply-To: <20021001051539.89B3D4B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 1 Oct 2002 itojun@iijlab.net wrote: > >> The question is whether IPv6/PPP/xyz/TCP is good enough for the > >> particular case of hosts stuck behind a NAT that they cannot remove or > >> upgrade. I think that the answer in this case may well be "yes". > > > >well, obviously it depends on the applications being run and the > >quality of the underlying links. if you're running real time apps > >over UDP over PPP over TCP over a lossy IP link, you'd probably > >be much happier using Teredo. do we really want to say, for instance, > >that it's okay for the generic solution to break streaming audio? > > the use of TCP doesn't really change the situation to streaming audio. > if you see how many layers of encapsulations we are using for DSL > services (take a look at diagrams in draft-mickles-v6ops-isp-cases-01) > i think you will agree with me. it's a horrible world. How many of those layers perform error correction (retransmission) measures like TCP does if there is a problem at a lower layer? End-to-end retransmissions? Right. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Oct 1 08:19:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11558 for ; Tue, 1 Oct 2002 08:19:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wLy9-000Apj-00 for v6ops-data@psg.com; Tue, 01 Oct 2002 05:17:41 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17wLy2-000ApU-00 for v6ops@ops.ietf.org; Tue, 01 Oct 2002 05:17:34 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g91CHTOb016603; Tue, 1 Oct 2002 14:17:30 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 1 Oct 2002 14:17:22 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0AA2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" , "Hesham Soliman (EAB)" Cc: "Hesham Soliman (EAB)" , "'itojun@iijlab.net'" , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Tue, 1 Oct 2002 14:17:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk > "Reachable" in what sense? I can see this argument for > the IPv6 PDP Context, since you might run a peer-to-peer > service over IPv6 for messaging, or whatever... > > But, what advantage is there to having an IPv4 PDP > Context up all of the time? If you are behind any type > of NAT (IPv4 NAT or NAT-PT), you won't be reachable > from the outside, anyway. => I wasn't referring to any particular solution or type of address. The point I am making is that regardless of the type of address you have, if you do not have a PDP context up then you are not reachable. Even if you have private v4 addresses and you need to be reachable by someone else inside the same domain they cannot reach you if you don't have a PDP context. BTW if you do have an IPv6 address you are reachable from the outside (by other v6 hosts). So you should always have a PDP context and be assigned at least one address. > > > > > - How many simultaneous IPv4 & IPv6 > > > connections are expected? > > > >=> Depends on the user, this is orthogonal to the > >PDP context(s). > > Right, but this is key to the scaling issues for any NAT > solution. The "10 million" nodes (or 100,000-500,000 nodes) > number is much less interesting, from a NAT scaling perspective, > then the number of simultaneous communication sessions for > which the NAT box will need to maintain state. => Sure but this is something that network designers will have to consider, in light of the types of devices/services that they expect to support. > We're in agreement, though, that a single NAT box won't be able > to handle 10 million nodes. Given that fact, I'm not sure that it > matters whether the end-hosts behind the NATs are numbered in > different ranges of the same address space (as they could be with > NAT-PT), or in private address spaces (as with IPv4 NAT). Both > address spaces would be private from the point of view of the > IPv4 Internet, requiring translation into globally routable IPv4 > addresses. => Yes, but the different I mentioned earlier was that there is no overlapping address spaces in the v6 network. But there will be for large or expanding private v4 networks. > > > (3) The nodes will only need occasional access to > > > IPv4 & IPv6 services. > > > >=> I think continuous accessibility is required. > >We don't want to tear down PDP contexts and start > >them again too often. > > Do you know how potential 3GPP operators think about this? I have > heard different things from different equipment manufacturers... => I think some would agree with my opinion above, but I really can't speak for them. > > However, I'll accept that we want a solution that can handle > always-on IPv4 and IPv6 access to every end-node, even if that > isn't how all of the networks are deployed. > => ok. > Are you willing to accept that it would probably make sense, in > the 3GPP topology to position the NATs (or either type) in or > just behind the GGSNs, rather than having a single (set of) NAT > box(es) between the full 10 million node network and the rest of > the Internet? => You really want to discuss solutions at the same time :) ok, I accept that it is certainly possible and I don't rule out that option. In fact I haven't ruled out any option. But I'm not confident enough to say that this is _the_ way to do it before I can study current scenarios and rollouts. Each operator has different requirements/addresses/plans ...etc and I don't know yet if we can cover all cases with this approach. Hesham From owner-v6ops@ops.ietf.org Tue Oct 1 09:22:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14904 for ; Tue, 1 Oct 2002 09:22:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wMyb-000CRZ-00 for v6ops-data@psg.com; Tue, 01 Oct 2002 06:22:13 -0700 Received: from mail1-0.chcgil.ameritech.net ([206.141.192.68]) by psg.com with esmtp (Exim 3.36 #1) id 17wMyV-000CRL-00 for v6ops@ops.ietf.org; Tue, 01 Oct 2002 06:22:07 -0700 Received: from repligate ([65.43.125.97]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20021001132205.OXJU6468.mail1-0.chcgil.ameritech.net@repligate>; Tue, 1 Oct 2002 08:22:05 -0500 Message-ID: <02e601c2694d$8c001890$617d2b41@repligate> From: "Jim Fleming" To: "Hesham Soliman \(EAB\)" , "'Margaret Wasserman'" Cc: "Hesham Soliman \(EAB\)" , , References: <4DA6EA82906FD511BE2F00508BCF0538044F0AA2@Esealnt861.al.sw.ericsson.se> Subject: Dynamic DNS vs. Hard-Wired IPv4 Connections Date: Tue, 1 Oct 2002 08:22:08 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Hesham Soliman (EAB)" > > > "Reachable" in what sense? I can see this argument for > > the IPv6 PDP Context, since you might run a peer-to-peer > > service over IPv6 for messaging, or whatever... > > > > But, what advantage is there to having an IPv4 PDP > > Context up all of the time? If you are behind any type > > of NAT (IPv4 NAT or NAT-PT), you won't be reachable > > from the outside, anyway. > > => I wasn't referring to any particular solution > or type of address. The point I am making is that > regardless of the type of address you have, if you > do not have a PDP context up then you are not reachable. > > Even if you have private v4 addresses and you need to > be reachable by someone else inside the same domain > they cannot reach you if you don't have a PDP > context. BTW if you do have an IPv6 address you > are reachable from the outside (by other v6 hosts). > > So you should always have a PDP context and be assigned > at least one address. > Assigned at least one "address" or "domain name" ? Dynamic DNS helps to solve the mobility binding problem... Vote early and often... http://www.kvtek.com/ddnsservices.asp Other links... DynDNS www.dyndns.org Yi www.yi.org DtDNS www.dtdns.com HammerNode www.hn.org EyeP www.eyep.net DynU www.dynu.com easyDNS www.easydns.com No-IP www.no-ip.com dyns.cx www.dyns.cx dnsQ.org www.dnsq.org myIP.org www.myip.org ns1.net www.ns1.net ZoneEdit www.zoneedit.com dyn.ee www.dyn.ee www.centralinfo.net NOLS www.nols.com dhs.org www.dhs.org YYweb.com www.yyweb.com dyn.ca www.dyn.ca DDNS.nu www.ddns.nu miniDNS www.minidns.net DynDNS.dk www.dyndns.dk changeIP www.changeip.com dnsArt www.dnsart.com DSL Reports www.dslreports.com GetmyIP.com www.getmyip.com From owner-v6ops@ops.ietf.org Tue Oct 1 09:40:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16015 for ; Tue, 1 Oct 2002 09:40:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wNGe-000Crx-00 for v6ops-data@psg.com; Tue, 01 Oct 2002 06:40:52 -0700 Received: from mail1-0.chcgil.ameritech.net ([206.141.192.68]) by psg.com with esmtp (Exim 3.36 #1) id 17wNGa-000Crl-00 for v6ops@ops.ietf.org; Tue, 01 Oct 2002 06:40:48 -0700 Received: from repligate ([65.43.125.97]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20021001134047.PIZG6468.mail1-0.chcgil.ameritech.net@repligate>; Tue, 1 Oct 2002 08:40:47 -0500 Message-ID: <02f001c26950$28a41fa0$617d2b41@repligate> From: "Jim Fleming" To: "Hesham Soliman \(EAB\)" , "'Margaret Wasserman'" Cc: "Hesham Soliman \(EAB\)" , , Subject: "...work is done in face-to-face meetings..." ??? Date: Tue, 1 Oct 2002 08:40:51 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.6 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_Q_MARK version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit http://rfc3314.x42.com/ 3GPP working methods are different from IETF working methods. The major difference is where the majority of the work is done. In 3GPP, the work is done in face-to-face meetings, and the mailing list is used mainly for distributing contributions, and for handling documents that were not handled in the meeting, due to lack of time. ===== "...work is done in face-to-face meetings..." ??? What is face-to-face ? http://www.runabot.com/infigon/ From owner-v6ops@ops.ietf.org Tue Oct 1 10:17:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18876 for ; Tue, 1 Oct 2002 10:17:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wNqW-000DsN-00 for v6ops-data@psg.com; Tue, 01 Oct 2002 07:17:56 -0700 Received: from mail1-0.chcgil.ameritech.net ([206.141.192.68]) by psg.com with esmtp (Exim 3.36 #1) id 17wNqQ-000Ds4-00 for v6ops@ops.ietf.org; Tue, 01 Oct 2002 07:17:50 -0700 Received: from repligate ([65.43.125.97]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20021001141745.QFQL6468.mail1-0.chcgil.ameritech.net@repligate> for ; Tue, 1 Oct 2002 09:17:45 -0500 Message-ID: <033901c26955$52aa3be0$617d2b41@repligate> From: "Jim Fleming" To: Subject: Fw: http://rfc3314.x42.com/ Date: Tue, 1 Oct 2002 09:17:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jim Fleming" To: ; ; ; ; "Christian Huitema" ; "Bob Hinden" ; ; ; Sent: Tuesday, October 01, 2002 9:07 AM Subject: http://rfc3314.x42.com/ > http://rfc3314.x42.com/ > This document was written by the IPv6 3GPP design team: > > Steve Deering, Cisco Systems > EMail: deering@cisco.com > > Karim El-Malki, Ericsson Radio Systems > EMail: Karim.El-Malki@era.ericsson.se > > Paul Francis, Tahoe Networks > EMail: francis@tahoenetworks.com > > Bob Hinden, Nokia > EMail: hinden@iprg.nokia.com > > Christian Huitema, Microsoft > EMail: huitema@windows.microsoft.com > > Niall Richard Murphy, Hutchison 3G > EMail: niallm@enigma.ie > > Markku Savela, Technical Research Centre of Finland > Email: Markku.Savela@vtt.fi > > Jonne Soininen, Nokia > EMail: Jonne.Soininen@nokia.com > > Margaret Wasserman, Wind River > EMail: mrw@windriver.com > ============================================= > > Your approach does not appear to represent the consensus of the marketplace. > It appears that you took a protocol, based on a 128-bit address field, and then > tried to develop an architecture to match the protocol. Most people would start > with an architecture, and then decide what components are needed, what are > available, and what need to be built, and then build those. While doing that, a > careful eye would be kept on making sure that ALL people/users/devices > currently connected to the global Internet remain connected, and evolve. That > prevents massive fragmentation of the network, stranding users and services. > Why would users want such a thing ? Evolution, not revolution has always been > the way the computer field has evolved. Stability and security of people's and > ISP's investments have to be considered. The world will route around you, > not in a revolutionary way, but, via evolution. There are plenty of addresses and > plenty of people writing software to make it all work. Face to face meetings and > documents do not move anything forward, in the real society. Face to face is > where people have fun. Somehow, you seem to have it backwards in the I* society. > > > 128-bit DNS AAAA Record Flag Day Formats > 2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] > [YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] > 1-bit to set the Reserved/Spare ("SNOOPY") bit in Fragment Offset [S] > 1-bit to set the Don't Fragment (DF) bit [D] > 2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL] > 1-bit for Options Control [O] > 7-bits to set the Identification Field(dst) [FFFFFFF] > 4-bits to set the TOS(dst) Field [TTTT] > Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000 > FFF.FFFF.TTTT = GGG.SSSS.SSSS > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > > > Jim Fleming > 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer... > http://www.ietf.com > http://www.iana.org/assignments/ipv4-address-space > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > http://www.netfilter.org/ > http://ipv8.dyndns.tv > http://ipv8.yi.org > http://ipv8.dyns.cx > http://ipv8.no-ip.com > http://ipv8.no-ip.org > http://ipv8.no-ip.biz > http://ipv8.no-ip.info > http://ipv8.myip.us > http://ipv8.dyn.ee > http://ipv8.community.net.au > http://ipv8.ods.org > From owner-v6ops@ops.ietf.org Tue Oct 1 10:39:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19948 for ; Tue, 1 Oct 2002 10:39:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wOCB-000ERn-00 for v6ops-data@psg.com; Tue, 01 Oct 2002 07:40:19 -0700 Received: from mail1-0.chcgil.ameritech.net ([206.141.192.68]) by psg.com with esmtp (Exim 3.36 #1) id 17wOC3-000ERa-00 for v6ops@ops.ietf.org; Tue, 01 Oct 2002 07:40:11 -0700 Received: from repligate ([65.43.125.97]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20021001144009.QUOX6468.mail1-0.chcgil.ameritech.net@repligate>; Tue, 1 Oct 2002 09:40:09 -0500 Message-ID: <03a801c26958$7445b880$617d2b41@repligate> From: "Jim Fleming" To: Cc: References: <20021001051539.89B3D4B22@coconut.itojun.org> Subject: "it's a horrible world"...Re: IPv6 tunnel over NAT Date: Tue, 1 Oct 2002 09:40:13 -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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: > if you see how many layers of encapsulations we are using for DSL > services (take a look at diagrams in draft-mickles-v6ops-isp-cases-01) > i think you will agree with me. it's a horrible world. > Do you think IPv6 makes it better ? Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer... http://www.ietf.com http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.netfilter.org/ http://ipv8.dyndns.tv http://ipv8.yi.org http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.org http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au http://ipv8.ods.org From owner-v6ops@ops.ietf.org Tue Oct 1 15:59:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03411 for ; Tue, 1 Oct 2002 15:59:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wTBI-000P2k-00 for v6ops-data@psg.com; Tue, 01 Oct 2002 12:59:44 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17wTBA-000P2Y-00 for v6ops@ops.ietf.org; Tue, 01 Oct 2002 12:59:36 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA08741 for ; Tue, 1 Oct 2002 12:59:34 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g91JxYj07845 for ; Tue, 1 Oct 2002 12:59:34 -0700 X-mProtect: <200210011959> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJ53gEw; Tue, 01 Oct 2002 12:59:32 PDT Message-ID: <3D9A024A.1000601@iprg.nokia.com> Date: Tue, 01 Oct 2002 13:15:06 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Operational requirements for a unified 6to4/isatap/teredo/6over4/SIIT solution Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Recent offline discussions have postulated a unified solution as a "widely applicable" mechanism that may satisfy most of the deployment scenarios envisioned by the design teams. (6to4, teredo, isatap, 6over4 and SIIT have all been mentioned as candidates for unification.) Since most of the unification would need to take place within the intra-site scope, I propose that the name '6over4' be (re)adopted for that portion of the unified scheme so that we would once again have: 6to4 + 6over4 as the unified solution (where "6over4" in this new sense combines the necessary aspects of rfc 2529, teredo, isatap, etc.) A comment was made during these discussions that, before any work on unification begins, scenarios must be identified in which a unified solution would be more useful than several seperate solutions. I am convinced that technical obstacles to realize such a unification are minimal and could be specified in a (bis) on RFC 2529. But the comment on identifying scenarios carries obvious operational implications - hence the decision to bring this topic to v6ops. I have listed below two possible scenarios in which a unified solution might be more useful than seperate solutions, but I leave it to the community to debate the merits of these scenarios and/or postulate others. As such, please direct all follow-up discussion to the v6ops list. Sincerely, Fred Templin ftemplin@iprg.nokia.com 1) Dual-stack router with native IPv6 connectivity ************************************************** The teredo specification ('shipworm-08.txt') deals with the "server" and "relay" functions as seperable entitites. When the functions are implemented in seperate boxes, the server cannot know in advance which relay will be used so it MUST assign clients the Global Teredo IPv6 service prefix (defined in 'shipworm-08.txt' as an IANA-assigned prefix of the form XXXX:XXXX/32). But, when the teredo server and relay occur in the same box the paradigm is identical to that of the isatap router function specified in 'isatap-04.txt'. The isatap router specification allows the advertisement of *any* globally routable IPv6 prefix(es) to clients up to and including /64's; not just prefixes derived from a specific IANA-assigned /32. By integrating the isatap router paradigm, the unified solution would allow native IPv6 prefix advertisements when the server and relay functions coincide, and whether isatap-style IPv6-in-IPv4 tunneling or teredo-style IPv6-in-UDP/IPv4 tunneling are used. Also, isatap-04.txt specifies a means for clients to discover and affiliate with multiple routers for the site. This means could also be applied for teredo in a unified solution. 2) Teredo server requiring a mapped address ******************************************* The 'shipworm-08.txt' specification assumes that the teredo server address will never require "mapping", as is required for teredo clients and that the 32-bit server IPv4 address alone is needed. As such, the specification seeks a /32 IANA assignment for the Global Teredo Service prefix. But, this decision casts in stone the assumption of no mapping requirement for servers, since a /32 assignment does not allow enough available bits (e.g., for encoding a 16-bit server port number) for future applications. One possible reason for the /32 target procurement is the difficulty in obtaining coarser-grained prefixes from IANA and unnecessary address space exhaustion. But, the 6to4 example shows that /16 prefixes can be obtained if the need is justified. In the case that a /16 simply cannot be procured, one alternative could be to claim an unused /20 prefix for teredo that would allow enough bits for future expansion. One such /20 exists that is currently unused (and unusable!) for other applications: 2002:f000::/20 This prefix is part of the 6to4 2002::/16, but is unused because it matches the IPv4 "Class E" experimental address space. There are +'s and -'s assocaited with claiming this /20 for teredo, however. On the '+' side, an otherwise-unusable /20 would be put to good use and a unified address prefix for transition mechanisms with room for expansion would be realized. On the '-' side, all 6to4 realys would need to be modified to either also support the teredo relay function, or advertise the subset of 2002::/16 to exclude 2002::f000/32. From owner-v6ops@ops.ietf.org Wed Oct 2 10:45:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22723 for ; Wed, 2 Oct 2002 10:45:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wkfq-0004QY-00 for v6ops-data@psg.com; Wed, 02 Oct 2002 07:40:26 -0700 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 17wkfm-0004Pu-00 for v6ops@ops.ietf.org; Wed, 02 Oct 2002 07:40:22 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id g92Ee1ks022566; Wed, 2 Oct 2002 16:40:02 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g92EdwoK048236; Wed, 2 Oct 2002 16:40:01 +0200 Received: from dhcp23-239.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA57972 from ; Wed, 2 Oct 2002 16:39:57 +0200 Message-Id: <3D9B0541.C59EF0A6@hursley.ibm.com> Date: Wed, 02 Oct 2002 16:40:01 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Fred L. Templin" Cc: v6ops@ops.ietf.org Subject: Re: Operational requirements for a unified 6to4/isatap/teredo/6over4/SIITsolution References: <3D9A024A.1000601@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I haven't been in any off line discussions, but I am dead against this. We should keep things simple and we should keep things modular. I oppose any overloading of the 2002:: address space, because overloading is evil. I oppose any attempt to reuse the name "6over4" beyond the clean, simple usage defined in RFC 2529. If you want to do something new, choose a new name, rather than overloading the old one. Brian "Fred L. Templin" wrote: > > Hello, > > Recent offline discussions have postulated a unified solution as a > "widely applicable" mechanism that may satisfy most of the deployment > scenarios envisioned by the design teams. (6to4, teredo, isatap, 6over4 > and SIIT have all been mentioned as candidates for unification.) Since > most of the unification would need to take place within the intra-site > scope, I propose that the name '6over4' be (re)adopted for that portion > of the unified scheme so that we would once again have: > > 6to4 + 6over4 > > as the unified solution (where "6over4" in this new sense combines the > necessary aspects of rfc 2529, teredo, isatap, etc.) A comment was made > during these discussions that, before any work on unification begins, > scenarios must be identified in which a unified solution would be more > useful than several seperate solutions. > > I am convinced that technical obstacles to realize such a unification are > minimal and could be specified in a (bis) on RFC 2529. But the comment on > identifying scenarios carries obvious operational implications - hence the > decision to bring this topic to v6ops. I have listed below two possible > scenarios in which a unified solution might be more useful than seperate > solutions, but I leave it to the community to debate the merits of these > scenarios and/or postulate others. As such, please direct all follow-up > discussion to the v6ops list. > > Sincerely, > > Fred Templin > ftemplin@iprg.nokia.com > > 1) Dual-stack router with native IPv6 connectivity > ************************************************** > The teredo specification ('shipworm-08.txt') deals with the "server" and "relay" > functions as seperable entitites. When the functions are implemented in seperate > boxes, the server cannot know in advance which relay will be used so it MUST > assign clients the Global Teredo IPv6 service prefix (defined in 'shipworm-08.txt' > as an IANA-assigned prefix of the form XXXX:XXXX/32). But, when the teredo server > and relay occur in the same box the paradigm is identical to that of the isatap > router function specified in 'isatap-04.txt'. > > The isatap router specification allows the advertisement of *any* globally routable > IPv6 prefix(es) to clients up to and including /64's; not just prefixes derived > from a specific IANA-assigned /32. By integrating the isatap router paradigm, the > unified solution would allow native IPv6 prefix advertisements when the server > and relay functions coincide, and whether isatap-style IPv6-in-IPv4 tunneling or > teredo-style IPv6-in-UDP/IPv4 tunneling are used. Also, isatap-04.txt specifies > a means for clients to discover and affiliate with multiple routers for the site. > This means could also be applied for teredo in a unified solution. > > 2) Teredo server requiring a mapped address > ******************************************* > The 'shipworm-08.txt' specification assumes that the teredo server address > will never require "mapping", as is required for teredo clients and that the > 32-bit server IPv4 address alone is needed. As such, the specification seeks > a /32 IANA assignment for the Global Teredo Service prefix. But, this decision > casts in stone the assumption of no mapping requirement for servers, since a /32 > assignment does not allow enough available bits (e.g., for encoding a 16-bit > server port number) for future applications. > > One possible reason for the /32 target procurement is the difficulty in obtaining > coarser-grained prefixes from IANA and unnecessary address space exhaustion. But, > the 6to4 example shows that /16 prefixes can be obtained if the need is justified. > In the case that a /16 simply cannot be procured, one alternative could be to claim > an unused /20 prefix for teredo that would allow enough bits for future expansion. > One such /20 exists that is currently unused (and unusable!) for other applications: > > 2002:f000::/20 > > This prefix is part of the 6to4 2002::/16, but is unused because it matches > the IPv4 "Class E" experimental address space. There are +'s and -'s assocaited > with claiming this /20 for teredo, however. On the '+' side, an otherwise-unusable > /20 would be put to good use and a unified address prefix for transition mechanisms > with room for expansion would be realized. On the '-' side, all 6to4 realys would > need to be modified to either also support the teredo relay function, or advertise > the subset of 2002::/16 to exclude 2002::f000/32. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-v6ops@ops.ietf.org Wed Oct 2 12:50:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28027 for ; Wed, 2 Oct 2002 12:50:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wmhV-0007ou-00 for v6ops-data@psg.com; Wed, 02 Oct 2002 09:50:17 -0700 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17wmhP-0007oh-00 for v6ops@ops.ietf.org; Wed, 02 Oct 2002 09:50:11 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id DC8946626; Wed, 2 Oct 2002 12:50:10 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 2 Oct 2002 12:50:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Operational requirements for a unified 6to4/isatap/teredo/6over4/SIIT solution Date: Wed, 2 Oct 2002 12:50:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9424@tayexc13.americas.cpqcorp.net> Thread-Topic: Operational requirements for a unified 6to4/isatap/teredo/6over4/SIIT solution Thread-Index: AcJphfFiDhsfIVgIRC6l4lr67TGwbwArZxFw From: "Bound, Jim" To: "Fred L. Templin" , X-OriginalArrivalTime: 02 Oct 2002 16:50:10.0631 (UTC) FILETIME=[C5545570:01C26A33] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA28027 Hi Fred, I agree with Brian' comment it should be new. Can you articulate for us exactly what the outcome of this is and its objective? Once I hear that it could be we are missing some pieces for this unification or maybe not but it is vague to me now? thanks /jim > -----Original Message----- > From: Fred L. Templin [mailto:ftemplin@IPRG.nokia.com] > Sent: Tuesday, October 01, 2002 4:15 PM > To: v6ops@ops.ietf.org > Subject: Operational requirements for a unified > 6to4/isatap/teredo/6over4/SIIT solution > > > Hello, > > Recent offline discussions have postulated a unified solution as a > "widely applicable" mechanism that may satisfy most of the deployment > scenarios envisioned by the design teams. (6to4, teredo, > isatap, 6over4 > and SIIT have all been mentioned as candidates for unification.) Since > most of the unification would need to take place within the intra-site > scope, I propose that the name '6over4' be (re)adopted for > that portion > of the unified scheme so that we would once again have: > > 6to4 + 6over4 > > as the unified solution (where "6over4" in this new sense combines the > necessary aspects of rfc 2529, teredo, isatap, etc.) A > comment was made > during these discussions that, before any work on unification begins, > scenarios must be identified in which a unified solution would be more > useful than several seperate solutions. > > I am convinced that technical obstacles to realize such a > unification are > minimal and could be specified in a (bis) on RFC 2529. But > the comment on > identifying scenarios carries obvious operational > implications - hence the > decision to bring this topic to v6ops. I have listed below > two possible > scenarios in which a unified solution might be more useful > than seperate > solutions, but I leave it to the community to debate the > merits of these > scenarios and/or postulate others. As such, please direct all > follow-up > discussion to the v6ops list. > > Sincerely, > > Fred Templin > ftemplin@iprg.nokia.com > > > > 1) Dual-stack router with native IPv6 connectivity > ************************************************** > The teredo specification ('shipworm-08.txt') deals with the > "server" and "relay" > functions as seperable entitites. When the functions are > implemented in seperate > boxes, the server cannot know in advance which relay will be > used so it MUST > assign clients the Global Teredo IPv6 service prefix (defined > in 'shipworm-08.txt' > as an IANA-assigned prefix of the form XXXX:XXXX/32). But, > when the teredo server > and relay occur in the same box the paradigm is identical to > that of the isatap > router function specified in 'isatap-04.txt'. > > The isatap router specification allows the advertisement of > *any* globally routable > IPv6 prefix(es) to clients up to and including /64's; not > just prefixes derived > from a specific IANA-assigned /32. By integrating the isatap > router paradigm, the > unified solution would allow native IPv6 prefix > advertisements when the server > and relay functions coincide, and whether isatap-style > IPv6-in-IPv4 tunneling or > teredo-style IPv6-in-UDP/IPv4 tunneling are used. Also, > isatap-04.txt specifies > a means for clients to discover and affiliate with multiple > routers for the site. > This means could also be applied for teredo in a unified solution. > > 2) Teredo server requiring a mapped address > ******************************************* > The 'shipworm-08.txt' specification assumes that the teredo > server address > will never require "mapping", as is required for teredo > clients and that the > 32-bit server IPv4 address alone is needed. As such, the > specification seeks > a /32 IANA assignment for the Global Teredo Service prefix. > But, this decision > casts in stone the assumption of no mapping requirement for > servers, since a /32 > assignment does not allow enough available bits (e.g., for > encoding a 16-bit > server port number) for future applications. > > One possible reason for the /32 target procurement is the > difficulty in obtaining > coarser-grained prefixes from IANA and unnecessary address > space exhaustion. But, > the 6to4 example shows that /16 prefixes can be obtained if > the need is justified. > In the case that a /16 simply cannot be procured, one > alternative could be to claim > an unused /20 prefix for teredo that would allow enough bits > for future expansion. > One such /20 exists that is currently unused (and unusable!) > for other applications: > > 2002:f000::/20 > > This prefix is part of the 6to4 2002::/16, but is unused > because it matches > the IPv4 "Class E" experimental address space. There are +'s > and -'s assocaited > with claiming this /20 for teredo, however. On the '+' side, > an otherwise-unusable > /20 would be put to good use and a unified address prefix for > transition mechanisms > with room for expansion would be realized. On the '-' side, > all 6to4 realys would > need to be modified to either also support the teredo relay > function, or advertise > the subset of 2002::/16 to exclude 2002::f000/32. > > > From owner-v6ops@ops.ietf.org Wed Oct 2 13:55:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01107 for ; Wed, 2 Oct 2002 13:55:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wnjX-0009eD-00 for v6ops-data@psg.com; Wed, 02 Oct 2002 10:56:27 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17wnjP-0009dy-00 for v6ops@ops.ietf.org; Wed, 02 Oct 2002 10:56:19 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 02 Oct 2002 10:56:16 -0700 Reply-To: From: "Tony Hain" To: "'Brian E Carpenter'" , "'Fred L. Templin'" Cc: Subject: RE: Operational requirements for a unified 6to4/isatap/teredo/6over4/SIITsolution Date: Wed, 2 Oct 2002 10:56:00 -0700 Message-ID: <051301c26a3c$f8ea1e70$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <3D9B0541.C59EF0A6@hursley.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA01107 Brian E Carpenter wrote: > I haven't been in any off line discussions, but I am dead > against this. We should keep things simple and we should keep > things modular. I strongly agree. For one any attempt to unifiy 6over4 & isatap will dilute their clear strengths. While each play in the space of the intranet, the fundemental technology difference of ipv4-multicast enabled vs. not provides each a clear deployment space. Any attempt to combine them will create a mechansim that is both more complex than 6over4, and restricted to the same subset of intranet deployments. Tony > > I oppose any overloading of the 2002:: address space, because > overloading is evil. > > I oppose any attempt to reuse the name "6over4" beyond the > clean, simple usage defined in RFC 2529. If you want to do > something new, choose a new name, rather than overloading the old one. > > Brian > > "Fred L. Templin" wrote: > > > > Hello, > > > > Recent offline discussions have postulated a unified solution as a > > "widely applicable" mechanism that may satisfy most of the > deployment > > scenarios envisioned by the design teams. (6to4, teredo, isatap, > > 6over4 and SIIT have all been mentioned as candidates for > > unification.) Since most of the unification would need to > take place > > within the intra-site scope, I propose that the name '6over4' be > > (re)adopted for that portion of the unified scheme so that we would > > once again have: > > > > 6to4 + 6over4 > > > > as the unified solution (where "6over4" in this new sense > combines the > > necessary aspects of rfc 2529, teredo, isatap, etc.) A comment was > > made during these discussions that, before any work on unification > > begins, scenarios must be identified in which a unified > solution would > > be more useful than several seperate solutions. > > > > I am convinced that technical obstacles to realize such a > unification > > are minimal and could be specified in a (bis) on RFC 2529. But the > > comment on identifying scenarios carries obvious operational > > implications - hence the decision to bring this topic to > v6ops. I have > > listed below two possible scenarios in which a unified > solution might > > be more useful than seperate solutions, but I leave it to the > > community to debate the merits of these scenarios and/or postulate > > others. As such, please direct all follow-up discussion to > the v6ops > > list. > > > > Sincerely, > > > > Fred Templin > > ftemplin@iprg.nokia.com > > > > 1) Dual-stack router with native IPv6 connectivity > > ************************************************** > > The teredo specification ('shipworm-08.txt') deals with the > "server" > > and "relay" functions as seperable entitites. When the > functions are > > implemented in seperate boxes, the server cannot know in > advance which > > relay will be used so it MUST assign clients the Global Teredo IPv6 > > service prefix (defined in 'shipworm-08.txt' as an IANA-assigned > > prefix of the form XXXX:XXXX/32). But, when the teredo server and > > relay occur in the same box the paradigm is identical to > that of the > > isatap router function specified in 'isatap-04.txt'. > > > > The isatap router specification allows the advertisement of *any* > > globally routable IPv6 prefix(es) to clients up to and including > > /64's; not just prefixes derived from a specific > IANA-assigned /32. By > > integrating the isatap router paradigm, the unified solution would > > allow native IPv6 prefix advertisements when the server and relay > > functions coincide, and whether isatap-style IPv6-in-IPv4 > tunneling or > > teredo-style IPv6-in-UDP/IPv4 tunneling are used. Also, > isatap-04.txt > > specifies a means for clients to discover and affiliate > with multiple > > routers for the site. This means could also be applied for > teredo in a > > unified solution. > > > > 2) Teredo server requiring a mapped address > > ******************************************* > > The 'shipworm-08.txt' specification assumes that the teredo server > > address will never require "mapping", as is required for teredo > > clients and that the 32-bit server IPv4 address alone is needed. As > > such, the specification seeks a /32 IANA assignment for the Global > > Teredo Service prefix. But, this decision casts in stone the > > assumption of no mapping requirement for servers, since a /32 > > assignment does not allow enough available bits (e.g., for > encoding a > > 16-bit server port number) for future applications. > > > > One possible reason for the /32 target procurement is the > difficulty > > in obtaining coarser-grained prefixes from IANA and unnecessary > > address space exhaustion. But, the 6to4 example shows that /16 > > prefixes can be obtained if the need is justified. In the > case that a > > /16 simply cannot be procured, one alternative could be to claim an > > unused /20 prefix for teredo that would allow enough bits > for future > > expansion. One such /20 exists that is currently unused (and > > unusable!) for other applications: > > > > 2002:f000::/20 > > > > This prefix is part of the 6to4 2002::/16, but is unused because it > > matches the IPv4 "Class E" experimental address space. > There are +'s > > and -'s assocaited with claiming this /20 for teredo, > however. On the > > '+' side, an otherwise-unusable /20 would be put to good use and a > > unified address prefix for transition mechanisms with room for > > expansion would be realized. On the '-' side, all 6to4 realys would > > need to be modified to either also support the teredo relay > function, > > or advertise the subset of 2002::/16 to exclude 2002::f000/32. > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment at the IBM Zurich Laboratory, Switzerland > From owner-v6ops@ops.ietf.org Wed Oct 2 14:54:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03202 for ; Wed, 2 Oct 2002 14:53:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17woeT-000BIr-00 for v6ops-data@psg.com; Wed, 02 Oct 2002 11:55:17 -0700 Received: from ftpbox.mot.com ([129.188.136.101]) by psg.com with esmtp (Exim 3.36 #1) id 17woeP-000BIf-00 for v6ops@ops.ietf.org; Wed, 02 Oct 2002 11:55:13 -0700 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA26635 for ; Wed, 2 Oct 2002 11:55:12 -0700 (MST)] Received: [from il06exm05.corp.mot.com (il06exm05.corp.mot.com [10.0.111.5]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id LAA18114 for ; Wed, 2 Oct 2002 11:55:12 -0700 (MST)] Received: by il06exm05.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 2 Oct 2002 13:54:26 -0500 Message-ID: From: Jung Cyndi-ACJ099 To: "'Fred L. Templin'" , v6ops@ops.ietf.org Subject: RE: Operational requirements for a unified 6to4/isatap/teredo/6ov er4/SIIT solution Date: Wed, 2 Oct 2002 13:54:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain X-Spam-Status: No, hits=2.6 required=5.0 tests=FROM_ENDS_IN_NUMS,DOUBLE_CAPSWORD,MSG_ID_ADDED_BY_MTA_3 version=2.31 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk I agree with Brian and Tony. Besides, a grand unified tool is just going to be one more tool - I thought v6ops was going to start from scenarios in different environments , examine the problems in each and show how the currentset of tools apply or reveal where we need another tool, but only with great justification create any new transition tools. On the other hand, if there is some additional benefit by making some of these tools work together, or if they can take advantage of the knowledge that they are co-located in the same system (say the 6to4 router at the ISP edge of an isatap or 6over4 domain), that might be worth identifying. Similarly, if there are some bad interactions between transition tools, those interactions need to be identified so people can avoid wasting time trying to make them work together. Cyndi -----Original Message----- From: Fred L. Templin [mailto:ftemplin@IPRG.nokia.com] Sent: Tuesday, October 01, 2002 1:15 PM To: v6ops@ops.ietf.org Subject: Operational requirements for a unified 6to4/isatap/teredo/6over4/SIIT solution Hello, Recent offline discussions have postulated a unified solution as a "widely applicable" mechanism that may satisfy most of the deployment scenarios envisioned by the design teams. (6to4, teredo, isatap, 6over4 and SIIT have all been mentioned as candidates for unification.) Since most of the unification would need to take place within the intra-site scope, I propose that the name '6over4' be (re)adopted for that portion of the unified scheme so that we would once again have: 6to4 + 6over4 as the unified solution (where "6over4" in this new sense combines the necessary aspects of rfc 2529, teredo, isatap, etc.) A comment was made during these discussions that, before any work on unification begins, scenarios must be identified in which a unified solution would be more useful than several seperate solutions. I am convinced that technical obstacles to realize such a unification are minimal and could be specified in a (bis) on RFC 2529. But the comment on identifying scenarios carries obvious operational implications - hence the decision to bring this topic to v6ops. I have listed below two possible scenarios in which a unified solution might be more useful than seperate solutions, but I leave it to the community to debate the merits of these scenarios and/or postulate others. As such, please direct all follow-up discussion to the v6ops list. Sincerely, Fred Templin ftemplin@iprg.nokia.com 1) Dual-stack router with native IPv6 connectivity ************************************************** The teredo specification ('shipworm-08.txt') deals with the "server" and "relay" functions as seperable entitites. When the functions are implemented in seperate boxes, the server cannot know in advance which relay will be used so it MUST assign clients the Global Teredo IPv6 service prefix (defined in 'shipworm-08.txt' as an IANA-assigned prefix of the form XXXX:XXXX/32). But, when the teredo server and relay occur in the same box the paradigm is identical to that of the isatap router function specified in 'isatap-04.txt'. The isatap router specification allows the advertisement of *any* globally routable IPv6 prefix(es) to clients up to and including /64's; not just prefixes derived from a specific IANA-assigned /32. By integrating the isatap router paradigm, the unified solution would allow native IPv6 prefix advertisements when the server and relay functions coincide, and whether isatap-style IPv6-in-IPv4 tunneling or teredo-style IPv6-in-UDP/IPv4 tunneling are used. Also, isatap-04.txt specifies a means for clients to discover and affiliate with multiple routers for the site. This means could also be applied for teredo in a unified solution. 2) Teredo server requiring a mapped address ******************************************* The 'shipworm-08.txt' specification assumes that the teredo server address will never require "mapping", as is required for teredo clients and that the 32-bit server IPv4 address alone is needed. As such, the specification seeks a /32 IANA assignment for the Global Teredo Service prefix. But, this decision casts in stone the assumption of no mapping requirement for servers, since a /32 assignment does not allow enough available bits (e.g., for encoding a 16-bit server port number) for future applications. One possible reason for the /32 target procurement is the difficulty in obtaining coarser-grained prefixes from IANA and unnecessary address space exhaustion. But, the 6to4 example shows that /16 prefixes can be obtained if the need is justified. In the case that a /16 simply cannot be procured, one alternative could be to claim an unused /20 prefix for teredo that would allow enough bits for future expansion. One such /20 exists that is currently unused (and unusable!) for other applications: 2002:f000::/20 This prefix is part of the 6to4 2002::/16, but is unused because it matches the IPv4 "Class E" experimental address space. There are +'s and -'s assocaited with claiming this /20 for teredo, however. On the '+' side, an otherwise-unusable /20 would be put to good use and a unified address prefix for transition mechanisms with room for expansion would be realized. On the '-' side, all 6to4 realys would need to be modified to either also support the teredo relay function, or advertise the subset of 2002::/16 to exclude 2002::f000/32. From owner-v6ops@ops.ietf.org Wed Oct 2 15:06:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03693 for ; Wed, 2 Oct 2002 15:06:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17woqH-000Bhx-00 for v6ops-data@psg.com; Wed, 02 Oct 2002 12:07:29 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17woqD-000BhT-00 for v6ops@ops.ietf.org; Wed, 02 Oct 2002 12:07:25 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA12445 for ; Wed, 2 Oct 2002 12:07:24 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g92J7O200594 for ; Wed, 2 Oct 2002 12:07:24 -0700 X-mProtect: <200210021907> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOKREBz; Wed, 02 Oct 2002 12:07:22 PDT Message-ID: <3D9B4795.90006@iprg.nokia.com> Date: Wed, 02 Oct 2002 12:23:01 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: Operational requirements for a unified 6to4/isatap/teredo/6over4/SIITsolution Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The comments on naming and prefix allocation are noted and appreciated. But, the main purpose of my original message was to initiate discussion within the community on the operational aspects of anticipated scenarios (which is consistent with my understanding of the v6ops charter.) I have gone to some trouble to initiate this discussion, and have done so *only* as a perceived professional responsibility to the community. It will be difficult for me to justify going to even more trouble if the operational aspects of my original message below are not thoroughly discussed within this forum. Fred ftemplin@iprg.nokia.com Fred L. Templin wrote: > Hello, > > Recent offline discussions have postulated a unified solution as a > "widely applicable" mechanism that may satisfy most of the deployment > scenarios envisioned by the design teams. (6to4, teredo, isatap, 6over4 > and SIIT have all been mentioned as candidates for unification.) Since > most of the unification would need to take place within the intra-site > scope, I propose that the name '6over4' be (re)adopted for that portion > of the unified scheme so that we would once again have: > > 6to4 + 6over4 > > as the unified solution (where "6over4" in this new sense combines the > necessary aspects of rfc 2529, teredo, isatap, etc.) A comment was made > during these discussions that, before any work on unification begins, > scenarios must be identified in which a unified solution would be more > useful than several seperate solutions. > > I am convinced that technical obstacles to realize such a unification are > minimal and could be specified in a (bis) on RFC 2529. But the comment on > identifying scenarios carries obvious operational implications - hence the > decision to bring this topic to v6ops. I have listed below two possible > scenarios in which a unified solution might be more useful than seperate > solutions, but I leave it to the community to debate the merits of these > scenarios and/or postulate others. As such, please direct all follow-up > discussion to the v6ops list. > > Sincerely, > > Fred Templin > ftemplin@iprg.nokia.com > > > > 1) Dual-stack router with native IPv6 connectivity > ************************************************** > The teredo specification ('shipworm-08.txt') deals with the "server" and "relay" > functions as seperable entitites. When the functions are implemented in seperate > boxes, the server cannot know in advance which relay will be used so it MUST > assign clients the Global Teredo IPv6 service prefix (defined in 'shipworm-08.txt' > as an IANA-assigned prefix of the form XXXX:XXXX/32). But, when the teredo server > and relay occur in the same box the paradigm is identical to that of the isatap > router function specified in 'isatap-04.txt'. > > The isatap router specification allows the advertisement of *any* globally routable > IPv6 prefix(es) to clients up to and including /64's; not just prefixes derived > from a specific IANA-assigned /32. By integrating the isatap router paradigm, the > unified solution would allow native IPv6 prefix advertisements when the server > and relay functions coincide, and whether isatap-style IPv6-in-IPv4 tunneling or > teredo-style IPv6-in-UDP/IPv4 tunneling are used. Also, isatap-04.txt specifies > a means for clients to discover and affiliate with multiple routers for the site. > This means could also be applied for teredo in a unified solution. > > 2) Teredo server requiring a mapped address > ******************************************* > The 'shipworm-08.txt' specification assumes that the teredo server address > will never require "mapping", as is required for teredo clients and that the > 32-bit server IPv4 address alone is needed. As such, the specification seeks > a /32 IANA assignment for the Global Teredo Service prefix. But, this decision > casts in stone the assumption of no mapping requirement for servers, since a /32 > assignment does not allow enough available bits (e.g., for encoding a 16-bit > server port number) for future applications. > > One possible reason for the /32 target procurement is the difficulty in obtaining > coarser-grained prefixes from IANA and unnecessary address space exhaustion. But, > the 6to4 example shows that /16 prefixes can be obtained if the need is justified. > In the case that a /16 simply cannot be procured, one alternative could be to claim > an unused /20 prefix for teredo that would allow enough bits for future expansion. > One such /20 exists that is currently unused (and unusable!) for other applications: > > 2002:f000::/20 > > This prefix is part of the 6to4 2002::/16, but is unused because it matches > the IPv4 "Class E" experimental address space. There are +'s and -'s assocaited > with claiming this /20 for teredo, however. On the '+' side, an otherwise-unusable > /20 would be put to good use and a unified address prefix for transition mechanisms > with room for expansion would be realized. On the '-' side, all 6to4 realys would > need to be modified to either also support the teredo relay function, or advertise > the subset of 2002::/16 to exclude 2002::f000/32. From owner-v6ops@ops.ietf.org Wed Oct 2 15:14:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04223 for ; Wed, 2 Oct 2002 15:14:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17woyr-000BzN-00 for v6ops-data@psg.com; Wed, 02 Oct 2002 12:16:21 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17woyo-000BzC-00 for v6ops@ops.ietf.org; Wed, 02 Oct 2002 12:16:18 -0700 Received: from kenawang.windriver.com ([128.224.4.101]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA10702; Wed, 2 Oct 2002 12:15:20 -0700 (PDT) Message-Id: <5.1.0.14.2.20021002151145.0312bcb0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 02 Oct 2002 15:17:11 -0400 To: Jung Cyndi-ACJ099 From: Margaret Wasserman Subject: RE: Operational requirements for a unified 6to4/isatap/teredo/6ov er4/SIIT solution Cc: "'Fred L. Templin'" , v6ops@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Cyndi, At 02:54 PM 10/2/02, Jung Cyndi-ACJ099 wrote: >I agree with Brian and Tony. Besides, a grand unified tool is just going to >be one >more tool - I thought v6ops was going to start from scenarios in different >environments , examine the problems in each and show how the currentset >of tools apply or reveal where we need another tool, but only with great >justification create any new transition tools. Yes, this is what we are chartered to do. Hopefully, in the course of this effort, we will analyze our scenarios and determine what sets of distinct requirements exist for tunneling solutions, and determine the right set of mechanisms to best meet those needs. Part of the analysis process will include understanding the strengths and weaknesses of various proposed solutions, and combining/modifying solutions as needed to create an architecturally sound and consistent set of solutions. This should include an overall understanding of how the solutions will interact and/or how a given node will determine which solutions to use (manual configuration, some type of auto-detection, etc.). Margaret From owner-v6ops@ops.ietf.org Mon Oct 7 09:27:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17847 for ; Mon, 7 Oct 2002 09:27:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17yXt2-0007PI-00 for v6ops-data@psg.com; Mon, 07 Oct 2002 06:25:28 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17yXsz-0007P4-00 for v6ops@ops.ietf.org; Mon, 07 Oct 2002 06:25:26 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g97DPMr24704; Mon, 7 Oct 2002 16:25:23 +0300 Date: Mon, 7 Oct 2002 16:25:22 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: mboned@network-services.uoregon.edu Subject: draft on IPv6 multicast issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.8 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello all, I've just sent a 7-page draft on IPv6 Multicast Deployment Issues to internet-drafts@ietf.org. In the meantime, it's available at: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-multicast-issues-00.txt The abstract is: There are many issues concerning the deployment and implementation, and to a lesser degree, specification of IPv6 multicast. This memo describes known problems, trying to raise awareness. Currently, global IPv6 interdomain multicast is completely impossible except using SSM: there is no way to convey information about multicast sources between PIM RPs. Site-scoped multicast is also problematic when used alongside to global multicast because of that. A few possible solutions are outlined or referred to. In addition, an issue regarding link-local multicast-blocking Ethernet switches is brought up. Finally, a feature request for MLD snooping switches is noted. The companion document on embedding the address of the RP in the multicast address will follow shortly. Comments are welcome, either directly or to the list(s) if appropriate. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Oct 7 12:20:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25486 for ; Mon, 7 Oct 2002 12:20:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17yaca-000C5i-00 for v6ops-data@psg.com; Mon, 07 Oct 2002 09:20:40 -0700 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by psg.com with esmtp (Exim 3.36 #1) id 17yacZ-000C5W-00 for v6ops@ops.ietf.org; Mon, 07 Oct 2002 09:20:39 -0700 Received: from newtwinkle.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id LAA26676; Mon, 7 Oct 2002 11:20:26 -0500 Message-Id: <5.1.1.6.2.20021007110904.02885410@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 07 Oct 2002 11:19:03 -0500 To: Pekka Savola From: Bill Nickless Subject: Re: draft on IPv6 multicast issues Cc: v6ops@ops.ietf.org, mboned@network-services.uoregon.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 04:25 PM 10/7/2002 +0300, Pekka Savola wrote: >Hello all, > >I've just sent a 7-page draft on IPv6 Multicast Deployment Issues to >internet-drafts@ietf.org. Please also see ftp://ftp.ietf.org/internet-drafts/draft-ietf-mboned-iesg-gap-analysis-00.txt Here's the abstract: An overview of IP multicast as deployed in the Internet today, from the perspective of the MBONED working group. Existing infrastructure is examined critically. Suggestions for possible improvement of the overall architecture are presented for the IESG. IPv6 multicast is included in this analysis. One of the concepts presented is that IGMP and MLD snooping might be discouraged, due to the complexity it requires on the part of the Ethernet switches. (Namely, interpretation of IPv4 and IPv6 datagrama.) Another concept presented is to change the many-to-one static mapping between IPv[46] multicast group addresses and IEEE MAC addresses, in favor of a dynamic mapping much like IPv4 ARP or IPv6 Neighbor Discovery. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov From owner-v6ops@ops.ietf.org Tue Oct 8 07:23:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06727 for ; Tue, 8 Oct 2002 07:23:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ysTG-000EVN-00 for v6ops-data@psg.com; Tue, 08 Oct 2002 04:24:14 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17ysTD-000EV9-00 for v6ops@ops.ietf.org; Tue, 08 Oct 2002 04:24:12 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g98BO4s02477; Tue, 8 Oct 2002 14:24:04 +0300 Date: Tue, 8 Oct 2002 14:24:04 +0300 (EEST) From: Pekka Savola To: Bill Nickless cc: v6ops@ops.ietf.org, Subject: Re: draft on IPv6 multicast issues In-Reply-To: <5.1.1.6.2.20021007110904.02885410@pop.mcs.anl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, On Mon, 7 Oct 2002, Bill Nickless wrote: > At 04:25 PM 10/7/2002 +0300, Pekka Savola wrote: > >Hello all, > > > >I've just sent a 7-page draft on IPv6 Multicast Deployment Issues to > >internet-drafts@ietf.org. > > Please also see > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mboned-iesg-gap-analysis-00.txt > > Here's the abstract: > > An overview of IP multicast as deployed in the Internet today, > from the perspective of the MBONED working group. Existing > infrastructure is examined critically. Suggestions for possible > improvement of the overall architecture are presented for the IESG. > > IPv6 multicast is included in this analysis. Thanks for the pointer, I had come across it earlier but hadn't looked into it much deeper. > One of the concepts presented is that IGMP and MLD snooping might be > discouraged, due to the complexity it requires on the part of the Ethernet > switches. (Namely, interpretation of IPv4 and IPv6 datagrama.) Agreed. > Another concept presented is to change the many-to-one static mapping > between IPv[46] multicast group addresses and IEEE MAC addresses, in favor > of a dynamic mapping much like IPv4 ARP or IPv6 Neighbor Discovery. This seems more like "nice to have in the future" issue, not absolutely criticial for present deployment. I'm adding appropriate pointers in the next revision, though. Thanks. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Oct 8 21:14:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05659 for ; Tue, 8 Oct 2002 21:14:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17z5NP-000CUq-00 for v6ops-data@psg.com; Tue, 08 Oct 2002 18:11:03 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17z5NN-000CUe-00 for v6ops@ops.ietf.org; Tue, 08 Oct 2002 18:11:01 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA05531; Tue, 8 Oct 2002 18:11:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g991AxT22854; Tue, 8 Oct 2002 18:10:59 -0700 X-mProtect: <200210090110> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdew2jFs; Tue, 08 Oct 2002 18:10:58 PDT Message-ID: <3DA385F1.5020207@iprg.nokia.com> Date: Tue, 08 Oct 2002 18:27:13 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org CC: lixia , "Fred L. Templin" Subject: Prior art on IPv6-in-IPv4 tunneling Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear friends, It has very recently been brought to my attention that a defining work on IPv6-in-IPv4 tunneling exists dating back to Spring 1998 and entitled: "Virtual Ethernet: A New Approach to IPv6 Transition" The work was prepared by a UCLA Masters Student named Quang Nguyen who was advised by Dr. Lixia Zhang. The document describes the case of intra-site tunneling when IPv4 multicast is deployed (as in 6over4) but also gives a detailed study of the case in which IPv4 multicast is absent (as in isatap). Upon examining the document, I realized that concepts presented in the isatap specification match up very closely with the prior art so I contacted Dr. Zhang to arrange a meeting to discuss the similarities. Dr. Zhang and I were able to meet today, and she has requested that an acknowledgement to her student and a reference to the document be given in the specification. This action will be taken asap in the next isatap draft revision. The document in question can be found at: http://irl.cs.ucla.edu/vet/report.ps I would encourage other v6ops/ngtrans authors to examine this work for prior art. For example, the isatap "automatic deprecation" and teredo "automatic sunset" functions seem to have existing precedence in this work. Sincerely, Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Oct 8 22:42:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07722 for ; Tue, 8 Oct 2002 22:42:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17z6mY-000G99-00 for v6ops-data@psg.com; Tue, 08 Oct 2002 19:41:06 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17z6mX-000G8x-00 for v6ops@ops.ietf.org; Tue, 08 Oct 2002 19:41:05 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 555B14B23 for ; Wed, 9 Oct 2002 11:41:04 +0900 (JST) To: v6ops@ops.ietf.org Subject: interim meeting minutes 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 From: itojun@iijlab.net Date: Wed, 09 Oct 2002 11:41:04 +0900 Message-Id: <20021009024104.555B14B23@coconut.itojun.org> X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk minutes from v6ops interim meeting is available at: http://www.6bone.net/v6ops/minutes/default.htm there are some "holes" specifically in breakout sessions. if you can send updates/fixes/whatever, it would be very nice. itojun From owner-v6ops@ops.ietf.org Wed Oct 9 02:33:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05191 for ; Wed, 9 Oct 2002 02:33:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zAOm-0000fs-00 for v6ops-data@psg.com; Tue, 08 Oct 2002 23:32:48 -0700 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 17zAOk-0000fg-00 for v6ops@ops.ietf.org; Tue, 08 Oct 2002 23:32:46 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id g996WLks014500; Wed, 9 Oct 2002 08:32:22 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g996WKWS026456; Wed, 9 Oct 2002 08:32:20 +0200 Received: from dhcp23-239.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34452 from ; Wed, 9 Oct 2002 08:32:17 +0200 Message-Id: <3DA3CD71.ADA251AB@hursley.ibm.com> Date: Wed, 09 Oct 2002 08:32:17 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Fred L. Templin" Cc: ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org, lixia Subject: Re: Prior art on IPv6-in-IPv4 tunneling References: <3DA385F1.5020207@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred, I'm not quite sure what point you are making here or why. That work was in fact the first implementation of 6over4 - the authors of RFC 2529 were in contact with Lixia Zhang and Quang Nguyen. The first publication was draft-carpenter-ipng-6over4-00.txt in November 1996, discussed at the IPNGWG meeting in December 1996. I agree that Quang Nguyen's paper was interesting and thought around the topic. But his code was 6over4 and the prior art for that is from November 1996. Both the authors of 6over4 have changed employers since then, but to the best of my knowledge no IPR claims were made. Of course the basic idea of tunnelling is older and trivial. Brian "Fred L. Templin" wrote: > > Dear friends, > > It has very recently been brought to my attention that a defining work > on IPv6-in-IPv4 tunneling exists dating back to Spring 1998 and entitled: > > "Virtual Ethernet: A New Approach to IPv6 Transition" > > The work was prepared by a UCLA Masters Student named Quang Nguyen > who was advised by Dr. Lixia Zhang. The document describes the case > of intra-site tunneling when IPv4 multicast is deployed (as in 6over4) > but also gives a detailed study of the case in which IPv4 multicast is > absent (as in isatap). > > Upon examining the document, I realized that concepts presented in > the isatap specification match up very closely with the prior art so > I contacted Dr. Zhang to arrange a meeting to discuss the similarities. > Dr. Zhang and I were able to meet today, and she has requested that an > acknowledgement to her student and a reference to the document be given > in the specification. This action will be taken asap in the next isatap > draft revision. > > The document in question can be found at: > > http://irl.cs.ucla.edu/vet/report.ps > > I would encourage other v6ops/ngtrans authors to examine this work for > prior art. For example, the isatap "automatic deprecation" and teredo > "automatic sunset" functions seem to have existing precedence in this > work. > > Sincerely, > > Fred Templin > ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Oct 9 09:24:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15231 for ; Wed, 9 Oct 2002 09:24:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zGna-000AuB-00 for v6ops-data@psg.com; Wed, 09 Oct 2002 06:22:50 -0700 Received: from parsmtp1.rd.francetelecom.com ([194.167.105.13]) by psg.com with esmtp (Exim 3.36 #1) id 17zGnX-000Att-00 for v6ops@ops.ietf.org; Wed, 09 Oct 2002 06:22:47 -0700 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 9 Oct 2002 15:22:46 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26F96.F47E48BB" X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: I-D ACTION:draft-noisette-v6ops-unmannet-isp-reqts-00.txt Date: Wed, 9 Oct 2002 15:22:45 +0200 Message-ID: Thread-Topic: RE: I-D ACTION:draft-noisette-v6ops-unmannet-isp-reqts-00.txt Thread-Index: AcJvlvYrSVGX5ewvTSWIdrVQDr+jWw== From: "NOISETTE Yoann FTRD/DMI/CAE" To: , , , X-OriginalArrivalTime: 09 Oct 2002 13:22:46.0545 (UTC) FILETIME=[F4F7C010:01C26F96] X-Spam-Status: No, hits=-1.5 required=5.0 tests=BIG_FONT,HTML_FONT_COLOR_BLUE,HTML_FONT_COLOR_RED, HTML_FONT_FACE_ODD,MAILTO_LINK,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,SUPERLONG_LINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C26F96.F47E48BB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've recently published an ID (see below), which aims at identifying the = requirements to deploy IPv6 unmanaged networks, from an ISP point of = view. This work encompasses topics that are (could be) addressed in the = ipv6, zeroconf WG and also in the current zerouter discussions. = Moreover, though v6ops appears in the title, I'm now convinced (after = the interim meeting resolutions) that this work doesn't fit in the mould = of this WG.=20 Nevertheless, this ID intends to identify the requirements which could = lead to the definition of new protocols, mechanisms or BCP in the = aforementioned context. As it is a first shot that needs to be = completed/commented, any feedback will be very welcome, if it is = considered of interest for any of the WG or mailing list quoted above. Yoann=20 -----Message d'origine----- De : Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Envoy=E9 : lundi 30 septembre 2002 13:45 Cc : ipng@sunroof.eng.sun.com; zeroconf@merit.edu Objet : I-D ACTION:draft-noisette-v6ops-unmannet-isp-reqts-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : ISP requirements for IPv6 unmanaged networks Author(s) : Y. Noisette Filename : draft-noisette-v6ops-unmannet-isp-reqts-00.txt Pages : 0 Date : 2002-9-27 =09 This document proposes to identify the elementary network functions = required to automatically deploy an IPv6 home network, i.e. with the = minimum (and ideally not a single) intervention from any administrator = or any user. The next generation Internet Protocol, IPv6, is expected to = being deployed in environments such as homes and SOHOs. However, most of = the people making use of the Internet at home don't have enough = knowledge to set up on their own the network and services. Therefore, = this document exposes the requirements necessary to ease such a = deployment, from an ISP point of view. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-noisette-v6ops-unmannet-isp-req= ts-00.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. 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-noisette-v6ops-unmannet-isp-reqts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-noisette-v6ops-unmannet-isp-reqts-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. NOISETTE Yoann &francetelecom R&D DMI/SIR/IPI 42, rue des Coutures - BP 6243 14066 CAEN Cedex 4 - FRANCE * : +33 (0)2.31.75.90.48 * : +33 (0)2.31.73.56.26 * mailto:yoann.noisette@francetelecom.com ------_=_NextPart_001_01C26F96.F47E48BB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D = ACTION:draft-noisette-v6ops-unmannet-isp-reqts-00.txt

Hi,

I've recently published an ID (see = below), which aims at identifying the requirements to deploy IPv6 = unmanaged networks, from an ISP point of view. This work encompasses = topics that are (could be) addressed in the ipv6, zeroconf WG and also = in the current zerouter discussions. Moreover, though v6ops appears in = the title, I'm now convinced (after the interim meeting resolutions) = that this work doesn't fit in the mould of this WG.

Nevertheless, this ID intends to = identify the requirements which could lead to the definition of new = protocols, mechanisms or BCP in the aforementioned context. As it is a = first shot that needs to be completed/commented, any feedback will be = very welcome, if it is considered of interest for any of the WG or = mailing list quoted above.

Yoann

-----Message = d'origine-----
De : Internet-Drafts@ietf.org = [mailto:Internet-Drafts@ietf.org<= /A>]
Envoy=E9 : lundi 30 septembre = 2002 13:45
Cc : ipng@sunroof.eng.sun.com; = zeroconf@merit.edu
Objet : I-D = ACTION:draft-noisette-v6ops-unmannet-isp-reqts-00.txt


A New Internet-Draft is available = from the on-line Internet-Drafts directories.


        Title   =         : ISP requirements for IPv6 = unmanaged networks
        Author(s)       : Y. = Noisette
        Filename        = : draft-noisette-v6ops-unmannet-isp-reqts-00.txt
        Pages   =         : 0
        Date    =         : 2002-9-27
       =20
This document proposes to = identify the elementary network functions required to automatically = deploy an IPv6 home network, i.e. with the minimum (and ideally not a = single) intervention from any administrator or any user. The next = generation Internet Protocol, IPv6, is expected to being deployed in = environments such as homes and SOHOs. However, most of the people making = use of the Internet at home don't have enough knowledge to set up on = their own the network and services. Therefore, this document exposes the = requirements necessary to ease such a deployment, from an ISP point of = view.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-noisette-v6o= ps-unmannet-isp-reqts-00.txt

To remove yourself from the IETF = Announcement list, send a message to
ietf-announce-request with the = word unsubscribe in the body of the message.

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-noisette-v6ops-unmannet-isp-reqts-00.txt".

A list of Internet-Drafts = directories can be found in
http://www.ietf.org/shadow.html<= /A>
or ftp://ftp.ietf.org/iet= f/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-noisette-v6ops-unmannet-isp-reqts-00.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will = enable a MIME compliant mail reader
implementation to automatically = retrieve the ASCII version of the
Internet-Draft.

NOISETTE Yoann
 &francetelecom R&D

              DMI/SIR/IPI
      42, rue des Coutures - BP 6243
      14066 CAEN Cedex 4 - = FRANCE

( : +33 (0)2.31.75.90.48    2 : +33 (0)2.31.73.56.26
* mailto:yoann.noisette@fr= ancetelecom.com


------_=_NextPart_001_01C26F96.F47E48BB-- From owner-v6ops@ops.ietf.org Wed Oct 9 12:46:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25125 for ; Wed, 9 Oct 2002 12:46:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zJzd-000FnF-00 for v6ops-data@psg.com; Wed, 09 Oct 2002 09:47:29 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17zJzb-000Fn3-00 for v6ops@ops.ietf.org; Wed, 09 Oct 2002 09:47:27 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA13742; Wed, 9 Oct 2002 09:47:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g99GlNn03229; Wed, 9 Oct 2002 09:47:23 -0700 X-mProtect: <200210091647> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdyUlk1F; Wed, 09 Oct 2002 09:47:21 PDT Message-ID: <3DA4616C.3050206@iprg.nokia.com> Date: Wed, 09 Oct 2002 10:03:40 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org CC: lixia , Brian E Carpenter , "Fred L. Templin" Subject: Re: Prior art on IPv6-in-IPv4 tunneling Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, Please don't get me wrong; I agree with the timeline you've outlined for 6over4 in relation to the work of Quang Nguyen who was advised by Dr. Zhang. My purpose is in flagging the fact that the Quang Nguyen paper also extends to the subject of intra-site automatic tunneling when IPv4 multicast is not available, where 6over4 (RFC 2529) does not. The unicast case represents the area covered by isatap, and now having seen the Quang Nguyen paper for the first time it is clear to me that isatap has independently re-created many aspects of this earlier work. Since isatap has been represented to the community for over 2yrs with no reference to the earlier work, I have a due dilligence responsibility to Quang Nguyen, Dr. Zhang and the community to make this known publicly and to outline my plans to remedy the shortcoming. At the same time, I am recommending that any other authors whose works on tunneling post-date the Quang Nguyen effort review this document for possible overlap with their work and give proper references if any such overlap exists. Does this make things clearer? Fred ftemplin@iprg.nokia.com Brian E Carpenter wrote: > Fred, > > I'm not quite sure what point you are making here or why. That work was > in fact the first implementation of 6over4 - the authors of RFC 2529 were > in contact with Lixia Zhang and Quang Nguyen. The first publication was > draft-carpenter-ipng-6over4-00.txt in November 1996, discussed at > the IPNGWG meeting in December 1996. > > I agree that Quang Nguyen's paper was interesting and thought around the > topic. But his code was 6over4 and the prior art for that is from > November 1996. Both the authors of 6over4 have changed employers since > then, but to the best of my knowledge no IPR claims were made. > > Of course the basic idea of tunnelling is older and trivial. > > Brian > > "Fred L. Templin" wrote: > >>Dear friends, >> >>It has very recently been brought to my attention that a defining work >>on IPv6-in-IPv4 tunneling exists dating back to Spring 1998 and entitled: >> >> "Virtual Ethernet: A New Approach to IPv6 Transition" >> >>The work was prepared by a UCLA Masters Student named Quang Nguyen >>who was advised by Dr. Lixia Zhang. The document describes the case >>of intra-site tunneling when IPv4 multicast is deployed (as in 6over4) >>but also gives a detailed study of the case in which IPv4 multicast is >>absent (as in isatap). >> >>Upon examining the document, I realized that concepts presented in >>the isatap specification match up very closely with the prior art so >>I contacted Dr. Zhang to arrange a meeting to discuss the similarities. >>Dr. Zhang and I were able to meet today, and she has requested that an >>acknowledgement to her student and a reference to the document be given >>in the specification. This action will be taken asap in the next isatap >>draft revision. >> >>The document in question can be found at: >> >> http://irl.cs.ucla.edu/vet/report.ps >> >>I would encourage other v6ops/ngtrans authors to examine this work for >>prior art. For example, the isatap "automatic deprecation" and teredo >>"automatic sunset" functions seem to have existing precedence in this >>work. >> >>Sincerely, >> >>Fred Templin >>ftemplin@iprg.nokia.com > From owner-v6ops@ops.ietf.org Wed Oct 9 12:50:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25251 for ; Wed, 9 Oct 2002 12:50:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zK4a-000Fxg-00 for v6ops-data@psg.com; Wed, 09 Oct 2002 09:52:36 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17zK4W-000FxU-00 for v6ops@ops.ietf.org; Wed, 09 Oct 2002 09:52:32 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA13955 for ; Wed, 9 Oct 2002 09:52:31 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g99GqV909459; Wed, 9 Oct 2002 09:52:31 -0700 X-mProtect: <200210091652> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdoWH9w4; Wed, 09 Oct 2002 09:52:29 PDT Message-ID: <3DA462A0.3020703@iprg.nokia.com> Date: Wed, 09 Oct 2002 10:08:48 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org CC: "Fred L. Templin" Subject: Re: Operational requirements for a unified 6to4/isatap/teredo/6over4/SIITsolution Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=2.2 required=5.0 tests=HOT_NASTY,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On this subject, I think plenty of time has gone by and I have seen no follow-up discussion. I recall Randy Bush saying something regarding silence as a determining factor at the v6ops interim meeting, but I believe he was only referring to official group concensus. In this case, I need to interpret things for myself and the silence is speaking volumes to me. I take this to mean one of the following: 1) No one cares about the subject 2) No one feels that the scenarios listed in my message carry operational concerns for v6ops As I have said, I have gone to some trouble to bring this discussion to the list, but the discussion has not been rejoined. With that in mind, it is going to be very difficult for me to justify going to even more trouble on the subject of a unified solution proposal. Fred ftemplin@iprg.nokia.com Fred L. Templin wrote: > The comments on naming and prefix allocation are noted and appreciated. > But, the main purpose of my original message was to initiate discussion > within the community on the operational aspects of anticipated scenarios > (which is consistent with my understanding of the v6ops charter.) I have > gone to some trouble to initiate this discussion, and have done so *only* > as a perceived professional responsibility to the community. It will be > difficult for me to justify going to even more trouble if the operational > aspects of my original message below are not thoroughly discussed within > this forum. > > Fred > ftemplin@iprg.nokia.com > > Fred L. Templin wrote: > >> Hello, >> >> Recent offline discussions have postulated a unified solution as a >> "widely applicable" mechanism that may satisfy most of the deployment >> scenarios envisioned by the design teams. (6to4, teredo, isatap, 6over4 >> and SIIT have all been mentioned as candidates for unification.) Since >> most of the unification would need to take place within the intra-site >> scope, I propose that the name '6over4' be (re)adopted for that portion >> of the unified scheme so that we would once again have: >> >> 6to4 + 6over4 >> >> as the unified solution (where "6over4" in this new sense combines the >> necessary aspects of rfc 2529, teredo, isatap, etc.) A comment was made >> during these discussions that, before any work on unification begins, >> scenarios must be identified in which a unified solution would be more >> useful than several seperate solutions. >> >> I am convinced that technical obstacles to realize such a unification are >> minimal and could be specified in a (bis) on RFC 2529. But the comment on >> identifying scenarios carries obvious operational implications - hence >> the >> decision to bring this topic to v6ops. I have listed below two possible >> scenarios in which a unified solution might be more useful than seperate >> solutions, but I leave it to the community to debate the merits of these >> scenarios and/or postulate others. As such, please direct all follow-up >> discussion to the v6ops list. >> >> Sincerely, >> >> Fred Templin >> ftemplin@iprg.nokia.com >> >> >> >> 1) Dual-stack router with native IPv6 connectivity >> ************************************************** >> The teredo specification ('shipworm-08.txt') deals with the "server" >> and "relay" >> functions as seperable entitites. When the functions are implemented >> in seperate >> boxes, the server cannot know in advance which relay will be used so >> it MUST >> assign clients the Global Teredo IPv6 service prefix (defined in >> 'shipworm-08.txt' >> as an IANA-assigned prefix of the form XXXX:XXXX/32). But, when the >> teredo server >> and relay occur in the same box the paradigm is identical to that of >> the isatap >> router function specified in 'isatap-04.txt'. >> >> The isatap router specification allows the advertisement of *any* >> globally routable >> IPv6 prefix(es) to clients up to and including /64's; not just >> prefixes derived >> from a specific IANA-assigned /32. By integrating the isatap router >> paradigm, the >> unified solution would allow native IPv6 prefix advertisements when >> the server >> and relay functions coincide, and whether isatap-style IPv6-in-IPv4 >> tunneling or >> teredo-style IPv6-in-UDP/IPv4 tunneling are used. Also, isatap-04.txt >> specifies >> a means for clients to discover and affiliate with multiple routers >> for the site. >> This means could also be applied for teredo in a unified solution. >> >> 2) Teredo server requiring a mapped address >> ******************************************* >> The 'shipworm-08.txt' specification assumes that the teredo server >> address >> will never require "mapping", as is required for teredo clients and >> that the >> 32-bit server IPv4 address alone is needed. As such, the specification >> seeks >> a /32 IANA assignment for the Global Teredo Service prefix. But, this >> decision >> casts in stone the assumption of no mapping requirement for servers, >> since a /32 >> assignment does not allow enough available bits (e.g., for encoding a >> 16-bit >> server port number) for future applications. >> >> One possible reason for the /32 target procurement is the difficulty >> in obtaining >> coarser-grained prefixes from IANA and unnecessary address space >> exhaustion. But, >> the 6to4 example shows that /16 prefixes can be obtained if the need >> is justified. >> In the case that a /16 simply cannot be procured, one alternative >> could be to claim >> an unused /20 prefix for teredo that would allow enough bits for >> future expansion. >> One such /20 exists that is currently unused (and unusable!) for other >> applications: >> >> 2002:f000::/20 >> >> This prefix is part of the 6to4 2002::/16, but is unused because it >> matches >> the IPv4 "Class E" experimental address space. There are +'s and -'s >> assocaited >> with claiming this /20 for teredo, however. On the '+' side, an >> otherwise-unusable >> /20 would be put to good use and a unified address prefix for >> transition mechanisms >> with room for expansion would be realized. On the '-' side, all 6to4 >> realys would >> need to be modified to either also support the teredo relay function, >> or advertise >> the subset of 2002::/16 to exclude 2002::f000/32. > > > From owner-v6ops@ops.ietf.org Wed Oct 9 14:42:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29119 for ; Wed, 9 Oct 2002 14:42:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zLnf-000JHa-00 for v6ops-data@psg.com; Wed, 09 Oct 2002 11:43:15 -0700 Received: from motgate2.mot.com ([136.182.1.10]) by psg.com with esmtp (Exim 3.36 #1) id 17zLnd-000JHO-00 for v6ops@ops.ietf.org; Wed, 09 Oct 2002 11:43:13 -0700 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA11929 for ; Wed, 9 Oct 2002 11:43:16 -0700 (MST)] Received: [from il06exb01.corp.mot.com (il06exb01.corp.mot.com [10.0.111.59]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id LAA03537 for ; Wed, 9 Oct 2002 11:43:11 -0700 (MST)] Received: by il06exb01.corp.mot.com with Internet Mail Service (5.5.2656.59) id <4SJT24WG>; Wed, 9 Oct 2002 13:43:11 -0500 Message-ID: From: Jung Cyndi-ACJ099 To: "'Brian E Carpenter'" , "Fred L. Templin" Cc: ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org, lixia Subject: RE: (ngtrans) Re: Prior art on IPv6-in-IPv4 tunneling Date: Wed, 9 Oct 2002 13:43:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=-2.9 required=5.0 tests=EXCHANGE_SERVER,FROM_ENDS_IN_NUMS,MSG_ID_ADDED_BY_MTA_3, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Fred, I can verify what Brian has said - I was about to say the same thing. As I recall, a 3Com switch to Lixia's lab was part of getting the project going. There are no IPR claims. At the time, the 6over4 draft had some language about what to do in case IPv4 multicast was not available, though that was removed (the thought at the time was that IPv4 multicast would be widely deployed long before IPv6 would be mature - how different things have turned out). When Microsoft Research implemented 6over4, and interoperability was established, the draft became RFC2529. Cyndi -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Tuesday, October 08, 2002 11:32 PM To: Fred L. Templin Cc: ngtrans@sunroof.eng.sun.com; v6ops@ops.ietf.org; lixia Subject: (ngtrans) Re: Prior art on IPv6-in-IPv4 tunneling Fred, I'm not quite sure what point you are making here or why. That work was in fact the first implementation of 6over4 - the authors of RFC 2529 were in contact with Lixia Zhang and Quang Nguyen. The first publication was draft-carpenter-ipng-6over4-00.txt in November 1996, discussed at the IPNGWG meeting in December 1996. I agree that Quang Nguyen's paper was interesting and thought around the topic. But his code was 6over4 and the prior art for that is from November 1996. Both the authors of 6over4 have changed employers since then, but to the best of my knowledge no IPR claims were made. Of course the basic idea of tunnelling is older and trivial. Brian "Fred L. Templin" wrote: > > Dear friends, > > It has very recently been brought to my attention that a defining work > on IPv6-in-IPv4 tunneling exists dating back to Spring 1998 and entitled: > > "Virtual Ethernet: A New Approach to IPv6 Transition" > > The work was prepared by a UCLA Masters Student named Quang Nguyen > who was advised by Dr. Lixia Zhang. The document describes the case > of intra-site tunneling when IPv4 multicast is deployed (as in 6over4) > but also gives a detailed study of the case in which IPv4 multicast is > absent (as in isatap). > > Upon examining the document, I realized that concepts presented in > the isatap specification match up very closely with the prior art so > I contacted Dr. Zhang to arrange a meeting to discuss the similarities. > Dr. Zhang and I were able to meet today, and she has requested that an > acknowledgement to her student and a reference to the document be given > in the specification. This action will be taken asap in the next isatap > draft revision. > > The document in question can be found at: > > http://irl.cs.ucla.edu/vet/report.ps > > I would encourage other v6ops/ngtrans authors to examine this work for > prior art. For example, the isatap "automatic deprecation" and teredo > "automatic sunset" functions seem to have existing precedence in this > work. > > Sincerely, > > Fred Templin > ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Oct 9 14:46:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29261 for ; Wed, 9 Oct 2002 14:46:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zLsn-000JRZ-00 for v6ops-data@psg.com; Wed, 09 Oct 2002 11:48:33 -0700 Received: from ftpbox.mot.com ([129.188.136.101]) by psg.com with esmtp (Exim 3.36 #1) id 17zLsm-000JRN-00 for v6ops@ops.ietf.org; Wed, 09 Oct 2002 11:48:32 -0700 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA27257 for ; Wed, 9 Oct 2002 11:48:31 -0700 (MST)] Received: [from il06exm05.corp.mot.com (il06exm05.corp.mot.com [10.0.111.5]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id LAA05391 for ; Wed, 9 Oct 2002 11:48:31 -0700 (MST)] Received: by il06exm05.corp.mot.com with Internet Mail Service (5.5.2656.59) id <4RKJ54H9>; Wed, 9 Oct 2002 13:47:45 -0500 Message-ID: From: Jung Cyndi-ACJ099 To: "'Fred L. Templin'" , ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org Cc: lixia , Brian E Carpenter Subject: RE: (ngtrans) Re: Prior art on IPv6-in-IPv4 tunneling Date: Wed, 9 Oct 2002 13:47:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=0.6 required=5.0 tests=EXCHANGE_SERVER,FROM_ENDS_IN_NUMS,MSG_ID_ADDED_BY_MTA_3, SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk By all means, acknowledge their work. Cyndi -----Original Message----- From: Fred L. Templin [mailto:ftemplin@iprg.nokia.com] Sent: Wednesday, October 09, 2002 10:04 AM To: ngtrans@sunroof.eng.sun.com; v6ops@ops.ietf.org Cc: lixia; Brian E Carpenter; Fred L. Templin Subject: (ngtrans) Re: Prior art on IPv6-in-IPv4 tunneling Brian, Please don't get me wrong; I agree with the timeline you've outlined for 6over4 in relation to the work of Quang Nguyen who was advised by Dr. Zhang. My purpose is in flagging the fact that the Quang Nguyen paper also extends to the subject of intra-site automatic tunneling when IPv4 multicast is not available, where 6over4 (RFC 2529) does not. The unicast case represents the area covered by isatap, and now having seen the Quang Nguyen paper for the first time it is clear to me that isatap has independently re-created many aspects of this earlier work. Since isatap has been represented to the community for over 2yrs with no reference to the earlier work, I have a due dilligence responsibility to Quang Nguyen, Dr. Zhang and the community to make this known publicly and to outline my plans to remedy the shortcoming. At the same time, I am recommending that any other authors whose works on tunneling post-date the Quang Nguyen effort review this document for possible overlap with their work and give proper references if any such overlap exists. Does this make things clearer? Fred ftemplin@iprg.nokia.com Brian E Carpenter wrote: > Fred, > > I'm not quite sure what point you are making here or why. That work was > in fact the first implementation of 6over4 - the authors of RFC 2529 were > in contact with Lixia Zhang and Quang Nguyen. The first publication was > draft-carpenter-ipng-6over4-00.txt in November 1996, discussed at > the IPNGWG meeting in December 1996. > > I agree that Quang Nguyen's paper was interesting and thought around the > topic. But his code was 6over4 and the prior art for that is from > November 1996. Both the authors of 6over4 have changed employers since > then, but to the best of my knowledge no IPR claims were made. > > Of course the basic idea of tunnelling is older and trivial. > > Brian > > "Fred L. Templin" wrote: > >>Dear friends, >> >>It has very recently been brought to my attention that a defining work >>on IPv6-in-IPv4 tunneling exists dating back to Spring 1998 and entitled: >> >> "Virtual Ethernet: A New Approach to IPv6 Transition" >> >>The work was prepared by a UCLA Masters Student named Quang Nguyen >>who was advised by Dr. Lixia Zhang. The document describes the case >>of intra-site tunneling when IPv4 multicast is deployed (as in 6over4) >>but also gives a detailed study of the case in which IPv4 multicast is >>absent (as in isatap). >> >>Upon examining the document, I realized that concepts presented in >>the isatap specification match up very closely with the prior art so >>I contacted Dr. Zhang to arrange a meeting to discuss the similarities. >>Dr. Zhang and I were able to meet today, and she has requested that an >>acknowledgement to her student and a reference to the document be given >>in the specification. This action will be taken asap in the next isatap >>draft revision. >> >>The document in question can be found at: >> >> http://irl.cs.ucla.edu/vet/report.ps >> >>I would encourage other v6ops/ngtrans authors to examine this work for >>prior art. For example, the isatap "automatic deprecation" and teredo >>"automatic sunset" functions seem to have existing precedence in this >>work. >> >>Sincerely, >> >>Fred Templin >>ftemplin@iprg.nokia.com > From owner-v6ops@ops.ietf.org Wed Oct 9 16:25:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03309 for ; Wed, 9 Oct 2002 16:25:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zNQ2-000Mdq-00 for v6ops-data@psg.com; Wed, 09 Oct 2002 13:26:58 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17zNQ0-000MdZ-00 for v6ops@ops.ietf.org; Wed, 09 Oct 2002 13:26:56 -0700 Received: from kenawang.windriver.com ([147.11.233.40]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA01503 for ; Wed, 9 Oct 2002 13:26:07 -0700 (PDT) Message-Id: <5.1.0.14.2.20021009162658.051cd890@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 09 Oct 2002 16:27:49 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Fwd: Re: draft: call for comments on accepting IDs into v6ops Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.9 required=5.0 tests=FWD_MSG,SPAM_PHRASE_01_02 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk v6ops Folks, At the interim meeting in Sunnyvale, we had consensus of the attendees to accept six Internet-Drafts as v6ops work items. This mail is intended to check that consensus with the v6ops list. Please let us know if you have any objections to accepting the following documents as v6ops work items: Survey of IPv4 Addresses in Currently Deployed IETF Standards (IPV4SURVVEY) Transition Mechanisms for IPv6 Hosts and Routers (MECH) Unmanaged Networks Transition Scope (UNMANSCOPE) Transition Scenarios for 3GPP Networks (3GPP-CASES) Transition Scenarios for ISP Networks (ISP-CASES) IPv6 Enterprise Networks Scenarios (ENT-V6NET) Thanks, Margaret & Itojun v6ops co-chairs From owner-v6ops@ops.ietf.org Thu Oct 10 05:35:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26445 for ; Thu, 10 Oct 2002 05:35:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zZj0-000G5d-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 02:35:22 -0700 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #1) id 17zZix-000G5P-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 02:35:20 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9A9ZHfw018332 for ; Thu, 10 Oct 2002 11:35:17 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9A9ZD7o008708 for ; Thu, 10 Oct 2002 11:35:17 +0200 Received: from dhcp222-5.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23700 from ; Thu, 10 Oct 2002 11:35:13 +0200 Message-Id: <3DA549D0.19BDC154@hursley.ibm.com> Date: Thu, 10 Oct 2002 11:35:12 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: IPv6 Operations Subject: Proposed 6to4 work Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.6 required=5.0 tests=NOSPAM_INC,SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'd like to propose that v6ops takes on the following items: Support for Multicast over 6to4 Networks (6TO4-MULTICAST) draft-ietf-ngtrans-6to4-multicast-01.txt (to be renamed draft-thaler-ngtrans-6to4-multicast-01.txt) Security Considerations for 6to4 draft-savola-ngtrans-6to4-security-01.txt Any future updates to RFC 3056 and RFC 3068. Brian From owner-v6ops@ops.ietf.org Thu Oct 10 07:21:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28597 for ; Thu, 10 Oct 2002 07:21:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zbOB-000IDb-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 04:21:59 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 17zbO8-000ICx-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 04:21:57 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9ABLje07580; Thu, 10 Oct 2002 14:21:45 +0300 Date: Thu, 10 Oct 2002 14:21:44 +0300 (EEST) From: Pekka Savola To: mboned@network-services.uoregon.edu cc: v6ops@ops.ietf.org, Brian Haberman Subject: New draft on embedding the RP address in IPv6 multicast address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.8 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, Me and Brian Haberman have submitted a new draft to internet-drafts@ietf.org. In the interim, it's available at: http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-mcast-rpaddr-00.txt "Embedding the Address of RP in IPv6 Multicast Address" Abstract As has been noticed, there is exists a huge deployment problem with global, interdomain IPv6 multicast: PIM RPs have no way of communicating the information about multicast sources to other multicast domains, as there is no MSDP, and the whole interdomain Any Source Multicast model is rendered unusable; SSM avoids these problems. This memo outlines a way to embed the address of the RP in the multicast address, solving the interdomain multicast problem. The problem is three-fold: specify an address format, adjust the operational procedures and configuration if necessary, and modify receiver-side PIM implementations. In consequence, there would be no need for interdomain MSDP. It's 9 pages. Comments are welcome, either directly or to the list(s) if appropriate. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Oct 10 07:31:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28936 for ; Thu, 10 Oct 2002 07:31:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zbYu-000ISl-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 04:33:04 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 17zbYs-000ISZ-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 04:33:03 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9ABWxQ07679; Thu, 10 Oct 2002 14:32:59 +0300 Date: Thu, 10 Oct 2002 14:32:59 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: IPv6 Operations Subject: Re: Proposed 6to4 work In-Reply-To: <3DA549D0.19BDC154@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 10 Oct 2002, Brian E Carpenter wrote: > I'd like to propose that v6ops takes on the following items: > > Support for Multicast over 6to4 Networks (6TO4-MULTICAST) > draft-ietf-ngtrans-6to4-multicast-01.txt > (to be renamed draft-thaler-ngtrans-6to4-multicast-01.txt) I'm a bit skeptic whether this can be made to work, and the fact that some 200 lines of comments I sent on the list on 11 Jul 2002 went unresponded didn't exactly help my skepticism.. > Security Considerations for 6to4 > draft-savola-ngtrans-6to4-security-01.txt The draft has focused on trying to spell out the filtering rules that could be done when implementing 6to4 .. but it takes no stance on "6to4 relay trust" issues. Those issues could be added if there's some thought how they can be solved (I can't think of any other than propagating more specific routes which doesn't seem to be an option). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Oct 10 08:16:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00281 for ; Thu, 10 Oct 2002 08:16:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zcFQ-000JIf-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 05:17:00 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17zcFG-000JIM-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 05:16:50 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id VAA27790 for ; Thu, 10 Oct 2002 21:16:48 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Thu, 10 Oct 2002 21:18:01 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zcFC-000GBH-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 21:16:46 +0900 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit From: "Marshall Eubanks" Subject: Re: New draft on embedding the RP address in IPv6 multicast address To: Pekka Savola , mboned@network-services.uoregon.edu Cc: v6ops@ops.ietf.org, Brian Haberman Date: Thu, 10 Oct 2002 08:11:54 -0400 X-Spam-Status: No, hits=-9.0 required=5.0 tests=DEAR_SOMEBODY,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_01_02 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On Thu, 10 Oct 2002 14:21:44 +0300 (EEST) Pekka Savola wrote: > Hello, > Dear Pekka; A quick question about Section 4 : o "plen" MUST NOT be 0 (ie. not SSM) o "plen" MUST NOT be greater than 96 The address of the RP can be obtained from a multicast address by taking the following steps: 1. take the last 96 bits of the multicast address 2. zero the last 128-"plen" bits, and 3. replace the last 4 bits with the contents of "RPad". If "plen" is = 1 (say), which seems to be allowed, then how do I zero the last 127 bits of a 96 bit slice of a multicast address ? I am pretty sure this is not what you mean, but this is what I read it to say. Regards Marshall Eubanks > Me and Brian Haberman have submitted a new draft to > internet-drafts@ietf.org. In the interim, it's available at: > > http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-mcast-rpaddr-00.txt > > "Embedding the Address of RP in IPv6 Multicast Address" > > Abstract > > As has been noticed, there is exists a huge deployment problem with > global, interdomain IPv6 multicast: PIM RPs have no way of > communicating the information about multicast sources to other > multicast domains, as there is no MSDP, and the whole interdomain Any > Source Multicast model is rendered unusable; SSM avoids these > problems. This memo outlines a way to embed the address of the RP in > the multicast address, solving the interdomain multicast problem. The > problem is three-fold: specify an address format, adjust the > operational procedures and configuration if necessary, and modify > receiver-side PIM implementations. In consequence, there would be no > need for interdomain MSDP. > > It's 9 pages. > > Comments are welcome, either directly or to the list(s) if appropriate. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > From owner-v6ops@ops.ietf.org Thu Oct 10 08:18:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00372 for ; Thu, 10 Oct 2002 08:18:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zcIh-000JMe-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 05:20:23 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 17zcIf-000JMR-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 05:20:22 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9ACKBl08143; Thu, 10 Oct 2002 15:20:11 +0300 Date: Thu, 10 Oct 2002 15:20:11 +0300 (EEST) From: Pekka Savola To: Marshall Eubanks cc: mboned@network-services.uoregon.edu, , Brian Haberman Subject: Re: New draft on embedding the RP address in IPv6 multicast address In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-11.6 required=5.0 tests=DEAR_SOMEBODY,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 10 Oct 2002, Marshall Eubanks wrote: > On Thu, 10 Oct 2002 14:21:44 +0300 (EEST) > Pekka Savola wrote: > > Hello, > > > > Dear Pekka; > > A quick question about Section 4 : > > o "plen" MUST NOT be 0 (ie. not SSM) > > o "plen" MUST NOT be greater than 96 > > The address of the RP can be obtained from a multicast address by > taking the following steps: > > 1. take the last 96 bits of the multicast address > > 2. zero the last 128-"plen" bits, and > > 3. replace the last 4 bits with the contents of "RPad". > > > If "plen" is = 1 (say), which seems to be allowed, then how do > I zero the last 127 bits of a 96 bit slice of a multicast address ? > > I am pretty sure this is not what you mean, but this is what I read it to say. The first bullet makes it implicit that those 96 bits are placed at the beginning of a 128-bit address struct (which is assumed to have been initialized to zero). But that should be clarified so there will be no misunderstandings, thanks. > Regards > Marshall Eubanks > > > > Me and Brian Haberman have submitted a new draft to > > internet-drafts@ietf.org. In the interim, it's available at: > > > > http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-mcast-rpaddr-00.txt > > > > "Embedding the Address of RP in IPv6 Multicast Address" > > > > Abstract > > > > As has been noticed, there is exists a huge deployment problem with > > global, interdomain IPv6 multicast: PIM RPs have no way of > > communicating the information about multicast sources to other > > multicast domains, as there is no MSDP, and the whole interdomain Any > > Source Multicast model is rendered unusable; SSM avoids these > > problems. This memo outlines a way to embed the address of the RP in > > the multicast address, solving the interdomain multicast problem. The > > problem is three-fold: specify an address format, adjust the > > operational procedures and configuration if necessary, and modify > > receiver-side PIM implementations. In consequence, there would be no > > need for interdomain MSDP. > > > > It's 9 pages. > > > > Comments are welcome, either directly or to the list(s) if appropriate. > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > > > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Oct 10 08:24:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00507 for ; Thu, 10 Oct 2002 08:24:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zcMV-000JRn-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 05:24:19 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 17zcMS-000JR5-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 05:24:16 -0700 Received: from kenawang.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA12710; Thu, 10 Oct 2002 05:22:54 -0700 (PDT) Message-Id: <5.1.0.14.2.20021010064706.029eec40@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 10 Oct 2002 08:24:30 -0400 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: Proposed 6to4 work Cc: IPv6 Operations In-Reply-To: <3DA549D0.19BDC154@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.7 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Brian, At 05:35 AM 10/10/02, Brian E Carpenter wrote: >I'd like to propose that v6ops takes on the following items: > >Support for Multicast over 6to4 Networks (6TO4-MULTICAST) > draft-ietf-ngtrans-6to4-multicast-01.txt > (to be renamed draft-thaler-ngtrans-6to4-multicast-01.txt) > >Security Considerations for 6to4 > draft-savola-ngtrans-6to4-security-01.txt Thanks for the submission. Dave and Pekka, do you think that these works are ready for consideration as v6ops work items? >Any future updates to RFC 3056 and RFC 3068. Our charter asserts that we would be responsible for any updates to these RFCs, but I don't know of any specific updates that have been proposed. Did I miss something? For the moment, let's talk about the two documents you listed above. As those of you who were at the Sunnyvale meeting may recall, we need to take several steps to accept a document into v6ops. For a document to become a WG work item, it must: - Fit within the WG charter (in the opinion of the chairs) Itojun and I will confer off-line and give an answer on this ASAP. But, in this particular case, let's start the next steps in parallel. - Have significant support from the working group, including: - People with expertise in all applicable areas who are willing to invest time to review the document, provide feedback, etc. Who has read either of these documents and would like to invest time in either of them as a v6ops work item? Obviously Brian. Are there others? Please be specific about which document(s) you are willing to work on. Also, are there folks with multicast and/or security backgrounds who are willing to review these documents? - Probable (or current) implementors, if applicable Has anyone implemented either of these I-Ds? Does anyone plan to implement them when they are more stable/complete? - Be accepted as a work item by a rough consensus of the WG - Should reflect WG belief that the document is taking the correct approach and would be a good starting place for a WG product Who has an opinion on whether we should/shouldn't accept these documents as work items? Please only reply to this if you have _read_ the document(s). This is not a general question like "should we work on multicast extensions to 6to4?" or "Is security important?", it is a specific question about whether or not to accept these documents as the basis for our work. Again, please be specific about which document you are discussing. Comments on the general approach taken in the documents? Are they correct and complete enough that we are ready to move editorial control of them to the WG? Authors, what are your opinions? Also, are the authors willing to serve as document editors if these documents are accepted? - Have corresponding goals/milestones in the charter - Approved by the Area Directors Itojun and I will work on this if/when the other pieces appear to be falling into line. Thanks, Margaret From owner-v6ops@ops.ietf.org Thu Oct 10 09:05:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02182 for ; Thu, 10 Oct 2002 09:05:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zd1r-000K8J-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 06:07:03 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 17zd1p-000K84-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 06:07:02 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9AD6u308546; Thu, 10 Oct 2002 16:06:56 +0300 Date: Thu, 10 Oct 2002 16:06:55 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: IPv6 Operations Subject: Re: Proposed 6to4 work (multicast) In-Reply-To: <5.1.0.14.2.20021010064706.029eec40@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-11.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I already commented but I'll do so directly and first only on multicast. On Thu, 10 Oct 2002, Margaret Wasserman wrote: > Our charter asserts that we would be responsible for any updates > to these RFCs, but I don't know of any specific updates that have > been proposed. Did I miss something? From the hip, so to speak, 3056: some nits about security considerations possibly. 3068: possibly whether the ipv4 anycast address can be used as the source address when the relay tunnels packets > - Have significant support from the working group, including: > - People with expertise in all applicable areas who are > willing > to invest time to review the document, provide feedback, > etc. > > Who has read either of these documents and would like to invest time in > either of them as a v6ops work item? Obviously Brian. Are there others? > Please be specific about which document(s) you are willing to work on. > Also, are there folks with multicast and/or security backgrounds who > are willing to review these documents? > > - Probable (or current) implementors, if applicable > > Has anyone implemented either of these I-Ds? Does anyone plan to > implement them when they are more stable/complete? > > - Be accepted as a work item by a rough consensus of the WG > - Should reflect WG belief that the document is taking the > correct approach and would be a good starting place for > a WG product > > Who has an opinion on whether we should/shouldn't accept these > documents as work items? Please only reply to this if you have _read_ > the document(s). This is not a general question like "should we work > on multicast extensions to 6to4?" or "Is security important?", it is a > specific question about whether or not to accept these documents as > the basis for our work. Again, please be specific about which document > you are discussing. > > Comments on the general approach taken in the documents? Are they > correct and complete enough that we are ready to move editorial control > of them to the WG? Authors, what are your opinions? First I'll answer the question you *didn't* ask: I believe it would be good to have "multicast extensions to 6to4" but only if they're sufficiently simple and actually workable. As for the question you did ask, I don't really think the proposed solution at least currently satisfies these requirements. At the very least the applicability would have to be restricted and a few cases that make it more complex be cut away. But if there is sufficient momentum from the others in the w.g., I'm still willing to work on the draft trying to salvage it. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Oct 10 09:17:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02605 for ; Thu, 10 Oct 2002 09:17:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zdD7-000KLr-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 06:18:41 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 17zdD5-000KLS-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 06:18:39 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9ADIII08669; Thu, 10 Oct 2002 16:18:18 +0300 Date: Thu, 10 Oct 2002 16:18:18 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: IPv6 Operations Subject: Re: Proposed 6to4 work (security) In-Reply-To: <5.1.0.14.2.20021010064706.029eec40@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 10 Oct 2002, Margaret Wasserman wrote: > Dave and Pekka, do you think that these works are ready for consideration > as v6ops work items? Depending on what v6ops wants. I believe my security draft is quite complete, as far as filtering goes, but if the community wants to extend it somehow (e.g. relay issues) that's another thing. > - Probable (or current) implementors, if applicable > > Has anyone implemented either of these I-Ds? Does anyone plan to > implement them when they are more stable/complete? Some of the checks are already in the implementations, but not a complete set. I believe the whole set also will be. > Comments on the general approach taken in the documents? Are they > correct and complete enough that we are ready to move editorial control > of them to the WG? Authors, what are your opinions? With the current scope, it's quite ready I think. > Also, are the authors willing to serve as document editors if these > documents are accepted? Sure. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Oct 10 13:27:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16297 for ; Thu, 10 Oct 2002 13:27:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zh5e-000Plm-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 10:27:14 -0700 Received: from ncsmtp03.ogw.rr.com ([24.93.67.84]) by psg.com with esmtp (Exim 3.36 #2) id 17zh5d-000PlS-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 10:27:13 -0700 Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9AHQpiZ012416; Thu, 10 Oct 2002 13:26:51 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 10 Oct 2002 13:26:59 -0400 Message-ID: <3DA5B917.1000900@nc.rr.com> Date: Thu, 10 Oct 2002 13:29:59 -0400 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marshall Eubanks CC: "Mike O'Connor" , Pekka Savola , mboned@network-services.uoregon.edu, v6ops@ops.ietf.org, nesg@es.net Subject: Re: New draft on embedding the RP address in IPv6 multicast address References: <2F7B93351D2DC54AAC898E8325DEEAA6220229@mail.esn.es.net> <3DA5A7B6.5080007@multicasttech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.4 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marshall Eubanks wrote: > Yes, I think so, this requires interdomain flooding, just like > interdomain MSDP in IPv4. Actually, I don't think it does. See comments below. > > However, you might be able to make ASM "SSM like" in that, if you > find the group address by some means out of band, you can join to the RP > and either send or receive. This is actually what is expected to happen. The steps look like: 1. A receiver finds out a group address from some means (e.g. SDR or a web page) 2. The receiver issues an MLD Report Joining the group 3. The receiver's DR will initiate the PIM Join process 4. The Join message flows up to the receivers RP 5. The RP recognizes the embedded RP format and extracts the owning RP address 6. The receiver's RP issues an SPT join to the owning RP and creates forwarding state One possible optimization is that the receiver's DR could issue the SPT to the owning RP. The sender side has two cases. 1. A sender in the owning domain. Nothing should be different here. 2. A sender in a foreign domain. This is the case that I have to do some work on. In order for a receiver in another domain to know about this sender, information will have to flow to the owning RP. > > It is also not clear to me how this would work in, say, a > teleconference. Doesn't it limit the group to only _one_ RP? What > functionality does it give that either SSM or MSDP doesn't ? One big advantage is the removal of inter-domain MSDP state. And the use of one RP is a downside of this approach. Brian From owner-v6ops@ops.ietf.org Thu Oct 10 13:38:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16672 for ; Thu, 10 Oct 2002 13:38:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zhIU-0000AV-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 10:40:30 -0700 Received: from ncsmtp03.ogw.rr.com ([24.93.67.84]) by psg.com with esmtp (Exim 3.36 #2) id 17zhIT-0000AG-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 10:40:29 -0700 Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9AHeBiZ027207; Thu, 10 Oct 2002 13:40:11 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 10 Oct 2002 13:40:18 -0400 Message-ID: <3DA5BC37.5050200@nc.rr.com> Date: Thu, 10 Oct 2002 13:43:19 -0400 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mike O'Connor" CC: Marshall Eubanks , Pekka Savola , mboned@network-services.uoregon.edu, v6ops@ops.ietf.org, nesg@es.net Subject: Re: New draft on embedding the RP address in IPv6 multicast address References: <2F7B93351D2DC54AAC898E8325DEEAA614C6FD@mail.esn.es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.1 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mike O'Connor wrote: > Marshall, > > I wasn't sure how the four bit RPad field is used, but the thought of a > single RP limitation occurred to me as well. I don't think that even if > the RPad allows for 16 RP's per group address it is large enough. There > have already been Access Grid conferences that have had thirty sites > join, each with their own RP. It's probably not a good idea to propose a > number that's already too small:) If there were 16 RP's per PIM domain > it might be enough. The 4-bit RPad is a strawman. The existing field is actually 8 bits wide, so it is possible to extend it. That is the kind of feedback that I would like to see on this. What are the operational issues that could pop up. Brian From owner-v6ops@ops.ietf.org Thu Oct 10 13:46:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17313 for ; Thu, 10 Oct 2002 13:45:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zhPd-0000MN-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 10:47:53 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 17zhPZ-0000MB-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 10:47:49 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9AHlCu11204; Thu, 10 Oct 2002 20:47:12 +0300 Date: Thu, 10 Oct 2002 20:47:12 +0300 (EEST) From: Pekka Savola To: "Mike O'Connor" cc: Marshall Eubanks , , , Brian Haberman , Subject: RE: New draft on embedding the RP address in IPv6 multicast address In-Reply-To: <2F7B93351D2DC54AAC898E8325DEEAA614C6FD@mail.esn.es.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-11.6 required=5.0 tests=DEAR_SOMEBODY,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 10 Oct 2002, Mike O'Connor wrote: > I wasn't sure how the four bit RPad field is used, but the thought of a > single RP limitation occurred to me as well. I don't think that even if > the RPad allows for 16 RP's per group address it is large enough. There > have already been Access Grid conferences that have had thirty sites > join, each with their own RP. It's probably not a good idea to propose a > number that's already too small:) If there were 16 RP's per PIM domain > it might be enough. Note that the proposed mechanism allows for _one_ RP per _group_, and 16 RP's per PIM domain. Perhaps you misunderstood the reason of "RPad". > -----Original Message----- > From: Marshall Eubanks [mailto:tme@multicasttech.com] > Sent: Thursday, October 10, 2002 12:16 PM > To: Mike O'Connor > Cc: Pekka Savola; mboned@network-services.uoregon.edu; > v6ops@ops.ietf.org; Brian Haberman; nesg@es.net > Subject: Re: New draft on embedding the RP address in IPv6 multicast > address > > > Yes, I think so, this requires interdomain flooding, just like > interdomain MSDP in IPv4. > > However, you might be able to make ASM "SSM like" in that, if you find > the group address by some means out of band, you can join to the RP > and either send or receive. > > It is also not clear to me how this would work in, say, a > teleconference. Doesn't it limit the group to only _one_ RP? What > functionality does it give that either SSM or MSDP doesn't ? > > Marshall > > Mike O'Connor wrote: > > If all source active advertisements are carried in PIM packets won't > > we need to flood and prune our local source PIM packets to all or our > > interdomain neighbors? Would this draft accommodate PIM sparse mode? > > > > -Mike > > > > -- > > Mike O'Connor, E-mail: moc@es.net > > Network Engineer Energy Sciences Network (ESnet) > > East coast: +1 631 344-7410 West coast: +1 510 486-7421 > > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > > > > > > > > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Thursday, October 10, 2002 8:20 AM > > To: Marshall Eubanks > > Cc: mboned@network-services.uoregon.edu; v6ops@ops.ietf.org; Brian > > Haberman > > Subject: Re: New draft on embedding the RP address in IPv6 multicast > > address > > > > > > On Thu, 10 Oct 2002, Marshall Eubanks wrote: > > > >>On Thu, 10 Oct 2002 14:21:44 +0300 (EEST) > >> Pekka Savola wrote: > >> > >>>Hello, > >>> > >> > >>Dear Pekka; > >> > >> A quick question about Section 4 : > >> > >> o "plen" MUST NOT be 0 (ie. not SSM) > >> > >> o "plen" MUST NOT be greater than 96 > >> > >> The address of the RP can be obtained from a multicast address by > >> taking the following steps: > >> > >> 1. take the last 96 bits of the multicast address > >> > >> 2. zero the last 128-"plen" bits, and > >> > >> 3. replace the last 4 bits with the contents of "RPad". > >> > >> > >>If "plen" is = 1 (say), which seems to be allowed, then how do I zero > >>the last 127 bits of a 96 bit slice of a multicast address ? > >> > >>I am pretty sure this is not what you mean, but this is what I read it > > > > > >>to say. > > > > > > The first bullet makes it implicit that those 96 bits are placed at > > the > > beginning of a 128-bit address struct (which is assumed to have been > > initialized to zero). > > > > But that should be clarified so there will be no misunderstandings, > > thanks. > > > > > > > >>Regards > >>Marshall Eubanks > >> > >> > >> > >>>Me and Brian Haberman have submitted a new draft to > >>>internet-drafts@ietf.org. In the interim, it's available at: > >>> > >>>http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-mcast-rpaddr-0 > >>>0.txt > >>> > >>> "Embedding the Address of RP in IPv6 Multicast Address" > >>> > >>>Abstract > >>> > >>> As has been noticed, there is exists a huge deployment problem > >> > > with > > > >>> global, interdomain IPv6 multicast: PIM RPs have no way of > >> > > > >>> communicating the information about multicast sources to other > >>> multicast domains, as there is no MSDP, and the whole interdomain > >> > > Any > > > >>> Source Multicast model is rendered unusable; SSM avoids these > >> > > > >>> problems. This memo outlines a way to embed the address of the > >> > > RP in > > > >>> the multicast address, solving the interdomain multicast problem. > >> > > The > > > >>> problem is three-fold: specify an address format, adjust the > >> > > > >>> operational procedures and configuration if necessary, and modify > >>> receiver-side PIM implementations. In consequence, there would > >> > > be no > > > >>> need for interdomain MSDP. > >>> > >>>It's 9 pages. > >>> > >>>Comments are welcome, either directly or to the list(s) if > >>>appropriate. > >>> > >>>-- > >>>Pekka Savola "Tell me of difficulties surmounted, > >>>Netcore Oy not those you stumble over and fall" > >>>Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > >>> > >>> > >>> > >>> > >>> > >>> > >> > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Oct 10 13:51:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17571 for ; Thu, 10 Oct 2002 13:51:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zhV6-0000WL-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 10:53:32 -0700 Received: from ncsmtp03.ogw.rr.com ([24.93.67.84]) by psg.com with esmtp (Exim 3.36 #2) id 17zhV5-0000W9-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 10:53:31 -0700 Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9AHr9iZ011948; Thu, 10 Oct 2002 13:53:09 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 10 Oct 2002 13:53:19 -0400 Message-ID: <3DA5BF40.9070205@nc.rr.com> Date: Thu, 10 Oct 2002 13:56:16 -0400 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mike O'Connor" CC: Marshall Eubanks , Pekka Savola , mboned@network-services.uoregon.edu, v6ops@ops.ietf.org, nesg@es.net Subject: Re: New draft on embedding the RP address in IPv6 multicast address References: <2F7B93351D2DC54AAC898E8325DEEAA614C6FE@mail.esn.es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.1 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mike O'Connor wrote: > Hi Brian, > > I don't understand how the reciever's RP receives the "owning RP" > address for a given multicast group. How are the "owning RP" addresses > distributed between domains without PIM flooding? The RP address is embedded in the multicast address. The key is in the assignment of multicast addresses in a domain and the configuration of RP addresses. So, if a domain uses prefix 3ffe:1:2::/48. It places an RP in the network and gives it an address of 3ffe:1:2:3::5. Now, this RP can be the RP for the multicast address range FF7x:0540:3ffe:1:2:3::/96. The key is that the IID portion of the RP's address is set to a value that can be encode in the RPad field of the multicast address. The mcast groups are distinguished by the lower 32 bits of the address. Now, a receiver's RP can examine the multicast address when it is creating state and reconstruct the owning RP's address by extracting the network prefix value and appending the RPad field. Brian From owner-v6ops@ops.ietf.org Thu Oct 10 14:54:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19675 for ; Thu, 10 Oct 2002 14:54:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17ziT2-0002Cl-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 11:55:28 -0700 Received: from ncsmtp02.ogw.rr.com ([24.93.67.83]) by psg.com with esmtp (Exim 3.36 #2) id 17ziSz-0002CY-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 11:55:26 -0700 Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9AItLv3024523; Thu, 10 Oct 2002 14:55:25 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 10 Oct 2002 14:55:13 -0400 Message-ID: <3DA5CDC2.2020008@nc.rr.com> Date: Thu, 10 Oct 2002 14:58:10 -0400 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mike O'Connor" CC: Marshall Eubanks , Pekka Savola , mboned@network-services.uoregon.edu, v6ops@ops.ietf.org, nesg@es.net Subject: Re: New draft on embedding the RP address in IPv6 multicast address References: <2F7B93351D2DC54AAC898E8325DEEAA614C6FF@mail.esn.es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.1 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mike, Mike O'Connor wrote: > Brian, > > Is there an underlying assumption that a given group has all of it's > sources in one PIM domain? In a previous append, I pointed out that there is still an open issue with a sender being outside of the PIM domain that allocated the address. > > ASM in V4 doesn't restrict the number of RP's per multicast group. How > does the proposal support an ASM conference where all participants are > in different AS/PIM domains and each is both sender and receiver with > it's own RP? I'm seeing this as supporting SSM but not ASM. Why would SSM need an RP? SSM support is a part of RFC 3306, which this approach is based on. Brian From owner-v6ops@ops.ietf.org Thu Oct 10 15:37:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21134 for ; Thu, 10 Oct 2002 15:37:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zj9e-0003cu-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 12:39:30 -0700 Received: from moebius2.space.net ([195.30.1.100] ident=qmailr) by psg.com with smtp (Exim 3.36 #2) id 17zj9d-0003ci-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 12:39:29 -0700 Received: (qmail 49423 invoked by uid 1007); 10 Oct 2002 19:39:27 -0000 Date: Thu, 10 Oct 2002 21:39:27 +0200 From: Gert Doering To: Brian Haberman Cc: "Mike O'Connor" , Marshall Eubanks , Pekka Savola , mboned@network-services.uoregon.edu, v6ops@ops.ietf.org, nesg@es.net Subject: Re: New draft on embedding the RP address in IPv6 multicast address Message-ID: <20021010213927.S80239@Space.Net> References: <2F7B93351D2DC54AAC898E8325DEEAA614C6FF@mail.esn.es.net> <3DA5CDC2.2020008@nc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DA5CDC2.2020008@nc.rr.com>; from bkhabs@nc.rr.com on Thu, Oct 10, 2002 at 02:58:10PM -0400 X-NCC-RegID: de.space X-Spam-Status: No, hits=-15.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Thu, Oct 10, 2002 at 02:58:10PM -0400, Brian Haberman wrote: > Mike O'Connor wrote: > > Is there an underlying assumption that a given group has all of it's > > sources in one PIM domain? > > In a previous append, I pointed out that there is still an > open issue with a sender being outside of the PIM domain that > allocated the address. Just an idea. What about sending a PIM register from the sender's RP to the RP that belongs to the multicast address? It would need another protocol change, of course. gert -- Total number of prefixes smaller than registry allocations: 47686 (47095) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Thu Oct 10 15:44:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21306 for ; Thu, 10 Oct 2002 15:44:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zjG6-0003sq-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 12:46:10 -0700 Received: from ncsmtp03.ogw.rr.com ([24.93.67.84]) by psg.com with esmtp (Exim 3.36 #2) id 17zjG3-0003sa-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 12:46:07 -0700 Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9AJjsiZ010170; Thu, 10 Oct 2002 15:45:54 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 10 Oct 2002 15:46:02 -0400 Message-ID: <3DA5D9AE.4090407@nc.rr.com> Date: Thu, 10 Oct 2002 15:49:02 -0400 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gert Doering CC: mboned@network-services.uoregon.edu, v6ops@ops.ietf.org Subject: Re: New draft on embedding the RP address in IPv6 multicast address References: <2F7B93351D2DC54AAC898E8325DEEAA614C6FF@mail.esn.es.net> <3DA5CDC2.2020008@nc.rr.com> <20021010213927.S80239@Space.Net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.1 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Gert Doering wrote: > Hi, > > On Thu, Oct 10, 2002 at 02:58:10PM -0400, Brian Haberman wrote: > >>Mike O'Connor wrote: >> >>>Is there an underlying assumption that a given group has all of it's >>>sources in one PIM domain? >> >> In a previous append, I pointed out that there is still an >>open issue with a sender being outside of the PIM domain that >>allocated the address. > > > Just an idea. What about sending a PIM register from the sender's RP > to the RP that belongs to the multicast address? It would need another > protocol change, of course. It can lead to a DoS attack on the embedded address. A bad guy could embed any address in the multicast address that it wants to attack. So using register messages would require some type of authentication mechanism. Brian From owner-v6ops@ops.ietf.org Thu Oct 10 17:47:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25289 for ; Thu, 10 Oct 2002 17:47:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zl8z-0007vM-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 14:46:57 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 17zl8y-0007vA-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 14:46:56 -0700 Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21917 for ; Thu, 10 Oct 2002 15:46:55 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H3S008D9CI6L6@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 10 Oct 2002 15:46:54 -0600 (MDT) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H3S0065NCI5GE@mail.sun.net> for v6ops@ops.ietf.org; Thu, 10 Oct 2002 15:46:54 -0600 (MDT) Date: Thu, 10 Oct 2002 14:45:50 -0700 From: Alain Durand Subject: Re: Proposed 6to4 work (security) To: IPv6 Operations Cc: Pekka Savola , Margaret Wasserman Message-id: <3DA5F50E.3080908@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020719 Netscape/7.0 References: X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Pekka Savola wrote: >On Thu, 10 Oct 2002, Margaret Wasserman wrote: > > >>Dave and Pekka, do you think that these works are ready for consideration >>as v6ops work items? >> >> > >Depending on what v6ops wants. I believe my security draft is quite >complete, as far as filtering goes, but if the community wants to extend >it somehow (e.g. relay issues) that's another thing. > I think the relay issue is very serious but I'm not sure there is any satisfying solution. Documenting it is probably a good start. There are also some issues aboout RFC3068, as there are very little public relays available today. We need to understand if this is just because we are still very early in IPv6 deployment or if it is because there is a fundamental problem in the model. As about multicast, I tend to agree with Pekka, yes multicast would be a nice thing to have, but I think we need first to undertand how critical it is in the various scenario documents. - Alain. From owner-v6ops@ops.ietf.org Thu Oct 10 20:36:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27683 for ; Thu, 10 Oct 2002 20:36:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17znnW-000DjD-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 17:36:58 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17znnU-000Dj1-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 17:36:56 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id JAA05900 for ; Fri, 11 Oct 2002 09:36:55 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Fri, 11 Oct 2002 09:38:09 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17znnR-000GcA-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 09:36:53 +0900 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2F7B93351D2DC54AAC898E8325DEEAA6220229@mail.esn.es.net> Thread-Topic: New draft on embedding the RP address in IPv6 multicast address Thread-Index: AcJwWGakOHGuxbTxRIaXZ9MwKoVjBQAGzxOg Subject: RE: New draft on embedding the RP address in IPv6 multicast address Date: Thu, 10 Oct 2002 08:47:18 -0700 From: "Mike O'Connor" To: "Pekka Savola" , "Marshall Eubanks" Cc: , , "Brian Haberman" , X-Spam-Status: No, hits=-6.4 required=5.0 tests=DEAR_SOMEBODY,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA27683 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] If all source active advertisements are carried in PIM packets won't we need to flood and prune our local source PIM packets to all or our interdomain neighbors? Would this draft accommodate PIM sparse mode? -Mike -- Mike O'Connor, E-mail: moc@es.net Network Engineer Energy Sciences Network (ESnet) East coast: +1 631 344-7410 West coast: +1 510 486-7421 Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Thursday, October 10, 2002 8:20 AM To: Marshall Eubanks Cc: mboned@network-services.uoregon.edu; v6ops@ops.ietf.org; Brian Haberman Subject: Re: New draft on embedding the RP address in IPv6 multicast address On Thu, 10 Oct 2002, Marshall Eubanks wrote: > On Thu, 10 Oct 2002 14:21:44 +0300 (EEST) > Pekka Savola wrote: > > Hello, > > > > Dear Pekka; > > A quick question about Section 4 : > > o "plen" MUST NOT be 0 (ie. not SSM) > > o "plen" MUST NOT be greater than 96 > > The address of the RP can be obtained from a multicast address by > taking the following steps: > > 1. take the last 96 bits of the multicast address > > 2. zero the last 128-"plen" bits, and > > 3. replace the last 4 bits with the contents of "RPad". > > > If "plen" is = 1 (say), which seems to be allowed, then how do I zero > the last 127 bits of a 96 bit slice of a multicast address ? > > I am pretty sure this is not what you mean, but this is what I read it > to say. The first bullet makes it implicit that those 96 bits are placed at the beginning of a 128-bit address struct (which is assumed to have been initialized to zero). But that should be clarified so there will be no misunderstandings, thanks. > Regards > Marshall Eubanks > > > > Me and Brian Haberman have submitted a new draft to > > internet-drafts@ietf.org. In the interim, it's available at: > > > > http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-mcast-rpaddr-0 > > 0.txt > > > > "Embedding the Address of RP in IPv6 Multicast Address" > > > > Abstract > > > > As has been noticed, there is exists a huge deployment problem with > > global, interdomain IPv6 multicast: PIM RPs have no way of > > communicating the information about multicast sources to other > > multicast domains, as there is no MSDP, and the whole interdomain Any > > Source Multicast model is rendered unusable; SSM avoids these > > problems. This memo outlines a way to embed the address of the RP in > > the multicast address, solving the interdomain multicast problem. The > > problem is three-fold: specify an address format, adjust the > > operational procedures and configuration if necessary, and modify > > receiver-side PIM implementations. In consequence, there would be no > > need for interdomain MSDP. > > > > It's 9 pages. > > > > Comments are welcome, either directly or to the list(s) if > > appropriate. > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > > > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Oct 10 20:37:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27699 for ; Thu, 10 Oct 2002 20:37:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17znpx-000Dq1-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 17:39:29 -0700 Received: from ncsmtp03.ogw.rr.com ([24.93.67.84]) by psg.com with esmtp (Exim 3.36 #2) id 17znpv-000Dpp-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 17:39:27 -0700 Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9B0dBiZ023416; Thu, 10 Oct 2002 20:39:11 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 10 Oct 2002 20:39:18 -0400 Message-ID: <3DA61D1F.D1F0F460@nc.rr.com> Date: Thu, 10 Oct 2002 20:36:47 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Leonard Giuliano CC: mboned@network-services.uoregon.edu, v6ops@ops.ietf.org Subject: Re: New draft on embedding the RP address in IPv6 multicast address References: <20021010142459.F86853-100000@maroon.jnpr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Lenny, Leonard Giuliano wrote: > > Going back a bit, if this ASM mechanism will rely on SSM-like group > discovery, why not just use SSM in the first place? I totally agree. However, other people don't and they want ASM in v6. I made it a point to ensure that we had a nice SSM range for v6 (see RFC 3306). What I would like to see with this work is whether or not we can have ASM without the burden of MSDP. If I had my way, SSM would be the solution even if we did have to deal with N^2 state. I would prefer that kind of problem. :) Brian From owner-v6ops@ops.ietf.org Thu Oct 10 20:39:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27724 for ; Thu, 10 Oct 2002 20:39:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17znrk-000DvD-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 17:41:20 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17znri-000DuU-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 17:41:18 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id JAA06028 for ; Fri, 11 Oct 2002 09:41:16 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Fri, 11 Oct 2002 09:42:31 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17znrf-000Gck-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 09:41:15 +0900 Message-ID: <3DA5A7B6.5080007@multicasttech.com> MIME-Version: 1.0 References: <2F7B93351D2DC54AAC898E8325DEEAA6220229@mail.esn.es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 10 Oct 2002 12:15:50 -0400 From: Marshall Eubanks To: "Mike O'Connor" CC: Pekka Savola , mboned@network-services.uoregon.edu, v6ops@ops.ietf.org, Brian Haberman , nesg@es.net Subject: Re: New draft on embedding the RP address in IPv6 multicast address X-Spam-Status: No, hits=-9.7 required=5.0 tests=DEAR_SOMEBODY,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_02_03 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Yes, I think so, this requires interdomain flooding, just like interdomain MSDP in IPv4. However, you might be able to make ASM "SSM like" in that, if you find the group address by some means out of band, you can join to the RP and either send or receive. It is also not clear to me how this would work in, say, a teleconference. Doesn't it limit the group to only _one_ RP? What functionality does it give that either SSM or MSDP doesn't ? Marshall Mike O'Connor wrote: > If all source active advertisements are carried in PIM packets won't we > need to flood and prune our local source PIM packets to all or our > interdomain neighbors? Would this draft accommodate PIM sparse mode? > > -Mike > > -- > Mike O'Connor, E-mail: moc@es.net > Network Engineer Energy Sciences Network (ESnet) > East coast: +1 631 344-7410 West coast: +1 510 486-7421 > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > > > > > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, October 10, 2002 8:20 AM > To: Marshall Eubanks > Cc: mboned@network-services.uoregon.edu; v6ops@ops.ietf.org; Brian > Haberman > Subject: Re: New draft on embedding the RP address in IPv6 multicast > address > > > On Thu, 10 Oct 2002, Marshall Eubanks wrote: > >>On Thu, 10 Oct 2002 14:21:44 +0300 (EEST) >> Pekka Savola wrote: >> >>>Hello, >>> >> >>Dear Pekka; >> >> A quick question about Section 4 : >> >> o "plen" MUST NOT be 0 (ie. not SSM) >> >> o "plen" MUST NOT be greater than 96 >> >> The address of the RP can be obtained from a multicast address by >> taking the following steps: >> >> 1. take the last 96 bits of the multicast address >> >> 2. zero the last 128-"plen" bits, and >> >> 3. replace the last 4 bits with the contents of "RPad". >> >> >>If "plen" is = 1 (say), which seems to be allowed, then how do I zero >>the last 127 bits of a 96 bit slice of a multicast address ? >> >>I am pretty sure this is not what you mean, but this is what I read it > > >>to say. > > > The first bullet makes it implicit that those 96 bits are placed at the > beginning of a 128-bit address struct (which is assumed to have been > initialized to zero). > > But that should be clarified so there will be no misunderstandings, > thanks. > > > >>Regards >>Marshall Eubanks >> >> >> >>>Me and Brian Haberman have submitted a new draft to >>>internet-drafts@ietf.org. In the interim, it's available at: >>> >>>http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-mcast-rpaddr-0 >>>0.txt >>> >>> "Embedding the Address of RP in IPv6 Multicast Address" >>> >>>Abstract >>> >>> As has been noticed, there is exists a huge deployment problem >> > with > >>> global, interdomain IPv6 multicast: PIM RPs have no way of >> > >>> communicating the information about multicast sources to other >>> multicast domains, as there is no MSDP, and the whole interdomain >> > Any > >>> Source Multicast model is rendered unusable; SSM avoids these >> > >>> problems. This memo outlines a way to embed the address of the >> > RP in > >>> the multicast address, solving the interdomain multicast problem. >> > The > >>> problem is three-fold: specify an address format, adjust the >> > >>> operational procedures and configuration if necessary, and modify >>> receiver-side PIM implementations. In consequence, there would >> > be no > >>> need for interdomain MSDP. >>> >>>It's 9 pages. >>> >>>Comments are welcome, either directly or to the list(s) if >>>appropriate. >>> >>>-- >>>Pekka Savola "Tell me of difficulties surmounted, >>>Netcore Oy not those you stumble over and fall" >>>Systems. Networks. Security. -- Robert Jordan: A Crown of Swords >>> >>> >>> >>> >>> >>> >> > -- Regards Marshall Eubanks This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html From owner-v6ops@ops.ietf.org Thu Oct 10 21:19:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28055 for ; Thu, 10 Oct 2002 21:19:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zoUG-000FTj-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 18:21:08 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17zoUE-000FTX-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 18:21:06 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id KAA07266 for ; Fri, 11 Oct 2002 10:21:04 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Fri, 11 Oct 2002 10:22:19 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zoUC-000Gf4-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 10:21:04 +0900 Message-ID: <3DA5BC5F.5020800@multicasttech.com> MIME-Version: 1.0 References: <2F7B93351D2DC54AAC898E8325DEEAA614C6FD@mail.esn.es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 10 Oct 2002 13:43:59 -0400 From: Marshall Eubanks To: "Mike O'Connor" CC: Pekka Savola , mboned@network-services.uoregon.edu, v6ops@ops.ietf.org, Brian Haberman , nesg@es.net Subject: Re: New draft on embedding the RP address in IPv6 multicast address X-Spam-Status: No, hits=-9.7 required=5.0 tests=DEAR_SOMEBODY,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_02_03 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Funny how, with enough IP addresses to give ~ 10^30 to each particle in the universe, there may not be enough. Wouldn't it be simpler to just say 1.) The last 64 bits of any ASM group address specifies first 64 bits of the (anycast?) address of a RP for the group 2.) RP addresses are valid for any MAC address - i.e., for any set of lower order 64 bits. 3.) RP-RP discovery is done out of band. Regards Marshall Mike O'Connor wrote: > Marshall, > > I wasn't sure how the four bit RPad field is used, but the thought of a > single RP limitation occurred to me as well. I don't think that even if > the RPad allows for 16 RP's per group address it is large enough. There > have already been Access Grid conferences that have had thirty sites > join, each with their own RP. It's probably not a good idea to propose a > number that's already too small:) If there were 16 RP's per PIM domain > it might be enough. > > -Mike > > -- > Mike O'Connor, E-mail: moc@es.net > Network Engineer Energy Sciences Network (ESnet) > East coast: +1 631 344-7410 West coast: +1 510 486-7421 > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > > > > > -----Original Message----- > From: Marshall Eubanks [mailto:tme@multicasttech.com] > Sent: Thursday, October 10, 2002 12:16 PM > To: Mike O'Connor > Cc: Pekka Savola; mboned@network-services.uoregon.edu; > v6ops@ops.ietf.org; Brian Haberman; nesg@es.net > Subject: Re: New draft on embedding the RP address in IPv6 multicast > address > > > Yes, I think so, this requires interdomain flooding, just like > interdomain MSDP in IPv4. > > However, you might be able to make ASM "SSM like" in that, if you find > the group address by some means out of band, you can join to the RP > and either send or receive. > > It is also not clear to me how this would work in, say, a > teleconference. Doesn't it limit the group to only _one_ RP? What > functionality does it give that either SSM or MSDP doesn't ? > > Marshall > > Mike O'Connor wrote: > >>If all source active advertisements are carried in PIM packets won't >>we need to flood and prune our local source PIM packets to all or our >>interdomain neighbors? Would this draft accommodate PIM sparse mode? >> >>-Mike >> >>-- >>Mike O'Connor, E-mail: moc@es.net >>Network Engineer Energy Sciences Network (ESnet) >>East coast: +1 631 344-7410 West coast: +1 510 486-7421 >>Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) >> >> >> >> >>-----Original Message----- >>From: Pekka Savola [mailto:pekkas@netcore.fi] >>Sent: Thursday, October 10, 2002 8:20 AM >>To: Marshall Eubanks >>Cc: mboned@network-services.uoregon.edu; v6ops@ops.ietf.org; Brian >>Haberman >>Subject: Re: New draft on embedding the RP address in IPv6 multicast >>address >> >> >>On Thu, 10 Oct 2002, Marshall Eubanks wrote: >> >> >>>On Thu, 10 Oct 2002 14:21:44 +0300 (EEST) >>>Pekka Savola wrote: >>> >>> >>>>Hello, >>>> >>> >>>Dear Pekka; >>> >>> A quick question about Section 4 : >>> >>> o "plen" MUST NOT be 0 (ie. not SSM) >>> >>> o "plen" MUST NOT be greater than 96 >>> >>> The address of the RP can be obtained from a multicast address by >>> taking the following steps: >>> >>> 1. take the last 96 bits of the multicast address >>> >>> 2. zero the last 128-"plen" bits, and >>> >>> 3. replace the last 4 bits with the contents of "RPad". >>> >>> >>>If "plen" is = 1 (say), which seems to be allowed, then how do I zero >>>the last 127 bits of a 96 bit slice of a multicast address ? >>> >>>I am pretty sure this is not what you mean, but this is what I read it >> >> >>>to say. >> >> >>The first bullet makes it implicit that those 96 bits are placed at >>the >>beginning of a 128-bit address struct (which is assumed to have been >>initialized to zero). >> >>But that should be clarified so there will be no misunderstandings, >>thanks. >> >> >> >> >>>Regards >>>Marshall Eubanks >>> >>> >>> >>> >>>>Me and Brian Haberman have submitted a new draft to >>>>internet-drafts@ietf.org. In the interim, it's available at: >>>> >>>>http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-mcast-rpaddr-0 >>>>0.txt >>>> >>>> "Embedding the Address of RP in IPv6 Multicast Address" >>>> >>>>Abstract >>>> >>>> As has been noticed, there is exists a huge deployment problem >>> >>with >> >> >>>> global, interdomain IPv6 multicast: PIM RPs have no way of >>> >>>> communicating the information about multicast sources to other >>>> multicast domains, as there is no MSDP, and the whole interdomain >>> >>Any >> >> >>>> Source Multicast model is rendered unusable; SSM avoids these >>> >>>> problems. This memo outlines a way to embed the address of the >>> >>RP in >> >> >>>> the multicast address, solving the interdomain multicast problem. >>> >>The >> >> >>>> problem is three-fold: specify an address format, adjust the >>> >>>> operational procedures and configuration if necessary, and modify >>>> receiver-side PIM implementations. In consequence, there would >>> >>be no >> >> >>>> need for interdomain MSDP. >>>> >>>>It's 9 pages. >>>> >>>>Comments are welcome, either directly or to the list(s) if >>>>appropriate. >>>> >>>>-- >>>>Pekka Savola "Tell me of difficulties surmounted, >>>>Netcore Oy not those you stumble over and fall" >>>>Systems. Networks. Security. -- Robert Jordan: A Crown of Swords >>>> >>>> >>>> >>>> >>>> >>>> >>> > > -- Regards Marshall Eubanks This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html From owner-v6ops@ops.ietf.org Thu Oct 10 21:19:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28069 for ; Thu, 10 Oct 2002 21:19:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zoTN-000FRH-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 18:20:13 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17zoTM-000FR5-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 18:20:12 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id KAA07225 for ; Fri, 11 Oct 2002 10:20:10 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Fri, 11 Oct 2002 10:21:24 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zoTI-000Geq-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 10:20:08 +0900 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2F7B93351D2DC54AAC898E8325DEEAA614C6FD@mail.esn.es.net> Thread-Topic: New draft on embedding the RP address in IPv6 multicast address Thread-Index: AcJweFHTVgCcf3UlQNqojmGYaTBPcgACa8Tg Subject: RE: New draft on embedding the RP address in IPv6 multicast address Date: Thu, 10 Oct 2002 10:34:00 -0700 From: "Mike O'Connor" To: "Marshall Eubanks" Cc: "Pekka Savola" , , , "Brian Haberman" , X-Spam-Status: No, hits=-6.4 required=5.0 tests=DEAR_SOMEBODY,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA28069 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Marshall, I wasn't sure how the four bit RPad field is used, but the thought of a single RP limitation occurred to me as well. I don't think that even if the RPad allows for 16 RP's per group address it is large enough. There have already been Access Grid conferences that have had thirty sites join, each with their own RP. It's probably not a good idea to propose a number that's already too small:) If there were 16 RP's per PIM domain it might be enough. -Mike -- Mike O'Connor, E-mail: moc@es.net Network Engineer Energy Sciences Network (ESnet) East coast: +1 631 344-7410 West coast: +1 510 486-7421 Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) -----Original Message----- From: Marshall Eubanks [mailto:tme@multicasttech.com] Sent: Thursday, October 10, 2002 12:16 PM To: Mike O'Connor Cc: Pekka Savola; mboned@network-services.uoregon.edu; v6ops@ops.ietf.org; Brian Haberman; nesg@es.net Subject: Re: New draft on embedding the RP address in IPv6 multicast address Yes, I think so, this requires interdomain flooding, just like interdomain MSDP in IPv4. However, you might be able to make ASM "SSM like" in that, if you find the group address by some means out of band, you can join to the RP and either send or receive. It is also not clear to me how this would work in, say, a teleconference. Doesn't it limit the group to only _one_ RP? What functionality does it give that either SSM or MSDP doesn't ? Marshall Mike O'Connor wrote: > If all source active advertisements are carried in PIM packets won't > we need to flood and prune our local source PIM packets to all or our > interdomain neighbors? Would this draft accommodate PIM sparse mode? > > -Mike > > -- > Mike O'Connor, E-mail: moc@es.net > Network Engineer Energy Sciences Network (ESnet) > East coast: +1 631 344-7410 West coast: +1 510 486-7421 > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > > > > > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, October 10, 2002 8:20 AM > To: Marshall Eubanks > Cc: mboned@network-services.uoregon.edu; v6ops@ops.ietf.org; Brian > Haberman > Subject: Re: New draft on embedding the RP address in IPv6 multicast > address > > > On Thu, 10 Oct 2002, Marshall Eubanks wrote: > >>On Thu, 10 Oct 2002 14:21:44 +0300 (EEST) >> Pekka Savola wrote: >> >>>Hello, >>> >> >>Dear Pekka; >> >> A quick question about Section 4 : >> >> o "plen" MUST NOT be 0 (ie. not SSM) >> >> o "plen" MUST NOT be greater than 96 >> >> The address of the RP can be obtained from a multicast address by >> taking the following steps: >> >> 1. take the last 96 bits of the multicast address >> >> 2. zero the last 128-"plen" bits, and >> >> 3. replace the last 4 bits with the contents of "RPad". >> >> >>If "plen" is = 1 (say), which seems to be allowed, then how do I zero >>the last 127 bits of a 96 bit slice of a multicast address ? >> >>I am pretty sure this is not what you mean, but this is what I read it > > >>to say. > > > The first bullet makes it implicit that those 96 bits are placed at > the > beginning of a 128-bit address struct (which is assumed to have been > initialized to zero). > > But that should be clarified so there will be no misunderstandings, > thanks. > > > >>Regards >>Marshall Eubanks >> >> >> >>>Me and Brian Haberman have submitted a new draft to >>>internet-drafts@ietf.org. In the interim, it's available at: >>> >>>http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-mcast-rpaddr-0 >>>0.txt >>> >>> "Embedding the Address of RP in IPv6 Multicast Address" >>> >>>Abstract >>> >>> As has been noticed, there is exists a huge deployment problem >> > with > >>> global, interdomain IPv6 multicast: PIM RPs have no way of >> > >>> communicating the information about multicast sources to other >>> multicast domains, as there is no MSDP, and the whole interdomain >> > Any > >>> Source Multicast model is rendered unusable; SSM avoids these >> > >>> problems. This memo outlines a way to embed the address of the >> > RP in > >>> the multicast address, solving the interdomain multicast problem. >> > The > >>> problem is three-fold: specify an address format, adjust the >> > >>> operational procedures and configuration if necessary, and modify >>> receiver-side PIM implementations. In consequence, there would >> > be no > >>> need for interdomain MSDP. >>> >>>It's 9 pages. >>> >>>Comments are welcome, either directly or to the list(s) if >>>appropriate. >>> >>>-- >>>Pekka Savola "Tell me of difficulties surmounted, >>>Netcore Oy not those you stumble over and fall" >>>Systems. Networks. Security. -- Robert Jordan: A Crown of Swords >>> >>> >>> >>> >>> >>> >> > -- Regards Marshall Eubanks This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html From owner-v6ops@ops.ietf.org Thu Oct 10 21:20:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28083 for ; Thu, 10 Oct 2002 21:20:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zoTn-000FTO-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 18:20:39 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17zoTm-000FTC-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 18:20:38 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id KAA07235 for ; Fri, 11 Oct 2002 10:20:36 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Fri, 11 Oct 2002 10:21:49 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zoTi-000Gez-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 10:20:34 +0900 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2F7B93351D2DC54AAC898E8325DEEAA614C6FE@mail.esn.es.net> Thread-Topic: New draft on embedding the RP address in IPv6 multicast address Thread-Index: AcJwgkFaWa+FL9BSSyaA10KjChaEfgAAWC2w Subject: RE: New draft on embedding the RP address in IPv6 multicast address Date: Thu, 10 Oct 2002 10:40:59 -0700 From: "Mike O'Connor" To: "Brian Haberman" , "Marshall Eubanks" Cc: "Pekka Savola" , , , X-Spam-Status: No, hits=-5.4 required=5.0 tests=QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA28083 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Hi Brian, I don't understand how the reciever's RP receives the "owning RP" address for a given multicast group. How are the "owning RP" addresses distributed between domains without PIM flooding? > This is actually what is expected to happen. The steps look like: > > 1. A receiver finds out a group address from some means > (e.g. SDR or a web page) > 2. The receiver issues an MLD Report Joining the group > 3. The receiver's DR will initiate the PIM Join process > 4. The Join message flows up to the receivers RP > 5. The RP recognizes the embedded RP format and extracts > the owning RP address > 6. The receiver's RP issues an SPT join to the owning RP > and creates forwarding state -- Mike O'Connor, E-mail: moc@es.net Network Engineer Energy Sciences Network (ESnet) East coast: +1 631 344-7410 West coast: +1 510 486-7421 Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) -----Original Message----- From: Brian Haberman [mailto:bkhabs@nc.rr.com] Sent: Thursday, October 10, 2002 1:30 PM To: Marshall Eubanks Cc: Mike O'Connor; Pekka Savola; mboned@network-services.uoregon.edu; v6ops@ops.ietf.org; nesg@es.net Subject: Re: New draft on embedding the RP address in IPv6 multicast address Marshall Eubanks wrote: > Yes, I think so, this requires interdomain flooding, just like > interdomain MSDP in IPv4. Actually, I don't think it does. See comments below. > > However, you might be able to make ASM "SSM like" in that, if you find > the group address by some means out of band, you can join to the RP > and either send or receive. This is actually what is expected to happen. The steps look like: 1. A receiver finds out a group address from some means (e.g. SDR or a web page) 2. The receiver issues an MLD Report Joining the group 3. The receiver's DR will initiate the PIM Join process 4. The Join message flows up to the receivers RP 5. The RP recognizes the embedded RP format and extracts the owning RP address 6. The receiver's RP issues an SPT join to the owning RP and creates forwarding state One possible optimization is that the receiver's DR could issue the SPT to the owning RP. The sender side has two cases. 1. A sender in the owning domain. Nothing should be different here. 2. A sender in a foreign domain. This is the case that I have to do some work on. In order for a receiver in another domain to know about this sender, information will have to flow to the owning RP. > > It is also not clear to me how this would work in, say, a > teleconference. Doesn't it limit the group to only _one_ RP? What > functionality does it give that either SSM or MSDP doesn't ? One big advantage is the removal of inter-domain MSDP state. And the use of one RP is a downside of this approach. Brian From owner-v6ops@ops.ietf.org Thu Oct 10 22:03:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28865 for ; Thu, 10 Oct 2002 22:03:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zp8k-000HIm-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 19:02:58 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17zp8j-000HIa-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 19:02:57 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id LAA08579 for ; Fri, 11 Oct 2002 11:02:55 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Fri, 11 Oct 2002 11:04:09 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zp8g-000Gty-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 11:02:54 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2F7B93351D2DC54AAC898E8325DEEAA622022F@mail.esn.es.net> Thread-Topic: New draft on embedding the RP address in IPv6 multicast address Thread-Index: AcJwhSAnzfN6HmCYSuaK7nWq6+exRQAACrBQ Subject: RE: New draft on embedding the RP address in IPv6 multicast address Date: Thu, 10 Oct 2002 10:49:36 -0700 From: "Mike O'Connor" To: "Pekka Savola" Cc: "Marshall Eubanks" , , , "Brian Haberman" , X-Spam-Status: No, hits=-6.4 required=5.0 tests=DEAR_SOMEBODY,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA28865 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Pekka, Yes, I was not clear on RPad, thanks for clearing that up. -Mike -- Mike O'Connor, E-mail: moc@es.net Network Engineer Energy Sciences Network (ESnet) East coast: +1 631 344-7410 West coast: +1 510 486-7421 Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Thursday, October 10, 2002 1:47 PM To: Mike O'Connor Cc: Marshall Eubanks; mboned@network-services.uoregon.edu; v6ops@ops.ietf.org; Brian Haberman; nesg@es.net Subject: RE: New draft on embedding the RP address in IPv6 multicast address On Thu, 10 Oct 2002, Mike O'Connor wrote: > I wasn't sure how the four bit RPad field is used, but the thought of > a single RP limitation occurred to me as well. I don't think that > even if the RPad allows for 16 RP's per group address it is large > enough. There have already been Access Grid conferences that have had > thirty sites join, each with their own RP. It's probably not a good > idea to propose a number that's already too small:) If there were 16 > RP's per PIM domain it might be enough. Note that the proposed mechanism allows for _one_ RP per _group_, and 16 RP's per PIM domain. Perhaps you misunderstood the reason of "RPad". > -----Original Message----- > From: Marshall Eubanks [mailto:tme@multicasttech.com] > Sent: Thursday, October 10, 2002 12:16 PM > To: Mike O'Connor > Cc: Pekka Savola; mboned@network-services.uoregon.edu; > v6ops@ops.ietf.org; Brian Haberman; nesg@es.net > Subject: Re: New draft on embedding the RP address in IPv6 multicast > address > > > Yes, I think so, this requires interdomain flooding, just like > interdomain MSDP in IPv4. > > However, you might be able to make ASM "SSM like" in that, if you find > the group address by some means out of band, you can join to the RP > and either send or receive. > > It is also not clear to me how this would work in, say, a > teleconference. Doesn't it limit the group to only _one_ RP? What > functionality does it give that either SSM or MSDP doesn't ? > > Marshall > > Mike O'Connor wrote: > > If all source active advertisements are carried in PIM packets won't > > we need to flood and prune our local source PIM packets to all or our > > interdomain neighbors? Would this draft accommodate PIM sparse mode? > > > > -Mike > > > > -- > > Mike O'Connor, E-mail: moc@es.net > > Network Engineer Energy Sciences Network (ESnet) > > East coast: +1 631 344-7410 West coast: +1 510 486-7421 > > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > > > > > > > > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Thursday, October 10, 2002 8:20 AM > > To: Marshall Eubanks > > Cc: mboned@network-services.uoregon.edu; v6ops@ops.ietf.org; Brian > > Haberman > > Subject: Re: New draft on embedding the RP address in IPv6 multicast > > address > > > > > > On Thu, 10 Oct 2002, Marshall Eubanks wrote: > > > >>On Thu, 10 Oct 2002 14:21:44 +0300 (EEST) > >> Pekka Savola wrote: > >> > >>>Hello, > >>> > >> > >>Dear Pekka; > >> > >> A quick question about Section 4 : > >> > >> o "plen" MUST NOT be 0 (ie. not SSM) > >> > >> o "plen" MUST NOT be greater than 96 > >> > >> The address of the RP can be obtained from a multicast address by > >> taking the following steps: > >> > >> 1. take the last 96 bits of the multicast address > >> > >> 2. zero the last 128-"plen" bits, and > >> > >> 3. replace the last 4 bits with the contents of "RPad". > >> > >> > >>If "plen" is = 1 (say), which seems to be allowed, then how do I > >>zero the last 127 bits of a 96 bit slice of a multicast address ? > >> > >>I am pretty sure this is not what you mean, but this is what I read > >>it > > > > > >>to say. > > > > > > The first bullet makes it implicit that those 96 bits are placed at > > the > > beginning of a 128-bit address struct (which is assumed to have been > > initialized to zero). > > > > But that should be clarified so there will be no misunderstandings, > > thanks. > > > > > > > >>Regards > >>Marshall Eubanks > >> > >> > >> > >>>Me and Brian Haberman have submitted a new draft to > >>>internet-drafts@ietf.org. In the interim, it's available at: > >>> > >>>http://www.netcore.fi/pekkas/ietf/draft-savola-mboned-mcast-rpaddr- > >>>0 > >>>0.txt > >>> > >>> "Embedding the Address of RP in IPv6 Multicast Address" > >>> > >>>Abstract > >>> > >>> As has been noticed, there is exists a huge deployment problem > >> > > with > > > >>> global, interdomain IPv6 multicast: PIM RPs have no way of > >> > > > >>> communicating the information about multicast sources to other > >>> multicast domains, as there is no MSDP, and the whole > >>> interdomain > >> > > Any > > > >>> Source Multicast model is rendered unusable; SSM avoids these > >> > > > >>> problems. This memo outlines a way to embed the address of the > >> > > RP in > > > >>> the multicast address, solving the interdomain multicast > >>> problem. > >> > > The > > > >>> problem is three-fold: specify an address format, adjust the > >> > > > >>> operational procedures and configuration if necessary, and modify > >>> receiver-side PIM implementations. In consequence, there would > >> > > be no > > > >>> need for interdomain MSDP. > >>> > >>>It's 9 pages. > >>> > >>>Comments are welcome, either directly or to the list(s) if > >>>appropriate. > >>> > >>>-- > >>>Pekka Savola "Tell me of difficulties surmounted, > >>>Netcore Oy not those you stumble over and fall" > >>>Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > >>> > >>> > >>> > >>> > >>> > >>> > >> > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Oct 10 22:03:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28884 for ; Thu, 10 Oct 2002 22:03:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zp92-000HJ3-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 19:03:16 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17zp91-000HIp-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 19:03:15 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id LAA08595 for ; Fri, 11 Oct 2002 11:03:13 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Fri, 11 Oct 2002 11:04:28 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zp8y-000Gu6-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 11:03:13 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2F7B93351D2DC54AAC898E8325DEEAA614C6FF@mail.esn.es.net> Thread-Topic: New draft on embedding the RP address in IPv6 multicast address Thread-Index: AcJwhe+LKeZ/4jkKQN2tOYwvh47r4QABe3Tw Subject: RE: New draft on embedding the RP address in IPv6 multicast address Date: Thu, 10 Oct 2002 11:45:11 -0700 From: "Mike O'Connor" To: "Brian Haberman" Cc: "Marshall Eubanks" , "Pekka Savola" , , , X-Spam-Status: No, hits=-4.7 required=5.0 tests=QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA28884 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Brian, Is there an underlying assumption that a given group has all of it's sources in one PIM domain? ASM in V4 doesn't restrict the number of RP's per multicast group. How does the proposal support an ASM conference where all participants are in different AS/PIM domains and each is both sender and receiver with it's own RP? I'm seeing this as supporting SSM but not ASM. -Mike -- Mike O'Connor, E-mail: moc@es.net Network Engineer Energy Sciences Network (ESnet) East coast: +1 631 344-7410 West coast: +1 510 486-7421 Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) -----Original Message----- From: Brian Haberman [mailto:bkhabs@nc.rr.com] Sent: Thursday, October 10, 2002 1:56 PM To: Mike O'Connor Cc: Marshall Eubanks; Pekka Savola; mboned@network-services.uoregon.edu; v6ops@ops.ietf.org; nesg@es.net Subject: Re: New draft on embedding the RP address in IPv6 multicast address Mike O'Connor wrote: > Hi Brian, > > I don't understand how the reciever's RP receives the "owning RP" > address for a given multicast group. How are the "owning RP" addresses > distributed between domains without PIM flooding? The RP address is embedded in the multicast address. The key is in the assignment of multicast addresses in a domain and the configuration of RP addresses. So, if a domain uses prefix 3ffe:1:2::/48. It places an RP in the network and gives it an address of 3ffe:1:2:3::5. Now, this RP can be the RP for the multicast address range FF7x:0540:3ffe:1:2:3::/96. The key is that the IID portion of the RP's address is set to a value that can be encode in the RPad field of the multicast address. The mcast groups are distinguished by the lower 32 bits of the address. Now, a receiver's RP can examine the multicast address when it is creating state and reconstruct the owning RP's address by extracting the network prefix value and appending the RPad field. Brian From owner-v6ops@ops.ietf.org Thu Oct 10 22:13:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29014 for ; Thu, 10 Oct 2002 22:13:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zpKE-000HVt-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 19:14:50 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17zpKC-000HVf-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 19:14:48 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id LAA08881 for ; Fri, 11 Oct 2002 11:14:47 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Fri, 11 Oct 2002 11:16:00 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zpK9-000Gvu-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 11:14:45 +0900 In-Reply-To: <3DA5F75A.4030600@multicasttech.com> Message-ID: <20021010185923.W63433-100000@maroon.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 10 Oct 2002 19:08:07 -0700 (PDT) From: Greg Shepherd To: Marshall Eubanks cc: Leonard Giuliano , Brian Haberman , "Mike O'Connor" , Pekka Savola , , , Subject: Re: New draft on embedding the RP address in IPv6 multicast address X-Spam-Status: No, hits=-8.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_01_02 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On Thu, 10 Oct 2002, Marshall Eubanks wrote: > 2000 member multi-player games come to mind. I believe that these have > been done (as military simulations). > > SSM will have state and flows that goes as N^2 in this case - the Many-to-many will always have flow of order of 1 outbound and N-1 inbound - ASM or SSM. State is also the same between SSM and ASM - though technically SSM has less state in that it does not require *,G for each unique G. Only a shared-tree-only mechanism like BiDir can reduce state for ASM. The ONLY thing ASM has over SSM is in-band source discovery. So do we build some ~universal mechanism in protocols to provide this, or do we push off to the application writers to provide source-discovery as best fits their audience scale and needs. Hmmm. ;-) Greg > real question is, can there be multi-domain solutions that only require > state and flows of order N. > > Regards > Marshall > > Leonard Giuliano wrote: > > -) > > > -) > However, you might be able to make ASM "SSM like" in that, if you > > -) > find the group address by some means out of band, you can join to the RP > > -) > and either send or receive. > > -) > > -) This is actually what is expected to happen. The steps look like: > > -) > > > > Going back a bit, if this ASM mechanism will rely on SSM-like group > > discovery, why not just use SSM in the first place? > > > > The main problem with SSM in IPv4 is that ASM was already in use, and > > there aren't enough implementations/deployments of SSM yet. But v6 need > > not carry the same albatross of legacy mechanisms around it's neck. It's > > a chance to do things right from the start. > > > > Does anyone actually see any real cases where SSM won't be at least "good > > enough?" Is all the complexity of ASM, and the duct tape solutions being > > discussed worth it just so that SDR will work? > > > > > > -Lenny > > > > > -- > Regards > Marshall Eubanks > > > T.M. Eubanks > Multicast Technologies, Inc > 10301 Democracy Lane, Suite 410 > Fairfax, Virginia 22030 > Phone : 703-293-9624 Fax : 703-293-9609 > e-mail : tme@multicasttech.com > http://www.multicasttech.com > > Test your network for multicast : > http://www.multicasttech.com/mt/ > Status of Multicast on the Web : > http://www.multicasttech.com/status/index.html > > From owner-v6ops@ops.ietf.org Thu Oct 10 22:14:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29028 for ; Thu, 10 Oct 2002 22:14:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zpLY-000HYA-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 19:16:12 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17zpLX-000HXx-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 19:16:11 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id LAA08925 for ; Fri, 11 Oct 2002 11:16:09 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Fri, 11 Oct 2002 11:17:23 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zpLU-000Gw4-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 11:16:08 +0900 In-Reply-To: Message-ID: <20021010190939.W63433-100000@maroon.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 10 Oct 2002 19:12:48 -0700 (PDT) From: Greg Shepherd To: Marshall Eubanks cc: Leonard Giuliano , Brian Haberman , "Mike O'Connor" , Pekka Savola , , , Subject: Re: New draft on embedding the RP address in IPv6 multicast address X-Spam-Status: No, hits=-8.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_01_02 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On Thu, 10 Oct 2002, Marshall Eubanks wrote: > On Thu, 10 Oct 2002 15:07:58 -0700 (PDT) > Leonard Giuliano wrote: > > > > Most PIM implementations switch to the SPT, and stay on it, so you are > > always going to have this problem. > > > > Yes, but in the ASM service model, there is no need to find the > addresses etc. of all of the source members, and pass this information around. > > In PIM-SM ASM _as practiced_ basically the RP's handle source discovery in a > distributed fashion. It would not be a bad idea to make this explicit, and I am > a firm believer in the separation of control and data. > > > I think it was Dave M who said that years of concern about state has > > solved the state problem- there's no mcast traffic. Let's have a state > > problem first, then worry about fixing it. > > > > The biggest use of multicast at present, by an order of magnitude or more, is > the distribution of financial data. Has any of this migrated to SSM ? It could, > maybe, but will it ? > > The amount of money that rides on these multicast packets to me provides a very > good indication that ASM will stick around. Not a fair comparison. Financial networks are walled-gardens. In the core distribution layer of the network, all S,Gs are well-known and in many casses are ~gauranteed to be delivered too the edge layers by static S,G-joins - VERY SSM-like. The growth in many-to-many at the edge networks is beginning to highlight the need for BiDir - over the next 2 years. Greg > Marshall > > > > > On Thu, 10 Oct 2002, Marshall Eubanks wrote: > > > > -) 2000 member multi-player games come to mind. I believe that these have > > -) been done (as military simulations). > > -) > > -) SSM will have state and flows that goes as N^2 in this case - the > > -) real question is, can there be multi-domain solutions that only require > > -) state and flows of order N. > > -) > > -) Regards > > -) Marshall > > -) > > -) Leonard Giuliano wrote: > > -) > -) > > > -) > -) > However, you might be able to make ASM "SSM like" in that, if you > > -) > -) > find the group address by some means out of band, you can join to > > the RP > > -) > -) > and either send or receive. > > -) > -) > > -) > -) This is actually what is expected to happen. The steps look like: > > -) > -) > > -) > > > -) > Going back a bit, if this ASM mechanism will rely on SSM-like group > > -) > discovery, why not just use SSM in the first place? > > -) > > > -) > The main problem with SSM in IPv4 is that ASM was already in use, and > > -) > there aren't enough implementations/deployments of SSM yet. But v6 need > > -) > not carry the same albatross of legacy mechanisms around it's neck. > > It's > > -) > a chance to do things right from the start. > > -) > > > -) > Does anyone actually see any real cases where SSM won't be at least > > "good > > -) > enough?" Is all the complexity of ASM, and the duct tape solutions > > being > > -) > discussed worth it just so that SDR will work? > > -) > > > -) > > > -) > -Lenny > > -) > > > -) > > -) > > -) -- > > -) Regards > > -) Marshall Eubanks > > -) > > -) > > -) T.M. Eubanks > > -) Multicast Technologies, Inc > > -) 10301 Democracy Lane, Suite 410 > > -) Fairfax, Virginia 22030 > > -) Phone : 703-293-9624 Fax : 703-293-9609 > > -) e-mail : tme@multicasttech.com > > -) http://www.multicasttech.com > > -) > > -) Test your network for multicast : > > -) http://www.multicasttech.com/mt/ > > -) Status of Multicast on the Web : > > -) http://www.multicasttech.com/status/index.html > > -) > > > > > > From owner-v6ops@ops.ietf.org Thu Oct 10 22:51:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29855 for ; Thu, 10 Oct 2002 22:51:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zpuJ-000Iwy-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 19:52:07 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17zpuI-000Iwm-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 19:52:06 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id LAA09931 for ; Fri, 11 Oct 2002 11:52:04 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Fri, 11 Oct 2002 11:53:19 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zpuF-000IYl-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 11:52:03 +0900 Message-ID: In-Reply-To: <20021010190939.W63433-100000@maroon.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit From: "Marshall Eubanks" Subject: Re: New draft on embedding the RP address in IPv6 multicast address To: Greg Shepherd , Marshall Eubanks Cc: Leonard Giuliano , Brian Haberman , "Mike O'Connor" , Pekka Savola , , , Date: Thu, 10 Oct 2002 22:34:21 -0400 X-Spam-Status: No, hits=-8.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On Thu, 10 Oct 2002 19:12:48 -0700 (PDT) Greg Shepherd wrote: > > > On Thu, 10 Oct 2002, Marshall Eubanks wrote: > > > On Thu, 10 Oct 2002 15:07:58 -0700 (PDT) > > Leonard Giuliano wrote: > > > > > > Most PIM implementations switch to the SPT, and stay on it, so you are > > > always going to have this problem. > > > > > > > Yes, but in the ASM service model, there is no need to find the > > addresses etc. of all of the source members, and pass this information > around. > > > > In PIM-SM ASM _as practiced_ basically the RP's handle source discovery in > a > > distributed fashion. It would not be a bad idea to make this explicit, and > I am > > a firm believer in the separation of control and data. > > > > > I think it was Dave M who said that years of concern about state has > > > solved the state problem- there's no mcast traffic. Let's have a state > > > problem first, then worry about fixing it. > > > > > > > The biggest use of multicast at present, by an order of magnitude or more, > is > > the distribution of financial data. Has any of this migrated to SSM ? It > could, > > maybe, but will it ? > > > > The amount of money that rides on these multicast packets to me provides a > very > > good indication that ASM will stick around. > > Not a fair comparison. Financial networks are walled-gardens. In the core > distribution layer of the network, all S,Gs are well-known and in many > casses are ~gauranteed to be delivered too the edge layers by static > S,G-joins - VERY SSM-like. > Hi Greg; I do not disagree - its just that I think that they will resist change. > The growth in many-to-many at the edge networks is beginning to highlight > the need for BiDir - over the next 2 years. > Good point. Marshall > Greg > > > Marshall > > > > > > > > On Thu, 10 Oct 2002, Marshall Eubanks wrote: > > > > > > -) 2000 member multi-player games come to mind. I believe that these have > > > -) been done (as military simulations). > > > -) > > > -) SSM will have state and flows that goes as N^2 in this case - the > > > -) real question is, can there be multi-domain solutions that only > require > > > -) state and flows of order N. > > > -) > > > -) Regards > > > -) Marshall > > > -) > > > -) Leonard Giuliano wrote: > > > -) > -) > > > > -) > -) > However, you might be able to make ASM "SSM like" in that, if > you > > > -) > -) > find the group address by some means out of band, you can join > to > > > the RP > > > -) > -) > and either send or receive. > > > -) > -) > > > -) > -) This is actually what is expected to happen. The steps look > like: > > > -) > -) > > > -) > > > > -) > Going back a bit, if this ASM mechanism will rely on SSM-like group > > > -) > discovery, why not just use SSM in the first place? > > > -) > > > > -) > The main problem with SSM in IPv4 is that ASM was already in use, > and > > > -) > there aren't enough implementations/deployments of SSM yet. But v6 > need > > > -) > not carry the same albatross of legacy mechanisms around it's neck. > > > It's > > > -) > a chance to do things right from the start. > > > -) > > > > -) > Does anyone actually see any real cases where SSM won't be at least > > > "good > > > -) > enough?" Is all the complexity of ASM, and the duct tape solutions > > > being > > > -) > discussed worth it just so that SDR will work? > > > -) > > > > -) > > > > -) > -Lenny > > > -) > > > > -) > > > -) > > > -) -- > > > -) Regards > > > -) Marshall Eubanks > > > -) > > > -) > > > -) T.M. Eubanks > > > -) Multicast Technologies, Inc > > > -) 10301 Democracy Lane, Suite 410 > > > -) Fairfax, Virginia 22030 > > > -) Phone : 703-293-9624 Fax : 703-293-9609 > > > -) e-mail : tme@multicasttech.com > > > -) http://www.multicasttech.com > > > -) > > > -) Test your network for multicast : > > > -) http://www.multicasttech.com/mt/ > > > -) Status of Multicast on the Web : > > > -) http://www.multicasttech.com/status/index.html > > > -) > > > > > > > > > > > From owner-v6ops@ops.ietf.org Fri Oct 11 00:56:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02096 for ; Fri, 11 Oct 2002 00:56:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zrqX-000Mdg-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 21:56:21 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17zrqV-000MdU-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 21:56:19 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id NAA13211 for ; Fri, 11 Oct 2002 13:56:18 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Fri, 11 Oct 2002 13:57:31 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zrqS-000IeI-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 13:56:16 +0900 Message-ID: In-Reply-To: <20021010185923.W63433-100000@maroon.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit From: "Marshall Eubanks" Subject: Re: New draft on embedding the RP address in IPv6 multicast address To: Greg Shepherd , Marshall Eubanks Cc: Leonard Giuliano , Brian Haberman , "Mike O'Connor" , Pekka Savola , , , Date: Fri, 11 Oct 2002 00:00:06 -0400 X-Spam-Status: No, hits=-7.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_03_05 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On Thu, 10 Oct 2002 19:08:07 -0700 (PDT) Greg Shepherd wrote: > > On Thu, 10 Oct 2002, Marshall Eubanks wrote: > > > 2000 member multi-player games come to mind. I believe that these have > > been done (as military simulations). > > > > SSM will have state and flows that goes as N^2 in this case - the > > Many-to-many will always have flow of order of 1 outbound and N-1 inbound > - ASM or SSM. State is also the same between SSM and ASM - though Greg; I am not sure I agree... Assume some many to many game application implemented using multicast Suppose that you at home and someone at the U of O want to participate in the same group, and that I join here too. Assume (as I believe to be the case) that you and the UO guy are topologically close in the network, and let the router A be at the point where the tree from me to you two diverges, and assume symmetric routing. Now, in an ASM model, I join one group. At the router A, once the SPT is set up, there is only state for the one path to me. In the SSM model, I have to join 2 channels - one for you, and one for UO. At router A, even though the groups have the same path, state has to be maintained for both channels. So, no, I do not see that the state is the same between SSM and ASM in this case, at least between router A and me, although the data flow is the same. Whether this is important is another question. > technically SSM has less state in that it does not require *,G for each > unique G. Only a shared-tree-only mechanism like BiDir can reduce state > for ASM. > > The ONLY thing ASM has over SSM is in-band source discovery. So do we > build some ~universal mechanism in protocols to provide this, or do we > push off to the application writers to provide source-discovery as best > fits their audience scale and needs. Hmmm. ;-) > You may be right. Maybe there is no real _need_ for inter-domain ASM protocols in IPv6. Maybe a toolkit approach would make sense here - if you need automatic source-discovery, here are some ways to do it - along the lines of the reliable multicast working group approach. > Greg > Marshall > > real question is, can there be multi-domain solutions that only require > > state and flows of order N. > > > > Regards > > Marshall > > > > Leonard Giuliano wrote: > > > -) > > > > -) > However, you might be able to make ASM "SSM like" in that, if you > > > -) > find the group address by some means out of band, you can join to > the RP > > > -) > and either send or receive. > > > -) > > > -) This is actually what is expected to happen. The steps look like: > > > -) > > > > > > Going back a bit, if this ASM mechanism will rely on SSM-like group > > > discovery, why not just use SSM in the first place? > > > > > > The main problem with SSM in IPv4 is that ASM was already in use, and > > > there aren't enough implementations/deployments of SSM yet. But v6 need > > > not carry the same albatross of legacy mechanisms around it's neck. It's > > > a chance to do things right from the start. > > > > > > Does anyone actually see any real cases where SSM won't be at least "good > > > enough?" Is all the complexity of ASM, and the duct tape solutions being > > > discussed worth it just so that SDR will work? > > > > > > > > > -Lenny > > > > > > > > > -- > > Regards > > Marshall Eubanks > > > > > > T.M. Eubanks > > Multicast Technologies, Inc > > 10301 Democracy Lane, Suite 410 > > Fairfax, Virginia 22030 > > Phone : 703-293-9624 Fax : 703-293-9609 > > e-mail : tme@multicasttech.com > > http://www.multicasttech.com > > > > Test your network for multicast : > > http://www.multicasttech.com/mt/ > > Status of Multicast on the Web : > > http://www.multicasttech.com/status/index.html > > > > > From owner-v6ops@ops.ietf.org Fri Oct 11 00:56:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02111 for ; Fri, 11 Oct 2002 00:56:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zrrR-000Mh2-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 21:57:17 -0700 Received: from mgo.iij.ad.jp ([202.232.15.6] ident=root) by psg.com with esmtp (Exim 3.36 #2) id 17zrrQ-000Mgo-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 21:57:16 -0700 Received: from fw2.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with SMTP id NAA13233 for ; Fri, 11 Oct 2002 13:57:14 +0900 (JST) Received: from h071n005.iij.ad.jp ([192.168.5.71]) by fw2.iij.ad.jp; Fri, 11 Oct 2002 13:58:28 +0900 (JST) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17zrrN-000IeS-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 13:57:13 +0900 In-Reply-To: Message-ID: <20021010211938.Y63433-100000@maroon.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 10 Oct 2002 21:21:26 -0700 (PDT) From: Greg Shepherd To: Marshall Eubanks cc: Leonard Giuliano , Brian Haberman , "Mike O'Connor" , Pekka Savola , , , Subject: Re: New draft on embedding the RP address in IPv6 multicast address X-Spam-Status: No, hits=-8.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO, SPAM_PHRASE_03_05 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On Fri, 11 Oct 2002, Marshall Eubanks wrote: > On Thu, 10 Oct 2002 19:08:07 -0700 (PDT) > Greg Shepherd wrote: > > > > On Thu, 10 Oct 2002, Marshall Eubanks wrote: > > > > > 2000 member multi-player games come to mind. I believe that these have > > > been done (as military simulations). > > > > > > SSM will have state and flows that goes as N^2 in this case - the > > > > Many-to-many will always have flow of order of 1 outbound and N-1 inbound > > - ASM or SSM. State is also the same between SSM and ASM - though > > Greg; > > I am not sure I agree... > > Assume some many to many game application implemented using multicast > > Suppose that you at home and someone at the U of O want to participate in the > same group, and that I join here too. Assume (as I believe to be the case) that > you and the UO guy are topologically close in the network, and let the router A > be at the point where the tree from me to you two diverges, and assume symmetric > routing. Where or not the paths diverge has no impact on state. You join *,G - you get packets from S1 and S2, so your DR joins S1,G and S2,G - you get data from both sources and you have the state for both source trees and the shared tree. Greg > Now, in an ASM model, I join one group. At the router A, once the SPT is set up, > there is only state for the one path to me. In the SSM model, I have to join 2 > channels - one for you, and one for UO. At router A, even though the groups have > the same path, state has to be maintained for both channels. So, no, I do not > see that the state is the same between SSM and ASM in this case, at least > between router A and me, although the data flow is the same. Whether this is > important is another question. > > > technically SSM has less state in that it does not require *,G for each > > unique G. Only a shared-tree-only mechanism like BiDir can reduce state > > for ASM. > > > > The ONLY thing ASM has over SSM is in-band source discovery. So do we > > build some ~universal mechanism in protocols to provide this, or do we > > push off to the application writers to provide source-discovery as best > > fits their audience scale and needs. Hmmm. ;-) > > > > You may be right. Maybe there is no real _need_ for inter-domain ASM protocols > in IPv6. > > Maybe a toolkit approach would make sense here - if you need automatic > source-discovery, here are some ways to do it - along the lines of the reliable > multicast working group approach. > > > Greg > > > > Marshall > > > > real question is, can there be multi-domain solutions that only require > > > state and flows of order N. > > > > > > Regards > > > Marshall > > > > > > Leonard Giuliano wrote: > > > > -) > > > > > -) > However, you might be able to make ASM "SSM like" in that, if you > > > > -) > find the group address by some means out of band, you can join to > > the RP > > > > -) > and either send or receive. > > > > -) > > > > -) This is actually what is expected to happen. The steps look like: > > > > -) > > > > > > > > Going back a bit, if this ASM mechanism will rely on SSM-like group > > > > discovery, why not just use SSM in the first place? > > > > > > > > The main problem with SSM in IPv4 is that ASM was already in use, and > > > > there aren't enough implementations/deployments of SSM yet. But v6 need > > > > not carry the same albatross of legacy mechanisms around it's neck. It's > > > > a chance to do things right from the start. > > > > > > > > Does anyone actually see any real cases where SSM won't be at least "good > > > > enough?" Is all the complexity of ASM, and the duct tape solutions being > > > > discussed worth it just so that SDR will work? > > > > > > > > > > > > -Lenny > > > > > > > > > > > > > -- > > > Regards > > > Marshall Eubanks > > > > > > > > > T.M. Eubanks > > > Multicast Technologies, Inc > > > 10301 Democracy Lane, Suite 410 > > > Fairfax, Virginia 22030 > > > Phone : 703-293-9624 Fax : 703-293-9609 > > > e-mail : tme@multicasttech.com > > > http://www.multicasttech.com > > > > > > Test your network for multicast : > > > http://www.multicasttech.com/mt/ > > > Status of Multicast on the Web : > > > http://www.multicasttech.com/status/index.html > > > > > > > > > > From owner-v6ops@ops.ietf.org Fri Oct 11 02:31:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12602 for ; Fri, 11 Oct 2002 02:31:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17ztKO-000PRX-00 for v6ops-data@psg.com; Thu, 10 Oct 2002 23:31:16 -0700 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #2) id 17ztKM-000PQq-00 for v6ops@ops.ietf.org; Thu, 10 Oct 2002 23:31:14 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9B6UflR020292; Fri, 11 Oct 2002 08:30:41 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9B6UcnA073746; Fri, 11 Oct 2002 08:30:40 +0200 Received: from dhcp22-101.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA38274 from ; Fri, 11 Oct 2002 08:30:37 +0200 Message-Id: <3DA6700C.A01BBE57@hursley.ibm.com> Date: Fri, 11 Oct 2002 08:30:36 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Margaret Wasserman Cc: IPv6 Operations Subject: Re: Proposed 6to4 work References: <5.1.0.14.2.20021010064706.029eec40@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-11.1 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret Wasserman wrote: > > Hi Brian, > > At 05:35 AM 10/10/02, Brian E Carpenter wrote: > >I'd like to propose that v6ops takes on the following items: > > > >Support for Multicast over 6to4 Networks (6TO4-MULTICAST) > > draft-ietf-ngtrans-6to4-multicast-01.txt > > (to be renamed draft-thaler-ngtrans-6to4-multicast-01.txt) > > > >Security Considerations for 6to4 > > draft-savola-ngtrans-6to4-security-01.txt > > Thanks for the submission. > > Dave and Pekka, do you think that these works are ready for consideration > as v6ops work items? Regardless of the strict answer to your question, the topics (multicast and spoofing risks) both need solutions - so sooner or later, we need to adopt drafts on these topics. > > >Any future updates to RFC 3056 and RFC 3068. > > Our charter asserts that we would be responsible for any updates > to these RFCs, but I don't know of any specific updates that have > been proposed. Did I miss something? I waiting to see whether we need to add a default MRU to RFC 3056, following the recent inconclusive discussions. That's the only thing I know of right now. Brian > > For the moment, let's talk about the two documents you listed above. > As those of you who were at the Sunnyvale meeting may recall, we need > to take several steps to accept a document into v6ops. > > For a document to become a WG work item, it must: > - Fit within the WG charter (in the opinion of the chairs) > > Itojun and I will confer off-line and give an answer on this ASAP. But, > in this particular case, let's start the next steps in parallel. > > - Have significant support from the working group, including: > - People with expertise in all applicable areas who are > willing > to invest time to review the document, provide feedback, > etc. > > Who has read either of these documents and would like to invest time in > either of them as a v6ops work item? Obviously Brian. Are there others? > Please be specific about which document(s) you are willing to work on. > Also, are there folks with multicast and/or security backgrounds who > are willing to review these documents? > > - Probable (or current) implementors, if applicable > > Has anyone implemented either of these I-Ds? Does anyone plan to > implement them when they are more stable/complete? > > - Be accepted as a work item by a rough consensus of the WG > - Should reflect WG belief that the document is taking the > correct approach and would be a good starting place for > a WG product > > Who has an opinion on whether we should/shouldn't accept these > documents as work items? Please only reply to this if you have _read_ > the document(s). This is not a general question like "should we work > on multicast extensions to 6to4?" or "Is security important?", it is a > specific question about whether or not to accept these documents as > the basis for our work. Again, please be specific about which document > you are discussing. > > Comments on the general approach taken in the documents? Are they > correct and complete enough that we are ready to move editorial control > of them to the WG? Authors, what are your opinions? > > Also, are the authors willing to serve as document editors if these > documents are accepted? > > - Have corresponding goals/milestones in the charter > - Approved by the Area Directors > > Itojun and I will work on this if/when the other pieces appear to be > falling into line. > > Thanks, > Margaret -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-v6ops@ops.ietf.org Fri Oct 11 03:34:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13410 for ; Fri, 11 Oct 2002 03:34:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 17zuJQ-0001WP-00 for v6ops-data@psg.com; Fri, 11 Oct 2002 00:34:20 -0700 Received: from moebius2.space.net ([195.30.1.100] ident=qmailr) by psg.com with smtp (Exim 3.36 #2) id 17zuJO-0001WD-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 00:34:18 -0700 Received: (qmail 90788 invoked by uid 1007); 11 Oct 2002 07:34:16 -0000 Date: Fri, 11 Oct 2002 09:34:16 +0200 From: Gert Doering To: Alain Durand Cc: IPv6 Operations , Pekka Savola , Margaret Wasserman Subject: Re: Proposed 6to4 work (security) Message-ID: <20021011093416.X80239@Space.Net> References: <3DA5F50E.3080908@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DA5F50E.3080908@sun.com>; from Alain.Durand@Sun.COM on Thu, Oct 10, 2002 at 02:45:50PM -0700 X-NCC-RegID: de.space X-Spam-Status: No, hits=-15.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Thu, Oct 10, 2002 at 02:45:50PM -0700, Alain Durand wrote: > There are also some issues aboout RFC3068, as there are very little > public relays > available today. We need to understand if this is just because we are > still very > early in IPv6 deployment or if it is because there is a fundamental problem > in the model. From what I have heard so far, there may be a couple of reasons: - there are only few 6to4 users yet, so the existing relays seem to suffice - more and more ISPs are trying to roll out "real" IPv6, so those do not perceive a need to deploy 6to4 in their networks and their customer networks (or they just don't even know about 6to4) - some people that run "classic" tunnel brokers have experimented with 6to4, and have closed down their relay due to abuse reasons (DoS attacks against IRC servers) - classic tunnels are easier to trace back. This problem could be solved by having *many* relays, and thus making it (maybe) easier to trace back the abuse to the source. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 47686 (47095) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Fri Oct 11 09:54:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21710 for ; Fri, 11 Oct 2002 09:54:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1800Ch-000Dfi-00 for v6ops-data@psg.com; Fri, 11 Oct 2002 06:51:47 -0700 Received: from ncsmtp02.ogw.rr.com ([24.93.67.83]) by psg.com with esmtp (Exim 3.36 #2) id 1800Ce-000DfM-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 06:51:44 -0700 Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9BDppup028242; Fri, 11 Oct 2002 09:51:51 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 11 Oct 2002 09:51:37 -0400 Message-ID: <3DA6D81F.1050609@nc.rr.com> Date: Fri, 11 Oct 2002 09:54:39 -0400 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mboned@network-services.uoregon.edu, v6ops@ops.ietf.org Subject: Re: New draft on embedding the RP address in IPv6 multicast address References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.1 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marshall Eubanks wrote: > On Thu, 10 Oct 2002 19:12:48 -0700 (PDT) > Greg Shepherd wrote: > >> >>On Thu, 10 Oct 2002, Marshall Eubanks wrote: >> >> [major snip] >>>The biggest use of multicast at present, by an order of magnitude or more, >> >>is >> >>>the distribution of financial data. Has any of this migrated to SSM ? It >> >>could, >> >>>maybe, but will it ? >>> >>>The amount of money that rides on these multicast packets to me provides a >> >>very >> >>>good indication that ASM will stick around. Not only is it ASM, some financial data distributors are still using DVMRP. They like it and they know it. >> >>Not a fair comparison. Financial networks are walled-gardens. In the core >>distribution layer of the network, all S,Gs are well-known and in many >>casses are ~gauranteed to be delivered too the edge layers by static >>S,G-joins - VERY SSM-like. And because the S's are known, they can use dynamic filters to switch to backup sources when connectivity goes down. >> > > > Hi Greg; > > I do not disagree - its just that I think that they will resist change. > > >>The growth in many-to-many at the edge networks is beginning to highlight >>the need for BiDir - over the next 2 years. >> So, back to an interesting discussion point. Do we need to worry about ASM in v6? Should we as the multicast standards community try and move things toward SSM? Brian From owner-v6ops@ops.ietf.org Fri Oct 11 17:19:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05403 for ; Fri, 11 Oct 2002 17:19:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1807BW-0004yo-00 for v6ops-data@psg.com; Fri, 11 Oct 2002 14:19:02 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 1807BV-0004yc-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 14:19:01 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 1807BV-000M9Z-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 14:19:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: <2F7B93351D2DC54AAC898E8325DEEAA614C6FF@mail.esn.es.net> From: "Rami Lehtonen" To: , , , "Brian Haberman" Cc: "Marshall Eubanks" , "Pekka Savola" Subject: RE: New draft on embedding the RP address in IPv6 multicast address Date: Fri, 11 Oct 2002 09:27:15 +0300 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Hi, I also see another problem in embedding the RP address in IPv6 multicast address. Now the sources have to know the address of the RP they are going to use, when selecting the multicast group address. Is there need for RP address discovery/announcement? Another problem that was identified already is that we have only one RP per group. This means that sources from the another domain than the RP can't use their own domain RP without RP-RP signalling (e.g. RP-RP Register messages). Also the receiver domain's RP does not join SPT (S, G) but (RP, G) which might be suboptimal. It could change afterwards to (S, G) when it learns the source address but this needs additional state creation signalling throughout the domains in between. And last point is that if there are no active sources for that group, this model allows Internet wide multicast state creation (from receiver(s) in another domain to the multicast group RP in another domain) compared to the domain wide state creation in IPv4 MSDP model. This is because we don't have any source active information available. - Rami Lehtonen From owner-v6ops@ops.ietf.org Fri Oct 11 17:19:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05419 for ; Fri, 11 Oct 2002 17:19:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1807BB-0004yO-00 for v6ops-data@psg.com; Fri, 11 Oct 2002 14:18:41 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 1807BA-0004yC-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 14:18:40 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 1807BA-000M92-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 14:18:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Marshall Eubanks of "Thu, 10 Oct 2002 13:43:59 EDT." <3DA5BC5F.5020800@multicasttech.com> Message-Id: To: Marshall Eubanks cc: "Mike O'Connor" , Pekka Savola , mboned@network-services.uoregon.edu, v6ops@ops.ietf.org, Brian Haberman , nesg@es.net, Jon.Crowcroft@cl.cam.ac.uk Subject: Re: New draft on embedding the RP address in IPv6 multicast address Date: Fri, 11 Oct 2002 06:04:44 +0100 From: Jon Crowcroft X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] In message <3DA5BC5F.5020800@multicasttech.com>, Marshall Eubanks typed: >>Funny how, with enough IP addresses to give ~ 10^30 to each particle in >>the universe, there may not be enough. >>Wouldn't it be simpler to just say of course, simple multicast would have been simpler, yes:) http://www.cs.ucl.ac.uk/research/rama/ back to the future... j.:) From owner-v6ops@ops.ietf.org Fri Oct 11 18:11:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06107 for ; Fri, 11 Oct 2002 18:11:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18082I-0006Vn-00 for v6ops-data@psg.com; Fri, 11 Oct 2002 15:13:34 -0700 Received: from ncsmtp02.ogw.rr.com ([24.93.67.83]) by psg.com with esmtp (Exim 3.36 #2) id 18082F-0006VJ-00 for v6ops@ops.ietf.org; Fri, 11 Oct 2002 15:13:32 -0700 Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9BMDaup027726; Fri, 11 Oct 2002 18:13:36 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 11 Oct 2002 18:13:21 -0400 Message-ID: <3DA74C6B.447303CD@nc.rr.com> Date: Fri, 11 Oct 2002 18:10:51 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rami Lehtonen CC: mboned@network-services.uoregon.edu, v6ops@ops.ietf.org Subject: Re: New draft on embedding the RP address in IPv6 multicast address References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Rami, Rami Lehtonen wrote: > > Hi, > > I also see another problem in embedding the RP address in IPv6 multicast > address. Now the sources have to know the address of the RP they are going > to use, when selecting the multicast group address. Is there need for RP > address discovery/announcement? I don't think so. Generally, I see applications being assigned addresses by network administrators. That allows the admins to setup their group to RP mappings. Other opinions? > > Another problem that was identified already is that we have only one RP per > group. This means that sources from the another domain than the RP can't use > their own domain RP without RP-RP signalling (e.g. RP-RP Register messages). Right. That is one of the open issues I pointed out. > > Also the receiver domain's RP does not join SPT (S, G) but (RP, G) which > might be suboptimal. It could change afterwards to (S, G) when it learns the > source address but this needs additional state creation signalling > throughout the domains in between. Actually, most PIM routers switch on the first packet anyway. So this approach gives you the same level of support as using MSDP. > > And last point is that if there are no active sources for that group, this > model allows Internet wide multicast state creation (from receiver(s) in > another domain to the multicast group RP in another domain) compared to the > domain wide state creation in IPv4 MSDP model. This is because we don't have > any source active information available. Good point. That issue needs to be investigated. Thanks, Brian From owner-v6ops@ops.ietf.org Tue Oct 15 23:27:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22566 for ; Tue, 15 Oct 2002 23:27:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181eq0-000P6Y-00 for v6ops-data@psg.com; Tue, 15 Oct 2002 20:27:12 -0700 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 181epy-000P6B-00 for v6ops@ops.ietf.org; Tue, 15 Oct 2002 20:27:10 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id AFD9C4B22; Wed, 16 Oct 2002 12:27:04 +0900 (JST) To: Gert Doering Cc: Alain Durand , IPv6 Operations , Pekka Savola , Margaret Wasserman In-reply-to: gert's message of Fri, 11 Oct 2002 09:34:16 +0200. <20021011093416.X80239@Space.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: Proposed 6to4 work (security) From: itojun@iijlab.net Date: Wed, 16 Oct 2002 12:27:04 +0900 Message-Id: <20021016032704.AFD9C4B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >On Thu, Oct 10, 2002 at 02:45:50PM -0700, Alain Durand wrote: >There are also some issues aboout RFC3068, as there are very little >public relays available today. We need to understand if this is >just because we are still very early in IPv6 deployment or if it >is because there is a fundamental problem in the model. as outlined in draft-itojun-ipv6-transition-abuse-01.txt, 6to4 relay routers - are packet laundering services to malicious parties. malicious parties can generate IPv6 packets anonymously by (ab)using 6to4 relay routers. - can chew up bandwidth of the 6to4 public relay router provider, and there's no way for an ISP to limit accesses to the relay router to their customers (it has to be public service to everyone) so ISPs has more risks than benefits in running 6to4 relay routers. itojun From owner-v6ops@ops.ietf.org Wed Oct 16 01:43:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25700 for ; Wed, 16 Oct 2002 01:43:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181gyV-0001La-00 for v6ops-data@psg.com; Tue, 15 Oct 2002 22:44:07 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 181gyT-0001LN-00 for v6ops@ops.ietf.org; Tue, 15 Oct 2002 22:44:05 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9G5hqr09740; Wed, 16 Oct 2002 08:43:53 +0300 Date: Wed, 16 Oct 2002 08:43:51 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: Gert Doering , Alain Durand , IPv6 Operations , Margaret Wasserman Subject: Re: Proposed 6to4 work (security) In-Reply-To: <20021016032704.AFD9C4B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 16 Oct 2002 itojun@iijlab.net wrote: > as outlined in draft-itojun-ipv6-transition-abuse-01.txt, 6to4 > relay routers [...] > - can chew up bandwidth of the 6to4 public relay router provider, and > there's no way for an ISP to limit accesses to the relay router > to their customers (it has to be public service to everyone) I believe you *can* quite effectively limit the access. First by not advertising 2002::/16 or 192.88.99.1 to your peers (or doing it by some controlled measure, like no-export community), and if it's really important, placing some ACL's. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Oct 16 02:03:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28278 for ; Wed, 16 Oct 2002 02:03:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181hIw-0001hj-00 for v6ops-data@psg.com; Tue, 15 Oct 2002 23:05:14 -0700 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 181hIt-0001hW-00 for v6ops@ops.ietf.org; Tue, 15 Oct 2002 23:05:11 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 6604F4B22; Wed, 16 Oct 2002 15:05:09 +0900 (JST) To: Pekka Savola Cc: IPv6 Operations , Margaret Wasserman In-reply-to: pekkas's message of Wed, 16 Oct 2002 08:43:51 +0300. 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: Proposed 6to4 work (security) From: itojun@iijlab.net Date: Wed, 16 Oct 2002 15:05:09 +0900 Message-Id: <20021016060509.6604F4B22@coconut.itojun.org> X-Spam-Status: No, hits=-5.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> - can chew up bandwidth of the 6to4 public relay router provider, and >> there's no way for an ISP to limit accesses to the relay router >> to their customers (it has to be public service to everyone) >I believe you *can* quite effectively limit the access. First by not >advertising 2002::/16 or 192.88.99.1 to your peers (or doing it by some >controlled measure, like no-export community), and if it's really >important, placing some ACL's. you are correct if you don't have downstream ISPs. if you are a big ISP and have downstream ISPs, by doing the above you will prohibit your downstream ISPs from providing 6to4 relay routers. i'm not sure if it is an acceptable thing to do. itojun From owner-v6ops@ops.ietf.org Wed Oct 16 02:59:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20407 for ; Wed, 16 Oct 2002 02:59:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181i8p-0002Y8-00 for v6ops-data@psg.com; Tue, 15 Oct 2002 23:58:51 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 181i8o-0002Xw-00 for v6ops@ops.ietf.org; Tue, 15 Oct 2002 23:58:50 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9G6whc10280; Wed, 16 Oct 2002 09:58:44 +0300 Date: Wed, 16 Oct 2002 09:58:43 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: IPv6 Operations , Margaret Wasserman Subject: Re: Proposed 6to4 work (security) In-Reply-To: <20021016060509.6604F4B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 16 Oct 2002 itojun@iijlab.net wrote: > >> - can chew up bandwidth of the 6to4 public relay router provider, and > >> there's no way for an ISP to limit accesses to the relay router > >> to their customers (it has to be public service to everyone) > >I believe you *can* quite effectively limit the access. First by not > >advertising 2002::/16 or 192.88.99.1 to your peers (or doing it by some > >controlled measure, like no-export community), and if it's really > >important, placing some ACL's. > > you are correct if you don't have downstream ISPs. > > if you are a big ISP and have downstream ISPs, by doing the above you > will prohibit your downstream ISPs from providing 6to4 relay routers. > i'm not sure if it is an acceptable thing to do. True, but I believe this is a bit non-issue: if a downstream ISP is providing the service for everyone, you as a big ISP doesn't really need to do it that badly (except perhaps as a backup, and then different policy could apply -- connect the relay with BGP and have the routes be less preferred) yourself. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Oct 16 04:08:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21707 for ; Wed, 16 Oct 2002 04:08:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181jF4-0003jz-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 01:09:22 -0700 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #2) id 181jF2-0003jn-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 01:09:20 -0700 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA03361 for ; Wed, 16 Oct 2002 09:09:18 +0100 (BST) Received: from starling.ecs.soton.ac.uk (starling.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g9G89DWX017271 for ; Wed, 16 Oct 2002 09:09:13 +0100 Received: (from tjc@localhost) by starling.ecs.soton.ac.uk (8.11.6/8.11.6) id g9G89Dc04796 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 09:09:13 +0100 Date: Wed, 16 Oct 2002 09:09:13 +0100 From: Tim Chown To: IPv6 Operations Subject: Re: Proposed 6to4 work (security) Message-ID: <20021016080912.GB4737@starling.ecs.soton.ac.uk> Mail-Followup-To: IPv6 Operations References: <20021016032704.AFD9C4B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-13.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Oct 16, 2002 at 08:43:51AM +0300, Pekka Savola wrote: > On Wed, 16 Oct 2002 itojun@iijlab.net wrote: > > as outlined in draft-itojun-ipv6-transition-abuse-01.txt, 6to4 > > relay routers > [...] > > - can chew up bandwidth of the 6to4 public relay router provider, and > > there's no way for an ISP to limit accesses to the relay router > > to their customers (it has to be public service to everyone) > > I believe you *can* quite effectively limit the access. First by not > advertising 2002::/16 or 192.88.99.1 to your peers (or doing it by some > controlled measure, like no-export community), and if it's really > important, placing some ACL's. didn't the same lessons get learnt with smtp relays and abuse, leading to isp's only allowing their own customers to use their smtp service? is there a reason to hope 6to4 could be different? there probably has to be some differentiation between transition tools that can be used when the isp offers support (e.g. isatap), and the tools used in spite of a lack of isp support (e.g. tunnel broker, where some authentication can, at present, be more easily included if required). tim From owner-v6ops@ops.ietf.org Wed Oct 16 04:18:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21839 for ; Wed, 16 Oct 2002 04:18:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181jOV-0003sq-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 01:19:07 -0700 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #2) id 181jOT-0003sc-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 01:19:05 -0700 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA03454 for ; Wed, 16 Oct 2002 09:18:55 +0100 (BST) Received: from starling.ecs.soton.ac.uk (starling.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g9G8IoWX018899 for ; Wed, 16 Oct 2002 09:18:50 +0100 Received: (from tjc@localhost) by starling.ecs.soton.ac.uk (8.11.6/8.11.6) id g9G8Io804828 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 09:18:50 +0100 Date: Wed, 16 Oct 2002 09:18:50 +0100 From: Tim Chown To: IPv6 Operations Subject: Re: Proposed 6to4 work Message-ID: <20021016081850.GF4737@starling.ecs.soton.ac.uk> Mail-Followup-To: IPv6 Operations References: <3DA549D0.19BDC154@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-13.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Oct 10, 2002 at 02:32:59PM +0300, Pekka Savola wrote: > On Thu, 10 Oct 2002, Brian E Carpenter wrote: > > I'd like to propose that v6ops takes on the following items: > > > > Support for Multicast over 6to4 Networks (6TO4-MULTICAST) > > draft-ietf-ngtrans-6to4-multicast-01.txt > > (to be renamed draft-thaler-ngtrans-6to4-multicast-01.txt) > > I'm a bit skeptic whether this can be made to work, and the fact that some > 200 lines of comments I sent on the list on 11 Jul 2002 went unresponded > didn't exactly help my skepticism.. I think it is a concern if the home user is possibly going to be a big target for 6to4 deployment (if cheap DSL+6to4 routers become available) and one of the desired delivery methods for certain IPv6 services is multicast. But we should also look at Multicast functionality in other transition tools too. > > Security Considerations for 6to4 > > draft-savola-ngtrans-6to4-security-01.txt > > The draft has focused on trying to spell out the filtering rules that > could be done when implementing 6to4 .. but it takes no stance on "6to4 > relay trust" issues. Those issues could be added if there's some thought > how they can be solved (I can't think of any other than propagating more > specific routes which doesn't seem to be an option). I think all three drafts mentioned by Brian should be taken forward if 6to4 itself is on the v6ops menu. Tim From owner-v6ops@ops.ietf.org Wed Oct 16 04:35:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22252 for ; Wed, 16 Oct 2002 04:35:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181jem-000498-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 01:35:56 -0700 Received: from moebius2.space.net ([195.30.1.100] ident=qmailr) by psg.com with smtp (Exim 3.36 #2) id 181jek-00048a-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 01:35:54 -0700 Received: (qmail 96253 invoked by uid 1007); 16 Oct 2002 08:35:46 -0000 Date: Wed, 16 Oct 2002 10:35:46 +0200 From: Gert Doering To: itojun@iijlab.net Cc: Gert Doering , Alain Durand , IPv6 Operations , Pekka Savola , Margaret Wasserman Subject: Re: Proposed 6to4 work (security) Message-ID: <20021016103546.Q94537@Space.Net> References: <20021011093416.X80239@Space.Net> <20021016032704.AFD9C4B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021016032704.AFD9C4B22@coconut.itojun.org>; from itojun@iijlab.net on Wed, Oct 16, 2002 at 12:27:04PM +0900 X-NCC-RegID: de.space X-Spam-Status: No, hits=-15.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk hi, On Wed, Oct 16, 2002 at 12:27:04PM +0900, itojun@iijlab.net wrote: > - can chew up bandwidth of the 6to4 public relay router provider, and > there's no way for an ISP to limit accesses to the relay router > to their customers (it has to be public service to everyone) It would be possible to restrict access by just not announcing the relay addresses (unicast or anycast) into the "public network". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48282 (47686) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Wed Oct 16 10:31:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00860 for ; Wed, 16 Oct 2002 10:31:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181pDs-000ANf-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 07:32:32 -0700 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #2) id 181pDp-000AMP-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 07:32:30 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9GEVYtt035014; Wed, 16 Oct 2002 16:31:35 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9GEVXmd025316; Wed, 16 Oct 2002 16:31:34 +0200 Received: from gsine01.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47662 from ; Wed, 16 Oct 2002 16:31:29 +0200 Message-Id: <3DAD783A.2DB24A1D@hursley.ibm.com> Date: Wed, 16 Oct 2002 16:31:22 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: itojun@iijlab.net, IPv6 Operations , Margaret Wasserman Subject: Re: Proposed 6to4 work (security) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > On Wed, 16 Oct 2002 itojun@iijlab.net wrote: > > >> - can chew up bandwidth of the 6to4 public relay router provider, and > > >> there's no way for an ISP to limit accesses to the relay router > > >> to their customers (it has to be public service to everyone) > > >I believe you *can* quite effectively limit the access. First by not > > >advertising 2002::/16 or 192.88.99.1 to your peers (or doing it by some > > >controlled measure, like no-export community), and if it's really > > >important, placing some ACL's. > > > > you are correct if you don't have downstream ISPs. > > > > if you are a big ISP and have downstream ISPs, by doing the above you > > will prohibit your downstream ISPs from providing 6to4 relay routers. > > i'm not sure if it is an acceptable thing to do. > > True, but I believe this is a bit non-issue: if a downstream ISP is > providing the service for everyone, you as a big ISP doesn't really need > to do it that badly (except perhaps as a backup, and then different policy > could apply -- connect the relay with BGP and have the routes be less > preferred) yourself. The idea was that relays would be run either by cooperatives or downstream ISPs. I can't see why a transit provider would want to run one. The spoofing issue is more serious; I can't see anything but some kind of ingress filtering to protect against that. This is why we need a 6to4 security draft in this WG. Brian From owner-v6ops@ops.ietf.org Wed Oct 16 13:03:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05802 for ; Wed, 16 Oct 2002 13:03:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181rbP-000DSr-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 10:04:59 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 181rbN-000DSL-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 10:04:57 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA01800 for ; Wed, 16 Oct 2002 10:04:26 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9GH4Qt32628 for ; Wed, 16 Oct 2002 10:04:26 -0700 X-mProtect: <200210161704> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtJZjVo; Wed, 16 Oct 2002 10:04:24 PDT Message-ID: <3DAD9C93.1090702@iprg.nokia.com> Date: Wed, 16 Oct 2002 10:06:27 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: Proposed 6to4 work (security) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Just reading through the comments so far, it occurs to me that any work on a 6to4 security document might benefit from a detailed analysis of anticipated deployment scenarios for relay routers. The latest teredo specification gives a nice taxonomy when it speaks of globally-accessible, domain-specific, and host-specific relays. While the teredo and 6to4 relays are different beasts, perhaps the 6to4 security study could take the example of teredo in adopting a deployment scenario taxonomy. In terms of the current discussion (and loosly applying the teredo taxonomy to 6to4), I believe the security issues raised thus far pertain to the "globally-accessible" scenario. I don't know whether "domain-specific" or "host-specific" deployment scenarios exist, but it seems to me that both cases are supported by the RFC 3056 specification and thus might require attention in the security study. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Oct 16 14:28:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08336 for ; Wed, 16 Oct 2002 14:28:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181sv1-000F0U-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 11:29:19 -0700 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by psg.com with esmtp (Exim 3.36 #2) id 181suz-000Ezz-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 11:29:17 -0700 Received: from newtwinkle.mcs.anl.gov (vpnclient18112.mcs.anl.gov [140.221.18.112]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id NAA165534; Wed, 16 Oct 2002 13:28:27 -0500 Message-Id: <5.1.1.6.2.20021016132340.02dd7b78@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 16 Oct 2002 13:27:06 -0500 To: Leonard Giuliano From: Bill Nickless Subject: Re: New draft on embedding the RP address in IPv6 multicast address Cc: Brian Haberman , Marshall Eubanks , "Mike O'Connor" , Pekka Savola , , , In-Reply-To: <20021010142459.F86853-100000@maroon.jnpr.net> References: <3DA5B917.1000900@nc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-5.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 02:36 PM 10/10/2002 -0700, Leonard Giuliano wrote: >The main problem with SSM in IPv4 is that ASM was already in use, and >there aren't enough implementations/deployments of SSM yet. But v6 need >not carry the same albatross of legacy mechanisms around it's neck. It's >a chance to do things right from the start. IMHO, the biggest barrier to IPv4 SSM deployment is the requirement that edge IEEE 802 switches be re-engineered to understand a new kind of IP packet: the IPv4 IGMPv3 packet. IPv6 suffers from the same problem; to wit, that IEEE 802 switches have to now be re-engineered to interpret IPv6 MLD packets. Fix the unreasonable IGMPv3/MLD requirement for nominally IEEE 802 switches, and I'll bet you dollars to donuts that SSM will take off like a rocket. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov From owner-v6ops@ops.ietf.org Wed Oct 16 14:32:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08408 for ; Wed, 16 Oct 2002 14:32:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181syI-000F57-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 11:32:42 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 181syH-000F4u-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 11:32:41 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9GIVog15839; Wed, 16 Oct 2002 21:31:50 +0300 Date: Wed, 16 Oct 2002 21:31:50 +0300 (EEST) From: Pekka Savola To: Bill Nickless cc: Leonard Giuliano , Brian Haberman , Marshall Eubanks , "Mike O'Connor" , , , Subject: Re: New draft on embedding the RP address in IPv6 multicast address In-Reply-To: <5.1.1.6.2.20021016132340.02dd7b78@pop.mcs.anl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 16 Oct 2002, Bill Nickless wrote: ... > IPv6 suffers from the same problem; to wit, that IEEE 802 switches have to > now be re-engineered to interpret IPv6 MLD packets. No: most switches by far work *just* fine. Only if you want snooping features, or the switch uses a broken logic (see the issues draft) you have problems.. > Fix the unreasonable IGMPv3/MLD requirement for nominally IEEE 802 > switches, and I'll bet you dollars to donuts that SSM will take off like a > rocket. Most switches work fine as is I believe, though flooding the multicasts all over the segment.. yet where is SSM? I sure would like to have it.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Oct 16 14:36:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08526 for ; Wed, 16 Oct 2002 14:36:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181t2w-000FCB-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 11:37:30 -0700 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by psg.com with esmtp (Exim 3.36 #2) id 181t2u-000FBa-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 11:37:29 -0700 Received: from newtwinkle.mcs.anl.gov (vpnclient18112.mcs.anl.gov [140.221.18.112]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id NAA158068; Wed, 16 Oct 2002 13:36:34 -0500 Message-Id: <5.1.1.6.2.20021016133338.021c9e10@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 16 Oct 2002 13:36:25 -0500 To: Pekka Savola From: Bill Nickless Subject: Re: New draft on embedding the RP address in IPv6 multicast address Cc: Bill Nickless , Leonard Giuliano , Brian Haberman , Marshall Eubanks , "Mike O'Connor" , , , In-Reply-To: References: <5.1.1.6.2.20021016132340.02dd7b78@pop.mcs.anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 09:31 PM 10/16/2002 +0300, Pekka Savola wrote: >No: most switches by far work *just* fine. > >Only if you want snooping features, or the switch uses a broken logic (see >the issues draft) you have problems.. Well over a year ago we ran into situations where a normal Access Grid traffic would overrun a 10 megabit/sec switch port. At the time the hosts were listening to RIP broadcasts to learn their default route. The congestion on those 10 megabit/sec switch ports was *SO* bad that the hosts lost their RIP default route. Darn right I want packets on a segment to only go to the appropriate output ports. If I wanted a single collision domain I wouldn't buy a switch. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov From owner-v6ops@ops.ietf.org Wed Oct 16 15:08:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09676 for ; Wed, 16 Oct 2002 15:08:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181tXs-000FsK-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 12:09:28 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 181tXr-000Fs8-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 12:09:27 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9GJ8uI16170; Wed, 16 Oct 2002 22:08:56 +0300 Date: Wed, 16 Oct 2002 22:08:56 +0300 (EEST) From: Pekka Savola To: ken lindahl cc: Bill Nickless , Leonard Giuliano , Brian Haberman , Marshall Eubanks , "Mike O'Connor" , , , Subject: Re: New draft on embedding the RP address in IPv6 multicast address In-Reply-To: <5.1.0.14.2.20021016114102.048802d0@uclink.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 16 Oct 2002, ken lindahl wrote: > At 09:31 PM 10/16/2002 +0300, Pekka Savola wrote: > >Most switches work fine as is I believe, though flooding the multicasts > >all over the segment.. yet where is SSM? I sure would like to have it.. > > that definition of working "fine" doesn't work for my campus. berkeley > researchers are investigating the use of relatively high-bandwidth > multicast (>10Mbps per stream) and i really don't want that flooding > on departmental segments with one receiver. other Internet2-connected > institutions are in similar positions, i think. Smaller segments can be used if that's really a problem (100/FD should probably handle some 20-30Mbit/s of multicast per port without anyone noticing anything but I haven't tested). SSM <-> ASM reflectors (I dunno if these have been specified but should not be difficult) could be used if that's really a problem. > i agree with Bill's earlier comment: lack of IGMPv3 snooping in current > switches is a major obstacle to IPv4 SSM deployment, and lack of MLD > snooping will become an impediment to IPv6 SSM deployment. There are many different kind of multicasts. If SSM would be hitting big, it would have come through with the other multicast applications (not so high volume), but where is it now..? I guess that's a good way to explain why SSM may be failing. Sure, IGMPv3, MLDv2 snooping would be nice but it seems hypocritical to say this is the reason why SSM isn't being used.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Oct 16 15:26:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09996 for ; Wed, 16 Oct 2002 15:26:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181tpe-000GHh-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 12:27:50 -0700 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by psg.com with esmtp (Exim 3.36 #2) id 181tpd-000GGb-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 12:27:49 -0700 Received: from newtwinkle.mcs.anl.gov (vpnclient18112.mcs.anl.gov [140.221.18.112]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id OAA102706; Wed, 16 Oct 2002 14:26:45 -0500 Message-Id: <5.1.1.6.2.20021016141313.027b6860@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 16 Oct 2002 14:26:37 -0500 To: Pekka Savola From: Bill Nickless Subject: Re: New draft on embedding the RP address in IPv6 multicast address Cc: ken lindahl , Bill Nickless , Leonard Giuliano , Brian Haberman , Marshall Eubanks , "Mike O'Connor" , , , In-Reply-To: References: <5.1.0.14.2.20021016114102.048802d0@uclink.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-5.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 10:08 PM 10/16/2002 +0300, Pekka Savola wrote: >Smaller segments can be used if that's really a problem (100/FD should >probably handle some 20-30Mbit/s of multicast per port without anyone >noticing anything but I haven't tested). If I have to re-engineer a network, resegmenting and renumbering, just to support multicast (IPv4, IPv6, SSM, or ASM), then I'd better have a darn good business case to go to all that expense and complexity. Taking your suggestion to an extreme, I would have to provide a layer-3 routed port for every high-bandwidth multicast host. Should I have to go to the trouble of assigning IPv4 /31s or /30s, or IPv6 /126es for every multicast-speaking host? Sorry, it's just not going to happen. IEEE 802 switches function just fine to send unicast frames only to the ports for which they're intended. Unicast IP uses ARP/ND to discover the MAC addresses that the IEEE 802 switches depend on to make this happen. What's wrong with asking IP multicast to use a similar mechanism? === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov From owner-v6ops@ops.ietf.org Wed Oct 16 15:47:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10386 for ; Wed, 16 Oct 2002 15:47:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181u9g-000Gjf-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 12:48:32 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 181u9e-000GjN-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 12:48:31 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9GJm3216590; Wed, 16 Oct 2002 22:48:03 +0300 Date: Wed, 16 Oct 2002 22:48:03 +0300 (EEST) From: Pekka Savola To: ken lindahl cc: Bill Nickless , Leonard Giuliano , Brian Haberman , Marshall Eubanks , "Mike O'Connor" , , , Subject: Re: New draft on embedding the RP address in IPv6 multicast address In-Reply-To: <5.1.0.14.2.20021016122221.0488f8d8@uclink.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 16 Oct 2002, ken lindahl wrote: > >Sure, IGMPv3, MLDv2 snooping would be nice but it seems hypocritical to > >say this is the reason why SSM isn't being used.. > > IGMPv2 snooping is enabled now on large parts of campus. i don't think > IGMPv3 will play nicely with that. disabling IGMP snooping so that SSM > will work doesn't seem like a step forward. where's the hypocracy in > that? Why would a switch with IGMP snooping enabled that doesn't understand a word about IGMPv3 not handle IGMPv2 snooping properly even though SSM multicast is broadcasted initally to every port in a segment with receivers? (Note: most switches with IGMP snooping enabled forward IPv6 multicasts just fine.) If that's not possible, seems like a huge problem with IGMP (snooping): either specification or implementation. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Oct 16 16:19:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11047 for ; Wed, 16 Oct 2002 16:19:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181uf7-000HQb-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 13:21:01 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 181uf5-000HQP-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 13:20:59 -0700 Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16229 for ; Wed, 16 Oct 2002 14:20:58 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H43005P7CIX6Y@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 16 Oct 2002 14:20:58 -0600 (MDT) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H4300AD3CIXVP@mail.sun.net> for v6ops@ops.ietf.org; Wed, 16 Oct 2002 14:20:57 -0600 (MDT) Date: Wed, 16 Oct 2002 13:19:58 -0700 From: Alain Durand Subject: Re: Proposed 6to4 work (security) To: Tim Chown Cc: IPv6 Operations Message-id: <3DADC9EE.2020608@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020719 Netscape/7.0 References: <20021016032704.AFD9C4B22@coconut.itojun.org> <20021016080912.GB4737@starling.ecs.soton.ac.uk> X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Tim Chown wrote: >On Wed, Oct 16, 2002 at 08:43:51AM +0300, Pekka Savola wrote: > > >>I believe you *can* quite effectively limit the access. First by not >>advertising 2002::/16 or 192.88.99.1 to your peers (or doing it by some >>controlled measure, like no-export community), and if it's really >>important, placing some ACL's. >> >> > >didn't the same lessons get learnt with smtp relays and abuse, leading to >isp's only allowing their own customers to use their smtp service? is >there a reason to hope 6to4 could be different > This is different.SMTP relay is part of the expected service from an ISP. 6to4 relay is not. One cannot build a deployment model of 6to4 that assumes that the v4 ISP have deployed a 6to4 relay. - Alain. From owner-v6ops@ops.ietf.org Wed Oct 16 16:27:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11281 for ; Wed, 16 Oct 2002 16:27:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181unK-000HcC-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 13:29:30 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 181unJ-000Hbz-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 13:29:29 -0700 Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05565 for ; Wed, 16 Oct 2002 14:29:28 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H430010QCW5PJ@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 16 Oct 2002 14:29:28 -0600 (MDT) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H4300G1TCW4LS@mail.sun.net> for v6ops@ops.ietf.org; Wed, 16 Oct 2002 14:28:53 -0600 (MDT) Date: Wed, 16 Oct 2002 13:27:53 -0700 From: Alain Durand Subject: Re: Proposed 6to4 work (security) To: Brian E Carpenter Cc: Pekka Savola , itojun@iijlab.net, IPv6 Operations , Margaret Wasserman Message-id: <3DADCBC9.5010504@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020719 Netscape/7.0 References: <3DAD783A.2DB24A1D@hursley.ibm.com> X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Brian E Carpenter wrote: >The spoofing issue is more serious; I can't see anything but some kind >of ingress filtering to protect against that. > This won't work. When a 6to4 relay send a packet to the 6to4 world, it uses it's IPv4 address as source in the outer header. IPv4 ingress filetering will always let it go through. When a 6to4 router receive an encapsulated packet on its external interface that has a native IPv6 inner src address, it can not do any security checks on the outer IPv4 address, as it can come from any host in the internet. More, as there is no mapping between the IPv4 src and the IPv6 src addresses, it is impossible to do any IPv6 ingress filtering. I fear there is no way to prevent spoofing. >This is why we need a 6to4 security draft in this WG. > Agreed. > Brian > - Alain. From owner-v6ops@ops.ietf.org Wed Oct 16 16:38:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11586 for ; Wed, 16 Oct 2002 16:38:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181uxs-000Hsc-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 13:40:24 -0700 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #2) id 181uxq-000HrX-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 13:40:22 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9GKdaJf018628; Wed, 16 Oct 2002 22:39:36 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id g9GKdZ5f077146; Wed, 16 Oct 2002 22:39:35 +0200 Received: from gsine01.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA64386 from ; Wed, 16 Oct 2002 22:39:29 +0200 Message-Id: <3DADCE73.8B85FEB3@hursley.ibm.com> Date: Wed, 16 Oct 2002 22:39:15 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Alain Durand Cc: Pekka Savola , itojun@iijlab.net, IPv6 Operations , Margaret Wasserman Subject: Re: Proposed 6to4 work (security) References: <3DAD783A.2DB24A1D@hursley.ibm.com> <3DADCBC9.5010504@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-10.4 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I was thinking of IPv6 ingress filtering (i.e. the relay, or the ISP running the relay, only accepts native IPv6 traffic from legitimate sources). IPv4 is only a link layer in the 6to4 context, so you have to treat it as transparent. Spoofing has to be handled as an IPv6 issue. Brian Alain Durand wrote: > > Brian E Carpenter wrote: > > >The spoofing issue is more serious; I can't see anything but some kind > >of ingress filtering to protect against that. > > > This won't work. When a 6to4 relay send a packet to the 6to4 world, > it uses it's IPv4 address as source in the outer header. > IPv4 ingress filetering will always let it go through. > > When a 6to4 router receive an encapsulated packet on its external interface > that has a native IPv6 inner src address, it can not do any security > checks on the outer IPv4 address, as it can come from any host in the > internet. More, as there is no mapping between the IPv4 src and > the IPv6 src addresses, it is impossible to do any IPv6 ingress filtering. > > I fear there is no way to prevent spoofing. > > >This is why we need a 6to4 security draft in this WG. > > > Agreed. > > > Brian > > > > - Alain. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-v6ops@ops.ietf.org Wed Oct 16 16:40:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11617 for ; Wed, 16 Oct 2002 16:40:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181uyS-000HuR-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 13:41:00 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 181uyQ-000HuF-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 13:40:58 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9GKelf17015; Wed, 16 Oct 2002 23:40:47 +0300 Date: Wed, 16 Oct 2002 23:40:47 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: Brian E Carpenter , , IPv6 Operations , Margaret Wasserman Subject: Re: Proposed 6to4 work (security) In-Reply-To: <3DADCBC9.5010504@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 16 Oct 2002, Alain Durand wrote: > Brian E Carpenter wrote: > > >The spoofing issue is more serious; I can't see anything but some kind > >of ingress filtering to protect against that. > > > This won't work. When a 6to4 relay send a packet to the 6to4 world, > it uses it's IPv4 address as source in the outer header. > IPv4 ingress filetering will always let it go through. The source IPv4 address could be '192.88.99.1'. If this was mandated, perhaps some checks would be easier. On the other hand, certain things (ones that were also criticized by IESG in Shipworm..) would appear. That's what it is in our publicly usable (as far from the US and Japan, even) relay. > When a 6to4 router receive an encapsulated packet on its external interface > that has a native IPv6 inner src address, it can not do any security > checks on the outer IPv4 address, as it can come from any host in the > internet. More, as there is no mapping between the IPv4 src and > the IPv6 src addresses, it is impossible to do any IPv6 ingress filtering. > > I fear there is no way to prevent spoofing. See above: it's not complete, but at least it's something. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Oct 16 17:19:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12547 for ; Wed, 16 Oct 2002 17:19:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181vZX-000ImL-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 14:19:19 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 181vZW-000Im9-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 14:19:18 -0700 Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11402 for ; Wed, 16 Oct 2002 15:19:18 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H4300172F85PJ@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 16 Oct 2002 15:19:17 -0600 (MDT) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H4300G0KF84LI@mail.sun.net> for v6ops@ops.ietf.org; Wed, 16 Oct 2002 15:19:17 -0600 (MDT) Date: Wed, 16 Oct 2002 14:18:18 -0700 From: Alain Durand Subject: Re: Proposed 6to4 work (security) To: Pekka Savola Cc: Brian E Carpenter , itojun@iijlab.net, IPv6 Operations , Margaret Wasserman Message-id: <3DADD79A.3080900@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020719 Netscape/7.0 References: X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Pekka Savola wrote: > > >The source IPv4 address could be '192.88.99.1'. If this was mandated, >perhaps some checks would be easier. On the other hand, certain things >(ones that were also criticized by IESG in Shipworm..) would appear. > How could you make regular IPv4 ingress filtering work? If you create an exception fo 192.88.99.1, anybody could impersonate a 6to4 relay, if you don't, packets will never reach destination... - Alain. From owner-v6ops@ops.ietf.org Wed Oct 16 17:33:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12780 for ; Wed, 16 Oct 2002 17:33:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181vno-000JBM-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 14:34:04 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 181vnm-000JB0-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 14:34:03 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9GLXrO17544; Thu, 17 Oct 2002 00:33:53 +0300 Date: Thu, 17 Oct 2002 00:33:53 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: Brian E Carpenter , , IPv6 Operations , Margaret Wasserman Subject: Re: Proposed 6to4 work (security) In-Reply-To: <3DADD79A.3080900@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-10.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 16 Oct 2002, Alain Durand wrote: > >The source IPv4 address could be '192.88.99.1'. If this was mandated, > >perhaps some checks would be easier. On the other hand, certain things > >(ones that were also criticized by IESG in Shipworm..) would appear. > > > > How could you make regular IPv4 ingress filtering work? > If you create an exception fo 192.88.99.1, anybody could > impersonate a 6to4 relay, if you don't, packets will > never reach destination... There are no need for any ingress filtering (implementation) exceptions. Only, you can't run 6to4 relay unless your upstream allows you to use that IP address. But that's, in my mind, in line with proper operational procedures anyway. It depends much on who's expected to run relays, though. With this what we could achieve is that to spoof these packets, the spoofer would have to be either in an area where there is no ingress filtering at all (ie. core, usually -- and there direct ipv6 spoofing would be equally useful) or where it has been explicitly allowed. The only real problem comes in certain cases if you're using unicast RPF, I enumerated these a year or so ago in a mail to Brian Carpenter and ngtrans. There are other options, some more scalable than others (like running multihop eBGP between "trusted" relays and propagating more specifics between them only -- in this way 6to4 sites could have total control and there could be a trust relationship between site <-> relay). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Oct 16 19:35:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15103 for ; Wed, 16 Oct 2002 19:35:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181xiK-000M2h-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 16:36:32 -0700 Received: from roam.psg.com ([147.28.4.2] ident=exim) by psg.com with esmtp (Exim 3.36 #2) id 181xiJ-000M2V-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 16:36:31 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 181xiH-0000xG-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 16:36:29 -0700 Message-Id: <5.1.0.14.2.20021016114102.048802d0@uclink.berkeley.edu> In-Reply-To: References: <5.1.1.6.2.20021016132340.02dd7b78@pop.mcs.anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Oct 2002 11:47:39 -0700 To: Pekka Savola , Bill Nickless From: ken lindahl Subject: Re: New draft on embedding the RP address in IPv6 multicast address Cc: Leonard Giuliano , Brian Haberman , Marshall Eubanks , "Mike O'Connor" , , , X-Spam-Status: No, hits=-6.5 required=5.0 tests=IN_REP_TO,REFERENCES,RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] At 09:31 PM 10/16/2002 +0300, Pekka Savola wrote: >Most switches work fine as is I believe, though flooding the multicasts >all over the segment.. yet where is SSM? I sure would like to have it.. that definition of working "fine" doesn't work for my campus. berkeley researchers are investigating the use of relatively high-bandwidth multicast (>10Mbps per stream) and i really don't want that flooding on departmental segments with one receiver. other Internet2-connected institutions are in similar positions, i think. i agree with Bill's earlier comment: lack of IGMPv3 snooping in current switches is a major obstacle to IPv4 SSM deployment, and lack of MLD snooping will become an impediment to IPv6 SSM deployment. i sure would like to have SSM too... ken From owner-v6ops@ops.ietf.org Wed Oct 16 19:35:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15117 for ; Wed, 16 Oct 2002 19:35:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181xiU-000M2v-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 16:36:42 -0700 Received: from roam.psg.com ([147.28.4.2] ident=exim) by psg.com with esmtp (Exim 3.36 #2) id 181xiS-000M2j-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 16:36:41 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 181xiR-0000xL-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 16:36:39 -0700 Message-Id: <5.1.0.14.2.20021016122221.0488f8d8@uclink.berkeley.edu> In-Reply-To: References: <5.1.0.14.2.20021016114102.048802d0@uclink.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Oct 2002 12:43:11 -0700 To: Pekka Savola From: ken lindahl Subject: Re: New draft on embedding the RP address in IPv6 multicast address Cc: Bill Nickless , Leonard Giuliano , Brian Haberman , Marshall Eubanks , "Mike O'Connor" , , , X-Spam-Status: No, hits=-10.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] At 10:08 PM 10/16/2002 +0300, Pekka Savola wrote: >On Wed, 16 Oct 2002, ken lindahl wrote: >> At 09:31 PM 10/16/2002 +0300, Pekka Savola wrote: >> >Most switches work fine as is I believe, though flooding the multicasts >> >all over the segment.. yet where is SSM? I sure would like to have it.. >> >> that definition of working "fine" doesn't work for my campus. berkeley >> researchers are investigating the use of relatively high-bandwidth >> multicast (>10Mbps per stream) and i really don't want that flooding >> on departmental segments with one receiver. other Internet2-connected >> institutions are in similar positions, i think. > >Smaller segments can be used if that's really a problem (100/FD should >probably handle some 20-30Mbit/s of multicast per port without anyone >noticing anything but I haven't tested). umm. berkeley's campus network has approx 50,000 connected hosts on approx 500 IP subnets. your suggestion sounds just a little bit expensive. i'm guessing the campus doesn't want SSM _that_ badly. >Sure, IGMPv3, MLDv2 snooping would be nice but it seems hypocritical to >say this is the reason why SSM isn't being used.. IGMPv2 snooping is enabled now on large parts of campus. i don't think IGMPv3 will play nicely with that. disabling IGMP snooping so that SSM will work doesn't seem like a step forward. where's the hypocracy in that? ken From owner-v6ops@ops.ietf.org Wed Oct 16 19:53:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15522 for ; Wed, 16 Oct 2002 19:53:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 181y0w-000Mbn-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 16:55:46 -0700 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 181y0u-000Mbb-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 16:55:44 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 646994B22; Thu, 17 Oct 2002 08:55:42 +0900 (JST) To: ken lindahl Cc: mboned@network-services.uoregon.edu, v6ops@ops.ietf.org, nesg@es.net In-reply-to: lindahl's message of Wed, 16 Oct 2002 12:43:11 MST. <5.1.0.14.2.20021016122221.0488f8d8@uclink.berkeley.edu> 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: New draft on embedding the RP address in IPv6 multicast address From: itojun@iijlab.net Date: Thu, 17 Oct 2002 08:55:42 +0900 Message-Id: <20021016235542.646994B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>Sure, IGMPv3, MLDv2 snooping would be nice but it seems hypocritical to >>say this is the reason why SSM isn't being used.. >IGMPv2 snooping is enabled now on large parts of campus. i don't think >IGMPv3 will play nicely with that. disabling IGMP snooping so that SSM >will work doesn't seem like a step forward. where's the hypocracy in >that? doesn't host compatibility mode behavior (draft-ietf-idmr-igmp-v3-11.txt 7.2) help this situation? caveat: i'm no multicast expert. itojun From owner-v6ops@ops.ietf.org Thu Oct 17 00:46:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21209 for ; Thu, 17 Oct 2002 00:46:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1822XR-0004P6-00 for v6ops-data@psg.com; Wed, 16 Oct 2002 21:45:37 -0700 Received: from roam.psg.com ([147.28.4.2] ident=exim) by psg.com with esmtp (Exim 3.36 #2) id 1822XP-0004Ou-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 21:45:36 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 1822XQ-00014r-00 for v6ops@ops.ietf.org; Wed, 16 Oct 2002 21:45:36 -0700 Message-Id: <5.1.0.14.2.20021016201917.00ac7b98@uclink.berkeley.edu> In-Reply-To: <20021016235542.646994B22@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Oct 2002 20:59:29 -0700 To: itojun@iijlab.net From: ken lindahl Subject: Re: New draft on embedding the RP address in IPv6 multicast address Cc: mboned@network-services.uoregon.edu, v6ops@ops.ietf.org, nesg@es.net X-Spam-Status: No, hits=-7.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] hi, At 08:55 AM 10/17/2002 +0900, itojun@iijlab.net wrote: >>IGMPv2 snooping is enabled now on large parts of campus. i don't think >>IGMPv3 will play nicely with that. disabling IGMP snooping so that SSM >>will work doesn't seem like a step forward. where's the hypocracy in >>that? > > doesn't host compatibility mode behavior (draft-ietf-idmr-igmp-v3-11.txt > 7.2) help this situation? caveat: i'm no multicast expert. and i'm no IGMP expert. but i think the answer is no: it won't help. if the host(s) drop into v2 or v1 compatibility mode, they won't be able to send (S,G) membership messages on which SSM depends. that breaks SSM. the real problem is the IGMPv2-snooping switch. the switch has to intercept and process membership messages, that's an essential part of snooping. if the switch is only v1 and v2 aware, it cannot send the appropriate (S,G) membership message, so once again SSM is broken. if, as was implicitly suggested earlier, the switch is somehow smart enough (or dumb enough) to not recognize the v3 packets and simply forwards them, then snooping won't work. and that's where i entered this discussion: i consider snooping a requirement for my campus network. if someone who is an IGMP and multicast expert knows that i'm wrong, i'd be glad to hear it. ken From owner-v6ops@ops.ietf.org Thu Oct 17 08:25:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07683 for ; Thu, 17 Oct 2002 08:25:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1829jr-000Fl4-00 for v6ops-data@psg.com; Thu, 17 Oct 2002 05:26:55 -0700 Received: from ncsmtp02.ogw.rr.com ([24.93.67.83]) by psg.com with esmtp (Exim 3.36 #2) id 1829jo-000Fkr-00 for v6ops@ops.ietf.org; Thu, 17 Oct 2002 05:26:52 -0700 Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9HCQlv1012347; Thu, 17 Oct 2002 08:26:49 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 17 Oct 2002 08:26:42 -0400 Message-ID: <3DAEABE7.9090005@nc.rr.com> Date: Thu, 17 Oct 2002 08:24:07 -0400 From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ken lindahl CC: itojun@iijlab.net, mboned@network-services.uoregon.edu, v6ops@ops.ietf.org Subject: Re: New draft on embedding the RP address in IPv6 multicast address References: <5.1.0.14.2.20021016201917.00ac7b98@uclink.berkeley.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,SPAM_PHRASE_05_08,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ken lindahl wrote: > hi, > > At 08:55 AM 10/17/2002 +0900, itojun@iijlab.net wrote: > >>>IGMPv2 snooping is enabled now on large parts of campus. i don't think >>>IGMPv3 will play nicely with that. disabling IGMP snooping so that SSM >>>will work doesn't seem like a step forward. where's the hypocracy in >>>that? >> >> doesn't host compatibility mode behavior (draft-ietf-idmr-igmp-v3-11.txt >> 7.2) help this situation? caveat: i'm no multicast expert. > > > and i'm no IGMP expert. but i think the answer is no: it won't help. > if the host(s) drop into v2 or v1 compatibility mode, they won't be > able to send (S,G) membership messages on which SSM depends. that > breaks SSM. You are correct on this point. Once the switch drops into one of the compatibility modes, SSM is broke. This applies to v4 and v6. > > the real problem is the IGMPv2-snooping switch. the switch has to intercept > and process membership messages, that's an essential part of snooping. > if the switch is only v1 and v2 aware, it cannot send the appropriate > (S,G) membership message, so once again SSM is broken. Correct. > > if, as was implicitly suggested earlier, the switch is somehow smart > enough (or dumb enough) to not recognize the v3 packets and simply > forwards them, then snooping won't work. and that's where i entered > this discussion: i consider snooping a requirement for my campus > network. A snooping switch is supposed to flood IGMP/MLD messages that it does not recognize. Most do, some don't. > > if someone who is an IGMP and multicast expert knows that i'm wrong, > i'd be glad to hear it. You're not wrong. The key is convincing switch vendors to support IGMPv3 and MLDv2 snooping ASAP. Tell your vendors you want/need this functionality. And tell them that you want them to implement draft-ietf-magma-snoop-02.txt. Regards, Brian From owner-v6ops@ops.ietf.org Thu Oct 17 13:58:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19974 for ; Thu, 17 Oct 2002 13:58:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182EwV-0000YW-00 for v6ops-data@psg.com; Thu, 17 Oct 2002 11:00:19 -0700 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by psg.com with esmtp (Exim 3.36 #2) id 182EwS-0000Wf-00 for v6ops@ops.ietf.org; Thu, 17 Oct 2002 11:00:16 -0700 Received: from newtwinkle.mcs.anl.gov (vpnclient18108.mcs.anl.gov [140.221.18.108]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id MAA82222; Thu, 17 Oct 2002 12:59:20 -0500 Message-Id: <5.1.1.6.2.20021017124048.0275a730@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 17 Oct 2002 12:59:01 -0500 To: Brian Haberman From: Bill Nickless Subject: Re: New draft on embedding the RP address in IPv6 multicast address Cc: ken lindahl , itojun@iijlab.net, mboned@network-services.uoregon.edu, v6ops@ops.ietf.org In-Reply-To: <3DAEABE7.9090005@nc.rr.com> References: <5.1.0.14.2.20021016201917.00ac7b98@uclink.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_05_08 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 08:24 AM 10/17/2002 -0400, Brian Haberman wrote: >You're not wrong. The key is convincing switch vendors to support >IGMPv3 and MLDv2 snooping ASAP. Tell your vendors you want/need >this functionality. And tell them that you want them to implement >draft-ietf-magma-snoop-02.txt. What you just wrote is the orthodox view in the IP multicast community. When I read that, I hear the IP multicast community saying: "We developed this IP multicast thing before 802.11 switches existed. MAC-based receiver registration isn't needed on single-collision-domain 10Base5 Ethernet segments, so we didn't bother with that when we developed the IP multicast protocols like IGMP. "If the world is going to use 802.11 MAC-based switches, well then the 802.11 MAC-based switches had better emulate a single-collision-domain segment, interpreting IPv4/IGMP and IPv6/MLD datagrams as necessary. We're not going to change our way of doing things because we were here first." === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov From owner-v6ops@ops.ietf.org Thu Oct 17 14:25:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20797 for ; Thu, 17 Oct 2002 14:25:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182FMi-0001aN-00 for v6ops-data@psg.com; Thu, 17 Oct 2002 11:27:24 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 182FMg-0001aB-00 for v6ops@ops.ietf.org; Thu, 17 Oct 2002 11:27:22 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g9HIOb004903; Thu, 17 Oct 2002 14:24:37 -0400 (EDT) Message-Id: <200210171824.g9HIOb004903@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bill Nickless cc: Brian Haberman , ken lindahl , itojun@iijlab.net, mboned@network-services.uoregon.edu, v6ops@ops.ietf.org Subject: Re: New draft on embedding the RP address in IPv6 multicast address In-reply-to: (Your message of "Thu, 17 Oct 2002 12:59:01 CDT.") <5.1.1.6.2.20021017124048.0275a730@pop.mcs.anl.gov> Date: Thu, 17 Oct 2002 14:24:37 -0400 X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > "We're not going to change our way of doing things because we were here first." My view is that if a vendor sells products that have an Ethernet interface and claim to emulate an Ethernet, then they should actually emulate an Ethernet, at least by default. Otherwise protocols and code that expect the network to act like an Ethernet won't work. That includes propagating broadcast and multicast packets to all stations. If they can improve performance with clever snooping, fine, but that should always be optional. From owner-v6ops@ops.ietf.org Thu Oct 17 14:45:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22133 for ; Thu, 17 Oct 2002 14:45:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182Fea-0002Ij-00 for v6ops-data@psg.com; Thu, 17 Oct 2002 11:45:52 -0700 Received: from ncsmtp02.ogw.rr.com ([24.93.67.83]) by psg.com with esmtp (Exim 3.36 #2) id 182FeZ-0002IW-00 for v6ops@ops.ietf.org; Thu, 17 Oct 2002 11:45:51 -0700 Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9HIjjup007531; Thu, 17 Oct 2002 14:45:45 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 17 Oct 2002 14:45:43 -0400 Message-ID: <3DAF0614.2000101@nc.rr.com> Date: Thu, 17 Oct 2002 14:48:52 -0400 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Nickless CC: mboned@network-services.uoregon.edu, v6ops@ops.ietf.org Subject: Re: New draft on embedding the RP address in IPv6 multicast address References: <5.1.0.14.2.20021016201917.00ac7b98@uclink.berkeley.edu> <5.1.1.6.2.20021017124048.0275a730@pop.mcs.anl.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,SPAM_PHRASE_05_08,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill Nickless wrote: > At 08:24 AM 10/17/2002 -0400, Brian Haberman wrote: > >> You're not wrong. The key is convincing switch vendors to support >> IGMPv3 and MLDv2 snooping ASAP. Tell your vendors you want/need >> this functionality. And tell them that you want them to implement >> draft-ietf-magma-snoop-02.txt. > > > What you just wrote is the orthodox view in the IP multicast community. > > When I read that, I hear the IP multicast community saying: > > "We developed this IP multicast thing before 802.11 switches existed. > MAC-based receiver registration isn't needed on single-collision-domain > 10Base5 Ethernet segments, so we didn't bother with that when we > developed the IP multicast protocols like IGMP. > > "If the world is going to use 802.11 MAC-based switches, well then the > 802.11 MAC-based switches had better emulate a single-collision-domain > segment, interpreting IPv4/IGMP and IPv6/MLD datagrams as necessary. > We're not going to change our way of doing things because we were here > first." Sounds to me like you just described a MAC-layer group management protocol. Since the IETF generally stays at Layer 3 (Sub-IP excluded), it is out of our control. Perhaps you should petition the IEEE to develop this protocol or write a draft on how a layer 3 devices should advertise their interest in receiving packets on layer 2 addresses. Regards, Brian From owner-v6ops@ops.ietf.org Thu Oct 17 15:10:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23227 for ; Thu, 17 Oct 2002 15:10:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182G45-0003PU-00 for v6ops-data@psg.com; Thu, 17 Oct 2002 12:12:13 -0700 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by psg.com with esmtp (Exim 3.36 #2) id 182G43-0003Nc-00 for v6ops@ops.ietf.org; Thu, 17 Oct 2002 12:12:11 -0700 Received: from newtwinkle.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id OAA93292; Thu, 17 Oct 2002 14:11:31 -0500 Message-Id: <5.1.1.6.2.20021017134820.026850b8@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 17 Oct 2002 14:11:12 -0500 To: Brian Haberman , Greg Shepherd From: Bill Nickless Subject: Layer 2 MAC-layer group management [Was: New draft on embedding the RP address in IPv6 multicast address] Cc: Bill Nickless , mboned@network-services.uoregon.edu, v6ops@ops.ietf.org In-Reply-To: <3DAF0614.2000101@nc.rr.com> References: <5.1.0.14.2.20021016201917.00ac7b98@uclink.berkeley.edu> <5.1.1.6.2.20021017124048.0275a730@pop.mcs.anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 02:48 PM 10/17/2002 -0400, Brian Haberman wrote: >Sounds to me like you just described a MAC-layer group management >protocol. Since the IETF generally stays at Layer 3 (Sub-IP >excluded), it is out of our control. Exactly right. So why are the IETF working groups like MAGMA trying to specify Layer 2 switch multicast behavior? >Perhaps you should petition the IEEE to develop this protocol or >write a draft on how a layer 3 devices should advertise their >interest in receiving packets on layer 2 addresses. The IEEE 802.1p committee did develop a MAC-layer receiver interest protocol. See the work on GARP/GMRP. A good introduction to that work can be found in the second section of http://www.ieee802.org/1/mirror/8021/tobagi/garp-gmrp-timers.pdf . I did write a draft, which included a discussion of how layer 3 devices should advertise their interest in receiving packets on layer 2 addresses. See the first part of section 22 (page 10) of ftp://ftp.ietf.org/internet-drafts/draft-ietf-mboned-iesg-gap-analysis-00.txt It's written to first fix the truly unpatchable problem at multicast exchange points, where not all exchange point participants have peering agreements--leading to situations where datagrams might need to traverse the exchange point media more than once. That happens all the time for unicast datagrams, but can't happen with multicast datagrams. (Ibid, Section 20, page 8.) Then, once the technology is tested and proven in the limited cases, leverage it at the network edge for large-ish segments (like at Berkeley). === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov From owner-v6ops@ops.ietf.org Thu Oct 17 15:17:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23358 for ; Thu, 17 Oct 2002 15:17:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182GAd-0003gu-00 for v6ops-data@psg.com; Thu, 17 Oct 2002 12:18:59 -0700 Received: from ncsmtp03.ogw.rr.com ([24.93.67.84]) by psg.com with esmtp (Exim 3.36 #2) id 182GAb-0003gf-00 for v6ops@ops.ietf.org; Thu, 17 Oct 2002 12:18:57 -0700 Received: from mail7.nc.rr.com (fe7 [24.93.67.54]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9HJIdiZ018407; Thu, 17 Oct 2002 15:18:39 -0400 (EDT) Received: from nc.rr.com ([63.109.132.2]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 17 Oct 2002 15:18:34 -0400 Message-ID: <3DAF0DDD.3030509@nc.rr.com> Date: Thu, 17 Oct 2002 15:22:05 -0400 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Nickless CC: mboned@network-services.uoregon.edu, v6ops@ops.ietf.org Subject: Re: Layer 2 MAC-layer group management [Was: New draft on embedding the RP address in IPv6 multicast address] References: <5.1.0.14.2.20021016201917.00ac7b98@uclink.berkeley.edu> <5.1.1.6.2.20021017124048.0275a730@pop.mcs.anl.gov> <5.1.1.6.2.20021017134820.026850b8@pop.mcs.anl.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill Nickless wrote: > At 02:48 PM 10/17/2002 -0400, Brian Haberman wrote: > >> Sounds to me like you just described a MAC-layer group management >> protocol. Since the IETF generally stays at Layer 3 (Sub-IP >> excluded), it is out of our control. > > > Exactly right. So why are the IETF working groups like MAGMA trying to > specify Layer 2 switch multicast behavior? Slow down, Bill. MAGMA is not specifying how L-2 devices behave. The snooping draft is guidance to switch vendors who want to do IGMP/MLD snooping. It is meant as an Informational document. Nothing more. > >> Perhaps you should petition the IEEE to develop this protocol or >> write a draft on how a layer 3 devices should advertise their >> interest in receiving packets on layer 2 addresses. > > > The IEEE 802.1p committee did develop a MAC-layer receiver interest > protocol. See the work on GARP/GMRP. A good introduction to that work > can be found in the second section of > http://www.ieee802.org/1/mirror/8021/tobagi/garp-gmrp-timers.pdf . I will take a look at it. Have you (or Ken) pushed on your router vendors to support this in conjunction with the switch vendors? > > I did write a draft, which included a discussion of how layer 3 devices > should advertise their interest in receiving packets on layer 2 > addresses. See the first part of section 22 (page 10) of > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mboned-iesg-gap-analysis-00.txt Ah, another draft I have on my list to read, but haven't gotten to yet. I will take a look at this also. Brian From owner-v6ops@ops.ietf.org Thu Oct 17 16:34:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25183 for ; Thu, 17 Oct 2002 16:34:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182HM5-0006nI-00 for v6ops-data@psg.com; Thu, 17 Oct 2002 13:34:53 -0700 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by psg.com with esmtp (Exim 3.36 #2) id 182HM3-0006mU-00 for v6ops@ops.ietf.org; Thu, 17 Oct 2002 13:34:51 -0700 Received: from newtwinkle.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id PAA148366; Thu, 17 Oct 2002 15:34:11 -0500 Message-Id: <5.1.1.6.2.20021017150834.02622d20@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 17 Oct 2002 15:33:32 -0500 To: Brian Haberman From: Bill Nickless Subject: Re: Layer 2 MAC-layer group management [Was: New draft on embedding the RP address in IPv6 multicast address] Cc: Bill Nickless , mboned@network-services.uoregon.edu, v6ops@ops.ietf.org In-Reply-To: <3DAF0DDD.3030509@nc.rr.com> References: <5.1.0.14.2.20021016201917.00ac7b98@uclink.berkeley.edu> <5.1.1.6.2.20021017124048.0275a730@pop.mcs.anl.gov> <5.1.1.6.2.20021017134820.026850b8@pop.mcs.anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 03:22 PM 10/17/2002 -0400, Brian Haberman wrote: >Slow down, Bill. MAGMA is not specifying how L-2 devices behave. >The snooping draft is guidance to switch vendors who want to do >IGMP/MLD snooping. It is meant as an Informational document. >Nothing more. I stand corrected on my terminology. Let me try again. So why are the IETF working groups like MAGMA trying to guide Layer 2 switch multicast behavior? >Have you (or Ken) pushed on your router vendors to support this in >conjunction with the switch vendors? I can say that there's some adoption by switch vendors: Cisco Systems already supports GARP/GMRP. See, for example, http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_guide_chapter09186a00800eb758.html D-Link Systems claims future support for GARP/GMRP. http://www.dlink.com/products/switches/des6000/ As of 2000 (at least), Cabletron/Enterasys supported GARP/GMRP. http://www.cabletron.com/support/relnotes/rn_2806-06.html Also, other areas of the IETF are aware of GARP/GMRP. For example, RFC 2878 (Standards Track) refers to GMRP support for the PPP Bridging Control Protocol (BCP). http://www.ietf.org/rfc/rfc2878.txt === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov From owner-v6ops@ops.ietf.org Thu Oct 17 17:09:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26180 for ; Thu, 17 Oct 2002 17:09:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182Ht0-0008Ap-00 for v6ops-data@psg.com; Thu, 17 Oct 2002 14:08:54 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 182Hsz-0008AV-00 for v6ops@ops.ietf.org; Thu, 17 Oct 2002 14:08:53 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA22752; Thu, 17 Oct 2002 14:08:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9HL8Ha26000; Thu, 17 Oct 2002 14:08:17 -0700 X-mProtect: <200210172108> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmhLCZR; Thu, 17 Oct 2002 14:08:15 PDT Message-ID: <3DAF2742.50806@iprg.nokia.com> Date: Thu, 17 Oct 2002 14:10:26 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org Subject: New ISATAP draft submissions... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have just submitted the following two documents to the Internet Drafts repository. Both are available for immediate perusal at the URLs listed below: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) http://www.geocities.com/osprey67/isatap-05.txt Proposed Solutions for ISATAP Operational Issues http://www.geocities.com/osprey67/isatap_issues-00.txt Please feel free to comment either to the list or to the authors directly. Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Oct 17 17:36:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26757 for ; Thu, 17 Oct 2002 17:36:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182IKX-0009MJ-00 for v6ops-data@psg.com; Thu, 17 Oct 2002 14:37:21 -0700 Received: from ncsmtp02.ogw.rr.com ([24.93.67.83]) by psg.com with esmtp (Exim 3.36 #2) id 182IKT-0009Ly-00 for v6ops@ops.ietf.org; Thu, 17 Oct 2002 14:37:17 -0700 Received: from mail7.nc.rr.com (fe7 [24.93.67.54]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9HLbJup008873; Thu, 17 Oct 2002 17:37:19 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 17 Oct 2002 17:36:54 -0400 Message-ID: <3DAF2CEB.8010209@nc.rr.com> Date: Thu, 17 Oct 2002 17:34:35 -0400 From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Nickless CC: mboned@network-services.uoregon.edu, v6ops@ops.ietf.org Subject: Re: Layer 2 MAC-layer group management [Was: New draft on embedding the RP address in IPv6 multicast address] References: <5.1.0.14.2.20021016201917.00ac7b98@uclink.berkeley.edu> <5.1.1.6.2.20021017124048.0275a730@pop.mcs.anl.gov> <5.1.1.6.2.20021017134820.026850b8@pop.mcs.anl.gov> <5.1.1.6.2.20021017150834.02622d20@pop.mcs.anl.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill Nickless wrote: > > At 03:22 PM 10/17/2002 -0400, Brian Haberman wrote: > >> Slow down, Bill. MAGMA is not specifying how L-2 devices behave. >> The snooping draft is guidance to switch vendors who want to do >> IGMP/MLD snooping. It is meant as an Informational document. >> Nothing more. > > > I stand corrected on my terminology. Let me try again. > > So why are the IETF working groups like MAGMA trying to guide Layer 2 > switch multicast behavior? Um, because some switch vendors have asked for guidance. > >> Have you (or Ken) pushed on your router vendors to support this in >> conjunction with the switch vendors? > > > I can say that there's some adoption by switch vendors: > > Cisco Systems already supports GARP/GMRP. See, for example, > http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_guide_chapter09186a00800eb758.html > > > D-Link Systems claims future support for GARP/GMRP. > http://www.dlink.com/products/switches/des6000/ > > As of 2000 (at least), Cabletron/Enterasys supported GARP/GMRP. > http://www.cabletron.com/support/relnotes/rn_2806-06.html > > Also, other areas of the IETF are aware of GARP/GMRP. For example, RFC > 2878 (Standards Track) refers to GMRP support for the PPP Bridging > Control Protocol (BCP). http://www.ietf.org/rfc/rfc2878.txt Cool. That is a small step in the right direction. Brian From owner-v6ops@ops.ietf.org Thu Oct 17 17:56:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27376 for ; Thu, 17 Oct 2002 17:56:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182IdB-000AAE-00 for v6ops-data@psg.com; Thu, 17 Oct 2002 14:56:37 -0700 Received: from moebius2.space.net ([195.30.1.100] ident=qmailr) by psg.com with smtp (Exim 3.36 #2) id 182Id9-000A9s-00 for v6ops@ops.ietf.org; Thu, 17 Oct 2002 14:56:36 -0700 Received: (qmail 48253 invoked by uid 1007); 17 Oct 2002 21:56:30 -0000 Date: Thu, 17 Oct 2002 23:56:30 +0200 From: Gert Doering To: Brian Haberman Cc: Bill Nickless , mboned@network-services.uoregon.edu, v6ops@ops.ietf.org Subject: Re: New draft on embedding the RP address in IPv6 multicast address Message-ID: <20021017235630.U94537@Space.Net> References: <5.1.0.14.2.20021016201917.00ac7b98@uclink.berkeley.edu> <5.1.1.6.2.20021017124048.0275a730@pop.mcs.anl.gov> <3DAF0614.2000101@nc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DAF0614.2000101@nc.rr.com>; from bkhabs@nc.rr.com on Thu, Oct 17, 2002 at 02:48:52PM -0400 X-NCC-RegID: de.space X-Spam-Status: No, hits=-10.5 required=5.0 tests=CASHCASHCASH,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Thu, Oct 17, 2002 at 02:48:52PM -0400, Brian Haberman wrote: > Perhaps you should petition the IEEE to develop this protocol or > write a draft on how a layer 3 devices should advertise their > interest in receiving packets on layer 2 addresses. Which is something direly needed in "tightly meshed" ethernet switch environments - some sort of "layer 2 SPF" protocol telling each bridge where what MAC address is connected, what the shortest path to a given target is, and so on. It's doable, but unless the market is willing to pay $$$$ for such devices, I doubt any vendor will invest the necessary money. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48282 (47686) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Fri Oct 18 20:30:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13277 for ; Fri, 18 Oct 2002 20:30:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182hV5-0001sE-00 for v6ops-data@psg.com; Fri, 18 Oct 2002 17:29:55 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 182hV4-0001rs-00 for v6ops@ops.ietf.org; Fri, 18 Oct 2002 17:29:54 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA08437; Fri, 18 Oct 2002 17:29:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9J0TMH08541; Fri, 18 Oct 2002 17:29:22 -0700 X-mProtect: <200210190029> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHYPAy3; Fri, 18 Oct 2002 17:29:20 PDT Message-ID: <3DB0A7E9.8010307@iprg.nokia.com> Date: Fri, 18 Oct 2002 17:31:37 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org CC: "Fred L. Templin" Subject: Out-of-date IPR statement Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, The IPR statement found at: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt pertains to work I did while at SRI International. This statement is out of date, and it is my understanding that SRI International has sent an update to the IETF Executive Director offering free access to any technologies for the development of and compliance with IETF standards. I no longer work for SRI and cannot speak for them; please direct any inquiries on this subject to SRI International. Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Sat Oct 19 06:32:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29599 for ; Sat, 19 Oct 2002 06:32:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182quB-000HuF-00 for v6ops-data@psg.com; Sat, 19 Oct 2002 03:32:27 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 182qu9-000Ht6-00 for v6ops@ops.ietf.org; Sat, 19 Oct 2002 03:32:25 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id DAA27486; Sat, 19 Oct 2002 03:31:54 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9JAVqq23447; Sat, 19 Oct 2002 03:31:52 -0700 X-mProtect: <200210191031> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGwkPuR; Sat, 19 Oct 2002 03:31:49 PDT Message-ID: <3DB13520.8030105@iprg.nokia.com> Date: Sat, 19 Oct 2002 03:34:08 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org, ngtrans@sunroof.eng.sun.com CC: "Fred L. Templin" Subject: New draft - Router Affiliation Protocol for IPv6-over-(foo)-over-IPv4 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have sent the above-named personal draft to the IETF repository. It is available for immediate perusal at: http://www.geocities.com/osprey67/router_affiliation-00.txt The document has both operational and technical implications, thus I am posting to both lists. Abstract follows; please send comments. Fred ftemplin@iprg.nokia.com Abstract This document proposes a router affiliation protocol for IPv6- over-(foo)-over-IPv4 links, where (foo) is either an encapsulating layer (e.g., UDP) or a NULL layer. It is essentially a lightweight, link-layer mechanism for nodes and routers to establish security associations, discover and dynamically re-adjust maximum transmission units, and detect router failures. The protocol makes no attempt to ensure reliable message delivery; this function is performed by higher-layer protocols, e.g. TCP. From owner-v6ops@ops.ietf.org Sat Oct 19 07:36:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00567 for ; Sat, 19 Oct 2002 07:36:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182ruR-000J8g-00 for v6ops-data@psg.com; Sat, 19 Oct 2002 04:36:47 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 182ruN-000J8U-00 for v6ops@ops.ietf.org; Sat, 19 Oct 2002 04:36:43 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9JBaWR12160; Sat, 19 Oct 2002 14:36:33 +0300 Date: Sat, 19 Oct 2002 14:36:32 +0300 (EEST) From: Pekka Savola Reply-To: pekkas@netcore.fi To: 6bone@isi.edu cc: v6ops@ops.ietf.org Subject: A looking glass/traceroute page Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.8 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, Failing to find good pages on collected looking glass/traceroute pointers for v6, I did some quick browsing and collected some at: http://staff.csc.fi/psavola/lg.html Please send updates/modifications/etc directly. In particular, I failed to find the pages (if they exist) for the major v6 services providers.. HTH. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sat Oct 19 07:42:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00607 for ; Sat, 19 Oct 2002 07:42:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182s0F-000JGx-00 for v6ops-data@psg.com; Sat, 19 Oct 2002 04:42:47 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 182s0E-000JGl-00 for v6ops@ops.ietf.org; Sat, 19 Oct 2002 04:42:46 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9JBgbp12213; Sat, 19 Oct 2002 14:42:37 +0300 Date: Sat, 19 Oct 2002 14:42:36 +0300 (EEST) From: Pekka Savola To: 6bone@isi.edu cc: v6ops@ops.ietf.org Subject: Re: A looking glass/traceroute page In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-10.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 19 Oct 2002, Pekka Savola wrote: > Failing to find good pages on collected looking glass/traceroute pointers > for v6, I did some quick browsing and collected some at: > > http://staff.csc.fi/psavola/lg.html > > Please send updates/modifications/etc directly. In particular, I failed > to find the pages (if they exist) for the major v6 services providers.. To clarify, because the mailing list removed the reply-to I set, do not send any updates etc. on the list(s) but directly. Thanks. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sat Oct 19 10:18:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03129 for ; Sat, 19 Oct 2002 10:18:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182uRD-000Mcg-00 for v6ops-data@psg.com; Sat, 19 Oct 2002 07:18:47 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 182uRB-000McU-00 for v6ops@ops.ietf.org; Sat, 19 Oct 2002 07:18:46 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9JEIPw13113; Sat, 19 Oct 2002 17:18:25 +0300 Date: Sat, 19 Oct 2002 17:18:24 +0300 (EEST) From: Pekka Savola To: Nicolas DEFFAYET cc: 6bone@ISI.EDU, Subject: Re: [6bone] A looking glass/traceroute page In-Reply-To: <1035036803.610.1726.camel@wks1.fr.corp.ndsoftware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 19 Oct 2002, Nicolas DEFFAYET wrote: > On Sat, 2002-10-19 at 13:36, Pekka Savola wrote: > Hello, > > > Failing to find good pages on collected looking glass/traceroute pointers > > for v6, I did some quick browsing and collected some at: > > http://www.traceroute6.org/, but jv don't update this site... Didn't know of this.. > > http://staff.csc.fi/psavola/lg.html > > http://noc.ndsoftwarenet.com/docs/ipv6-tools-links.php Didn't know of this either... :-) If you add some sane groupings, I don't want to update my list anymore, as traceroute6 + you should be sufficient; no use having too many competing pages, best to have only one or two. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Oct 22 10:28:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18894 for ; Tue, 22 Oct 2002 10:28:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18401J-000GuZ-00 for v6ops-data@psg.com; Tue, 22 Oct 2002 07:28:33 -0700 Received: from smistad.uninett.no ([158.38.62.77]) by psg.com with esmtp (Exim 3.36 #2) id 18401H-000GuN-00 for v6ops@ops.ietf.org; Tue, 22 Oct 2002 07:28:31 -0700 Received: from localhost (localhost [127.0.0.1]) by smistad.uninett.no (Postfix) with ESMTP id 95481292C2; Tue, 22 Oct 2002 16:28:29 +0200 (CEST) Date: Tue, 22 Oct 2002 16:28:29 +0200 (CEST) Message-Id: <20021022.162829.128876470.he@uninett.no> To: lindahl@uclink.berkeley.edu Cc: pekkas@netcore.fi, nickless@mcs.anl.gov, lenny@juniper.net, bkhabs@nc.rr.com, tme@multicasttech.com, moc@es.net, mboned@network-services.uoregon.edu, v6ops@ops.ietf.org, nesg@es.net Subject: Re: New draft on embedding the RP address in IPv6 multicast address From: Havard Eidnes In-Reply-To: <5.1.0.14.2.20021016114102.048802d0@uclink.berkeley.edu> References: <5.1.1.6.2.20021016132340.02dd7b78@pop.mcs.anl.gov> <5.1.0.14.2.20021016114102.048802d0@uclink.berkeley.edu> X-Mailer: Mew version 1.95b124 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 X-Spam-Status: No, hits=-8.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA18894 > i agree with Bill's earlier comment: lack of IGMPv3 snooping in > current switches is a major obstacle to IPv4 SSM deployment, and > lack of MLD snooping will become an impediment to IPv6 SSM > deployment. I've said it before and I'll say it again: it strikes me as architecturally wrong to have traditionally cost-sensitive layer-2 switching devices having to implement interpretation of layer-3 protocol information in frames not explicitly directed at itself. It's IGMPv3 this day, and MLD for IPv6 the next day, and whatever we might dream up next after that. Multicast protocol development appears to still be in flux. This makes for complexity which leads to deployment problems because old non-field-upgradeable devices need to be replaced and one needs to wait for switch vendors to become aware of and then to delivering software upgrades (even if the devices are field- upgradeable). It would seem to me to be an architecturally better and longer-term more "stable" way to put the layer-3 smarts in the layer-3 devices, and to devise a protocol where the layer-3 devices could direct the layer-2 devices as appropriate, a'la Cisco's CGMP. Regards, - Håvard From owner-v6ops@ops.ietf.org Wed Oct 23 09:08:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18735 for ; Wed, 23 Oct 2002 09:08:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184LFX-000B3c-00 for v6ops-data@psg.com; Wed, 23 Oct 2002 06:08:39 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 184LFV-000B33-00 for v6ops@ops.ietf.org; Wed, 23 Oct 2002 06:08:37 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 184LFV-0004BD-00 for v6ops@ops.ietf.org; Wed, 23 Oct 2002 06:08:37 -0700 Message-Id: <200210231137.HAA14123@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-savola-v6ops-6to4-security-00.txt Date: Wed, 23 Oct 2002 07:37:07 -0400 X-Spam-Status: No, hits=0.0 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,RESENT_TO, SEARCH_ENGINE_PROMO,SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Security Considerations for 6to4 Author(s) : P. Savola Filename : draft-savola-v6ops-6to4-security-00.txt Pages : 20 Date : 2002-10-22 The IPv6 interim mechanism 6to4 [6TO4] uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes Relay Routers and Routers, which accept and decapsulate IPv4 traffic from anywhere. There aren't many constraints on the embedded IPv6 packets, or where IPv4 traffic will be automatically tunneled to. These could enable one to go around access controls, and more likely, being able to perform proxy Denial of Service attacks using Relays as reflectors. Anyone is also capable of spoofing traffic from non-6to4 addresses, as if it was coming from a relay, to a 6to4 router. This document discusses these issues in more detail and tries to suggest enhancements to alleviate the problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-v6ops-6to4-security-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-savola-v6ops-6to4-security-00.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-savola-v6ops-6to4-security-00.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: <2002-10-22143620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-savola-v6ops-6to4-security-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-savola-v6ops-6to4-security-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-22143620.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Oct 23 09:30:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23329 for ; Wed, 23 Oct 2002 09:30:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184LcL-000Bwc-00 for v6ops-data@psg.com; Wed, 23 Oct 2002 06:32:13 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 184Lbq-000Bve-00 for v6ops@ops.ietf.org; Wed, 23 Oct 2002 06:31:42 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9NDVe932583 for ; Wed, 23 Oct 2002 16:31:40 +0300 Date: Wed, 23 Oct 2002 16:31:40 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-00.txt In-Reply-To: <200210231137.HAA14123@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SEARCH_ENGINE_PROMO, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, As noted, here's a revision of my old draft. I've mainly added some textual enhancements and an initial take on "spoofing relay" issues; security considerations should also take remainder threats into account a bit better. Have fun.. On Wed, 23 Oct 2002 Internet-Drafts@ietf.org wrote: > Title : Security Considerations for 6to4 > Author(s) : P. Savola > Filename : draft-savola-v6ops-6to4-security-00.txt > Pages : 20 > Date : 2002-10-22 > > The IPv6 interim mechanism 6to4 [6TO4] uses automatic IPv6-over-IPv4 > tunneling to interconnect IPv6 networks. The architecture includes > Relay Routers and Routers, which accept and decapsulate IPv4 traffic > from anywhere. There aren't many constraints on the embedded IPv6 > packets, or where IPv4 traffic will be automatically tunneled to. > These could enable one to go around access controls, and more likely, > being able to perform proxy Denial of Service attacks using Relays as > reflectors. Anyone is also capable of spoofing traffic from non-6to4 > addresses, as if it was coming from a relay, to a 6to4 router. This > document discusses these issues in more detail and tries to suggest > enhancements to alleviate the problems. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-savola-v6ops-6to4-security-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > 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-savola-v6ops-6to4-security-00.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-savola-v6ops-6to4-security-00.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. > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Fri Oct 25 07:30:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20469 for ; Fri, 25 Oct 2002 07:30:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1852fk-0004rq-00 for v6ops-data@psg.com; Fri, 25 Oct 2002 04:30:36 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 1852fi-0004rd-00 for v6ops@ops.ietf.org; Fri, 25 Oct 2002 04:30:34 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19953; Fri, 25 Oct 2002 07:28:14 -0400 (EDT) Message-Id: <200210251128.HAA19953@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-savola-v6ops-6bone-mess-00.txt Date: Fri, 25 Oct 2002 07:28:14 -0400 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Moving from 6bone to IPv6 Internet Author(s) : P. Savola Filename : draft-savola-v6ops-6bone-mess-00.txt Pages : 13 Date : 2002-10-24 Currently, IPv6 Internet is, globally considered, inseparable from the 6bone network. The 6bone has been built as a tighly meshed tunneled topology. As the number of participants has grown, it has become an untangible mess, hindering the real deployment of IPv6 due to low quality of connections. This memo discusses the nature and the state of 6bone/IPv6 Internet, points out problems and outlines a few ways to start fixing them; also, some rough operational guidelines for different-sized organizations are presented. The most important issues are: not offering transit to everyone and real transit operators being needed to take a more active role. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-savola-v6ops-6bone-mess-00.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-savola-v6ops-6bone-mess-00.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: <2002-10-24142159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-savola-v6ops-6bone-mess-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-savola-v6ops-6bone-mess-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-24142159.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Oct 25 12:25:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00617 for ; Fri, 25 Oct 2002 12:25:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1857Hy-000CP7-00 for v6ops-data@psg.com; Fri, 25 Oct 2002 09:26:22 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 1857Hx-000CNq-00 for v6ops@ops.ietf.org; Fri, 25 Oct 2002 09:26:21 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 6F25237A1C4 for ; Fri, 25 Oct 2002 16:26:19 +0000 (GMT) From: Paul Vixie To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6bone-mess-00.txt In-Reply-To: Message from Internet-Drafts@ietf.org of "Fri, 25 Oct 2002 07:28:14 -0400." <200210251128.HAA19953@ietf.org> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 25 Oct 2002 16:26:19 +0000 Message-Id: <20021025162619.6F25237A1C4@as.vix.com> X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk re: > http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-00.txt i suggest adding a reference to http://www.isc.org/tn/isc-tn-2002-1.txt, which addresses some of the dns-related issues in migrating away from 6bone. From owner-v6ops@ops.ietf.org Fri Oct 25 12:43:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01316 for ; Fri, 25 Oct 2002 12:43:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1857a7-000F52-00 for v6ops-data@psg.com; Fri, 25 Oct 2002 09:45:07 -0700 Received: from ny-ppp012.iij-us.net ([216.98.99.12] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #2) id 1857a4-000F4c-00 for v6ops@ops.ietf.org; Fri, 25 Oct 2002 09:45:05 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 44DAF7BB; Sat, 26 Oct 2002 01:44:17 +0900 (JST) To: Paul Vixie Cc: v6ops@ops.ietf.org In-reply-to: paul's message of Fri, 25 Oct 2002 16:26:19 GMT. <20021025162619.6F25237A1C4@as.vix.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: I-D ACTION:draft-savola-v6ops-6bone-mess-00.txt From: Jun-ichiro itojun Hagino Date: Sat, 26 Oct 2002 01:44:17 +0900 Message-Id: <20021025164417.44DAF7BB@starfruit.itojun.org> X-Spam-Status: No, hits=-5.4 required=5.0 tests=GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >re: >> http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-00.txt >i suggest adding a reference to http://www.isc.org/tn/isc-tn-2002-1.txt, >which addresses some of the dns-related issues in migrating away from 6bone. two comments - 1. DNAME is not widely implemented in resolvers in the wild. therefore not many will be able to resolve "blah.int" with this scheme. 2. if you drop $ORIGIN from the zone file, you will be okay with the following configuration (which is simpler IMHO). itojun f.2.0.0.8.0.e.f.f.f.7.4.3.0.2.0.d.0.0.0 PTR pa-blue.fwpaa.isc.org. 8.f.b.4.0.0.e.f.f.f.7.4.3.0.2.0.d.0.0.0 PTR pa-blue.fwpab.isc.org. e.7.0.b.3.c.e.f.f.f.b.2.0.0.a.0.d.0.0.0 PTR isrv4.isc.org. a.7.7.e.7.0.e.f.f.f.8.f.0.0.2.0.d.0.0.0 PTR phred.isc.org. 2.3. BIND9's configuration file would include two "zone" declarations: zone "8.f.4.0.1.0.0.2.ip6.arpa" { // ARIN ISC6-1 type master; file "pri/2001:04F8:"; }; zone "8.f.4.0.1.0.0.2.ip6.int" { // ARIN ISC6-1 (.int) type master; file "pri/2001:04F8:"; }; From owner-v6ops@ops.ietf.org Fri Oct 25 12:43:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01334 for ; Fri, 25 Oct 2002 12:43:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1857Za-000F30-00 for v6ops-data@psg.com; Fri, 25 Oct 2002 09:44:34 -0700 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 1857ZX-000F2i-00 for v6ops@ops.ietf.org; Fri, 25 Oct 2002 09:44:32 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g9PGiNW28384; Fri, 25 Oct 2002 19:44:23 +0300 Date: Fri, 25 Oct 2002 19:44:23 +0300 (EEST) From: Pekka Savola To: Paul Vixie cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6bone-mess-00.txt In-Reply-To: <20021025162619.6F25237A1C4@as.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 25 Oct 2002, Paul Vixie wrote: > re: > > > http://www.ietf.org/internet-drafts/draft-savola-v6ops-6bone-mess-00.txt > > i suggest adding a reference to http://www.isc.org/tn/isc-tn-2002-1.txt, > which addresses some of the dns-related issues in migrating away from 6bone. The draft is focused on issues in routing (God knows, there are enough problems there! :-) -- I'll consider whether this needs to be clarified or the scope expanded so issue with ip6.int/ip6.arpa can be dealt properly. Resolvers I'm using query ip6.arpa only so I'm constantly being bitten by this .. I really hope the political reasons were good enough... -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Fri Oct 25 12:45:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01499 for ; Fri, 25 Oct 2002 12:45:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1857cy-000FVn-00 for v6ops-data@psg.com; Fri, 25 Oct 2002 09:48:04 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 1857cw-000FVb-00 for v6ops@ops.ietf.org; Fri, 25 Oct 2002 09:48:02 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 7302237A1C4 for ; Fri, 25 Oct 2002 16:48:02 +0000 (GMT) From: Paul Vixie To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6bone-mess-00.txt In-Reply-To: Message from Jun-ichiro itojun Hagino of "Sat, 26 Oct 2002 01:44:17 +0900." <20021025164417.44DAF7BB@starfruit.itojun.org> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 25 Oct 2002 16:48:02 +0000 Message-Id: <20021025164802.7302237A1C4@as.vix.com> X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >i suggest adding a reference to http://www.isc.org/tn/isc-tn-2002-1.txt, > >which addresses some of the dns-related issues in migrating away from 6bone. > > two comments - > 1. DNAME is not widely implemented in resolvers in the wild. therefore > not many will be able to resolve "blah.int" with this scheme. the dname logic executes in the authority servers, by synthesizing cnames. so as long as the master and all slaves understand dname, this proposal works. From owner-v6ops@ops.ietf.org Fri Oct 25 12:53:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01910 for ; Fri, 25 Oct 2002 12:53:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1857kc-000GZP-00 for v6ops-data@psg.com; Fri, 25 Oct 2002 09:55:58 -0700 Received: from ny-ppp012.iij-us.net ([216.98.99.12] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #2) id 1857kZ-000GZB-00 for v6ops@ops.ietf.org; Fri, 25 Oct 2002 09:55:56 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E5EB47BB; Sat, 26 Oct 2002 01:55:10 +0900 (JST) To: Paul Vixie Cc: v6ops@ops.ietf.org In-reply-to: paul's message of Fri, 25 Oct 2002 16:48:02 GMT. <20021025164802.7302237A1C4@as.vix.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: I-D ACTION:draft-savola-v6ops-6bone-mess-00.txt From: Jun-ichiro itojun Hagino Date: Sat, 26 Oct 2002 01:55:10 +0900 Message-Id: <20021025165510.E5EB47BB@starfruit.itojun.org> X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> >i suggest adding a reference to http://www.isc.org/tn/isc-tn-2002-1.txt, >> >which addresses some of the dns-related issues in migrating away from 6bone. >> two comments - >> 1. DNAME is not widely implemented in resolvers in the wild. therefore >> not many will be able to resolve "blah.int" with this scheme. >the dname logic executes in the authority servers, by synthesizing cnames. >so as long as the master and all slaves understand dname, this proposal works. then - how do you sign a zone with DNAME? synthesize = you can't sign. - why DNAME resolution has to be kept in BIND8 resolver? (i have sent a diff to remove DNAME processing in BIND8 resolver distributed in BIND9 package, and i got "don't remove DNAME" comment) itojun From owner-v6ops@ops.ietf.org Fri Oct 25 13:04:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02335 for ; Fri, 25 Oct 2002 13:04:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1857uo-000Hzp-00 for v6ops-data@psg.com; Fri, 25 Oct 2002 10:06:30 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 1857um-000Hyy-00 for v6ops@ops.ietf.org; Fri, 25 Oct 2002 10:06:28 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA25914; Fri, 25 Oct 2002 10:05:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9PH5vZ05877; Fri, 25 Oct 2002 10:05:57 -0700 X-mProtect: <200210251705> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdm7HbvZ; Fri, 25 Oct 2002 10:05:55 PDT Message-ID: <3DB97AA2.9090606@iprg.nokia.com> Date: Fri, 25 Oct 2002 10:08:50 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org, ngtrans@sunroof.eng.sun.com CC: "Fred L. Templin" Subject: Re: New draft - Router Affiliation Protocol for IPv6-over-(foo)-over-IPv4 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit FYI, An update to this document will be submitted ahead of the draft deadline. Fred Templin ftemplin@iprg.nokia.com Fred L. Templin wrote: > Hello, > > I have sent the above-named personal draft to the IETF repository. > It is available for immediate perusal at: > > http://www.geocities.com/osprey67/router_affiliation-00.txt > > The document has both operational and technical implications, > thus I am posting to both lists. Abstract follows; please send > comments. > > Fred > ftemplin@iprg.nokia.com > > Abstract > > This document proposes a router affiliation protocol for IPv6- > over-(foo)-over-IPv4 links, where (foo) is either an encapsulating > layer (e.g., UDP) or a NULL layer. It is essentially a lightweight, > link-layer mechanism for nodes and routers to establish security > associations, discover and dynamically re-adjust maximum transmission > units, and detect router failures. The protocol makes no attempt to > ensure reliable message delivery; this function is performed by > higher-layer protocols, e.g. TCP. From owner-v6ops@ops.ietf.org Fri Oct 25 13:09:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02573 for ; Fri, 25 Oct 2002 13:09:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18580B-000Iw5-00 for v6ops-data@psg.com; Fri, 25 Oct 2002 10:12:03 -0700 Received: from ny-ppp012.iij-us.net ([216.98.99.12] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #2) id 185808-000Ivq-00 for v6ops@ops.ietf.org; Fri, 25 Oct 2002 10:12:01 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id C6A917BB; Sat, 26 Oct 2002 02:11:15 +0900 (JST) To: Paul Vixie , v6ops@ops.ietf.org In-reply-to: itojun's message of Sat, 26 Oct 2002 01:55:10 +0900. <20021025165510.E5EB47BB@starfruit.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: I-D ACTION:draft-savola-v6ops-6bone-mess-00.txt From: Jun-ichiro itojun Hagino Date: Sat, 26 Oct 2002 02:11:15 +0900 Message-Id: <20021025171115.C6A917BB@starfruit.itojun.org> X-Spam-Status: No, hits=-6.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>> >i suggest adding a reference to http://www.isc.org/tn/isc-tn-2002-1.txt, >>> >which addresses some of the dns-related issues in migrating away from 6bone. >>> two comments - >>> 1. DNAME is not widely implemented in resolvers in the wild. therefore >>> not many will be able to resolve "blah.int" with this scheme. >>the dname logic executes in the authority servers, by synthesizing cnames. >>so as long as the master and all slaves understand dname, this proposal works. > > then > - how do you sign a zone with DNAME? synthesize = you can't sign. > - why DNAME resolution has to be kept in BIND8 resolver? > (i have sent a diff to remove DNAME processing in BIND8 resolver > distributed in BIND9 package, and i got "don't remove DNAME" comment) and - RFC2672 doesn't say that DNAME is a pseudo RR type (which does not appear on wire), so i assume it is a real RR tyep (which appears on the wire). this is opposite from your statement above. itojun From owner-v6ops@ops.ietf.org Fri Oct 25 15:46:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08519 for ; Fri, 25 Oct 2002 15:46:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 185AR9-000Fai-00 for v6ops-data@psg.com; Fri, 25 Oct 2002 12:48:03 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #2) id 185AQz-000FaQ-00 for v6ops@ops.ietf.org; Fri, 25 Oct 2002 12:47:53 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 3832E37A1C4 for ; Fri, 25 Oct 2002 19:47:53 +0000 (GMT) From: Paul Vixie To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6bone-mess-00.txt In-Reply-To: Message from Jun-ichiro itojun Hagino of "Sat, 26 Oct 2002 02:11:15 +0900." <20021025171115.C6A917BB@starfruit.itojun.org> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 25 Oct 2002 19:47:53 +0000 Message-Id: <20021025194753.3832E37A1C4@as.vix.com> X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk this isn't specifically ipv6 related, but it has to do with DNAME, which is referred to in ISC-TN-2002-1 that was URL'd here earlier, so: (my thanks to nominum for help providing these answers) > - how do you sign a zone with DNAME? synthesize = you can't sign. The synthesized CNAME won't be signed, but the DNAME will. This just means that anything capable of DNSSEC validation must look at the DNAME, not the CNAME. That's exactly what BIND 9's internal resolver does. > - why DNAME resolution has to be kept in BIND8 resolver? > (i have sent a diff to remove DNAME processing in BIND8 resolver > distributed in BIND9 package, and i got "don't remove DNAME" comment) it should have been removed when we tore dnssec support out of bind8. my apologies for rejecting your patch earlier. please resend :-). > - RFC2672 doesn't say that DNAME is a pseudo RR type (which does not > appear on wire), so i assume it is a real RR tyep (which appears > on the wire). this is opposite from your statement above. It is a real RR type. Any server that doesn't understand DNAMEs should treat it no differently than any other unknown RR types, and things will still work (because of the synthesized CNAMEs). From owner-v6ops@ops.ietf.org Wed Oct 30 13:52:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03664 for ; Wed, 30 Oct 2002 13:52:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186xxl-000I2R-00 for v6ops-data@psg.com; Wed, 30 Oct 2002 10:53:09 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 186xxj-000I1G-00 for v6ops@ops.ietf.org; Wed, 30 Oct 2002 10:53:07 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA03047; Wed, 30 Oct 2002 10:52:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g9UIqaC11834; Wed, 30 Oct 2002 10:52:36 -0800 X-mProtect: <200210301852> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeYvDHa; Wed, 30 Oct 2002 10:52:34 PST Message-ID: <3DC02B3F.3090508@iprg.nokia.com> Date: Wed, 30 Oct 2002 10:55:59 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org, ngtrans@sunroof.eng.sun.com CC: "Fred L. Templin" Subject: New draft - NeighborAffiliation Protocol for IPv6-over-(foo)-over-IPv4 (version -01) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have sent the above-named personal draft to the IETF repository. It is available for immediate perusal at: http://www.geocities.com/osprey67/neighbor_affiliation-01.txt The document obsoletes both a "-00" draft version of the same posted on 10/25/02 and an earlier document posted on 10/19/02 named "router_affiliation-00.txt". You've all done a great job of withholding your comments up to now, but this will be the last update I send prior to IETF 55; please send any comments you may have based on this version. Abstract appears below: Fred ftemplin@iprg.nokia.com Abstract This document proposes extensions to IPv6 Neighbor Discovery for IPv6-over-(foo)-over-IPv4 links, where (foo) is either an encapsulating layer (e.g., UDP) or a NULL layer. It is essentially a lightweight, link-layer mechanism for neighbors to establish security associations, discover and dynamically re-adjust maximum receive unit (MRU) estimates, and perform unreachability detection. The protocol makes no attempt to ensure reliable message delivery; this function is performed by higher-layer protocols, e.g. TCP. From owner-v6ops@ops.ietf.org Wed Oct 30 16:38:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13849 for ; Wed, 30 Oct 2002 16:38:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1870Yb-0002BQ-00 for v6ops-data@psg.com; Wed, 30 Oct 2002 13:39:21 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 1870YX-00029K-00 for v6ops@ops.ietf.org; Wed, 30 Oct 2002 13:39:17 -0800 Received: from kenawang.windriver.com ([147.11.233.12]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA26732 for ; Wed, 30 Oct 2002 13:38:40 -0800 (PST) Message-Id: <5.1.0.14.2.20021030145821.07b03260@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Oct 2002 15:08:41 -0500 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Agenda Items for Atlanta Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.7 required=5.0 tests=SPAM_PHRASE_02_03 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, We are working on putting together an agenda for the v6ops meeting in Atlanta. Please let us know if there are items that you would like us to include in the agenda. Your requests should include: - Proposed Topic - Presenter's name - Length of time requested - URL(s) for related draft or reference(s) Thanks, Margaret & Itojun v6ops chairs From owner-v6ops@ops.ietf.org Thu Oct 31 06:16:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13280 for ; Thu, 31 Oct 2002 06:16:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187DJo-000LtE-00 for v6ops-data@psg.com; Thu, 31 Oct 2002 03:16:56 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 187DJm-000Lt2-00 for v6ops@ops.ietf.org; Thu, 31 Oct 2002 03:16:54 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13075; Thu, 31 Oct 2002 06:14:29 -0500 (EST) Message-Id: <200210311114.GAA13075@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shin-v6ops-application-transition-00.txt Date: Thu, 31 Oct 2002 06:14:29 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Application Aspects of IPv6 Transition Author(s) : M. Shin et al. Filename : draft-shin-v6ops-application-transition-00.txt Pages : 15 Date : 2002-10-30 The document specifies application aspects of IPv6 transition. As IPv6 is deployed, the application developers and the administrators will face several problems. This draft clarifies the problems occurring in transition period between IPv4 applications and IPv6 applications. It also proposes guidelines that help application developers understand how to develop IP version-independent applications during the transition period. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transition-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-shin-v6ops-application-transition-00.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-shin-v6ops-application-transition-00.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: <2002-10-30162412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shin-v6ops-application-transition-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shin-v6ops-application-transition-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-30162412.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Oct 31 13:41:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07220 for ; Thu, 31 Oct 2002 13:41:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187KHE-000Lsq-00 for v6ops-data@psg.com; Thu, 31 Oct 2002 10:42:44 -0800 Received: from howler.tri.sbc.com ([205.173.58.4]) by psg.com with esmtp (Exim 3.36 #2) id 187KHC-000LsZ-00 for v6ops@ops.ietf.org; Thu, 31 Oct 2002 10:42:42 -0800 Received: from sbctri.tri.sbc.com (mayhem-web-dmz.tri.sbc.com [144.60.9.137]) by howler.tri.sbc.com (8.12.5/8.12.5) with ESMTP id g9VIlQ8W017536 for ; Thu, 31 Oct 2002 12:47:27 -0600 (CST) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g9VIexk27872 for ; Thu, 31 Oct 2002 12:40:59 -0600 (CST) Received: by trimail2 with Internet Mail Service (5.5.2653.19) id <40VRJJ9H>; Thu, 31 Oct 2002 12:42:37 -0600 Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D63226DF@trimail2> From: "Chen, Weijing" To: "'v6ops@ops.ietf.org'" Subject: IPv6, broadband access, VPN Date: Thu, 31 Oct 2002 12:42:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2810D.4265F010" X-Spam-Status: No, hits=-1.8 required=5.0 tests=BIG_FONT,EXCHANGE_SERVER,HTML_50_70,HTML_FONT_COLOR_BLUE, HTML_FONT_COLOR_NAME,HTML_FONT_FACE_ODD,MAILTO_LINK, MIME_NULL_BLOCK,SPAM_PHRASE_03_05 version=2.41 Sender: owner-v6ops@ops.ietf.org 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_01C2810D.4265F010 Content-Type: text/plain All, We have been studying the benefits that IPv6 could bring to a large carrier like SBC, in addition to large IP address, plug-play host connection. You might be interested in an Internet-Draft that we recently submitted as http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt . In it, we make a case for why companies like ours should be turning towards IPv6, and also suggest some new capabilities for IPv6, such as broadband Internet access, L3VPN, L2VPN. Although we have focused on IPv6 service in this draft, we would welcome the expansion of it to the same IPv4 service offering through IPv6 core network. We would like to hear comments and interests from all the parities. Regards, -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 wchen@tri.sbc.com ------_=_NextPart_001_01C2810D.4265F010 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

All,

 

We have been studying the benefits = that IPv6 could bring to a large carrier like SBC, in addition to large IP = address, plug-play host connection.  You might be interested in an = Internet-Draft that we recently submitted as http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt.  In it, we make a = case for why companies like ours should be turning towards IPv6, and also = suggest some new capabilities for IPv6, such as broadband Internet access, L3VPN, = L2VPN.  Although we have focused on IPv6 service in this draft, we would = welcome the expansion of it to the same IPv4 service offering through IPv6 core = network.

 

We would like to hear comments and interests from = all the parities.

 

Regards,

--

Weijing Chen

SBC Technology Resources

9505 Arboretum Blvd.

Austin, TX 78759

512 372 5710

wchen@tri.sbc.com=

------_=_NextPart_001_01C2810D.4265F010--