From crsnyder@earthlink.net Wed Feb 01 11:35:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Kwh-0005EF-Da for v6ops-archive@megatron.ietf.org; Wed, 01 Feb 2006 11:35:05 -0500 Received: from cliente-38979.iberbanda.es (cliente-38979.iberbanda.es [83.230.216.65] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12872 for ; Wed, 1 Feb 2006 11:33:19 -0500 (EST) Received: from horology.chloroplast.com (ed [215.140.60.159]) by frontage.com (sparse) with flake id 835153633227607 for ; Wed, 01 Feb 2006 09:06:38 -0600 Date: Wed, 01 Feb 2006 05:31:06 -0600 From: Chuck Patterson X-Mailer: systemization 98.636.03630361 Reply-To: Tania Cortes X-Priority: 3 (Normal) Message-ID: <86502850260785978081@earthlink.net> To: v6ops-archive@ietf.org Subject: Amazing, Eula In-Reply-To: <87088623009704202277290@earthlink.net> References: <28541360276835504461@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------=71957589504" Content-Transfer-Encoding: base64 --------=71957589504 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package	Quantity	Price in your local drugstore*	Our price	Learn More Now
10 softtabs	20 doses	~~$149.95~~	$119.95
20 softtabs	40 doses	~~$299.95~~	$159.95
30 softtabs	60 doses	~~$849.95~~	$169.95
60 softtabs	120 doses	~~$1 999.95~~	$259.95
90 softtabs	180 doses	~~$3 099.95~~	$299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

It is the privilege of those who fear love to murder those who do not fear it!
There is not a fiercer hell than the failure in a great object.Happiness grows at our own firesides, and is not to be picked in stranger's gardens. --------=71957589504 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Nathaniel-> http://wwpfpe.your4you.info/?23829381 --------=71957589504-- From owner-v6ops@ops.ietf.org Fri Feb 03 22:17:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5DvV-0003jR-8L for v6ops-archive@megatron.ietf.org; Fri, 03 Feb 2006 22:17:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26706 for ; Fri, 3 Feb 2006 22:15:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5Drr-000299-TL for v6ops-data@psg.com; Sat, 04 Feb 2006 03:13:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5Drr-00028u-3H for v6ops@ops.ietf.org; Sat, 04 Feb 2006 03:13:43 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 3 Feb 2006 19:13:42 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 19:13:42 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 19:13:42 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 19:13:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Teredo spec has been published! Date: Fri, 3 Feb 2006 19:13:41 -0800 Message-ID: In-Reply-To: <761163F2-1FA3-46A5-8AB2-A25C4FB6F8F4@cisco.com> Thread-Topic: Teredo spec has been published! thread-index: AcX/3u1kIwWOGsssRJO2rn2bSlJDkQpWbqag From: "Christian Huitema" To: X-OriginalArrivalTime: 04 Feb 2006 03:13:42.0376 (UTC) FILETIME=[006E9680:01C62939] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable The Teredo spec has been published as an individual submission: RFC4380=20 Teredo: Tunneling IPv6 over UDP through Network Address=20 Translations (NATs) =20 C. Huitema February 2006 ASCII =20 PROPOSED STANDARD Thanks to the many NGTRANS and V6OPS working group members who reviewed the spec! -- Christian Huitema From owner-v6ops@ops.ietf.org Sat Feb 04 22:00:42 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5a8j-0000oa-PI for v6ops-archive@megatron.ietf.org; Sat, 04 Feb 2006 22:00:42 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29039 for ; Sat, 4 Feb 2006 21:58:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5a5B-000GTu-Lu for v6ops-data@psg.com; Sun, 05 Feb 2006 02:56:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,HTML_40_50, HTML_MESSAGE,SPF_PASS autolearn=ham version=3.1.0 Received: from [66.249.82.203] (helo=xproxy.gmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5a5A-000GTi-QO for v6ops@ops.ietf.org; Sun, 05 Feb 2006 02:56:56 +0000 Received: by xproxy.gmail.com with SMTP id s10so757276wxc for ; Sat, 04 Feb 2006 18:56:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=jB8A7TxyxoGIA8a323jpTfIbZia5iIs8BsuqDEjHGuHrLUt1tCXFmBCY509YSMTUlkw/extv6sY7/IgHmE0DXYF3XJurC4vVars8MvbzodfwFp7khdyQKjRzF2ygU7wE55b2F9krl+sRnw612s/uBDW0HCSmmQkw8jqkaPb/K0Q= Received: by 10.70.44.13 with SMTP id r13mr4057836wxr; Sat, 04 Feb 2006 18:56:54 -0800 (PST) Received: by 10.70.39.20 with HTTP; Sat, 4 Feb 2006 18:56:54 -0800 (PST) Message-ID: Date: Sun, 5 Feb 2006 10:56:54 +0800 From: haofeng Zhang To: Christian Huitema Subject: Re: Teredo spec has been published! Cc: v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18218_11557058.1139108214727" References: <761163F2-1FA3-46A5-8AB2-A25C4FB6F8F4@cisco.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk ------=_Part_18218_11557058.1139108214727 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Great News. I am expecting the next version of Windows will support Teredo service proposed by RFC4380. Also, I think it will be more flexible if a Teredo Client accepts any reasonable global IPv6 prefix, not only 2001:0000::/32 defined in the sepcification. 2006/2/4, Christian Huitema : > > The Teredo spec has been published as an individual submission: > > RFC4380 > Teredo: Tunneling IPv6 over UDP through Network Address > Translations (NATs) > C. Huitema February 2006 ASCII > PROPOSED STANDARD > > Thanks to the many NGTRANS and V6OPS working group members who reviewed > the spec! > > -- Christian Huitema > > -- Best regards, Zhang haofeng ------=_Part_18218_11557058.1139108214727 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Great News.

I am expecting the next version of Windows will support Teredo service= proposed by RFC4380.

Also, I think it will be more flexible if a Teredo Client ac= cepts any reasonable global IPv6 prefix, not only 2001:0000::/32 defin= ed in the sepcification.

2006/2/4, Christian Huitema <huitema@windows.microsoft.com>= ;: =20

The Teredo spec has been publish= ed as an individual submission:

      = RFC4380
       Teredo: Tunneling IPv6 ove= r UDP through Network Address=20
       Translations (NATs)
  = ;     C. Huitema February 2006 ASCII
  &nb= sp;    PROPOSED STANDARD

Thanks to the many NGTRANS a= nd V6OPS working group members who reviewed
the spec!

-- Christia= n Huitema

--
Best regards,
Zh= ang haofeng=20 ------=_Part_18218_11557058.1139108214727-- From owner-v6ops@ops.ietf.org Sun Feb 05 07:05:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5idk-0007CA-Dd for v6ops-archive@megatron.ietf.org; Sun, 05 Feb 2006 07:05:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02017 for ; Sun, 5 Feb 2006 07:03:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5iah-000F0r-3G for v6ops-data@psg.com; Sun, 05 Feb 2006 12:02:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.27.42.28] (helo=smtp2-g19.free.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5iag-000Ezo-4O for v6ops@ops.ietf.org; Sun, 05 Feb 2006 12:02:02 +0000 Received: from [192.168.0.14] (ver78-2-82-241-89-240.fbx.proxad.net [82.241.89.240]) by smtp2-g19.free.fr (Postfix) with ESMTP id 276DE6CD5A; Sun, 5 Feb 2006 13:02:00 +0100 (CET) Subject: Re: Teredo spec has been published! From: Vincent Jardin To: haofeng Zhang Cc: Christian Huitema , v6ops@ops.ietf.org In-Reply-To: References: <761163F2-1FA3-46A5-8AB2-A25C4FB6F8F4@cisco.com> Content-Type: text/plain; charset=utf-8 Organization: http://www.6wind.com/ Date: Sun, 05 Feb 2006 13:01:58 +0100 Message-Id: <1139140919.19913.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA02017 Le dimanche 05 f=C3=A9vrier 2006 =C3=A0 10:56 +0800, haofeng Zhang a =C3=A9= crit : > Great News. > I am expecting the next version of Windows will support Teredo service > proposed by RFC4380. > Also, I think it will be more flexible if a Teredo Client accepts any > reasonable global IPv6 prefix, not only 2001:0000::/32 defined in the > sepcification. =20 Yes, it would be very usefull with we can configure the Teredo prefix on the next update of Windows, instead of having a hard-coded 2001:0000::/32. Regards, Vincent >=20 > =20 > 2006/2/4, Christian Huitema :=20 > The Teredo spec has been published as an individual > submission: > =20 > RFC4380 > Teredo: Tunneling IPv6 over UDP through Network > Address=20 > Translations (NATs) > C. Huitema February 2006 ASCII > PROPOSED STANDARD > =20 > Thanks to the many NGTRANS and V6OPS working group members who > reviewed > the spec! > =20 > -- Christian Huitema > =20 >=20 >=20 >=20 > --=20 > Best regards, > Zhang haofeng=20 From owner-v6ops@ops.ietf.org Sun Feb 05 07:15:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5inN-0001nS-Of for v6ops-archive@megatron.ietf.org; Sun, 05 Feb 2006 07:15:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02781 for ; Sun, 5 Feb 2006 07:13:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5imj-000Fdo-0g for v6ops-data@psg.com; Sun, 05 Feb 2006 12:14:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5imh-000FdY-R6 for v6ops@ops.ietf.org; Sun, 05 Feb 2006 12:14:28 +0000 Received: from [10.10.10.101] by consulintel.es (MDaemon.PRO.v8.0.1.R) with ESMTP id md50001606820.msg for ; Sun, 05 Feb 2006 13:17:00 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 05 Feb 2006 13:14:15 +0100 Subject: Re: Teredo spec has been published! From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: Teredo spec has been published! Thread-Index: AcYqTa4y7KyHVpZAEdqrTwANky3PwA== In-Reply-To: <1139140919.19913.2.camel@localhost.localdomain> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060205:v6ops@ops.ietf.org::EonPYYAa9+uAlCRy:00000000000000000000000000000000000000000001M+N X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Sun, 05 Feb 2006 13:17:03 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I don't agree. If you do so, you break one of the principles of Teredo, and then you do not longer need an IANA assigned prefix. The idea is to ensure that all the Teredo clients can talk peer-to-peer. Regards, Jordi > De: Vincent Jardin > Organizaci=F3n: http://www.6wind.com/ > Responder a: > Fecha: Sun, 05 Feb 2006 13:01:58 +0100 > Para: haofeng Zhang > CC: Christian Huitema , "v6ops@ops.ietf.org" > > Asunto: Re: Teredo spec has been published! >=20 > Le dimanche 05 f=E9vrier 2006 =E0 10:56 +0800, haofeng Zhang a =E9crit : >> Great News. >> I am expecting the next version of Windows will support Teredo service >> proposed by RFC4380. >> Also, I think it will be more flexible if a Teredo Client accepts any >> reasonable global IPv6 prefix, not only 2001:0000::/32 defined in the >> sepcification. =20 >=20 > Yes, it would be very usefull with we can configure the Teredo prefix on > the next update of Windows, instead of having a hard-coded > 2001:0000::/32. >=20 > Regards, > Vincent >=20 >>=20 >> =20 >> 2006/2/4, Christian Huitema : >> The Teredo spec has been published as an individual >> submission: >> =20 >> RFC4380 >> Teredo: Tunneling IPv6 over UDP through Network >> Address=20 >> Translations (NATs) >> C. Huitema February 2006 ASCII >> PROPOSED STANDARD >> =20 >> Thanks to the many NGTRANS and V6OPS working group members who >> reviewed >> the spec! >> =20 >> -- Christian Huitema >> =20 >>=20 >>=20 >>=20 >> --=20 >> Best regards, >> Zhang haofeng=20 >=20 >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sun Feb 05 08:39:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5k7J-00054u-76 for v6ops-archive@megatron.ietf.org; Sun, 05 Feb 2006 08:39:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09785 for ; Sun, 5 Feb 2006 08:38:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5k5T-000K4e-LI for v6ops-data@psg.com; Sun, 05 Feb 2006 13:37:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [138.195.130.75] (helo=durga.via.ecp.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5k5Q-000K4H-Kb for v6ops@ops.ietf.org; Sun, 05 Feb 2006 13:37:52 +0000 Received: from localhost (durga.via.ecp.fr [127.0.0.1]) by durga.via.ecp.fr (Postfix) with ESMTP id 0850E3CD5 for ; Sun, 5 Feb 2006 14:37:51 +0100 (CET) Received: from durga.via.ecp.fr ([127.0.0.1]) by localhost (durga [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13022-91 for ; Sun, 5 Feb 2006 14:37:50 +0100 (CET) Received: from auguste.via.ecp.fr (auguste.via.ecp.fr [IPv6:2002:8ac3:802d:1242:20d:60ff:fe38:6d16]) by durga.via.ecp.fr (Postfix) with ESMTP id DF8573C96 for ; Sun, 5 Feb 2006 14:37:50 +0100 (CET) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: =?iso-8859-1?q?=C9l=E8ve_de_l=27=C9cole_Centrale?= Paris To: jordi.palet@consulintel.es Subject: Re: Teredo spec has been published! Date: Sun, 5 Feb 2006 14:23:28 +0100 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200602051423.28271.Remi.Denis-Courmont@via.ecp.fr> X-Length: 4348 X-UID: 3744 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at via.ecp.fr Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Le Dimanche 5 F=E9vrier 2006 13:14, JORDI PALET MARTINEZ a =E9crit : > I don't agree. > If you do so, you break one of the principles of Teredo, and then you > do not longer need an IANA assigned prefix. > The idea is to ensure that all the Teredo clients can talk > peer-to-peer. I would say there are different problems here: 1/ the transition from Microsoft experimental (3ffe:831f::/32) to IANA=20 assigned (2001:0000::/32) prefixes 2/ internal private use of Teredo as a NAT-friendly ISATAP, whereas it=20 is defined as a NAT-friendly 6to4 (sort of) Regarding the Teredo prefixes transition: I would say it would have been more practical if Windows-based clients=20 had accepted any (sensible?) Teredo prefix until the RFC was published,=20 which is what my -admittedly hardly used at all- implementation does.=20 Similarly, it should have been possible to configure the prefix=20 advertised by servers and relays until a post-RFC updates, to ease=20 migration of pre-RFC users. The fact is that they are many Windows users that use pre-RFC Teredo=20 clients that only accept 3ffe:831f::/32, probably many of whom not even=20 knowingly. As a reference, the www.videolan.org typically receives=20 something like 50Gb/day IPv4 traffic, 500Mb/day native IPv6+6to4,=20 50Mb/day via pre-RFC Teredo, and absolute zero IANA Teredo. It has=20 Teredo relays for both Microsoft experimental and IANA assigned=20 prefixes. If you maintain a relay, you can transition smoothly by putting two=20 relays until 6bone is phased out. But for Teredo servers and clients,=20 there is no way to transition smoothly at the moment. Regarding the private use case: The fact that the prefix has to be a /32 renders, it is almost=20 impossible in practice. I would say implementors should obviously use=20 and encourage use of the IANA prefix by default. It is arguably useless=20 to allow the use of another prefix, but implementations should at least=20 accept the experimental prefix until 6bone is phased out for pratical=20 reasons discussed above. A company willing to use Teredo internal as a "NAT-friendly ISATAP" may=20 still want to use a different prefix, e.g. for access-control, or=20 because it wants to put the servers/relays on private IPv4. However, in=20 any case, that would involve a bunch of modifications in contradiction=20 to the Teredo RFC in any case, such as: =2D allowing Teredo addresses bits 32-63 to differ from the server IPv4 so= =20 that 64-bits prefix is sufficient, provided all clients can assume the=20 others use the same server as themselves, =2D ignoring the requirements for mapped and server IPv4 addresses to be=20 unicast global. So... well... there is indeed probably no case for a *RFC-compliant*=20 implementation to accept a prefix other than the IANA (and=20 experimental) one(s). But then, Microsoft is already promising an unspecified extension in=20 upcoming Vista, which is the ability to use Teredo from behind a=20 symmetric NAT, at the obvious expense of transitive reachability. Also,=20 as I already pointed out a long time ago here, Teredo clients assume=20 that the server secondary IPv4 address is always next to the server=20 primary address, though I could find no mention of that requirement in=20 the RFC nor any of the six drafts (I've not read the older "shipworm"=20 ones). =2D-=20 R=E9mi Denis-Courmont Student-engineer at the Ecole Centrale Paris http://www.simphalempin.com/home/infos/cv.shtml.en From owner-v6ops@ops.ietf.org Sun Feb 05 08:44:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5kBP-00066f-Nf for v6ops-archive@megatron.ietf.org; Sun, 05 Feb 2006 08:44:04 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10748 for ; Sun, 5 Feb 2006 08:42:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5kBB-000KRR-Ap for v6ops-data@psg.com; Sun, 05 Feb 2006 13:43:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.0 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5kB9-000KRB-SX for v6ops@ops.ietf.org; Sun, 05 Feb 2006 13:43:48 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id k15DhjQk122124 for ; Sun, 5 Feb 2006 13:43:45 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k15DhiaM242180 for ; Sun, 5 Feb 2006 14:43:44 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k15DhiIS026725 for ; Sun, 5 Feb 2006 14:43:44 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k15DhigG026722; Sun, 5 Feb 2006 14:43:44 +0100 Received: from zurich.ibm.com (sig-9-145-251-60.de.ibm.com [9.145.251.60]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA49852; Sun, 5 Feb 2006 14:43:43 +0100 Message-ID: <43E6010D.1090509@zurich.ibm.com> Date: Sun, 05 Feb 2006 14:43:41 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Bora Akyol CC: Vishwas Manral , v6ops@ops.ietf.org Subject: Re: Flow label and its uses References: <03235919BBDE634289BB6A0758A20B36358030@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <03235919BBDE634289BB6A0758A20B36358030@NT-SJCA-0751.brcm.ad.broadcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As the flow label spec says (RFC 3697, section 5.1), you can trust the flow label just as much as you can trust the source and destination addresses - exactly the same attackers can forge any of them. As Spencer and Thomas have pointed out, it's too expensive to check an authenticator at each hop, and the hops cannot know the relevant keys anyway. So, you can use the address pair and flow label for classification, just as safely (or dangerously) as you can use the address pair and the DSCP. There's no impact on the applicable threats. A MITM can change any of them. The key difference from the DSCP in this regard is only that the DSCP is defined as mutable at domain boundaries and the flow label is defined as immutable. In both cases, you can't detect if someone breaks those rules. That constrains the use cases - erroneous usage mustn't change the basic semantics of unreliable datagram delivery to the intended destination. RFC 2474 and RFC 3697 both assume this - i.e. the added threat is theft of QoS. In a connectionless datagram network, it seems impossible to do better. Brian Bora Akyol wrote: > Flow label is not a field that is protected by IPSEC > hence I do not think you can use > this as a selector. > > Unless you do modifications to IKEv2, you can not also let > the other end know what exactly the SP (security policy) > is based on. > > Frankly, use of flow label as a selector would be a hack > to get around the problem of the full security policy lookup > in IPSEC at high speeds. The truth is that this has not > been a problem for at least 4-5 years now as long > as the selectors themselves are TCAM friendly. > > Bora > > > >>-----Original Message----- >>From: Vishwas Manral [mailto:Vishwas@sinett.com] >>Sent: Tuesday, January 31, 2006 2:08 AM >>To: Bora Akyol; Spencer Dawkins; v6ops@ops.ietf.org >>Subject: RE: Flow label and its uses >> >>Bora, >> >> >>>Does this mean that you are using the flow label in lieu of the >>>regular IPSEC SP match? >> >>All I am saying is just as we can have local and remote ports >>as selectors; we can instead use Flow Labels along with the >>IP addresses for the same purpose, if some assumptions can be >>made for the flow label. >> >>Is my understanding wrong? >> >>Thanks, >>Vishwas > > > > From owner-v6ops@ops.ietf.org Sun Feb 05 09:03:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5kUV-0004qj-KK for v6ops-archive@megatron.ietf.org; Sun, 05 Feb 2006 09:03:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12886 for ; Sun, 5 Feb 2006 09:02:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5kTo-000LjY-Ip for v6ops-data@psg.com; Sun, 05 Feb 2006 14:03:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [212.27.42.35] (helo=smtp5-g19.free.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5kTn-000LiL-9I for v6ops@ops.ietf.org; Sun, 05 Feb 2006 14:03:03 +0000 Received: from [192.168.0.14] (ver78-2-82-241-89-240.fbx.proxad.net [82.241.89.240]) by smtp5-g19.free.fr (Postfix) with ESMTP id 3AF8817E71; Sun, 5 Feb 2006 15:02:59 +0100 (CET) Subject: Re: Teredo spec has been published! From: Vincent Jardin To: jordi.palet@consulintel.es Cc: "v6ops@ops.ietf.org" In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Organization: http://www.6wind.com/ Date: Sun, 05 Feb 2006 15:02:58 +0100 Message-Id: <1139148178.31150.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA12886 Jordi, Even if you remove the constraint on the hard-coded prefix, the Teredo clients "can talk peer-to-peer"; it does not break any compatibility, please can you explain why it would be broken ? The requirement of being able to configure the Teredo prefix is: - control the transition from the previous prefix to the new one, - be able to support some private usages of the Teredo prefix (development, testing, etc.). I don't say that 2001:0000::/32 should not be the default value, as recommended by the IANA, but it should be configure-able. It is more a implementation constraint rather than a standardization constraint. Regards, Vincent Le dimanche 05 f=C3=A9vrier 2006 =C3=A0 13:14 +0100, JORDI PALET MARTINEZ= a =C3=A9crit : > I don't agree. >=20 > If you do so, you break one of the principles of Teredo, and then you d= o not > longer need an IANA assigned prefix. >=20 > The idea is to ensure that all the Teredo clients can talk peer-to-peer. >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 > > De: Vincent Jardin > > Organizaci=C3=B3n: http://www.6wind.com/ > > Responder a: > > Fecha: Sun, 05 Feb 2006 13:01:58 +0100 > > Para: haofeng Zhang > > CC: Christian Huitema , "v6ops@ops.iet= f.org" > > > > Asunto: Re: Teredo spec has been published! > >=20 > > Le dimanche 05 f=C3=A9vrier 2006 =C3=A0 10:56 +0800, haofeng Zhang a = =C3=A9crit : > >> Great News. > >> I am expecting the next version of Windows will support Teredo servi= ce > >> proposed by RFC4380. > >> Also, I think it will be more flexible if a Teredo Client accepts an= y > >> reasonable global IPv6 prefix, not only 2001:0000::/32 defined in th= e > >> sepcification. =20 > >=20 > > Yes, it would be very usefull with we can configure the Teredo prefix= on > > the next update of Windows, instead of having a hard-coded > > 2001:0000::/32. > >=20 > > Regards, > > Vincent > >=20 > >>=20 > >> =20 > >> 2006/2/4, Christian Huitema : > >> The Teredo spec has been published as an individual > >> submission: > >> =20 > >> RFC4380 > >> Teredo: Tunneling IPv6 over UDP through Network > >> Address=20 > >> Translations (NATs) > >> C. Huitema February 2006 ASCII > >> PROPOSED STANDARD > >> =20 > >> Thanks to the many NGTRANS and V6OPS working group members w= ho > >> reviewed > >> the spec! > >> =20 > >> -- Christian Huitema > >> =20 > >>=20 > >>=20 > >>=20 > >> --=20 > >> Best regards, > >> Zhang haofeng=20 > >=20 > >=20 >=20 >=20 >=20 >=20 > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org >=20 > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com >=20 > This electronic message contains information which may be privileged or= confidential. The information is intended to be for the use of the indiv= idual(s) named above. If you are not the intended recipient be aware that= any disclosure, copying, distribution or use of the contents of this inf= ormation, including attached files, is prohibited. >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sun Feb 05 09:18:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5kid-00026u-SQ for v6ops-archive@megatron.ietf.org; Sun, 05 Feb 2006 09:18:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14295 for ; Sun, 5 Feb 2006 09:16:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5khm-000MkH-Jt for v6ops-data@psg.com; Sun, 05 Feb 2006 14:17:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5khl-000Mjs-GU for v6ops@ops.ietf.org; Sun, 05 Feb 2006 14:17:29 +0000 Received: from [10.10.10.101] by consulintel.es (MDaemon.PRO.v8.0.1.R) with ESMTP id md50001606901.msg for ; Sun, 05 Feb 2006 15:20:01 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 05 Feb 2006 15:17:16 +0100 Subject: Re: Teredo spec has been published! From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: Teredo spec has been published! Thread-Index: AcYqXt2dHCE2fJZSEdqB4QANky3PwA== In-Reply-To: <200602051423.28271.Remi.Denis-Courmont@via.ecp.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060205:v6ops@ops.ietf.org::9Aek7l7ln6WxTWJz:000000000000000000000000000000000000000000044ES X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Sun, 05 Feb 2006 15:20:05 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Remi, I see your point regarding the transition, but I'm sure Microsoft, which is where we have the *much much much* higher % of the Clients, Servers and Relays, will issue an automatic update that will correct it. Also, as the clients point by default to the Microsoft Teredo Server, something there may also do "something" regarding this. May be the Microsoft Patch for the servers will come out first, allowing some kind of "dual prefix" support until 6bone phase out, then after a few weeks, the Client update will be made available. I guess Christian could describe the "transition" plan so other implementers can follow a similar approach and we don't get 2 disconnected Teredo "Internets". Once this Teredo Server/Relay/Client update is available, at least in our case, which maintain a Server and a Relay, will move to the new prefix. It will be just a matter of minutes, hopefully, but an "official" procedure could be very useful. I'm not sure if it make sense to make a draft for this. It could be possible to make a draft just to describe it, even if afterwards is not promoted to RFC. Just in order to ensure that people looking for "Teredo" in the next 6 months for implementing and/or deploying it, make sure to follow the same "transition" plan. Regards, Jordi > De: R=E9mi Denis-Courmont > Organizaci=F3n: =C9l=E8ve de l'=C9cole Centrale Paris > Responder a: > Fecha: Sun, 5 Feb 2006 14:23:28 +0100 > Para: > Asunto: Re: Teredo spec has been published! >=20 > Le Dimanche 5 F=E9vrier 2006 13:14, JORDI PALET MARTINEZ a =E9crit : >> I don't agree. >=20 >> If you do so, you break one of the principles of Teredo, and then you >> do not longer need an IANA assigned prefix. >=20 >> The idea is to ensure that all the Teredo clients can talk >> peer-to-peer. >=20 > I would say there are different problems here: > 1/ the transition from Microsoft experimental (3ffe:831f::/32) to IANA > assigned (2001:0000::/32) prefixes > 2/ internal private use of Teredo as a NAT-friendly ISATAP, whereas it > is defined as a NAT-friendly 6to4 (sort of) >=20 >=20 > Regarding the Teredo prefixes transition: >=20 > I would say it would have been more practical if Windows-based clients > had accepted any (sensible?) Teredo prefix until the RFC was published, > which is what my -admittedly hardly used at all- implementation does. > Similarly, it should have been possible to configure the prefix > advertised by servers and relays until a post-RFC updates, to ease > migration of pre-RFC users. >=20 > The fact is that they are many Windows users that use pre-RFC Teredo > clients that only accept 3ffe:831f::/32, probably many of whom not even > knowingly. As a reference, the www.videolan.org typically receives > something like 50Gb/day IPv4 traffic, 500Mb/day native IPv6+6to4, > 50Mb/day via pre-RFC Teredo, and absolute zero IANA Teredo. It has > Teredo relays for both Microsoft experimental and IANA assigned > prefixes. >=20 > If you maintain a relay, you can transition smoothly by putting two > relays until 6bone is phased out. But for Teredo servers and clients, > there is no way to transition smoothly at the moment. >=20 >=20 > Regarding the private use case: >=20 > The fact that the prefix has to be a /32 renders, it is almost > impossible in practice. I would say implementors should obviously use > and encourage use of the IANA prefix by default. It is arguably useless > to allow the use of another prefix, but implementations should at least > accept the experimental prefix until 6bone is phased out for pratical > reasons discussed above. >=20 > A company willing to use Teredo internal as a "NAT-friendly ISATAP" may > still want to use a different prefix, e.g. for access-control, or > because it wants to put the servers/relays on private IPv4. However, in > any case, that would involve a bunch of modifications in contradiction > to the Teredo RFC in any case, such as: > - allowing Teredo addresses bits 32-63 to differ from the server IPv4 so > that 64-bits prefix is sufficient, provided all clients can assume the > others use the same server as themselves, > - ignoring the requirements for mapped and server IPv4 addresses to be > unicast global. >=20 > So... well... there is indeed probably no case for a *RFC-compliant* > implementation to accept a prefix other than the IANA (and > experimental) one(s). >=20 > But then, Microsoft is already promising an unspecified extension in > upcoming Vista, which is the ability to use Teredo from behind a > symmetric NAT, at the obvious expense of transitive reachability. Also, > as I already pointed out a long time ago here, Teredo clients assume > that the server secondary IPv4 address is always next to the server > primary address, though I could find no mention of that requirement in > the RFC nor any of the six drafts (I've not read the older "shipworm" > ones). >=20 > --=20 > R=E9mi Denis-Courmont > Student-engineer at the Ecole Centrale Paris > http://www.simphalempin.com/home/infos/cv.shtml.en >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sun Feb 05 09:29:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5ktj-0006HW-8x for v6ops-archive@megatron.ietf.org; Sun, 05 Feb 2006 09:29:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15076 for ; Sun, 5 Feb 2006 09:28:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5ktE-000NTU-6S for v6ops-data@psg.com; Sun, 05 Feb 2006 14:29:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5ktD-000NTC-Bo for v6ops@ops.ietf.org; Sun, 05 Feb 2006 14:29:19 +0000 Received: from [10.10.10.101] by consulintel.es (MDaemon.PRO.v8.0.1.R) with ESMTP id md50001606908.msg for ; Sun, 05 Feb 2006 15:31:52 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 05 Feb 2006 15:29:08 +0100 Subject: Re: Teredo spec has been published! From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: Teredo spec has been published! Thread-Index: AcYqYIX/xModspZTEdqB4QANky3PwA== In-Reply-To: <1139148178.31150.10.camel@localhost.localdomain> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060205:v6ops@ops.ietf.org::EUAxxBPn534sXFy2:00000000000000000000000000000000000000000002hqj X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Sun, 05 Feb 2006 15:31:55 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Vincent, I mean peer-to-peer across different domains if we allow different prefixes (except the issue of the transition period from the 6bone one to the RFC one). (see my previous email regarding the transition) In general I'm not sure if it is a good practice to ignore the IANA defines definitions for prefixes, addresses, ports, etc. If you really want to use a different one for an experiment, it may be safer to force doing a patch for it instead of allowing users to arbitrary change it. Regarding the private usages, it will be probably so easy as to describe them in a new draft, so implementers can decide if support only the existing RFC or also the private usages (I guess most of the open source implementations will be happy to do that). Regards, Jordi > De: Vincent Jardin > Organizaci=F3n: http://www.6wind.com/ > Responder a: > Fecha: Sun, 05 Feb 2006 15:02:58 +0100 > Para: > CC: "v6ops@ops.ietf.org" > Asunto: Re: Teredo spec has been published! >=20 > Jordi, >=20 > Even if you remove the constraint on the hard-coded prefix, the Teredo > clients "can talk peer-to-peer"; it does not break any compatibility, > please can you explain why it would be broken ? >=20 > The requirement of being able to configure the Teredo prefix is: > - control the transition from the previous prefix to the new one, > - be able to support some private usages of the Teredo prefix > (development, testing, etc.). >=20 > I don't say that 2001:0000::/32 should not be the default value, as > recommended by the IANA, but it should be configure-able. It is more a > implementation constraint rather than a standardization constraint. >=20 > Regards, > Vincent >=20 > Le dimanche 05 f=E9vrier 2006 =E0 13:14 +0100, JORDI PALET MARTINEZ a > =E9crit : >> I don't agree. >>=20 >> If you do so, you break one of the principles of Teredo, and then you do not >> longer need an IANA assigned prefix. >>=20 >> The idea is to ensure that all the Teredo clients can talk peer-to-peer. >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >>=20 >>> De: Vincent Jardin >>> Organizaci=F3n: http://www.6wind.com/ >>> Responder a: >>> Fecha: Sun, 05 Feb 2006 13:01:58 +0100 >>> Para: haofeng Zhang >>> CC: Christian Huitema , "v6ops@ops.ietf.org" >>> >>> Asunto: Re: Teredo spec has been published! >>>=20 >>> Le dimanche 05 f=E9vrier 2006 =E0 10:56 +0800, haofeng Zhang a =E9crit : >>>> Great News. >>>> I am expecting the next version of Windows will support Teredo service >>>> proposed by RFC4380. >>>> Also, I think it will be more flexible if a Teredo Client accepts any >>>> reasonable global IPv6 prefix, not only 2001:0000::/32 defined in the >>>> sepcification. >>>=20 >>> Yes, it would be very usefull with we can configure the Teredo prefix on >>> the next update of Windows, instead of having a hard-coded >>> 2001:0000::/32. >>>=20 >>> Regards, >>> Vincent >>>=20 >>>>=20 >>>> =20 >>>> 2006/2/4, Christian Huitema : >>>> The Teredo spec has been published as an individual >>>> submission: >>>> =20 >>>> RFC4380 >>>> Teredo: Tunneling IPv6 over UDP through Network >>>> Address >>>> Translations (NATs) >>>> C. Huitema February 2006 ASCII >>>> PROPOSED STANDARD >>>> =20 >>>> Thanks to the many NGTRANS and V6OPS working group members who >>>> reviewed >>>> the spec! >>>> =20 >>>> -- Christian Huitema >>>> =20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Best regards, >>>> Zhang haofeng=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >>=20 >> Barcelona 2005 Global IPv6 Summit >> Slides available at: >> http://www.ipv6-es.com >>=20 >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sun Feb 05 11:40:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5mw9-00062X-KY for v6ops-archive@megatron.ietf.org; Sun, 05 Feb 2006 11:40:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24303 for ; Sun, 5 Feb 2006 11:38:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5mtM-0004pb-LU for v6ops-data@psg.com; Sun, 05 Feb 2006 16:37:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5mtL-0004pQ-Uj for v6ops@ops.ietf.org; Sun, 05 Feb 2006 16:37:35 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Sun, 5 Feb 2006 08:37:35 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Feb 2006 08:37:35 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Feb 2006 08:37:34 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Feb 2006 08:37:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Teredo spec has been published! Date: Sun, 5 Feb 2006 08:37:31 -0800 Message-ID: In-Reply-To: Thread-Topic: Teredo spec has been published! thread-index: AcYqYIX/xModspZTEdqB4QANky3PwAAD4QIQ From: "Christian Huitema" To: , "Vincent Jardin" Cc: X-OriginalArrivalTime: 05 Feb 2006 16:37:34.0494 (UTC) FILETIME=[776D7BE0:01C62A72] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Regarding the private usages, it will be probably so easy as to describe > them in a new draft, so implementers can decide if support only the > existing > RFC or also the private usages (I guess most of the open source > implementations will be happy to do that). The Teredo specification, as it stands, is largely "good enough". It could certainly be made even better. But, before we work on a new solution, it would be nice to understand the new requirements that we try to address.=20 The current specification is designed for the "capital I" Internet, and the use of a common prefix pretty much derives from that requirement. The 32 bit length derives from a requirement was to embed the server's IPv4 address in the prefix. If you don't do that, you end up with a reliance on a static "IPv4 anycast" address, which would have to be used as source address for the packets sent by Teredo servers. This was in fact the original "shipworm" design. It was rejected by the IESG because using "anycast" as source causes hard management issues. In any case, obtaining a /32 bit allocation from the IANA was very hard, and I don't think we will see another one anytime soon. -- Christian Huitema From owner-v6ops@ops.ietf.org Sun Feb 05 13:21:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5oWJ-00052a-65 for v6ops-archive@megatron.ietf.org; Sun, 05 Feb 2006 13:21:55 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01415 for ; Sun, 5 Feb 2006 13:20:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5oUI-000Apz-5B for v6ops-data@psg.com; Sun, 05 Feb 2006 18:19:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5oUH-000Apa-6i for v6ops@ops.ietf.org; Sun, 05 Feb 2006 18:19:49 +0000 Received: from [10.10.10.101] by consulintel.es (MDaemon.PRO.v8.0.1.R) with ESMTP id md50001607007.msg for ; Sun, 05 Feb 2006 19:19:04 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sun, 05 Feb 2006 19:19:30 +0100 Subject: Re: Teredo spec has been published! From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: Teredo spec has been published! Thread-Index: AcYqYIX/xModspZTEdqB4QANky3PwAAD4QIQAAQqoS4= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060205:v6ops@ops.ietf.org::P2CNXlDkZPx7JmNe:0000000000000000000000000000000000000000000H4FY X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Sun, 05 Feb 2006 19:19:10 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Agree. So then let's work in a "transision" plan. I guess we want to make it coordinated among different implementations, not just the Microsoft one. I guess Microsoft has some specific thought of how you're going to do that, and it will be good to coordinate some how, so the current people who has already deployed Teredo Relays and/or Servers can follow the same criteria. Can you already tell us something on this, or is still not concreted ? Regards, Jordi > De: Christian Huitema > Responder a: > Fecha: Sun, 5 Feb 2006 08:37:31 -0800 > Para: , Vincent Jardin > CC: > Conversaci=F3n: Teredo spec has been published! > Asunto: RE: Teredo spec has been published! >=20 >> Regarding the private usages, it will be probably so easy as to > describe >> them in a new draft, so implementers can decide if support only the >> existing >> RFC or also the private usages (I guess most of the open source >> implementations will be happy to do that). >=20 > The Teredo specification, as it stands, is largely "good enough". It > could certainly be made even better. But, before we work on a new > solution, it would be nice to understand the new requirements that we > try to address.=20 >=20 > The current specification is designed for the "capital I" Internet, and > the use of a common prefix pretty much derives from that requirement. > The 32 bit length derives from a requirement was to embed the server's > IPv4 address in the prefix. If you don't do that, you end up with a > reliance on a static "IPv4 anycast" address, which would have to be used > as source address for the packets sent by Teredo servers. This was in > fact the original "shipworm" design. It was rejected by the IESG because > using "anycast" as source causes hard management issues. In any case, > obtaining a /32 bit allocation from the IANA was very hard, and I don't > think we will see another one anytime soon. >=20 > -- Christian Huitema >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sun Feb 05 13:31:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5ofp-0008Oi-3P for v6ops-archive@megatron.ietf.org; Sun, 05 Feb 2006 13:31:57 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01890 for ; Sun, 5 Feb 2006 13:29:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5ofI-000BeD-Dj for v6ops-data@psg.com; Sun, 05 Feb 2006 18:31:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5ofG-000Bdx-Ux for v6ops@ops.ietf.org; Sun, 05 Feb 2006 18:31:11 +0000 Received: (qmail 82924 invoked by uid 1007); 5 Feb 2006 18:31:09 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=TNTpOQ0k8PCdVQLKNrHA+27souh8Y3z1pY0y4o4VG5kIRVom4z4xodBIQ0X5st73 ; Date: Sun, 5 Feb 2006 19:31:09 +0100 From: Gert Doering To: Christian Huitema Cc: jordi.palet@consulintel.es, Vincent Jardin , v6ops@ops.ietf.org Subject: Re: Teredo spec has been published! Message-ID: <20060205183109.GK55194@Space.Net> References:

Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Sun, Feb 05, 2006 at 08:37:31AM -0800, Christian Huitema wrote: [..] > using "anycast" as source causes hard management issues. In any case, > obtaining a /32 bit allocation from the IANA was very hard, and I don't > think we will see another one anytime soon. Off a slightly different tangent: what sort of routes are expected to show up from 2001:0000::/32 in the routing table? I didn't read recent Teredo drafts, but if I remember the concept clearly enough, the embedded server (relay?) address would make this "one /64 prefix per server", right? Or will all relays announce the whole /32, effectively anycasting it, as it is done with 6to4 2002::/32? (Sorry if this is something obviously answered in the draft - I really don't have time to read up on the details right now, but I think I'll have to update my filtering recommendations page). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From owner-v6ops@ops.ietf.org Sun Feb 05 14:22:16 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5pSf-0006mi-DI for v6ops-archive@megatron.ietf.org; Sun, 05 Feb 2006 14:22:16 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05058 for ; Sun, 5 Feb 2006 14:20:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5pR6-000EjM-21 for v6ops-data@psg.com; Sun, 05 Feb 2006 19:20:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5pR2-000Ej4-BP for v6ops@ops.ietf.org; Sun, 05 Feb 2006 19:20:32 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Sun, 5 Feb 2006 11:20:31 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Feb 2006 11:20:31 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Feb 2006 11:20:31 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Feb 2006 11:20:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Teredo spec has been published! Date: Sun, 5 Feb 2006 11:20:28 -0800 Message-ID: In-Reply-To: <20060205183109.GK55194@Space.Net> Thread-Topic: Teredo spec has been published! thread-index: AcYqgl8td8gcBwl0TcKcnjWP4CyIegABXFJg From: "Christian Huitema" To: "Gert Doering" Cc: , "Vincent Jardin" , X-OriginalArrivalTime: 05 Feb 2006 19:20:30.0952 (UTC) FILETIME=[3AA69680:01C62A89] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Off a slightly different tangent: what sort of routes are expected to > show up from 2001:0000::/32 in the routing table? I would expect a single 2001:0000::/32 route leading to the closest teredo relay. > I didn't read recent Teredo drafts, but if I remember the concept clearly > enough, the embedded server (relay?) address would make this "one /64 > prefix per server", right? Only a tiny fraction of the traffic goes through the servers. The bulk of it goes on a direct IPv4 path between the relay and the Teredo host. The benefits of "per server' /64 routes would be marginal and the impact on the routing tables would be large. > Or will all relays announce the whole /32, effectively anycasting it, > as it is done with 6to4 2002::/32? Yes. With this design, traffic will go from IPv6 host to the closest Teredo relay and from there on a direct IPv4 path to the Teredo host. This is expected to be a good approximation of the shortest path between the IPv6 host and the Teredo host. -- Christian Huitema From owner-v6ops@ops.ietf.org Sun Feb 05 21:21:01 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5vzr-0006Gt-VX for v6ops-archive@megatron.ietf.org; Sun, 05 Feb 2006 21:21:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04524 for ; Sun, 5 Feb 2006 21:19:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5vwt-000EZP-On for v6ops-data@psg.com; Mon, 06 Feb 2006 02:17:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, SPF_PASS autolearn=ham version=3.1.0 Received: from [66.249.82.197] (helo=xproxy.gmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F5vws-000EZC-Ql for v6ops@ops.ietf.org; Mon, 06 Feb 2006 02:17:50 +0000 Received: by xproxy.gmail.com with SMTP id s10so878742wxc for ; Sun, 05 Feb 2006 18:17:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=nNoU+dQ4D5EqgP5vxP5vCmkpVlyaUwCEVncGud9mRYdZQ+xKH+Yvs+JmI55YsrXYy+QqAmSlkZ+94bjk0y022KyWFk7QPvvPlSZ535jzH5HXLfx6qil0Dk1txK9tfuZA/tIwjrVMED+9Smbx5maoy/zt7bcaniUqcoJKk32l7Nc= Received: by 10.70.16.15 with SMTP id 15mr5179939wxp; Sun, 05 Feb 2006 18:17:49 -0800 (PST) Received: by 10.70.39.20 with HTTP; Sun, 5 Feb 2006 18:17:49 -0800 (PST) Message-ID: Date: Mon, 6 Feb 2006 10:17:49 +0800 From: haofeng Zhang To: Christian Huitema Subject: Re: Teredo spec has been published! Cc: Gert Doering , jordi.palet@consulintel.es, Vincent Jardin , v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_24712_27556478.1139192269378" References: <20060205183109.GK55194@Space.Net> Sender: owner-v6ops@ops.ietf.org Precedence: bulk ------=_Part_24712_27556478.1139192269378 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Christian, Jordi, Vincent: My reason to raise such a topic is the concern that current Teredo specification may cause routing problem in the real ISP network, because of the fact that many ISPs wanna control the routing policy of their own IPv6 network. And this problem may cause ISPs unwilling to deploy Teredo service= . This problem, for example, 1. Based on current Teredo spec, the core router in an IPv6 network shall advertise 2001:0000::/32 route through BGP4+ to other ASes, to ensure the connectivity of its own Teredo users. Also, I think it's better for the cor= e router to also act as a Teredo relay router, otherwise too many static routes have to be configured. But how can we expect the IPv6 core router t= o have the native IPv4 connection? 2. In some situation, the traffic from a IPv6 server to a Teredo user in IS= P network A may bypass ISP B's network, if the Teredo relay router of ISP B i= s nearer to the IPv6 server. So for all network operators, it's hard to predict and control both the IPv4 routing path and IPv6 routing path. Actually, We are considering the availability of 6to4 service in our curren= t IPv6 network construction. Teredo service is using the similarly solution i= n IPv6 routing to 6to4. Vicent gave the good point that 2001:0000::/32 should be the default value, as recommended by the IANA, but I recommend that this prefix be configure-able in Teredo server. In such case, the ISP provides the Teredo server, and the ISP controls IPv6 routing policy. Best wishes Haofeng. Zhang 2006/2/6, Christian Huitema : > > > Off a slightly different tangent: what sort of routes are expected to > > show up from 2001:0000::/32 in the routing table? > > I would expect a single 2001:0000::/32 route leading to the closest > teredo relay. > > > I didn't read recent Teredo drafts, but if I remember the concept > clearly > > enough, the embedded server (relay?) address would make this "one /64 > > prefix per server", right? > > Only a tiny fraction of the traffic goes through the servers. The bulk > of it goes on a direct IPv4 path between the relay and the Teredo host. > The benefits of "per server' /64 routes would be marginal and the impact > on the routing tables would be large. > > > Or will all relays announce the whole /32, effectively anycasting it, > > as it is done with 6to4 2002::/32? > > Yes. With this design, traffic will go from IPv6 host to the closest > Teredo relay and from there on a direct IPv4 path to the Teredo host. > This is expected to be a good approximation of the shortest path between > the IPv6 host and the Teredo host. > > -- Christian Huitema > > > > -- Best regards, Zhang haofeng ------=_Part_24712_27556478.1139192269378 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi, Christian, Jordi, Vincent:

My reason to raise such a topic is the concern that current Tered= o specification may cause routing problem in the real ISP network, because = of the fact that many ISPs wanna control the routing policy of&nb= sp;their own IPv6 network. And this problem may cause ISPs unwill= ing to deploy Teredo service.

This problem, for example,

1. Based on current Teredo spec, the core router in an IPv6 network sh= all advertise 2001:0000::/32 route through BGP4+ to other ASes, to ensure t= he connectivity of its own Teredo users. Also, I think it's better for the = core router to also act as a Teredo relay router, otherwise too many s= tatic routes have to be configured. But how can we expect the IPv6 co= re router to have the native IPv4 connection?

2. In some situation, the traffic from a IPv6 server to a Te= redo user in ISP network A may bypass ISP B's network, if the Teredo relay = router of ISP B is nearer to the IPv6 server. So for all network operators,= it's hard to predict and control both the IPv4 routing path and IPv6 routi= ng path.

Actually, We are considering the availability of 6to4 service in our c= urrent IPv6 network construction. Teredo service is using the similarly sol= ution in IPv6 routing to 6to4.

Vicent gave the good point that 2001:0000::/32 should be the default v= alue, as recommended by the IANA, but I recommend that this prefix be confi= gure-able in Teredo server. In such case, the ISP provides the Teredo serve= r, and the ISP controls IPv6 routing policy.

Best wishes

Haofeng. Zhang

2006/2/6, Christian Huitema <huitema@windows.microsoft.com>= ;:

> Off a slightly different ta= ngent: what sort of routes are expected to
> show up from 2001:0000::= /32 in the routing table?

I would expect a single 2001:0000::/32 route leading to the closest=
teredo relay.

> I didn't read recent Teredo drafts, but if I = remember the concept
clearly
> enough, the embedded server (relay?= ) address would make this "one /64
> prefix per server", right?

Only a tiny fraction of the= traffic goes through the servers. The bulk
of it goes on a direct IPv4 = path between the relay and the Teredo host.
The benefits of "per se= rver' /64 routes would be marginal and the impact
on the routing tables would be large.

> Or will all relays an= nounce the whole /32, effectively anycasting it,
> as it is done with= 6to4 2002::/32?

Yes. With this design, traffic will go from IPv6 ho= st to the closest
Teredo relay and from there on a direct IPv4 path to the Teredo host.This is expected to be a good approximation of the shortest path between<= br>the IPv6 host and the Teredo host.

-- Christian Huitema

--
Best regards,Zhang haofeng=20 ------=_Part_24712_27556478.1139192269378-- From owner-v6ops@ops.ietf.org Mon Feb 06 04:30:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F62h8-0006fT-8h for v6ops-archive@megatron.ietf.org; Mon, 06 Feb 2006 04:30:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01348 for ; Mon, 6 Feb 2006 04:28:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F62eF-000Eq7-5R for v6ops-data@psg.com; Mon, 06 Feb 2006 09:27:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F62eD-000Epq-Se for v6ops@ops.ietf.org; Mon, 06 Feb 2006 09:27:02 +0000 Received: (qmail 37371 invoked by uid 1007); 6 Feb 2006 09:26:59 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=BrQenThXTGKRiB5TfFlPZz1hdO4VsQuNsS7E3cBuajIaTsxCTgmWDgoxbEo1rGXt ; Date: Mon, 6 Feb 2006 10:26:59 +0100 From: Gert Doering To: Christian Huitema Cc: jordi.palet@consulintel.es, Vincent Jardin , v6ops@ops.ietf.org Subject: Re: Teredo spec has been published! Message-ID: <20060206092659.GN55194@Space.Net> References:

<20060205183109.GK55194@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060205183109.GK55194@Space.Net> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Sun, Feb 05, 2006 at 07:31:09PM +0100, Gert Doering wrote: > Or will all relays announce the whole /32, effectively anycasting it, > as it is done with 6to4 2002::/32? Make that 2001::/32 and 2002::/16. Just to make sure the correct value is in the list archives. Sorry. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From owner-v6ops@ops.ietf.org Mon Feb 06 04:39:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F62qQ-0000LZ-Aa for v6ops-archive@megatron.ietf.org; Mon, 06 Feb 2006 04:39:38 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02070 for ; Mon, 6 Feb 2006 04:37:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F62px-000FiQ-4N for v6ops-data@psg.com; Mon, 06 Feb 2006 09:39:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F62pw-000Fgt-2J for v6ops@ops.ietf.org; Mon, 06 Feb 2006 09:39:08 +0000 Received: (from leinen@localhost) by diotima.switch.ch (8.13.5+Sun/8.13.5) id k169cQLr024933; Mon, 6 Feb 2006 10:38:27 +0100 (CET) To: Gert Doering Cc: Christian Huitema , jordi.palet@consulintel.es, Vincent Jardin , v6ops@ops.ietf.org Subject: Re: Teredo spec has been published! X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <20060205183109.GK55194@Space.Net> (Gert Doering's message of "Sun, 5 Feb 2006 19:31:09 +0100") References:

<20060205183109.GK55194@Space.Net> Date: Mon, 06 Feb 2006 10:38:26 +0100 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-v6ops@ops.ietf.org Precedence: bulk Gert Doering writes: > Or will all relays announce the whole /32, effectively anycasting > it, as it is done with 6to4 2002::/32? 2002::/16, you mean. -- Simon. From owner-v6ops@ops.ietf.org Mon Feb 06 14:27:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6C0o-0000v4-Nh for v6ops-archive@megatron.ietf.org; Mon, 06 Feb 2006 14:27:03 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14794 for ; Mon, 6 Feb 2006 14:25:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6BxX-0008r2-AC for v6ops-data@psg.com; Mon, 06 Feb 2006 19:23:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6BxW-0008qr-BU for v6ops@ops.ietf.org; Mon, 06 Feb 2006 19:23:34 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 6 Feb 2006 11:23:33 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 11:23:33 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 11:23:33 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Feb 2006 11:23:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Teredo spec has been published! Date: Mon, 6 Feb 2006 11:23:16 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1158BCFCF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Teredo spec has been published! Thread-Index: AcYqXXwUB0+19ewcSP6z5mXwXeVDmgA9Q90A From: "Dave Thaler" To: "Vincent Jardin" , Cc: X-OriginalArrivalTime: 06 Feb 2006 19:23:32.0978 (UTC) FILETIME=[D18F4D20:01C62B52] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I'm told by the devs that the prefix is already configurable on Windows = XP. The Teredo prefix can be configured by adding/altering the following = REG_DWORD value: = \HKLM\System\CurrentControlSet\Services\Tcpip6\Parameters\GlobalParams\Te= redoPrefix. The DWORD value is interpreted as a 32 bit prefix, in = network byte order. -Dave > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf > Of Vincent Jardin > Sent: Sunday, February 05, 2006 6:03 AM > To: jordi.palet@consulintel.es > Cc: v6ops@ops.ietf.org > Subject: Re: Teredo spec has been published! >=20 > Jordi, >=20 > Even if you remove the constraint on the hard-coded prefix, the Teredo > clients "can talk peer-to-peer"; it does not break any compatibility, > please can you explain why it would be broken ? >=20 > The requirement of being able to configure the Teredo prefix is: > - control the transition from the previous prefix to the new one, > - be able to support some private usages of the Teredo prefix > (development, testing, etc.). >=20 > I don't say that 2001:0000::/32 should not be the default value, as > recommended by the IANA, but it should be configure-able. It is more a > implementation constraint rather than a standardization constraint. >=20 > Regards, > Vincent >=20 > Le dimanche 05 f=E9vrier 2006 =E0 13:14 +0100, JORDI PALET MARTINEZ a > =E9crit : > > I don't agree. > > > > If you do so, you break one of the principles of Teredo, and then = you do > not > > longer need an IANA assigned prefix. > > > > The idea is to ensure that all the Teredo clients can talk = peer-to-peer. > > > > Regards, > > Jordi > > > > > > > > > > > De: Vincent Jardin > > > Organizaci=F3n: http://www.6wind.com/ > > > Responder a: > > > Fecha: Sun, 05 Feb 2006 13:01:58 +0100 > > > Para: haofeng Zhang > > > CC: Christian Huitema , > "v6ops@ops.ietf.org" > > > > > > Asunto: Re: Teredo spec has been published! > > > > > > Le dimanche 05 f=E9vrier 2006 =E0 10:56 +0800, haofeng Zhang a = =E9crit : > > >> Great News. > > >> I am expecting the next version of Windows will support Teredo > service > > >> proposed by RFC4380. > > >> Also, I think it will be more flexible if a Teredo Client accepts = any > > >> reasonable global IPv6 prefix, not only 2001:0000::/32 defined in = the > > >> sepcification. > > > > > > Yes, it would be very usefull with we can configure the Teredo = prefix > on > > > the next update of Windows, instead of having a hard-coded > > > 2001:0000::/32. > > > > > > Regards, > > > Vincent > > > > > >> > > >> > > >> 2006/2/4, Christian Huitema : > > >> The Teredo spec has been published as an individual > > >> submission: > > >> > > >> RFC4380 > > >> Teredo: Tunneling IPv6 over UDP through Network > > >> Address > > >> Translations (NATs) > > >> C. Huitema February 2006 ASCII > > >> PROPOSED STANDARD > > >> > > >> Thanks to the many NGTRANS and V6OPS working group = members > who > > >> reviewed > > >> the spec! > > >> > > >> -- Christian Huitema > > >> > > >> > > >> > > >> > > >> -- > > >> Best regards, > > >> Zhang haofeng > > > > > > > > > > > > > > > > ********************************************** > > The IPv6 Portal: http://www.ipv6tf.org > > > > Barcelona 2005 Global IPv6 Summit > > Slides available at: > > http://www.ipv6-es.com > > > > This electronic message contains information which may be privileged = or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be = aware > that any disclosure, copying, distribution or use of the contents of = this > information, including attached files, is prohibited. > > > > > > > > > > >=20 From owner-v6ops@ops.ietf.org Mon Feb 06 14:38:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6CCE-0003wh-FW for v6ops-archive@megatron.ietf.org; Mon, 06 Feb 2006 14:38:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15789 for ; Mon, 6 Feb 2006 14:37:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6CBU-000ADA-UK for v6ops-data@psg.com; Mon, 06 Feb 2006 19:38:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE,SPF_PASS autolearn=ham version=3.1.0 Received: from [66.249.82.193] (helo=xproxy.gmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6CBT-000ACx-Pw for v6ops@ops.ietf.org; Mon, 06 Feb 2006 19:38:00 +0000 Received: by xproxy.gmail.com with SMTP id s10so1035184wxc for ; Mon, 06 Feb 2006 11:37:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Ighwc4oog0FAL0LffzEHjwxJLhyYMJDs5AqxGZkZiAGTbolIAJrdQf9LeYxcwSp90i5ixnjkO/Fk3iWwLtZAzOk9uxwfilc7dJSR/4YdCpGeQMc15RqUnnxrXhmcqF8aJ7iFiMpsrSc4/RZlf3ZDjPS7QUYtXuzsEXUyJnNzDxo= Received: by 10.70.86.8 with SMTP id j8mr6284783wxb; Mon, 06 Feb 2006 11:37:58 -0800 (PST) Received: by 10.70.8.7 with HTTP; Mon, 6 Feb 2006 11:37:58 -0800 (PST) Message-ID: <77ead0ec0602061137w212a8965u4e2dd834aab51f33@mail.gmail.com> Date: Mon, 6 Feb 2006 11:37:58 -0800 From: Vishwas Manral To: Brian E Carpenter , v6ops@ops.ietf.org, Bora Akyol Subject: Re: Flow label and its uses In-Reply-To: <77ead0ec0602061127x3c0df2f8x95a23323d73cc853@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9593_23385017.1139254678703" References: <77ead0ec0602061127x3c0df2f8x95a23323d73cc853@mail.gmail.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk ------=_Part_9593_23385017.1139254678703 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I agree totally with Brian. I had sent a mail regarding the same earlier, but it somehow dissappeared in transit. That said,we could use it either as normal selectors and signal it using IK= E or as DSCP and not signal it using IKE. Thanks, Vishwas =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Brian said=3D> > > As the flow label spec says (RFC 3697, section 5.1), you can > trust the flow label just as much as you can trust the source > > and destination addresses - exactly the same attackers can forge > any of them. As Spencer and Thomas have pointed out, it's too > expensive to check an authenticator at each hop, and the hops > cannot know the relevant keys anyway. > > > So, you can use the address pair and flow label for classification, > just as safely (or dangerously) as you can use the address pair > and the DSCP. There's no impact on the applicable threats. > A MITM can change any of them. > > > The key difference from the DSCP in this regard is only that the > DSCP is defined as mutable at domain boundaries and the flow > label is defined as immutable. In both cases, you can't detect > if someone breaks those rules. That constrains the use cases - > > erroneous usage mustn't change the basic semantics of unreliable > datagram delivery to the intended destination. RFC 2474 and > RFC 3697 both assume this - i.e. the added threat is theft > of QoS. > > In a connectionless datagram network, it seems impossible to > > do better. > > Brian > > Bora Akyol wrote: > > Flow label is not a field that is protected by IPSEC > hence I do not think you can use > this as a selector. > > Unless you do modifications to IKEv2, you can not also let > the other end know what exactly the SP (security policy) > > is based on. > > Frankly, use of flow label as a selector would be a hack > to get around the problem of the full security policy lookup > in IPSEC at high speeds. The truth is that this has not > been a problem for at least 4-5 years now as long > > as the selectors themselves are TCAM friendly. > > Bora > > > > -----Original Message----- > > From: Vishwas Manral [ mailto:Vishwas@sinett.com ] Se= nt: > Tuesday, January 31, 2006 2:08 AM > > To: Bora Akyol; Spencer Dawkins; v6ops@ops.ietf.org > Subject: RE: Flow label and its uses > > Bora, > > > Does this mean that you are using the flow label in lieu of the regular > IPSEC SP match? > > All I am saying is just as we can have local and remote ports as > selectors; we can instead use Flow Labels along with the IP addresses for > the same purpose, if some assumptions can be made for the flow label. > > Is my understanding wrong? > > Thanks, > Vishwas > > ------=_Part_9593_23385017.1139254678703 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi,

I agree totally with Brian. I had sent a mail regarding the same earlier, b= ut it somehow dissappeared in transit.

That said,we could use it either as normal selectors and signal it using IK= E or as DSCP and not signal it using IKE.

Thanks,
Vishwas
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Brian said=3D>

As the flow label spec says (RFC 3697, =
section=20
5.1), you can
trust the flow label just as much as you can trust the sou=
rce

and destination addresses - exactly the same attackers can forge=

any of them. As Spencer and Thomas have pointed out, it's too
expens=
ive to check an authenticator at each hop, and the hops

cannot know the relevant keys anyway.


So, you can use the ad=
dress pair and flow label for classification,
just as safely (or dangero=
usly) as you can use the address pair
and the DSCP. There's no impact on=
 the applicable threats.

A MITM can change any of them.


The key difference from the D=
SCP in this regard is only that the
DSCP is defined as mutable at domain=
 boundaries and the flow
label is defined as immutable. In both cases, y=
ou can't detect

if someone breaks those rules. That constrains the use cases -

e=
rroneous usage mustn't change the basic semantics of unreliable
datagram=
 delivery to the intended destination. RFC 2474 and
RFC 3697 both assume=
 this -=20
i.e. the added threat is theft
of QoS.

In a connectionless datagr=
am network, it seems impossible to

do better.

   Brian
Bora Akyol wrote:

Flow label is not a field that is protected by =
IPSEC
hence I do not think you can use
this as a selector.

Unl=
ess you do modifications to IKEv2, you can not also let
the other end kn=
ow what exactly the SP (security policy)


is based on.

Frankly, use of flow label as a selector would =
be a hack
to get around the problem of the full security policy lookupin IPSEC at high speeds. The truth is that this has not
been a problem=
 for at least 4-5 years now as long


as the selectors themselves are TCAM friendly.

Bora

<=
br>

-----Original Message-=
----
From: Vishwas Manral [ mailto:Vishwas@sinett.com]=20Sent: Tuesday, January 31, 2006 2:08 AM
To: Bora Akyol; Spencer Dawkins; v6ops@ops.ietf.org
Subject: RE: Flow =
label and its uses


Bora,
Does this mean that you are using the flow label in lieu of the=20regular IPSEC SP match?
All I am saying is just as we can have local and remo= te ports=20as selectors; we can instead use Flow Labels along with the=20IP addresses for the same purpose, if some assumptions can be=20made for the flow label.=20
Is my understanding wrong?

Thanks,<=
br>Vishwas

------=_Part_9593_23385017.1139254678703-- From owner-v6ops@ops.ietf.org Mon Feb 06 14:42:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6CFr-0004tH-0m for v6ops-archive@megatron.ietf.org; Mon, 06 Feb 2006 14:42:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16118 for ; Mon, 6 Feb 2006 14:40:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6CFP-000AeS-VM for v6ops-data@psg.com; Mon, 06 Feb 2006 19:42:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6CFO-000Adn-LQ for v6ops@ops.ietf.org; Mon, 06 Feb 2006 19:42:02 +0000 Received: from [10.10.10.11] by consulintel.es (MDaemon.PRO.v8.0.1.R) with ESMTP id md50001609774.msg for ; Mon, 06 Feb 2006 20:41:19 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 06 Feb 2006 20:41:40 +0100 Subject: Re: Teredo spec has been published! From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" , Dave Thaler , Vincent Jardin Message-ID: Thread-Topic: Teredo spec has been published! Thread-Index: AcYqXXwUB0+19ewcSP6z5mXwXeVDmgA9Q90AAACzfNM= In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1158BCFCF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060206:v6ops@ops.ietf.org::oztv3y80IUAcDmgI:00000000000000000000000000000000000000000004CLy X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Mon, 06 Feb 2006 20:41:26 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thanks Dave, That's a good option (instead of needing a hack for those that want to make use of a different prefix for an experiment). The point is still that will be good to know if there are any specific transition plans from Microsoft, so we can all try to coordinate ... Regards, Jordi > De: Dave Thaler > Responder a: > Fecha: Mon, 6 Feb 2006 11:23:16 -0800 > Para: Vincent Jardin , > CC: > Conversaci=F3n: Teredo spec has been published! > Asunto: RE: Teredo spec has been published! >=20 > I'm told by the devs that the prefix is already configurable on Windows XP. >=20 > The Teredo prefix can be configured by adding/altering the following REG_DWORD > value:=20 > \HKLM\System\CurrentControlSet\Services\Tcpip6\Parameters\GlobalParams\TeredoP > refix. The DWORD value is interpreted as a 32 bit prefix, in network byte > order. >=20 > -Dave >=20 >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf >> Of Vincent Jardin >> Sent: Sunday, February 05, 2006 6:03 AM >> To: jordi.palet@consulintel.es >> Cc: v6ops@ops.ietf.org >> Subject: Re: Teredo spec has been published! >>=20 >> Jordi, >>=20 >> Even if you remove the constraint on the hard-coded prefix, the Teredo >> clients "can talk peer-to-peer"; it does not break any compatibility, >> please can you explain why it would be broken ? >>=20 >> The requirement of being able to configure the Teredo prefix is: >> - control the transition from the previous prefix to the new one, >> - be able to support some private usages of the Teredo prefix >> (development, testing, etc.). >>=20 >> I don't say that 2001:0000::/32 should not be the default value, as >> recommended by the IANA, but it should be configure-able. It is more a >> implementation constraint rather than a standardization constraint. >>=20 >> Regards, >> Vincent >>=20 >> Le dimanche 05 f=E9vrier 2006 =E0 13:14 +0100, JORDI PALET MARTINEZ a >> =E9crit : >>> I don't agree. >>>=20 >>> If you do so, you break one of the principles of Teredo, and then you do >> not >>> longer need an IANA assigned prefix. >>>=20 >>> The idea is to ensure that all the Teredo clients can talk peer-to-peer. >>>=20 >>> Regards, >>> Jordi >>>=20 >>>=20 >>>=20 >>>=20 >>>> De: Vincent Jardin >>>> Organizaci=F3n: http://www.6wind.com/ >>>> Responder a: >>>> Fecha: Sun, 05 Feb 2006 13:01:58 +0100 >>>> Para: haofeng Zhang >>>> CC: Christian Huitema , >> "v6ops@ops.ietf.org" >>>> >>>> Asunto: Re: Teredo spec has been published! >>>>=20 >>>> Le dimanche 05 f=E9vrier 2006 =E0 10:56 +0800, haofeng Zhang a =E9crit : >>>>> Great News. >>>>> I am expecting the next version of Windows will support Teredo >> service >>>>> proposed by RFC4380. >>>>> Also, I think it will be more flexible if a Teredo Client accepts any >>>>> reasonable global IPv6 prefix, not only 2001:0000::/32 defined in the >>>>> sepcification. >>>>=20 >>>> Yes, it would be very usefull with we can configure the Teredo prefix >> on >>>> the next update of Windows, instead of having a hard-coded >>>> 2001:0000::/32. >>>>=20 >>>> Regards, >>>> Vincent >>>>=20 >>>>>=20 >>>>>=20 >>>>> 2006/2/4, Christian Huitema : >>>>> The Teredo spec has been published as an individual >>>>> submission: >>>>>=20 >>>>> RFC4380 >>>>> Teredo: Tunneling IPv6 over UDP through Network >>>>> Address >>>>> Translations (NATs) >>>>> C. Huitema February 2006 ASCII >>>>> PROPOSED STANDARD >>>>>=20 >>>>> Thanks to the many NGTRANS and V6OPS working group members >> who >>>>> reviewed >>>>> the spec! >>>>>=20 >>>>> -- Christian Huitema >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Best regards, >>>>> Zhang haofeng >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> ********************************************** >>> The IPv6 Portal: http://www.ipv6tf.org >>>=20 >>> Barcelona 2005 Global IPv6 Summit >>> Slides available at: >>> http://www.ipv6-es.com >>>=20 >>> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From goij200@yahoo.co.jp Tue Feb 07 03:31:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6OFg-0005Zq-Ri for v6ops-archive@megatron.ietf.org; Tue, 07 Feb 2006 03:31:08 -0500 Received: from ocn.co.jp ([221.212.59.76]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03011 for ; Tue, 7 Feb 2006 03:29:10 -0500 (EST) Date: Tue, 7 Feb 2006 03:29:10 -0500 (EST) Message-Id: <200602070829.DAA03011@ietf.org> Received: from hcteuuvlke6 (unknown [32.92.234.12]) by smtp6 (Coremail) with SMTP id hOvoHKf1XUxCkl0Y.1 for ; Tue, 04 Mar 2003 01:16:47 +0800 (CST) X-Originating-IP: [32.92.234.12] Subject: =?iso-2022-jp?B?KH5vfikbJEIkNDNORycyPCQ1JCQhKiEqGyhC?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C2DD98.18D6E820" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C2DD98.18D6E820 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCNS5FQiRPS1xFUE8/JEokNSRsJEYkJCReJDskcyEjJDMkTiReJF4kRyQ5JEg1VTFnPXVCUD5d JEskSiRqJF4kOyRzJE4kR0IuJGQkKyRLS1xFUE8/JHIkKjpRJF4kOzI8JDUkJCEjGyhCDQpodHRw Oi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5MjkNCg0KGyRCIiM1LkVCO1hEajh9OkI/Njl+ JF8yREc9JEo9d0AtQj8/dCRHJDkbKEIgGyRCIiMxZz11NmJAaEonJCQ2ZDlUPzY5fjJERz0lNyU5 JUYlYEVrOlwbKEINChskQjg9Ol8hShsoQjIwMDYtMDEbJEIhSyRONVUxZz11QWo+bCRPGyhCOC41 GyRCS3wxXyFBGyhCMTUuNhskQkt8MV8kSCRKJEMkRiQqJGokXiQ5ISMbKEINClBDIBskQjdIQlMh Ik14TVEyREc9JEckOSEjGyhCDQobJEIkXiQ6JE8/NzUsTDVOQUVQTz8kKyRpJCo0aiQkQ1ckNyRe JDkhIxsoQg0KDQpodHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5MjkNCg0KPBskQjUu PXckTiVVJSclaSVGJS8kXyQ7JEYyPCQ1JCQhZBsoQg0KIA0KGyRCIVolVSUnJWk8K0t9PXdALUpn PTghWxsoQg0KGyRCJVUlJyVpOSUkLSRONS49dyRLJEgkQyRGOkc5YiROPVAycSQkJE4+bD1qJEck OSEqGyhCDQobJEI6IyRKJGlCdDszJE5DS0AtIWEhSiQqJEEkcyRBJHMhSyRyQSokU0p8QmokRyQ5 ISobKEINChskQjUuPXckTiVVJSclaSVGJS8lSyVDJS8kcjtXJCZCOEosQUc/TUNLQC0kSztuJDck RiRfJEYyPCQ1JCQhIxsoQg0KGyRCJCokQSRzJEEkc0M1JDckTzojRD4kMCRLJEckYiEqGyhCDQpo dHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5MjkNCg0KGyRCIVolVSUnJWk5JSQtJEpD S0AtPTgkXiRsISohWxsoQg0KIA0KGyRCIXtDS0AtRVBPPyRiJCpCVCRBJDckRiQqJGokXiQ5ISMb KEINChskQiF7Q0tALSROSn0kT0w1TkEkR0VQTz9EOiQxJF4kOSEjGyhCDQpodHRwOi8vYXdnLndl YmNodS5jb20vY2FzYW5vdmEvPzE5MjkNCg0KIA0KDQoNCiANCg0KDQobJEI6IzJzNj1MIyQsQTQk L0w1JCRKfSEiJWEhPCVrSVRNVyROSn0kTyQzJEEkaSRLJWEhPCVrJHIiLRsoQg0KY29uY2VwdDJf bmV0QHlhaG9vLmNh ------=_NextPart_000_0006_01C2DD98.18D6E820 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiPjxGT05U IHNpemU9Mj4NCjxESVY+GyRCNS5FQiRPS1xFUE8/JEokNSRsJEYkJCReJDskcyEjJDMkTiReJF4k RyQ5JEg1VTFnPXVCUD5dJEskSiRqJF4kOyRzJE4kR0IuJGQkKyRLS1xFUE8/JHIkKjpRJF4kOzI8 JDUkJCEjGyhCPEJSPjxBIA0KaHJlZj0iaHR0cDovL2F3Zy53ZWJjaHUuY29tL2Nhc2Fub3ZhLz8x OTI5Ij5odHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5Mjk8L0E+PC9ESVY+DQo8RElW PjxCUj4bJEIiIzUuRUI7WERqOH06Qj82OX4kXzJERz0kSj13QC1CPz90JEckORsoQiANChskQiIj MWc9dTZiQGhKJyQkNmQ5VD82OX4yREc9JTclOSVGJWBFazpcGyhCPEJSPhskQjg9Ol8hShsoQjIw MDYtMDEbJEIhSyRONVUxZz11QWo+bCRPGyhCOC41GyRCS3wxXyFBGyhCMTUuNhskQkt8MV8kSCRK JEMkRiQqJGokXiQ5ISMbKEI8QlI+UEMgDQobJEI3SEJTISJNeE1RMkRHPSRHJDkhIxsoQjxCUj4b JEIkXiQ6JE8/NzUsTDVOQUVQTz8kKyRpJCo0aiQkQ1ckNyReJDkhIxsoQjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+PEEgDQpocmVmPSJodHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5v dmEvPzE5MjkiPmh0dHA6Ly9hd2cud2ViY2h1LmNvbS9jYXNhbm92YS8/MTkyOTwvQT48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT0bJEJBV0JOGyhCPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+Jmx0 OxskQjUuPXckTiVVJSclaSVGJS8kXyQ7JEYyPCQ1JCQhZBsoQjxCUj4mbmJzcDs8QlI+GyRCIVol VSUnJWk8K0t9PXdALUpnPTghWxsoQjxCUj4bJEIlVSUnJWk5JSQtJE41Lj13JEskSCRDJEY6Rzli JE49UDJxJCQkTj5sPWokRyQ5ISobKEI8QlI+GyRCOiMkSiRpQnQ7MyROQ0tALSFhIUokKiRBJHMk QSRzIUskckEqJFNKfEJqJEckOSEqGyhCPEJSPhskQjUuPXckTiVVJSclaSVGJS8lSyVDJS8kcjtX JCZCOEosQUc/TUNLQC0kSztuJDckRiRfJEYyPCQ1JCQhIxsoQjxCUj4bJEIkKiRBJHMkQSRzQzUk NyRPOiNEPiQwJEskRyRiISobKEI8QlI+PEEgDQpocmVmPSJodHRwOi8vYXdnLndlYmNodS5jb20v Y2FzYW5vdmEvPzE5MjkiPmh0dHA6Ly9hd2cud2ViY2h1LmNvbS9jYXNhbm92YS8/MTkyOTwvQT48 L0RJVj4NCjxESVY+PEJSPhskQiFaJVUlJyVpOSUkLSRKQ0tALT04JF4kbCEqIVsbKEI8QlI+Jm5i c3A7PEJSPhskQiF7Q0tALUVQTz8kYiQqQlQkQSQ3JEYkKiRqJF4kOSEjGyhCPEJSPhskQiF7Q0tA LSROSn0kT0w1TkEkR0VQTz9EOiQxJF4kOSEjGyhCPEJSPjxBIA0KaHJlZj0iaHR0cDovL2F3Zy53 ZWJjaHUuY29tL2Nhc2Fub3ZhLz8xOTI5Ij5odHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEv PzE5Mjk8L0E+PC9ESVY+DQo8RElWPjxCUj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPjxCUj4mbmJzcDs8L0RJVj48L0ZPTlQ+PC9GT05UPg0KPERJVj48Rk9OVCBmYWNlPSJN UyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 Ik1TIFVJIEdvdGhpYyI+PEJSPjxGT05UIA0Kc2l6ZT0yPhskQjojMnM2PUwjJCxBNCQvTDUkJEp9 ISIlYSE8JWtJVE1XJE5KfSRPJDMkQSRpJEslYSE8JWskciItGyhCPEJSPjwvRk9OVD48Rk9OVCBz aXplPTI+PEEgDQpocmVmPSJtYWlsdG86Y29uY2VwdDJfbmV0QHlhaG9vLmNhIj5jb25jZXB0Ml9u ZXRAeWFob28uY2E8L0E+PC9GT05UPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0006_01C2DD98.18D6E820-- From owner-v6ops@ops.ietf.org Tue Feb 07 19:58:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6dfP-0008Id-HV for v6ops-archive@megatron.ietf.org; Tue, 07 Feb 2006 19:58:45 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21175 for ; Tue, 7 Feb 2006 19:57:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6dbg-00088v-PK for v6ops-data@psg.com; Wed, 08 Feb 2006 00:54:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.31.210.19] (helo=MMS3.broadcom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6dbe-00088k-8d for v6ops@ops.ietf.org; Wed, 08 Feb 2006 00:54:50 +0000 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 07 Feb 2006 16:54:39 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 8D3EA2AF; Tue, 7 Feb 2006 16:54:39 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 76E452AE; Tue, 7 Feb 2006 16:54:39 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id CWM59599; Tue, 7 Feb 2006 16:54:37 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id C4B5B20501; Tue, 7 Feb 2006 16:54:37 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Teredo spec has been published! Date: Tue, 7 Feb 2006 16:54:37 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36358833@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: Teredo spec has been published! Thread-Index: AcYqx4tdn6gNGuHXRq+yC4Ldp/a6qABgljOQ From: "Bora Akyol" To: "haofeng Zhang" , "Christian Huitema" cc: v6ops@ops.ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006020709; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230352E34334539334638362E303030382D412D; ENG=IBF; TS=20060208005440; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006020709_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FF79EC541W8371685-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I think it would be bad if the Teredo prefix was announced via eBGP. Each domain is supposed to announce the Teredo prefix within the domain, not outside, if I understood it correctly. I would also expect each AS to filter out the announced prefix. Bora =20 ---------------------------------------------------------- =20 This problem, for example, 1. Based on current Teredo spec, the core router in an IPv6 network shall advertise 2001:0000::/32 route through BGP4+ to other ASes, to ensure the connectivity of its own Teredo users. Also, I think it's better for the core router to also act as a Teredo relay router, otherwise too many static routes have to be configured. But how can we expect the IPv6 core router to have the native IPv4 connection?=20 =20 From owner-v6ops@ops.ietf.org Tue Feb 07 21:36:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6fBv-0005Z6-Rv for v6ops-archive@megatron.ietf.org; Tue, 07 Feb 2006 21:36:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05312 for ; Tue, 7 Feb 2006 21:34:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6f9j-000Fey-DB for v6ops-data@psg.com; Wed, 08 Feb 2006 02:34:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE,SPF_PASS autolearn=ham version=3.1.0 Received: from [66.249.82.201] (helo=xproxy.gmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6f9i-000Fem-I2 for v6ops@ops.ietf.org; Wed, 08 Feb 2006 02:34:06 +0000 Received: by xproxy.gmail.com with SMTP id s10so1345720wxc for ; Tue, 07 Feb 2006 18:34:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=StJILNfV7T6WPCCJfit6DgoZr+4Rf08ycRtT37/rZysddbsgEQtS8eL4IHoWfdAMjPUQliHhjCfZjZfaMmvDuwd+qd6iFPGaJwxAJl8rUlQN7Jx6ezgnvmE53n6TBMf1P6g232PIU67gjciXOZVFXPPzQ2BExvXD5qq0rI1Wh4U= Received: by 10.70.45.14 with SMTP id s14mr8296888wxs; Tue, 07 Feb 2006 18:34:04 -0800 (PST) Received: by 10.70.39.20 with HTTP; Tue, 7 Feb 2006 18:34:04 -0800 (PST) Message-ID: Date: Wed, 8 Feb 2006 10:34:04 +0800 From: haofeng Zhang To: Bora Akyol , v6ops@ops.ietf.org Subject: Re: Teredo spec has been published! In-Reply-To: <03235919BBDE634289BB6A0758A20B36358833@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_561_23466825.1139366044343" References: <03235919BBDE634289BB6A0758A20B36358833@NT-SJCA-0751.brcm.ad.broadcom.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk ------=_Part_561_23466825.1139366044343 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Bora, I think every AS which has Teredo users should announce Teredo prefix via eBGP. Only by this way an IPv6 node can find the closest path to a Teredo client. Within the domain, the eBGP router can use other routing protocol to ensure the traffic destinated to Teredo client can reach Teredo relay router. Haofeng Zhang 2006/2/8, Bora Akyol : > > I think it would be bad if the Teredo prefix was announced via eBGP. > Each domain is supposed to announce > the Teredo prefix within the domain, not outside, if I understood it > correctly. I would also expect > each AS to filter out the announced prefix. > > Bora > > ---------------------------------------------------------- > > > This problem, for example, > 1. Based on current Teredo spec, the core router in an IPv6 > network shall advertise 2001:0000::/32 route through BGP4+ to other > ASes, to ensure the connectivity of its own Teredo users. Also, I think > it's better for the core router to also act as a Teredo relay router, > otherwise too many static routes have to be configured. But how can we > expect the IPv6 core router to have the native IPv4 connection? > > > ------=_Part_561_23466825.1139366044343 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi Bora,

I think every AS which has Teredo users should announce Teredo prefix = via eBGP.

Only by this way an IPv6 node can find the closest path to a Teredo cl= ient.

Within the domain, the eBGP router can use other routing protocol to e= nsure the traffic destinated to Teredo client can reach Teredo relay r= outer.

Haofeng Zhang

2006/2/8, Bora Akyol <bora@broadcom.com>:=20

I think it would be bad if the T= eredo prefix was announced via eBGP.
Each domain is supposed to announce= =20
the Teredo prefix within the domain, not outside, if I understood itcorrectly. I would also expect
each AS to filter out the announced pref= ix.

Bora

----------------------------------------------------= ------=20

This problem, for example,=
1. Based on current Teredo spec, t= he core router in an IPv6
network shall advertise 2001:0000::/32 route t= hrough BGP4+ to other
ASes, to ensure the connectivity of its own Teredo= users. Also, I think=20
it's better for the core router to also act as a Teredo relay router,otherwise too many static routes have to be configured. But how can = we
expect the IPv6 core router to have the native IPv4 connection?=

------=_Part_561_23466825.1139366044343-- From owner-v6ops@ops.ietf.org Tue Feb 07 22:56:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6gQy-0000cd-Tm for v6ops-archive@megatron.ietf.org; Tue, 07 Feb 2006 22:56:07 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09853 for ; Tue, 7 Feb 2006 22:54:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6gOt-000LNs-Ax for v6ops-data@psg.com; Wed, 08 Feb 2006 03:53:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F6gOs-000LNg-QV for v6ops@ops.ietf.org; Wed, 08 Feb 2006 03:53:50 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 7 Feb 2006 19:53:50 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Feb 2006 19:53:50 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Feb 2006 19:53:49 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Feb 2006 19:53:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Teredo spec has been published! Date: Tue, 7 Feb 2006 19:53:44 -0800 Message-ID: In-Reply-To: Thread-Topic: Teredo spec has been published! thread-index: AcYsWNWpW7IPAg6oTpKSVaysviG4WQACeQvw From: "Christian Huitema" To: "haofeng Zhang" , "Bora Akyol" , X-OriginalArrivalTime: 08 Feb 2006 03:53:49.0550 (UTC) FILETIME=[44DF30E0:01C62C63] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I think every AS which has Teredo users should announce Teredo prefix via eBGP. > Only by this way an IPv6 node can find the closest path to a Teredo client. The spec is purposely vague. May decide to announce reachability of the Teredo prefix in eBGP/IPv6, but they should obviously only do so if they are ready to accept and relay teredo traffic. This will be very similar to announcing the 6to4 relay prefix in eBPG/IPv4, and probably requires the same kind of logistics. -- Christian Huitema From necojp@citiz.net Wed Feb 08 01:56:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6jFk-0005wz-KW for v6ops-archive@megatron.ietf.org; Wed, 08 Feb 2006 01:56:36 -0500 Received: from ocn.ne.jp ([221.212.59.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21664 for ; Wed, 8 Feb 2006 01:54:45 -0500 (EST) Date: Wed, 8 Feb 2006 01:54:45 -0500 (EST) Message-Id: <200602080654.BAA21664@ietf.org> Received: from guembep2 (unknown [207.85.147.123]) by smtp0 (Coremail) with SMTP id 44AXc7egjVjWw3Up.1 for ; Wed, 08 Feb 2006 15:54:56 +0800 (CST) X-Originating-IP: [207.85.147.123] Subject: =?iso-2022-jp?B?GyRCSFZBSCROJCpDTiRpJDsbKEI=?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: text/plain; Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: base64 GyRCQn46IyVsJUclIyUzJV8hIj13QC1AbE1RJSIlQCVrJUg7KDtvRXkkSzdHOlwkNyRGJCokaj83 NSw9d0AtMnEwd01NJCw1XkF9JDckRiQqJGohIhsoQg0KGyRCJD0kTiQ/JGFDS0AtMnEwd01NRVBP PyUtJWMlcyVaITwlcyRyJCokMyRKJEMkRiQqJGokXiQ5ISMbKEJodHRwOi8vYXdnLndlYmNodS5j b20vY2FzYW5vdmEvPzE5MzUNCg0KGyRCQn46Iz83NSxDS0AtMnEwd01NJEskTzR7QjgkTkNLQC0y cTB3JEtNJUBoRSokSz83NSw9d0AtMnEwd01NJHIkND5SMnAkNyRGJCokaiReJDkhIxsoQg0KGyRC JS0lYyVzJVohPCVzQ2YkTz83NSwkTj13QC0ycTB3JEskTz83NSwkTkNLQC0ycTB3JE4kXyROJSIl LyU7JTkkSCRKJGokXiQ5ISMbKEINCg0KDQoNCg0KGyRCJWEhPCVrSVRNVyROSn0kTyQzJEEkaSRL JWEhPCVrJHIiLRsoQg0KY29uY2VwdDNfbmV0QHlhaG9vLmNhDQoNCg== From necojp@citiz.net Wed Feb 08 18:48:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6z37-0006bv-2s for v6ops-archive@megatron.ietf.org; Wed, 08 Feb 2006 18:48:37 -0500 Received: from ocn.ne.jp ([221.212.58.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17802 for ; Wed, 8 Feb 2006 18:46:34 -0500 (EST) Date: Wed, 8 Feb 2006 18:46:34 -0500 (EST) Message-Id: <200602082346.SAA17802@ietf.org> Received: from lotzrtmi7 (unknown [236.227.172.238]) by smtp42 (Coremail) with SMTP id LlyLKgkD2ASTBgSb.1 for ; Wed, 05 Mar 2003 16:36:32 +0800 (CST) X-Originating-IP: [236.227.172.238] Subject: =?iso-2022-jp?B?GyRCS1xGfCReJEckRyQ5JCwhIiQkJCskLCQkJD8kNyReJDckZyQmGyhC?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: base64 GyRCIihNLTh6NHw4QkZ8JEckOSIoGyhCDQobJEIkKk1CJCskaiROGyhCMjAbJEJLfDFfJE48dTxo NHw4QkZ8JCxLXEZ8JEgkSiRDJEYkKiRqJF4kOSEjQmc7ajVeJDMkQSRpJGgkaiQqPHUkMTxoJGoy PCQ1JCQhIxsoQg0KDQpodHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5MjENCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNChskQiVhITwla0lUTVckSkp9JE8k MyRBJGkiLRsoQg0KDQpjb25jZXB0M19uZXRAeWFob28uY2ENCg0K From oi053060@yahoo.co.jp Wed Feb 08 23:11:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F739X-0003cc-6D for v6ops-archive@megatron.ietf.org; Wed, 08 Feb 2006 23:11:31 -0500 Received: from ocn.ne.jp ([221.212.57.186]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12574 for ; Wed, 8 Feb 2006 23:09:33 -0500 (EST) Date: Wed, 8 Feb 2006 23:09:33 -0500 (EST) Message-Id: <200602090409.XAA12574@ietf.org> Received: from mphhjed1 (unknown [226.101.188.170]) by smtp85 (Coremail) with SMTP id 5Tda0no2XiAT717p.1 for ; Sat, 01 Feb 2003 22:08:29 +0800 (CST) X-Originating-IP: [226.101.188.170] Subject: =?iso-2022-jp?B?GyRCRn4kbD8pJCQhIkZ+JGw/KSQkGyhC?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C2C966.983A9B20" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C2C966.983A9B20 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCIioiKkQ+JSIlSThyNDkyREc9ISpMNU5BJTUlJCVINDBBNEApR0YhKkw1TkEkRzJxJCgkSiQt JGNCOyRAJGgkTSEqISoiKyIrGyhCDQoNChskQiF6IXo/TTUkRVklSiVzJVAhPCMxIXohehsoQg0K GyRCISohKiQ5JDAkSyRkJGokPyQkJEokaSQzJDMkNyQrJEokJCRHJDckZyEqISobKEINChskQiEh ISEbKEJodHRwOi8vd3d3LmF3ZzUubmV0Lz8yMDA2DQoNChskQiEhRD4lIiVJOHI0OSRHJC0kayQr JGkhIkZ+JGw/KSQkPnVCViEqGyhCDQobJEIlYSE8JWs4cjQ5JEckLSRKJCQ7UiRPTDU7ayQ5JGsk QCQxJEcjTyNLISobKEINCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQobJEI1cUhdISEbKEJwcmlvcml0 eTdfbmV0QHlhaG9vLmNhDQoNCg== ------=_NextPart_000_0006_01C2C966.983A9B20 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgDQpmYWNlPSJNUyBVSSBHb3Ro aWMiPhskQiIqIipEPiUiJUk4cjQ5MkRHPSEqTDVOQSU1JSQlSDQwQTRAKUdGISpMNU5BJEcycSQo JEokLSRjQjskQCRoJE0hKiEqIisiKxsoQjxCUj48QlI+GyRCIXohej9NNSRFWSVKJXMlUCE8IzEh eiF6GyhCPEJSPhskQiEqISokOSQwJEskZCRqJD8kJCRKJGkkMyQzJDckKyRKJCQkRyQ3JGchKiEq GyhCPEJSPhskQiEhISEbKEI8QSANCmhyZWY9Imh0dHA6Ly93d3cuYXdnNS5uZXQvPzIwMDYiPmh0 dHA6Ly93d3cuYXdnNS5uZXQvPzIwMDY8L0E+PEJSPjxCUj4bJEIhIUQ+JSIlSThyNDkkRyQtJGsk KyRpISJGfiRsPykkJD51QlYhKhsoQjxCUj4bJEIlYSE8JWs4cjQ5JEckLSRKJCQ7UiRPTDU7ayQ5 JGskQCQxJEcjTyNLISobKEI8QlI+PC9GT05UPjxGT05UIA0KZmFjZT0iTVMgVUkgR290aGljIj48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6ZT0y PjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhp YyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6 ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdv dGhpYyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQg c2l6ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJ IEdvdGhpYyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6ZT0yPhskQjVxSF0hIRsoQjxBIA0KaHJl Zj0ibWFpbHRvOnByaW9yaXR5N19uZXRAeWFob28uY2EiPnByaW9yaXR5N19uZXRAeWFob28uY2E8 L0E+PEEgDQpocmVmPSJtYWlsdG86Y29uY2VwdF9uZXRAeWFob28uY2EiPjwvQT48L0ZPTlQ+PC9E SVY+DQo8RElWPjxCUj48L0RJVj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0006_01C2C966.983A9B20-- From oi053060@yahoo.co.jp Thu Feb 09 09:49:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7D6V-0007PE-Ah for v6ops-archive@megatron.ietf.org; Thu, 09 Feb 2006 09:49:03 -0500 Received: from ocn.ne.jp ([221.212.57.186]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27352 for ; Thu, 9 Feb 2006 09:46:53 -0500 (EST) Date: Thu, 9 Feb 2006 09:46:53 -0500 (EST) Message-Id: <200602091446.JAA27352@ietf.org> Received: from prsnsc7 (unknown [172.175.124.6]) by smtp68 (Coremail) with SMTP id mGMjgXMlz2a63lMf.1 for ; Sun, 02 Feb 2003 08:45:50 +0800 (CST) X-Originating-IP: [172.175.124.6] Subject: =?iso-2022-jp?B?GyRCRn4kbD8pJCQhIkZ+JGw/KSQkGyhC?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C2C966.983A9B20" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C2C966.983A9B20 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCIioiKkQ+JSIlSThyNDkyREc9ISpMNU5BJTUlJCVINDBBNEApR0YhKkw1TkEkRzJxJCgkSiQt JGNCOyRAJGgkTSEqISoiKyIrGyhCDQoNChskQiF6IXo/TTUkRVklSiVzJVAhPCMxIXohehsoQg0K GyRCISohKiQ5JDAkSyRkJGokPyQkJEokaSQzJDMkNyQrJEokJCRHJDckZyEqISobKEINChskQiEh ISEbKEJodHRwOi8vd3d3LmF3ZzUubmV0Lz8yMDA2DQoNChskQiEhRD4lIiVJOHI0OSRHJC0kayQr JGkhIkZ+JGw/KSQkPnVCViEqGyhCDQobJEIlYSE8JWs4cjQ5JEckLSRKJCQ7UiRPTDU7ayQ5JGsk QCQxJEcjTyNLISobKEINCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQobJEI1cUhdISEbKEJwcmlvcml0 eTdfbmV0QHlhaG9vLmNhDQoNCg== ------=_NextPart_000_0006_01C2C966.983A9B20 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgDQpmYWNlPSJNUyBVSSBHb3Ro aWMiPhskQiIqIipEPiUiJUk4cjQ5MkRHPSEqTDVOQSU1JSQlSDQwQTRAKUdGISpMNU5BJEcycSQo JEokLSRjQjskQCRoJE0hKiEqIisiKxsoQjxCUj48QlI+GyRCIXohej9NNSRFWSVKJXMlUCE8IzEh eiF6GyhCPEJSPhskQiEqISokOSQwJEskZCRqJD8kJCRKJGkkMyQzJDckKyRKJCQkRyQ3JGchKiEq GyhCPEJSPhskQiEhISEbKEI8QSANCmhyZWY9Imh0dHA6Ly93d3cuYXdnNS5uZXQvPzIwMDYiPmh0 dHA6Ly93d3cuYXdnNS5uZXQvPzIwMDY8L0E+PEJSPjxCUj4bJEIhIUQ+JSIlSThyNDkkRyQtJGsk KyRpISJGfiRsPykkJD51QlYhKhsoQjxCUj4bJEIlYSE8JWs4cjQ5JEckLSRKJCQ7UiRPTDU7ayQ5 JGskQCQxJEcjTyNLISobKEI8QlI+PC9GT05UPjxGT05UIA0KZmFjZT0iTVMgVUkgR290aGljIj48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6ZT0y PjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhp YyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6 ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdv dGhpYyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQg c2l6ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJ IEdvdGhpYyI+PEZPTlQgc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9Ik1TIFVJIEdvdGhpYyI+PEZPTlQgc2l6ZT0yPhskQjVxSF0hIRsoQjxBIA0KaHJl Zj0ibWFpbHRvOnByaW9yaXR5N19uZXRAeWFob28uY2EiPnByaW9yaXR5N19uZXRAeWFob28uY2E8 L0E+PEEgDQpocmVmPSJtYWlsdG86Y29uY2VwdF9uZXRAeWFob28uY2EiPjwvQT48L0ZPTlQ+PC9E SVY+DQo8RElWPjxCUj48L0RJVj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0006_01C2C966.983A9B20-- From owner-v6ops@ops.ietf.org Thu Feb 09 15:57:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7IqV-0003eG-UM for v6ops-archive@megatron.ietf.org; Thu, 09 Feb 2006 15:57:02 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29782 for ; Thu, 9 Feb 2006 15:55:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7In0-000I2v-DH for v6ops-data@psg.com; Thu, 09 Feb 2006 20:53:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE,SPF_PASS autolearn=ham version=3.1.0 Received: from [66.249.82.195] (helo=xproxy.gmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7Imz-000I2j-77 for v6ops@ops.ietf.org; Thu, 09 Feb 2006 20:53:17 +0000 Received: by xproxy.gmail.com with SMTP id s6so170055wxc for ; Thu, 09 Feb 2006 12:53:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=a8MC9KXoAmtD5U3ue1nqfWx4KCdGPwe+lTSX3zMJZiLatydIfUI9rZZxcEFaCaB6AAPKYq50U5luIPtd+8H+6JDSO9bbc3uiCp2rWaXSWUAIJck88zICqanEGURDZiDeM+uSi4maOaPKrF4UChUPa08nBh5d1k5TqozUhjHvrS4= Received: by 10.70.10.2 with SMTP id 2mr65wxj; Thu, 09 Feb 2006 12:53:09 -0800 (PST) Received: by 10.70.7.13 with HTTP; Thu, 9 Feb 2006 12:53:08 -0800 (PST) Message-ID: <77ead0ec0602091253l2e039840qcea87c770b852562@mail.gmail.com> Date: Thu, 9 Feb 2006 12:53:08 -0800 From: Vishwas Manral To: Brian E Carpenter , v6ops@ops.ietf.org, Bora Akyol Subject: Re: Flow label and its uses In-Reply-To: <77ead0ec0602061137w212a8965u4e2dd834aab51f33@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8457_18621574.1139518388753" References: <77ead0ec0602061127x3c0df2f8x95a23323d73cc853@mail.gmail.com> <77ead0ec0602061137w212a8965u4e2dd834aab51f33@mail.gmail.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk ------=_Part_8457_18621574.1139518388753 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, It would be good if someone could summarize the discussions about Flow Labe= l in some IETF document. It would be of great help for the community to get over misgivings about th= e use of Flow Label, possible scenarios of where it can be used and its limitations. Thanks, Vishwas On 2/6/06, Vishwas Manral wrote: > > Hi, > > I agree totally with Brian. I had sent a mail regarding the same earlier, > but it somehow dissappeared in transit. > > That said,we could use it either as normal selectors and signal it using > IKE or as DSCP and not signal it using IKE. > > Thanks, > Vishwas > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Brian said=3D> > > > > As the flow label spec says (RFC 3697, section > > 5.1), you can > > trust the flow label just as much as you can trust the source > > > > and destination addresses - exactly the same attackers can forge > > any of them. As Spencer and Thomas have pointed out, it's too > > expensive to check an authenticator at each hop, and the hops > > > > cannot know the relevant keys anyway. > > > > > > So, you can use the address pair and flow label for classification, > > just as safely (or dangerously) as you can use the address pair > > and the DSCP. There's no impact on the applicable threats. > > > > A MITM can change any of them. > > > > > > The key difference from the DSCP in this regard is only that the > > DSCP is defined as mutable at domain boundaries and the flow > > label is defined as immutable. In both cases, you can't detect > > > > if someone breaks those rules. That constrains the use cases - > > > > erroneous usage mustn't change the basic semantics of unreliable > > datagram delivery to the intended destination. RFC 2474 and > > RFC 3697 both assume this - > > i.e. the added threat is theft > > of QoS. > > > > In a connectionless datagram network, it seems impossible to > > > > do better. > > > > Brian > > > > Bora Akyol wrote: > > > > Flow label is not a field that is protected by IPSEC > > hence I do not think you can use > > this as a selector. > > > > Unless you do modifications to IKEv2, you can not also let > > the other end know what exactly the SP (security policy) > > > > > > is based on. > > > > Frankly, use of flow label as a selector would be a hack > > to get around the problem of the full security policy lookup > > in IPSEC at high speeds. The truth is that this has not > > been a problem for at least 4-5 years now as long > > > > > > as the selectors themselves are TCAM friendly. > > > > Bora > > > > > > > > -----Original Message----- > > > > From: Vishwas Manral [ mailto:Vishwas@sinett.com ] = Sent: > > Tuesday, January 31, 2006 2:08 AM > > > > To: Bora Akyol; Spencer Dawkins; v6ops@ops.ietf.org > > Subject: RE: Flow label and its uses > > > > > > Bora, > > > > > > Does this mean that you are using the flow label in lieu of the regular > > IPSEC SP match? > > > > All I am saying is just as we can have local and remote ports as > > selectors; we can instead use Flow Labels along with the IP addresses > > for the same purpose, if some assumptions can be made for the flow > > label. > > > > Is my understanding wrong? > > > > Thanks, > > Vishwas > > > > > ------=_Part_8457_18621574.1139518388753 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,

It would be good if someone could summarize the discussions about Flow Labe= l in some IETF document.

It would be of great help for the community to get over misgivings about the use of Flow Label, possible scenarios of where it can be used and its limitations.

Thanks,
Vishwas

On 2/6/06, Vishwas Manral <vishwas.ietf@gmail.com> wrote:

Hi,

I agree totally with Brian. I had sent a mail regarding the same earlier, b= ut it somehow dissappeared in transit.

That said,we could use it either as normal selectors and signal it using IK= E or as DSCP and not signal it using IKE.

Thanks,
Vishwas
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Brian said=3D>

As the flow label spec says (RFC 3697, = section=20
5.1), you can
trust the flow label just as much as you can trust the= source

and destination addresses - exactly the same attackers can f= orge
any of them. As Spencer and Thomas have pointed out, it's too
expensive to check an authenticator at each hop, and the hops

cannot= know the relevant keys anyway.

So, you can use the address pair= and flow label for classification,
just as safely (or dangerously) as y= ou can use the address pair
and the DSCP. There's no impact on the applicable threats.

A MIT= M can change any of them.

The key difference from the DSCP in th= is regard is only that the
DSCP is defined as mutable at domain boundari= es and the flow
label is defined as immutable. In both cases, you can't detect

i= f someone breaks those rules. That constrains the use cases -

errone= ous usage mustn't change the basic semantics of unreliable
datagram deli= very to the intended destination. RFC 2474 and
RFC 3697 both assume this -
i.e. the added threat is theft
of Qo= S.

In a connectionless datagram network, it seems impossible to
<= br>do better.

Brian

Bora Akyol wrote:

Flow label is not a field that is protected by = IPSEC
hence I do not think you can use
this as a selector.

Unl= ess you do modifications to IKEv2, you can not also let
the other end kn= ow what exactly the SP (security policy)

is based on.

Frankly, use of flow label as a selector wo= uld be a hack
to get around the problem of the full security policy look= up
in IPSEC at high speeds. The truth is that this has not
been a pro= blem for at least 4-5 years now as long

as the selectors themselves are TCAM friendly.

Bora
<= br>

-----Original Message-= ----
From: Vishwas Manral [ mailto:Vishwas@sinett.com]=20Sent: Tuesday, January 31, 2006 2:08 AM
To: Bora Akyol; Spencer Dawkins; v6ops@ops.ietf.org
Subject: RE: Flow = label and its uses

Bora,

Does this mean that you are using the flow label in lieu of the=20regular IPSEC SP match?
All I am saying is just as we can have local and remo= te ports=20as selectors; we can instead use Flow Labels along with the=20IP addresses for the same purpose, if some assumptions can be=20made for the flow label.=20
Is my understanding wrong?

Thanks,<= br>Vishwas

------=_Part_8457_18621574.1139518388753-- From owner-v6ops@ops.ietf.org Thu Feb 09 16:23:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7JGX-0003tG-Lj for v6ops-archive@megatron.ietf.org; Thu, 09 Feb 2006 16:23:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05509 for ; Thu, 9 Feb 2006 16:22:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7JFp-000KD6-Ob for v6ops-data@psg.com; Thu, 09 Feb 2006 21:23:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.1.0 Received: from [204.202.242.120] (helo=mail19d.g19.rapidsite.net) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7JFo-000KCs-TU for v6ops@ops.ietf.org; Thu, 09 Feb 2006 21:23:05 +0000 Received: from mx13.stngva01.us.mxservers.net (204.202.242.69) by mail19d.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 0-053692180 for ; Thu, 9 Feb 2006 16:23:03 -0500 (EST) Received: from www.native6.com [198.170.236.53] (EHLO JSN6LT) by mx13.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 4b2bbe34.25376.190.mx13.stngva01.us.mxservers.net; Thu, 09 Feb 2006 16:23:00 -0500 (EST) From: "John Spence" To: Subject: Does a Teredo client send keepalive packets to Teredo Relays to maintain a mapping in the NAT ... Date: Thu, 9 Feb 2006 13:23:04 -0800 Message-ID: <002601c62dbf$063d4540$7615509c@native6.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYqgl8td8gcBwl0TcKcnjWP4CyIegABXFJgAM2otxA= X-Spam: [F=0.0103475208; heur=0.500(300); stat=0.010; spamtraq-heur=0.500(2006020906)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] X-Loop-Detect: 1 X-DistLoop-Detect: 1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I apologize if this is in the spec - I could not find it. I see the Teredo client sends keepalive packets to the Teredo Server to maintain it's address. Does the client send keepalives towards active Relay's to maintain the mapping for active sessions? Of if a sessions through a Relay goes quiet for 2 or 3 minutes is the session considered ended? Thanks. ---------------------------------------------------- John Spence, CCSI, CCNA, CISSP Native6, Inc. IPv6 Training and Consulting jspence@native6.com ---------------------------------------------------- From owner-v6ops@ops.ietf.org Thu Feb 09 17:01:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Jqi-0002rW-Ci for v6ops-archive@megatron.ietf.org; Thu, 09 Feb 2006 17:01:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11995 for ; Thu, 9 Feb 2006 16:59:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7Jox-000MoA-Ea for v6ops-data@psg.com; Thu, 09 Feb 2006 21:59:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7Jow-000Mny-OW for v6ops@ops.ietf.org; Thu, 09 Feb 2006 21:59:22 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 9 Feb 2006 13:59:22 -0800 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 13:59:22 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 13:59:21 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Feb 2006 13:59:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Does a Teredo client send keepalive packets to Teredo Relays to maintain a mapping in the NAT ... Date: Thu, 9 Feb 2006 13:59:20 -0800 Message-ID: In-Reply-To: <002601c62dbf$063d4540$7615509c@native6.com> Thread-Topic: Does a Teredo client send keepalive packets to Teredo Relays to maintain a mapping in the NAT ... thread-index: AcYqgl8td8gcBwl0TcKcnjWP4CyIegABXFJgAM2otxAAAVBmwA== From: "Christian Huitema" To: "John Spence" , X-OriginalArrivalTime: 09 Feb 2006 21:59:21.0625 (UTC) FILETIME=[1506E090:01C62DC4] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I apologize if this is in the spec - I could not find it. I see > the Teredo client sends keepalive packets to the Teredo Server to > maintain it's address. Does the client send keepalives towards > active Relay's to maintain the mapping for active sessions? Of > if a sessions through a Relay goes quiet for 2 or 3 minutes is > the session considered ended? The client does not send keep-alive packets to the relay. Clients and relays maintain a cache of their active peers, based on the traffic exchanged with these peers. If a peer drops out of the cache, bubbles will have to be exchanged through the server before sending the next packet. -- Christian Huitema=20 From owner-v6ops@ops.ietf.org Thu Feb 09 17:14:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7K3e-0002rf-T5 for v6ops-archive@megatron.ietf.org; Thu, 09 Feb 2006 17:14:35 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12861 for ; Thu, 9 Feb 2006 17:12:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7K3G-000NrA-KZ for v6ops-data@psg.com; Thu, 09 Feb 2006 22:14:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [138.195.130.75] (helo=durga.via.ecp.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7K3E-000Nqy-Op for v6ops@ops.ietf.org; Thu, 09 Feb 2006 22:14:09 +0000 Received: from localhost (durga.via.ecp.fr [127.0.0.1]) by durga.via.ecp.fr (Postfix) with ESMTP id 30A134401; Thu, 9 Feb 2006 23:14:07 +0100 (CET) Received: from durga.via.ecp.fr ([127.0.0.1]) by localhost (durga [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11337-21; Thu, 9 Feb 2006 23:14:07 +0100 (CET) Received: from auguste.via.ecp.fr (auguste.via.ecp.fr [IPv6:2002:8ac3:802d:1242:20d:60ff:fe38:6d16]) by durga.via.ecp.fr (Postfix) with ESMTP id 1D78E43E8; Thu, 9 Feb 2006 23:14:07 +0100 (CET) From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Reply-To: rdenis@simphalempin.com Organization: =?iso-8859-1?q?=C9l=E8ve_de_l=27=C9cole_Centrale?= Paris To: "John Spence" Subject: Re: Does a Teredo client send keepalive packets to Teredo Relays to maintain a mapping in the NAT ... Date: Thu, 9 Feb 2006 23:14:06 +0100 User-Agent: KMail/1.9.1 References: <002601c62dbf$063d4540$7615509c@native6.com> In-Reply-To: <002601c62dbf$063d4540$7615509c@native6.com> Cc: v6ops@ops.ietf.org X-Content-Encoding: 100% standard charset and encoding. Fix your MUA in case of problem. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200602092314.06677@auguste.simphalempin.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at via.ecp.fr Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Le Jeudi 9 F=E9vrier 2006 22:23, vous avez =E9crit : > I apologize if this is in the spec - I could not find it. I see > the Teredo client sends keepalive packets to the Teredo Server to > maintain it's address. Does the client send keepalives towards > active Relay's to maintain the mapping for active sessions? Of > if a sessions through a Relay goes quiet for 2 or 3 minutes is > the session considered ended? You have to considered such a session as ended. Relay maintain a list of=20 recently contacted clients. If they receive traffic from a client they=20 have not heard of for a long time, they'll ignore the packet. =46ollowing the rule that you should be strict in what you send, and lax=20 in what you accept, you should rather restart the "IPv6 direct=20 connectivity check" through your Teredo server, when you have not=20 contacted any given remote IPv6 peer for some time. If you wish to avoid the implied delay, you should send higher-level=20 keep alives, if specified at given level. =2D-=20 R=E9mi Denis-Courmont Student-engineer at the Ecole Centrale Paris http://www.simphalempin.com/home/infos/cv.shtml.en From baito_jimukyoku@hotmail.co.jp Thu Feb 09 17:25:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7KEI-0007ux-3t for v6ops-archive@megatron.ietf.org; Thu, 09 Feb 2006 17:25:34 -0500 Received: from ocn.ne.jp ([221.212.57.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13383 for ; Thu, 9 Feb 2006 17:23:38 -0500 (EST) Date: Thu, 9 Feb 2006 17:23:38 -0500 (EST) Message-Id: <200602092223.RAA13383@ietf.org> Received: from lpzomnb6 (unknown [201.181.17.59]) by smtp57 (Coremail) with SMTP id 66KQ5CqMEjP658cU.1 for ; Sun, 02 Feb 2003 14:14:43 +0800 (CST) X-Originating-IP: [201.181.17.59] Subject: =?iso-2022-jp?B?IBskQiQqJFBNTSRHMlQkMCEqISobKEI=?= From: =?gb2312?B?YmFpdG8=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: text/plain; Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: base64 GyRCJ1gnWCdYJ1gnWCdYJ1gnWCdYJ1gnWCdYGyhCDQoNChskQj13QC0kTkFqPGokciQ3JEZEOiQx JGtDS0AtSmc9OBsoQg0KDQobJEJFdkhWQUgkRyRPISJFUE8/JDckRiQkJGs9d0AtMnEwdyROGyhC DQoNChskQkFqPGokciQ3JEYkLyRsJGtDS0AtJHJKZz04JDckRiQkJF4kOSEjGyhCDQpodHRwOi8v d3d3LmF3ZzUubmV0Lz8yMDExDQoNChskQkpnPTg+cjdvISEjMiMyOlAkKyRpIzMjNTpQJF4kRyRO Q0tALRsoQg0KDQobJEJKcz03JEs0WCQ3JEYkTyEiQWo8aj13QC0kSEQ+QFxPQyQ3JEYkKjdoJGEy PCQ1JCQhIxsoQg0KDQobJEJFdkp9JE84cj5EQC5OKSROOl0hIj13QC0ycTB3JE5KfSQrJGlOQTZi JHJEOiQvMFkbKEINCg0KGyRCQ0tALTJxMHckTkp9JCskaTBsQFokKjZiJHJEOiQtJF4kOyRzISMb KEINCg0KGyRCPjAhIkVQTz8kNyRGJCQkaz13QC0ycTB3JE5KfSRPISI/SDg1PzM6OiRyJDckPxso Qg0KDQobJEJKfSROJF8kSCRKJGokXiQ5ISMycTB3JE5DZiRLJE88UjJxRSpDTzBMJE4kIiRrSn0k YhsoQg0KDQobJEIkKiRqJF4kOSROJEchIj5vPDEkIiRrSn0kTiRfJE5KZz04JEgkNSQ7JEZEOiQt JF4kOSEjGyhCDQoNChskQiQ0NHVLPiROSn0kTyQzJEEkaSROTng/TUpnPTgkaCRqJCpGfiRqMjwk NSQkISMbKEINCg0KGyRCNTkkNyQvJCo0aiQkQ1ckNyReJDkhIxsoQg0KDQpodHRwOi8vd3d3LmF3 ZzUubmV0Lz8yMDExDQoNChskQidYJ1gnWCdYJ1gnWCdYJ1gnWCdYGyhCDQoNCg0KDQoNCg0KDQoN Cg0KSSBkb24ndCB2ZWNlaXZlIHlvdXJtYWlsDQoNChskQiVhITwlazx1Py41cUhdGyhCDQpwcmlv cml0eTdfbmV0QHlhaG9vLmNhDQobJEIhIRsoQg0K From owner-v6ops@ops.ietf.org Thu Feb 09 22:18:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7OoC-0007Fj-5b for v6ops-archive@megatron.ietf.org; Thu, 09 Feb 2006 22:18:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05971 for ; Thu, 9 Feb 2006 22:17:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7OlP-000HWv-V6 for v6ops-data@psg.com; Fri, 10 Feb 2006 03:16:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [66.249.82.207] (helo=xproxy.gmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7OlP-000HWI-4b for v6ops@ops.ietf.org; Fri, 10 Feb 2006 03:16:03 +0000 Received: by xproxy.gmail.com with SMTP id s6so226375wxc for ; Thu, 09 Feb 2006 19:16:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=WGAvFtj+e6jcuw4M/WOTXHgbDEr1knY9fhEamSCCO0TtIzHbWtTTsfUYW8dFUQow3SqrU2aQfP22JeFU4eqoB59gSTJzJcO2T7beagg25OAxgGcv3ypp+Jyow0lDklUp5Xw8loSWZMWaGCjGTV++1s6TftSI8RRub8EmOeXP1v0= Received: by 10.70.19.6 with SMTP id 6mr956610wxs; Thu, 09 Feb 2006 19:16:01 -0800 (PST) Received: by 10.70.40.8 with HTTP; Thu, 9 Feb 2006 19:16:01 -0800 (PST) Message-ID: Date: Fri, 10 Feb 2006 11:16:01 +0800 From: haofeng Zhang To: v6ops@ops.ietf.org Subject: How to differentiate traffic in NAT-PT box? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_865_21843892.1139541361447" Sender: owner-v6ops@ops.ietf.org Precedence: bulk ------=_Part_865_21843892.1139541361447 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear all, I have a problem regarding to NAT-PT and ALG. In the RFC2766(NAT-PT spec), nat-pt box cooperates with ALG to deal with some application carrying IP addresses in payload. But for the operation of nat-box box, how can the box differentiate which kind of traffic needs to b= e processed by ALG and others needn't? Or the nat-pt box just send all traffi= c to ALG module and leave the differentiation problem to ALG? I don't find the clarification in the spec. So if answer is the latter, doe= s it means a big waste of device resource? After all, usually only the signaling traffic needs to be processed by ALG. So any kind of help is appreciated. -- Best regards, Zhang haofeng ------=_Part_865_21843892.1139541361447 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Dear all,

I have a problem regarding to NAT-PT and ALG.

In the RFC2766(NAT-PT spec), nat-pt box cooperates with ALG to deal wi= th some application carrying IP addresses in payload. But for the operation= of nat-box box, how can the box differentiate which kind of traffic n= eeds to be processed by ALG and others needn't? Or the nat-pt box just= send all traffic to ALG module and leave the differentiation problem to AL= G?

I don't find the clarification in the spec. So if answer is the latter= , does it means a big waste of device resource? After all, usually only the= signaling traffic needs to be processed by ALG.

So any kind of help is appreciated.

--
Best r= egards,
Zhang haofeng

------=_Part_865_21843892.1139541361447-- From owner-v6ops@ops.ietf.org Thu Feb 09 22:55:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7PNo-0003RO-Fo for v6ops-archive@megatron.ietf.org; Thu, 09 Feb 2006 22:55:44 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08359 for ; Thu, 9 Feb 2006 22:54:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7PMz-000K01-7T for v6ops-data@psg.com; Fri, 10 Feb 2006 03:54:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,HTML_50_60, HTML_FONT_FACE_BAD,HTML_MESSAGE,RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [61.144.161.55] (helo=huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7PMx-000JzQ-6y for v6ops@ops.ietf.org; Fri, 10 Feb 2006 03:54:52 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUG006TBDLEDI@szxga03-in.huawei.com> for v6ops@ops.ietf.org; Fri, 10 Feb 2006 11:56:02 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUG00II3DLD4P@szxga03-in.huawei.com> for v6ops@ops.ietf.org; Fri, 10 Feb 2006 11:56:02 +0800 (CST) Received: from S18601F ([10.111.12.85]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUG00468DU35B@szxml02-in.huawei.com>; Fri, 10 Feb 2006 12:01:16 +0800 (CST) Date: Fri, 10 Feb 2006 11:49:11 +0800 From: xiao bin Subject: Re: How to differentiate traffic in NAT-PT box? To: haofeng Zhang , v6ops@ops.ietf.org Message-id: <003701c62df4$f4552a10$550c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: multipart/alternative; boundary="Boundary_(ID_in+ITbOx/3WmEwXMHXrtNQ)" X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_in+ITbOx/3WmEwXMHXrtNQ) Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT For some packet, the device can judge whether a packet need ALG by the protocol number in the packet header. ----- Original Message ----- From: haofeng Zhang To: v6ops@ops.ietf.org Sent: Friday, February 10, 2006 11:16 AM Subject: How to differentiate traffic in NAT-PT box? Dear all, I have a problem regarding to NAT-PT and ALG. In the RFC2766(NAT-PT spec), nat-pt box cooperates with ALG to deal with some application carrying IP addresses in payload. But for the operation of nat-box box, how can the box differentiate which kind of traffic needs to be processed by ALG and others needn't? Or the nat-pt box just send all traffic to ALG module and leave the differentiation problem to ALG? I don't find the clarification in the spec. So if answer is the latter, does it means a big waste of device resource? After all, usually only the signaling traffic needs to be processed by ALG. So any kind of help is appreciated. -- Best regards, Zhang haofeng --Boundary_(ID_in+ITbOx/3WmEwXMHXrtNQ) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT

For some packet, the device can judge whether a packet need ALG by the protocol number in the packet header.

----- Original Message -----

From: haofeng Zhang

To: v6ops@ops.ietf.org

Sent: Friday, February 10, 2006 11:16 AM

Subject: How to differentiate traffic in NAT-PT box?

Dear all,

I have a problem regarding to NAT-PT and ALG.

In the RFC2766(NAT-PT spec), nat-pt box cooperates with ALG to deal with some application carrying IP addresses in payload. But for the operation of nat-box box, how can the box differentiate which kind of traffic needs to be processed by ALG and others needn't? Or the nat-pt box just send all traffic to ALG module and leave the differentiation problem to ALG?

I don't find the clarification in the spec. So if answer is the latter, does it means a big waste of device resource? After all, usually only the signaling traffic needs to be processed by ALG.

So any kind of help is appreciated.

--
Best regards,
Zhang haofeng

--Boundary_(ID_in+ITbOx/3WmEwXMHXrtNQ)-- From owner-v6ops@ops.ietf.org Fri Feb 10 07:06:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7X33-000896-Ip for v6ops-archive@megatron.ietf.org; Fri, 10 Feb 2006 07:06:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13536 for ; Fri, 10 Feb 2006 07:05:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7X0V-000Nxs-18 for v6ops-data@psg.com; Fri, 10 Feb 2006 12:04:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7X0T-000Nv0-Ky for v6ops@ops.ietf.org; Fri, 10 Feb 2006 12:04:10 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id k1AC3f7i031362 for ; Fri, 10 Feb 2006 12:03:41 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1AC3gC3235288 for ; Fri, 10 Feb 2006 13:03:42 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k1AC3fGB020903 for ; Fri, 10 Feb 2006 13:03:41 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k1AC3eFS020891; Fri, 10 Feb 2006 13:03:40 +0100 Received: from zurich.ibm.com (sig-9-145-253-49.de.ibm.com [9.145.253.49]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA34802; Fri, 10 Feb 2006 13:03:34 +0100 Message-ID: <43EC8114.3010005@zurich.ibm.com> Date: Fri, 10 Feb 2006 13:03:32 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: haofeng Zhang CC: v6ops@ops.ietf.org Subject: Re: How to differentiate traffic in NAT-PT box? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit One of the many reasons for killing NAT-PT. Brian haofeng Zhang wrote: > Dear all, > > I have a problem regarding to NAT-PT and ALG. > In the RFC2766(NAT-PT spec), nat-pt box cooperates with ALG to deal with > some application carrying IP addresses in payload. But for the operation of > nat-box box, how can the box differentiate which kind of traffic needs to be > processed by ALG and others needn't? Or the nat-pt box just send all traffic > to ALG module and leave the differentiation problem to ALG? > I don't find the clarification in the spec. So if answer is the latter, does > it means a big waste of device resource? After all, usually only the > signaling traffic needs to be processed by ALG. > So any kind of help is appreciated. > > -- > Best regards, > Zhang haofeng > From owner-v6ops@ops.ietf.org Fri Feb 10 08:50:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7YfX-0002m8-Vs for v6ops-archive@megatron.ietf.org; Fri, 10 Feb 2006 08:50:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20474 for ; Fri, 10 Feb 2006 08:48:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7Ydj-0004ej-6N for v6ops-data@psg.com; Fri, 10 Feb 2006 13:48:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7Ydi-0004eU-32 for v6ops@ops.ietf.org; Fri, 10 Feb 2006 13:48:46 +0000 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1F7Ydc-0005H3-04; Fri, 10 Feb 2006 13:48:40 +0000 Message-ID: <43EC9A3F.8000202@dial.pipex.com> Date: Fri, 10 Feb 2006 13:50:55 +0000 From: Elwyn Davies User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: haofeng Zhang CC: Brian E Carpenter , v6ops@ops.ietf.org Subject: Re: How to differentiate traffic in NAT-PT box? References: <43EC8114.3010005@zurich.ibm.com> In-Reply-To: <43EC8114.3010005@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Indeed so. Have you read draft-ietf-v6ops-natpt-to-exprmntl-03.txt? The Abstract says: > This document discusses issues with the specific form of IPv6-IPv4 > protocol translation mechanism implemented by the Network Address > Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These > issues are sufficiently serious that recommending RFC 2766 as a > general purpose transition mechanism is no longer desirable, and this > document recommends that the IETF should reclassify RFC 2766 from > Standards Track to Experimental status You should think very carefully before spending a lot of time on this work. Regards, Elwyn Brian E Carpenter wrote: > One of the many reasons for killing NAT-PT. > > Brian > > haofeng Zhang wrote: >> Dear all, >> >> I have a problem regarding to NAT-PT and ALG. >> In the RFC2766(NAT-PT spec), nat-pt box cooperates with ALG to deal with >> some application carrying IP addresses in payload. But for the >> operation of >> nat-box box, how can the box differentiate which kind of traffic >> needs to be >> processed by ALG and others needn't? Or the nat-pt box just send all >> traffic >> to ALG module and leave the differentiation problem to ALG? >> I don't find the clarification in the spec. So if answer is the >> latter, does >> it means a big waste of device resource? After all, usually only the >> signaling traffic needs to be processed by ALG. >> So any kind of help is appreciated. >> >> -- >> Best regards, >> Zhang haofeng >> > > From owner-v6ops@ops.ietf.org Sun Feb 12 21:46:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8TjB-0003gT-4t for v6ops-archive@megatron.ietf.org; Sun, 12 Feb 2006 21:46:15 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04666 for ; Sun, 12 Feb 2006 21:44:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8TeM-000NLM-Pg for v6ops-data@psg.com; Mon, 13 Feb 2006 02:41:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8TeL-000NL5-Db for v6ops@ops.ietf.org; Mon, 13 Feb 2006 02:41:13 +0000 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IUL002B0U4NDN@mailout2.samsung.com> for v6ops@ops.ietf.org; Mon, 13 Feb 2006 11:41:11 +0900 (KST) Received: from daniellaptop ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IUL00BCWU4N3O@mmp1.samsung.com> for v6ops@ops.ietf.org; Mon, 13 Feb 2006 11:41:11 +0900 (KST) Date: Mon, 13 Feb 2006 11:41:24 +0900 From: Soohong Daniel Park Subject: Re: How to differentiate traffic in NAT-PT box? To: Brian E Carpenter , haofeng Zhang Cc: v6ops@ops.ietf.org Message-id: <018601c63046$fb307a20$6dc6dba8@daniellaptop> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <43EC8114.3010005@zurich.ibm.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Withour DNS-ALG, we can live with NAT-PT as well. http://www.watersprings.org/pub/id/draft-daniel-natpt-bis-01.txt Don't say "Killing NAT-PT". It seems a harmful opinion against NAT-PT developer, although they are still weak status. Just saying "Clarifying NAT-PT". No technology can be a perfect level. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: "Brian E Carpenter" To: "haofeng Zhang" Cc: Sent: Friday, February 10, 2006 9:03 PM Subject: Re: How to differentiate traffic in NAT-PT box? > One of the many reasons for killing NAT-PT. > > Brian > > haofeng Zhang wrote: >> Dear all, >> >> I have a problem regarding to NAT-PT and ALG. >> In the RFC2766(NAT-PT spec), nat-pt box cooperates with ALG to deal with >> some application carrying IP addresses in payload. But for the operation of >> nat-box box, how can the box differentiate which kind of traffic needs to be >> processed by ALG and others needn't? Or the nat-pt box just send all traffic >> to ALG module and leave the differentiation problem to ALG? >> I don't find the clarification in the spec. So if answer is the latter, does >> it means a big waste of device resource? After all, usually only the >> signaling traffic needs to be processed by ALG. >> So any kind of help is appreciated. >> >> -- >> Best regards, >> Zhang haofeng >> > > > > From owner-v6ops@ops.ietf.org Mon Feb 13 03:41:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8ZGb-0005HK-4z for v6ops-archive@megatron.ietf.org; Mon, 13 Feb 2006 03:41:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25783 for ; Mon, 13 Feb 2006 03:39:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8ZD9-000Fc4-OR for v6ops-data@psg.com; Mon, 13 Feb 2006 08:37:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [84.14.106.33] (helo=proxy.6wind.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8ZD7-000Fbq-Le for v6ops@ops.ietf.org; Mon, 13 Feb 2006 08:37:29 +0000 Received: from [10.16.0.239] (unknown [10.16.0.239]) by proxy.6wind.com (Postfix) with ESMTP id 33C76525F84; Mon, 13 Feb 2006 09:37:28 +0100 (CET) Message-ID: <43F0454C.2000501@6wind.com> Date: Mon, 13 Feb 2006 09:37:32 +0100 From: Vincent Jardin User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xiao bin Cc: haofeng Zhang , v6ops@ops.ietf.org Subject: Re: How to differentiate traffic in NAT-PT box? References: <003701c62df4$f4552a10$550c6f0a@china.huawei.com> In-Reply-To: <003701c62df4$f4552a10$550c6f0a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, From our experience and implementation into the 6WINDGate software, you should not try to link the DNS ALG with NAT-PT. Moreover, DNS ALG and NAT-PT could be into 2 different routers: 1- one module or router is used in order to process the DNS AAAA requrests and it provides a reply with a NAT-PT::/96 prefix in order to route the packets to a NAT-PT translator (router, module, etc.) 2- another module or router is just an IPv6/IPv4 translator based on the NAT-PT::/96 prefix Instead of 1, for some services, you can replace dynamic DNS ALG by static IPv6 intries into your IPv6 DNS, these entries are just NAT-PT::A.B.C.D. Regards, Vincent xiao bin wrote: > For some packet, the device can judge whether a packet need ALG by the > protocol number in the packet header. > > ----- Original Message ----- > *From:* haofeng Zhang > *To:* v6ops@ops.ietf.org > *Sent:* Friday, February 10, 2006 11:16 AM > *Subject:* How to differentiate traffic in NAT-PT box? > > Dear all, > I have a problem regarding to NAT-PT and ALG. > In the RFC2766(NAT-PT spec), nat-pt box cooperates with ALG to > deal with some application carrying IP addresses in payload. But > for the operation of nat-box box, how can the box differentiate > which kind of traffic needs to be processed by ALG and others > needn't? Or the nat-pt box just send all traffic to ALG module and > leave the differentiation problem to ALG? > I don't find the clarification in the spec. So if answer is the > latter, does it means a big waste of device resource? After all, > usually only the signaling traffic needs to be processed by ALG. > So any kind of help is appreciated. > > -- > Best regards, > Zhang haofeng > From 2esau@a1.mbn.or.jp Mon Feb 13 16:29:33 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8lGH-0005Ia-57 for v6ops-archive@megatron.ietf.org; Mon, 13 Feb 2006 16:29:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24924 for ; Mon, 13 Feb 2006 16:27:48 -0500 (EST) Received: from [62.57.198.233] (helo=233.red-62-57-198.user.auna.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F8lTs-0006dI-4w for v6ops-archive@ietf.org; Mon, 13 Feb 2006 16:43:42 -0500 Message-ID: From: "Steven A. Norman" <2esau@a1.mbn.or.jp> To: v6ops-archive@ietf.org Subject: Copies of swiss watches Date: Mon, 13 Feb 2006 18:09:02 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_662A6B8E.AABC541D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 25620135586de10c627e3628c432b04a This is a multi-part message in MIME format. ------=_NextPart_000_0000_662A6B8E.AABC541D Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_7706F75E.03DC0ED0" ------=_NextPart_001_0001_7706F75E.03DC0ED0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit EXACT COPIES OF SWISS WATCHES - exact copies of V.I.P. watches - perfect as a gift for your colleagues and friends - free gift box Rolex, Patek Philippe, Omega Cartier, Bvlgari, Franck Muller .. and 15 other most famous manufacturers. http://121.yeswatches.net All watches are for only $239.95 - $279.95! ________________________________ To change your mail preferences, go here ------=_NextPart_001_0001_7706F75E.03DC0ED0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

EXACT COPIES OF SWISS WATCHES

- exact copies of V.I.P. watches
- perfect as a gift for your colleagues and friends
- free gift box

Rolex, Patek Philippe, Omega
Cartier, Bvlgari, Franck Muller

.. and 15 other most famous manufacturers.

http://121.yeswatches.net

All watches are for only $239.95 - $279.95!

________________________________
To change your mail preferences, go here

------=_NextPart_001_0001_7706F75E.03DC0ED0-- ------=_NextPart_000_0000_662A6B8E.AABC541D-- From owner-v6ops@ops.ietf.org Wed Feb 15 15:54:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Tf1-0003Bj-DJ for v6ops-archive@megatron.ietf.org; Wed, 15 Feb 2006 15:54:03 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00724 for ; Wed, 15 Feb 2006 15:52:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9TbK-0005Bx-Q9 for v6ops-data@psg.com; Wed, 15 Feb 2006 20:50:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F9TbJ-0005Bh-Vu for v6ops@ops.ietf.org; Wed, 15 Feb 2006 20:50:14 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1FKo20e014524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1F9Tb8-0005lp-0l; Wed, 15 Feb 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ent-analysis-04.txt Message-Id: Date: Wed, 15 Feb 2006 15:50:02 -0500 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Enterprise Network Analysis Author(s) : J. Bound, et al. Filename : draft-ietf-v6ops-ent-analysis-04.txt Pages : 38 Date : 2006-2-15 This document analyzes the transition to IPv6 in enterprise networks. These networks are characterized as a network that has multiple internal links, one or more router connections, to one or more Providers, and is managed by a network operations entity. The analysis will focus on a base set of transition notational networks and requirements expanded from a previous Enterprise Scenarios document. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment, within the enterprise. Then a set of transition mechanisms are recommended for each notational network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ent-analysis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ent-analysis-04.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: <2006-2-15143325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ent-analysis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ent-analysis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-15143325.I-D@ietf.org> --OtherAccess-- --NextPart--