From owner-v6ops@ops.ietf.org Sat Nov 2 00:52:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18240 for ; Sat, 2 Nov 2002 00:52:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 187rBo-000MRw-00 for v6ops-data@psg.com; Fri, 01 Nov 2002 21:51:20 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #2) id 187rBm-000MRk-00 for v6ops@ops.ietf.org; Fri, 01 Nov 2002 21:51:18 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 03FBA907; Sat, 2 Nov 2002 00:51:18 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 2 Nov 2002 00:50:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28233.BB6182FB" Subject: RE: IPv6, broadband access, VPN Date: Sat, 2 Nov 2002 00:50:21 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9852@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6, broadband access, VPN Thread-Index: AcKBDZqC0t6JDclxQvmh2echaC68/wBJhDFg From: "Bound, Jim" To: "Chen, Weijing" , X-OriginalArrivalTime: 02 Nov 2002 05:50:22.0459 (UTC) FILETIME=[BBBEECB0:01C28233] X-Spam-Status: No, hits=-0.1 required=5.0 tests=BIG_FONT,HTML_50_70,HTML_FONT_COLOR_BLUE, HTML_FONT_COLOR_NAME,HTML_FONT_FACE_ODD,MAILTO_LINK, SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C28233.BB6182FB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Thanks I in fact pulled this to read before the IETF. Yes we will look at this for sure. =20 Are you going to present it at Altanta? =20 thanks =20 =20 /jim [In matters of style, swim with the currents...in matters of principle, stand like a rock. - Thomas Jefferson] -----Original Message----- From: Chen, Weijing [mailto:wchen@tri.sbc.com]=20 Sent: Thursday, October 31, 2002 1:42 PM To: 'v6ops@ops.ietf.org' Subject: IPv6, broadband access, VPN =09 =09 All, =20 We have been studying the benefits that IPv6 could bring to a large carrier like SBC, in addition to large IP address, plug-play host connection. You might be interested in an Internet-Draft that we recently submitted as http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt. In it, we make a case for why companies like ours should be turning towards IPv6, and also suggest some new capabilities for IPv6, such as broadband Internet access, L3VPN, L2VPN. Although we have focused on IPv6 service in this draft, we would welcome the expansion of it to the same IPv4 service offering through IPv6 core network. =20 We would like to hear comments and interests from all the parities. =20 Regards, -- Weijing Chen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 512 372 5710 wchen@tri.sbc.com =20 ------_=_NextPart_001_01C28233.BB6182FB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
Thanks=20 I in fact pulled this to read before the IETF.  Yes we will look at = this=20 for sure.
 
Are=20 you going to present it at Altanta?
 
thanks
 
 
/jim
[In matters of style, swim = with the=20 currents...in matters of principle, stand like a rock.  - Thomas=20 Jefferson]
-----Original Message-----
From: = Chen, Weijing=20 [mailto:wchen@tri.sbc.com]
Sent: Thursday, October 31, 2002 = 1:42=20 PM
To: 'v6ops@ops.ietf.org'
Subject: IPv6, = broadband=20 access, VPN

All,

 

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

 

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

 

Regards,

--

Weijing = Chen

SBC Technology=20 Resources

9505 Arboretum=20 Blvd.

Austin, TX=20 78759

512 372 = 5710

wchen@tri.sbc.com

=00 ------_=_NextPart_001_01C28233.BB6182FB-- From owner-v6ops@ops.ietf.org Mon Nov 4 10:06:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16607 for ; Mon, 4 Nov 2002 10:06:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188ioW-0008rD-00 for v6ops-data@psg.com; Mon, 04 Nov 2002 07:06:52 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 188ioU-0008r1-00 for v6ops@ops.ietf.org; Mon, 04 Nov 2002 07:06:50 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16035; Mon, 4 Nov 2002 10:04:20 -0500 (EST) Message-Id: <200211041504.KAA16035@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mccann-mobileip-ipv6mipv4-03.txt Date: Mon, 04 Nov 2002 10:04:19 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 over Mobile IPv4 Author(s) : P. Calhoun, P. Engelstad, T. Hiller, P. McCann Filename : draft-mccann-mobileip-ipv6mipv4-03.txt Pages : 11 Date : 2002-11-1 This document specifies a Mobile IPv4 extension that may be used by dual stack mobile nodes to obtain IPv6 service with the use of a Mobile IPv4 registration. This extension allows for immediate deployment of IPv6 on dual stack mobile devices, without the need for a full IPv6 infrastructure. It is believed that providing IPv6 services to mobile devices in the short term will spur the growth of IPv6 networks. This extension makes use of the existing Mobile IPv4 security model, including the interface to the AAA infrastructure, but does not provide the route optimization capabilities included in the Mobile IPv6 protocol. Further, this specification requires that the mobile node and Home Agent have dual IPv4 and IPv6 stacks. There are no changes to the FA nor does it need to be dual stack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mccann-mobileip-ipv6mipv4-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mccann-mobileip-ipv6mipv4-03.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-mccann-mobileip-ipv6mipv4-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-1143117.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mccann-mobileip-ipv6mipv4-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-mccann-mobileip-ipv6mipv4-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-1143117.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Nov 4 10:06:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16651 for ; Mon, 4 Nov 2002 10:06:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188iqD-0008uz-00 for v6ops-data@psg.com; Mon, 04 Nov 2002 07:08:37 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 188iqA-0008un-00 for v6ops@ops.ietf.org; Mon, 04 Nov 2002 07:08:35 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16519; Mon, 4 Nov 2002 10:06:06 -0500 (EST) Message-Id: <200211041506.KAA16519@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-cases-00.txt Date: Mon, 04 Nov 2002 10:06:05 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Transition Scenarios for 3GPP Networks Author(s) : J. Soininen Filename : draft-ietf-v6ops-3gpp-cases-00.txt Pages : 10 Date : 2002-11-1 This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e. General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet. GPRS network internal transition scenarios, i.e. between different GPRS elements in the network, are out of scope of this document. The purpose of the document is to list the scenarios for further discussion and study. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-3gpp-cases-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-3gpp-cases-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-1143511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-cases-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-cases-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-1143511.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Nov 4 10:48:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18885 for ; Mon, 4 Nov 2002 10:48:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188jUL-000Gaw-00 for v6ops-data@psg.com; Mon, 04 Nov 2002 07:50:05 -0800 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by psg.com with esmtp (Exim 3.36 #2) id 188jUH-000Ga9-00 for v6ops@ops.ietf.org; Mon, 04 Nov 2002 07:50:02 -0800 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id gA4FnUd05322; Mon, 4 Nov 2002 09:49:30 -0600 (CST) Message-ID: <3DC69745.4020103@alcatel.com> Date: Mon, 04 Nov 2002 09:50:29 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" CC: "Chen, Weijing" , v6ops@ops.ietf.org Subject: Re: IPv6, broadband access, VPN References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9852@tayexc13.americas.cpqcorp.net> Content-Type: multipart/alternative; boundary="------------060206050801030601070906" X-Spam-Status: No, hits=-10.2 required=5.0 tests=BIG_FONT,EMAIL_ATTRIBUTION,HTML_50_70,HTML_FONT_COLOR_BLUE, HTML_FONT_COLOR_NAME,HTML_FONT_FACE_ODD,MAILTO_LINK, NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --------------060206050801030601070906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I am curious in which WG this draft could be presented. Its Sec. 3.2 on VPN is very much related to PPVPN WG. Bound, Jim wrote: > Hi, > > Thanks I in fact pulled this to read before the IETF. Yes we will > look at this for sure. > > Are you going to present it at Altanta? > > thanks > > > /jim > [In matters of style, swim with the currents...in matters of > principle, stand like a rock. - Thomas Jefferson] > > -----Original Message----- > From: Chen, Weijing [mailto:wchen@tri.sbc.com] > Sent: Thursday, October 31, 2002 1:42 PM > To: 'v6ops@ops.ietf.org' > Subject: IPv6, broadband access, VPN > > All, > > > > We have been studying the benefits that IPv6 could bring to a > large carrier like SBC, in addition to large IP address, plug-play > host connection. You might be interested in an Internet-Draft > that we recently submitted as > http://www.ietf.org/internet-drafts/draft-allen-lap-ipv6-00.txt. > In it, we make a case for why companies like ours should be > turning towards IPv6, and also suggest some new capabilities for > IPv6, such as broadband Internet access, L3VPN, L2VPN. Although > we have focused on IPv6 service in this draft, we would welcome > the expansion of it to the same IPv4 service offering through IPv6 > core network. > > > > We would like to hear comments and interests from all the parities. > > > > Regards, > > -- > > Weijing Chen > > SBC Technology Resources > > 9505 Arboretum Blvd. > > Austin, TX 78759 > > 512 372 5710 > > wchen@tri.sbc.com > -- Behcet --------------060206050801030601070906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I am curious in which WG this draft could be presented. Its Sec. 3.2 on VPN is very much related to PPVPN WG.

Bound, Jim wrote:
Message
Hi,
 
Thanks I in fact pulled this to read before the IETF.  Yes we will look at this for sure.
 
Are you going to present it at Altanta?
 
thanks
 
 
/jim
[In matters of style, swim with the currents...in matters of principle, stand like a rock.  - Thomas Jefferson]
-----Original Message-----
From: Chen, Weijing [mailto:wchen@tri.sbc.com]
Sent: Thursday, October 31, 2002 1:42 PM
To: 'v6ops@ops.ietf.org'
Subject: IPv6, broadband access, VPN

All,

 

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

 

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

 

Regards,

--

Weijing Chen

SBC Technology Resources

9505 Arboretum Blvd.

Austin, TX 78759

512 372 5710

wchen@tri.sbc.com


-- 
Behcet

--------------060206050801030601070906-- From owner-v6ops@ops.ietf.org Mon Nov 4 21:57:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20614 for ; Mon, 4 Nov 2002 21:57:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 188tut-000OKc-00 for v6ops-data@psg.com; Mon, 04 Nov 2002 18:58:11 -0800 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by psg.com with esmtp (Exim 3.36 #2) id 188tuo-000OKP-00 for v6ops@ops.ietf.org; Mon, 04 Nov 2002 18:58:06 -0800 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA52x3X19654 for ; Mon, 4 Nov 2002 20:59:03 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 4 Nov 2002 20:58:04 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 4 Nov 2002 18:58:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C28477.28673298" Subject: FW: I-D ACTION:draft-ietf-v6ops-3gpp-cases-00.txt Date: Mon, 4 Nov 2002 18:58:03 -0800 Message-ID: <4D7B558499107545BB45044C63822DDE0175D894@mvebe001.americas.nokia.com> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-ietf-v6ops-3gpp-cases-00.txt Thread-Index: AcKEFiH630Lw2gQgRLW5Ce4NP+zKGgAYN3QA From: To: X-OriginalArrivalTime: 05 Nov 2002 02:58:04.0349 (UTC) FILETIME=[28FDC6D0:01C28477] X-Spam-Status: No, hits=2.3 required=5.0 tests=NO_REAL_NAME,OUTLOOK_FW_MSG,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02 version=2.41 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C28477.28673298 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, here is the new version of the 3GPP scenarios draft. It has not actually = changed, except for it becoming a WG draft. I would guess it is rather = stable already. Cheers, Jonne. -----Original Message----- From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, November 04, 2002 7:06 AM Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-cases-00.txt 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 : Transition Scenarios for 3GPP Networks Author(s) : J. Soininen Filename : draft-ietf-v6ops-3gpp-cases-00.txt Pages : 10 Date : 2002-11-1 =09 This document describes different scenarios in Third Generation=20 Partnership Project (3GPP) defined packet network, i.e. General=20 Packet Radio Service (GPRS) that would need IP version 6 and IP=20 version 4 transition. The focus of this document is on the scenarios=20 where the User Equipment (UE) connects to nodes in other networks,=20 e.g. in the Internet. GPRS network internal transition scenarios,=20 i.e. between different GPRS elements in the network, are out of scope=20 of this document. =20 The purpose of the document is to list the scenarios for further=20 discussion and study. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-00.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-3gpp-cases-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-3gpp-cases-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C28477.28673298 Content-Type: application/octet-stream; name="ATT359564.TXT" Content-Description: ATT359564.TXT Content-Disposition: attachment; filename="ATT359564.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAyLTExLTExNDM1MTEuSS1EQGlldGYub3JnPg0KDQpF TkNPRElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi12Nm9wcy0zZ3Bw LWNhc2VzLTAwLnR4dA0K ------_=_NextPart_001_01C28477.28673298 Content-Type: application/octet-stream; name="draft-ietf-v6ops-3gpp-cases-00.URL" Content-Description: draft-ietf-v6ops-3gpp-cases-00.URL Content-Disposition: attachment; filename="draft-ietf-v6ops-3gpp-cases-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXY2b3BzLTNncHAtY2FzZXMtMDAudHh0DQo= ------_=_NextPart_001_01C28477.28673298-- From owner-v6ops@ops.ietf.org Tue Nov 5 06:01:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09720 for ; Tue, 5 Nov 2002 06:01:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1891Th-0001Ua-00 for v6ops-data@psg.com; Tue, 05 Nov 2002 03:02:37 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #2) id 1891Tf-0001UO-00 for v6ops@ops.ietf.org; Tue, 05 Nov 2002 03:02:35 -0800 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA5B30B28053 for ; Tue, 5 Nov 2002 13:03:00 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 5 Nov 2002 13:02:31 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 13:02:31 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: 3gpp transition solutions, revision -02 Date: Tue, 5 Nov 2002 13:02:31 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC358E@esebe005.ntc.nokia.com> Thread-Topic: 3gpp transition solutions, revision -02 Thread-Index: AcKEutZaBbI+0mDFQTy5NaUOPiwWSQ== From: To: X-OriginalArrivalTime: 05 Nov 2002 11:02:32.0136 (UTC) FILETIME=[D6BE1480:01C284BA] X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA09720 Hi all, a new version of the 3GPP (cellular) network design team solutions draft is available here: http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-transition-02.txt All comments are appreciated a lot. Cheers, -Juha W.- From owner-v6ops@ops.ietf.org Tue Nov 5 06:06:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10361 for ; Tue, 5 Nov 2002 06:06:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1891Zx-0001o7-00 for v6ops-data@psg.com; Tue, 05 Nov 2002 03:09:05 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 1891Zv-0001nv-00 for v6ops@ops.ietf.org; Tue, 05 Nov 2002 03:09:03 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10312; Tue, 5 Nov 2002 06:06:33 -0500 (EST) Message-Id: <200211051106.GAA10312@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-savola-v6ops-multicast-issues-01.txt Date: Tue, 05 Nov 2002 06:06:33 -0500 X-Spam-Status: No, hits=1.8 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.41 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Multicast Deployment Issues Author(s) : P. Savola Filename : draft-savola-v6ops-multicast-issues-01.txt Pages : 8 Date : 2002-11-4 There are many issues concerning the deployment and implementation, and to a lesser degree, specification of IPv6 multicast. This memo describes known problems, trying to raise awareness. Currently, global IPv6 interdomain multicast is completely impossible except using SSM: there is no way to convey information about multicast sources between PIM RPs. Site-scoped multicast is also problematic when used alongside to global multicast because of that. A few possible solutions are outlined or referred to. In addition, an issue regarding link-local multicast-blocking Ethernet switches is brought up. Finally, a feature request for MLD snooping switches is noted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-v6ops-multicast-issues-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-savola-v6ops-multicast-issues-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-v6ops-multicast-issues-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-4171605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-savola-v6ops-multicast-issues-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-savola-v6ops-multicast-issues-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4171605.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Nov 5 12:47:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01635 for ; Tue, 5 Nov 2002 12:47:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1897nk-0000WR-00 for v6ops-data@psg.com; Tue, 05 Nov 2002 09:47:44 -0800 Received: from parsmtp1.rd.francetelecom.com ([194.167.105.13]) by psg.com with esmtp (Exim 3.36 #2) id 1897nj-0000WD-00 for v6ops@ops.ietf.org; Tue, 05 Nov 2002 09:47:43 -0800 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 18:47:41 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: 3gpp transition solutions, revision -02 Date: Tue, 5 Nov 2002 18:47:41 +0100 Message-ID: Thread-Topic: 3gpp transition solutions, revision -02 Thread-Index: AcKEutZaBbI+0mDFQTy5NaUOPiwWSQANvzuQ From: "BELOEIL Luc FTRD/DMI/CAE" To: , X-OriginalArrivalTime: 05 Nov 2002 17:47:41.0765 (UTC) FILETIME=[70691750:01C284F3] X-Spam-Status: No, hits=-5.1 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA01635 hi all, 1- You'll find me boring but I'd prefer not to see in section 4.2 that a S-CSCF could be dual-stack. To my mind that would mean that IMS would not be IPv6-only anymore?! ref. section 4.2 "If the S-CSCF is dual stack capable, the ALG specific functions can be done in the S-CSCF directly, i.e. changing the SIP message headers, and the SDP payload. " 2- I'm till ill at ease will the fact that NAT-PT is till the only solution mentioned even if that solution is none to be not enough efficient. Is IETF allowed to propose 3GPP other solutions ? How to do that ? Regards, Luc > -----Message d'origine----- > De : juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Envoyé : mardi 5 novembre 2002 12:03 > À : v6ops@ops.ietf.org > Objet : 3gpp transition solutions, revision -02 > > > > Hi all, > > a new version of the 3GPP (cellular) network design team > solutions draft is available here: > > http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-t > ransition-02.txt > > All comments are appreciated a lot. > > Cheers, > -Juha W.- > > > From owner-v6ops@ops.ietf.org Tue Nov 5 13:52:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05132 for ; Tue, 5 Nov 2002 13:52:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 1898p8-0005az-00 for v6ops-data@psg.com; Tue, 05 Nov 2002 10:53:14 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 1898p6-0005an-00 for v6ops@ops.ietf.org; Tue, 05 Nov 2002 10:53:12 -0800 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA5Ir9KV007132; Tue, 5 Nov 2002 19:53:09 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 5 Nov 2002 19:53:08 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C8C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'BELOEIL Luc FTRD/DMI/CAE'" , juha.wiljakka@nokia.com, v6ops@ops.ietf.org Subject: RE: 3gpp transition solutions, revision -02 Date: Tue, 5 Nov 2002 19:53:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Status: No, hits=-1.2 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > 2- I'm till ill at ease will the fact that NAT-PT is till > the only solution mentioned even if that solution is none > to be not enough efficient. Is IETF allowed to propose 3GPP > other solutions ? => Sure. How to do that ? => You have to have a solution first :) There were several discussions about taking the ALG out of NAT-PT, but we don't have a WG doc. Hesham From owner-v6ops@ops.ietf.org Wed Nov 6 06:33:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12964 for ; Wed, 6 Nov 2002 06:33:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189OS1-0009cI-00 for v6ops-data@psg.com; Wed, 06 Nov 2002 03:34:25 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 189ORz-0009c6-00 for v6ops@ops.ietf.org; Wed, 06 Nov 2002 03:34:23 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA6BXtO07824 for ; Wed, 6 Nov 2002 13:33:55 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Nov 2002 13:34:20 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 13:34:20 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 3gpp transition solutions, revision -02 Date: Wed, 6 Nov 2002 13:34:19 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3599@esebe005.ntc.nokia.com> Thread-Topic: 3gpp transition solutions, revision -02 Thread-Index: AcKEutZaBbI+0mDFQTy5NaUOPiwWSQANvzuQACTdkYA= From: To: , , X-OriginalArrivalTime: 06 Nov 2002 11:34:20.0876 (UTC) FILETIME=[72DA70C0:01C28588] X-Spam-Status: No, hits=-6.1 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, SUPERLONG_LINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA12964 Hi, Luc! 1) As 3GPP specification TS 23.221 v.5.5.0 says: "The UMTS/GSM architecture shall support IPv4 / IPv6 based on the statements below. - IP transport between network elements of the IP Connectivity services (between RNC, SGSN and GGSN) and IP transport for the CS Domain: both IPv4 / IPv6 are options for IP Connectivity -IM CN subsystem elements (UE to CSCF and the other elements e.g. MRF): - The architecture shall make optimum use of IPv6. - The IM CN subsystem shall exclusively support IPv6. - The UE shall exclusively support IPv6 for the connection to services provided by the IM CN subsystem. ..." => IMS *is* IPv6-only for both UE - CSCF and IMS internal interfaces. Yep, the text is just an "if" statement and in my opinion could be removed from the solutions doc. 2) Well, can you suggest something? As Hesham pointed out, there should be a standardized solution to be proposed to the 3GPP. I would like also to remind that our design team aims not to specify new transition mechanisms or propose changes to 3GPP specs. We just make a "gap analysis" on the exisiting transition tools and their usability in 3GPP environment. And we will report our findings to the v6ops wg. NAT-PT does have issues, the issues pointed out in section 3.4 are relevant in chapter 4 as well. The issues discussed in v6ops Interim meeting can be found in "3GPP breakout report" http://www.6bone.net/v6ops/minutes/default.htm BR, -Juha- -----Original Message----- From: ext BELOEIL Luc FTRD/DMI/CAE [mailto:luc.beloeil@rd.francetelecom.com] 1- You'll find me boring but I'd prefer not to see in section 4.2 that a S-CSCF could be dual-stack. To my mind that would mean that IMS would not be IPv6-only anymore?! ref. section 4.2 "If the S-CSCF is dual stack capable, the ALG specific functions can be done in the S-CSCF directly, i.e. changing the SIP message headers, and the SDP payload. " 2- I'm till ill at ease will the fact that NAT-PT is till the only solution mentioned even if that solution is none to be not enough efficient. Is IETF allowed to propose 3GPP other solutions ? How to do that ? > -----Message d'origine----- > De : juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Envoyé : mardi 5 novembre 2002 12:03 > À : v6ops@ops.ietf.org > Objet : 3gpp transition solutions, revision -02 > > > > Hi all, > > a new version of the 3GPP (cellular) network design team > solutions draft is available here: > > http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-t > ransition-02.txt > > All comments are appreciated a lot. > > Cheers, > -Juha W.- > > > From owner-v6ops@ops.ietf.org Wed Nov 6 06:59:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14148 for ; Wed, 6 Nov 2002 06:59:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189OsO-000BYi-00 for v6ops-data@psg.com; Wed, 06 Nov 2002 04:01:40 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 189OsL-000BYQ-00 for v6ops@ops.ietf.org; Wed, 06 Nov 2002 04:01:39 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 17:30:36 +0530 Message-ID: From: "Thakur, Anand" To: juha.wiljakka@nokia.com Cc: ngtrans@sunroof.eng.sun.com, luc.beloeil@rd.francetelecom.com, v6ops@ops.ietf.org Subject: 3gpp transition solutions Date: Wed, 6 Nov 2002 17:36:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-1.2 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk hi all, i have released a draft proposing solutions to different 3gpp transition scenarios (GPRS only). i am in the final year of my enginering course and very new to this field so i will appreciate any comments. please follow the following url. http://www.ietf.org/internet-drafts/draft-thakur-v6ops-3gpp-cases-00.txt thanks a lot anand From owner-v6ops@ops.ietf.org Wed Nov 6 07:18:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14900 for ; Wed, 6 Nov 2002 07:18:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189PAK-000Crx-00 for v6ops-data@psg.com; Wed, 06 Nov 2002 04:20:12 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #2) id 189PAI-000Crk-00 for v6ops@ops.ietf.org; Wed, 06 Nov 2002 04:20:10 -0800 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA6CKbB27661 for ; Wed, 6 Nov 2002 14:20:37 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Nov 2002 14:20:07 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 14:20:07 +0200 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 3gpp transition solutions Date: Wed, 6 Nov 2002 14:20:07 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FCE52D1@esebe005.ntc.nokia.com> Thread-Topic: 3gpp transition solutions Thread-Index: AcKFjEfNin3JDgsDS8ypcytcyCxssgAAbZxQ From: To: Cc: X-OriginalArrivalTime: 06 Nov 2002 12:20:07.0983 (UTC) FILETIME=[D841B3F0:01C2858E] X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA14900 Anand, there is already a design team working on these issues in the v6ops design team. The current working documents are: 3GPP Scenarios document: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-00.txt 3GPP Solutions document: http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-transition-02.txt What is the scope of your document? Cheers, -Juha W.- -----Original Message----- From: ext Thakur, Anand [mailto:Anand.Thakur@hpsglobal.com] Sent: 06 November, 2002 14:06 To: Wiljakka Juha (NMP/Tampere) Cc: ngtrans@sunroof.eng.sun.com; luc.beloeil@rd.francetelecom.com; v6ops@ops.ietf.org Subject: 3gpp transition solutions hi all, i have released a draft proposing solutions to different 3gpp transition scenarios (GPRS only). i am in the final year of my enginering course and very new to this field so i will appreciate any comments. please follow the following url. http://www.ietf.org/internet-drafts/draft-thakur-v6ops-3gpp-cases-00.txt thanks a lot anand From owner-v6ops@ops.ietf.org Wed Nov 6 11:51:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01225 for ; Wed, 6 Nov 2002 11:51:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189TQJ-0007qf-00 for v6ops-data@psg.com; Wed, 06 Nov 2002 08:52:59 -0800 Received: from parsmtp2.rd.francetelecom.com ([194.167.105.14]) by psg.com with esmtp (Exim 3.36 #2) id 189TQH-0007qT-00 for v6ops@ops.ietf.org; Wed, 06 Nov 2002 08:52:57 -0800 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Nov 2002 17:52:55 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: 3gpp transition solutions, revision -02 Date: Wed, 6 Nov 2002 17:52:55 +0100 Message-ID: Thread-Topic: 3gpp transition solutions, revision -02 Thread-Index: AcKE/JaBAQD6oX5GRNSo2vQvDsoeGwAtZHgA From: "BELOEIL Luc FTRD/DMI/CAE" To: "Hesham Soliman (EAB)" , , , Cc: "MARTIQUET Nicolas FTRD/DMR/ISS" X-OriginalArrivalTime: 06 Nov 2002 16:52:55.0866 (UTC) FILETIME=[F44671A0:01C285B4] X-Spam-Status: No, hits=-4.2 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA01225 > > > 2- I'm till ill at ease will the fact that NAT-PT is till > > the only solution mentioned even if that solution is none > > to be not enough efficient. Is IETF allowed to propose 3GPP > > other solutions ? > > => Sure. > > How to do that ? > > => You have to have a solution first :) > There were several discussions about taking the > ALG out of NAT-PT, but we don't have a WG doc. > > Hesham > > Alain Baudot reminds me that some have already outlined the possibility to use tunneling mechanisms (+ ROHC to optimize performances) so as to solve the issue: -> dual-stack UE connecting to a node via an IPv4 network through IMS That could be easily an IETF solution but I do not think that 3GPP proposes any mechanism to allocate IPv4 address when required, does it ? Luc From owner-v6ops@ops.ietf.org Wed Nov 6 14:29:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08261 for ; Wed, 6 Nov 2002 14:29:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189VsT-000LTz-00 for v6ops-data@psg.com; Wed, 06 Nov 2002 11:30:13 -0800 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 189VsR-000LTa-00 for v6ops@ops.ietf.org; Wed, 06 Nov 2002 11:30:11 -0800 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA6JU2Q1004274; Wed, 6 Nov 2002 20:30:07 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 6 Nov 2002 20:30:02 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0C99@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'BELOEIL Luc FTRD/DMI/CAE'" , juha.wiljakka@nokia.com, v6ops@ops.ietf.org, Jonne.Soininen@nokia.com Cc: MARTIQUET Nicolas FTRD/DMR/ISS Subject: RE: 3gpp transition solutions, revision -02 Date: Wed, 6 Nov 2002 20:30:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Status: No, hits=-2.5 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_02_03 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > 2- I'm till ill at ease will the fact that NAT-PT is till > > > the only solution mentioned even if that solution is none > > > to be not enough efficient. Is IETF allowed to propose 3GPP > > > other solutions ? > > > > => Sure. > > > > How to do that ? > > > > => You have to have a solution first :) > > There were several discussions about taking the > > ALG out of NAT-PT, but we don't have a WG doc. > > > > Hesham > > > > > Alain Baudot reminds me that some have already outlined the > possibility to use tunneling mechanisms (+ ROHC to optimize > performances) so as to solve the issue: => In theory, yes. But we need to get an IP n IP profile for ROHC. Pretty easily done. > -> dual-stack UE connecting to a node via an IPv4 network > through IMS => ok. That's what ISATAP gives us. I do not think > that 3GPP proposes any mechanism to allocate IPv4 address > when required, does it ? => Yes, it does. They're defined in TS.23060. Ideally you don't want to run too many PDP contexts, they take time and add significant state to GGSNs and terminals. Hesham From owner-v6ops@ops.ietf.org Wed Nov 6 23:00:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22708 for ; Wed, 6 Nov 2002 23:00:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189dqe-000NON-00 for v6ops-data@psg.com; Wed, 06 Nov 2002 20:00:52 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 189dqc-000NOA-00 for v6ops@ops.ietf.org; Wed, 06 Nov 2002 20:00:50 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Nov 2002 09:29:46 +0530 Message-ID: From: "Thakur, Anand" To: juha.wiljakka@nokia.com Cc: v6ops@ops.ietf.org, ngtrans@sunroof.eng.sun.com Subject: RE: 3gpp transition solutions Date: Thu, 7 Nov 2002 09:35:30 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-6.0 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk juha, my document basically deals with scenarios without the use of the SIP based IP Multimedia Core Network Subsystem (IMS). i have felt the need for a new transition mechanism, especially in the scenario where ipv6 UEs communicate over ipv4 network. this new mechanism is basically a slight modification of the existing nat-pt mechanism. i will soon release a more precise and elaborate version of this draft(-01). thanks a lot for your comments. regards, anand. > -----Original Message----- > From: juha.wiljakka@nokia.com [SMTP:juha.wiljakka@nokia.com] > Sent: Wednesday, November 06, 2002 5:50 PM > To: Anand.Thakur@hpsglobal.com > Cc: v6ops@ops.ietf.org > Subject: RE: 3gpp transition solutions > > Anand, > > there is already a design team working on these issues in the v6ops design > team. The current working documents are: > > 3GPP Scenarios document: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-00.txt > > 3GPP Solutions document: > http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-transition-02 > .txt > > What is the scope of your document? > > Cheers, > -Juha W.- > > -----Original Message----- > From: ext Thakur, Anand [mailto:Anand.Thakur@hpsglobal.com] > Sent: 06 November, 2002 14:06 > To: Wiljakka Juha (NMP/Tampere) > Cc: ngtrans@sunroof.eng.sun.com; luc.beloeil@rd.francetelecom.com; > v6ops@ops.ietf.org > Subject: 3gpp transition solutions > > > hi all, > i have released a draft proposing solutions to different 3gpp transition > scenarios (GPRS only). i am in the final year of my enginering course and > very new to this field so i will appreciate any comments. > please follow the following url. > > http://www.ietf.org/internet-drafts/draft-thakur-v6ops-3gpp-cases-00.txt > > thanks a lot > anand > > From owner-v6ops@ops.ietf.org Thu Nov 7 08:09:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20434 for ; Thu, 7 Nov 2002 08:09:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189mQR-0001pL-00 for v6ops-data@psg.com; Thu, 07 Nov 2002 05:10:23 -0800 Received: from parsmtp1.rd.francetelecom.com ([194.167.105.13]) by psg.com with esmtp (Exim 3.36 #2) id 189mQP-0001p9-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 05:10:21 -0800 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 14:10:14 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: 3gpp transition solutions, revision -02 Date: Thu, 7 Nov 2002 14:10:13 +0100 Message-ID: Thread-Topic: 3gpp transition solutions, revision -02 Thread-Index: AcKFyus1lzBIwPFQTBCDwxYoOBgILQAkZf/g From: "BELOEIL Luc FTRD/DMI/CAE" To: "Hesham Soliman (EAB)" , , , Cc: "MARTIQUET Nicolas FTRD/DMR/ISS" X-OriginalArrivalTime: 07 Nov 2002 13:10:14.0203 (UTC) FILETIME=[028438B0:01C2865F] X-Spam-Status: No, hits=-5.1 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA20434 Thanks a lot for all our remarks, > > Alain Baudot reminds me that some have already outlined the > > possibility to use tunneling mechanisms (+ ROHC to optimize > > performances) so as to solve the issue: > > => In theory, yes. But we need to get an IP n IP profile > for ROHC. Pretty easily done. > ok, and that sounds better than using translation mechanisms. > > -> dual-stack UE connecting to a node via an IPv4 network > > through IMS > > => ok. That's what ISATAP gives us. > Yep, ISATAP is one of tunneling solutions. > I do not think > > that 3GPP proposes any mechanism to allocate IPv4 address > > when required, does it ? > > => Yes, it does. They're defined in TS.23060. > Ideally you don't want to run too many PDP contexts, > they take time and add significant state to GGSNs and > terminals. > > Hesham > I've just tried to check that big document (TS.23060). But I did not find your point. Anyway, if you say that is possible, I think that this case and solution (dual-stack UE connecting to a node via an IPv4 network through IMS) should be mentioned in: draft-ietf-v6ops-3gpp-cases-00.txt and draft-wiljakka-3gpp-ipv6-transition-02.txt Do you agree? regards, Luc From owner-v6ops@ops.ietf.org Thu Nov 7 09:58:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26747 for ; Thu, 7 Nov 2002 09:58:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189o8C-000CBO-00 for v6ops-data@psg.com; Thu, 07 Nov 2002 06:59:40 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 189o8A-000CBC-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 06:59:38 -0800 Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA7ExaKW017458 for ; Thu, 7 Nov 2002 15:59:37 +0100 (MET) Received: by esealnt611.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 7 Nov 2002 15:59:36 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0CB1@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'BELOEIL Luc FTRD/DMI/CAE'" , juha.wiljakka@nokia.com, v6ops@ops.ietf.org, Jonne.Soininen@nokia.com Cc: MARTIQUET Nicolas FTRD/DMR/ISS Subject: RE: 3gpp transition solutions, revision -02 Date: Thu, 7 Nov 2002 15:59:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-1.2 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > => In theory, yes. But we need to get an IP n IP profile > > for ROHC. Pretty easily done. > > > > ok, and that sounds better than using translation mechanisms. => Sorry, I don't think this has anything to do with replacing translation. We're talking about two different cases. I was trying to explain that tunnelling overhead, over the air interface can be removed with ROHC. That doesn't mean that IPv6 UEs will not talk to IPv4 UEs. > I've just tried to check that big document (TS.23060). But > I did not find your point. Anyway, if you say that is > possible, I think that this case and solution (dual-stack > UE connecting to a node via an IPv4 network through IMS) => I'm sorry, I don't mean to confuse you, but I was saying that it is possible to allocate IPv4 addresses to UEs and that it is explained in TS.23.060. This TS says nothing about V4 - V6 coexistence issues Hesham From owner-v6ops@ops.ietf.org Thu Nov 7 11:20:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00602 for ; Thu, 7 Nov 2002 11:20:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189pO1-000Jgv-00 for v6ops-data@psg.com; Thu, 07 Nov 2002 08:20:05 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #2) id 189pNx-000Jad-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 08:20:01 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gA7GJMjT049856; Thu, 7 Nov 2002 17:19:22 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gA7GJKU7063806; Thu, 7 Nov 2002 17:19:21 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA43232 from ; Thu, 7 Nov 2002 17:19:18 +0100 Message-Id: <3DCA9277.1FF92DB5@hursley.ibm.com> Date: Thu, 07 Nov 2002 17:19:03 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Hesham Soliman (EAB)" Cc: v6ops@ops.ietf.org Subject: Re: 3gpp transition solutions, revision -02 References: <4DA6EA82906FD511BE2F00508BCF0538044F0CB1@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Hesham Soliman (EAB)" wrote: > > > > => In theory, yes. But we need to get an IP n IP profile > > > for ROHC. Pretty easily done. > > > > > > > ok, and that sounds better than using translation mechanisms. > > => Sorry, I don't think this has anything to do with replacing > translation. We're talking about two different cases. I was > trying to explain that tunnelling overhead, over the air interface > can be removed with ROHC. That doesn't mean that IPv6 UEs will > not talk to IPv4 UEs. What is the plan for apps that are broken by NAT? Won't the supported apps be relatively few, and better handled by dual stack application proxies than by NAT-PT? Brian From owner-v6ops@ops.ietf.org Thu Nov 7 11:21:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00631 for ; Thu, 7 Nov 2002 11:21:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189pRp-000K5G-00 for v6ops-data@psg.com; Thu, 07 Nov 2002 08:24:01 -0800 Received: from parsmtp1.rd.francetelecom.com ([194.167.105.13]) by psg.com with esmtp (Exim 3.36 #2) id 189pRo-000K54-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 08:24:00 -0800 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 17:23:58 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: 3gpp transition solutions, revision -02 Date: Thu, 7 Nov 2002 17:23:57 +0100 Message-ID: Thread-Topic: 3gpp transition solutions, revision -02 Thread-Index: AcKGbkq5QpAaBNjdSTWMInk8cuY8lQACRLCA From: "BELOEIL Luc FTRD/DMI/CAE" To: "Hesham Soliman (EAB)" , , , Cc: "MARTIQUET Nicolas FTRD/DMR/ISS" X-OriginalArrivalTime: 07 Nov 2002 16:23:58.0687 (UTC) FILETIME=[133FB6F0:01C2867A] X-Spam-Status: No, hits=-5.1 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA00631 I'm sad now ;+) Even if I will own a dual-stack UE, I won't be able to communicate with my IPv4 stack if that communication was initiated through IMS :+(. I'll be forced to use my IPv6 stack and go through a surely less efficient translation mechanism (in comparison with native end-to-end IPv4). I can not agree with that. As you said tunneling is an option, so what about DSTM (that solves temporary IPv4 address assignement, and allow the use of end-to-end native IPv4 flows) ?! Luc > -----Message d'origine----- > De : Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > Envoyé : jeudi 7 novembre 2002 16:00 > À : BELOEIL Luc FTRD/DMI/CAE; juha.wiljakka@nokia.com; > v6ops@ops.ietf.org; Jonne.Soininen@nokia.com > Cc : MARTIQUET Nicolas FTRD/DMR/ISS > Objet : RE: 3gpp transition solutions, revision -02 > > > > > > => In theory, yes. But we need to get an IP n IP profile > > > for ROHC. Pretty easily done. > > > > > > > ok, and that sounds better than using translation mechanisms. > > => Sorry, I don't think this has anything to do with replacing > translation. We're talking about two different cases. I was > trying to explain that tunnelling overhead, over the air interface > can be removed with ROHC. That doesn't mean that IPv6 UEs will > not talk to IPv4 UEs. > > > I've just tried to check that big document (TS.23060). But > > I did not find your point. Anyway, if you say that is > > possible, I think that this case and solution (dual-stack > > UE connecting to a node via an IPv4 network through IMS) > > => I'm sorry, I don't mean to confuse you, but I was > saying that it is possible to allocate IPv4 addresses to > UEs and that it is explained in TS.23.060. This TS says > nothing about V4 - V6 coexistence issues > > Hesham > > From owner-v6ops@ops.ietf.org Thu Nov 7 11:43:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01388 for ; Thu, 7 Nov 2002 11:43:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189plm-000M3r-00 for v6ops-data@psg.com; Thu, 07 Nov 2002 08:44:38 -0800 Received: from parsmtp1.rd.francetelecom.com ([194.167.105.13]) by psg.com with esmtp (Exim 3.36 #2) id 189pli-000M0V-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 08:44:36 -0800 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 17:44:15 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: 3gpp transition solutions, revision -02 Date: Thu, 7 Nov 2002 17:44:14 +0100 Message-ID: Thread-Topic: 3gpp transition solutions, revision -02 Thread-Index: AcKGfDfavrnCtYlmTmyROc5ejVTLNwAACbhw From: "BELOEIL Luc FTRD/DMI/CAE" To: "Brian E Carpenter" , "Hesham Soliman (EAB)" Cc: X-OriginalArrivalTime: 07 Nov 2002 16:44:15.0695 (UTC) FILETIME=[E8A465F0:01C2867C] X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA01388 > De : Brian E Carpenter [mailto:brian@hursley.ibm.com] > > "Hesham Soliman (EAB)" wrote: > > > > > > => In theory, yes. But we need to get an IP n IP profile > > > > for ROHC. Pretty easily done. > > > > > > > > > > ok, and that sounds better than using translation mechanisms. > > > > => Sorry, I don't think this has anything to do with replacing > > translation. We're talking about two different cases. I was > > trying to explain that tunnelling overhead, over the air interface > > can be removed with ROHC. That doesn't mean that IPv6 UEs will > > not talk to IPv4 UEs. > > What is the plan for apps that are broken by NAT? Won't the > supported apps be relatively few, and better handled by dual stack > application proxies than by NAT-PT? > > Brian > The main situation where NAT-PT has been chosen by 3GPP is the services provided by IMS. IMS services are only SIP-based services. For SIP-based services an application proxy is not sufficient. Luc From owner-v6ops@ops.ietf.org Thu Nov 7 11:50:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01575 for ; Thu, 7 Nov 2002 11:50:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189pt4-000Mjv-00 for v6ops-data@psg.com; Thu, 07 Nov 2002 08:52:10 -0800 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 189pt2-000Mji-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 08:52:08 -0800 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA7Gq5Q1010870; Thu, 7 Nov 2002 17:52:05 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 7 Nov 2002 17:52:05 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0CB7@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'BELOEIL Luc FTRD/DMI/CAE'" , "Hesham Soliman (EAB)" , juha.wiljakka@nokia.com, v6ops@ops.ietf.org, Jonne.Soininen@nokia.com Cc: MARTIQUET Nicolas FTRD/DMR/ISS Subject: RE: 3gpp transition solutions, revision -02 Date: Thu, 7 Nov 2002 17:52:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-1.2 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I'm sad now ;+) > > Even if I will own a dual-stack UE, I won't be able to > communicate with my IPv4 stack if that communication was > initiated through IMS :+(. I'll be forced to use my IPv6 > stack and go through a surely less efficient translation > mechanism (in comparison with native end-to-end IPv4). > > I can not agree with that. => ok fair enough. But please understand that this decision (IPv6 only in IMS) was taken by 3GPP about 2 years ago and the specs are frozen. We are working within 3GPP specs. Hesham From owner-v6ops@ops.ietf.org Thu Nov 7 11:56:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01803 for ; Thu, 7 Nov 2002 11:56:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189pzZ-000NSp-00 for v6ops-data@psg.com; Thu, 07 Nov 2002 08:58:53 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 189pzW-000NSc-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 08:58:51 -0800 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA7GwmKW021362; Thu, 7 Nov 2002 17:58:48 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 7 Nov 2002 17:58:48 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0CB8@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Brian E Carpenter'" Cc: v6ops@ops.ietf.org Subject: RE: 3gpp transition solutions, revision -02 Date: Thu, 7 Nov 2002 17:58:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-1.2 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > > => In theory, yes. But we need to get an IP n IP profile > > > > for ROHC. Pretty easily done. > > > > > > > > > > ok, and that sounds better than using translation mechanisms. > > > > => Sorry, I don't think this has anything to do with replacing > > translation. We're talking about two different cases. I was > > trying to explain that tunnelling overhead, over the air interface > > can be removed with ROHC. That doesn't mean that IPv6 UEs will > > not talk to IPv4 UEs. > > What is the plan for apps that are broken by NAT? => Broken by NATv4 or NAT-PT or both? If both, then there is no difference. Won't the > supported apps be relatively few, and better handled by dual stack > application proxies than by NAT-PT? => I'm sure there will be application proxies for well-known and popular apps (HTTP, email ...etc), but not for every single one. I understood that the discussion was focused on IMS signalling for p2p apps. 3GPP mandates that this be done using IPv6. The good thing about that is that it encourages IPv6 deployment and thanks to this decision every phone vendor will support v6, if they haven't already. As for availability of apps on NAT-PT, this is probably getting a bit speculative for me. I don't know if it's too difficult to port the NATv4 ones to NAT-PT, but anyway if I have to guess I would say that if there is enough demand, I'm sure it will be done. Hesham From owner-v6ops@ops.ietf.org Thu Nov 7 12:22:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02904 for ; Thu, 7 Nov 2002 12:22:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189qNv-000Pto-00 for v6ops-data@psg.com; Thu, 07 Nov 2002 09:24:03 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 189qNt-000PtY-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 09:24:02 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA7HLPl10352; Thu, 7 Nov 2002 12:21:26 -0500 (EST) Message-Id: <200211071721.gA7HLPl10352@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "BELOEIL Luc FTRD/DMI/CAE" cc: "Brian E Carpenter" , "Hesham Soliman (EAB)" , v6ops@ops.ietf.org Subject: Re: 3gpp transition solutions, revision -02 In-reply-to: (Your message of "Thu, 07 Nov 2002 17:44:14 +0100.") Date: Thu, 07 Nov 2002 12:21:25 -0500 X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > For SIP-based services an application proxy is not sufficient. and NAT-PT is sufficient? from my limited knowledge of SIP I find this surprising. however I don't see a huge problem with using NAT-PT only for a specific set of well-defined services on networks with known characteristics; presumably it can be adapted as needed to accomodate those services. the imposition of NAT-PT on other services is of course a separate question. From owner-v6ops@ops.ietf.org Thu Nov 7 14:23:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07021 for ; Thu, 7 Nov 2002 14:23:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189sHB-000COO-00 for v6ops-data@psg.com; Thu, 07 Nov 2002 11:25:13 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 189sH9-000CN9-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 11:25:11 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA07145; Thu, 7 Nov 2002 11:24:40 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA7JOdG31986; Thu, 7 Nov 2002 11:24:39 -0800 X-mProtect: <200211071924> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdunuxg1; Thu, 07 Nov 2002 11:24:37 PST Message-ID: <3DCABEF1.3070003@iprg.nokia.com> Date: Thu, 07 Nov 2002 11:28:49 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org Subject: Re: (ngtrans) NUD for ISATAP Routers Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Karen, The co-authors discussed this issue in some detail, and the intended meaning of the base specification is that ISATAP nodes SHOULD send NSs and MUST send solicited NAs to establish neighbor cache state even though address resolution is done via static computation. So, the functionality is recommended (but optional) for the source and mandatory for the target. Even so, there may be an operational issue for ISATAP routers when the base specification alone is used, since hints of forward progress probably will not be available from upper layers, i.e., reliable transport connections are normally forwarded *through* the router; not terminated *at* the router. If alternate paths exist, this could result in a unidirectional link *from* the ISATAP source node *to* the next-hop ISATAP router, which may cause operational problems in some cases. When the base specification alone is used, one implementation alternative that will satisfy many deployment scenarios is to restrict ISATAP nodes to accepting packets from and sending packets to *exactly one* ISATAP router; even though numerous potential routers may be available. But, a more generalized, robust, secure, and scalable alternative is to provide optional extensions to the base specification that ensure link bi-directionality even when alternate paths exist. Such an optional extension is proposed here: http://www.ietf.org/internet-drafts/draft-templin-v6v4-ndisc-01.txt Does this help clarify things? Fred Templin ftemplin@iprg.nokia.com Karen E Nielsen (TED) wrote: > Hi, > > Looking into the latest Isatap draft (v06) I am (still) puzzled by the fact > (Section 5.1) that ISATAP nodes SHOULD perform NUD in accordance with RFC 2461, > although we all agree (I think) that NUD in accordance with RFc 2461 doesn't work > for ISATAP routers - > What NUD functionality do you demand (SHOULD) on an ISATAP Router interface ??? > > Karen From owner-v6ops@ops.ietf.org Thu Nov 7 17:31:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16185 for ; Thu, 7 Nov 2002 17:31:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189vDO-00060V-00 for v6ops-data@psg.com; Thu, 07 Nov 2002 14:33:30 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 189vDN-000609-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 14:33:29 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 189vDN-000BTB-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 14:33:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: The IESG To: All IETF Working Groups: ; Subject: Note Well Statement Date: Thu, 07 Nov 2002 15:11:40 -0500 X-Spam-Status: No, hits=-0.9 required=5.0 tests=RESENT_TO,SPAM_PHRASE_01_02,TO_HAS_SPACES,TO_MALFORMED version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit >From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-v6ops@ops.ietf.org Thu Nov 7 17:33:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16237 for ; Thu, 7 Nov 2002 17:33:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189vFX-0006Gi-00 for v6ops-data@psg.com; Thu, 07 Nov 2002 14:35:43 -0800 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 189vFV-0006AA-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 14:35:41 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA7MYwxF018625; Thu, 7 Nov 2002 14:34:58 -0800 (PST) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.0-GA) with ESMTP id ABF43078; Thu, 7 Nov 2002 14:35:26 -0800 (PST) Date: Thu, 7 Nov 2002 14:35:05 -0800 (PST) From: Suresh K Satapati To: BELOEIL Luc FTRD/DMI/CAE cc: "Hesham Soliman (EAB)" , , , , MARTIQUET Nicolas FTRD/DMR/ISS Subject: RE: 3gpp transition solutions, revision -02 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-Spam-Status: No, hits=-7.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id RAA16237 > I'm sad now ;+) > > Even if I will own a dual-stack UE, I won't be able to communicate with my IPv4 stack > if that communication was initiated through IMS :+(. I'll be forced to use my IPv6 > stack and go through a surely less efficient translation mechanism (in comparison with > native end-to-end IPv4). > > I can not agree with that. with the current state of NAT-PT, yes. but this is something that can be fixed. there were some other problems raised by design teams, we need to put all of those together and address them. -Suresh > > > > -----Message d'origine----- > > De : Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > > Envoyé : jeudi 7 novembre 2002 16:00 > > À : BELOEIL Luc FTRD/DMI/CAE; juha.wiljakka@nokia.com; > > v6ops@ops.ietf.org; Jonne.Soininen@nokia.com > > Cc : MARTIQUET Nicolas FTRD/DMR/ISS > > Objet : RE: 3gpp transition solutions, revision -02 > > > > > > > > > > => In theory, yes. But we need to get an IP n IP profile > > > > for ROHC. Pretty easily done. > > > > > > > > > > ok, and that sounds better than using translation mechanisms. > > > > => Sorry, I don't think this has anything to do with replacing > > translation. We're talking about two different cases. I was > > trying to explain that tunnelling overhead, over the air interface > > can be removed with ROHC. That doesn't mean that IPv6 UEs will > > not talk to IPv4 UEs. > > > > > I've just tried to check that big document (TS.23060). But > > > I did not find your point. Anyway, if you say that is > > > possible, I think that this case and solution (dual-stack > > > UE connecting to a node via an IPv4 network through IMS) > > > > => I'm sorry, I don't mean to confuse you, but I was > > saying that it is possible to allocate IPv4 addresses to > > UEs and that it is explained in TS.23.060. This TS says > > nothing about V4 - V6 coexistence issues > > > > Hesham > > > > > > From owner-v6ops@ops.ietf.org Thu Nov 7 20:41:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20648 for ; Thu, 7 Nov 2002 20:41:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189yAa-000Pdh-00 for v6ops-data@psg.com; Thu, 07 Nov 2002 17:42:48 -0800 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by psg.com with esmtp (Exim 3.36 #2) id 189yAY-000PdV-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 17:42:46 -0800 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA81hSx10329 for ; Thu, 7 Nov 2002 19:43:28 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 7 Nov 2002 19:42:45 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 19:42:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 3gpp transition solutions, revision -02 Date: Thu, 7 Nov 2002 17:42:42 -0800 Message-ID: <4D7B558499107545BB45044C63822DDEEBDB54@mvebe001.americas.nokia.com> Thread-Topic: 3gpp transition solutions, revision -02 Thread-Index: AcKGokOFImlFs5KuTDaOCQi1Kodi6QAI0PXw From: To: , Cc: , , X-OriginalArrivalTime: 08 Nov 2002 01:42:43.0401 (UTC) FILETIME=[21891B90:01C286C8] X-Spam-Status: No, hits=-5.9 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, SUPERLONG_LINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA20648 Hi, sorry to step into the discussion so late. (I had computer trouble for a while!) I would like to remind everybody that as IMS is _exclusively_ IPv6, and the NAT-PT (or a flavor of that) is just an interworking solution to a non-IMS network that supports IMS like services. (Confusing enough?;) This means that IMS itself has no interworking problems, no NATs, no NAT-PTs, and no IPv4 - it is only IPv6. Thus, there are no problems inside the IMS. The NAT-PT would come to the picture if, for instance, you have to place a call to another "system" that does not support v6. (It may be that you have to do another kind of translation as well, e.g. SIP to H.323, or SIP to ISUP, or whatever.) The NAT-PT would be an interworking function to an outside world - not an internal part! People seem to write all the time that with dual-stack you can fix the interworking problems of IMS. That however is not true, because you end up with normal NAT for your IPv4 connections. You cannot get (at least in certain areas of the world) enough IPv4 addresses to even support it as an interworking method and to have global addresses. In addition, you end up having a dual-stack in your phones until the end of time or to the point where the last _possible_ IPv4 device in the world would be extinct! These are just some of the reasons why 3GPP decided to have IPv6 only IMS. Anyways, the 3GPP specifications (as Hesham pointed out) now say that this network/system, the IMS, is exclusively IPv6. We cannot change the specs, and there is no reason for changing them - the contrary. I would propose that we concentrate now on solving the problem instead of changing the problem. Cheers, Jonne. > -----Original Message----- > From: ext Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, November 07, 2002 9:21 AM > To: BELOEIL Luc FTRD/DMI/CAE > Cc: Brian E Carpenter; Hesham Soliman (EAB); v6ops@ops.ietf.org > Subject: Re: 3gpp transition solutions, revision -02 > > > > For SIP-based services an application proxy is not sufficient. > > and NAT-PT is sufficient? from my limited knowledge of SIP I > find this > surprising. > > however I don't see a huge problem with using NAT-PT only for > a specific > set of well-defined services on networks with known characteristics; > presumably it can be adapted as needed to accomodate those services. > > the imposition of NAT-PT on other services is of course a > separate question. > > From owner-v6ops@ops.ietf.org Thu Nov 7 21:32:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21757 for ; Thu, 7 Nov 2002 21:32:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 189yyM-0004FA-00 for v6ops-data@psg.com; Thu, 07 Nov 2002 18:34:14 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 189yyK-0004Ex-00 for v6ops@ops.ietf.org; Thu, 07 Nov 2002 18:34:12 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gA82Wnl19113; Thu, 7 Nov 2002 21:32:49 -0500 (EST) Message-Id: <200211080232.gA82Wnl19113@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jonne.Soininen@nokia.com cc: moore@cs.utk.edu, luc.beloeil@rd.francetelecom.com, brian@hursley.ibm.com, hesham.soliman@era.ericsson.se, v6ops@ops.ietf.org Subject: Re: 3gpp transition solutions, revision -02 In-reply-to: (Your message of "Thu, 07 Nov 2002 17:42:42 PST.") <4D7B558499107545BB45044C63822DDEEBDB54@mvebe001.americas.nokia.com> Date: Thu, 07 Nov 2002 21:32:49 -0500 X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk thanks for the explanation. the approach makes sense to me. Keith > I would like to remind everybody that as IMS is _exclusively_ IPv6, and the > NAT-PT (or a flavor of that) is just an interworking solution to a non-IMS > network that supports IMS like services. (Confusing enough?;) From owner-v6ops@ops.ietf.org Fri Nov 8 07:11:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14077 for ; Fri, 8 Nov 2002 07:11:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18A7y9-0001Ww-00 for v6ops-data@psg.com; Fri, 08 Nov 2002 04:10:37 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 18A6qj-0000pL-00 for v6ops@ops.ietf.org; Fri, 08 Nov 2002 02:58:53 -0800 Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA8AwlKV002723; Fri, 8 Nov 2002 11:58:47 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WPTS6WR7; Fri, 8 Nov 2002 11:58:47 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Nov 2002 11:51:53 +0100 Message-ID: <387F69AC05062649946B28CFA0FD620C019F72BD@esealnt853.al.sw.ericsson.se> X-Sybari-Trust: 8772d163 ca231590 d342b509 00000138 From: "Karen E Nielsen (TED)" To: "'Fred L. Templin'" , ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org Subject: RE: (ngtrans) NUD for ISATAP Routers Date: Fri, 8 Nov 2002 11:58:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-4.7 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Fred, I can see lots of reasons for demanding an Isatap HOST to perform NUD on its neighbours (enabling it to change between Isatap routers etc.) Further it is natural to demand (MUST) all Isatap nodes to cooperate with other nodes performing NUD by responding to solicited NS. What I do not understand is why an Isatap ROUTER in the "base specification" SHOULD perform NUD in accordance with 2461 on it's Isatap hosts, when we agree that this mechsnism is broken and for ROUTERS amounts to nothing (except for overhead). I would suggest either to omit this requirement for ROUTERS or then at least describe how the NUD mechanism from 2461 should be altered in order to make it meaningful (and scalable) for a ROUTER. Karen > > > Karen, > > The co-authors discussed this issue in some detail, and the intended > meaning of the base specification is that ISATAP nodes SHOULD send NSs > and MUST send solicited NAs to establish neighbor cache state > even though > address resolution is done via static computation. So, the > functionality > is recommended (but optional) for the source and mandatory > for the target. > > Even so, there may be an operational issue for ISATAP routers > when the base > specification alone is used, since hints of forward progress > probably will > not be available from upper layers, i.e., reliable transport > connections are > normally forwarded *through* the router; not terminated *at* > the router. If > alternate paths exist, this could result in a unidirectional > link *from* the > ISATAP source node *to* the next-hop ISATAP router, which may > cause operational > problems in some cases. > > When the base specification alone is used, one implementation > alternative that > will satisfy many deployment scenarios is to restrict ISATAP > nodes to accepting > packets from and sending packets to *exactly one* ISATAP > router; even though > numerous potential routers may be available. But, a more > generalized, robust, > secure, and scalable alternative is to provide optional > extensions to the base > specification that ensure link bi-directionality even when > alternate paths exist. > Such an optional extension is proposed here: > > http://www.ietf.org/internet-drafts/draft-templin-v6v4-ndisc-01.txt > > Does this help clarify things? > > Fred Templin > ftemplin@iprg.nokia.com > > Karen E Nielsen (TED) wrote: > > Hi, > > > > Looking into the latest Isatap draft (v06) I am (still) > puzzled by the fact > > (Section 5.1) that ISATAP nodes SHOULD perform NUD in > accordance with RFC 2461, > > although we all agree (I think) that NUD in accordance > with RFc 2461 doesn't work > > for ISATAP routers - > > What NUD functionality do you demand (SHOULD) on an ISATAP > Router interface ??? > > > > Karen > From owner-v6ops@ops.ietf.org Fri Nov 8 07:19:08 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14300 for ; Fri, 8 Nov 2002 07:19:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18A86T-0002Ii-00 for v6ops-data@psg.com; Fri, 08 Nov 2002 04:19:13 -0800 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #2) id 18A68O-0000Ye-00 for v6ops@ops.ietf.org; Fri, 08 Nov 2002 02:13:04 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id gA8ACQgx037544; Fri, 8 Nov 2002 11:12:28 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gA8ACK3k036242; Fri, 8 Nov 2002 11:12:25 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA72614 from ; Fri, 8 Nov 2002 11:12:18 +0100 Message-Id: <3DCB8DF3.CB6416F1@hursley.ibm.com> Date: Fri, 08 Nov 2002 11:12:03 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Jonne.Soininen@nokia.com Cc: v6ops@ops.ietf.org Subject: Re: 3gpp transition solutions, revision -02 References: <4D7B558499107545BB45044C63822DDEEBDB54@mvebe001.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-13.9 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03,SUPERLONG_LINE, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jonne.Soininen@nokia.com wrote: > > Hi, > > sorry to step into the discussion so late. (I had computer trouble for a while!) > > I would like to remind everybody that as IMS is _exclusively_ IPv6, and the NAT-PT (or a flavor of that) is just an interworking solution to a non-IMS network that supports IMS like services. (Confusing enough?;) > > This means that IMS itself has no interworking problems, no NATs, no NAT-PTs, and no IPv4 - it is only IPv6. Thus, there are no problems inside the IMS. The NAT-PT would come to the picture if, for instance, you have to place a call to another "system" that does not support v6. (It may be that you have to do another kind of translation as well, e.g. SIP to H.323, or SIP to ISUP, or whatever.) (BC) And if that is the case, the IWU that does this translation can be dual stacked, with its IPv6 stack talking to IMS and its IPv4 stack talking to the legacy system. If you do that, NAT-PT isn't needed. > The NAT-PT would be an interworking function to an outside world - not an internal part! (BC) Agreed. So let's try to get rid of it by using dual stack IWUs instead. > > People seem to write all the time that with dual-stack you can fix the interworking problems of IMS. That however is not true, because you end up with normal NAT for your IPv4 connections. You cannot get (at least in certain areas of the world) enough IPv4 addresses to even support it as an interworking method and to have global addresses. (BC) Agreed. That's why I think you should dual stack the IWUs only. > In addition, you end up having a dual-stack in your phones until the end of time or to the point where the last _possible_ IPv4 device in the world would be extinct! These are just some of the reasons why 3GPP decided to have IPv6 only IMS. (BC) Which was an excellent decision. > > Anyways, the 3GPP specifications (as Hesham pointed out) now say that this network/system, the IMS, is exclusively IPv6. We cannot change the specs, and there is no reason for changing them - the contrary. I would propose that we concentrate now on solving the problem instead of changing the problem. (BC) Indeed. And given that the set of applications on 3G devices is likely to be constrained, we can concentrate on the IWUs. Now, what's the answer to Keith's point below? Brian > > Cheers, > > Jonne. > > > -----Original Message----- > > From: ext Keith Moore [mailto:moore@cs.utk.edu] > > Sent: Thursday, November 07, 2002 9:21 AM > > To: BELOEIL Luc FTRD/DMI/CAE > > Cc: Brian E Carpenter; Hesham Soliman (EAB); v6ops@ops.ietf.org > > Subject: Re: 3gpp transition solutions, revision -02 > > > > > > > For SIP-based services an application proxy is not sufficient. > > > > and NAT-PT is sufficient? from my limited knowledge of SIP I > > find this > > surprising. > > > > however I don't see a huge problem with using NAT-PT only for > > a specific > > set of well-defined services on networks with known characteristics; > > presumably it can be adapted as needed to accomodate those services. > > > > the imposition of NAT-PT on other services is of course a > > separate question. > > > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-v6ops@ops.ietf.org Fri Nov 8 08:17:05 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17811 for ; Fri, 8 Nov 2002 08:17:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18A91S-0006Zh-00 for v6ops-data@psg.com; Fri, 08 Nov 2002 05:18:06 -0800 Received: from tms002bb.han.telia.se ([131.115.230.133]) by psg.com with esmtp (Exim 3.36 #2) id 18A91O-0006ZU-00 for v6ops@ops.ietf.org; Fri, 08 Nov 2002 05:18:03 -0800 Received: from tms031mb.han.telia.se ([131.115.230.162]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Nov 2002 14:17:56 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 3gpp transition solutions, revision -02 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 8 Nov 2002 14:17:56 +0100 Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE807E13C@TMS031MB.tcad.telia.se> Thread-Topic: 3gpp transition solutions, revision -02 Thread-Index: AcKHIq+26S6eWct4Se++QeRqfLlc9AABeApQ From: To: X-OriginalArrivalTime: 08 Nov 2002 13:17:56.0644 (UTC) FILETIME=[4090DE40:01C28729] X-Spam-Status: No, hits=-3.7 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA17811 > This means that IMS itself has no interworking problems, no > NATs, no NAT-PTs, and no IPv4 - it is only IPv6. Thus, there > are no problems inside the IMS. The NAT-PT would come to the > picture if, for instance, you have to place a call to another > "system" that does not support v6. (It may be that you have > to do another kind of translation as well, e.g. SIP to H.323, > or SIP to ISUP, or whatever.) > > (BC) And if that is the case, the IWU that does this > translation can be dual > stacked, with its IPv6 stack talking to IMS and its IPv4 stack talking > to the legacy system. If you do that, NAT-PT isn't needed. > that will take care of the signalling part. you still need a box to translate the media flow, which is not going through the ims. jasminko From owner-v6ops@ops.ietf.org Fri Nov 8 08:42:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18666 for ; Fri, 8 Nov 2002 08:42:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18A9R7-0007ay-00 for v6ops-data@psg.com; Fri, 08 Nov 2002 05:44:37 -0800 Received: from tms002bb.han.telia.se ([131.115.230.133]) by psg.com with esmtp (Exim 3.36 #2) id 18A9R5-0007af-00 for v6ops@ops.ietf.org; Fri, 08 Nov 2002 05:44:35 -0800 Received: from tms031mb.han.telia.se ([131.115.230.162]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Nov 2002 14:44:33 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 3gpp transition solutions, revision -02 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 8 Nov 2002 14:44:32 +0100 Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE8D72E46@TMS031MB.tcad.telia.se> Thread-Topic: 3gpp transition solutions, revision -02 Thread-Index: AcKEutZaBbI+0mDFQTy5NaUOPiwWSQANvzuQACTdkYAAadwZIA== From: To: , X-OriginalArrivalTime: 08 Nov 2002 13:44:33.0191 (UTC) FILETIME=[F82E9B70:01C2872C] X-Spam-Status: No, hits=-4.5 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA18666 > => IMS *is* IPv6-only for both UE - CSCF and IMS internal > interfaces. Yep, the text is just an "if" statement and in my > opinion could be removed from the solutions doc. ims _is_ v6 only. i suggest you remove it. it's only confusing. thanx! jasminko From owner-v6ops@ops.ietf.org Fri Nov 8 13:46:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07257 for ; Fri, 8 Nov 2002 13:46:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AE9N-00029c-00 for v6ops-data@psg.com; Fri, 08 Nov 2002 10:46:37 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 18AE9K-00028m-00 for v6ops@ops.ietf.org; Fri, 08 Nov 2002 10:46:35 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA06442 for ; Fri, 8 Nov 2002 10:46:04 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA8Ik4E24883 for ; Fri, 8 Nov 2002 10:46:04 -0800 X-mProtect: <200211081846> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKR7VAx; Fri, 08 Nov 2002 10:46:02 PST Message-ID: <3DCC076A.70203@iprg.nokia.com> Date: Fri, 08 Nov 2002 10:50:18 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Comments on draft-ietf-ngtrans-mech-v2-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In section 3.2, the following text appears (actually, this is unchanged since mech-v2-00.txt): Encapsulating nodes that have a large number of tunnels might not be able to store the IPv4 Path MTU for all tunnels. Such nodes can, at the expense of additional fragmentation in the network, avoid using the IPv4 Path MTU algorithm across the tunnel and instead use the MTU of the link layer (under IPv4) in the above algorithm instead of the IPv4 path MTU. In this case the Don't Fragment bit MUST NOT be set in the encapsulating IPv4 header. When you say: "...and instead use the MTU of the link layer (under IPv4) in the above algorithm...", it is not clear whether you mean the *full* MTU of an arbitrary link layer, or the MTU of the link layer *up to some limit* (e.g., 4400 bytes). If your meaning is the latter, then it would help make things clearer if you re-iterate the 4400 byte limit in this text also. If instead your meaning is to use the full MTU of an arbitrary link layer, then nodes implementing this specification run the risk of creating "harmful fragmentation" in the network and/or reassembly buffer overruns in receivers. So, I suggest this text be made clear. I believe you should also state somewhere that section 3.2 provides only a *limited* tunnel MTU configuration mechanism. A more generalized mechanism is possible if explicit fedback from the decapsulator is available. For example, see: http://www.ietf.org/internet-drafts/draft-templin-v6v4-ndisc-01.txt Thanks, Fred Templin femplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Fri Nov 8 17:22:48 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19270 for ; Fri, 8 Nov 2002 17:22:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AHY3-000IjF-00 for v6ops-data@psg.com; Fri, 08 Nov 2002 14:24:19 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18AHY1-000Iin-00 for v6ops@ops.ietf.org; Fri, 08 Nov 2002 14:24:17 -0800 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA8MNkO03236 for ; Sat, 9 Nov 2002 00:23:46 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 9 Nov 2002 00:24:14 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 9 Nov 2002 00:24:14 +0200 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 14:24:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 3gpp transition solutions, revision -02 Date: Fri, 8 Nov 2002 14:24:09 -0800 Message-ID: <4D7B558499107545BB45044C63822DDE0175D924@mvebe001.americas.nokia.com> Thread-Topic: 3gpp transition solutions, revision -02 Thread-Index: AcKEutZaBbI+0mDFQTy5NaUOPiwWSQANvzuQACTdkYAAadwZIAASMUWA From: To: , , X-OriginalArrivalTime: 08 Nov 2002 22:24:11.0228 (UTC) FILETIME=[8FBD81C0:01C28775] X-Spam-Status: No, hits=-4.5 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA19270 > > > => IMS *is* IPv6-only for both UE - CSCF and IMS internal > > interfaces. Yep, the text is just an "if" statement and in my > > opinion could be removed from the solutions doc. > > ims _is_ v6 only. i suggest you remove it. it's only confusing. thanx! Yes, sorry about it. Cheers, Jonne. -------- Jonne Soininen Nokia Tel. +1 650 864 6794 Cellular: +1 650 714 7733 Email: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Fri Nov 8 18:23:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22011 for ; Fri, 8 Nov 2002 18:23:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AIUq-000MXE-00 for v6ops-data@psg.com; Fri, 08 Nov 2002 15:25:04 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 18AIUn-000MTh-00 for v6ops@ops.ietf.org; Fri, 08 Nov 2002 15:25:01 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA22449; Fri, 8 Nov 2002 15:24:30 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA8NOTS05248; Fri, 8 Nov 2002 15:24:29 -0800 X-mProtect: <200211082324> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXWObXr; Fri, 08 Nov 2002 15:24:28 PST Message-ID: <3DCC48AE.9090609@iprg.nokia.com> Date: Fri, 08 Nov 2002 15:28:46 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org Subject: Re: (ngtrans) NUD for ISATAP Routers Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.4 required=5.0 tests=SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Karen, Karen E Nielsen (TED) wrote: > What I do not understand is why an Isatap ROUTER in the "base specification" > SHOULD perform NUD in accordance with 2461 on it's Isatap hosts, when we agree that > this mechsnism is broken and for ROUTERS amounts to nothing (except for overhead). > I would suggest either to omit this requirement for ROUTERS or then at > least describe how the NUD mechanism from 2461 should be altered in order to > make it meaningful (and scalable) for a ROUTER. I believe what you are saying is consistent with our intended meaning. But, the text in the draft seems to be coming across to you as too restrictive and this was not our intention (Tim, Mohit, or Dave - please let us know if you disagree.) Let's look at the two elements of section 5.1 that may be causing confusion in more detail: Protocol addresses (IPv6) in ISATAP are resolved to link-layer addresses (IPv4) by a static computation, i.e., the last four octets are treated as an IPv4 address. I do not believe there should be any confusion in what is being said here, but what is *not* said is whether/not the node should send NSs and wait for NAs at the time the static computation is done. This seems to me to be an implementation alternative that may provide faster unreachability detection in some cases, i.e., it is not required for interoperability. Perhaps a sentence could be added to the effect of "Nodes MAY send NSs and wait for NAs when performing static computation." I personally don't believe this is needed, but I could possibly be convinced otherwise. ISATAP nodes SHOULD perform Neighbor Unreachability Detection (NUD) as specified in [DISC, 7.3], and MUST send solicited neighbor adver- tisements as specified in [DISC, 7.2.4]. The "SHOULD" here seems to be your bone of contention, and I can understand your concern. But, I believe we were intending a looser interpretation of the SHOULD, based on our earlier discussions on NUD for routers. Perhaps a slight re-wording such as the following could help disambiguate things: + ISATAP routers MAY and ISATAP nodes SHOULD perform Neighbor + Unreachability Detection (NUD) as specified in [DISC, 7.3]. + ISATAP nodes MUST send solicited neighbor advertisements as + specified in [DISC, 7.2.4]. Does this address your concerns? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Fri Nov 8 19:33:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24192 for ; Fri, 8 Nov 2002 19:33:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AJaA-000PiG-00 for v6ops-data@psg.com; Fri, 08 Nov 2002 16:34:38 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 18AJa8-000PhH-00 for v6ops@ops.ietf.org; Fri, 08 Nov 2002 16:34:36 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA26417; Fri, 8 Nov 2002 16:34:03 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA90Y2k32448; Fri, 8 Nov 2002 16:34:02 -0800 X-mProtect: <200211090034> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQ1dIhn; Fri, 08 Nov 2002 16:34:01 PST Message-ID: <3DCC58FB.6060408@iprg.nokia.com> Date: Fri, 08 Nov 2002 16:38:19 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org, ngtrans@sunroof.eng.sun.com Subject: Reachability confirmation issue for ISATAP routers (plus solution) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, The ISATAP specification allows nodes to discover the addresses of multiple "potential routers" and affiliate with as many or few of them as desired. For ISATAP nodes that affiliate with more than one router, an issue for NUD may occur if hints from upper layer protocols are used to indicate a connection is making forward progress. In [RFC2461, 7.3.1], we find the following text: "A connection makes "forward progress" if the packets received from a remote peer can only be arriving if recent packets sent to that peer are actually reaching it. In TCP, for example, receipt of a (new) acknowledgement indicates that previously sent data reached the peer. Likewise, the arrival of new (non-duplicate) data indicates that earlier acknowledgements are being delivered to the remote peer. If packets are reaching the peer, they must also be reaching the sender's next-hop neighbor; thus "forward progress" is a confirmation that the next-hop neighbor is reachable. For off-link destinations, forward progress implies that the first-hop router is reachable. When available, this upper-layer information SHOULD be used." When a node (A) affiliates with only a single ISATAP router (B), the above specification works fine, because forward progress will only occur if both of the following are true: 1. outgoing packets are flowing from A -> B 2. return packets are flowing from B -> A i.e., the bi-directional link A <-> B is confirmed. But, when A affiliates with multiple ISATAP routers, this condition no longer holds. In particular, consider the following case: 1. A affiliates with routers B, C 2. A initiates a TCP connection with remote peer D. Outgoing packets from A -> D flow through B, but return packets from D -> A flow through C (i.e., outgoing and return paths are asymmetric) 3. A initiates a multimedia UDP stream to remote peer E. Outgoing packets from A -> E flow through B, but no return packets occur Now, if "forward progress" indications from the A -> D TCP connection were used, A would conclude that B was reachable and continue to keep its neighbor cache entry for B in the REACHABLE state. If the return path from B -> A were disrupted (i.e., the link becomes unidirectional from A -> B) this condition would go undetected. This could produce undesireable results if packets from A -> E were going to a black hole but B could not deliver critical ICMP messages to A. Fortunately, the very next paragraph in [RFC2461, 7.3.1] provides the solution to the problem: "In some cases (e.g., UDP-based protocols and routers forwarding packets to hosts) such reachability information may not be readily available from upper-layer protocols. When no hints are available and a node is sending packets to a neighbor, the node actively probes the neighbor using unicast Neighbor Solicitation messages to verify that the forward path is still working." So, the solution for ISATAP nodes when performing NUD for routers is the following: 1. When the node affiliates with only a single router, upper-layer hints of forward progress MAY be used for reachability confirmation as in the first RFC2461 paragraph above 2. When a node affiliates with multiple routers, upper-layer hints of forward progress MUST NOT be used for reachability confirmation. Instead, the node MUST actively probe neighboring routers using unicast Neighbor Solicitation messages as in the second paragraph of RFC2461 Note that in case 2), ONLY those routers that are actively carrying outgoing traffic are probed. There is no need to probe routers that carry only return traffic, since the forward direction is all that is needed. Comments? Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Fri Nov 8 20:54:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26098 for ; Fri, 8 Nov 2002 20:54:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AKr5-0003lM-00 for v6ops-data@psg.com; Fri, 08 Nov 2002 17:56:11 -0800 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by psg.com with esmtp (Exim 3.36 #2) id 18AKr3-0003kn-00 for v6ops@ops.ietf.org; Fri, 08 Nov 2002 17:56:09 -0800 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA91unx23204 for ; Fri, 8 Nov 2002 19:56:50 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Nov 2002 19:56:06 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 17:55:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 3gpp transition solutions, revision -02 Date: Fri, 8 Nov 2002 17:55:47 -0800 Message-ID: <4D7B558499107545BB45044C63822DDEEBDB5A@mvebe001.americas.nokia.com> Thread-Topic: 3gpp transition solutions, revision -02 Thread-Index: AcKHIfENFVWskaEFSWCirTMHvDmJ/AAU7AMw From: To: Cc: X-OriginalArrivalTime: 09 Nov 2002 01:55:48.0950 (UTC) FILETIME=[202C1F60:01C28793] X-Spam-Status: No, hits=-6.1 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, SUPERLONG_LINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA26098 Hi Brian, > (BC) And if that is the case, the IWU that does this > translation can be dual > stacked, with its IPv6 stack talking to IMS and its IPv4 stack talking > to the legacy system. If you do that, NAT-PT isn't needed. OK, for the SIP signalling part you have to use an IWU (or a NAT-PT with a SIP ALG, which I guess would be the same thing, right?). As Jasminko pointed out there is also the "media stream" (SIP only negotiates the session e.g. VoIP - the data goes end-to-end). There NAT-PT (or a mutation of that) could be used. > > In addition, you end up having a dual-stack in your phones > until the end of time or to the point where the last > _possible_ IPv4 device in the world would be extinct! These > are just some of the reasons why 3GPP decided to have IPv6 only IMS. > > (BC) Which was an excellent decision. I think so too! > > Now, what's the answer to Keith's point below? > If I got it right, the question was if NAT-PT is sufficient. No, you need application level gateways in many cases (like in your IWU). But this is "business as usual" in NATed environments. Though, I hope the NAT-PT for the media stream can be pretty basic. Cheers, Jonne. > Brian > > > > > > -----Original Message----- > > > From: ext Keith Moore [mailto:moore@cs.utk.edu] > > > Sent: Thursday, November 07, 2002 9:21 AM > > > To: BELOEIL Luc FTRD/DMI/CAE > > > Cc: Brian E Carpenter; Hesham Soliman (EAB); v6ops@ops.ietf.org > > > Subject: Re: 3gpp transition solutions, revision -02 > > > > > > > > > > For SIP-based services an application proxy is not sufficient. > > > > > > and NAT-PT is sufficient? from my limited knowledge of SIP I > > > find this > > > surprising. > > > > > > however I don't see a huge problem with using NAT-PT only for > > > a specific > > > set of well-defined services on networks with known > characteristics; > > > presumably it can be adapted as needed to accomodate > those services. > > > > > > the imposition of NAT-PT on other services is of course a > > > separate question. > > > > > > > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment at the IBM Zurich Laboratory, Switzerland > > From owner-v6ops@ops.ietf.org Fri Nov 8 21:11:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26472 for ; Fri, 8 Nov 2002 21:11:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AL7p-0004cb-00 for v6ops-data@psg.com; Fri, 08 Nov 2002 18:13:29 -0800 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by psg.com with esmtp (Exim 3.36 #2) id 18AL7m-0004cP-00 for v6ops@ops.ietf.org; Fri, 08 Nov 2002 18:13:26 -0800 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA92EOX29441 for ; Fri, 8 Nov 2002 20:14:24 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Nov 2002 20:13:24 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 8 Nov 2002 18:13:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 3gpp transition solutions, revision -02 Date: Fri, 8 Nov 2002 18:13:23 -0800 Message-ID: <4D7B558499107545BB45044C63822DDE0175D92F@mvebe001.americas.nokia.com> Thread-Topic: 3gpp transition solutions, revision -02 Thread-Index: AcKGokOFImlFs5KuTDaOCQi1Kodi6QAI0PXwAA1yxLAAJnF6UA== From: To: , Cc: , , , X-OriginalArrivalTime: 09 Nov 2002 02:13:24.0441 (UTC) FILETIME=[954B4490:01C28795] X-Spam-Status: No, hits=-6.7 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, SUPERLONG_LINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA26472 Hi Luc, > -----Original Message----- > Here is my last point, > > IMS is IPv6-only ok, but IMS is a set of SIP servers. > SIP is a control protocol that can initiate IPv4-based or > IPv6-based flows. > But 3GPP specs have constrainted nodes, that use IMS SIP > server services, only to use IPv6 (signalling + communication > flows). The communications initiated by IMS (SIP) are not > intend to go through IMS (routing is different). > IMS is not only the SIP server, etc. It comprises the whole system. That is why the media stream between the nodes is actually part of IMS as well. > So, consider I'm using IMS services, even if: > - I have a dual-stack node, > - I have sufficient IPv4 public addresses (some areas are > still not constrainted) > - I may just need private IPv4 address (its depends of your > architectures) > - SIP protocol is efficient enough to allow you to open IPv4 > and/or IPv6 communications, > I can not use IPv4. > > So why not using DSTM + ROHC ? Because then you would be using IPv4 as well, and you would have to have IPv4 on your terminal. > Just a comment: > A transition mechanism (whatever it is) would be necessary > until I wanna offer services towards other IPv4-only SIP-based system. Yes. > Moreover, I think that dual-stack phones are usefull to use > IPv4-only services not based on IMS, and those services may > not be disregarded. That is why we have the different scenarios (this is under the general scenarios). IMS is IPv6 only, but if you want to have, for example, a connection to your intranet that is IPv4 you can. However, the intranet is not part of the IMS. Cheers, Jonne. > > De : Jonne.Soininen@nokia.com [mailto:Jonne.Soininen@nokia.com] > > > > Hi, > > > > sorry to step into the discussion so late. (I had computer > > trouble for a while!) > > > > I would like to remind everybody that as IMS is _exclusively_ > > IPv6, and the NAT-PT (or a flavor of that) is just an > > interworking solution to a non-IMS network that supports IMS > > like services. (Confusing enough?;) > > > > This means that IMS itself has no interworking problems, no > > NATs, no NAT-PTs, and no IPv4 - it is only IPv6. Thus, there > > are no problems inside the IMS. The NAT-PT would come to the > > picture if, for instance, you have to place a call to another > > "system" that does not support v6. (It may be that you have > > to do another kind of translation as well, e.g. SIP to H.323, > > or SIP to ISUP, or whatever.) The NAT-PT would be an > > interworking function to an outside world - not an internal part! > > > > People seem to write all the time that with dual-stack you > > can fix the interworking problems of IMS. That however is not > > true, because you end up with normal NAT for your IPv4 > > connections. You cannot get (at least in certain areas of the > > world) enough IPv4 addresses to even support it as an > > interworking method and to have global addresses. In > > addition, you end up having a dual-stack in your phones until > > the end of time or to the point where the last _possible_ > > IPv4 device in the world would be extinct! These are just > > some of the reasons why 3GPP decided to have IPv6 only IMS. > > > > Anyways, the 3GPP specifications (as Hesham pointed out) now > > say that this network/system, the IMS, is exclusively IPv6. > > We cannot change the specs, and there is no reason for > > changing them - the contrary. I would propose that we > > concentrate now on solving the problem instead of changing > > the problem. > > > > Cheers, > > > > Jonne. > > > > > > > > > -----Original Message----- > > > From: ext Keith Moore [mailto:moore@cs.utk.edu] > > > Sent: Thursday, November 07, 2002 9:21 AM > > > To: BELOEIL Luc FTRD/DMI/CAE > > > Cc: Brian E Carpenter; Hesham Soliman (EAB); v6ops@ops.ietf.org > > > Subject: Re: 3gpp transition solutions, revision -02 > > > > > > > > > > For SIP-based services an application proxy is not sufficient. > > > > > > and NAT-PT is sufficient? from my limited knowledge of SIP I > > > find this > > > surprising. > > > > > > however I don't see a huge problem with using NAT-PT only for > > > a specific > > > set of well-defined services on networks with known > > characteristics; > > > presumably it can be adapted as needed to accomodate those > > services. > > > > > > the imposition of NAT-PT on other services is of course a > > > separate question. > > > > > > > > > From owner-v6ops@ops.ietf.org Sat Nov 9 23:02:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00551 for ; Sat, 9 Nov 2002 23:02:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AjIQ-000LiG-00 for v6ops-data@psg.com; Sat, 09 Nov 2002 20:02:02 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18AjIO-000Li4-00 for v6ops@ops.ietf.org; Sat, 09 Nov 2002 20:02:00 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18AjIO-000DOq-00 for v6ops@ops.ietf.org; Sat, 09 Nov 2002 20:02:00 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: v6ops@ops.ietf.org Subject: draft-ymbk-6to4-arpa-delegation-00.txt Message-Id: Date: Sat, 09 Nov 2002 20:02:00 -0800 X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit in order to formally request delegation the 6to4 reverse zone, we need a document such as joao and i drafted the other month but never published. see i would appreciate it if this document could be discussed in v6ops. thanks. randy From owner-v6ops@ops.ietf.org Sun Nov 10 08:53:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16419 for ; Sun, 10 Nov 2002 08:53:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AsWX-000O4Q-00 for v6ops-data@psg.com; Sun, 10 Nov 2002 05:53:13 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18AsWV-000O3l-00; Sun, 10 Nov 2002 05:53:11 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAADprl12802; Sun, 10 Nov 2002 08:51:53 -0500 (EST) Message-Id: <200211101351.gAADprl12802@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: v6ops@ops.ietf.org Subject: Re: draft-ymbk-6to4-arpa-delegation-00.txt In-reply-to: (Your message of "Sat, 09 Nov 2002 20:02:00 PST.") Date: Sun, 10 Nov 2002 08:51:53 -0500 X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Randy, for what it's worth, I've updated the 6to4 and DNS document referenced in this draft. the current version is draft-moore-6to4-dns-03.txt . Keith From owner-v6ops@ops.ietf.org Sun Nov 10 12:06:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19683 for ; Sun, 10 Nov 2002 12:06:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AvYI-0006Ch-00 for v6ops-data@psg.com; Sun, 10 Nov 2002 09:07:14 -0800 Received: from ny-ppp004.iij-us.net ([216.98.99.4] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #2) id 18AvYF-0006CE-00 for v6ops@ops.ietf.org; Sun, 10 Nov 2002 09:07:12 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id D1EEF7AF; Mon, 11 Nov 2002 02:06:54 +0900 (JST) To: Keith Moore Cc: Randy Bush , v6ops@ops.ietf.org In-reply-to: moore's message of Sun, 10 Nov 2002 08:51:53 EST. <200211101351.gAADprl12802@astro.cs.utk.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-ymbk-6to4-arpa-delegation-00.txt From: Jun-ichiro itojun Hagino Date: Mon, 11 Nov 2002 02:06:54 +0900 Message-Id: <20021110170654.D1EEF7AF@starfruit.itojun.org> X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >Randy, >for what it's worth, I've updated the 6to4 and DNS document referenced >in this draft. the current version is draft-moore-6to4-dns-03.txt . will you guys get a slot in dnsop also? itojun From owner-v6ops@ops.ietf.org Sun Nov 10 12:14:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19832 for ; Sun, 10 Nov 2002 12:14:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18AvhY-0006h3-00 for v6ops-data@psg.com; Sun, 10 Nov 2002 09:16:48 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18AvhW-0006gq-00 for v6ops@ops.ietf.org; Sun, 10 Nov 2002 09:16:46 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18AvhV-0006ib-00; Sun, 10 Nov 2002 09:16:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org, dns op wg Subject: Re: draft-ymbk-6to4-arpa-delegation-00.txt References: <200211101351.gAADprl12802@astro.cs.utk.edu> <20021110170654.D1EEF7AF@starfruit.itojun.org> Message-Id: Date: Sun, 10 Nov 2002 09:16:45 -0800 X-Spam-Status: No, hits=-5.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> for what it's worth, I've updated the 6to4 and DNS document referenced >> in this draft. the current version is draft-moore-6to4-dns-03.txt . > will you guys get a slot in dnsop also? good question. perhaps both belong there as opposed to v6ops. dnsop, please see randy From owner-v6ops@ops.ietf.org Mon Nov 11 02:14:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12515 for ; Mon, 11 Nov 2002 02:14:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18B8kM-000Et7-00 for v6ops-data@psg.com; Sun, 10 Nov 2002 23:12:34 -0800 Received: from web13007.mail.yahoo.com ([216.136.174.17]) by psg.com with smtp (Exim 3.36 #2) id 18B8kH-000Est-00 for v6ops@ops.ietf.org; Sun, 10 Nov 2002 23:12:30 -0800 Message-ID: <20021111071228.57857.qmail@web13007.mail.yahoo.com> Received: from [63.197.18.101] by web13007.mail.yahoo.com via HTTP; Sun, 10 Nov 2002 23:12:28 PST Date: Sun, 10 Nov 2002 23:12:28 -0800 (PST) From: Fred Templin Subject: The Inside-Out ISATAP Model To: v6ops@ops.ietf.org Cc: osprey67@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=3.2 required=5.0 tests=FROM_ENDS_IN_NUMS,MAILTO_TO_SPAM_ADDR,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: *** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, I didn't get a chance to write a draft on this ahead of the deadline, but I would like to propose a discussion topic for the design teams at IETF 55. The topic proposes the use of ISATAP with globally-unique interface identifiers, i.e., with the 'u/l' bit in the company code set to "universal" and a globally unique IPv4 address. This feature enables the "Inside-Out ISATAP model", which I would also like to propose as design team discussion material. For a diagrammatic represenation of this model, see: http://www.geocities.com/osprey67/inside_out.ppt In the traditional model, ISATAP operates "intra-site" as its name implies. Nodes within an ISATAP site connect across the global Internet to other sites via 6to4, native IPv6 routing, etc. But, when globally unique IPv4 addresses are used, the model can be turned "inside-out". In the inside-out model, ISATAP treats the global Internet as a monolithic site with IPv6 clouds hanging off the edges. As in the traditional model, ISATAP treats the IPv4 Internet as a link layer for IPv6, thus the interface identifier is the natural place to embed the link layer address. Moreover, this model allows all 64 bits of the routing prefix to be used for other purposes, e.g. v6 routing. Note that this model does NOT displace 6to4 and/or Teredo; instead, all three mechanisms have important and complementary roles to play in the global scheme. I would also like to suggest further discussion along these lines in the design teams. Fred Templin osprey67@yahoo.com __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 From owner-v6ops@ops.ietf.org Mon Nov 11 02:36:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12893 for ; Mon, 11 Nov 2002 02:36:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18B98q-000FLV-00 for v6ops-data@psg.com; Sun, 10 Nov 2002 23:37:52 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18B98o-000FLI-00 for v6ops@ops.ietf.org; Sun, 10 Nov 2002 23:37:50 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAB7bjq25597; Mon, 11 Nov 2002 09:37:45 +0200 Date: Mon, 11 Nov 2002 09:37:45 +0200 (EET) From: Pekka Savola To: Fred Templin cc: v6ops@ops.ietf.org Subject: Re: The Inside-Out ISATAP Model In-Reply-To: <20021111071228.57857.qmail@web13007.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 10 Nov 2002, Fred Templin wrote: [...] > In the traditional model, ISATAP operates "intra-site" as its name > implies. Nodes within an ISATAP site connect across the global Internet > to other sites via 6to4, native IPv6 routing, etc. But, when globally > unique IPv4 addresses are used, the model can be turned "inside-out". > > In the inside-out model, ISATAP treats the global Internet as a > monolithic site with IPv6 clouds hanging off the edges. As in the > traditional model, ISATAP treats the IPv4 Internet as a link layer > for IPv6, thus the interface identifier is the natural place to > embed the link layer address. Moreover, this model allows all 64 > bits of the routing prefix to be used for other purposes, e.g. > v6 routing. Wasn't this model already exhausted with "automatic tunneling using compatible addresses"? The topology is flat, you can't connect even routers using this mechanism. I fail to see what new advantages ISATAP would bring here. Instead, the trust model is completely different, and certain assumptions no longer hold. btw. reference to section 4.7 in isatap Security Considerations should be 4.5, I believe. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Nov 11 08:28:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17981 for ; Mon, 11 Nov 2002 08:28:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BEd6-000KM5-00 for v6ops-data@psg.com; Mon, 11 Nov 2002 05:29:28 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #2) id 18BEd4-000KLf-00 for v6ops@ops.ietf.org; Mon, 11 Nov 2002 05:29:26 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gABDScvx064366; Mon, 11 Nov 2002 14:28:39 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gABDSYEw028666; Mon, 11 Nov 2002 14:28:35 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA17898 from ; Mon, 11 Nov 2002 14:28:30 +0100 Message-Id: <3DCFB06F.B82A214C@hursley.ibm.com> Date: Mon, 11 Nov 2002 14:28:15 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Randy Bush Cc: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org, dns op wg Subject: Re: draft-ymbk-6to4-arpa-delegation-00.txt References: <200211101351.gAADprl12802@astro.cs.utk.edu> <20021110170654.D1EEF7AF@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit fwiw, I think both of these documents are important to get done. The delegation looks like a no-brainer, but constructive review from dnsop of draft-moore- would be very welcome. Brian Randy Bush wrote: > > >> for what it's worth, I've updated the 6to4 and DNS document referenced > >> in this draft. the current version is draft-moore-6to4-dns-03.txt . > > will you guys get a slot in dnsop also? > > good question. perhaps both belong there as opposed to v6ops. > > dnsop, please see > > > > > randy From owner-v6ops@ops.ietf.org Mon Nov 11 09:32:34 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20267 for ; Mon, 11 Nov 2002 09:32:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BFdV-000LNx-00 for v6ops-data@psg.com; Mon, 11 Nov 2002 06:33:57 -0800 Received: from web13005.mail.yahoo.com ([216.136.174.15]) by psg.com with smtp (Exim 3.36 #2) id 18BFdT-000LNl-00 for v6ops@ops.ietf.org; Mon, 11 Nov 2002 06:33:55 -0800 Message-ID: <20021111143352.33870.qmail@web13005.mail.yahoo.com> Received: from [63.197.18.101] by web13005.mail.yahoo.com via HTTP; Mon, 11 Nov 2002 06:33:52 PST Date: Mon, 11 Nov 2002 06:33:52 -0800 (PST) From: Fred Templin Subject: Re: The Inside-Out ISATAP Model To: Pekka Savola Cc: v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.9 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,MAILTO_TO_SPAM_ADDR, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, --- Pekka Savola wrote: > On Sun, 10 Nov 2002, Fred Templin wrote: > [...] > > In the traditional model, ISATAP operates "intra-site" as its name > > implies. Nodes within an ISATAP site connect across the global Internet > > to other sites via 6to4, native IPv6 routing, etc. But, when globally > > unique IPv4 addresses are used, the model can be turned "inside-out". > > > > In the inside-out model, ISATAP treats the global Internet as a > > monolithic site with IPv6 clouds hanging off the edges. As in the > > traditional model, ISATAP treats the IPv4 Internet as a link layer > > for IPv6, thus the interface identifier is the natural place to > > embed the link layer address. Moreover, this model allows all 64 > > bits of the routing prefix to be used for other purposes, e.g. > > v6 routing. > > Wasn't this model already exhausted with "automatic tunneling using > compatible addresses"? The topology is flat, you can't connect even > routers using this mechanism. It may well have been. If it was, I either missed the discussion or it went over my head. It seems to me that microcausms of the model I'm describing here have been debated over the past several months in the newsgroups, but the model itself was not mentioned from a high-level perspective. My purpose in bringing it up now is to inform any others like myself who had never previously considered turning the ISATAP model inside-out, and to initiate discussion in the design teams. > I fail to see what new advantages ISATAP would bring here. Instead, the > trust model is completely different, and certain assumptions no longer > hold. Whether/not there are advantages, and whether/not the trust model issues can be worked is something that needs to be discussed in the design teams, given sufficient interest. I don't have good answers to these questions myself, and am not entirely certain what other questions may remain. > btw. reference to section 4.7 in isatap Security Considerations should be > 4.5, I believe. Arg! You mentioned that before, and I had every intention of fixing it. Thanks for pointing it out - again! Fred Templin osprey67@yahoo.com > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 From owner-v6ops@ops.ietf.org Mon Nov 11 09:42:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20614 for ; Mon, 11 Nov 2002 09:42:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BFoG-000LcI-00 for v6ops-data@psg.com; Mon, 11 Nov 2002 06:45:04 -0800 Received: from e6.ny.us.ibm.com ([32.97.182.106]) by psg.com with esmtp (Exim 3.36 #2) id 18BFoD-000Lb1-00 for v6ops@ops.ietf.org; Mon, 11 Nov 2002 06:45:01 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gABEiUqJ251650; Mon, 11 Nov 2002 09:44:30 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gABEiQno120464; Mon, 11 Nov 2002 09:44:28 -0500 To: ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org Subject: Questions on Configured Tunnel MTU and TOS Byte Settings MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 11/11/2002 09:44:04 AM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 11/11/2002 09:44:04 AM, Serialize complete at 11/11/2002 09:44:04 AM, S/MIME Sign failed at 11/11/2002 09:44:04 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|October 31, 2002) at 11/11/2002 07:44:29, Serialize complete at 11/11/2002 07:44:29 Message-ID: Date: Mon, 11 Nov 2002 09:44:27 -0500 Content-Type: text/plain; charset="US-ASCII" X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I've got a few of questions on configured tunnels, as described in draft-ietf-ngtrans-mech-v2-01.txt. - Section 3.2 discusses how to set the tunnel MTU. It covers the case where the tunnel MTU size is manually configured, with a default of 1280. While it discusses capping the tunnel MTU at 4400 when IPv4 path MTU discovery is used, it doesn't discuss a maximum configured value for the tunnel. Does this mean there is no cap when manually configuring the tunnel MTU (i.e., the configured tunnel MTU may be as large as 65515, or even larger if jumbograms are used?) - The same section does not discuss what a host should do if it receives a Router Advertisement with an MTU option. Should the MTU value received be used? If so, is there a cap associated with this MTU value? In other words, if it exceeds 4400 bytes should the value be used? - In section 3.5, the TOS byte is defined as being set to 0 unless otherwise specified. What exactly does this mean? That, if RFC 2893 is followed the DSCP in the TOS byte may be set to a non-zero value? Or that RFC 2893 and RFC 3168 should explicitly NOT be implemented for configured tunnels? If the latter, I think some discussion on exactly WHY these two RFCs are not to be implemented would be helpful. - In section 3.6, the TOS byte of the inner packet is left unmodified at the tunnel egress. This seems to contradict some of the referenced. For instance, RFC 3168 defines both limited-functionality and full-functionality support for ECN support over tunnels. For limited-functionality, which seems to most closely match what is described in this draft, it discusses what to do at the tunnel egress if the CE option is set in the outer packet header but not the inner packet header. This processing does not seem to match what is described in this draft. Is this intentional? Roy From owner-v6ops@ops.ietf.org Mon Nov 11 10:09:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21460 for ; Mon, 11 Nov 2002 10:09:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BGEN-000MCn-00 for v6ops-data@psg.com; Mon, 11 Nov 2002 07:12:03 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #2) id 18BGEL-000MBv-00 for v6ops@ops.ietf.org; Mon, 11 Nov 2002 07:12:01 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gABFBSvx051318; Mon, 11 Nov 2002 16:11:28 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gABFBNEw041554; Mon, 11 Nov 2002 16:11:23 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA62628 from ; Mon, 11 Nov 2002 16:11:06 +0100 Message-Id: <3DCFC87A.7FCF7ABC@hursley.ibm.com> Date: Mon, 11 Nov 2002 16:10:50 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Roy Brabson Cc: ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org Subject: Re: (ngtrans) Questions on Configured Tunnel MTU and TOS Byte Settings References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy, Roy Brabson wrote: > > I've got a few of questions on configured tunnels, as described in > draft-ietf-ngtrans-mech-v2-01.txt. ... > - In section 3.5, the TOS byte is defined as being set to 0 unless > otherwise specified. What exactly does this mean? That, if RFC 2893 is > followed the DSCP in the TOS byte may be set to a non-zero value? Or > that RFC 2893 and RFC 3168 should explicitly NOT be implemented for > configured tunnels? If the latter, I think some discussion on exactly > WHY these two RFCs are not to be implemented would be helpful. Firstl there is an important typo in the references. [20] should be RFC 2983 and *not* 2893. 2983 is the diffserv/tunnels RFC. Although it's only Informational, I would be very upset if the transition draft was intended to mean "don't implement 2983". On the contrary, it should mean "do implement 2983" and if the text isn't clear on that, it needs fixing. I don't claim expertise on ECN, but I expect the same applies. > > - In section 3.6, the TOS byte of the inner packet is left unmodified at > the tunnel egress. This seems to contradict some of the referenced. > For instance, RFC 3168 defines both limited-functionality and > full-functionality support for ECN support over tunnels. For > limited-functionality, which seems to most closely match what is > described in this draft, it discusses what to do at the tunnel egress if > the CE option is set in the outer packet header but not the inner packet > header. This processing does not seem to match what is described in > this draft. Is this intentional? Surely the interpretation should be the same, i.e. do what [20] and [21] say. If not, the text needs fixing. By the way, RFC 2983 is Informational because at the time it was written, we didn't feel certain enough to put it on standards track. But I've seen nothing to suggest that what it recommends is wrong. Brian From owner-v6ops@ops.ietf.org Mon Nov 11 13:49:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27341 for ; Mon, 11 Nov 2002 13:49:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BJdG-0000FI-00 for v6ops-data@psg.com; Mon, 11 Nov 2002 10:49:58 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18BJdC-0000Et-00 for v6ops@ops.ietf.org; Mon, 11 Nov 2002 10:49:54 -0800 Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11025 for ; Mon, 11 Nov 2002 11:49:51 -0700 (MST) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5F00B9YDN2X4@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 11 Nov 2002 11:49:51 -0700 (MST) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H5F004BVDMWBV@mail.sun.net> for v6ops@ops.ietf.org; Mon, 11 Nov 2002 11:49:50 -0700 (MST) Date: Mon, 11 Nov 2002 10:49:42 -0800 From: Alain Durand Subject: Re: draft-ymbk-6to4-arpa-delegation-00.txt To: dns op wg Cc: v6ops@ops.ietf.org Message-id: <3DCFFBC6.4060000@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <200211101351.gAADprl12802@astro.cs.utk.edu> <20021110170654.D1EEF7AF@starfruit.itojun.org> <3DCFB06F.B82A214C@hursley.ibm.com> X-Spam-Status: No, hits=-2.4 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT I have some comments about section 3.1 "6to4 NS records derived from IPv4 NS records" when 6to4 is deployed by end users. Who is going to get the delegation: the ISP or the end customers? In IPv4 land, current practise is home customers do not get the delegation in the reverse tree DNS of their /32, so I suspect it would be the same in IPv6 land. [Note that, if the IPv4 address used for the 6to4 router is transient (DHCP allocated with a short lease, say one day), getting the delegation maintained properly would probably not be trivial anyway.] End customers will only deploy 6to4 because their ISP does not support IPv6 yet. Is it reasonable to expect the same ISP to manage the IPv6 reverse DNS zone? Perhaps yes if this can be done automaticaly, probably not if it involves manual intervention on the zones themselves. More, in IPv4 land, it is rather easy to prepopulate the zone with all the PTR, this is not possible in IPv6 land because of the size of the address space. So it seems to me that, for this to work, something like what I suggested a fews days ago in DNSext is needed. I'll repost it here. - Alain. ------------------- Repost from DNSext: As highlighted in the DNSop wg in draft-durand-ngtrans-dns-issues-00.txt & draft-durand-ngtrans-dns-issues-01.txt (this draft needs to be rename draft-ietf-dnsop-ipv6-dns-isssues-..) a current IPv4 practise of end-user ISPs is to pre-populate the reverse tree DNS with records like dsl-customer-374.pop-12.isp.net Due to the size of Ipv6 adddres space, this practise is no more possible. Several solutions have been proposed so far, but all of them have serious drawbacks: - do not populate the reverse tree at all - only populate for some hosts - use wildcard DNS records - dynamically generate DNS records This is a new proposal that should not get in the way of DNSsec but would require some changes in the stub resolver library routines, getnameinfo and getaddrinfo. I would like to get feedback from the DNSext wg before I present this to DNSop. - Alain. ps: as this was first discussed with a few people last week at ARIN, it was too late to publish an Internet Draft, so here is an outline of the proposal. Note: this is a similar idea as described in RFC1101 DNS operational requirements: For each /64 network, in the delegated /64 reverse zone: a record: 0.0.0.0.0.0.0.0 IN PTR networkname and in the direct zone networkname IN AAAA xxxxxxxxxxx:0.0.0.0.0.0.0.0 SHOULD be in place. Stub resolver library changes: getaddrinfo(): - if a PTR exist for the IPv6 address, returns it. - else - split the IPv6 address into a /64 $prefix and an Interface ID $interfaceID (note $interfaceID is a pure hex string) - append Interface ID all zeros to $prefix to form $networkAddr - lookup a PTR for $networkAddr into $networkName - if it exists, return the string $InterfaceID "+" $networkName - else return non existant getnameinfo(): - only for AAAA lookups: - lookup AAAA for $name - if exist, retuns it - if not exist AND $name matches the syntax $interfaceID "+" non empty valid DNS name then: - check $interfaceID is a 64 bit long hex string - look AAAA for the RHS to $netAddr - if non existant, return error - if lower 64 bits non empty, return error - append $interfaceID to $netAddr into $Addr - return $Addr - else return non existant From owner-v6ops@ops.ietf.org Mon Nov 11 14:05:49 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28120 for ; Mon, 11 Nov 2002 14:05:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BJuC-0000ef-00 for v6ops-data@psg.com; Mon, 11 Nov 2002 11:07:28 -0800 Received: from fbca.west.iij-america.com ([216.98.98.238] helo=starfruit.itojun.org ident=fwuser) by psg.com with esmtp (Exim 3.36 #2) id 18BJu9-0000eS-00 for v6ops@ops.ietf.org; Mon, 11 Nov 2002 11:07:25 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 294FD7AF; Tue, 12 Nov 2002 04:07:12 +0900 (JST) To: Alain Durand Cc: dns op wg , v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Mon, 11 Nov 2002 10:49:42 PST. <3DCFFBC6.4060000@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-ymbk-6to4-arpa-delegation-00.txt From: Jun-ichiro itojun Hagino Date: Tue, 12 Nov 2002 04:07:12 +0900 Message-Id: <20021111190712.294FD7AF@starfruit.itojun.org> X-Spam-Status: No, hits=-2.7 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >So it seems to me that, for this to work, something like what I suggested >a fews days ago in DNSext is needed. I'll repost it here. i would prefer it if you impose no changes to getaddrinfo/getnameinfo with your proposal. arrangements within server side would be better at this stage (we can't change deployed codebase any longer, there are huge number of Solaris 8 boxen out there). itojun From owner-v6ops@ops.ietf.org Mon Nov 11 16:32:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02524 for ; Mon, 11 Nov 2002 16:32:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BMAV-000421-00 for v6ops-data@psg.com; Mon, 11 Nov 2002 13:32:27 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18BMAQ-00041m-00 for v6ops@ops.ietf.org; Mon, 11 Nov 2002 13:32:23 -0800 Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19265 for ; Mon, 11 Nov 2002 14:32:22 -0700 (MST) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5F00BDFL5RWZ@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 11 Nov 2002 14:32:22 -0700 (MST) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H5F004P4L5QBV@mail.sun.net> for v6ops@ops.ietf.org; Mon, 11 Nov 2002 14:32:15 -0700 (MST) Date: Mon, 11 Nov 2002 13:32:12 -0800 From: Alain Durand Subject: Re: draft-ymbk-6to4-arpa-delegation-00.txt To: Jun-ichiro itojun Hagino Cc: dns op wg , v6ops@ops.ietf.org Message-id: <3DD021DC.70400@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <20021111190712.294FD7AF@starfruit.itojun.org> X-Spam-Status: No, hits=-3.9 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Jun-ichiro itojun Hagino wrote: >>So it seems to me that, for this to work, something like what I suggested >>a fews days ago in DNSext is needed. I'll repost it here. >> >> > > i would prefer it if you impose no changes to getaddrinfo/getnameinfo > with your proposal. arrangements within server side would be better > at this stage > (we can't change deployed codebase any longer, there are huge number > of Solaris 8 boxen out there). > I would like not to change it too, but the alternative to create records on the fly in the DNS servers is an invitation for DOS attack on DNSsec... - Alain. From owner-v6ops@ops.ietf.org Mon Nov 11 20:11:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07603 for ; Mon, 11 Nov 2002 20:11:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BPaL-000A3d-00 for v6ops-data@psg.com; Mon, 11 Nov 2002 17:11:21 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 18BPaI-000A2M-00 for v6ops@ops.ietf.org; Mon, 11 Nov 2002 17:11:18 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA11589; Mon, 11 Nov 2002 17:10:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAC1AaS03994; Mon, 11 Nov 2002 17:10:36 -0800 X-mProtect: <200211120110> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcnnvfy; Mon, 11 Nov 2002 17:10:34 PST Message-ID: <3DD0561D.8090708@iprg.nokia.com> Date: Mon, 11 Nov 2002 17:15:09 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org Subject: Re: Questions on Configured Tunnel MTU and TOS Byte Settings Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=5.0 tests=SPAM_PHRASE_05_08,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit FYI, Below is a message from Matt Mathis (fwd'd with his permission) announcing a new mailing list for MTU discussions. Matt has also posted an interesting new document titled: "Path MSS Discovery". See: http://www.psc.edu/~mathis/MTU/draft-mathis-MSS-discovery.txt Fred Templin ftemplin@iprg.nokia.com > Date: Thu, 7 Nov 2002 15:49:05 -0500 (EST) > From: Matt Mathis > Subject: Please subscribe to a new MTU mailling list (fwd) > Message-ID: > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Content-Length: 666 > > For all *technical* and *public policy* issues pertaining to pushing up the > Internet MTU. This is an open list, so please be careful. You must be > subscribed to post. > > See http://www.psc.edu/~mathis/MTU for more information > > If you are interested, please subscribe YOURSELF by sending a note to > majordomo@psc.edu with: > subscribe mtu > or > subscribe mtu > in the body. Please forward this message to anybody else who may be > interested. > > Thanks, > --MM-- From owner-v6ops@ops.ietf.org Tue Nov 12 14:18:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10894 for ; Tue, 12 Nov 2002 14:18:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BgY6-000AdZ-00 for v6ops-data@psg.com; Tue, 12 Nov 2002 11:18:10 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18BgY5-000Aci-00 for v6ops@ops.ietf.org; Tue, 12 Nov 2002 11:18:09 -0800 Received: from kenawang.windriver.com ([147.11.233.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA11843 for ; Tue, 12 Nov 2002 11:17:23 -0800 (PST) Message-Id: <5.1.0.14.2.20021112141345.074a6ec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Nov 2002 14:17:26 -0500 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Minor Charter Updates Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI -- We have a new charter available at: http://www.ietf.org/html.charters/v6ops-charter.html The new charter includes the changes that we discussed at the interim meeting, including: - Switching items (6) and (7) - Removing the use of the undefined term "deployment issues" - Changing the name of the deployment solutions documents to deployment analysis documents. Some of our milestones were also updated, based on current status. Margaret From owner-v6ops@ops.ietf.org Tue Nov 12 18:02:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19311 for ; Tue, 12 Nov 2002 18:02:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Bk3k-000GQf-00 for v6ops-data@psg.com; Tue, 12 Nov 2002 15:03:04 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18Bk3g-000GQN-00 for v6ops@ops.ietf.org; Tue, 12 Nov 2002 15:03:00 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Bk3g-000D9D-00 for v6ops@ops.ietf.org; Tue, 12 Nov 2002 15:03:00 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: v6ops@ops.ietf.org Subject: draft-ymbk-sparse-v6-allocation-00.txt Message-Id: Date: Tue, 12 Nov 2002 15:03:00 -0800 X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit i doubt this is worth discussion in the wg meeting in atlanta, as it is more process than engineering. but folk may be interested anyway, and may want to ding me on it in the corridors. http://psg.com/~randy/draft-ymbk-sparse-v6-allocation-00.txt http://psg.com/~randy/draft-ymbk-sparse-v6-allocation-00.html Abstract This document proposes that the IAB request the IANA to allocate the address space for the IPv6 2000::/3 prefix to the Common Registration Service for further allocation under the registry plan for IPv6 Address Space Management. randy From owner-v6ops@ops.ietf.org Tue Nov 12 18:47:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20210 for ; Tue, 12 Nov 2002 18:47:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Bkn6-000HVN-00 for v6ops-data@psg.com; Tue, 12 Nov 2002 15:49:56 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18Bkn1-000HV2-00 for v6ops@ops.ietf.org; Tue, 12 Nov 2002 15:49:51 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Bkmz-000ESl-00; Tue, 12 Nov 2002 15:49:49 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Margaret Wasserman Cc: v6ops@ops.ietf.org Subject: Re: Minor Charter Updates References: <5.1.0.14.2.20021112141345.074a6ec0@mail.windriver.com> Message-Id: Date: Tue, 12 Nov 2002 15:49:49 -0800 X-Spam-Status: No, hits=-5.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The v6ops working group will it is time for the present tense throughout > 2. Provide feedback to the IPv6 WG regarding portions of the IPv6 > specifications that cause, or are likely to cause, operational > or security concerns, and work with the IPv6 WG to resolve > those concerns. This feedback will be published in > Internet-Drafts or RFCs. s/will/may/ > 5. should be specific that the developed scenarios will drive the selection of tools and protocol changes. i.e. make explicit the move from "this might be useful" to "it must be useful." > NOV 02 Publish Unmanaged Network Deployment Scenarios as a WG I-D > NOV 02 Publish ISP Deployment Scenarios as a WG I-D > NOV 02 Publish Survey of IPv4 Addresses in IETF Standards as WG > I-D > NOV 02 Publish Cellular Deployment Solutions as a WG I-D should natalia syracuse (a personal heroine of mine, especially in this season) hold her breath? randy From owner-v6ops@ops.ietf.org Wed Nov 13 07:05:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28263 for ; Wed, 13 Nov 2002 07:05:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BwHt-0007zi-00 for v6ops-data@psg.com; Wed, 13 Nov 2002 04:06:29 -0800 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 3.36 #2) id 18BwHm-0007y9-00 for v6ops@ops.ietf.org; Wed, 13 Nov 2002 04:06:22 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00963; Wed, 13 Nov 2002 04:05:19 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gADC5IL21436; Wed, 13 Nov 2002 13:05:18 +0100 (MET) Date: Wed, 13 Nov 2002 13:02:13 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on draft-ietf-ngtrans-mech-v2-01.txt To: "Fred L. Templin" Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3DCC076A.70203@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > In section 3.2, the following text appears (actually, > this is unchanged since mech-v2-00.txt): > > Encapsulating nodes that have a large number of tunnels might not be > able to store the IPv4 Path MTU for all tunnels. Such nodes can, at > the expense of additional fragmentation in the network, avoid using > the IPv4 Path MTU algorithm across the tunnel and instead use the MTU > of the link layer (under IPv4) in the above algorithm instead of the > IPv4 path MTU. > > In this case the Don't Fragment bit MUST NOT be set in the > encapsulating IPv4 header. > > When you say: "...and instead use the MTU of the link layer (under IPv4) > in the above algorithm...", it is not clear whether you mean the *full* > MTU of an arbitrary link layer, or the MTU of the link layer *up to > some limit* (e.g., 4400 bytes). If your meaning is the latter, then > it would help make things clearer if you re-iterate the 4400 byte > limit in this text also. Thanks for catching this inconsistency. The intent is that this be limited by the magic number as well - and the magic number (currently) in the document for encapsulators that don't do path MTU discovery is 1280. So how about adding: In that case the IPv6 MTU for the tunnel SHOULD be limited to 1280 and MUST not exceed 4400. > I believe you should also state somewhere that section 3.2 provides > only a *limited* tunnel MTU configuration mechanism. A more generalized > mechanism is possible if explicit fedback from the decapsulator is > available. For example, see: > > http://www.ietf.org/internet-drafts/draft-templin-v6v4-ndisc-01.txt Hmm - I don't know how to do this without creating a reference against that draft. Perhaps you can suggest concrete text that we can look at. Erik From owner-v6ops@ops.ietf.org Wed Nov 13 07:22:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28628 for ; Wed, 13 Nov 2002 07:22:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BwW1-0008Gy-00 for v6ops-data@psg.com; Wed, 13 Nov 2002 04:21:05 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18BwVy-0008GX-00 for v6ops@ops.ietf.org; Wed, 13 Nov 2002 04:21:02 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21300; Wed, 13 Nov 2002 05:20:59 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gADCKwL22766; Wed, 13 Nov 2002 13:20:58 +0100 (MET) Date: Wed, 13 Nov 2002 13:17:53 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: (ngtrans) Questions on Configured Tunnel MTU and TOS Byte Settings To: Brian E Carpenter Cc: Roy Brabson , ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3DCFC87A.7FCF7ABC@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Firstl there is an important typo in the references. [20] should be > RFC 2983 and *not* 2893. 2983 is the diffserv/tunnels RFC. Oops. Will fix. Erik From owner-v6ops@ops.ietf.org Wed Nov 13 07:22:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28644 for ; Wed, 13 Nov 2002 07:22:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18BwUj-0008E5-00 for v6ops-data@psg.com; Wed, 13 Nov 2002 04:19:45 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18BwUe-0008Do-00 for v6ops@ops.ietf.org; Wed, 13 Nov 2002 04:19:41 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09022; Wed, 13 Nov 2002 05:19:38 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gADCJaL22528; Wed, 13 Nov 2002 13:19:36 +0100 (MET) Date: Wed, 13 Nov 2002 13:16:31 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Questions on Configured Tunnel MTU and TOS Byte Settings To: Roy Brabson Cc: ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I've got a few of questions on configured tunnels, as described in > draft-ietf-ngtrans-mech-v2-01.txt. > > - Section 3.2 discusses how to set the tunnel MTU. It covers the case > where the tunnel MTU size is manually configured, with a default of > 1280. While it discusses capping the tunnel MTU at 4400 when IPv4 > path MTU discovery is used, it doesn't discuss a maximum configured > value for the tunnel. Does this mean there is no cap when manually > configuring the tunnel MTU (i.e., the configured tunnel MTU may be as > large as 65515, or even larger if jumbograms are used?) It might be worth while to separate what the document currently says and what folks want it to say. I saw some comments that for a configured tunnel it makes sense to allow the encapsulator and decapsulator to (out of band) agree on what mtu to use for the tunnel. Thus as long as the decapsulator is capable of reassembling IPv4 packets of size X for the tunnel, the encapsulator can be configured to use size X for that tunnel's MTU. But in the case when the tunnel MTU isn't explicitly configured, it must have a default which all receivers are required to be able to reassemble. Does that make sense to folks as the intent? Does this mean that we should add some warnings that it doesn't make sense to configure the tunnel MTU to be larger than the IPv4 path MTU between the encapsulator and decapsulator? > - The same section does not discuss what a host should do if it receives a > Router Advertisement with an MTU option. Should the MTU value received > be used? If so, is there a cap associated with this MTU value? In > other words, if it exceeds 4400 bytes should the value be used? Good question. I assume the issue is confined to an RA with the MTU option received on the tunnel interface. In RFC 2461 is says that the advertised MTU should not be used when it exceeds the default MTU specified in the link type specific document (e.g. IPv6 over Ethernet). Does that mean that it shouldn't be used when it exceeds 4400? 1280? > - In section 3.5, the TOS byte is defined as being set to 0 unless > otherwise specified. What exactly does this mean? That, if RFC 2893 is > followed the DSCP in the TOS byte may be set to a non-zero value? Or > that RFC 2893 and RFC 3168 should explicitly NOT be implemented for > configured tunnels? If the latter, I think some discussion on exactly > WHY these two RFCs are not to be implemented would be helpful. The intent is that the setting of the TOS byte for tunnels is specified in other documents, but we do not want to have a normative reference on those documents since it would create an obstacle to moving this draft to Draft Standard. Any suggestions on how to make this more clear? > - In section 3.6, the TOS byte of the inner packet is left unmodified at > the tunnel egress. This seems to contradict some of the referenced. > For instance, RFC 3168 defines both limited-functionality and > full-functionality support for ECN support over tunnels. For > limited-functionality, which seems to most closely match what is > described in this draft, it discusses what to do at the tunnel egress if > the CE option is set in the outer packet header but not the inner packet > header. This processing does not seem to match what is described in > this draft. Is this intentional? Same isssue as above. If RFC 3168 was moved to draft standard status we could have more prescriptive language. Erik From owner-v6ops@ops.ietf.org Wed Nov 13 09:10:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01599 for ; Wed, 13 Nov 2002 09:10:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ByFE-000Ak8-00 for v6ops-data@psg.com; Wed, 13 Nov 2002 06:11:52 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #2) id 18ByFB-000Aii-00; Wed, 13 Nov 2002 06:11:49 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gADEBFdK062296; Wed, 13 Nov 2002 15:11:15 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gADEBClO093218; Wed, 13 Nov 2002 15:11:15 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA64622 from ; Wed, 13 Nov 2002 15:11:10 +0100 Message-Id: <3DD25D6E.A1C356AF@hursley.ibm.com> Date: Wed, 13 Nov 2002 15:10:54 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Randy Bush Cc: v6ops@ops.ietf.org Subject: Re: draft-ymbk-sparse-v6-allocation-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Cite RFC 1881 "IPv6 Address Allocation Management." Otherwise, no brainer. It's a power shift, but a good one IMHO. Brian Randy Bush wrote: > > i doubt this is worth discussion in the wg meeting in atlanta, as it > is more process than engineering. but folk may be interested anyway, > and may want to ding me on it in the corridors. > > http://psg.com/~randy/draft-ymbk-sparse-v6-allocation-00.txt > http://psg.com/~randy/draft-ymbk-sparse-v6-allocation-00.html > > Abstract > > This document proposes that the IAB request the IANA to allocate the > address space for the IPv6 2000::/3 prefix to the Common Registration > Service for further allocation under the registry plan for IPv6 > Address Space Management. > > randy From owner-v6ops@ops.ietf.org Wed Nov 13 09:31:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02384 for ; Wed, 13 Nov 2002 09:31:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ByaL-000BKj-00 for v6ops-data@psg.com; Wed, 13 Nov 2002 06:33:41 -0800 Received: from web13008.mail.yahoo.com ([216.136.174.18]) by psg.com with smtp (Exim 3.36 #2) id 18ByaI-000BKJ-00 for v6ops@ops.ietf.org; Wed, 13 Nov 2002 06:33:38 -0800 Message-ID: <20021113143337.36325.qmail@web13008.mail.yahoo.com> Received: from [63.197.18.101] by web13008.mail.yahoo.com via HTTP; Wed, 13 Nov 2002 06:33:37 PST Date: Wed, 13 Nov 2002 06:33:37 -0800 (PST) From: Fred Templin Subject: Re: Comments on draft-ietf-ngtrans-mech-v2-01.txt To: v6ops@ops.ietf.org Cc: osprey67@yahoo.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.6 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,MAILTO_TO_SPAM_ADDR, QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --- Erik Nordmark wrote: > > I believe you should also state somewhere that section 3.2 provides > > only a *limited* tunnel MTU configuration mechanism. A more generalized > > mechanism is possible if explicit fedback from the decapsulator is > > available. For example, see: > > > > http://www.ietf.org/internet-drafts/draft-templin-v6v4-ndisc-01.txt > > Hmm - I don't know how to do this without creating a reference > against that draft. Perhaps you can suggest concrete text that we can > look at. Best to wait for the -02 version of that draft. I'd be happy to talk about what's right and what's wrong with the -01 version at IETF 55. Fred Templin osprey67@yahoo.com __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 From owner-v6ops@ops.ietf.org Thu Nov 14 05:51:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15246 for ; Thu, 14 Nov 2002 05:51:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CHc8-000109-00 for v6ops-data@psg.com; Thu, 14 Nov 2002 02:52:48 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18CHc6-0000zx-00 for v6ops@ops.ietf.org; Thu, 14 Nov 2002 02:52:47 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAEAqiK02281 for ; Thu, 14 Nov 2002 12:52:44 +0200 Date: Thu, 14 Nov 2002 12:52:44 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-01.txt In-Reply-To: <200211081235.HAA15814@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 8 Nov 2002 Internet-Drafts@ietf.org wrote: > Title : Basic Transition Mechanisms for IPv6 Hosts and Routers > Author(s) : E. Nordmark, R. Gilligan > Filename : draft-ietf-ngtrans-mech-v2-01.txt > Pages : 25 > Date : 2002-11-7 Just two comments on this: This dynamic MTU determination is OPTIONAL. However, if it is implemented it SHOULD have the behavior described in this document and the tunnel MTU MUST be not exceed 4400 bytes. If it is not implemented instead the node MUST instead limit the size of the IPv6 packets it tunnels to 1280 bytes i.e., treat the tunnel interface as having a fixed interface MTU of 1280 bytes. An implementation MAY have a configuration knob which can be used to set a larger value of the tunnel MTU than 1280 bytes, but if so the default MUST be 1280 bytes. ==> 1) does 'tunnel MTU MUST be not exceed 4400 bytes' only apply to the dynamic MTU determination part or also to "manual configuration" part? (probably the latter, but it's a bit unclear.) 2) Why just 4400, not e.g. 4500? (Note: ATM/POS links usually have a default MTU of 4470 bytes, so either 4470+20 or 4470-20 (depending on which kind of encapsulation you believe is more useful) would be one interesting compromise, I believe.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 14 10:00:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21008 for ; Thu, 14 Nov 2002 10:00:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CLSJ-0008Um-00 for v6ops-data@psg.com; Thu, 14 Nov 2002 06:58:55 -0800 Received: from web13001.mail.yahoo.com ([216.136.174.11]) by psg.com with smtp (Exim 3.36 #2) id 18CLSG-0008UR-00 for v6ops@ops.ietf.org; Thu, 14 Nov 2002 06:58:53 -0800 Message-ID: <20021114145851.63742.qmail@web13001.mail.yahoo.com> Received: from [63.197.18.101] by web13001.mail.yahoo.com via HTTP; Thu, 14 Nov 2002 06:58:51 PST Date: Thu, 14 Nov 2002 06:58:51 -0800 (PST) From: Fred Templin Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-01.txt To: Pekka Savola , v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.9 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,MAILTO_TO_SPAM_ADDR, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Another thing to note about MTUs is that bigger is NOT always better. Take wireless media for example, where bit error rates are high. The larger the packet, the more exposure to the high bit error rate and the greater the probability of loss or long delays due to link-level retransmissions. 1500 bytes should be a plenty-large MTU for any wireless media unless/until some laws of physics are bent to allow a more efficient transmission media than RF. Pretty much all routers these days can handle 1500 byte packets, and it doesn't take *any* signalling between the encapsulator and decapsulator to determine that. The problem comes if you err a bit on the high side, incurring fragmentation in the network if additional link-level encapsulations occur. "Beyond Folklore: Observations on Fragmented Traffic" observes that tunneled traffic is the #2 contributer to fragmentation due to mis-configured MTUs. Packet lengths of 1520 - 1636 bytes in fragmented series were observed, with 1520 (due to a 20-byte IPv4 encapsulation layer) and 1572 (due to 20 byte IPv4 and 52-byte L2TP/PPTP ecapsualtion for VPN) by far the most common. This situation is to be avoided for transition mechanism tunneling, since fragmentation at 1500 bytes usually results in a maximum-sized packet followed by a "tinygram" of 20 - 72 data bytes plus 20 additional bytes for the IPv4 fragment header, which is terribly inefficient. Consider finally that if the network is going to fragment packets on a smaller granularity than 1500 bytes, it will likely do so at 576 bytes (a common MTU for some serial line protocols), as observed in "Beyond Folklore: Observations on Fragmented Traffic". But, both 1280 and 1500 byte packets will require 3 fragments in this case, so it makes no sense to to err on the low side. Conclusion - the fixed interface MTU of 1280 bytes suggested in the MECH text is too small. I suggest it be changed to 1428 (1500 minus 72 for IPv4/VPN encaps). Fred Templin osprey67@yahoo.com --- Pekka Savola wrote: > On Fri, 8 Nov 2002 Internet-Drafts@ietf.org wrote: > > Title : Basic Transition Mechanisms for IPv6 Hosts and Routers > > Author(s) : E. Nordmark, R. Gilligan > > Filename : draft-ietf-ngtrans-mech-v2-01.txt > > Pages : 25 > > Date : 2002-11-7 > > Just two comments on this: > > This dynamic MTU determination is OPTIONAL. However, if it is > implemented it SHOULD have the behavior described in this document > and the tunnel MTU MUST be not exceed 4400 bytes. If it is not > implemented instead the node MUST instead limit the size of the IPv6 > packets it tunnels to 1280 bytes i.e., treat the tunnel interface as > having a fixed interface MTU of 1280 bytes. An implementation MAY > have a configuration knob which can be used to set a larger value of > the tunnel MTU than 1280 bytes, but if so the default MUST be 1280 > bytes. > > ==> > 1) does 'tunnel MTU MUST be not exceed 4400 bytes' only apply to the > dynamic MTU determination part or also to "manual configuration" part? > (probably the latter, but it's a bit unclear.) > > 2) Why just 4400, not e.g. 4500? (Note: ATM/POS links usually have a > default MTU of 4470 bytes, so either 4470+20 or 4470-20 (depending on > which kind of encapsulation you believe is more useful) would be one > interesting compromise, I believe.) > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com From owner-v6ops@ops.ietf.org Thu Nov 14 20:51:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13236 for ; Thu, 14 Nov 2002 20:51:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CVfG-000E8n-00 for v6ops-data@psg.com; Thu, 14 Nov 2002 17:52:58 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with esmtp (Exim 3.36 #2) id 18CVfF-000E4z-00 for v6ops@ops.ietf.org; Thu, 14 Nov 2002 17:52:57 -0800 Received: from mail6.microsoft.com ([157.54.6.196]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 14 Nov 2002 17:52:26 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 14 Nov 2002 17:52:25 -0800 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Nov 2002 17:52:25 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 14 Nov 2002 17:52:18 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 14 Nov 2002 17:52:25 -0800 Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Thu, 14 Nov 2002 17:52:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-01.txt Date: Thu, 14 Nov 2002 17:52:24 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1073843EF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-01.txt thread-index: AcKL8UQECHSuGlfDQ9uO7DWCQFL74QAV5GfA From: "Dave Thaler" To: "Fred Templin" Cc: "Pekka Savola" , X-OriginalArrivalTime: 15 Nov 2002 01:52:24.0243 (UTC) FILETIME=[A4A2D030:01C28C49] X-Spam-Status: No, hits=-1.9 required=5.0 tests=MAILTO_TO_SPAM_ADDR,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA13236 > From: Fred Templin [mailto:osprey67@yahoo.com] [...] > Conclusion - the fixed interface MTU of 1280 bytes suggested in the > MECH text is too small. I suggest it be changed to 1428 (1500 minus > 72 for IPv4/VPN encaps). I'm told by our VPN folks here that the MTU on our IPv4 VPN interfaces is 1400. This was based on overhead for IP+AH+ESP+UDP+L2TP+PPP, and still fitting in an Ethernet MTU. Hence to avoid gratuitous fragmentation, we'd want the MTU inside an IPv6-over-IPv4 tunnel interface to be at most 1380. -Dave From owner-v6ops@ops.ietf.org Fri Nov 15 05:38:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04464 for ; Fri, 15 Nov 2002 05:38:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Cdrr-000F6V-00 for v6ops-data@psg.com; Fri, 15 Nov 2002 02:38:31 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18Cdrp-000F69-00 for v6ops@ops.ietf.org; Fri, 15 Nov 2002 02:38:29 -0800 Received: from kenawang.windriver.com ([147.11.72.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id CAA21420 for ; Fri, 15 Nov 2002 02:37:42 -0800 (PST) Message-Id: <5.1.0.14.2.20021115053804.02abb310@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Nov 2002 05:39:30 -0500 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: v6ops Agenda for Atlanta Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Here is the draft agenda for our v6ops meeting in Atlanta. Please let me know if there are any questions or comments, or if I seem to have omitted anything. Margaret IPv6 Operations WG (v6ops) Wednesday, November 20, 2002, 0900-1130 ======================================= CHAIRS: Jun-ichiro "Itojun" Hagino Margaret Wasserman AGENDA: Introduction and Agenda Bashing -- Margaret (5 min) Report from Interim Meeting -- Margaret (5 min) Deployment Scenario/Analysis Status & Open Issues: Unmanaged Networks Team -- Christian Huitema (20 min) http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-unmanscope-02.txt http://www.ietf.org/internet-drafts/draft-huitema-ngtrans-unmaneval-01.txt ISP Team -- Cleve Mickles (20 min) http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-02.txt Enterprise Team -- Yanick Pouffary (20 min) http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-01.txt Cellular Networks Team -- Jonne Soininen (20 min) http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-00.txt http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-transition-02.txt Current Work Items (Status & Open Issues): Transition Mechanisms -- Erik Nordmark (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-v2-01.txt Proposals for New Work Items: Application Aspects of IPv6 Transition (5min) - Myung-Ki Shin http://www.ipv6.or.kr/Internet-Draft/draft-shin-v6ops-application-transition-00.txt 6to4 Security -- Pekka Savola (5 min) http://www.ietf.org/internet-drafts/draft-savola-v6ops-6to4-security-00.txt Firewalling Considerations for IPv6 -- Pekka Savola (5 min) http://www.ietf.org/internet-drafts/draft-savola-v6ops-firewalling-00.txt IPv4 Mapped Addresses Considered Harmful -- Craig Metz (10 min) http://www.ietf.org/internet-drafts/draft-cmetz-v6ops-v4mapped-api-harmful-00.txt http://www.ietf.org/internet-drafts/draft-itojun-v6ops-v4mapped-harmful-01.txt From owner-v6ops@ops.ietf.org Fri Nov 15 10:40:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10765 for ; Fri, 15 Nov 2002 10:40:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CiYk-0001IY-00 for v6ops-data@psg.com; Fri, 15 Nov 2002 07:39:06 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #2) id 18CiYi-0001IM-00 for v6ops@ops.ietf.org; Fri, 15 Nov 2002 07:39:04 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 68DCC9C20; Fri, 15 Nov 2002 10:39:03 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 15 Nov 2002 10:39:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: API Discussion RE: v6ops Agenda for Atlanta Date: Fri, 15 Nov 2002 10:39:02 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9B2D@tayexc13.americas.cpqcorp.net> Thread-Topic: API Discussion RE: v6ops Agenda for Atlanta Thread-Index: AcKMlHOgtGaXbnYOR4a/H2aZxfl8dgAKGcTQ From: "Bound, Jim" To: "Margaret Wasserman" , X-OriginalArrivalTime: 15 Nov 2002 15:39:03.0235 (UTC) FILETIME=[1FF06130:01C28CBD] X-Spam-Status: No, hits=-2.9 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA10765 Why is ipv4mapped still being discussed in this sense. Itojun was told clearly that we are NOT going to change the API defaults with current deployed products. This has been discusseed to death and a standard in IEEE. Any other working group member who was NOT the chair would be told to go away. /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Friday, November 15, 2002 5:40 AM > To: v6ops@ops.ietf.org > Subject: v6ops Agenda for Atlanta > > > > Here is the draft agenda for our v6ops meeting in Atlanta. > Please let me know if there are any questions or comments, or > if I seem to have omitted anything. > > Margaret > > > > IPv6 Operations WG (v6ops) > Wednesday, November 20, 2002, 0900-1130 > ======================================= > > CHAIRS: Jun-ichiro "Itojun" Hagino > Margaret Wasserman > > AGENDA: > > Introduction and Agenda Bashing -- Margaret (5 min) > > Report from Interim Meeting -- Margaret (5 min) > > Deployment Scenario/Analysis Status & Open Issues: > > Unmanaged Networks Team -- Christian Huitema (20 min) > > http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-unmansc > ope-02.txt > > http://www.ietf.org/internet-drafts/draft-huitema-ngtrans-unma neval-01.txt ISP Team -- Cleve Mickles (20 min) http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-02.txt Enterprise Team -- Yanick Pouffary (20 min) http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-01.tx t Cellular Networks Team -- Jonne Soininen (20 min) http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-00.txt http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-transition- 02.txt Current Work Items (Status & Open Issues): Transition Mechanisms -- Erik Nordmark (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-v2-01.txt Proposals for New Work Items: Application Aspects of IPv6 Transition (5min) - Myung-Ki Shin http://www.ipv6.or.kr/Internet-Draft/draft-shin-v6ops-application-transi tion-00.txt 6to4 Security -- Pekka Savola (5 min) http://www.ietf.org/internet-drafts/draft-savola-v6ops-6to4-security-00. txt Firewalling Considerations for IPv6 -- Pekka Savola (5 min) http://www.ietf.org/internet-drafts/draft-savola-v6ops-firewalling-00.tx t IPv4 Mapped Addresses Considered Harmful -- Craig Metz (10 min) http://www.ietf.org/internet-drafts/draft-cmetz-v6ops-v4mapped-api-harmf ul-00.txt http://www.ietf.org/internet-drafts/draft-itojun-v6ops-v4mapped-harmful- 01.txt From owner-v6ops@ops.ietf.org Fri Nov 15 11:34:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11864 for ; Fri, 15 Nov 2002 11:34:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CjQM-0002wx-00 for v6ops-data@psg.com; Fri, 15 Nov 2002 08:34:30 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18CjQC-0002vv-00 for v6ops@ops.ietf.org; Fri, 15 Nov 2002 08:34:20 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA10805; Fri, 15 Nov 2002 08:33:27 -0800 (PST) Message-Id: <5.1.0.14.0.20021115112136.03f04df0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Nov 2002 11:33:17 -0500 To: "Bound, Jim" , From: Margaret Wasserman Subject: Re: API Discussion RE: v6ops Agenda for Atlanta In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9B2D@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim, It is true that we did discuss the IPv4 mapped address issues in Sunnyvale. At that time, Itojun presented one draft that concerned two different parts of the issue: what should and shouldn't be sent on the wire, and what should and shouldn't be passed by the API, particularly in a dual stack. There was some agreement in the meeting that there are issues with using IPv4 mapped addresses on the wire that need to be documented, although it was not clear what action we should recommend to correct these issues -- updating the IPv6 addressing architecture, modifying SIIT, etc. The API portion was much more controversial, and there was a general consensus in the room not to impose any API changes on existing implementations. Of course, the whole WG was not necessarily represented at the meeting. Based on the input they received in Sunnyvale, Craig and Itojun have split the document into two parts -- the on-wire part and the API part, and they have updated both parts. This will allow us to consider the two parts separately. There was enough interest and discussion in Sunnyvale, at least regarding the on-wire issues that it seemed worthwhile to discuss this again in Atlanta to see if this is something that the v6ops WG should document. Margaret At 10:39 AM 11/15/2002 -0500, Bound, Jim wrote: >Why is ipv4mapped still being discussed in this sense. Itojun was told >clearly that we are NOT going to change the API defaults with current >deployed products. This has been discusseed to death and a standard in >IEEE. > >Any other working group member who was NOT the chair would be told to go >away. > >/jim >[Honor, Commitment, Integrity] > > > > -----Original Message----- > > From: Margaret Wasserman [mailto:mrw@windriver.com] > > Sent: Friday, November 15, 2002 5:40 AM > > To: v6ops@ops.ietf.org > > Subject: v6ops Agenda for Atlanta > > > > > > > > Here is the draft agenda for our v6ops meeting in Atlanta. > > Please let me know if there are any questions or comments, or > > if I seem to have omitted anything. > > > > Margaret > > > > > > > > IPv6 Operations WG (v6ops) > > Wednesday, November 20, 2002, 0900-1130 > > ======================================= > > > > CHAIRS: Jun-ichiro "Itojun" Hagino > > Margaret Wasserman > > > > AGENDA: > > > > Introduction and Agenda Bashing -- Margaret (5 min) > > > > Report from Interim Meeting -- Margaret (5 min) > > > > Deployment Scenario/Analysis Status & Open Issues: > > > > Unmanaged Networks Team -- Christian Huitema (20 min) > > > > http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-unmansc > > ope-02.txt > > > > http://www.ietf.org/internet-drafts/draft-huitema-ngtrans-unma >neval-01.txt > > ISP Team -- Cleve Mickles (20 min) > >http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-02.txt > > Enterprise Team -- Yanick Pouffary (20 min) > >http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-01.tx >t > > Cellular Networks Team -- Jonne Soininen (20 min) > >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-00.txt > >http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-transition- >02.txt > >Current Work Items (Status & Open Issues): > > Transition Mechanisms -- Erik Nordmark (10 min) > >http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-v2-01.txt > >Proposals for New Work Items: > > Application Aspects of IPv6 Transition (5min) - Myung-Ki Shin > >http://www.ipv6.or.kr/Internet-Draft/draft-shin-v6ops-application-transi >tion-00.txt > > 6to4 Security -- Pekka Savola (5 min) > >http://www.ietf.org/internet-drafts/draft-savola-v6ops-6to4-security-00. >txt > > Firewalling Considerations for IPv6 -- Pekka Savola (5 min) > >http://www.ietf.org/internet-drafts/draft-savola-v6ops-firewalling-00.tx >t > > IPv4 Mapped Addresses Considered Harmful -- Craig Metz (10 min) > >http://www.ietf.org/internet-drafts/draft-cmetz-v6ops-v4mapped-api-harmf >ul-00.txt > > >http://www.ietf.org/internet-drafts/draft-itojun-v6ops-v4mapped-harmful- >01.txt From owner-v6ops@ops.ietf.org Fri Nov 15 12:36:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13127 for ; Fri, 15 Nov 2002 12:36:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CkPb-0004sh-00 for v6ops-data@psg.com; Fri, 15 Nov 2002 09:37:47 -0800 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 18CkPY-0004sC-00 for v6ops@ops.ietf.org; Fri, 15 Nov 2002 09:37:44 -0800 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAFHbfQ1024730; Fri, 15 Nov 2002 18:37:42 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 15 Nov 2002 18:37:41 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0D10@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" , "Bound, Jim" , v6ops@ops.ietf.org Subject: RE: API Discussion RE: v6ops Agenda for Atlanta Date: Fri, 15 Nov 2002 18:37:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-1.2 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > It is true that we did discuss the IPv4 mapped address issues in > Sunnyvale. At that time, > Itojun presented one draft that concerned two different > parts of the > issue: what should and > shouldn't be sent on the wire, and what should and > shouldn't be passed by > the API, > particularly in a dual stack. > > There was some agreement in the meeting that there are > issues with using > IPv4 mapped > addresses on the wire that need to be documented, although > it was not clear > what action we > should recommend to correct these issues -- updating the > IPv6 addressing > architecture, > modifying SIIT, etc. => I would not say we agreed on this, I for one don't think the scenarios presented by Itojun as valid. I believe others made the same comment. Hesham From owner-v6ops@ops.ietf.org Fri Nov 15 12:50:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13801 for ; Fri, 15 Nov 2002 12:50:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ckcn-0005IF-00 for v6ops-data@psg.com; Fri, 15 Nov 2002 09:51:25 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #2) id 18Ckck-0005Hz-00 for v6ops@ops.ietf.org; Fri, 15 Nov 2002 09:51:22 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 484E52AF5; Fri, 15 Nov 2002 12:51:21 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 15 Nov 2002 12:51:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: API Discussion RE: v6ops Agenda for Atlanta Date: Fri, 15 Nov 2002 12:51:20 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240C2D@tayexc13.americas.cpqcorp.net> Thread-Topic: API Discussion RE: v6ops Agenda for Atlanta Thread-Index: AcKMxMmvLAYKRhbgSAqkTEXGNuJcmwABy3YQ From: "Bound, Jim" To: "Margaret Wasserman" , X-OriginalArrivalTime: 15 Nov 2002 17:51:21.0130 (UTC) FILETIME=[9B4B08A0:01C28CCF] X-Spam-Status: No, hits=-4.2 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA13801 Hi Margaret, > Hi Jim, > > It is true that we did discuss the IPv4 mapped address issues in > Sunnyvale. At that time, > Itojun presented one draft that concerned two different parts of the > issue: what should and > shouldn't be sent on the wire, and what should and shouldn't > be passed by > the API, > particularly in a dual stack. Yes I was there. > > There was some agreement in the meeting that there are issues > with using > IPv4 mapped > addresses on the wire that need to be documented, although it > was not clear > what action we > should recommend to correct these issues -- updating the > IPv6 addressing > architecture, > modifying SIIT, etc. I agree and was there. > > The API portion was much more controversial, and there was a general > consensus in the room > not to impose any API changes on existing implementations. > Of course, the > whole WG was not > necessarily represented at the meeting. What you say is true and that was the feeling. My issue is that this was discussed on ipng and the apifolks design team. So what we heard at Sunnyvale Interim meeting is consensus already and Itojun and Craig know that. So I don't see why we are revisting it again. But it feels like v6ops is being duped to bring it up yet again. The problem is that the current API defaults are deployed in production and supported in practice and spirit by all but two implementations is my knowledge. The API is now not 2553 but an IEEE spec/std. So I sense politics here but if you want to have this come up again that is your choice as chair. But we are not going to break customers at this point using IPv6 is my strong guess. > > Based on the input they received in Sunnyvale, Craig and > Itojun have split > the document into > two parts -- the on-wire part and the API part, and they have > updated both > parts. This will > allow us to consider the two parts separately. That is good. > > There was enough interest and discussion in Sunnyvale, at > least regarding > the on-wire issues > that it seemed worthwhile to discuss this again in Atlanta to > see if this > is something that the > v6ops WG should document. If this is the discussion I fully agree. Thanks for listening to my point and responding, /jim From owner-v6ops@ops.ietf.org Fri Nov 15 15:13:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17607 for ; Fri, 15 Nov 2002 15:13:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Cmp9-000Agh-00 for v6ops-data@psg.com; Fri, 15 Nov 2002 12:12:19 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 18Cmp7-000Ag7-00 for v6ops@ops.ietf.org; Fri, 15 Nov 2002 12:12:17 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA09181; Fri, 15 Nov 2002 12:11:38 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAFKBbY02359; Fri, 15 Nov 2002 12:11:37 -0800 X-mProtect: <200211152011> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdT9FE4e; Fri, 15 Nov 2002 12:11:35 PST Message-ID: <3DD55621.5020209@iprg.nokia.com> Date: Fri, 15 Nov 2002 12:16:33 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org CC: Dave Thaler , Fred Templin , Pekka Savola Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-01.txt References: <2E33960095B58E40A4D3345AB9F65EC1073843EF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=MAILTO_TO_SPAM_ADDR,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave Thaler wrote: >>From: Fred Templin [mailto:osprey67@yahoo.com] > > [...] > >>Conclusion - the fixed interface MTU of 1280 bytes suggested in the >>MECH text is too small. I suggest it be changed to 1428 (1500 minus >>72 for IPv4/VPN encaps). > > > I'm told by our VPN folks here that the MTU on our IPv4 VPN > interfaces is 1400. This was based on overhead for > IP+AH+ESP+UDP+L2TP+PPP, and still fitting in an Ethernet MTU. > > Hence to avoid gratuitous fragmentation, we'd want the MTU > inside an IPv6-over-IPv4 tunnel interface to be at most 1380. > > -Dave Regarding the tunnel MTU, my conclusion was incorrect. Fragmentation due to improperly-configured tunnel MTUs is a growing problem in the Internet, thus it is very important that we get this right. Many thanks to Dave Thaler and his colleagues for the accurate analysis. Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Fri Nov 15 15:43:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18562 for ; Fri, 15 Nov 2002 15:43:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CnK9-000Bxa-00 for v6ops-data@psg.com; Fri, 15 Nov 2002 12:44:21 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18CnK7-000Bwj-00 for v6ops@ops.ietf.org; Fri, 15 Nov 2002 12:44:19 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA02455; Fri, 15 Nov 2002 12:43:30 -0800 (PST) Message-Id: <5.1.0.14.0.20021115152818.03f1e358@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Nov 2002 15:39:44 -0500 To: "Bound, Jim" , From: Margaret Wasserman Subject: RE: API Discussion RE: v6ops Agenda for Atlanta In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03240C2D@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-6.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim, > > It is true that we did discuss the IPv4 mapped address issues in > > Sunnyvale. [...] > >Yes I was there. I remember. :-) I was just reviewing for folks who weren't... > > There was some agreement in the meeting that there are issues > > with using IPv4 mapped addresses on the wire [... > >I agree and was there. Good, so the v6ops WG needs to decide whether we should produce a document and/or make any recommendations in this area. Thoughts? > > The API portion was much more controversial, and there was a general > > consensus in the room not to impose any API changes [...] > >What you say is true and that was the feeling. My issue is that this >was discussed on ipng and the apifolks design team. So what we heard at >Sunnyvale Interim meeting is consensus already and Itojun and Craig know >that. So I don't see why we are revisting it again. Obviously, there is quite a bit more history here than I am aware of, as I am no on the API design team... Now, I am better understanding your point. >But it feels like >v6ops is being duped to bring it up yet again. The problem is that the >current API defaults are deployed in production and supported in >practice and spirit by all but two implementations is my knowledge. The >API is now not 2553 but an IEEE spec/std. >So I sense politics here but if you want to have this come up again that >is your choice as chair. But we are not going to break customers at >this point using IPv6 is my strong guess. One point that I should make very clear: The v6ops group is NOT chartered to make any changes to the IPv6 APIs and/or the IPv6 specifications. We are chartered to identify real operational and/or security issues and make recommendations to the IPv6 WG, as appropriate. In this case, we need to figure out if there an issue here that should be documented, and then decide if we want to recommend any changes. From the discussion in Sunnyvale, there seems to be significant resistance to any changes, which is fine. Do you think that there is a real technical issue here that operators and implementors need to be aware of? Or, is this a non-issue? > > There was enough interest and discussion in Sunnyvale, at > > least regarding the on-wire issues that it seemed worthwhile to discuss > > this again in Atlanta to [...[ > >If this is the discussion I fully agree. Well, we'll see. I know that Craig and Itojun are following this thread, and I'm sure that they will try to focus their attentions on the areas that might need some attention from v6ops. >Thanks for listening to my point and responding, Thanks for letting me know what you were thinking, so that I could respond. Margaret From owner-v6ops@ops.ietf.org Fri Nov 15 18:49:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23998 for ; Fri, 15 Nov 2002 18:49:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18CqEW-000Ism-00 for v6ops-data@psg.com; Fri, 15 Nov 2002 15:50:44 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.36 #2) id 18CqET-000IsP-00 for v6ops@ops.ietf.org; Fri, 15 Nov 2002 15:50:42 -0800 Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5190162572; Sat, 16 Nov 2002 00:50:36 +0100 (CET) Date: Fri, 15 Nov 2002 13:16:30 -0500 From: Harald Tveit Alvestrand To: Alain Durand Cc: v6ops@ops.ietf.org Subject: Re: draft-ymbk-6to4-arpa-delegation-00.txt Message-ID: <21615962.1037366190@localhost> In-Reply-To: <3DD021DC.70400@sun.com> References: <20021111190712.294FD7AF@starfruit.itojun.org> <3DD021DC.70400@sun.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-6.7 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.41 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 11. november 2002 13:32 -0800 Alain Durand wrote: > I would like not to change it too, but the alternative to create records > on the fly in the DNS servers is an invitation for DOS attack on DNSsec... why? the synthesized records are "like" glue records, aren't they? so they shouldn't be signed anyway....? Harald From owner-v6ops@ops.ietf.org Sun Nov 17 09:56:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19250 for ; Sun, 17 Nov 2002 09:56:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DQpz-000Nyp-00 for v6ops-data@psg.com; Sun, 17 Nov 2002 06:55:51 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #2) id 18DQpw-000NyX-00 for v6ops@ops.ietf.org; Sun, 17 Nov 2002 06:55:48 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 8530069A0; Sun, 17 Nov 2002 09:55:45 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 17 Nov 2002 09:55:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: API Discussion RE: v6ops Agenda for Atlanta Date: Sun, 17 Nov 2002 09:55:44 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240C30@tayexc13.americas.cpqcorp.net> Thread-Topic: API Discussion RE: v6ops Agenda for Atlanta Thread-Index: AcKM57Nwp7DcbsADS2WHje7MVwAOJwBX2hpQ From: "Bound, Jim" To: "Margaret Wasserman" , X-OriginalArrivalTime: 17 Nov 2002 14:55:45.0389 (UTC) FILETIME=[685409D0:01C28E49] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA19250 Hi Margaret, > Hi Jim, > > > > It is true that we did discuss the IPv4 mapped address issues in > > > Sunnyvale. [...] > > > >Yes I was there. > > I remember. :-) I was just reviewing for folks who weren't... Yes of course. Just being a pain here :---) > > > > There was some agreement in the meeting that there are > issues with > > > using IPv4 mapped addresses on the wire [... > > > >I agree and was there. > > Good, so the v6ops WG needs to decide whether we should > produce a document and/or make any recommendations in this > area. Thoughts? My gut feeling is this and for all NOT MY COMPANY I ALWAYS SPEAK AS JIM HERE and MY COMPANY HAS NO PROBLEM WITH THAT (in fact all over the world and in some very intense other places). I thought I heard consensus that v4mapped should not be on the wire at interim meeting and on the list. But here is my bias and not an IETF norm. Erik has created these in SIIT. If he is not comfortable with this as principle designer of the mechanism then I will support Erik. I am tired of watered down designs that are built on consensus. I started working with Bob Gilligan on the API as one example in 1994. Implemented it multiple times and someone is still talking about it. But if we are to change it or any long time spec that has been implemented. I think what we should do is build Extensions to those specs in separate RFCs esp when it has significant implementation. Me personally. I did not like vmapped in SIIT years ago (just like SLs) and felt it would cause applications confusion. But we worked around it and all the security issues Itojun has presented in our implementation, which I can't go into and sorry about that. So to reach "forward progress" unless Erik is convinced we document the known security problems with SIIT in RFC and move on. > > > > The API portion was much more controversial, and there > was a general > > > consensus in the room not to impose any API changes [...] > > > >What you say is true and that was the feeling. My issue is > that this > >was discussed on ipng and the apifolks design team. So what > we heard at > >Sunnyvale Interim meeting is consensus already and Itojun and Craig > >know that. So I don't see why we are revisting it again. > > Obviously, there is quite a bit more history here than I am > aware of, as I am no on the API design team... Now, I am > better understanding your point. Yep. The mail api list is dormant now but we went to IEEE and the current model of the default being IPv4 Mapped can be shared by an app is the standard and implemented widely. As a note there will be an IPv6 Forum paper on porting to IPv6 that we will put out in the new year (probably January) and that paper shows very clearly why we chose what we did as the default. But the paper is not ready for prime time just yet to release. > > >But it feels like > >v6ops is being duped to bring it up yet again. The problem > is that the > >current API defaults are deployed in production and supported in > >practice and spirit by all but two implementations is my > knowledge. The > >API is now not 2553 but an IEEE spec/std. So I sense > politics here but > >if you want to have this come up again that is your choice > as chair. > >But we are not going to break customers at this point using > IPv6 is my > >strong guess. > > One point that I should make very clear: > > The v6ops group is NOT chartered to make any changes to the > IPv6 APIs and/or the IPv6 specifications. We are chartered > to identify real operational and/or security issues and make > recommendations to the IPv6 WG, as appropriate. In this > case, we need to figure out if there an issue here that > should be documented, and then decide if we want to recommend > any changes. From the discussion in Sunnyvale, there seems > to be significant resistance to any changes, which is fine. > > Do you think that there is a real technical issue here that > operators and implementors need to be aware of? Or, is this > a non-issue? I think v4mapped on the wire is something we do need to be sure is figured out and we need to make a statement. For the API default this has nothing to do with operators and why I don't like to see it presented here by Itojun and Craig and why I feel v6ops is being used as a poltical backdoor to bring this up again. I have been accused of beating a dead horse on SLs. OK this API is older and tons more of a dead issue. I don't think v6ops has the charter to be experts around APIs and in fact no where in the IETF. It just so happens we have lots of implementors who do build APIs but that is serendipity not a charter. FYI the only issue we have left is the scope_id for the base api and we have now stated see future work. 2553-bis-07 should go to Information RFC and any new parts folks want for the API can be NEW documents. But my bias is we need to do APIs in the IEEE where they are truly chartered and have integral processes to build APIs. thanks /jim [Honor, Commitment, Integrity] From owner-v6ops@ops.ietf.org Sun Nov 17 12:41:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22126 for ; Sun, 17 Nov 2002 12:41:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DTQa-0000z3-00 for v6ops-data@psg.com; Sun, 17 Nov 2002 09:41:48 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18DTQZ-0000yr-00 for v6ops@ops.ietf.org; Sun, 17 Nov 2002 09:41:47 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10481; Sun, 17 Nov 2002 10:41:45 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAHHfgL18046; Sun, 17 Nov 2002 18:41:42 +0100 (MET) Date: Sun, 17 Nov 2002 18:38:34 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-01.txt To: Pekka Savola Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > 1) does 'tunnel MTU MUST be not exceed 4400 bytes' only apply to the > dynamic MTU determination part or also to "manual configuration" part? > (probably the latter, but it's a bit unclear.) For manual I assume the encapsulator and decapsualtor should be able to pick whatever values they want, since this is manual. For instance, if they have IP over AAL5/ATM in the path they might want to configure a 9k number. I take it I need to make this more clear in the draft on this point. > 2) Why just 4400, not e.g. 4500? (Note: ATM/POS links usually have a > default MTU of 4470 bytes, so either 4470+20 or 4470-20 (depending on > which kind of encapsulation you believe is more useful) would be one > interesting compromise, I believe.) As I pointed out in emails (but not in the draft) we can debate the actual numbers - possibly forever. 4400 was something I pulled from a hat. I don't know what *process* to use to determine the numbers. (There is also the 1280 default number when the tunnel MTU is not dynamic which perhaps we need to debate.) In terms of the 4400 number, it effects a bit the IPv4 reassembly buffer in decapsulators. This is because the encapsulator might be using the dynamic scheme. Thus if a decapsulator have an interface which can receive packets of size X, it needs a reassembly buffer size for MIN(X, 4400). Does this mean we can make the 4400 number larger (e.g. 8k, 9k?) The 1280 number (the MTU used when there is the tunnel MTU is not dynamic) directly effects the IPv4 reassembly buffer in decapsulators so we presumably don't want this number to be much larger (but one could argue that 2k would not be a big deal I think). Erik From owner-v6ops@ops.ietf.org Sun Nov 17 12:57:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22381 for ; Sun, 17 Nov 2002 12:57:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DThX-0001Ov-00 for v6ops-data@psg.com; Sun, 17 Nov 2002 09:59:19 -0800 Received: from dhcp-204-42-71-254.ietf55.ops.ietf.org ([204.42.71.254] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #2) id 18DThV-0001Oh-00 for v6ops@ops.ietf.org; Sun, 17 Nov 2002 09:59:18 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E5FDE7AF; Mon, 18 Nov 2002 02:59:03 +0900 (JST) To: v6ops@ops.ietf.org Subject: draft-thakur-v6ops-3gpp-cases-00.txt comments X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Mon, 18 Nov 2002 02:59:03 +0900 Message-Id: <20021117175904.E5FDE7AF@starfruit.itojun.org> X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk i'm not sure if the way transition mechanisms are presented in 2.3 is the best way to capture multiple translation techniques. it goes into too much detail in some place (like DNS-ALG behavior), it does not go into details in some places. 2.3 (2) > it itself creates . This "A" response consists of an IP address of > the router itself and a port number that this router will use to > identify 'B'(similar to NATting). These two responses are eventually first, we cannot return port number in A DNS RR. (*) second, this subsection seems to me a proposal for new transition mechanism. if you are just making a recap of some other mechanism, which mechanism is it? (**) 2.3 (3) ditto for (**). 2.3 (4) it basically documents behavior of NAT-PT (or some other translation methodology) in the presense of mobile-ip6, right? if so, just say so. 2.3 (5) ditto for (*) and (**). itojun From owner-v6ops@ops.ietf.org Sun Nov 17 13:04:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22526 for ; Sun, 17 Nov 2002 13:04:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DToS-0001aO-00 for v6ops-data@psg.com; Sun, 17 Nov 2002 10:06:28 -0800 Received: from dhcp-204-42-71-254.ietf55.ops.ietf.org ([204.42.71.254] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #2) id 18DToP-0001aC-00 for v6ops@ops.ietf.org; Sun, 17 Nov 2002 10:06:25 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 224F37AF; Mon, 18 Nov 2002 03:06:12 +0900 (JST) To: v6ops@ops.ietf.org In-reply-to: itojun's message of Mon, 18 Nov 2002 02:59:03 +0900. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-thakur-v6ops-3gpp-cases-00.txt comments From: Jun-ichiro itojun Hagino Date: Mon, 18 Nov 2002 03:06:12 +0900 Message-Id: <20021117180612.224F37AF@starfruit.itojun.org> X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > i'm not sure if the way transition mechanisms are presented in 2.3 > is the best way to capture multiple translation techniques. > it goes into too much detail in some place (like DNS-ALG behavior), > it does not go into details in some places. and i'm a bit confused about how this document relates to draft-ietf-v6ops-3gpp-cases-00.txt... itojun From owner-v6ops@ops.ietf.org Sun Nov 17 15:47:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25069 for ; Sun, 17 Nov 2002 15:47:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DWKy-0004j3-00 for v6ops-data@psg.com; Sun, 17 Nov 2002 12:48:12 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18DWKw-0004io-00; Sun, 17 Nov 2002 12:48:11 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAHKm8T11045; Sun, 17 Nov 2002 22:48:08 +0200 Date: Sun, 17 Nov 2002 22:48:08 +0200 (EET) From: Pekka Savola To: Randy Bush cc: v6ops@ops.ietf.org Subject: Re: draft-ymbk-sparse-v6-allocation-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, A few comments. Special allocations from 2000::/3, e.g., space for experimental use, documentation, critical infrastructure, etc., will use the IETF consensus process [RFC2434]. Such special allocations will be requested of the Common Registration Service by IANA Considerations sections in IETF consensus documents. ==> how can IETF consensus process change anything (e.g. allocate 3FFF::/16 for 6bone_v2) once it has been fully allocated to RIRs. Then, it's already out of the IETF control. I suggest delegating a smaller block for now. Additionally, this memo requests that the IAB request that the IANA delegate the corresponding DNS zones, 2.IP6.ARPA and 3.IP6.ARPA, to the RIRs in accordance with a DNS server plan to be decided by the RIR community. ==> I guess this could be used to provide ip6.arpa reverses for 3FFE.. [I-D.ietf-ipngwg-addr-arch-v3] Gupta, M. and S. Deering, "IP Version 6 Addressing Architecture", draft-ietf-ipngwg-addr-arch-v3-11 (work in ==> I don't think M. Gupta had anything to do with this.. :-) On Tue, 12 Nov 2002, Randy Bush wrote: > i doubt this is worth discussion in the wg meeting in atlanta, as it > is more process than engineering. but folk may be interested anyway, > and may want to ding me on it in the corridors. > > http://psg.com/~randy/draft-ymbk-sparse-v6-allocation-00.txt > http://psg.com/~randy/draft-ymbk-sparse-v6-allocation-00.html > > Abstract > > This document proposes that the IAB request the IANA to allocate the > address space for the IPv6 2000::/3 prefix to the Common Registration > Service for further allocation under the registry plan for IPv6 > Address Space Management. > > randy > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sun Nov 17 16:45:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26102 for ; Sun, 17 Nov 2002 16:45:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DXFl-0005vO-00 for v6ops-data@psg.com; Sun, 17 Nov 2002 13:46:53 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18DXFj-0005ux-00 for v6ops@ops.ietf.org; Sun, 17 Nov 2002 13:46:51 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAHLkmd11510 for ; Sun, 17 Nov 2002 23:46:48 +0200 Date: Sun, 17 Nov 2002 23:46:48 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: comment on v4mapped-api-harmful Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, Even though I'm sympathic to the cause, I, too, have started to believe it's too late now -- changing this would only add confusion. We don't want even another different behaviour when binding addresses. However, I believe the long-term goal should be separate INET6 and INET. The question is how to get there, and how quickly. In particular, o Do not intentionally use RFC2553 section 3.7 (IPv4 traffic on AF_INET6 socket). Implement server applications by using separate AF_INET and AF_INET6 listening sockets. Explicitly set the IPV6_V6ONLY socket option to on, whenever the socket option is available on the system. ==> please provide some overview on the migration path (kernel/library, apps) from the current state to this. Reversing the default value would appear to be totally unacceptable, because it'd break _all_ current apps. Perhaps detecting the behaviour might be doable by some test macro.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sun Nov 17 17:06:43 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26455 for ; Sun, 17 Nov 2002 17:06:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DXZP-0006Ol-00 for v6ops-data@psg.com; Sun, 17 Nov 2002 14:07:11 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18DXZM-0006OY-00 for v6ops@ops.ietf.org; Sun, 17 Nov 2002 14:07:08 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAHM76211817 for ; Mon, 18 Nov 2002 00:07:06 +0200 Date: Mon, 18 Nov 2002 00:07:06 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: unmanaged scope comments (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I was a bit frustrated to note that my earlier comments on unmaneval-00 weren't replied to, or taken into account in -01. One of the biggest issues is that there seems to an assumption that unmanaged networks always employ (from ISP and/or internally) NAT. That restricts the applicability unnecessarily. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords ---------- Forwarded message ---------- Date: Thu, 19 Sep 2002 18:34:23 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: unmanaged scope comments Larger issues: 1) Especially for case A and C. I think there needs to be a clearer characterization of (IPv4) connectivity and addresses, like (this has all cases I think -- it could be simplified): 1. global addresses a) dynamic - enough addresses for every node - only one b) static - ^ - ^ 2. private addresses: NAT by ISP (or outside of your control) [otherwise one of cases above] - dynamic - static 2) 4 Application requirements of an IPv6 unmanaged network The application requirements are expressed in mostly three dimensions: connectivity, naming, and security. Connectivity issues include the provision of IPv6 addresses and their quality: do host need a global scope address, should this address be stable, or more precisely what should be the expected lifetime of the address. ==> connectivity includes one very important component IMO: the quality of network connections. This is often ignored. It's a high risk for a vendor to enable IPv6 by default, for example, if that'd result in lower quality connections to e.g. dual-stack web servers (a very real fact in 6bone), this should be taken into consideration at least in the short term. 3) 4.2 Requirements of client applications [...] maintaining the privacy of the client. Many potential users of IPv6 observe that the current NAT configuration provides some level of privacy: all communications to outside servers appear to come from the single IPv4 address of the NAT; the source IPv4 address does not identify a specific host inside the unmanaged network .. ==> .. or even a specific host in the ISP. IMO it's usually a non-issue, particularly in unmanaged case, whether someone can identify which node in a sparsely populated subnet is which. 4) Triggered by sect 4.3 and 4.4, but it's more generic than that; I think the draft needs to consider differences wrt. static/dynamic addresses/prefixes. In particular, privacy, server address and generally DNS issues come to mind. 5) The case where the ISP is IPv6 capable, but the gateway is not is similar to case A. 5.1 Case A, host deployment of IPv6 applications In this case the gateway doesn't provide IPv6; the ISP may or may not provide IPv6, but this is not relevant, since the non-upgraded gateway would prevent the hosts from using the ISP service. Some hosts will try to get IPv6 connectivity, in order to run applications that require IPv6, or work better with IPv6. ==> This is not true I think: for example, even if gateway runs v4 private addresses, ISP could provide e.g. internal tunnel service or something like ISATAP to their v6-enabled network. ==> Do you refer to *layer 3* gateway? (Otherwise, this gets simpler with e.g. bridged ATM encapsulation in xDSL). 6) 5.1.1 Application support in Case A Server applications are also not a primary focus of Case A. Server applications require DNS support, which is difficult to engineer for clients located behind a NAT. Besides, server applications, at this stage, cater mostly to IPv4 clients; putting up an IPv6 only server is not very attractive. ==> I'm not quite sure how DNS support is difficult to engineer; this probably has an unstated assumption that the address behind NAT would change too often to be really updateable or writable in DNS. This does not need to be the case. ==> In case A, clients don't necessarily need to be behind a NAT. 7) backward/upward compatibility; I brought this up in the interim meeting. IMO I don't see it as a hard requirement to be able to be able to perform v4only <-> v6only conversions. This depends quite a bit on what our "dual stack" deployment strategy is: whether we encourage vendors (e.g. LCNA type applications) to ship v6-only stacks or dual-stacks. 8) A comment: -- I think that there is a case to be made that using translation tools boosts the previously mentioned network effect and makes it work in our favor; the somewhat crippled nature of the translation tools is in fact also a good thing, because it gives people an incentive to throw them away once they realize that they are broken. I realize that this is heresy, so be it. -- ==> No I don't agree with the last statement: this gives folks only an incentive to enhance and tweak these features, not fix them *properly*. Think NAT ALGs... Semi-editorial: nat/firewall with that name. Since updating DNS is a management task, it somewhat falls outside the scope of an unmanaged network. ==> management, yes, but it's often automatic. A peer to peer session typically starts by an exchange of synchronization messages through the rendezvous servers, during which the peers exchange the addresses that will be used for the session. ==> not knowing better these protocols, I'm only guessing, but some of these messages could be done e.g. to initiate NAT, and thus be at least partially unnecessary with IPv6. There are multiple aspects to the security of peer-to-peer applications, many of which relate to the security of the rendezvous system. ==> I'm not sure which threats you refer to; the one I can think of is some kind of information disclosure. But I'm more afraid of the (programming) security of p2p apps myself. 4.4 Requirements of server applications The DNS entries for the server will have to be updated, preferably in real time, if the server's address changes. In practice, updating the DNS is slow, which implies that server applications will have a ==> The slowness of DNS is debatable, I think. TTL can be tuned if necessary. The security of server applications depends mostly on the correctness of the server, and also on the absence of collateral effects: many incidents occur when the opening of a server on the Internet inadvertently enables remote access to some other services on the same host. ==> s/host/node/ ==> not necessarily only the same node, even on the same local network ==> does 'correctness of the server' refer to the server application? 5.1.3 Naming services in Case A At this phase of IPv6 deployment, hosts in the unmanaged domain have access to DNS services over IPv4, through the existing gateway. DNS resolvers are supposed to serve AAAA records, even if they only implement IPv4; the local hosts should thus be able to obtain the IPv6 addresses of IPv6 only servers. ==> s/are supposed to// ==> s/should thus be/are/ (are these really worth the conditionals..) presence of translation or port mapping services; there is also not much of a case for letting local IPv4 servers publish their service on the IPv6 Internet. ==> I agree! These should be dual-stacked if they're important. To enable this scenario, the gateway need to use a mechanism obtain a global address prefix from the ISP, and advertise this address prefix to the hosts in the unmanaged network; several solutions will be assessed in a companion memo [EVAL]. ==> and in the degenate case...? 5.2.3 Naming services in Case B [...]. Currently, IPv4 only hosts discover the IPv4 address of the local DNS server using DHCP; there must be a way for IPv6 only hosts to discover the IPv6 address of the DNS server. ==> s/discover/usually discover/ Generic issue: I think that perhaps case B and case C could be reversed; I find it more probable that ISP is the last party of the three to offer v6 service. 5.3.2 Addresses and connectivity in Case C There are two ways to bring immediate IPv6 connectivity on top of an IPv4 only infrastructure: automatic tunnels provided by the [6TO4] technology, or configured tunnels. Both technologies have advantages and limitations, which will be studied in a companion document. ==> + mechanisms if gateway does not have global addresses. 5.4 Case D, ISP stops providing native IPv4 connectivity In this case the ISP is IPv6-only, so the gateway looses IPv4 connectivity, and is faced with an IPv6-only service provider. The gateway itself is dual stack, and the unmanaged network includes IPv4 only, IPv6 only and dual stack hosts. ==> no IPv4 connectivity to the customer, or no v4 at all (e.g. no possibility for ALG's, web caches, DNS / SMTP servers etc.). Probably the former. Editorial: s/IPv6 only/IPv6-only/ ? s/IPv4 only/IPv4-only/ ? 2 Topology (ISP)connection. Several hosts are connected to the subnet: ==> s/are/may be/ or may not perform NAT and firewall function. A key point of this ==> s/function/functions/ 3.2 Client applications network and a server at a remote location. A typical example is accessing a web server from a client inside the managed network, or reading and sending e-mail with the help of a server outside the managed network. ==> s/managed/unmanaged/g (whoops.. :-) 3.3 Peer-to-peer applications There are two kinds of peer-to-peer applications, the "local peer- to-peer" that only involve hosts on the unmanaged network, and the s/on the unmanaged network/in the unmanaged network/ (lots of other places; I'm not sure which one is correct, but 'in' sounds better to my ear at least) well identified peers outside the unmanaged network. These ==> s/well identified/well-identified/ ? applications are often facilitated by a server outside the managed networks. Examples of a peer-to-peer application would be a video- ==> s/managed/unmanaged/ (whoops :-) ==> s/networks/network/ 3.4 Server applications ==> I think the order should be changed: Server before Peer-to-peer, as peer to peer is IMO the most generic case. requires some special programming of the NAT or firewall. When the NAT only publishes a small number of global IP addresses and relies on "port ==> s/requires/require/ ==> s/publishes/maps to/ (or something else, publishes sounds funny)? nat/firewall with that name. Since updating DNS is a management task, it somewhat falls outside the scope of an unmanaged network. ==> s/nat/NAT/ 4.2 Requirements of client applications An important security issues with client applications is, ==> s/issues/issue/ ==> s/is,/is/ 4.3 Requirements of peer-to-peer applications Peer-to-peer applications require global connectivity. In an IPv6 network, we would expect the peers to use a global IPv6 address, which will have to remain stable for the duration of the peer-to- peer between client and server. ==> s/peer/peer session/ ==> "client and server" is a bit funny wording in P-2-P case.. :-) to deploy, and light weight; it will have to involve tunneling over ==> s/light weight/light-weight/ (not sure..?) 5.2.1 Application support in Case B We expect the unmanaged network to include three kinds of hosts: IPv4 only, IPv6 only, and dual stack. ==> soften the wording a bit: not every unmanaged network need to include all three. IPv4 only hosts use the services a brand new IPv6 only printer. ==> s/services/services, like/ To enable this scenario, the gateway need to use a mechanism obtain ==> s/need/needs/, s/obtain/to obtain/ not. The gateway has been upgraded and offers both IPv4 and IPv6 connectivity the hosts. It cannot rely on the ISP for IPv6 ==> s/connectivity/connectivity to/ connectivity, because the ISP does not offer ISP connectivity yet. ==> s/offer ISP/offer IPv6/ representation of the IPv4 address of the server, either by sing a ==> s/sing/using/ -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sun Nov 17 17:25:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26646 for ; Sun, 17 Nov 2002 17:24:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DXrR-0006kJ-00 for v6ops-data@psg.com; Sun, 17 Nov 2002 14:25:49 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18DXrQ-0006k7-00 for v6ops@ops.ietf.org; Sun, 17 Nov 2002 14:25:48 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 4736B4B22; Mon, 18 Nov 2002 07:25:46 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org In-reply-to: pekkas's message of Sun, 17 Nov 2002 23:46:48 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: comment on v4mapped-api-harmful From: itojun@iijlab.net Date: Mon, 18 Nov 2002 07:25:46 +0900 Message-Id: <20021117222546.4736B4B22@coconut.itojun.org> X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk to be clear, i have been pointing this problem out since 2553bis discussions group (apifolks). >o Do not intentionally use RFC2553 section 3.7 (IPv4 traffic on AF_INET6 > socket). Implement server applications by using separate AF_INET and > AF_INET6 listening sockets. Explicitly set the IPV6_V6ONLY socket > option to on, whenever the socket option is available on the system. >==> please provide some overview on the migration path (kernel/library, >apps) from the current state to this. >Reversing the default value would appear to be totally unacceptable, >because it'd break _all_ current apps. it'd breaks apps that assume IPv4 mapped address support, such as: - server program that listens to AF_INET6 socket only to receive both IPv4 and IPv6 inbound traffic. can be worked around by running two instance of the app, one for AF_INET and one for AF_INET6 - client program that uses getaddrinfo(3) with AI_MAPPED and AF_INET6 socket to connect to IPv4 and IPv6 destination should be rewritten to socket(2) after getaddrinfo(3) the change in default behavior shouldn't break applications if appliations are correctly written to handle IPv4 traffic on AF_INET socket, and IPv6 traffic on AF_INET6 socket. the following code fragment (server side) should avoid vulnerability on systems with/without IPv4 mapped address behavior, assuming: - bind(2) to the same port on AF_INET and AF_INET6 does not conflict (yes, some systems they do conflict and you can open only one of them) - 2553bis IPV6_V6ONLY is implemented - getaddrinfo(3) returns both AF_INET and AF_INET6 wildcard address on AI_PASSIVE i dunno, on how many systems, the above assumption holds. due to the lack of specification bind(2) behavior varies very much by implementation. >Perhaps detecting the behaviour might be doable by some test macro.. getsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &v, sizeof(v))? itojun int socks[NSOCK]; int nsocks; foo(port) char *port; { struct addrinfo hints, *res, *res0; int s; const int on = 1; memset(&hints, 0, sizeof(hints)); hints.ai_socktype = SOCK_STREAM; /* of DGRAM if you want to */ hints.ai_flags = AI_PASSIVE; getaddrinfo(NULL, port, &hints, &res0); nsocks = 0; for (res = res0; res; res = res->ai_next) { s = socket(res->ai_family, res->ai_socktype, res->ai_protocol); if (s < 0) continue; #ifdef IPV6_V6ONLY if (res->ai_family == AF_INET6 && setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &on, sizeof(on)) < 0) { close(s); continue; } #endif if (bind(s, res->ai_addr, res->ai_addrlen) < 0) { close(s); continue; } if (listen(s, 5) < 0) { close(s); continue; } socks[nsocks++] = s; } if (nsocks == 0) exit(1); /* handle socks[0] to socks[nsocks - 1] by select(2) or poll(2 )*/ } From owner-v6ops@ops.ietf.org Sun Nov 17 18:06:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27135 for ; Sun, 17 Nov 2002 18:06:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DYW2-0007Ws-00 for v6ops-data@psg.com; Sun, 17 Nov 2002 15:07:46 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18DYW0-0007Wd-00 for v6ops@ops.ietf.org; Sun, 17 Nov 2002 15:07:44 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAHN7gu12186 for ; Mon, 18 Nov 2002 01:07:42 +0200 Date: Mon, 18 Nov 2002 01:07:42 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: isp-cases-02 comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, First, it seems that some/many of my earlier comments: Date: Wed, 18 Sep 2002 18:25:58 +0300 (EEST) From: Pekka Savola To: Cleve Mickles Cc: v6ops@ops.ietf.org Subject: ISP scenarios comments haven't been integrated or commented on. Frustrating. As for the other issues that struct me while reading.. Substantial: 3.1.3.4.....Multicast Multicast is not widely deployed in CORE networks. To implement multicast, providers have deployed parallel infrastructure using Unix hosts running mboned or dvmrp on separate routers. ==> I don't know which providers (today) do that, but all I know either don't do multicast at all, or do it using PIM. 3.1.4. Traffic Engineering ==> advertisements between and inside ISP's today are also TE (some of them are multihoming, of course). There may be a problem with this if certain policies disallow more specifics. 3.1.5.2.....Ingress Filtering ==> note that ingress filtering can also be implemented as static access lists, not just as uRPF. Cable modems use a combination of policy settings and IGMPv2[RFC2236] to control multicast forwarding (see Section 3.3.1 [DOCSIS-1.1]). Forwarding of IPv6 multicast datagrams may not occur properly as CMs are required to forward multicast datagrams only when CPE equipment has joined that group. This is potentially a show-stopper if native IPv6 Neighbor Discovery[RFC2461] is being used through a CM. ==> this may or may not be related to the multicast problems presented at draft-savola-v6ops-multicast-issues-01. If not, I'd like to hear comments from people more familiar with the inner workings cable modems. 3.2.4. HFC IPv6 Deployment Options ==> some of these might be (to some degree of detail) better off in the yet-to-come solutions document. 3.2.8 Network Management DOCSIS cable modems use an out of band, privately addressed IPv4 network for configuration and network management functions. ==> I don't really know DOCSIS, but is it _really_ out-of-band? How is it separated from the rest of the traffic? 3.4.6. Network Management [dialup] ==> especially in dial-up, the ISP usually collects some info like userid, IP address, time connected, etc. for accounting purposes. These accounting tools may need to support v6 addresses too. 3.6.1.1 Physical architecture of public wireless LAN Public wireless LAN (WLAN) enables subscribers within home, office or the outdo Figure 3.6.1 describes the physical architecture of wireless LAN model. +-------+ | AAA | | Radius| | TACACS| '---' +-------+ ( ) | +-----+ (Wireless) +----+ /------------\ +-------+ |Hosts+--( LAN )---| AP |----| Underlying \--- | ISP |==> Core +-----+ ( ) +----+ \ technology | | Edge | ( ) \-----------/ | Router| '---' +-------+ ==> isn't this a simplification? Where's the access router here? Are these routed/bridged connections? (1 AP/subnet or possibly many APs/subnet) ==> in bridged case, may have v6-specific considerations. Like ethernet, IEEE 802.11 standard dose not define authentication and security mechanisms. Moreover, WLAN is basically a broadcast network and each host can l two authentication mechanisms: (1) IEEE 802.1x and (2) non-standard MAC address based authentication. ==> I believe there are many other ways to build WLAN's that using these two authentication techniques (e.g. some web hijacking + auth). 3.6.4.1 IEEE 802.1x based authentication IEEE 802.1x enables edge devices such as bridge or AP to perform authentication mechanism, and determines whether to allow or block data transmitted by hosts. It uses extended authentication protocol (EAP) as a standard protocol to transmit subscriber's authentication data. Authentication is based of userID and/or password, and packets transmitted by un-authenticated hosts are filtered and dropped by AP Figure 3.6.3 describes logical architecture of 802.1x based authentication ==> I can't see how eavesdropping couldn't be used to cause MITM or steal credentials, but I'm not sure if more detailed discussion of 802.1x belongs here. 3.6.4.4 Intrusion Detection, Ingress Filtering, and Prevention ==> one particular point about WLAN's is that as they're usually more widely available (think of "war-driving"), attempts for malicious activies are more probably higher too -- there may have to be more monitoring activities than other access methods usually. Editorial: ==> the lines are way too long, the limit is 72 chars. ==> different scenarios under section 3 should really be their own higher-level sections -- that would reduce the nesting a bit; listing all the levels of requirements (IGP, EGP, ...) may not be usable in ToC, it just makes it longer. 3.1.6.2.....Configuration Tools Many ISPs have monitoring tools that query the network gear to gather data. These scripts are written in perl or expect and will access the device via the CLI over the in-band ipv4 connection. ==> not so definite, please (at least s/are written/may be written/) A CMTS MAY also be an IPv6 router and thus support IPv6 natively. ==> should this special-uppercase keywording be a bit more restricted, to cases it's really useful for -- the document is not meant to be normative, I think -- s/MAY/may/ ? Some small ISPs do not even provide global addresses to their customers. These ISPs then operates NATs on their backbones. ==> s/operates/operate/ Once a subscriber is considered as valid, information exchanged between AP ==> s/as// ? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Nov 18 00:06:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02898 for ; Mon, 18 Nov 2002 00:06:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18De7X-000LdZ-00 for v6ops-data@psg.com; Sun, 17 Nov 2002 21:06:51 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18De7W-000LdM-00 for v6ops@ops.ietf.org; Sun, 17 Nov 2002 21:06:50 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Nov 2002 10:36:23 +0530 Message-ID: From: "Thakur, Anand" To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org Subject: RE: draft-thakur-v6ops-3gpp-cases-00.txt comments Date: Mon, 18 Nov 2002 10:37:48 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.4 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk hi, first of all thanks for your comments. actually what i have proposed is something very similar to NAT-PT but is not exactly "translation", but a new tunneling mechanism. the reason for using the tunneling mechanism is explained in 2.2. as you may have noticed, i have mentioned that header details (destination address and port number) will be collected using normal NAT-PT + DNS_ALG mechanism (as mentioned in rfc 2766) but this information will not be used to translate the IPV6/IPV4 header but to encapsulate it within another IPV6/IPV4 header. as far as 2.3 (4) is concerned. the main objective of this sub-section is to raise a few questions like how a mobile ipv6 node can avoid sending binding updates to a ipv4 (which may or may not be mobility enabled) node and a few other questions as well, which i hope to answer myself in my forthcoming (-01) draft. thanks anand > -----Original Message----- > From: Jun-ichiro itojun Hagino [SMTP:itojun@iijlab.net] > Sent: Sunday, November 17, 2002 11:29 PM > To: v6ops@ops.ietf.org > Subject: draft-thakur-v6ops-3gpp-cases-00.txt comments > > i'm not sure if the way transition mechanisms are presented in 2.3 > is the best way to capture multiple translation techniques. > it goes into too much detail in some place (like DNS-ALG behavior), > it does not go into details in some places. > > 2.3 (2) > > > it itself creates . This "A" response consists of an IP address of > > the router itself and a port number that this router will use to > > identify 'B'(similar to NATting). These two responses are eventually > > first, we cannot return port number in A DNS RR. (*) > second, this subsection seems to me a proposal for new transition > mechanism. if you are just making a recap of some other mechanism, > which mechanism is it? (**) > > 2.3 (3) > > ditto for (**). > > 2.3 (4) > > it basically documents behavior of NAT-PT (or some other translation > methodology) in the presense of mobile-ip6, right? if so, just > say so. > > 2.3 (5) > > ditto for (*) and (**). > > itojun From owner-v6ops@ops.ietf.org Mon Nov 18 07:06:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18606 for ; Mon, 18 Nov 2002 07:06:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DkgT-000Avn-00 for v6ops-data@psg.com; Mon, 18 Nov 2002 04:07:21 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #2) id 18DkgQ-000AvI-00 for v6ops@ops.ietf.org; Mon, 18 Nov 2002 04:07:18 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 10F40BCD; Mon, 18 Nov 2002 07:07:18 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Nov 2002 07:07:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: comment on v4mapped-api-harmful Date: Mon, 18 Nov 2002 07:07:17 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9B7B@tayexc13.americas.cpqcorp.net> Thread-Topic: comment on v4mapped-api-harmful Thread-Index: AcKOiKFZKLzSP5F4RoqogJ3OMyaFpwAccAAA From: "Bound, Jim" To: , "Pekka Savola" Cc: X-OriginalArrivalTime: 18 Nov 2002 12:07:17.0682 (UTC) FILETIME=[0A141920:01C28EFB] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA18606 To be clear this is not a problem. Most believe ISVs will want to deal only with AF_INET6 code and not run two instances of server apps on a node but one once moving to IPv6. For those that do then they must use the default of v6only. There will be a paper in the industry describing all of this very soon and sent out worldwide. I have to look at this workaround but that is not the point. It is the view of porting to IPv6 and that view and majority is to support one instance of a server on an application like ftp, telnet, oracle server, mail system, etc with one socket opne for both v4 and v6. Any port space issue also has work arounds and that will be addressed in the paper above too. Regards, /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Sunday, November 17, 2002 5:26 PM > To: Pekka Savola > Cc: v6ops@ops.ietf.org > Subject: Re: comment on v4mapped-api-harmful > > > to be clear, i have been pointing this problem out since 2553bis > discussions group (apifolks). > > >o Do not intentionally use RFC2553 section 3.7 (IPv4 traffic on > >AF_INET6 > > socket). Implement server applications by using separate > AF_INET and > > AF_INET6 listening sockets. Explicitly set the IPV6_V6ONLY socket > > option to on, whenever the socket option is available on > the system. > >==> please provide some overview on the migration path > (kernel/library, > >apps) from the current state to this. > >Reversing the default value would appear to be totally unacceptable, > >because it'd break _all_ current apps. > > it'd breaks apps that assume IPv4 mapped address > support, such as: > - server program that listens to AF_INET6 socket only > to receive both > IPv4 and IPv6 inbound traffic. > can be worked around by running two instance of the app, > one for AF_INET and one for AF_INET6 > - client program that uses getaddrinfo(3) with > AI_MAPPED and AF_INET6 > socket to connect to IPv4 and IPv6 destination > should be rewritten to socket(2) after getaddrinfo(3) > > the change in default behavior shouldn't break applications if > appliations are correctly written to handle IPv4 > traffic on AF_INET > socket, and IPv6 traffic on AF_INET6 socket. > > the following code fragment (server side) should avoid > vulnerability > on systems with/without IPv4 mapped address behavior, assuming: > - bind(2) to the same port on AF_INET and AF_INET6 does > not conflict > (yes, some systems they do conflict and you can open > only one of them) > - 2553bis IPV6_V6ONLY is implemented > - getaddrinfo(3) returns both AF_INET and AF_INET6 > wildcard address > on AI_PASSIVE > i dunno, on how many systems, the above assumption > holds. due to the > lack of specification bind(2) behavior varies very much by > implementation. > > >Perhaps detecting the behaviour might be doable by some test macro.. > > getsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &v, sizeof(v))? > > itojun > > > int socks[NSOCK]; > int nsocks; > > foo(port) > char *port; > { > struct addrinfo hints, *res, *res0; > int s; > const int on = 1; > > memset(&hints, 0, sizeof(hints)); > hints.ai_socktype = SOCK_STREAM; /* of DGRAM if > you want to */ > hints.ai_flags = AI_PASSIVE; > getaddrinfo(NULL, port, &hints, &res0); > nsocks = 0; > for (res = res0; res; res = res->ai_next) { > s = socket(res->ai_family, res->ai_socktype, > res->ai_protocol); > if (s < 0) > continue; > #ifdef IPV6_V6ONLY > if (res->ai_family == AF_INET6 && setsockopt(s, > IPPROTO_IPV6, > IPV6_V6ONLY, &on, sizeof(on)) < 0) { > close(s); > continue; > } > #endif > if (bind(s, res->ai_addr, res->ai_addrlen) < 0) { > close(s); > continue; > } > if (listen(s, 5) < 0) { > close(s); > continue; > } > socks[nsocks++] = s; > } > if (nsocks == 0) > exit(1); > > /* handle socks[0] to socks[nsocks - 1] by select(2) or > poll(2 )*/ } > > From owner-v6ops@ops.ietf.org Mon Nov 18 07:26:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18961 for ; Mon, 18 Nov 2002 07:26:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Dl0w-000Bc7-00 for v6ops-data@psg.com; Mon, 18 Nov 2002 04:28:30 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Dl0u-000Bbp-00 for v6ops@ops.ietf.org; Mon, 18 Nov 2002 04:28:28 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAICSMM17889; Mon, 18 Nov 2002 14:28:22 +0200 Date: Mon, 18 Nov 2002 14:28:22 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org Subject: Re: comment on v4mapped-api-harmful In-Reply-To: <20021117222546.4736B4B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 18 Nov 2002 itojun@iijlab.net wrote: > to be clear, i have been pointing this problem out since 2553bis > discussions group (apifolks). Yep.. > >o Do not intentionally use RFC2553 section 3.7 (IPv4 traffic on AF_INET6 > > socket). Implement server applications by using separate AF_INET and > > AF_INET6 listening sockets. Explicitly set the IPV6_V6ONLY socket > > option to on, whenever the socket option is available on the system. > >==> please provide some overview on the migration path (kernel/library, > >apps) from the current state to this. > >Reversing the default value would appear to be totally unacceptable, > >because it'd break _all_ current apps. > > it'd breaks apps that assume IPv4 mapped address support, such as: > - server program that listens to AF_INET6 socket only to receive both > IPv4 and IPv6 inbound traffic. > can be worked around by running two instance of the app, > one for AF_INET and one for AF_INET6 Sure, but the point was how to get there? Hypothetically assume that the model you proposed is adopted. Some vendors have it right now. Some have it in 1 year, some in 2. Some may never implement it. How should you code your app so that it detects whether AF_INET6 is enough or whether it needs also AF_INET? In particular, in some systems: 1) bind to AF_INET6 with IPV6_V6ONLY gives only AF_INET6 a) on some, setsockopt IPV6_V6ONLY will fail 2) bind to AF_INET6 without IPV6_ONLY gives a) only AF_INET6 b) both AF_INET and AF_INET6 3) bind to AF_INET6 with some new "IPV6_ALSOV4" gives both sockets Porting apps wrt. AF_INET6 quirks is complicated enough already (but somehow getting to the state you propose would simplify it in the long term). I guess you could use something like "#ifdef IPV6_ALSOV4" to check whether the system would support your model -- checking with IPV6_V6ONLY will not be enough -- but in reality, the check should be done at runtime. > the change in default behavior shouldn't break applications if > appliations are correctly written to handle IPv4 traffic on AF_INET > socket, and IPv6 traffic on AF_INET6 socket. The problem is that the definition of "correctly written" is currently satisfied by doing AF_INET6 + mapped addrs. > the following code fragment (server side) should avoid vulnerability > on systems with/without IPv4 mapped address behavior, assuming: > - bind(2) to the same port on AF_INET and AF_INET6 does not conflict > (yes, some systems they do conflict and you can open only one of them) > - 2553bis IPV6_V6ONLY is implemented > - getaddrinfo(3) returns both AF_INET and AF_INET6 wildcard address > on AI_PASSIVE > i dunno, on how many systems, the above assumption holds. due to the > lack of specification bind(2) behavior varies very much by > implementation. I think you're also assuming: - when the system headers/libs support IPV6_V6ONLY, the kernel also supports it - the same binary cannot be used on systems with different IPV6_V6ONLY etc. implementation (see above) > #ifdef IPV6_V6ONLY > if (res->ai_family == AF_INET6 && setsockopt(s, IPPROTO_IPV6, > IPV6_V6ONLY, &on, sizeof(on)) < 0) { > close(s); > continue; > } > #endif > if (bind(s, res->ai_addr, res->ai_addrlen) < 0) { > close(s); > continue; if your lib supports IPV6_V6ONLY (or, rather, the version where the program compiled with) but kernel doesn't, I believe this will end up listening to AF_INET only. Seems like a pretty nasty change of behaviour (== DoS) to me. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Nov 18 08:10:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20089 for ; Mon, 18 Nov 2002 08:10:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Dlgi-000Cz4-00 for v6ops-data@psg.com; Mon, 18 Nov 2002 05:11:40 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18Dlgg-000Cyl-00 for v6ops@ops.ietf.org; Mon, 18 Nov 2002 05:11:38 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E246D4B22; Mon, 18 Nov 2002 22:11:31 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org In-reply-to: pekkas's message of Mon, 18 Nov 2002 14:28:22 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: comment on v4mapped-api-harmful From: itojun@iijlab.net Date: Mon, 18 Nov 2002 22:11:31 +0900 Message-Id: <20021118131131.E246D4B22@coconut.itojun.org> X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >I think you're also assuming: > - when the system headers/libs support IPV6_V6ONLY, the kernel also >supports it i consider such system totally broken. header has to have items that is supported by kernel, period. >> #ifdef IPV6_V6ONLY >> if (res->ai_family == AF_INET6 && setsockopt(s, IPPROTO_IPV6, >> IPV6_V6ONLY, &on, sizeof(on)) < 0) { >> close(s); >> continue; >> } >> #endif >> if (bind(s, res->ai_addr, res->ai_addrlen) < 0) { >> close(s); >> continue; >if your lib supports IPV6_V6ONLY (or, rather, the version where the >program compiled with) but kernel doesn't, I believe this will end up >listening to AF_INET only. >Seems like a pretty nasty change of behaviour (== DoS) to me. we could ignore setsockopt() error and continue on, but if we do so, on certain stacks AF_INET/INET6 port number conflict happens on some of the platforms. itojun From owner-v6ops@ops.ietf.org Mon Nov 18 08:30:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20394 for ; Mon, 18 Nov 2002 08:30:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Dm0B-000Df1-00 for v6ops-data@psg.com; Mon, 18 Nov 2002 05:31:47 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Dm08-000Dep-00 for v6ops@ops.ietf.org; Mon, 18 Nov 2002 05:31:45 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAIDVdm18406; Mon, 18 Nov 2002 15:31:39 +0200 Date: Mon, 18 Nov 2002 15:31:39 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org Subject: Re: comment on v4mapped-api-harmful In-Reply-To: <20021118131131.E246D4B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 18 Nov 2002 itojun@iijlab.net wrote: > >I think you're also assuming: > > - when the system headers/libs support IPV6_V6ONLY, the kernel also > >supports it > > i consider such system totally broken. header has to have items > that is supported by kernel, period. This is is an easy consideration, but it just doesn't hold, e.g. in two cases: 1) incremental OS upgrades ("to upgrade X, you must also upgrade Y immediately and reboot or else hell breaks loose"), or 2) libc and kernel managed by different people (eg. linux, possibly others) YMMV. > >if your lib supports IPV6_V6ONLY (or, rather, the version where the > >program compiled with) but kernel doesn't, I believe this will end up > >listening to AF_INET only. > >Seems like a pretty nasty change of behaviour (== DoS) to me. > > we could ignore setsockopt() error and continue on, but if we do so, > on certain stacks AF_INET/INET6 port number conflict happens on > some of the platforms. Exactly.. which is why some form of more reliable indicator of the system support would be nice. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Nov 18 10:04:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22835 for ; Mon, 18 Nov 2002 10:04:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DnSf-000Gs6-00 for v6ops-data@psg.com; Mon, 18 Nov 2002 07:05:17 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18DnSd-000Gru-00 for v6ops@ops.ietf.org; Mon, 18 Nov 2002 07:05:15 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gAIF5Am03884; Mon, 18 Nov 2002 16:05:10 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gAIF59te027449; Mon, 18 Nov 2002 16:05:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211181505.gAIF59te027449@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: comment on v4mapped-api-harmful In-reply-to: Your message of Mon, 18 Nov 2002 07:25:46 +0900. <20021117222546.4736B4B22@coconut.itojun.org> Date: Mon, 18 Nov 2002 16:05:09 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: it'd breaks apps that assume IPv4 mapped address support, such as: => yes, it'd breaks apps that assume implementations are compliant! We already had this discussion, I support Jim: don't reopen it because your side didn't win. Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Mon Nov 18 10:20:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23265 for ; Mon, 18 Nov 2002 10:20:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DnjZ-000Hcy-00 for v6ops-data@psg.com; Mon, 18 Nov 2002 07:22:45 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18DnjV-000HcS-00 for v6ops@ops.ietf.org; Mon, 18 Nov 2002 07:22:42 -0800 Received: from jurassic.eng.sun.com ([129.146.17.55]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10232; Mon, 18 Nov 2002 08:22:38 -0700 (MST) Received: from eng.sun.com (vpn-129-147-152-154.Central.Sun.COM [129.147.152.154]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAIFMNbS288325; Mon, 18 Nov 2002 07:22:23 -0800 (PST) Message-ID: <3DD90584.5030802@eng.sun.com> Date: Mon, 18 Nov 2002 07:21:40 -0800 From: Jason Goldschmidt User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Fred L. Templin" CC: v6ops@ops.ietf.org, ngtrans@sunroof.eng.sun.com Subject: Re: Reachability confirmation issue for ISATAP routers (plus solution) References: <3DCC58FB.6060408@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.1 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_03_05,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Fred, Sorry for the slow reply and thank you for summarizing the problem for everyone. Fred L. Templin wrote: > > 2. When a node affiliates with multiple routers, upper-layer hints of > forward progress MUST NOT be used for reachability confirmation. > Instead, the node MUST actively probe neighboring routers using > unicast Neighbor Solicitation messages as in the second paragraph > of RFC2461 I don't understand how this is a solution. Requiring this probing will seriously limit the scalability of ISATAP. Given the architecture for ISATAP, NS/NA messages will need to be sent unicast between ISATAP hosts and routers. What this means is that each ISATAP host will be sending an NS message every 30 seconds or so (depending on the host configuration, but 30 seconds is the default timer for ND). The ISATAP router would need to reply to all of these messages, since there is no way for hosts to passively listen for ND messages sent to ipv6_all_nodes. This would create a packet storm of ND messages on a semi-large network deploying ISATAP. Requiring (or even making this mechanism a SHOULD) is a really bad idea. At best it should be a MAY with strong wording suggesting the scalability issues I mentioned above. > > Note that in case 2), ONLY those routers that are actively carrying > outgoing > traffic are probed. There is no need to probe routers that carry only > return > traffic, since the forward direction is all that is needed. I don't understand what you mean by "routers actively carrying outgoing traffic"? Is it possible that you are refering to only those routers that an ISATAP host has affiliated with and has defined a 'default route'? It seems you are talking about a scenario (packets going out router B from A->D and returning on C from D->A) were the usage of the PRL is compounded. I want to understand how router 'C' might not fall into your "ONLY" statement above. thanks, -Jason > > > Comments? > > Fred Templin > ftemplin@iprg.nokia.com > > > > From owner-v6ops@ops.ietf.org Mon Nov 18 15:47:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02954 for ; Mon, 18 Nov 2002 15:47:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Dsmx-0005bf-00 for v6ops-data@psg.com; Mon, 18 Nov 2002 12:46:35 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Dsmr-0005b7-00 for v6ops@ops.ietf.org; Mon, 18 Nov 2002 12:46:30 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA11088 for ; Mon, 18 Nov 2002 20:46:27 GMT Received: from login.ecs.soton.ac.uk (IDENT:XSCqI1JeAteMmFgMqepbXwfnBscoma2r@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAIKkLWX024386 for ; Mon, 18 Nov 2002 20:46:22 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gAIKkLG17366 for v6ops@ops.ietf.org; Mon, 18 Nov 2002 20:46:21 GMT Date: Mon, 18 Nov 2002 20:46:21 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: draft-pouffary-v6ops-ent-v6net-01 Message-ID: <20021118204621.GA17242@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <5.1.0.14.2.20021115053804.02abb310@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20021115053804.02abb310@mail.windriver.com> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT,WORK_AT_HOME version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk A few casual comments on v6ops-ent from the European 6NET perspective (international academic IPv6 testbed) tim An Enterprise network for this document is a user network connected to an Internet Service Provider (ISP) or a Private Network Service Provider (PSNP), is actively managed by the users of that network, - or rather the administrators of the network and has multiple independent networks within the Enterprise. It may also have mobile IP users accessing the Enterprise Network within the Enterprise network, from the public Internet into the Enterprise, or from a private external Internet network. An Enterprise could be a Fortune 100 company large business (e.g. Manufacturing, Financial, - which may be geographically dispersed? Government) or a small office business (e.g. Law Firm, Stock Brokerage, Discrete Engineering Parts Supplier, Office of 30 users). - or a university (typically 20,000 staff and students), perhaps spread out - across a town/city M7: Single Stack IPv6 ONLY Nodes (no known implementations today) - but nodes can be run ipv6-only, e.g. FreeBSD, Linux (the main missing piece - is often IPv6 transport for client host DNS lookups). This is being done - in some WLAN networks. Each EN will need to select the method to best suit their business requirements. Any attempt to define a default or one-size-fits-all set of variables and methods for all ENs would result in failure. These methods are discussed in Section 6 of the document. - are there other metrics for the transition tool requirements/evaluation - of applicability? For example the number of global v4 addresses available. These are the six scenarios that will be used in the document to drive the ENPTs, which will be determined by the transition variables, methods, and tools. This is an overview of each of the scenarios. Scenario #1 A large (20,000+ node) enterprise has an existing IPv4 network and wishes to turn on IPv6 for an engineering development group of ~100 clients that exist at two geographic sites. Each engineering group is on its own switched subnet. The IPv6 clients need to communicate with each other, but still need access to IPv4 based services provided by the corporation. What needs to be done to enable this deployment and where? - this is like a scenario we are considering in 6NET, where early testbeds - may exist in a campus, with perhaps also individuals scattered in the campus. - the wording "IPv6 turned on" implies dual-stack in the "islands"? Scenario #2 An enterprise decides to deploy wireless services across their network, and for reasons of geography and topology groups of access points end up on different subnets. To optimize their support for IP mobility, they choose to make this service IPv6-only, while to secure the air link they choose to have all connections use a VPN access technology. These mobile IPv6-only nodes will still need access to legacy IPv4-only applications. - this is a possible university scenario for new WLAN services. Although few - people are running v6-only routing now, it will happen, and at that time we - may still have dual-stack nodes with v4 apps (i.e. although it's putting the - cart before the horse, I think this scenario is our reason to keep working - on DSTM, where much good work has already been done). It is also worth - considering whether the IPv4-only devices are internal (e.g. printers, or - access points that can only be managed over IPv4) or external (e.g. remote - POP mail servers). Scenario #3 A modest sized (<10,0000 nodes) multi-site enterprise has deployed IPv4-NAT with overlapping private address ranges between the sites. They are looking to improve productivity through a peer-to-peer conferencing application, that will need to work between sites. They are willing to update the operating systems running that application to support both IPv4 & IPv6, and over time will do the same for other services on the network. Which transition technologies are applicable initially as they begin using the application? What changes or additional technologies are applicable when the ISP for some, but not all sites, offers native IPv6 service? What transition technologies are applicable when all ISPs offer IPv6 services, but some of the internal nodes remain IPv4-only? - wearing the 6NET hat again, it is unlikely that European universities run - NAT, except for smaller colleges who brought in external "consultants" to - advise and deploy IP services. Note we need to understand here the scenario - for a single site, in addition to merging sites, as there are competing - solutions. Having said that, GEANT (and 6NET) are spreading east to - countries where v4 global space is not so available. - i think that scenarios 4 and 5 are not primarily academic-oriented, so i - won't comment on them. Scenario #6 A new Enterprise network is being defined for a new Trucking Business that provides location based services for their Truck Fleet over a wide geography. The network will grow to > 10,000 nodes, and the Truck Fleets and Account Teams will use Mobile devices to access the Enterpise network's data and services. In addition many employees will be able to telecommute and work from home. There is no physical Enterprise network today, and the Enterprise network team for the business wants to build this new network with IPv6. - teleworking and mobility between campuses apply to university scenarios, be - it staff or students roaming on campus or requiring connectivity from home - networks, or perhaps while visiting other universities. A common access - method is desirable here for roaming (see www.terena.nl/tech/mobility/). 6.3 M3: IPv6 NAT to Communicate with IPv4 1. A DSN wants to communicate with a legacy ENAD IPv4 ONLY service or node. EN policy is that IPv6 NAT should be used for this communications. - It would be nice not to use the phrase "IPv6 NAT" :) Some general translation - mechanism is required, it may be at the network, transport or application - layer (i.e. NAT-PT, TRT or ALG when we discuss solutions). To me, IPv6 NAT - suggests something else entirely, that we want to avoid. 4. Others ???? - IPv4 nodes inside or outside the enterprise may wish to initiate connections - to IPv6 services inside the enterprise. ***IMPORTANT Discussion for Design Team and Working Group*** Should we recommend the following to the working group in the next draft and discuss at the IETF Atlanta meeting with the working group the following: 1. The EN Design Team highly recommends that ENs not adopt the policy in reference "1" above. - When we come to solutions, yes, probably, but the scenarios document isn't - the place to push policy recommendations, imo. 2. IPv6 ONLY nodes should not be deployed in an EN until they will not require access to any legacy IPv4. This means that applications and infrastructure has been ported or moved to IPv6. Until that time nodes for transition should be DSNs. This means ENs that want to use IPv6 ONLY nodes will be required to move applications and infrastructure to IPv6 first. - but this cannot always be done. I like to print stuff, but I prefer to use - IPv6 for the bulk of my day-to-day routine. Has anyone built a v6 network - printer yet (even dual stack)? We also need to get industry input from IPv6 early adopters and those planning to move to IPv6 or in IPv6 test mode to note in this draft. It is imperative we get all input on this issue because it can mean avoiding NAT for IPv6 and the loss of end-2-end communications and security for the deployment of Next Generation Networks. - I think everyone in 6NET deploying IPv6 now would want to avoid IPv6 NAT, - but 6-6 NAT is a different animal to 6-4 or 4-6 NAT-PT. ALGs can often - provide a solution (e.g. a Unix lp daemon could perhaps run 4 and 6, and - talk 4 to the printer) and should thus not be discounted. It depends on - how limited the application space is (some student halls of residence have - only http(s)/ssh/ftp/telnet outbound and nothing inbound, so could more - easily be serviced by ALG/TRT type solutions). 6.4 M4: IPv6 Native LANs This ENPT exists when the ENAD wants to support the deployment of Native IPv6 LANs. This condition will be driven by the EN transition variables V1-V14 stated in Section 4. - IPv6 deployment in sites in 6NET has, where done extensively, been done by - carrying IPv6 routing in parallel to the v4 routing, and then injecting the - /64's from the v6-only hierarchy (admittedly FreeBSD-based at this stage) - into the same VLANs as v4 subnets, overlaying v4 and v6 subnets, but of course - with many more hosts available in the v6 space. This can also carry IPv6 - only subnets in VLANs (e.g. for early trial deployments of IPv6 WLAN and of - MIPv6 in that environment). This is quite workable given the level of v6 - traffic until the enterprise vendors do smart L2/L3 v6 routing as they do - for ipv4 now. 6.5 M5: IPv6 Native Routing Domains This ENPT exists when the ENAD and/or the ENE wants to support the deployment of IPv6 Native Routing Domains. This condition will be driven by the EN variables V1-14 stated in Section 4. - as per 6.4, this can be done in parallel to v4 in an early (end host) dual - stack deployment. 6.6 M6: Dual Stack Nodes supporting IPv6 and IPv4 This ENPT is a method to deploy IPv6 and a method for transition. An EN that deploys DSNs as they adopt IPv6 are more assured that IPv6 and IPv4 interoperation will be possible between the two nodes or services. It also means for many legacy IPv4 nodes that they can be upgraded to support IPv4 and IPv6, but not turn on IPv6 until the IPv6 operational network has been verified to be interoperable and secure. It also means that both IPv4 and IPv6 can be supported by the nodes that transition to IPv6 and then will be able to communicate with IPv4 nodes using an IPv4 network infrastructure. - the big problem of course is then assumptions about which services are - available via which IP versions (just look at the SMTP MX considerations - draft for example). 6.7 M7: Single Stack IPv6 ONLY Nodes This ENPT will exist when ENs deploy IPv6 ONLY nodes. At this time there are no known implementations of these node types. This method for transition will require IPv6 NAT and the EN will lose IPv6 capability and end-2-end security for IPv6 ONLY to IPv4 ONLY communications. - Well, you can run Linux or FreeBSD IPv6-only, e.g. in an IPv6-only WLAN. - This has been done for a long time now in Tromso, Norway in a production - academic network, and exists in smaller testbeds in other 6NET sites. 7. Enterprise Network Infrastructure Points of Transition The Enterprise will be required to determine what network infrastructure will be affected by transtion to IPv6. This infrastructure must be analyzed and understood as a critical resource to manage within the ENAD. Each topic below in this section will be discussed and the issues facing transition for these network infrastructure parts will be discussed. - A key requirement lies on the server side, e.g. being confident of interactions - of NFS over IPv6 over a wide variety of client implementations. This sort of - support is still quite patchy (but some are robust). - I think a lot depends on whether you wish to keep existing v4 services v4 - only, and add new devices (like wlan) dual-stack, thus allowing access to - legacy apps via v4 on DSNs and allowing innovation v6-v6 between the WLAN - devices (the "clients" of the old world, now the new p2p endpoints). 7.1 DNS This will be discussed in the next draft. - e.g. whether to use the same or a separate name space for v and 6 in an - early deployment. 7.5 Applications and APIs This will be discussed in the next draft. - There is now a v6 ops draft on porting, which should probably be referenced here 7.7 Network Management This will be discussed in the next draft. - I think now that's run over IPv4, querying IPv6 MIBs at the moment (e.g. the - 6NET backbone is IPv6-only between the GSRs, but the access links between the - backbone routers and the national PoPs has IPv4 to access the SNMP. 7.8 Address Planning This will be discussed in the next draft. - Should probably be a separate draft? I'm not sure this is a design team - transition issue per se. It is worth noting though that a /48 isn't actually - a lot of space for a large university, if certain types of new networks will - exist (e.g. PANs). SOme further quick comments: I think here Itojun's draft on "missing IPv6 pieces" could be referenced for items relevant to the enterprise (e.g. today you might point DNS at IPv4 root DNS servers). The sections to be completed are quite broad in scope - are we taking on too much, or must we really consider all these aspects fully at this stage? There are also general requirements and properties of transition tools, e.g. - how do they scale? (e.g. single NAT-PT restrictions) - what are their security implications? (e.g. 6to4 relays) - what are performance issues (packet overhead, encapsulation cpu) - ipv4 and ipv6 address requirements (e.g. one static IPv4 for 6to4, ideally) - application requirements (e.g. configuration of ALGs) - ease of use/activation (for end users) - ease of management (for admins) - and probably many more... cheers, tim From owner-v6ops@ops.ietf.org Mon Nov 18 16:58:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05149 for ; Mon, 18 Nov 2002 16:58:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Dtvt-0009cE-00 for v6ops-data@psg.com; Mon, 18 Nov 2002 13:59:53 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #2) id 18Dtvq-0009Yw-00; Mon, 18 Nov 2002 13:59:50 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAILxC3H025246; Mon, 18 Nov 2002 22:59:12 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAILxBff067308; Mon, 18 Nov 2002 22:59:12 +0100 Received: from [9.29.3.174] by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61142 from ; Mon, 18 Nov 2002 22:59:09 +0100 Message-Id: <3DD96299.5E598BE9@hursley.ibm.com> Date: Mon, 18 Nov 2002 22:58:49 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: Randy Bush , v6ops@ops.ietf.org Subject: Re: draft-ymbk-sparse-v6-allocation-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Pekka Savola wrote: > > Hello, > > A few comments. > > Special allocations from 2000::/3, e.g., space for experimental use, > documentation, critical infrastructure, etc., will use the IETF > consensus process [RFC2434]. Such special allocations will be > requested of the Common Registration Service by IANA Considerations > sections in IETF consensus documents. > > ==> how can IETF consensus process change anything (e.g. allocate > 3FFF::/16 for 6bone_v2) once it has been fully allocated to RIRs. > > Then, it's already out of the IETF control. > > I suggest delegating a smaller block for now. Address allocation has been out of the IETF's direct control for many years; we delegated the entire IPv6 space to the IANA 7 years ago (RFC 1881, December 1995). And we have an excellent collaborative relationship with the RIRs. Brian > > Additionally, this memo requests that the IAB request that the IANA > delegate the corresponding DNS zones, 2.IP6.ARPA and 3.IP6.ARPA, to > the RIRs in accordance with a DNS server plan to be decided by the > RIR community. > > ==> I guess this could be used to provide ip6.arpa reverses for 3FFE.. > > [I-D.ietf-ipngwg-addr-arch-v3] > Gupta, M. and S. Deering, "IP Version 6 Addressing > Architecture", draft-ietf-ipngwg-addr-arch-v3-11 (work in > > ==> I don't think M. Gupta had anything to do with this.. :-) > > On Tue, 12 Nov 2002, Randy Bush wrote: > > > i doubt this is worth discussion in the wg meeting in atlanta, as it > > is more process than engineering. but folk may be interested anyway, > > and may want to ding me on it in the corridors. > > > > http://psg.com/~randy/draft-ymbk-sparse-v6-allocation-00.txt > > http://psg.com/~randy/draft-ymbk-sparse-v6-allocation-00.html > > > > Abstract > > > > This document proposes that the IAB request the IANA to allocate the > > address space for the IPv6 2000::/3 prefix to the Common Registration > > Service for further allocation under the registry plan for IPv6 > > Address Space Management. > > > > randy > > > > > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Nov 18 17:27:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05971 for ; Mon, 18 Nov 2002 17:27:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18DuOQ-000B9L-00 for v6ops-data@psg.com; Mon, 18 Nov 2002 14:29:22 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18DuOO-000B96-00; Mon, 18 Nov 2002 14:29:20 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAIMTGA23977; Tue, 19 Nov 2002 00:29:16 +0200 Date: Tue, 19 Nov 2002 00:29:16 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Randy Bush , Subject: Re: draft-ymbk-sparse-v6-allocation-00.txt In-Reply-To: <3DD96299.5E598BE9@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 18 Nov 2002, Brian E Carpenter wrote: > > A few comments. > > > > Special allocations from 2000::/3, e.g., space for experimental use, > > documentation, critical infrastructure, etc., will use the IETF > > consensus process [RFC2434]. Such special allocations will be > > requested of the Common Registration Service by IANA Considerations > > sections in IETF consensus documents. > > > > ==> how can IETF consensus process change anything (e.g. allocate > > 3FFF::/16 for 6bone_v2) once it has been fully allocated to RIRs. > > > > Then, it's already out of the IETF control. > > > > I suggest delegating a smaller block for now. > > Address allocation has been out of the IETF's direct control for many > years; we delegated the entire IPv6 space to the IANA 7 years ago > (RFC 1881, December 1995). And we have an excellent collaborative > relationship with the RIRs. I believe IANA has been tasked to do allocations under the direct guidance of IESG/IAB; in practise, allocate only when told to do so. There is no such formal control with RIR's. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Nov 19 10:24:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07365 for ; Tue, 19 Nov 2002 10:24:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EACh-000LcZ-00 for v6ops-data@psg.com; Tue, 19 Nov 2002 07:22:19 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #2) id 18EACe-000Lbm-00 for v6ops@ops.ietf.org; Tue, 19 Nov 2002 07:22:16 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAJFL8kL016010; Tue, 19 Nov 2002 16:21:11 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAJFL7nb052148; Tue, 19 Nov 2002 16:21:08 +0100 Received: from [9.29.3.173] by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA67678 from ; Tue, 19 Nov 2002 16:21:01 +0100 Message-Id: <3DDA552A.7DBD09E2@hursley.ibm.com> Date: Tue, 19 Nov 2002 16:13:46 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Tim Chown Cc: v6ops@ops.ietf.org Subject: Re: draft-pouffary-v6ops-ent-v6net-01 References: <5.1.0.14.2.20021115053804.02abb310@mail.windriver.com> <20021118204621.GA17242@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: > > A few casual comments on v6ops-ent from the European 6NET perspective > (international academic IPv6 testbed) Actually, not all of us in 6NET would agree that it's "academic". One of the objectives is to pilot e-business oriented apps, i.e. enterprise type apps. ... > 6.3 M3: IPv6 NAT to Communicate with IPv4 > > 1. A DSN wants to communicate with a legacy ENAD IPv4 ONLY service > or node. EN policy is that IPv6 NAT should be used for this > communications. > > - It would be nice not to use the phrase "IPv6 NAT" :) Some general translation > - mechanism is required, it may be at the network, transport or application > - layer (i.e. NAT-PT, TRT or ALG when we discuss solutions). To me, IPv6 NAT > - suggests something else entirely, that we want to avoid. Well, what is really wrong with the text is the choice of the word "policy". Such a decision isn't policy, it's a specific technology choice: use a network level solution rather than an application level solution. > > 4. Others ???? > > - IPv4 nodes inside or outside the enterprise may wish to initiate connections > - to IPv6 services inside the enterprise. > > ***IMPORTANT Discussion for Design Team and Working Group*** Should > we recommend the following to the working group in the next draft and > discuss at the IETF Atlanta meeting with the working group the > following: > > 1. The EN Design Team highly recommends that ENs not adopt the policy > in reference "1" above. > > - When we come to solutions, yes, probably, but the scenarios document isn't > - the place to push policy recommendations, imo. Indeed, especially if you don't recommend an alternative solution. What we should do here is simply describe solutions with their advantages and disadvantages. While I'm talking, one thing I miss in the document is an analysis of current scenarios (IPv4 scenarios) where enterprises have significant problems and difficulties that more address space will solve. That might suggest additional deployment scenarios. ... > > 6.6 M6: Dual Stack Nodes supporting IPv6 and IPv4 > > This ENPT is a method to deploy IPv6 and a method for transition. An > EN that deploys DSNs as they adopt IPv6 are more assured that IPv6 > and IPv4 interoperation will be possible between the two nodes or > services. It also means for many legacy IPv4 nodes that they can be > upgraded to support IPv4 and IPv6, but not turn on IPv6 until the > IPv6 operational network has been verified to be interoperable and > secure. It also means that both IPv4 and IPv6 can be supported by > the nodes that transition to IPv6 and then will be able to > communicate with IPv4 nodes using an IPv4 network infrastructure. > > - the big problem of course is then assumptions about which services are > - available via which IP versions (just look at the SMTP MX considerations > - draft for example). Well, in general there is the question of what to do when only some applications have been ported. Is it better to wait, to use application proxies, to use BIA, or what? We need the advantages & disadvantages for each of these approaches - these are just as important as network level approaches. ... > 7.5 Applications and APIs > > This will be discussed in the next draft. Good, but this should not be separated from the network level mechanisms; the application level techniques need to be considered in parallel with mechanisms M1 through M7. Brian From owner-v6ops@ops.ietf.org Tue Nov 19 11:53:32 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09727 for ; Tue, 19 Nov 2002 11:53:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EBeb-000Aki-00 for v6ops-data@psg.com; Tue, 19 Nov 2002 08:55:13 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EBeY-000AkT-00 for v6ops@ops.ietf.org; Tue, 19 Nov 2002 08:55:11 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA23468 for ; Tue, 19 Nov 2002 16:55:09 GMT Received: from login.ecs.soton.ac.uk (IDENT:j4antNSxMHmHDF5oBvAPNAC/swRv2h3s@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAJGt3WX014910 for ; Tue, 19 Nov 2002 16:55:03 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gAJGt3d10462 for v6ops@ops.ietf.org; Tue, 19 Nov 2002 16:55:03 GMT Date: Tue, 19 Nov 2002 16:55:03 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: draft-pouffary-v6ops-ent-v6net-01 Message-ID: <20021119165503.GJ9846@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <5.1.0.14.2.20021115053804.02abb310@mail.windriver.com> <20021118204621.GA17242@login.ecs.soton.ac.uk> <3DDA552A.7DBD09E2@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DDA552A.7DBD09E2@hursley.ibm.com> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Nov 19, 2002 at 04:13:46PM +0100, Brian E Carpenter wrote: > > Actually, not all of us in 6NET would agree that it's "academic". > One of the objectives is to pilot e-business oriented apps, > i.e. enterprise type apps. Hi Brian, I should have been clearer - what I meant was that we wouldn't be deploying like a multinational organisation, or similar not-uncommon commercial scenarios. Academic sites are becoming more e-business aware. The typical 6NET sites are universities in a single town/city scope. Some are more interesting, like Tromso in Norway due to WLAN use for WAN links. tim From owner-v6ops@ops.ietf.org Tue Nov 19 14:22:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13849 for ; Tue, 19 Nov 2002 14:22:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EDy3-000968-00 for v6ops-data@psg.com; Tue, 19 Nov 2002 11:23:27 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18EDy0-00095l-00 for v6ops@ops.ietf.org; Tue, 19 Nov 2002 11:23:24 -0800 Received: from jurassic.eng.sun.com ([129.146.17.55]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03994; Tue, 19 Nov 2002 12:23:23 -0700 (MST) Received: from eng.sun.com (vpn-129-152-200-229.East.Sun.COM [129.152.200.229]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAJJNJbS605842; Tue, 19 Nov 2002 11:23:21 -0800 (PST) Message-ID: <3DDA8F7B.5090409@eng.sun.com> Date: Tue, 19 Nov 2002 11:22:35 -0800 From: Jason Goldschmidt User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Chown CC: v6ops@ops.ietf.org Subject: Re: draft-pouffary-v6ops-ent-v6net-01 References: <5.1.0.14.2.20021115053804.02abb310@mail.windriver.com> <20021118204621.GA17242@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.7 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tim, Tim Chown wrote: > M7: Single Stack IPv6 ONLY Nodes (no known implementations today) > >- but nodes can be run ipv6-only, e.g. FreeBSD, Linux (the main missing piece >- is often IPv6 transport for client host DNS lookups). This is being done >- in some WLAN networks. > This is not what IPv6 ONLY refers to. A machine, such as a linux or BSD box, that has only an IPv6 interface configured is not IPV6 ONLY, it is still dual stack. Unless these implementations were modified to remove the IPv4 stack, they are not IPV6 ONLY devices. -Jason From owner-v6ops@ops.ietf.org Tue Nov 19 14:58:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14853 for ; Tue, 19 Nov 2002 14:58:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EEYN-000HGH-00 for v6ops-data@psg.com; Tue, 19 Nov 2002 12:00:59 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EEYK-000HFe-00 for v6ops@ops.ietf.org; Tue, 19 Nov 2002 12:00:56 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA25967 for ; Tue, 19 Nov 2002 20:00:54 GMT Received: from login.ecs.soton.ac.uk (IDENT:YzIdW1GJGvkqdRc6H3gol5IzBn65u4id@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAJK0jWX010615 for ; Tue, 19 Nov 2002 20:00:45 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gAJK0j313237 for v6ops@ops.ietf.org; Tue, 19 Nov 2002 20:00:45 GMT Date: Tue, 19 Nov 2002 20:00:45 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: draft-pouffary-v6ops-ent-v6net-01 Message-ID: <20021119200044.GC13005@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <5.1.0.14.2.20021115053804.02abb310@mail.windriver.com> <20021118204621.GA17242@login.ecs.soton.ac.uk> <3DDA8F7B.5090409@eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DDA8F7B.5090409@eng.sun.com> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Nov 19, 2002 at 11:22:35AM -0800, Jason Goldschmidt wrote: > > This is not what IPv6 ONLY refers to. A machine, such as a linux or BSD > box, that has only an IPv6 interface configured is not IPV6 ONLY, it is > still dual stack. Unless these implementations were modified to remove > the IPv4 stack, they are not IPV6 ONLY devices. But for the sake of the scenarios, what is the difference? I think that most IP stacks are not dual implementation, but hybrid, so they are not separate. If the design team wishes to keep that interpretation of IPv6-only, I think it should change the text or define it with the other definitions (DSN, etc), as "common" usage of the term is possibly different. Tim From owner-v6ops@ops.ietf.org Tue Nov 19 16:56:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18145 for ; Tue, 19 Nov 2002 16:56:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EGNC-000JBu-00 for v6ops-data@psg.com; Tue, 19 Nov 2002 13:57:34 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18EGN9-000JBc-00 for v6ops@ops.ietf.org; Tue, 19 Nov 2002 13:57:31 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 3B2697D04; Tue, 19 Nov 2002 22:57:49 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id DF2AD7C73; Tue, 19 Nov 2002 22:57:43 +0100 (CET) From: "Jeroen Massar" To: "'Tim Chown'" , Subject: RE: draft-pouffary-v6ops-ent-v6net-01 Date: Tue, 19 Nov 2002 22:58:01 +0100 Organization: Unfix Message-ID: <005e01c29016$bba8fe50$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: <20021119200044.GC13005@login.ecs.soton.ac.uk> X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA18145 Tim Chown wrote: > On Tue, Nov 19, 2002 at 11:22:35AM -0800, Jason Goldschmidt wrote: > > > > This is not what IPv6 ONLY refers to. A machine, such as a > linux or BSD > > box, that has only an IPv6 interface configured is not IPV6 > ONLY, it is > > still dual stack. Unless these implementations were > modified to remove > > the IPv4 stack, they are not IPV6 ONLY devices. > > But for the sake of the scenarios, what is the difference? I > think that > most IP stacks are not dual implementation, but hybrid, so they are > not separate. > > If the design team wishes to keep that interpretation of IPv6-only, I > think it should change the text or define it with the other > definitions > (DSN, etc), as "common" usage of the term is possibly different. IMHO a "IPv6 Only" device is a device which only can do network functions over IPv6. Thus a box which has a IPv4 and a IPv6 stack but doesn't use the IPv4 stack, or the IPv4 stack isn't usable due to no routing etc is a "IPv6 only" device. As Tim also mentions most stacks are Hybrid, and actually most OS's will depend internally, due to source code dependancies on the IPv4 stack. Even some message passing techniques use different parts of IP-alike stacks to pass system messages (ever blocked your loopback :) Greets, Jeroen From owner-v6ops@ops.ietf.org Tue Nov 19 18:10:48 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20257 for ; Tue, 19 Nov 2002 18:10:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EHXx-000C5d-00 for v6ops-data@psg.com; Tue, 19 Nov 2002 15:12:45 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.36 #2) id 18EHXt-000C2i-00 for v6ops@ops.ietf.org; Tue, 19 Nov 2002 15:12:41 -0800 Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B886862206; Wed, 20 Nov 2002 00:12:37 +0100 (CET) Date: Tue, 19 Nov 2002 18:10:47 -0500 From: Harald Tveit Alvestrand To: Jim Bound Cc: v6ops@ops.ietf.org Subject: On NGTRANS, transition mechanisms and consortia Message-ID: <100606594.1037729447@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim, this is in reply to your note of November 14, entitled "IPv6 Transition Mechanisms and Industry Transition Consortia". I'm attempting to share with you thoughts on three issues: - The transition between NGTRANS and v6ops - The status of transition mechanisms in the IPv6 space - The relationship between the IETF and industry consortia Since these are topics of significant interest to the v6ops community, this message is being CCed to the v6ops mailing list. Since our meeting in San Jose, I have attempted to get the story of the NGTRANS/v6Ops transition straight; while I have not completely succeded, I beleive I now understand the logic behind the decisions made. In the June timeframe, some features of the NGTRANS effort were becoming painfully clear: - We had multiple transition mechanisms on the standards track. Some of these were proving to have significant problems when tried in practice. - We had multiple additional transition mechanisms being worked on, some of which overlapped in functionality with existing mechanisms (possibly fixing problems), some of which added significant new functionality - yet there was little effort to position those new protocols as updates to or replacements for the existing mechanisms. - We detected a growing lack of consensus in the community about whether the burden of supporting specific mechanisms was worth the cost of adding more of those. In such a situation, it seemed appropriate to focus the efforts of the community, if possible, on increasing the understanding of what mechanisms were required in various scenarios. Several possible ideas were being floated, including: - Rechartering the NGTRANS working group - Establishing a new group with responsibility for "scenario modelling" only - Establishing a new group with both "scenario modelling" and parallel work on the transition mechanisms in progress After discussion between the ADs, the middle alternative was chosen; this seemed to give the cleanest positioning of the new WG. This was not done in a particularly clear or fashion, for which the relevant AD must bear responsibility. This had as a consequence the dropping until further notice of WG support for development of new transition mechanisms; the logic behind this was that until one knew the scenarios envisioned, it was hard to know what requirements existed for the new (and old!) transition mechanisms. The IETF never required the work on mechanisms to stop; since we're an organization of volunteers, we weren't even taking resources away from the documents - even the ngtrans mailing list remained open. But a logical inference was that the IESG would be unlikely to promote new documents to the standards track until the scenarios and resulting requirements were defined in v6ops. There are several ways around this if you want things published: - Publish through other mechanisms than the RFC process - Publish as Experimental RFC - Plead with the ADs to sponsor the mechanisms for standards track based on their obvious merits (identifying the mechanisms they obsolete) One last word on industry consortia, transition and the IETF: The IETF is quite aware that not all work fits within the organization. The exact borders are continuously the subject of intense debate - but it is clear that the elements that deal directly with business issues are outside the borders. We are normally happy to leave these issues to others. However, the IETF is also required to take the desire of business for an Internet that works well; this includes making mechanisms available in a timely fashion that support a reasonable subset of the business models on the market. In some cases, non-IETF consortia have worked very closely with the IETF, making the IETF standards process part of the work supported by the consortium. In other cases, consortia have taken up work that never belonged in the IETF (voice over MPLS and HTML are merely two examples). In the IPv6 transition case, I am sure we will find ways to work together, if all work towards a common understanding of the problems involved. With hope for a better understanding in the future, Harald From owner-v6ops@ops.ietf.org Tue Nov 19 18:24:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20544 for ; Tue, 19 Nov 2002 18:24:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EHm1-000FwR-00 for v6ops-data@psg.com; Tue, 19 Nov 2002 15:27:17 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #2) id 18EHlz-000FwC-00 for v6ops@ops.ietf.org; Tue, 19 Nov 2002 15:27:15 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 57CB62AF0; Tue, 19 Nov 2002 18:27:14 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Nov 2002 18:27:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: On NGTRANS, transition mechanisms and consortia Date: Tue, 19 Nov 2002 18:27:13 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240C3E@tayexc13.americas.cpqcorp.net> Thread-Topic: On NGTRANS, transition mechanisms and consortia Thread-Index: AcKQISyjrPLVciO8SE6hAk0ObGzVagAAIErg From: "Bound, Jim" To: "Harald Tveit Alvestrand" Cc: X-OriginalArrivalTime: 19 Nov 2002 23:27:14.0287 (UTC) FILETIME=[3129BFF0:01C29023] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA20544 Harald, Thank you for this clear response. This is what we needed to hear with this clarity and the communications. Trust that nothing I do in the industry will be counter to anything you state below and if a consortia for mechanisms is required for fast track because of market pressures as I am involved I assure you it will work very closely with the IETF for sure. I think we have alternatives and the scenarios are key. One thing I do ask just for thought. Please ask and request IESG members not act out on assumptions or read between the lines of work we do. If they have a concern be forthright and ask directly. I really hate to see us do a bunch of work in v6ops and be second guessed without clear, direct, and crystal communications as below. Often the chairs too can be at the receiving end of such mis-communications and not just us regular members of a working group. Thanks Again. Sincerely, /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no] > Sent: Tuesday, November 19, 2002 6:11 PM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: On NGTRANS, transition mechanisms and consortia > > > Jim, > > this is in reply to your note of November 14, entitled "IPv6 > Transition > Mechanisms and Industry Transition Consortia". > > I'm attempting to share with you thoughts on three issues: > > - The transition between NGTRANS and v6ops > - The status of transition mechanisms in the IPv6 space > - The relationship between the IETF and industry consortia > > Since these are topics of significant interest to the v6ops > community, this > message is being CCed to the v6ops mailing list. > > Since our meeting in San Jose, I have attempted to get the > story of the > NGTRANS/v6Ops transition straight; while I have not > completely succeded, I > beleive I now understand the logic behind the decisions made. > > In the June timeframe, some features of the NGTRANS effort > were becoming > painfully clear: > - We had multiple transition mechanisms on the standards > track. Some of > these were proving to have significant problems when tried in > practice. > - We had multiple additional transition mechanisms being > worked on, some of > which overlapped in functionality with existing mechanisms > (possibly fixing > problems), some of which added significant new functionality > - yet there > was little effort to position those new protocols as updates to or > replacements for the existing mechanisms. > - We detected a growing lack of consensus in the community > about whether > the burden of supporting specific mechanisms was worth the > cost of adding > more of those. > > In such a situation, it seemed appropriate to focus the > efforts of the > community, if possible, on increasing the understanding of > what mechanisms > were required in various scenarios. > Several possible ideas were being floated, including: > - Rechartering the NGTRANS working group > - Establishing a new group with responsibility for "scenario > modelling" only > - Establishing a new group with both "scenario modelling" and > parallel work > on the transition mechanisms in progress > > After discussion between the ADs, the middle alternative was > chosen; this > seemed to give the cleanest positioning of the new WG. > This was not done in a particularly clear or fashion, for which the > relevant AD must bear responsibility. > > This had as a consequence the dropping until further notice > of WG support > for development of new transition mechanisms; the logic > behind this was > that until one knew the scenarios envisioned, it was hard to > know what > requirements existed for the new (and old!) transition mechanisms. > > The IETF never required the work on mechanisms to stop; since > we're an > organization of volunteers, we weren't even taking resources > away from the > documents - even the ngtrans mailing list remained open. > But a logical inference was that the IESG would be unlikely > to promote new > documents to the standards track until the scenarios and resulting > requirements were defined in v6ops. > > There are several ways around this if you want things published: > - Publish through other mechanisms than the RFC process > - Publish as Experimental RFC > - Plead with the ADs to sponsor the mechanisms for standards > track based on > their obvious merits (identifying the mechanisms they obsolete) > > One last word on industry consortia, transition and the IETF: > The IETF is quite aware that not all work fits within the > organization. The exact borders are continuously the subject > of intense debate - but it > is clear that the elements that deal directly with business > issues are > outside the borders. We are normally happy to leave these > issues to others. > > However, the IETF is also required to take the desire of > business for an > Internet that works well; this includes making mechanisms > available in a > timely fashion that support a reasonable subset of the > business models on > the market. > > In some cases, non-IETF consortia have worked very closely > with the IETF, > making the IETF standards process part of the work supported by the > consortium. > > In other cases, consortia have taken up work that never > belonged in the > IETF (voice over MPLS and HTML are merely two examples). > > In the IPv6 transition case, I am sure we will find ways to > work together, > if all work towards a common understanding of the problems involved. > > With hope for a better understanding in the future, > > Harald > > > > From owner-v6ops@ops.ietf.org Tue Nov 19 21:22:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27310 for ; Tue, 19 Nov 2002 21:22:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EKWU-0009nq-00 for v6ops-data@psg.com; Tue, 19 Nov 2002 18:23:26 -0800 Received: from node147c0.a2000.nl ([24.132.71.192] helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #2) id 18EKWQ-0009ne-00 for v6ops@ops.ietf.org; Tue, 19 Nov 2002 18:23:23 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id gAK2Mh905377; Wed, 20 Nov 2002 03:22:43 +0100 (CET) Date: Wed, 20 Nov 2002 03:22:43 +0100 From: Ronald van der Pol To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: unmanaged scope comments (fwd) Message-ID: <20021120022242.GC4864@rvdp.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Nov 18, 2002 at 00:07:06 +0200, Pekka Savola wrote: > I was a bit frustrated to note that my earlier comments on unmaneval-00 > weren't replied to, or taken into account in -01. Sorry about that. Your email is in my inbox, and parts were discussed within the design team. But we should have sent a reply. > One of the biggest issues is that there seems to an assumption that > unmanaged networks always employ (from ISP and/or internally) NAT. That > restricts the applicability unnecessarily. You told me about bridged dsl in Finland which offers several global v4 addresses. I think the specific v4 situation does not matter that much. The main requirement is that v4 connectivity should not worsen when you transition to v6. > 1) Especially for case A and C. I think there needs to be a clearer > characterization of (IPv4) connectivity and addresses, like (this has all > cases I think -- it could be simplified): > > 1. global addresses > a) dynamic > - enough addresses for every node > - only one Yes, we realized we do not discuss dynamic v4 addresses. We probably should. > 2) > > 4 Application requirements of an IPv6 unmanaged network > > The application requirements are expressed in mostly three > dimensions: connectivity, naming, and security. Connectivity issues > include the provision of IPv6 addresses and their quality: do host > need a global scope address, should this address be stable, or more > precisely what should be the expected lifetime of the address. > > ==> connectivity includes one very important component IMO: the quality of > network connections. This is often ignored. It's a high risk for a vendor > to enable IPv6 by default, for example, if that'd result in lower quality > connections to e.g. dual-stack web servers (a very real fact in 6bone), this > should be taken into consideration at least in the short term. I think this is YACEP (Yet Another Chicken and Egg Problem). Routing is bad because people don't use v6 on a daily basis. And people don't use v6 (upgrade services to dual stack) because routing is bad. But this is not specific to unmanaged networks. It could go in a general BCP. > 5.1 Case A, host deployment of IPv6 applications > > In this case the gateway doesn't provide IPv6; the ISP may or may > not provide IPv6, but this is not relevant, since the non-upgraded > gateway would prevent the hosts from using the ISP service. Some > hosts will try to get IPv6 connectivity, in order to run > applications that require IPv6, or work better with IPv6. > > ==> This is not true I think: for example, even if gateway runs v4 private > addresses, ISP could provide e.g. internal tunnel service or something like > ISATAP to their v6-enabled network. I think this is meant: "the ISP may or may not provide *native* IPv6" > ==> Do you refer to *layer 3* gateway? (Otherwise, this gets simpler with > e.g. bridged ATM encapsulation in xDSL). Yes, should we discuss bridged networks? Are they widely deployed or are they corner cases? > 6) > > 5.1.1 Application support in Case A > Server applications are also not a primary focus of Case A. Server > applications require DNS support, which is difficult to engineer for > clients located behind a NAT. Besides, server applications, at this > stage, cater mostly to IPv4 clients; putting up an IPv6 only server > is not very attractive. > > ==> I'm not quite sure how DNS support is difficult to engineer; this > probably has an unstated assumption that the address behind NAT would change > too often to be really updateable or writable in DNS. This does not need to > be the case. Maybe its not so much DNS which is the problem, but the server port mapping. How would you do this unmanaged? > ==> In case A, clients don't necessarily need to be behind a NAT. The question is what percentage of SOHOs use NAT. If it is the vast majority, I don't think we should complicate the draft even further. > The security of server applications depends mostly on the > correctness of the server, and also on the absence of collateral > effects: many incidents occur when the opening of a server on the > Internet inadvertently enables remote access to some other services > on the same host. > > ==> s/host/node/ > ==> not necessarily only the same node, even on the same local network > ==> does 'correctness of the server' refer to the server application? I think it means how vulnerable the server OS is. > 5.1.3 Naming services in Case A > > At this phase of IPv6 deployment, hosts in the unmanaged domain have > access to DNS services over IPv4, through the existing gateway. DNS > resolvers are supposed to serve AAAA records, even if they only > implement IPv4; the local hosts should thus be able to obtain the > IPv6 addresses of IPv6 only servers. > > ==> s/are supposed to// > ==> s/should thus be/are/ (are these really worth the conditionals..) Very old resolvers don't support AAAA. > 5.4 Case D, ISP stops providing native IPv4 connectivity > > In this case the ISP is IPv6-only, so the gateway looses IPv4 > connectivity, and is faced with an IPv6-only service provider. The > gateway itself is dual stack, and the unmanaged network includes > IPv4 only, IPv6 only and dual stack hosts. > > ==> no IPv4 connectivity to the customer, or no v4 at all (e.g. no > possibility for ALG's, web caches, DNS / SMTP servers etc.). Probably the > former. I think so. > 3.2 Client applications > > network and a server at a remote location. A typical example is > accessing a web server from a client inside the managed network, or > reading and sending e-mail with the help of a server outside the > managed network. > > ==> s/managed/unmanaged/g (whoops.. :-) Fixed in -02. > applications are often facilitated by a server outside the managed > networks. Examples of a peer-to-peer application would be a video- > > ==> s/managed/unmanaged/ (whoops :-) Fixed in -02. > representation of the IPv4 address of the server, either by sing a > > ==> s/sing/using/ Fixed in -02. We will fix the others in -03. Thanks for reading the draft and commenting on it. rvdp From owner-v6ops@ops.ietf.org Tue Nov 19 21:40:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28829 for ; Tue, 19 Nov 2002 21:40:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EKoU-000El2-00 for v6ops-data@psg.com; Tue, 19 Nov 2002 18:42:02 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.36 #2) id 18EKoS-000Ekk-00 for v6ops@ops.ietf.org; Tue, 19 Nov 2002 18:42:00 -0800 Received: from localhost (retro.viagenie.qc.ca [3ffe:b00:c18:3::22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id gAK2fma75619; Tue, 19 Nov 2002 21:41:50 -0500 (EST) Date: Tue, 19 Nov 2002 21:41:41 -0500 From: Marc Blanchet To: Harald Tveit Alvestrand cc: v6ops@ops.ietf.org Subject: Re: On NGTRANS, transition mechanisms and consortia Message-ID: <75550000.1037760101@classic.viagenie.qc.ca> In-Reply-To: <100606594.1037729447@localhost> References: <100606594.1037729447@localhost> X-Mailer: Mulberry/3.0.0a5 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA28829 -- mardi, novembre 19, 2002 18:10:47 -0500 Harald Tveit Alvestrand wrote/a écrit: > Jim, > > this is in reply to your note of November 14, entitled "IPv6 Transition > Mechanisms and Industry Transition Consortia". part of mail cut > > The IETF never required the work on mechanisms to stop; since we're an > organization of volunteers, we weren't even taking resources away from > the documents - even the ngtrans mailing list remained open. But a > logical inference was that the IESG would be unlikely to promote new > documents to the standards track until the scenarios and resulting > requirements were defined in v6ops. > > There are several ways around this if you want things published: > - Publish through other mechanisms than the RFC process > - Publish as Experimental RFC I proposed this as a way to revolve/help resolve the transition mechanisms drop: - many mechanisms are documented, are implemented and used (to various levels) - I agree with the desire to make a short list. - but it seems to me to soon to conclude that all mechanisms that will not be in the short list are bad or broken or not useful. - all this is also based on the assumption that we will agree on the scenarios and requirements, which is not always the case happening in the ietf. on the other hand, there are many implementations, and those who are developing are using expired drafts. Many mechanisms might be of not short term use, or more specific use, or might be perceived as not the right mechanism from some people. I would propose that we have a track to publish many of those mechanisms as experimental RFC. After some period of time (might be years), we could revisit to put them back on the standard track. That way, we will have a stable document where implementors, users, the community could use, while keeping the goal of a short list for standard track. Marc. part of mail cut > > > With hope for a better understanding in the future, > > Harald > > > From owner-v6ops@ops.ietf.org Tue Nov 19 21:54:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29904 for ; Tue, 19 Nov 2002 21:54:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EL2a-000IcZ-00 for v6ops-data@psg.com; Tue, 19 Nov 2002 18:56:36 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EL2X-000IYy-00 for v6ops@ops.ietf.org; Tue, 19 Nov 2002 18:56:33 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAK2uMD05657; Wed, 20 Nov 2002 04:56:22 +0200 Date: Wed, 20 Nov 2002 04:56:22 +0200 (EET) From: Pekka Savola To: Ronald van der Pol cc: v6ops@ops.ietf.org Subject: Re: unmanaged scope comments (fwd) In-Reply-To: <20021120022242.GC4864@rvdp.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 20 Nov 2002, Ronald van der Pol wrote: > > One of the biggest issues is that there seems to an assumption that > > unmanaged networks always employ (from ISP and/or internally) NAT. That > > restricts the applicability unnecessarily. > > You told me about bridged dsl in Finland which offers several global > v4 addresses. I think the specific v4 situation does not matter that > much. The main requirement is that v4 connectivity should not worsen > when you transition to v6. Naturally, it should not get any worse. But depending on whether the boxes that can (or need) to support v6 can be upgraded or not sets some requirements to consider. For example, consider the following connectivity methods: a) ISP -- DSL modem w/ bridging --> and b) ISP -- DSL modem w/ routing --> and what's connected behind that: 1) hub/switch 2) some cheapo router 3) some PC (e.g. a windows box with connection sharing, BSD router, etc.) 4) directly connected PC Now, in case a) you never have to upgrade the DSL modem -- you will only need to care about what you connect to it. This is only problematic in case 2) above. Of course this will break if the ISP doesn't even offer public addresses in the DHCP. On the other hand, in case b), you will basically always have to care about upgrading the DSL box -- and even if you get a public IP address, it will get wasted in the DSL modem, as it (usually) offers only private connectivity to the LAN. > > 4 Application requirements of an IPv6 unmanaged network > > > > The application requirements are expressed in mostly three > > dimensions: connectivity, naming, and security. Connectivity issues > > include the provision of IPv6 addresses and their quality: do host > > need a global scope address, should this address be stable, or more > > precisely what should be the expected lifetime of the address. > > > > ==> connectivity includes one very important component IMO: the quality of > > network connections. This is often ignored. It's a high risk for a vendor > > to enable IPv6 by default, for example, if that'd result in lower quality > > connections to e.g. dual-stack web servers (a very real fact in 6bone), this > > should be taken into consideration at least in the short term. > > I think this is YACEP (Yet Another Chicken and Egg Problem). Routing is > bad because people don't use v6 on a daily basis. And people don't use > v6 (upgrade services to dual stack) because routing is bad. But this is > not specific to unmanaged networks. It could go in a general BCP. Agreed that it isn't special. People do use v6 on a daily basis, but the problem is that the mess is so big and remote, it just can't be fixed because those causing the problems apparently either aren't sufferiong from the probles or aren't using v6 on a daily basis. > > 5.1 Case A, host deployment of IPv6 applications > > > > In this case the gateway doesn't provide IPv6; the ISP may or may > > not provide IPv6, but this is not relevant, since the non-upgraded > > gateway would prevent the hosts from using the ISP service. Some > > hosts will try to get IPv6 connectivity, in order to run > > applications that require IPv6, or work better with IPv6. > > > > ==> This is not true I think: for example, even if gateway runs v4 private > > addresses, ISP could provide e.g. internal tunnel service or something like > > ISATAP to their v6-enabled network. > > I think this is meant: > "the ISP may or may not provide *native* IPv6" That could be changed, yes, but I don't think it fixes the real issue that if gateway hasn't been upgraded, you may still be able to use v6 just fine (just not native all the way to the ISP but who cares?). > > ==> Do you refer to *layer 3* gateway? (Otherwise, this gets simpler with > > e.g. bridged ATM encapsulation in xDSL). > > Yes, should we discuss bridged networks? Are they widely deployed or are > they corner cases? Perhaps this question should be raised at the v6ops meeting when discussing the scenarios document. > > 6) > > > > 5.1.1 Application support in Case A > > Server applications are also not a primary focus of Case A. Server > > applications require DNS support, which is difficult to engineer for > > clients located behind a NAT. Besides, server applications, at this > > stage, cater mostly to IPv4 clients; putting up an IPv6 only server > > is not very attractive. > > > > ==> I'm not quite sure how DNS support is difficult to engineer; this > > probably has an unstated assumption that the address behind NAT would change > > too often to be really updateable or writable in DNS. This does not need to > > be the case. > > Maybe its not so much DNS which is the problem, but the server port mapping. > How would you do this unmanaged? It's difficult to say, depends on what was meant with the term "DNS support" here. If there is just one service, the mapping need to be too difficult (just 1:1). > > ==> In case A, clients don't necessarily need to be behind a NAT. > > The question is what percentage of SOHOs use NAT. If it is the vast > majority, I don't think we should complicate the draft even further. At least around here, and I know many other places, where at least one IP address is provided to the end-user. > > The security of server applications depends mostly on the > > correctness of the server, and also on the absence of collateral > > effects: many incidents occur when the opening of a server on the > > Internet inadvertently enables remote access to some other services > > on the same host. > > > > ==> s/host/node/ > > ==> not necessarily only the same node, even on the same local network > > ==> does 'correctness of the server' refer to the server application? > > I think it means how vulnerable the server OS is. reword :-) > > 5.1.3 Naming services in Case A > > > > At this phase of IPv6 deployment, hosts in the unmanaged domain have > > access to DNS services over IPv4, through the existing gateway. DNS > > resolvers are supposed to serve AAAA records, even if they only > > implement IPv4; the local hosts should thus be able to obtain the > > IPv6 addresses of IPv6 only servers. > > > > ==> s/are supposed to// > > ==> s/should thus be/are/ (are these really worth the conditionals..) > > Very old resolvers don't support AAAA. Current draft has moved around a bit and this doesn't even seem to exist anymore, so this is probably moot. > > 5.4 Case D, ISP stops providing native IPv4 connectivity > > > > In this case the ISP is IPv6-only, so the gateway looses IPv4 > > connectivity, and is faced with an IPv6-only service provider. The > > gateway itself is dual stack, and the unmanaged network includes > > IPv4 only, IPv6 only and dual stack hosts. > > > > ==> no IPv4 connectivity to the customer, or no v4 at all (e.g. no > > possibility for ALG's, web caches, DNS / SMTP servers etc.). Probably the > > former. > > I think so. Right. These have entirely different design restrictions on what services must be provided. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Nov 19 23:20:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16753 for ; Tue, 19 Nov 2002 23:20:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EMNO-000Fvl-00 for v6ops-data@psg.com; Tue, 19 Nov 2002 20:22:10 -0800 Received: from web13002.mail.yahoo.com ([216.136.174.12]) by psg.com with smtp (Exim 3.36 #2) id 18EMNM-000FvO-00 for v6ops@ops.ietf.org; Tue, 19 Nov 2002 20:22:08 -0800 Message-ID: <20021120042207.27468.qmail@web13002.mail.yahoo.com> Received: from [63.78.179.5] by web13002.mail.yahoo.com via HTTP; Tue, 19 Nov 2002 20:22:07 PST Date: Tue, 19 Nov 2002 20:22:07 -0800 (PST) From: Fred Templin Subject: Re: Reachability confirmation issue for ISATAP routers (plus solution) To: Jason Goldschmidt Cc: v6ops@ops.ietf.org, ngtrans@sunroof.eng.sun.com In-Reply-To: <3DD90584.5030802@eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=1.1 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,MAILTO_TO_SPAM_ADDR, QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jason, Sorry for the delay; I needed to confer with one of the co-authors before responding: --- Jason Goldschmidt wrote: > Hi Fred, > > Sorry for the slow reply and thank you for summarizing the problem for > everyone. > > Fred L. Templin wrote: > > > > > 2. When a node affiliates with multiple routers, upper-layer hints of > > forward progress MUST NOT be used for reachability confirmation. > > Instead, the node MUST actively probe neighboring routers using > > unicast Neighbor Solicitation messages as in the second paragraph > > of RFC2461 > > I don't understand how this is a solution. Requiring this probing will > seriously limit the scalability of ISATAP. Given the architecture for > ISATAP, NS/NA messages will need to be sent unicast between ISATAP hosts > and routers. What this means is that each ISATAP host will be sending > an NS message every 30 seconds or so (depending on the host > configuration, but 30 seconds is the default timer for ND). The ISATAP > router would need to reply to all of these messages, since there is no > way for hosts to passively listen for ND messages sent to > ipv6_all_nodes. This would create a packet storm of ND messages on a > semi-large network deploying ISATAP. Requiring (or even making this > mechanism a SHOULD) is a really bad idea. At best it should be a MAY > with strong wording suggesting the scalability issues I mentioned above. After conferring with one of the co-authors, we agree with your above comments. Hints of forward progress may tell only unidirectional link information in some cases when there are multiple ISATAP routers. But, this is only an issue if important ICMPs (e.g., ICMPv4 fragment needed) are being black-holed along the reverse-path to the source from the egress router. This presents a possible issue for Path MTU discovery in operational scenarios, but note that RFC 1981 allows path MTU discovery to be disabled. After consulting with the co-authors, we may decide to write this up as an operational consideration in -07. > > Note that in case 2), ONLY those routers that are actively carrying > > outgoing > > traffic are probed. There is no need to probe routers that carry only > > return > > traffic, since the forward direction is all that is needed. > > > I don't understand what you mean by "routers actively carrying outgoing > traffic"? Is it possible that you are refering to only those routers > that an ISATAP host has affiliated with and has defined a 'default > route'? It seems you are talking about a scenario (packets going out > router B from A->D and returning on C from D->A) were the usage of the > PRL is compounded. I want to understand how router 'C' might not fall > into your "ONLY" statement above. Not quite following you, but the concern here again was the case of ICMPs being black-holed along the reverse path to the source. Let me know if the above comments spoke sufficiently to the (non)issue. > thanks, > -Jason Regards, Fred Templin osprey67@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com From owner-v6ops@ops.ietf.org Wed Nov 20 09:57:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20888 for ; Wed, 20 Nov 2002 09:57:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EWHQ-000KuF-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 06:56:40 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #2) id 18EWHN-000KtM-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 06:56:37 -0800 Received: from consulintel02 ([204.42.71.231]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Wed, 20 Nov 2002 16:01:08 +0100 Message-ID: <033101c29073$521b39f0$e7472acc@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: "Cleveland Mickles" Cc: Subject: Fw: Transition Scenarios for ISP Networks Date: Wed, 20 Nov 2002 10:00:36 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 204.42.71.231 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=DATE_IN_PAST_03_06,DEAR_SOMEBODY,NOSPAM_INC,OUTLOOK_FW_MSG, SPAM_PHRASE_03_05,USER_AGENT_OE,X_MSMAIL_PRIORITY_HIGH, X_PRIORITY_HIGH version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Cleveland, I already emailed you this message during the Yokohama meeting, and I never got your answer. Definitively I will be very interested in working in this. Please, let me know. Regards, Jordi ----- Original Message ----- From: "JORDI PALET MARTINEZ" To: Sent: Wednesday, July 17, 2002 9:29 AM Subject: Transition Scenarios for ISP Networks > Hi, > > I'm right now in the ngtrans session, and after your presentation I believe we have the perfect platform where we can work in your > draft and design team in a practical way. > > Let me explain. > > I'm the scientific project coordinator of Euro6IX, and EC funded project (see www.euro6ix.org). > > This project main goal is ensuring that the core and the access networks of Europe are ready for IPv6. You will see that the > partners are all the European big Telcos and ISP's, so that's the relevance with your work. > > But also, we are taking care of the access networks, including wired (as xDSL) and wireless. > > One very important activity area is the IX deployment. We are working not just in layer 2, but also in a new concept of layer 3 IXs. > > I'm also working in other projects as 6Power (broadband - 45 to 200 Mbps - IPv6 with QoS on Power Line), 6QM (IPv6 QoS Measurement), > 6AIR (hot spots with IPv6), and some others of less relevance for this work, but all focused in IPv6. They just started, so still > not ready the web site. > > So the question is, there is any way I can participate in the design team, and work together in the work you are doing ? > Definitively, our network is the perfect platform to provide inputs to this work ;-) > > Regards, > Jordi > *********************************** Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Soon on line at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Wed Nov 20 11:17:48 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23537 for ; Wed, 20 Nov 2002 11:17:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EXZB-000NAW-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 08:19:05 -0800 Received: from tyholt.uninett.no ([158.38.60.10]) by psg.com with esmtp (Exim 3.36 #2) id 18EXZ8-000NAK-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 08:19:02 -0800 Received: from sverresborg.uninett.no (sverresborg.uninett.no [158.38.62.92]) by tyholt.uninett.no (8.12.6/8.12.6) with ESMTP id gAKGJ0N1011639; Wed, 20 Nov 2002 17:19:00 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.11.6/8.11.2) id gAKGJ0527332; Wed, 20 Nov 2002 17:19:00 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 20 Nov 2002 17:19:00 +0100 From: Stig Venaas To: Erik Nordmark Cc: v6ops@ops.ietf.org Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-01.txt Message-ID: <20021120171900.A27327@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Erik.Nordmark@sun.com on Sun, Nov 17, 2002 at 06:38:34PM +0100 X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT,X_AUTH_WARNING version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk As Dave said at the meeting, I believe MTU of 1280 might be a problem for MIP. It might also be a problem when doing multicast and sending PIM register messages. Stig From owner-v6ops@ops.ietf.org Wed Nov 20 11:25:05 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23850 for ; Wed, 20 Nov 2002 11:25:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EXgn-000NQl-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 08:26:57 -0800 Received: from dhcp-204-42-71-254.ietf55.ops.ietf.org ([204.42.71.254] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #2) id 18EXgk-000NQI-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 08:26:55 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id F21FB7AF; Thu, 21 Nov 2002 01:04:35 +0900 (JST) To: v6ops@ops.ietf.org Subject: transition mechanism (tunnel MTU) comment X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Thu, 21 Nov 2002 01:04:35 +0900 Message-Id: <20021120160435.F21FB7AF@starfruit.itojun.org> X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk on non-dynamic case, for me, - 1280 MTU is fine - 4400 MRU is fine compromise. i would like to see smaller number, but 4400 is okay. itojun From owner-v6ops@ops.ietf.org Wed Nov 20 12:21:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25420 for ; Wed, 20 Nov 2002 12:21:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EYYW-000Ow2-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 09:22:28 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EYYT-000Ovp-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 09:22:25 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAKHMMF12166 for ; Wed, 20 Nov 2002 19:22:22 +0200 Date: Wed, 20 Nov 2002 19:22:22 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: firewalling points Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, As there was no time for this in the meeting, I'd really like to hear thoughts from the wg on my firewalling considerations draft (draft-savola-v6ops-firewalling-00.txt). Below is the core of the presentation. To re-iterate, I'd really like to hear thoughts: * Are these real problems? * If yes, do we have to do something? If we agree on those, the rest should follow. ==== Issues RFC2460 ambiguity intermediate nodes must not process packets but in practise, they do -- what to do with e.g. unknown headers? Extension Header chain parsing if an unknown header encountered when looking for e.g. TCP/UDP headers, big problems Unknown Destination Options and security policy strict firewalls may disallow dstopts they don't recognize Firewalls and E2E ESP IPSEC can't apply security policy, must trust end-nodes could end up disallowed by default? Firewalls and Peer-to-Peer Apps how to allow in a controlled fashion? Steps forward / What to Do? Do we have to do something? is a clarification wrt. processing required? is the restriction about new extension headers ok? how to deal with e2e IPSEC so that it's not disallowed? how to be able to manage p2p apps without compromising security? etc. If so, what? would it be useful to have this as a w.g. document and push for Informational? interaction with ipv6 wg on specification parts? solutions to bigger problems like ESP IPSEC or P2P must be developed individually Other thoughts? ==== -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 20 12:30:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25575 for ; Wed, 20 Nov 2002 12:30:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EYiC-000PEI-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 09:32:28 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EYiA-000PE1-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 09:32:26 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAKHWNM12234 for ; Wed, 20 Nov 2002 19:32:23 +0200 Date: Wed, 20 Nov 2002 19:32:23 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 6to4 security questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, The most important part (how to go forward) got cut-off at the meeting, so I'm hoping to be able to hear some thoughts on the 6to4 security issues. * The most important thing: ==> document the existing problems and declare done or try to invent bigger fixes for the problems? * Draft has two parts - relay spoofing troubles - 6to4 usage analysis, guidelines for sec considerations implementation etc. ==> keep these separate or not? (the second are IMO ready) * Is the relay problem (spoofing from 2001::/16) something we need to worry about? - after all, you probably can spoof the source addresses without 6to4 too.. ==> if yes, how much effort should we put into it? * Should we analyze the DoS attacks (abusing relays) whether anything can be done against those in more detail? - already in the draft, maybe more -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 20 12:54:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25884 for ; Wed, 20 Nov 2002 12:54:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EZ5O-000Pvv-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 09:56:26 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18EZ5L-000Pvi-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 09:56:24 -0800 Received: from jurassic.eng.sun.com ([129.146.17.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21456; Wed, 20 Nov 2002 10:56:22 -0700 (MST) Received: from eng.sun.com (vpn-129-152-200-45.East.Sun.COM [129.152.200.45]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKHuJbS818533; Wed, 20 Nov 2002 09:56:21 -0800 (PST) Message-ID: <3DDBCC97.6020901@eng.sun.com> Date: Wed, 20 Nov 2002 09:55:35 -0800 From: Jason Goldschmidt User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: Hi Pekka, Thank you for the presentation today, it was too bad we didn't have more time to discuss it. >The most important part (how to go forward) got cut-off at the meeting, so >I'm hoping to be able to hear some thoughts on the 6to4 security issues. > >* The most important thing: > ==> document the existing problems and declare done or try to invent >bigger fixes for the problems? > Documenting the problems is the first step (which your draft mostly does) and I believe these should remain in their own draft. The larger, relay router related, problems I do not believe can or should be solved by this draft. This draft should present the security concerns, the possible attacks and any known ways to protect a 6to4 site. I also believe there needs text that speaks to the usefulness of a 6to4 relay router. It should be made clear that a site should just block all traffic to/from relay routers if that site does not have a compelling reason to connect to the (Native) IPv6 Internet. 6to4 works great for connecting isolated clouds, but we can all see how connecting to the IPv6 Internet using 6to4 relay routers is flawed and dangerous. > >* Draft has two parts > - relay spoofing troubles > - 6to4 usage analysis, guidelines for sec considerations >implementation etc. > > ==> keep these separate or not? (the second are IMO ready) > Keep it in one draft. Any "solutions" for the relay router problems should be brought up in another draft. > >* Is the relay problem (spoofing from 2001::/16) something we need to >worry about? > - after all, you probably can spoof the source addresses without 6to4 >too.. > ==> if yes, how much effort should we put into it? > This is a very serious problem which can make 6to4 hosts into pawns for a DDoS attack. It needs mentioning, but we might just have to accept that it is very difficult to prevent for the average case. Certainly 6to4 relay routers as an entity are not evil, only the potential abuse. With proper considerations and limited usage, relay routers can be used safely. A few people during the meeting mentioned using IPSec or some sort of three way handshake. These approaches will not work for the average case, but can work for specific deployments of 6to4. thanks, -Jason >* Should we analyze the DoS attacks (abusing relays) whether anything can >be done against those in more detail? > - already in the draft, maybe more > > > > From owner-v6ops@ops.ietf.org Wed Nov 20 13:06:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26236 for ; Wed, 20 Nov 2002 13:06:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EZHB-0000Ls-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 10:08:37 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18EZH9-0000LP-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 10:08:35 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gAKI8Om16162; Wed, 20 Nov 2002 19:08:24 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gAKI8Ote035518; Wed, 20 Nov 2002 19:08:25 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211201808.gAKI8Ote035518@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org Subject: Re: transition mechanism (tunnel MTU) comment In-reply-to: Your message of Thu, 21 Nov 2002 01:04:35 +0900. <20021120160435.F21FB7AF@starfruit.itojun.org> Date: Wed, 20 Nov 2002 19:08:24 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk About the dynamic case, I don't understand the 4400 limit (far too low for GigaEthernet where the MTU is commonly ~9k). Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Wed Nov 20 13:08:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26290 for ; Wed, 20 Nov 2002 13:08:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EZJT-0000RA-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 10:10:59 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #2) id 18EZJQ-0000QB-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 10:10:56 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05324; Wed, 20 Nov 2002 10:10:23 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAKIALH07113; Wed, 20 Nov 2002 19:10:21 +0100 (MET) Date: Wed, 20 Nov 2002 19:06:58 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: transition mechanism (tunnel MTU) comment To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20021120160435.F21FB7AF@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > - 4400 MRU is fine compromise. i would like to see smaller number, > but 4400 is okay. As I tried to say on the slides the reassembly buffers, even if the 4400 number is changed to infinity (=64k), do not need to me larger than the maximum interface MTU/MRU on the tunnel endpoint. THus if you have a decapsulator attached to only Ethernet its reassembly buffer size need not be more than 1500 bytes. If attached to IPoverATM it would not be more than 9180 bytes (rfc 1626) etc. Thus the draft is incorrect in stating the the reassembly buffer size is tied to the max MTU for the dynamic tunnel. Erik From owner-v6ops@ops.ietf.org Wed Nov 20 13:19:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26585 for ; Wed, 20 Nov 2002 13:19:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EZTq-0000nx-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 10:21:42 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18EZTo-0000nh-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 10:21:40 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09075; Wed, 20 Nov 2002 11:21:37 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAKILWH08238; Wed, 20 Nov 2002 19:21:32 +0100 (MET) Date: Wed, 20 Nov 2002 19:18:19 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 6to4 security questions To: Jason Goldschmidt Cc: Pekka Savola , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3DDBCC97.6020901@eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Documenting the problems is the first step (which your draft mostly > does) and I believe these should remain in their own draft. The larger, > relay router related, problems I do not believe can or should be solved > by this draft. This draft should present the security concerns, the > possible attacks and any known ways to protect a 6to4 site. I also > believe there needs text that speaks to the usefulness of a 6to4 relay > router. It should be made clear that a site should just block all > traffic to/from relay routers if that site does not have a compelling > reason to connect to the (Native) IPv6 Internet. 6to4 works great for > connecting isolated clouds, but we can all see how connecting to the > IPv6 Internet using 6to4 relay routers is flawed and dangerous. I think that would result in a separate "6to4 Internet" and "IPv6-native Internet" which can't (reliably) communicate which would be a very bad idea - so bad that we should deprecate 6to4 IMHO. Instead it makes sense trying to find sound operational practises that can be applied while allowing nodes/sites using 6to4 to communicate with nodes/sites that do not use 6to4 without severe security issues. Erik From owner-v6ops@ops.ietf.org Wed Nov 20 13:19:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26603 for ; Wed, 20 Nov 2002 13:19:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EZUF-0000ow-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 10:22:07 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EZUC-0000ob-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 10:22:04 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAKILxu12753; Wed, 20 Nov 2002 20:21:59 +0200 Date: Wed, 20 Nov 2002 20:21:59 +0200 (EET) From: Pekka Savola To: Jason Goldschmidt cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-Reply-To: <3DDBCC97.6020901@eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for the comments, a reply to a comment below. On Wed, 20 Nov 2002, Jason Goldschmidt wrote: > [...] I also > believe there needs text that speaks to the usefulness of a 6to4 relay > router. It should be made clear that a site should just block all > traffic to/from relay routers if that site does not have a compelling > reason to connect to the (Native) IPv6 Internet. 6to4 works great for > connecting isolated clouds, but we can all see how connecting to the > IPv6 Internet using 6to4 relay routers is flawed and dangerous. I'm not so sure about that -- if you just want to connect isolated islands, usually you could also use configured tunneling. Global connectivity is an important factor, but those that don't want it seem to be just a corner case. There are two special cases that I can think of: - people using 6to4 addresses merely because of their automatic features, as a replacement for automatic tunneling/ISATAP (e.g. to connect v6 edge routers over v4 MPLS core). ==> personally I'm not sure this is really a valid usage scenario but rather a hack. - people using 6to4 merely to be able to "optimize" (assuming v4 tunneling is better than v6 native, which is currently true) 6to4 connections in addition to their native v6 connections. Then a relay is not needed. But blocking may still be a bit problematic as it depends on proper source/destination address selection everywhere (depending a bit on wheter 6to4 address are published e.g. in DNS) What do others feel? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 20 13:28:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26701 for ; Wed, 20 Nov 2002 13:28:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EZcE-0001Ah-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 10:30:22 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.36 #2) id 18EZcC-0001AR-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 10:30:20 -0800 Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F8DC6220C; Wed, 20 Nov 2002 19:30:11 +0100 (CET) Date: Wed, 20 Nov 2002 09:47:06 -0500 From: Harald Tveit Alvestrand To: Alain Durand Cc: v6ops@ops.ietf.org Subject: Re: draft-ymbk-6to4-arpa-delegation-00.txt Message-ID: <156785515.1037785626@localhost> In-Reply-To: <21615962.1037366190@localhost> References: <20021111190712.294FD7AF@starfruit.itojun.org> <3DD021DC.70400@sun.com> <21615962.1037366190@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-1.0 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 15. november 2002 13:16 -0500 Harald Tveit Alvestrand wrote: > > > --On 11. november 2002 13:32 -0800 Alain Durand > wrote: > >> I would like not to change it too, but the alternative to create records >> on the fly in the DNS servers is an invitation for DOS attack on >> DNSsec... > > why? > > the synthesized records are "like" glue records, aren't they? > so they shouldn't be signed anyway....? I was corrected by Rob Austein. If we want to be able to use DNSSEC at the 6to4 leaf nodes, the synthesized record set has to include a (signed) DS record. And then it gets ugly..... Harald From owner-v6ops@ops.ietf.org Wed Nov 20 13:52:32 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27373 for ; Wed, 20 Nov 2002 13:52:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EZzt-00025M-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 10:54:49 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #2) id 18EZzp-00024m-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 10:54:46 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAKIs7kL060644; Wed, 20 Nov 2002 19:54:07 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAKIs6da053060; Wed, 20 Nov 2002 19:54:07 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA75170 from ; Wed, 20 Nov 2002 19:54:02 +0100 Message-Id: <3DDBDA36.FD94C495@hursley.ibm.com> Date: Wed, 20 Nov 2002 19:53:42 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.6 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, My fundamental question since the 6to4 spoofing issue was first raised is whether this exposure to spoofing is a *significant* addition to the generic exposure. If you were a spoofer, would you really bother spoofing 6to4 rather than just plain spoofing? So my feeling is that we really need more general work on anti-v6-spoofing, with this viewed as once case among many. I am reluctant to see us publish an RFC containing specific heuristics for the 6to4 case until we have really looked at spoofing in general. Brian Pekka Savola wrote: > > Hello, > > The most important part (how to go forward) got cut-off at the meeting, so > I'm hoping to be able to hear some thoughts on the 6to4 security issues. > > * The most important thing: > ==> document the existing problems and declare done or try to invent > bigger fixes for the problems? > > * Draft has two parts > - relay spoofing troubles > - 6to4 usage analysis, guidelines for sec considerations > implementation etc. > ==> keep these separate or not? (the second are IMO ready) > > * Is the relay problem (spoofing from 2001::/16) something we need to > worry about? > - after all, you probably can spoof the source addresses without 6to4 > too.. > ==> if yes, how much effort should we put into it? > > * Should we analyze the DoS attacks (abusing relays) whether anything can > be done against those in more detail? > - already in the draft, maybe more > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-v6ops@ops.ietf.org Wed Nov 20 14:03:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27625 for ; Wed, 20 Nov 2002 14:03:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EaAk-0002ZY-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 11:06:02 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EaAc-0002Xl-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 11:05:54 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAKJ5p413123; Wed, 20 Nov 2002 21:05:51 +0200 Date: Wed, 20 Nov 2002 21:05:51 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-Reply-To: <3DDBDA36.FD94C495@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 20 Nov 2002, Brian E Carpenter wrote: > My fundamental question since the 6to4 spoofing issue was first > raised is whether this exposure to spoofing is a *significant* > addition to the generic exposure. If you were a spoofer, would > you really bother spoofing 6to4 rather than just plain spoofing? So > my feeling is that we really need more general work on anti-v6-spoofing, > with this viewed as once case among many. That depends on how you expect the spoofing protection to be implemented. If we assume that v6 deployments have learned since v4 deployments, and are now also using ingress filtering -- v6 spoofing could be more difficult than v4. But then again, v6 spoofing could be equally easy (or even easier, due to "experimental" nature). Note that even if both v4 and v6 ingress filtering is deployed, this attack is still usable (it's unlikely that the encapsulating source v4 address will be logged, and even if it were, it's probably just some compromised box sitting behind some poor fools DSL line). > Pekka Savola wrote: > > > > Hello, > > > > The most important part (how to go forward) got cut-off at the meeting, so > > I'm hoping to be able to hear some thoughts on the 6to4 security issues. > > > > * The most important thing: > > ==> document the existing problems and declare done or try to invent > > bigger fixes for the problems? > > > > * Draft has two parts > > - relay spoofing troubles > > - 6to4 usage analysis, guidelines for sec considerations > > implementation etc. > > ==> keep these separate or not? (the second are IMO ready) > > > > * Is the relay problem (spoofing from 2001::/16) something we need to > > worry about? > > - after all, you probably can spoof the source addresses without 6to4 > > too.. > > ==> if yes, how much effort should we put into it? > > > > * Should we analyze the DoS attacks (abusing relays) whether anything can > > be done against those in more detail? > > - already in the draft, maybe more > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 20 14:04:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27671 for ; Wed, 20 Nov 2002 14:04:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EaAS-0002Xa-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 11:05:44 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18EaAP-0002XJ-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 11:05:41 -0800 Received: from esunmail ([129.147.58.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10518 for ; Wed, 20 Nov 2002 12:05:41 -0700 (MST) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5W003TM2DG0V@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 20 Nov 2002 12:05:40 -0700 (MST) Received: from sun.com ([204.42.66.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H5W00AFZ2DEKC@mail.sun.net> for v6ops@ops.ietf.org; Wed, 20 Nov 2002 12:05:40 -0700 (MST) Date: Wed, 20 Nov 2002 11:05:43 -0800 From: Alain Durand Subject: Re: 6to4 security questions To: Erik Nordmark Cc: Jason Goldschmidt , Pekka Savola , v6ops@ops.ietf.org Message-id: <3DDBDD07.7030903@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_02_03,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: >>Instead it makes sense trying to find sound operational practises that can >>be applied while allowing nodes/sites using 6to4 to communicate with >>nodes/sites that do not use 6to4 without severe security issues. >> Give the current open, asymetrical, relay architecture of 6to4, this is not possible. The core of the problem is that when decapsulating packets, 6to4 routers have currently no way to know if packets are comming from a legitimate relay or not. Any IPv4 host can impersonate a 6to4 relay and send a packet to a candid 6to4 host with IPv6 src the address of an IPv6 victim. The associated 6to4 router will decapsulate (no way to apply any check), pass it to the candid host that will reply to the IPv6 src, that is, the victim. Multiply this by thousands of candid hosts and you have a very nice anonymized distributed denial of service attack on the IPv6 victim. This is nothing new and was presented at London IETF. There are in my opinion 4 ways forward: 1- Revisit 6to4 architecture to have bi-directional communication between the 6to4 router and the 6to4 relay. That way the decapsulating 6to4 router could apply some checks and make sure packets are comming from a legitimate 6to4 relay. 2- Declare the problem unsolvable and try to mitigate the effect, investigate iTrace solutions to enable tracing back the source of DDOS attack. 3- The main security concern is that the open relay architecture enables an attacker to defeat IPv4 ingress filtering (if in place) to do perform DDOS on a IPv6 host. There are already many other ways to create DDOS, so we should not worry to much. 4- Declare the problem unsolvable and serious. This means deprecating 6to4. IMHO, 1) is a major undertaking, 2) is scarry at least, 3) is irresponsible and 4) has tremendous consequences. - Alain. From owner-v6ops@ops.ietf.org Wed Nov 20 14:08:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27785 for ; Wed, 20 Nov 2002 14:08:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EaFV-0002kN-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 11:10:57 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #2) id 18EaFQ-0002iz-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 11:10:54 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAKJADMT009092; Wed, 20 Nov 2002 20:10:13 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAKJACda089204; Wed, 20 Nov 2002 20:10:12 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA35794 from ; Wed, 20 Nov 2002 20:10:09 +0100 Message-Id: <3DDBDDFC.2108B6CC@hursley.ibm.com> Date: Wed, 20 Nov 2002 20:09:48 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Jason Goldschmidt Cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: <3DDBCC97.6020901@eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jason Goldschmidt wrote: ... > ...It should be made clear that a site should just block all > traffic to/from relay routers if that site does not have a compelling > reason to connect to the (Native) IPv6 Internet. 6to4 works great for > connecting isolated clouds, but we can all see how connecting to the > IPv6 Internet using 6to4 relay routers is flawed and dangerous. Er, you're missing the main reason 6to4 was invented, i.e. allowing isolated IPv6 sites to connect to the IPv6 Internet using relay routers. The use of 6to4 encapsulation to source bogus traffic was in fact discussed very briefly in the security section of RFC 3056, but without proposing a way to identify valid relay routers. If, after studying spoofing in general, we still need a specific solution to the 6to4 spoofing risk, it will need to be a secure way of identifying valid relays. Brian From owner-v6ops@ops.ietf.org Wed Nov 20 14:10:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27845 for ; Wed, 20 Nov 2002 14:10:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EaHL-0002qb-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 11:12:51 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EaHI-0002pi-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 11:12:49 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAKJCh313206; Wed, 20 Nov 2002 21:12:43 +0200 Date: Wed, 20 Nov 2002 21:12:42 +0200 (EET) From: Pekka Savola To: Alain Durand cc: Erik Nordmark , Jason Goldschmidt , Subject: Re: 6to4 security questions In-Reply-To: <3DDBDD07.7030903@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 20 Nov 2002, Alain Durand wrote: > 1- Revisit 6to4 architecture to have bi-directional communication > between the 6to4 router and the 6to4 relay. That way the decapsulating > 6to4 router could apply some checks and make sure packets are comming > from a legitimate 6to4 relay. I believe the "Limited Distribution of More Specific Routes" approach in the draft could perhaps be able to solve these problems. This would only be very minor modifications for the 6to4 routers/nodes, so this might yet be doable. There are some caveats though.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 20 14:13:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27928 for ; Wed, 20 Nov 2002 14:13:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EaKH-0002z9-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 11:15:53 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18EaKF-0002yx-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 11:15:51 -0800 Received: from esunmail ([129.147.58.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09178 for ; Wed, 20 Nov 2002 12:15:50 -0700 (MST) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5W00MIY2UEOB@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 20 Nov 2002 12:15:50 -0700 (MST) Received: from sun.com ([204.42.66.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H5W00A672UBK3@mail.sun.net> for v6ops@ops.ietf.org; Wed, 20 Nov 2002 12:15:50 -0700 (MST) Date: Wed, 20 Nov 2002 11:15:52 -0800 From: Alain Durand Subject: Re: 6to4 security questions To: Brian E Carpenter Cc: Pekka Savola , v6ops@ops.ietf.org Message-id: <3DDBDF68.2070407@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: <3DDBDA36.FD94C495@hursley.ibm.com> X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Brian E Carpenter wrote: >Pekka, > >My fundamental question since the 6to4 spoofing issue was first >raised is whether this exposure to spoofing is a *significant* >addition to the generic exposure. If you were a spoofer, would >you really bother spoofing 6to4 rather than just plain spoofing? > IPv4 ingress filtering is an answer to IPv4 spoofing. IPv6 ingress filtering is an answer to IPv6 spoofing The 6to4 relay architecture enable an IPv4 attacker to bypass IPv4 and IPv6 ingress filtering to bring down an IPv6 host. - Alain. From owner-v6ops@ops.ietf.org Wed Nov 20 14:48:03 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28913 for ; Wed, 20 Nov 2002 14:48:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EaqC-0004Nk-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 11:48:52 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18Eaq2-0004M3-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 11:48:43 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 8E31D7E13 for ; Wed, 20 Nov 2002 20:48:35 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 388C67976 for ; Wed, 20 Nov 2002 20:48:29 +0100 (CET) From: "Jeroen Massar" To: Subject: RE: 6to4 security questions Date: Wed, 20 Nov 2002 20:48:45 +0100 Organization: Unfix Message-ID: <006a01c290cd$d6728500$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3DDBDD07.7030903@sun.com> Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA28913 [I removed the To's and CC's as they are all on the list anyways ;) ] Alain Durand wrote: > Erik Nordmark wrote: > 1- Revisit 6to4 architecture to have bi-directional communication > between the 6to4 router and the 6to4 relay. That way the decapsulating > 6to4 router could apply some checks and make sure packetsare comming > from a legitimate 6to4 relay. > > 2- Declare the problem unsolvable and try to mitigate the effect, > investigate iTrace solutions to enable tracing back the source of > DDOS attack. > > 3- The main security concern is that the open relay > architecture enables > an attacker to defeat IPv4 ingress filtering (if in place) to do > perform DDOS on a IPv6 host. > There are already many other ways to create DDOS, so we > should not worry to much. Currently in europe, at least, there are only a few 6to4 relays: - Switch - Cybernet - Funet More at http://www.kfu.com/~nsayer/6to4/ (which bans IE browsers) Of the above Switch attracts the most traffic. Limiting the 6to4 relay to a certain scope using the 6to4 anycast. Allows one to at least limit ddos attacks also to that scope. Which could be only a couple of neighboring AS's. This will also solve the problem of the "I route via switzerland" problem even though one is in The Netherlands for example. Afaik FUNET only announces it's relay to a couple of AS's and this seems to work quite well. Ofcourse to be completely certain of this you should query them if they had any problems. IPng (www.ipng.nl) had a 6to4 relay for some time but we closed it due to the many abuses it came along with it. Requiring users to at least sign up to the service does impose a small step but apparently seeing the numbers of configured tunnels provided by the many tunnel broker services it apparently isn't a very big limitation for most people. Personally I don't like 6to4 because the routing in the 6to4 world is far from perfect, or acceptable for most people. Configured tunnels are clearer, easier to troubleshout and to trace abuse from/to. Good thing ofcourse is that it helps out people wanting to do IPv6 to transition very quickly. Even though I would recommend those people to get a configured tunnel from their closed upstream and transition to native IPv6 where possible ofcourse. Greets, Jeroen From owner-v6ops@ops.ietf.org Wed Nov 20 14:56:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29014 for ; Wed, 20 Nov 2002 14:56:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Eaz9-0004hm-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 11:58:07 -0800 Received: from dhcp-204-42-71-254.ietf55.ops.ietf.org ([204.42.71.254] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #2) id 18Eaz6-0004hY-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 11:58:04 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 772457AF; Thu, 21 Nov 2002 04:57:59 +0900 (JST) To: v6ops@ops.ietf.org In-reply-to: jeroen's message of Wed, 20 Nov 2002 20:48:45 +0100. <006a01c290cd$d6728500$210d640a@unfix.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: 6to4 security questions From: Jun-ichiro itojun Hagino Date: Thu, 21 Nov 2002 04:57:59 +0900 Message-Id: <20021120195759.772457AF@starfruit.itojun.org> X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk at IIJ, we had a long internal discussion whether we should provide 6to4 relay router or not. we of course are serious about IPv6, would like it to be deployed real soon, but we decided not to provide it due to the very problems outlined in pekka's draft. (actually, i've pointed it out before him in draft-itojun-ipv6-transition-abuse-01) >Personally I don't like 6to4 because the routing in the 6to4 world is >far from perfect, or acceptable for most people. >Configured tunnels are clearer, easier to troubleshout and to trace >abuse from/to. Good thing ofcourse is that it helps out people wanting=20 >to do IPv6 to transition very quickly. Even though I would recommend >those people to get a configured tunnel from their closed upstream and >transition to native IPv6 where possible ofcourse. i 100% agree with the above opinion. itojun From owner-v6ops@ops.ietf.org Wed Nov 20 14:58:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29068 for ; Wed, 20 Nov 2002 14:58:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Eb1R-0004nQ-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 12:00:29 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #2) id 18Eb1O-0004ly-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 12:00:26 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAKJxleW074644; Wed, 20 Nov 2002 20:59:47 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAKJxlda072828; Wed, 20 Nov 2002 20:59:47 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45030 from ; Wed, 20 Nov 2002 20:59:43 +0100 Message-Id: <3DDBE99A.42CD1C41@hursley.ibm.com> Date: Wed, 20 Nov 2002 20:59:22 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Alain Durand Cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: <3DDBDA36.FD94C495@hursley.ibm.com> <3DDBDF68.2070407@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alain Durand wrote: > > Brian E Carpenter wrote: > > >Pekka, > > > >My fundamental question since the 6to4 spoofing issue was first > >raised is whether this exposure to spoofing is a *significant* > >addition to the generic exposure. If you were a spoofer, would > >you really bother spoofing 6to4 rather than just plain spoofing? > > > IPv4 ingress filtering is an answer to IPv4 spoofing. > IPv6 ingress filtering is an answer to IPv6 spoofing > > The 6to4 relay architecture enable an IPv4 attacker to bypass > IPv4 and IPv6 ingress filtering to bring down an IPv6 host. I'm aware of all that, but you're not answering my question. Is the risk significant? Brian From owner-v6ops@ops.ietf.org Wed Nov 20 15:00:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29208 for ; Wed, 20 Nov 2002 15:00:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Eb3S-0004sY-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 12:02:34 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #2) id 18Eb3N-0004qR-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 12:02:30 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAKK1mkL029774; Wed, 20 Nov 2002 21:01:48 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAKK1kda014380; Wed, 20 Nov 2002 21:01:47 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA71796 from ; Wed, 20 Nov 2002 21:01:42 +0100 Message-Id: <3DDBEA11.FCB9D6B9@hursley.ibm.com> Date: Wed, 20 Nov 2002 21:01:21 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: Alain Durand , Erik Nordmark , Jason Goldschmidt , v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > On Wed, 20 Nov 2002, Alain Durand wrote: > > 1- Revisit 6to4 architecture to have bi-directional communication > > between the 6to4 router and the 6to4 relay. That way the decapsulating > > 6to4 router could apply some checks and make sure packets are comming > > from a legitimate 6to4 relay. > > I believe the "Limited Distribution of More Specific Routes" approach in > the draft could perhaps be able to solve these problems. > > This would only be very minor modifications for the 6to4 routers/nodes, so > this might yet be doable. > > There are some caveats though.. Nevertheless I do prefer this approach, or to be more precise, I'd like to be able to answer the question "should I trust this relay router?" Brian From owner-v6ops@ops.ietf.org Wed Nov 20 15:02:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29248 for ; Wed, 20 Nov 2002 15:02:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Eb5F-0004xJ-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 12:04:25 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Eb5B-0004wx-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 12:04:22 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAKK4BE13706; Wed, 20 Nov 2002 22:04:11 +0200 Date: Wed, 20 Nov 2002 22:04:11 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Alain Durand , Erik Nordmark , Jason Goldschmidt , Subject: Re: 6to4 security questions In-Reply-To: <3DDBEA11.FCB9D6B9@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 20 Nov 2002, Brian E Carpenter wrote: > > On Wed, 20 Nov 2002, Alain Durand wrote: > > > 1- Revisit 6to4 architecture to have bi-directional communication > > > between the 6to4 router and the 6to4 relay. That way the decapsulating > > > 6to4 router could apply some checks and make sure packets are comming > > > from a legitimate 6to4 relay. > > > > I believe the "Limited Distribution of More Specific Routes" approach in > > the draft could perhaps be able to solve these problems. > > > > This would only be very minor modifications for the 6to4 routers/nodes, so > > this might yet be doable. > > > > There are some caveats though.. > > Nevertheless I do prefer this approach, or to be more precise, > I'd like to be able to answer the question "should I trust > this relay router?" Yep. Some relays would never be able part of this "more specific 2002::/16 routes mesh": then you can pick the policy; either discard the packet (if coming from a relay not part of the mesh) or accept it (should be trusted). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 20 16:01:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00699 for ; Wed, 20 Nov 2002 16:01:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ec0R-0006WZ-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 13:03:31 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #2) id 18Ec0P-0006VO-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 13:03:29 -0800 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18784; Wed, 20 Nov 2002 13:02:58 -0800 (PST) Received: from eng.sun.com (vpn-129-152-201-123.East.Sun.COM [129.152.201.123]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKL2sbS871722; Wed, 20 Nov 2002 13:02:56 -0800 (PST) Message-ID: <3DDBF852.2080404@eng.sun.com> Date: Wed, 20 Nov 2002 13:02:10 -0800 From: Jason Goldschmidt User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: <3DDBCC97.6020901@eng.sun.com> <3DDBDDFC.2108B6CC@hursley.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: >Jason Goldschmidt wrote: >... > > >> ...It should be made clear that a site should just block all >>traffic to/from relay routers if that site does not have a compelling >>reason to connect to the (Native) IPv6 Internet. 6to4 works great for >>connecting isolated clouds, but we can all see how connecting to the >>IPv6 Internet using 6to4 relay routers is flawed and dangerous. >> >> > >Er, you're missing the main reason 6to4 was invented, i.e. allowing >isolated IPv6 sites to connect to the IPv6 Internet using relay routers. > Understood, but the sparse deployment of 6to4 relay routers suggests people are not using 6to4 to connect to the IPv6 Internet. And if they are, it isn't anything really that important. -Jason > >The use of 6to4 encapsulation to source bogus traffic was in fact >discussed very briefly in the security section of RFC 3056, but without >proposing a way to identify valid relay routers. If, after studying >spoofing in general, we still need a specific solution to the 6to4 >spoofing risk, it will need to be a secure way of identifying valid >relays. > > Brian > > > From owner-v6ops@ops.ietf.org Wed Nov 20 16:06:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00827 for ; Wed, 20 Nov 2002 16:06:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ec5l-0006iA-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 13:09:01 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Ec5i-0006hD-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 13:08:58 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA08094 for ; Wed, 20 Nov 2002 21:08:55 GMT Received: from login.ecs.soton.ac.uk (IDENT:d9vapckV98e0HMki1uX4wjmo2A3/Pf7i@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAKL8sWX014524 for ; Wed, 20 Nov 2002 21:08:54 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gAKL8sF09905 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 21:08:54 GMT Date: Wed, 20 Nov 2002 21:08:54 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: 6to4 security questions Message-ID: <20021120210853.GD9782@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <3DDBDD07.7030903@sun.com> <006a01c290cd$d6728500$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006a01c290cd$d6728500$210d640a@unfix.org> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Nov 20, 2002 at 08:48:45PM +0100, Jeroen Massar wrote: > > Currently in europe, at least, there are only a few 6to4 relays: > - Switch > - Cybernet > - Funet There are others (e.g. three I know of in the UK). How public they are is another issue. Just to put 6to4 in perspective for its current deployment, I am not aware of any European NRENs that are using 6to4 to connect sites to their national IPv6 deployments. Everything is done by manually configured tunnels. That's not to say 6to4 doesn't have a place (our students use it for access from their home networks, and it will work behind a NAT with tunnel forwarding) but it is perhaps more likely to be in large customer networks? To play devil's advocate, who is using 6to4 in a notable deployment? Tim From owner-v6ops@ops.ietf.org Wed Nov 20 16:13:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00985 for ; Wed, 20 Nov 2002 16:13:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EcCp-00078f-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 13:16:19 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18EcCm-00078N-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 13:16:16 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gAKLGCm18563; Wed, 20 Nov 2002 22:16:12 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gAKLGCte035951; Wed, 20 Nov 2002 22:16:12 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211202116.gAKLGCte035951@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-reply-to: Your message of Wed, 20 Nov 2002 19:32:23 +0200. Date: Wed, 20 Nov 2002 22:16:12 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk A general remark: the reflexion DoS attack was extensively discussed in the mobile-ip WG mailing list for the Home Agent Option which has a similar problem... Francis.Dupont@enst-bretagne.fr PS: Pekka, I supposed you have followed the discussion (or at least you know where are the archives). IMHO a summary of proposed solutions (with pros & cons in the 6to4 context) should be a nice thing. PPS: I have another concern about 6to4: the business model for running 6to4 relays seems to be flawed (for example there are a very small number of available 6to4 relays today and *no* ISP guy I asked why he didn't run one gave an answer different than a loud no). I am afraid that if 6to4 is deployed we'll get two distinct IPv6 Internets: the 6to4 one and the native one... From owner-v6ops@ops.ietf.org Wed Nov 20 16:31:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01640 for ; Wed, 20 Nov 2002 16:31:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EcTm-00084o-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 13:33:50 -0800 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #2) id 18EcTj-00083y-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 13:33:47 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAKLXAQ4227490; Wed, 20 Nov 2002 22:33:11 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAKLXAqG150544; Wed, 20 Nov 2002 22:33:10 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60292 from ; Wed, 20 Nov 2002 22:33:07 +0100 Message-Id: <3DDBFF7E.A78ED135@hursley.ibm.com> Date: Wed, 20 Nov 2002 22:32:46 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Jason Goldschmidt Cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: <3DDBCC97.6020901@eng.sun.com> <3DDBDDFC.2108B6CC@hursley.ibm.com> <3DDBF852.2080404@eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jason Goldschmidt wrote: > > Brian E Carpenter wrote: > > >Jason Goldschmidt wrote: > >... > > > > > >> ...It should be made clear that a site should just block all > >>traffic to/from relay routers if that site does not have a compelling > >>reason to connect to the (Native) IPv6 Internet. 6to4 works great for > >>connecting isolated clouds, but we can all see how connecting to the > >>IPv6 Internet using 6to4 relay routers is flawed and dangerous. > >> > >> > > > >Er, you're missing the main reason 6to4 was invented, i.e. allowing > >isolated IPv6 sites to connect to the IPv6 Internet using relay routers. > > > Understood, but the sparse deployment of 6to4 relay routers suggests > people are not using 6to4 to connect to the IPv6 Internet. And if they > are, it isn't anything really that important. Let's be clear why 6to4 was invented. It was intended to be a disruptive technology for the case where a relatively sophisticated site's ISP was unwilling to provide IPv6 service, and no upstream tunnel provider was available. But I wouldn't expect to see widespread deployment until there is widespread demand for IPv6 access, by which time we need to have fixed the spoofing risk. Brian > > -Jason > > > > >The use of 6to4 encapsulation to source bogus traffic was in fact > >discussed very briefly in the security section of RFC 3056, but without > >proposing a way to identify valid relay routers. If, after studying > >spoofing in general, we still need a specific solution to the 6to4 > >spoofing risk, it will need to be a secure way of identifying valid > >relays. > > > > Brian > > > > > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-v6ops@ops.ietf.org Wed Nov 20 16:31:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01656 for ; Wed, 20 Nov 2002 16:31:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EcTr-00085G-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 13:33:55 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18EcTn-000852-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 13:33:51 -0800 Received: from jurassic.eng.sun.com ([129.146.17.55]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04518; Wed, 20 Nov 2002 14:33:50 -0700 (MST) Received: from eng.sun.com (vpn-129-152-201-123.East.Sun.COM [129.152.201.123]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gAKLXlbS879129; Wed, 20 Nov 2002 13:33:49 -0800 (PST) Message-ID: <3DDBFF8E.2010401@eng.sun.com> Date: Wed, 20 Nov 2002 13:33:02 -0800 From: Jason Goldschmidt User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Chown CC: v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: <3DDBDD07.7030903@sun.com> <006a01c290cd$d6728500$210d640a@unfix.org> <20021120210853.GD9782@login.ecs.soton.ac.uk> In-Reply-To: <3DDBDD07.7030903@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: > >To play devil's advocate, who is using 6to4 in a notable deployment? > At Sun we are using 6to4, as an early transition mechanism, for our deployment. For the past few years we have had a few (read 3) engineering sites connected by configured tunnels. We found deployment scalability problems with this approach, so we decided to go with 6to4. Why? In these tough economic times, were it is near impossible to convince cost constrained IT departments to upgrade their core routers, 6to4 becomes the poor man's solution. We are in the process of creating 10-15 6to4 sites which will consist of engineering and labs groups. Unlike configured tunnels, new 6to4 sites can be added at will, instead of having to dig a new configured tunnel for each site. When Alain and I explained how configured tunnels might work, the IT folks turned green remembering deploying multicast. :) At Sun we have the, possibly not so unique, situation of not "owning" parts of our network. A few years back, Sun outsourced mostly all of its network. There is an interface for upgrading routers and such, but this brings up back to the cost problem. Also, our IT department requires that emerging technologies go through a Trial phase (described below) and thus are unwilling to simply "turn-on" native IPv6 routing. Our plan for deployment has four phases. Proof-of-concept - Trial - Pilot - Full Deployment. The Proof-of-concept phase is complete, IPv6, using configured tunnels and local IPv6 routing, has been running for the last few years. The Trial phase is starting now, it will start with 6to4 and transition to using native IPv6 routing after the harder issues of DNS, applications and management tools are figured out (and thus we get more "buy-in"). The Pilot phase will appear much like the Trial phase, but with two key distinctions, it will be on a larger scale and owned by the IT department (not owned by a joint effort of engineering and an advanced development group from IT). Full Deployment is the true, ubiquitous, deployment of IPv6 on our enterprise and edge networks. -Jason > >Tim > > > > > From owner-v6ops@ops.ietf.org Wed Nov 20 16:38:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01810 for ; Wed, 20 Nov 2002 16:38:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EcaP-0008VN-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 13:40:41 -0800 Received: from mail-out1.apple.com ([17.254.0.52]) by psg.com with esmtp (Exim 3.36 #2) id 18EcaE-0008Ut-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 13:40:30 -0800 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gAKLeTw28676 for ; Wed, 20 Nov 2002 13:40:29 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 20 Nov 2002 13:40:10 -0800 Received: from [204.42.72.166] (vpn-scv-x3-72.apple.com [17.219.194.72]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gAKLeKu00098; Wed, 20 Nov 2002 13:40:20 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 20 Nov 2002 13:40:20 -0800 Subject: Re: 6to4 security questions From: Laurent Dumont To: Tim Chown , Message-ID: In-Reply-To: <20021120210853.GD9782@login.ecs.soton.ac.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_ENTOURAGE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We're planning to offer 6to4 as an auto configured fallback for getting home Mac users on IPv6. This of course if we don't get a RA and only in the case we're the Mac is not behind a NAT... But that's another issue. Laurent on 11/20/02 13:08, Tim Chown at tjc@ecs.soton.ac.uk wrote: > On Wed, Nov 20, 2002 at 08:48:45PM +0100, Jeroen Massar wrote: >> >> Currently in europe, at least, there are only a few 6to4 relays: >> - Switch >> - Cybernet >> - Funet > > There are others (e.g. three I know of in the UK). How public they are > is another issue. > > Just to put 6to4 in perspective for its current deployment, I am not aware > of any European NRENs that are using 6to4 to connect sites to their national > IPv6 deployments. Everything is done by manually configured tunnels. > > That's not to say 6to4 doesn't have a place (our students use it for access > from their home networks, and it will work behind a NAT with tunnel > forwarding) > but it is perhaps more likely to be in large customer networks? > > To play devil's advocate, who is using 6to4 in a notable deployment? > > Tim > > From owner-v6ops@ops.ietf.org Wed Nov 20 16:38:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01825 for ; Wed, 20 Nov 2002 16:38:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EcaG-0008V3-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 13:40:32 -0800 Received: from laptop2.ietf55.ops.ietf.org ([204.42.72.221] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18EcaB-0008UY-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 13:40:29 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gAKLd8ve006525; Wed, 20 Nov 2002 22:39:11 +0100 (CET) Date: Wed, 20 Nov 2002 22:39:07 +0100 Subject: Re: 6to4 security questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Pekka Savola , v6ops@ops.ietf.org To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3DDBDA36.FD94C495@hursley.ibm.com> Message-Id: <7FB0A1EE-FCD0-11D6-BC97-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > addition to the generic exposure. If you were a spoofer, would > you really bother spoofing 6to4 rather than just plain spoofing? So > my feeling is that we really need more general work on > anti-v6-spoofing, > with this viewed as once case among many. > I agree with Brian, however - how keen an attacker is to spoof something is ofcourse depending on what he can DoS or connect to. Best regards, - kurtis - From owner-v6ops@ops.ietf.org Wed Nov 20 16:40:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01856 for ; Wed, 20 Nov 2002 16:40:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EccR-0008fF-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 13:42:47 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18EccO-0008e1-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 13:42:45 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gAKLgbm19131; Wed, 20 Nov 2002 22:42:37 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gAKLgbte036048; Wed, 20 Nov 2002 22:42:37 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211202142.gAKLgbte036048@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Jason Goldschmidt , Pekka Savola , v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-reply-to: Your message of Wed, 20 Nov 2002 19:18:19 +0100. Date: Wed, 20 Nov 2002 22:42:37 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: I think that would result in a separate "6to4 Internet" and "IPv6-native Internet" which can't (reliably) communicate which would be a very bad idea - so bad that we should deprecate 6to4 IMHO. => I agree but even we solve the security issue IMHO we have to know why ISPs don't want to run 6to4 relays, i.e., perhaps there is also an operational issue to solve. I believe they are many ISP persons reading this list. Can you explain why there is such a low number of available 6to4 relays today? Thanks Francis.Dupont@enst-bretagne.fr PS (for David Kessens): this can be an item to add to the agenda at the next RIPE meeting. From owner-v6ops@ops.ietf.org Wed Nov 20 16:55:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02417 for ; Wed, 20 Nov 2002 16:55:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ecqu-0009ev-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 13:57:44 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Ecqr-0009eU-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 13:57:41 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAKLvS314734; Wed, 20 Nov 2002 23:57:29 +0200 Date: Wed, 20 Nov 2002 23:57:28 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: v6ops@ops.ietf.org Subject: 6to4 relay deployment [Re: 6to4 security questions] In-Reply-To: <200211202142.gAKLgbte036048@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 20 Nov 2002, Francis Dupont wrote: > I believe they are many ISP persons reading this list. Can you explain > why there is such a low number of available 6to4 relays today? How do you know? Perhaps they do have them, but aren't advertising them to the internet -- certainly, they probably don't see it as their business to provide relay service for *others*. (However, when I've been roaming, not too often though, I've never stumbled on a non-public relay) P.S. We do advertise both 192.88.99.0/24 and 2002::/16 everywhere. And receive quite a bit of traffic, even afar. Actually I have a few gigabytes of logged data I've analyzed once or twice to see who is using the service. Not many of them were from our network. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 20 16:58:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02640 for ; Wed, 20 Nov 2002 16:58:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ectp-0009rs-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 14:00:45 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Ectl-0009rc-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 14:00:41 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAKM07E14802; Thu, 21 Nov 2002 00:00:07 +0200 Date: Thu, 21 Nov 2002 00:00:07 +0200 (EET) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-Reply-To: <20021120210853.GD9782@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 20 Nov 2002, Tim Chown wrote: > Just to put 6to4 in perspective for its current deployment, I am not aware > of any European NRENs that are using 6to4 to connect sites to their national > IPv6 deployments. Everything is done by manually configured tunnels. > > That's not to say 6to4 doesn't have a place (our students use it for access > from their home networks, and it will work behind a NAT with tunnel forwarding) > but it is perhaps more likely to be in large customer networks? > > To play devil's advocate, who is using 6to4 in a notable deployment? To me, it is clear that 6to4 is probably never the best solution except in most SOHO/Home network solutions, or in testing (easy to get started, as there is no need to negotiate a tunnel). But that is what it was designed for, I think. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 20 17:07:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02891 for ; Wed, 20 Nov 2002 17:07:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ed1z-000ANA-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 14:09:11 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Ed1v-000AMm-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 14:09:07 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA08371 for ; Wed, 20 Nov 2002 22:09:05 GMT Received: from login.ecs.soton.ac.uk (IDENT:pl87+Vd3FG0OkpG35tkiq7JiuTnt5gCv@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAKM8cWX022095 for ; Wed, 20 Nov 2002 22:08:39 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gAKM8cU10464 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 22:08:38 GMT Date: Wed, 20 Nov 2002 22:08:38 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: 6to4 relay deployment [Re: 6to4 security questions] Message-ID: <20021120220837.GN9782@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <200211202142.gAKLgbte036048@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Nov 20, 2002 at 11:57:28PM +0200, Pekka Savola wrote: > On Wed, 20 Nov 2002, Francis Dupont wrote: > > I believe they are many ISP persons reading this list. Can you explain > > why there is such a low number of available 6to4 relays today? > > How do you know? Perhaps they do have them, but aren't advertising them > to the internet -- certainly, they probably don't see it as their business > to provide relay service for *others*. (However, when I've been roaming, > not too often though, I've never stumbled on a non-public relay) Indeed. There's one running like this on the UK academic network, but noone's using 6to4. The largest NREN deployment is probably in DFN (Germany) with over 200 academic and commercial customers, all now migrated to DFN's SubTLA I think, and all manual tunnels. Tim From owner-v6ops@ops.ietf.org Wed Nov 20 17:13:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03007 for ; Wed, 20 Nov 2002 17:13:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ed8t-000Asa-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 14:16:19 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18Ed8r-000AsI-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 14:16:17 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gAKMGAm19969; Wed, 20 Nov 2002 23:16:10 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gAKMGAte036224; Wed, 20 Nov 2002 23:16:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211202216.gAKMGAte036224@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: Alain Durand , Pekka Savola , v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-reply-to: Your message of Wed, 20 Nov 2002 20:59:22 +0100. <3DDBE99A.42CD1C41@hursley.ibm.com> Date: Wed, 20 Nov 2002 23:16:10 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: I'm aware of all that, but you're not answering my question. Is the risk significant? => the risk was considered enough significant for the home address option in mobile IPv6 to kill triangular routing, i.e., to drop packets with a HAO which can not be verified (no IPsec SA or binding cache entry). If you consider it is no significant, I'll ask to reopen the HAO discussion in mobile IPv6. Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Wed Nov 20 17:16:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03053 for ; Wed, 20 Nov 2002 17:16:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EdBt-000B4V-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 14:19:25 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18EdBr-000B4H-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 14:19:23 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 83E7B7E0F; Wed, 20 Nov 2002 23:19:40 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 92AED7976; Wed, 20 Nov 2002 23:19:34 +0100 (CET) From: "Jeroen Massar" To: "'Laurent Dumont'" , Subject: RE: 6to4 security questions Date: Wed, 20 Nov 2002 23:19:47 +0100 Organization: Unfix Message-ID: <001001c290e2$f13ab3c0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA03053 Laurent Dumont wrote: > We're planning to offer 6to4 as an auto configured fallback > for getting home > Mac users on IPv6. This of course if we don't get a RA and > only in the case we're the Mac is not behind a NAT... But that's another issue. I think that making that a default option will lead into _many_ helpdesk phonecalls. The actual upstream ISP will get phonecalls like: "www.example.org doesn't work" Even though the upstream (ISP) can reach it quite well over IPv4. Ofcourse one will have IPv6 -> IPv4 fallback. But the latency for falling back will be quite big. Also note that, unless 6to4 relays suddenly pop out of nowhere, the traffic of these users will go through a couple of different countries without the user probably wanting it. It would be a good thing to do to 'force' upstreams to get IPv6 in their networks. But I really don't think it will scale and it will deliver a load of headaches. If you added this option as an option in the network settings with a big help doc alongside with it describing the problems which could arise this would be great. "Go to network config and hit that 'enable 6to4' button to enable it" or something similar. A warning on a non-responded RA could also be a good idea but one has to remember that most users will blindly click "Yes" on most forms they don't understand. People really wanting IPv6 will get it from their upstream or a transitional method and they can pick out of a lot: 6to4, configured using a tunnelbroker or their upstream. Note also that current tunnelbroker systems have quite intuitive websites and for example freenet6 delivers an automatic configuration tool. At least then they will be begging their upstream to get it supported :) Greets, Jeroen From owner-v6ops@ops.ietf.org Wed Nov 20 17:22:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03207 for ; Wed, 20 Nov 2002 17:22:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EdH1-000BQf-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 14:24:43 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EdGy-000BQK-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 14:24:40 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA08406 for ; Wed, 20 Nov 2002 22:24:38 GMT Received: from login.ecs.soton.ac.uk (IDENT:UeLP6buBurBuqOjsrfieHlxSMVBAxRK4@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAKMOVWX023855 for ; Wed, 20 Nov 2002 22:24:31 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gAKMOVA10640 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 22:24:31 GMT Date: Wed, 20 Nov 2002 22:24:31 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: 6to4 security questions Message-ID: <20021120222430.GO9782@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20021120210853.GD9782@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-1.9 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_03_05,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Nov 21, 2002 at 12:00:07AM +0200, Pekka Savola wrote: > > To me, it is clear that 6to4 is probably never the best solution except in > most SOHO/Home network solutions, or in testing (easy to get started, as > there is no need to negotiate a tunnel). > > But that is what it was designed for, I think. If you look at home user connectivity now, the most common method used is a tunnel broker, witness 10K+(?) users of freenet6. A TB can serve /48's as well as just connecting hosts. I doubt there's 10K users of 6to4? I think people can probably handle having a "TB connect" icon on their desktops if needed. I know of many young gamers who were very adept at keeping DirectX versions up to date to play Windows games not so long ago, which is no more tricky. The TB main weakness is tunnel topology - it doesn't optimise like 6to4. I really don't want to use freenet6 from the UK, for example. I also worry about scalability, but the TB web server can farm out tunnels to a farm of TB servers (is this what freenet6 does?). But a nice advantage is that you can use TSP and authentication. I take the point about 6to4 deployment in Sun. It's certainly easier than a mesh of tunnels in that respect (depending on the topology you want), but you still need the same ISP support (ip tunnels allowed). Tim From owner-v6ops@ops.ietf.org Wed Nov 20 17:23:03 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03238 for ; Wed, 20 Nov 2002 17:23:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EdHp-000BVU-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 14:25:33 -0800 Received: from mail-out1.apple.com ([17.254.0.52]) by psg.com with esmtp (Exim 3.36 #2) id 18EdHm-000BVF-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 14:25:31 -0800 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gAKMPTw14166 for ; Wed, 20 Nov 2002 14:25:30 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 20 Nov 2002 14:25:29 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id gAKMPTp25706 for ; Wed, 20 Nov 2002 14:25:29 -0800 (PST) Date: Wed, 20 Nov 2002 14:25:28 -0800 Subject: Re: 6to4 security questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) From: Joshua Graessley To: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <20021120210853.GD9782@login.ecs.soton.ac.uk> Message-Id: X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, November 20, 2002, at 01:08 PM, Tim Chown wrote: > On Wed, Nov 20, 2002 at 08:48:45PM +0100, Jeroen Massar wrote: >> >> Currently in europe, at least, there are only a few 6to4 relays: >> - Switch >> - Cybernet >> - Funet > > There are others (e.g. three I know of in the UK). How public they are > is another issue. > > Just to put 6to4 in perspective for its current deployment, I am not > aware > of any European NRENs that are using 6to4 to connect sites to their > national > IPv6 deployments. Everything is done by manually configured tunnels. > > That's not to say 6to4 doesn't have a place (our students use it for > access > from their home networks, and it will work behind a NAT with tunnel > forwarding) > but it is perhaps more likely to be in large customer networks? > > To play devil's advocate, who is using 6to4 in a notable deployment? Define a notable deployment. Windows XP comes with IPv6 support. It isn't on by default, but with a few commands, IPv6 is on and 6to4 is up. Mac OS X 10.2 (a.k.a. Jaguar) ships with IPv6 on and listening for routing advertisements. With a command, 6to4 is on and the node has an IPv6 address. These releases require people to manually enable 6to4. It won't be long before such technologies are enabled by default. Will the 6to4 relays melt down? Perhaps. Will there be any incentive for people to deploy 6to4 relays or even maintain them if the traffic does pick up? At the very least, it will be a sign that there is demand for IPv6 connectivity. Is it reasonable to rely on ISPs supplying IPv6 to their customers? I don't imagine I'll live to see the day that SBC hands out IPv6 addresses to DSL customers, and I'm only 25. I see only one compelling reason to use IPv6 instead of IPv4, and that's end to end connectivity (no NATs). The problem is, developers are not going to deploy an IPv6 application if there are no clients that have IPv6 addresses. Until there are applications that support IPv6 and don't work over IPv4, there will be no demand for IPv6. 6to4 is a bootstrap technology that lets you get IPv6 out to a lot of people, people that have no hope of getting IPv6 addresses from shortsighted ISPs. With transition technologies like 6to4, developers can count on IPv6 and writing their applications. If the applications succeed and people are using IPv6, the demand may convince the ISPs to deploy IPv6. Unfortunately, 6to4 will not work for everyone out there, especially those behind a NAT. Vendors of NAT boxes are not implementing 6to4, they don't see any demand. The shipworm/teredo draft is an interesting proposal for getting IPv6 connectivity to nodes behind a NAT. Unfortunately, the IETF seems to be totally uninterested. If the transition to IPv6 relies on ISPs making a multi-billion dollar gamble that deploying IPv6 without any customer demand will pay off, IPv6 will never be widely deployed. Tunnel brokers don't scale, unless they charge. If they charge, only corporations and the few individuals that care enough will have IPv6 connectivity. -josh From owner-v6ops@ops.ietf.org Wed Nov 20 17:25:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03263 for ; Wed, 20 Nov 2002 17:25:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EdKK-000Bgg-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 14:28:08 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18EdKG-000BgQ-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 14:28:04 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gAKMRxm20191; Wed, 20 Nov 2002 23:27:59 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gAKMS0te036273; Wed, 20 Nov 2002 23:28:00 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211202228.gAKMS0te036273@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alain Durand cc: Erik Nordmark , Jason Goldschmidt , Pekka Savola , v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-reply-to: Your message of Wed, 20 Nov 2002 11:05:43 PST. <3DDBDD07.7030903@sun.com> Date: Wed, 20 Nov 2002 23:28:00 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: There are in my opinion 4 ways forward: 1- Revisit 6to4 architecture to have bi-directional communication between the 6to4 router and the 6to4 relay. That way the decapsulating 6to4 router could apply some checks and make sure packets are comming from a legitimate 6to4 relay. => this is the solution for the home address option similar issue (the option is checked against the binding cache, i.e., is validated only when two-way communication is used). Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Wed Nov 20 17:39:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03757 for ; Wed, 20 Nov 2002 17:39:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EdXt-000Cd7-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 14:42:09 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EdXr-000Ccu-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 14:42:07 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAKMftG15189; Thu, 21 Nov 2002 00:41:55 +0200 Date: Thu, 21 Nov 2002 00:41:55 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Alain Durand , Erik Nordmark , Jason Goldschmidt , Subject: Re: 6to4 security questions In-Reply-To: <200211202228.gAKMS0te036273@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 20 Nov 2002, Francis Dupont wrote: > There are in my opinion 4 ways forward: > > 1- Revisit 6to4 architecture to have bi-directional communication > between the 6to4 router and the 6to4 relay. That way the decapsulating > 6to4 router could apply some checks and make sure packets are comming > from a legitimate 6to4 relay. > > => this is the solution for the home address option similar issue > (the option is checked against the binding cache, i.e., is validated > only when two-way communication is used). The amount of harm one can do is similar, but the model seems otherwise a bit different. Mobile nodes _were able to_ (speaking about the old spec where unverified HAO was still ok) communicate without HAO's. Your regular honest 6to4 node can't as it's its only address; they have no care-of addresses for bootstrapping, regular/no-frills operation, etc. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 20 17:49:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04004 for ; Wed, 20 Nov 2002 17:49:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EdhA-000D62-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 14:51:44 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Edh8-000D5a-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 14:51:42 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAKMp9w15287; Thu, 21 Nov 2002 00:51:09 +0200 Date: Thu, 21 Nov 2002 00:51:09 +0200 (EET) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-Reply-To: <20021120222430.GO9782@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 20 Nov 2002, Tim Chown wrote: > If you look at home user connectivity now, the most common method used is > a tunnel broker, witness 10K+(?) users of freenet6. A TB can serve /48's > as well as just connecting hosts. I doubt there's 10K users of 6to4? Really that many? I wonder how many of them are actually being used? To me, 6to4 seems far better mechanism to deploy v6 for organizations that _usually_ need tunnel broker (easy access, tunnel end-point far away). Controlled tunnel brokering seems of course the better choice. But it appears to me that that's _not_ what most of those tunnel sites are.. > I take the point about 6to4 deployment in Sun. It's certainly easier than > a mesh of tunnels in that respect (depending on the topology you want), > but you still need the same ISP support (ip tunnels allowed). That's wrong way to deploy 6to4, as it breaks the assumption about global reachability. Instead, if configuring tunnels between the sites (the N^2 problem) is a real problem, Sun should use native addresses for infrastructure, and 6to4 just for the "point-to-point links" betweent the sites (think of BGP tunneling except replace BGP with 6to4). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 20 17:53:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04105 for ; Wed, 20 Nov 2002 17:53:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Edlh-000DPE-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 14:56:25 -0800 Received: from mail-out1.apple.com ([17.254.0.52]) by psg.com with esmtp (Exim 3.36 #2) id 18Edle-000DP1-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 14:56:22 -0800 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gAKMuLw23669 for ; Wed, 20 Nov 2002 14:56:22 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 20 Nov 2002 14:56:02 -0800 Received: from [204.42.65.123] (vpn-scv-x3-98.apple.com [17.219.194.98]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gAKMuHu12215; Wed, 20 Nov 2002 14:56:17 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 20 Nov 2002 14:56:15 -0800 Subject: Re: 6to4 security questions From: Laurent Dumont To: Jeroen Massar , Message-ID: In-Reply-To: <001001c290e2$f13ab3c0$210d640a@unfix.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_ENTOURAGE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 11/20/02 14:19, Jeroen Massar at jeroen@unfix.org wrote: > Laurent Dumont wrote: > >> We're planning to offer 6to4 as an auto configured fallback >> for getting home >> Mac users on IPv6. This of course if we don't get a RA and >> only in the case we're the Mac is not behind a NAT... But that's > another issue. > > I think that making that a default option will lead into _many_ helpdesk > phonecalls. > The actual upstream ISP will get phonecalls like: > "www.example.org doesn't work" That raises another issue which was briefly stated this morning in one of the presentation about getaddrinfo and the address selection process. Does it make sense at this point for a web browser sitting on a dual stack implementation to try the AAAA address first, maybe wait 75 seconds to timeout because the DNS the v6 host is declared in DNS but not reachable along the path and then try the A record over v4? I don't think that's really a good user experience, but I haven't seen anything that could prevent this to happen right now. > > Even though the upstream (ISP) can reach it quite well over IPv4. > Ofcourse one will have IPv6 -> IPv4 fallback. But the latency for > falling > back will be quite big. Also note that, unless 6to4 relays suddenly pop > out > of nowhere, the traffic of these users will go through a couple of > different > countries without the user probably wanting it. > > It would be a good thing to do to 'force' upstreams to get IPv6 in their > networks. > But I really don't think it will scale and it will deliver a load of > headaches. > If you added this option as an option in the network settings with a big > help doc > alongside with it describing the problems which could arise this would > be great. > "Go to network config and hit that 'enable 6to4' button to enable it" or > something > similar. A warning on a non-responded RA could also be a good idea but > one has > to remember that most users will blindly click "Yes" on most forms they > don't understand. > > People really wanting IPv6 will get it from their upstream or a > transitional method > and they can pick out of a lot: 6to4, configured using a tunnelbroker or > their upstream. > Note also that current tunnelbroker systems have quite intuitive > websites and for example > freenet6 delivers an automatic configuration tool. > At least then they will be begging their upstream to get it supported :) > Maybe that's a way to get ISPs to move on and provide direct IPv6 support, for us the clear identified reason to use IPv6 vs IPv4 is a restored peer to peer connectivity, even if it has to go through something like 6to4. I think everybody agrees that the best way would be native IPv6 support by the ISPs, but I don't see the incentive for them to move until apps are deployed. --Laurent > Greets, > Jeroen > > From owner-v6ops@ops.ietf.org Wed Nov 20 18:07:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04373 for ; Wed, 20 Nov 2002 18:07:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EdyS-000EFk-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 15:09:36 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18EdyP-000EFX-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 15:09:33 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 89BAF7E2B; Thu, 21 Nov 2002 00:09:53 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 796637C9A; Thu, 21 Nov 2002 00:09:47 +0100 (CET) From: "Jeroen Massar" To: "'Joshua Graessley'" , Subject: RE: 6to4 security questions Date: Thu, 21 Nov 2002 00:10:01 +0100 Organization: Unfix Message-ID: <001801c290e9$f4795fd0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA04373 Joshua Graessley wrote: > On Wednesday, November 20, 2002, at 01:08 PM, Tim Chown wrote: > > > On Wed, Nov 20, 2002 at 08:48:45PM +0100, Jeroen Massar wrote: > >> > >> Currently in europe, at least, there are only a few 6to4 relays: > >> - Switch > >> - Cybernet > >> - Funet > > > I see only one compelling reason to use IPv6 instead of IPv4, and > that's end to end connectivity (no NATs). The problem is, developers > are not going to deploy an IPv6 application if there are no clients > that have IPv6 addresses. Until there are applications that support > IPv6 and don't work over IPv4, there will be no demand for IPv6. Microsoft will be releasing many tools, which currently use IPv4, with IPv6 support. At least that's what their program manager said :) Application vs Network is ofcourse a very big chicken and egg problem and one has to push it from both sides. Many freesoftware programmers fortunatly realise this and are doing the right thing(tm). One 'killer' program will certainly be a videoconferencing tool. Say Netmeeting but then IPv6 capable. Another one will ofcourse be a Peer to Peer application where people can transfer their files. I am currently seeing a move to IPv6 support on news servers which is a good thing as it is a huge amount of data every day. Xs4all even have their big (2Tb or something) news server open for the public. (news://newszilla6.xs4all.nl). > If the transition to IPv6 relies on ISPs making a > multi-billion dollar gamble that deploying IPv6 without any customer demand will pay off, > IPv6 will never be widely deployed. Tunnel brokers don't > scale, unless they charge. If they charge, only corporations and the few > individuals that care enough will have IPv6 connectivity. IMHO Tunnel brokers _will_ and can scale well of correctly built ofcourse. Both freenet6 (www.freenet6.net) and XS26 (www.xs26.net) have many (10K+) users who apparently are quite content with it. I personally can vouch for the system called SixXS built by Pim van Pelt and myself which is an evolvement of the IPng (www.ipng.nl) tunnelbroker. See http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-i pv6-ipng for the presentation given at RIPE42 in short: The SixXS (www.sixxs.net) system is a whitelabeled tunnelbroker, giving ISP's the opportunity to setup a private (for ISP own use) or public POP managed by a console, webinterface or using a custom interface which can very easily be attached to the current system. Currently this system is in use by 5 ISP's who have their own POP: .nl: AMS-IX, Concepts, IPng .de: Cybernet AG .ie: HEAnet The AMS-IX POP is currently providing tunnels to ISP's connected to the AMS-IX to help them bootstrap into the IPv6 world, most of them have requested an sTLA from RIPE since we launced it at the AIAD (AMS-IX IPv6 Awareness Day) held last month. An ISP thus can setup tunneling to clients very easily providing IPv6 where native IPv6 isn't possible yet. Check the website for more information. And ofcourse don't hesitate to contact info@sixxs.net ;) Greets, Jeroen From owner-v6ops@ops.ietf.org Wed Nov 20 20:01:34 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06745 for ; Wed, 20 Nov 2002 20:01:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EfkF-000LXI-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 17:03:03 -0800 Received: from mail-out1.apple.com ([17.254.0.52]) by psg.com with esmtp (Exim 3.36 #2) id 18Efk8-000LUq-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 17:02:56 -0800 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gAL12rw17736 for ; Wed, 20 Nov 2002 17:02:53 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 20 Nov 2002 17:02:53 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id gAL12qp19573 for ; Wed, 20 Nov 2002 17:02:52 -0800 (PST) Date: Wed, 20 Nov 2002 17:02:52 -0800 Subject: Re: 6to4 security questions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) From: Joshua Graessley To: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <001801c290e9$f4795fd0$210d640a@unfix.org> Message-Id: X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, November 20, 2002, at 03:10 PM, Jeroen Massar wrote: > Microsoft will be releasing many tools, which currently use IPv4, with > IPv6 support. > At least that's what their program manager said :) > > Application vs Network is ofcourse a very big chicken and egg problem > and one has to push it from both sides. Many freesoftware programmers > fortunatly realise this and are doing the right thing(tm). > > One 'killer' program will certainly be a videoconferencing tool. > Say Netmeeting but then IPv6 capable. Another one will ofcourse be > a Peer to Peer application where people can transfer their files. > > I am currently seeing a move to IPv6 support on news servers which is > a good thing as it is a huge amount of data every day. Xs4all even have > their big (2Tb or something) news server open for the public. > (news://newszilla6.xs4all.nl). So if something works over IPv4 and IPv6, and I've already got IPv4, why would I worry about getting IPv6 connectivity? A game developer certainly has a compelling reason to use IPv6. Instead of supporting a massive server with a huge pipe, the developer could use a small server that allows gamers to find each other. All of the traffic could be sent directly between the peers with IPv6. A game developer can not deploy an application that relies on IPv6 because it isn't widely deployed. They could develop a protocol for communicating over IPv4 if IPv6 isn't present, but then IPv4 nodes couldn't play with IPv6 nodes. As a game developer, I would write only the IPv4 code. There is no incentive to develop an IPv6 only application. This is a chicken and egg problem. That is why transition tools are important. Apple could develop and ship a system that implemented 6to4 and shipworm/teredo to fall back on when IPv6 wasn't immediately available. Apple could also ship an application that made use of IPv6. Microsoft is in a similar position. Once that's done, third party developers can take advantage of that, assuming all of the transition mechanisms work. Shooting down 6to4 eliminates one transition mechanism. Not even acknowledging Teredo is another shot at transition. Pointing us at configured tunnels as a solution to deploying IPv6 to our customers is not a reasonable solution. If Apple and Microsoft ship their next releases configured to automatically use one of the free tunnel brokers, overnight that service will be barraged with millions of requests and probably become unusable. The only reason those services are available for free and work is because the vast majority of people don't know about them or don't care. >> If the transition to IPv6 relies on ISPs making a >> multi-billion dollar gamble that deploying IPv6 without any customer > demand will pay off, >> IPv6 will never be widely deployed. Tunnel brokers don't >> scale, unless they charge. If they charge, only corporations and the > few >> individuals that care enough will have IPv6 connectivity. > > IMHO Tunnel brokers _will_ and can scale well of correctly built > ofcourse. > Both freenet6 (www.freenet6.net) and XS26 (www.xs26.net) have many > (10K+) > users who apparently are quite content with it. Will it scale to millions? Who's going to pay for all that bandwidth? These solutions are only used by enthusiast. As long as that's the case, they will continue to work. These solutions will not work for a wide deployment of IPv6. Without a wide deployment, no applications, and no demand for IPv6. No solution to the chicken and egg problem. -josh P.S. I'd like to apologize to SBC, I know there are some smart people there that are interested in IPv6, I just don't think the company's management is likely to approve spending money on deploying IPv6. From owner-v6ops@ops.ietf.org Wed Nov 20 20:17:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07106 for ; Wed, 20 Nov 2002 20:17:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Efzi-000MYU-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 17:19:02 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18Efzf-000MXc-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 17:19:00 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gAL1Itm22657; Thu, 21 Nov 2002 02:18:55 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gAL1Iute036858; Thu, 21 Nov 2002 02:18:56 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211210118.gAL1Iute036858@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: 6to4 relay deployment [Re: 6to4 security questions] In-reply-to: Your message of Wed, 20 Nov 2002 23:57:28 +0200. Date: Thu, 21 Nov 2002 02:18:56 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: How do you know? => traceroute 192.88.99.x and traceroute6 2002:x:y:z:... Perhaps they do have them, but aren't advertising them to the internet => they don't advertise them to me so they are not available to me. Something amazing is I got the same relay for 192.88.99.1 from here (Atlanta) and from my office in France... P.S. We do advertise both 192.88.99.0/24 and 2002::/16 everywhere. => obviously they don't reach or Atlanta or Brittany... Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Wed Nov 20 20:39:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07712 for ; Wed, 20 Nov 2002 20:39:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EgLc-000O7x-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 17:41:40 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EgLZ-000O7a-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 17:41:38 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAL1fRC16588; Thu, 21 Nov 2002 03:41:27 +0200 Date: Thu, 21 Nov 2002 03:41:25 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: v6ops@ops.ietf.org Subject: Re: 6to4 relay deployment [Re: 6to4 security questions] In-Reply-To: <200211210118.gAL1Iute036858@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 21 Nov 2002, Francis Dupont wrote: > In your previous mail you wrote: > > How do you know? > > => traceroute 192.88.99.x and traceroute6 2002:x:y:z:... That's only one part of the answer: public relays, or relays in the network you're visiting. There could be hundreds of relays out there. The only way to measure that would be to run some logging on a 6to4 router -- check which addresses packets tunneled to come from 2001/3ffe come from (and take out the spoofs). > Perhaps they do have them, but aren't advertising them > to the internet > > => they don't advertise them to me so they are not available to me. > Something amazing is I got the same relay for 192.88.99.1 from here > (Atlanta) and from my office in France... > > P.S. We do advertise both 192.88.99.0/24 and 2002::/16 everywhere. > > => obviously they don't reach or Atlanta or Brittany... You're sitting in a wrong network :-). Try e.g. from somewhere Abilene. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 20 20:51:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07834 for ; Wed, 20 Nov 2002 20:51:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EgWR-000Oqn-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 17:52:51 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 18EgWP-000Oq0-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 17:52:49 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA09222; Wed, 20 Nov 2002 17:52:19 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAL1qIE18484; Wed, 20 Nov 2002 17:52:18 -0800 X-mProtect: <200211210152> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.193.188, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3o9xNZ; Wed, 20 Nov 2002 17:52:15 PST Message-ID: <3DDC3C4B.9010801@iprg.nokia.com> Date: Wed, 20 Nov 2002 17:52:11 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: v6ops@ops.ietf.org Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-01.txt References: <20021120171900.A27327@sverresborg.uninett.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.3 required=5.0 tests=MAILTO_TO_SPAM_ADDR,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, I liked the suggestion of 1380 bytes for the MTU when dynamic tunnel configuration is not used. I believe this also requires an MRU of at least 1400 bytes in the receiver, however. Does this require any sync-up with the IPv6 node requirements draft? The text there says: "If Path MTU Discovery is not implemented then the sending packet size is limited to 1280 octets ..." We would like to be able to cite [MECH](bis) out of the next version of the ISATAP draft. Do you have any timeframe for making the changes? Fred Templin osprey67@yahoo.com From owner-v6ops@ops.ietf.org Wed Nov 20 20:51:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07851 for ; Wed, 20 Nov 2002 20:51:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EgXf-000OuB-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 17:54:07 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18EgXd-000Otx-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 17:54:05 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gAL1rwm22930; Thu, 21 Nov 2002 02:53:58 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gAL1rwte036975; Thu, 21 Nov 2002 02:53:58 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211210153.gAL1rwte036975@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Alain Durand , Erik Nordmark , Jason Goldschmidt , v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-reply-to: Your message of Thu, 21 Nov 2002 00:41:55 +0200. Date: Thu, 21 Nov 2002 02:53:58 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > => this is the solution for the home address option similar issue > (the option is checked against the binding cache, i.e., is validated > only when two-way communication is used). The amount of harm one can do is similar, but the model seems otherwise a bit different. Mobile nodes _were able to_ (speaking about the old spec where unverified HAO was still ok) communicate without HAO's. Your regular honest 6to4 node can't as it's its only address; they have no care-of addresses for bootstrapping, regular/no-frills operation, etc. => I don't buy this argument: 6to4 is not the only transition technology. Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Wed Nov 20 21:18:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08614 for ; Wed, 20 Nov 2002 21:18:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Egwy-0000pn-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 18:20:16 -0800 Received: from web13005.mail.yahoo.com ([216.136.174.15]) by psg.com with smtp (Exim 3.36 #2) id 18Egwt-0000oz-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 18:20:11 -0800 Message-ID: <20021121022007.19851.qmail@web13005.mail.yahoo.com> Received: from [192.100.124.219] by web13005.mail.yahoo.com via HTTP; Wed, 20 Nov 2002 18:20:07 PST Date: Wed, 20 Nov 2002 18:20:07 -0800 (PST) From: Fred Templin Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-01.txt To: v6ops@ops.ietf.org In-Reply-To: <3DDC3C4B.9010801@iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=1.3 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,MAILTO_TO_SPAM_ADDR, SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Harald, You made some comment during the v6ops meeting this AM regarding an "interesting" draft. Could you be referring to this one: http://www.ietf.org/internet-drafts/draft-templin-v6v4-ndisc-01.txt The main idea is to have an after-market deployable mechanism that can allow automatic tunnel encapsulators/decapsulators to participate in path MTU discovery. The mechanism detects whether both ends are participating in the protocol and only runs if the handshake is completed. The penalty is extra state for neighbor cache entries, which presents a scaling issue for routers - but one that I think can be quantified. I'd be happy to have some comments on the draft, Fred Templin osprey67@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-v6ops@ops.ietf.org Wed Nov 20 21:38:34 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09230 for ; Wed, 20 Nov 2002 21:38:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EhGN-0002Ev-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 18:40:19 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #2) id 18EhGK-0002Ac-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 18:40:16 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06622; Wed, 20 Nov 2002 18:39:45 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAL2dfH18865; Thu, 21 Nov 2002 03:39:42 +0100 (MET) Date: Thu, 21 Nov 2002 03:36:30 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-01.txt To: "Fred L. Templin" Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3DDC3C4B.9010801@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I liked the suggestion of 1380 bytes for the MTU when dynamic tunnel > configuration > is not used. I believe this also requires an MRU of at least 1400 bytes > in the receiver, > however. Does this require any sync-up with the IPv6 node requirements > draft? The > text there says: > > "If Path MTU Discovery is not implemented then the sending packet size is > limited to 1280 octets ..." That is an orthogonal issue. An IPv6 sender that doesn't perform path MTU discovery will only send <=1280 bytes as you point out, but the IPv4 reassembly buffer size of the receiver on a tunnel decapsulator is merely a function of how the IPv6-in-IPv4 tunneling is done. > We would like to be able to cite [MECH](bis) out of the next version of the > ISATAP draft. Do you have any timeframe for making the changes? I'd like to get it done in a month. Erik From owner-v6ops@ops.ietf.org Wed Nov 20 21:45:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09335 for ; Wed, 20 Nov 2002 21:45:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EhND-0002iB-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 18:47:23 -0800 Received: from imo-d10.mx.aol.com ([205.188.157.42]) by psg.com with esmtp (Exim 3.36 #2) id 18EhNB-0002hV-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 18:47:21 -0800 Received: from MicklesCK@aol.com by imo-d10.mx.aol.com (mail_out_v34.13.) id i.169.1760e32b (5711) for ; Wed, 20 Nov 2002 21:46:42 -0500 (EST) Received: from pcsn630877 ([10.0.198.43]) by air-id04.mx.aol.com (v89.12) with ESMTP id MAILINID44-1120214641; Wed, 20 Nov 2002 21:46:41 -0500 Reply-To: From: "Cleve Mickles" To: "V6ops" Subject: ISP Cases Draft: Which sections have too much information? Date: Wed, 20 Nov 2002 21:46:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_00_01,TO_LOCALPART_EQ_REAL,USER_AGENT_OUTLOOK version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From the WG meeting today there was consensus that there was too much information in the draft. Can we get specific feedback on which sections should be paired back? http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-02.txt Thanks, Cleve.... Cleve Mickles America Online, Network Operations From owner-v6ops@ops.ietf.org Wed Nov 20 22:08:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09790 for ; Wed, 20 Nov 2002 22:08:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ehk3-0004Qd-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 19:10:59 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 18Ehk1-0004Ma-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 19:10:57 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA12520; Wed, 20 Nov 2002 19:10:26 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAL3AQn11421; Wed, 20 Nov 2002 19:10:26 -0800 X-mProtect: <200211210310> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.193.188, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdF8wcgM; Wed, 20 Nov 2002 19:10:22 PST Message-ID: <3DDC4E9A.3060209@iprg.nokia.com> Date: Wed, 20 Nov 2002 19:10:18 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: v6ops@ops.ietf.org Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-01.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.9 required=5.0 tests=EMAIL_ATTRIBUTION,MAILTO_TO_SPAM_ADDR,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>I liked the suggestion of 1380 bytes for the MTU when dynamic tunnel >>configuration >>is not used. I believe this also requires an MRU of at least 1400 bytes >>in the receiver, >>however. Does this require any sync-up with the IPv6 node requirements >>draft? The >>text there says: >> >> "If Path MTU Discovery is not implemented then the sending packet size is >> limited to 1280 octets ..." >> >> > >That is an orthogonal issue. >An IPv6 sender that doesn't perform path MTU discovery will only send <=1280 >bytes as you point out, but the IPv4 reassembly buffer size of >the receiver on a tunnel decapsulator is merely a function of how >the IPv6-in-IPv4 tunneling is done. > Yes - unless a dynamic mechanism is used. >>We would like to be able to cite [MECH](bis) out of the next version of the >>ISATAP draft. Do you have any timeframe for making the changes? >> >> > >I'd like to get it done in a month. > This might be too late for us to get ISATAP ready for last call. We may decide to continue to work the issue out of our document for now. But, I believe we have sufficient flexibility around the minimum sizing to acommodate extra layers of encapsulation, e.g., VPN. Thanks, Fred Templin osprey67@yahoo.com From owner-v6ops@ops.ietf.org Wed Nov 20 23:25:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11390 for ; Wed, 20 Nov 2002 23:25:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EivP-0009Xl-00 for v6ops-data@psg.com; Wed, 20 Nov 2002 20:26:47 -0800 Received: from web13007.mail.yahoo.com ([216.136.174.17]) by psg.com with smtp (Exim 3.36 #2) id 18EivJ-0009XX-00 for v6ops@ops.ietf.org; Wed, 20 Nov 2002 20:26:41 -0800 Message-ID: <20021121042641.52555.qmail@web13007.mail.yahoo.com> Received: from [192.100.124.219] by web13007.mail.yahoo.com via HTTP; Wed, 20 Nov 2002 20:26:41 PST Date: Wed, 20 Nov 2002 20:26:41 -0800 (PST) From: Fred Templin Subject: my notes from today's v6ops session To: v6ops@ops.ietf.org Cc: osprey67@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=1.7 required=5.0 tests=FROM_ENDS_IN_NUMS,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk V6ops meeting minutes *************************** 1) Unmanaged networks (Christian Huitema) - privacy analysis - privacy addressing issues for various environment; BCP document needed - better NAT-PT needed - reserved prefix in IPv6? - mapping of IPv4 to IPv6 by V6-only host - v6-only to v4 netwoks? - Comments: - keep things simple so that operators can deploy easily - Teredo too complex - micro-optimizaions needed - too complex for corporate LAN mgr. - can tunnel broker be used to cross the NAT? 2) ISP - Cleve Mickles: - multi-homng; address management - overlap with enterprise/managed space? - new name: home networking to broadband ether - public wireless LAN - infrastructure svcs - Itojun comment: - multihoming is issue for enterprise - assigned addresses? 3) Enterprise/managed - Yanick Pouffary: - new mailing list - solutions will be part of a seperate document - network connected to an Internet provider? - Comment: - draft needs more text to define scope - business requirements may drive IPv6 decision - S/W transition points - DNS routing - address plan - network mgmt - IPv6 address scoping - Comments: - one enterprise (at least) has deplloyed v6 - real deployment carries more weight - doesn't like he idea of using vendors' input (wants input from someone like GM) - doesn't like the term IPv6 NAT 5) V6ops-3GPP - Jonne S. - V6ops 3GPP design team - scenarios doc WG item - seems stable - analysis doc - editorial changes - static vs. dynamic tunneling - NAT-PT vs. NAT-64 - Scenarios: - dual-stack IMS scenario - Jonne: IPv6-only IMSs - Analysis: need to mention dual-stack CSCF in 4.2 - WG last call for scenarios - WG draft for analysis - accept as WG item? - NAT-PT issues: - NAT-PT needed for IPv6-only nodes - Should only be used in stub networks? - numerous comments on whether a NAT-PT solution can be made to work at all. This is a matter of possible concern for the IPv6-only terminal 6) RFC 2893(bis) - dynamic tunnel interface MTU - 1380 bytes proposed for MTU when tunnel not dynamically config'd (DF bit not set) - (1380 = VPN MTU - 20 for IP) - reassembly buffers NOT 64K; 4400 is Erik's pick for now - ingress filtering? 7) 6to4 Security Considerations (Pekka Savola) - spec is very terse - automatic tunneling mechanisms used in same box - relay spoofing; anyone can spoof 2001::/16 addr's pretending to come from relay - relays use RFC 3068 as their source address 8) Harald Alvestrand - v6ops group closing - what to do with NGTRANS drafts? - ask for experimental status? - go to ADs and ask for stds track? - aspects of transition were mis-managed - "circuit switching in an alternate reality"? __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-v6ops@ops.ietf.org Thu Nov 21 07:56:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29955 for ; Thu, 21 Nov 2002 07:55:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EqrO-000DUQ-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 04:55:10 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18EqrM-000DU1-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 04:55:08 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03045; Thu, 21 Nov 2002 05:55:03 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gALCt0H06389; Thu, 21 Nov 2002 13:55:01 +0100 (MET) Date: Thu, 21 Nov 2002 13:51:48 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-v2-01.txt To: "Fred L. Templin" Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3DDC4E9A.3060209@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >That is an orthogonal issue. > >An IPv6 sender that doesn't perform path MTU discovery will only send <=1280 > >bytes as you point out, but the IPv4 reassembly buffer size of >the > receiver on a tunnel decapsulator is merely a function of how >the > IPv6-in-IPv4 tunneling is done. > > Yes - unless a dynamic mechanism is used. My point about orthogonality holds even if a dynamic tunnel MTU is in use. Erik From owner-v6ops@ops.ietf.org Thu Nov 21 07:58:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29991 for ; Thu, 21 Nov 2002 07:58:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Eqwt-000DjL-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 05:00:51 -0800 Received: from web13008.mail.yahoo.com ([216.136.174.18]) by psg.com with smtp (Exim 3.36 #2) id 18Eqwn-000Dj2-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 05:00:45 -0800 Message-ID: <20021121130041.19107.qmail@web13008.mail.yahoo.com> Received: from [63.78.179.4] by web13008.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 05:00:41 PST Date: Thu, 21 Nov 2002 05:00:41 -0800 (PST) From: Fred Templin Subject: isatap-07 draft offered as last-call To: v6ops@ops.ietf.org Cc: osprey67@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=2.4 required=5.0 tests=FROM_ENDS_IN_NUMS,MAILTO_TO_SPAM_ADDR,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, As per Harald Alvestrand's message "On NGTRANS, transition mechanisms and consortia", I would like to offer the current isatap version as immediate last-call candidate for experimental track. The document can be found at: http://www.geocities.com/osprey67/isatap-07.txt Fred Templin osprey67@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-v6ops@ops.ietf.org Thu Nov 21 08:28:43 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01298 for ; Thu, 21 Nov 2002 08:28:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ErO8-000FHQ-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 05:29:00 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18ErO6-000FHD-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 05:28:58 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gALDSra21921; Thu, 21 Nov 2002 15:28:53 +0200 Date: Thu, 21 Nov 2002 15:28:53 +0200 (EET) From: Pekka Savola To: Fred Templin cc: v6ops@ops.ietf.org Subject: Re: isatap-07 draft offered as last-call In-Reply-To: <20021121130041.19107.qmail@web13008.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 21 Nov 2002, Fred Templin wrote: > As per Harald Alvestrand's message "On NGTRANS, transition mechanisms and consortia", > I would like to offer the current isatap version as immediate last-call candidate for > experimental track. The document can be found at: > > http://www.geocities.com/osprey67/isatap-07.txt Please be specific what you mean. I took Harald's message as to signify "you can always submit a draft for experimental as an individual submission". It's not clear to me whether you interpreted it as something else (like, wg can automatically adjust the charter to accept documents to be published as experimental). btw. the draft does not mention there have been IPR claims. IMO it's a good practise to state that. btw.2. security considerations wrt. disclosing the potentially NAT'ed addresses is still not mentioned. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 08:49:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01994 for ; Thu, 21 Nov 2002 08:49:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EriY-000GZh-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 05:50:06 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EriV-000GYl-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 05:50:03 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gALDnrN22099; Thu, 21 Nov 2002 15:49:53 +0200 Date: Thu, 21 Nov 2002 15:49:53 +0200 (EET) From: Pekka Savola To: Fred Templin cc: v6ops@ops.ietf.org Subject: Re: isatap-07 draft offered as last-call In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 21 Nov 2002, Pekka Savola wrote: > > http://www.geocities.com/osprey67/isatap-07.txt > > btw. the draft does not mention there have been IPR claims. IMO it's a > good practise to state that. Sorry, I missed it completely as it was so far down after the appendices and there is no table-of-contents. The statement itself appears to be fine. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 09:03:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02357 for ; Thu, 21 Nov 2002 09:03:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Eruc-000HFq-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 06:02:34 -0800 Received: from web13001.mail.yahoo.com ([216.136.174.11]) by psg.com with smtp (Exim 3.36 #2) id 18EruZ-000HF7-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 06:02:31 -0800 Message-ID: <20021121140230.95412.qmail@web13001.mail.yahoo.com> Received: from [63.78.179.4] by web13001.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 06:02:30 PST Date: Thu, 21 Nov 2002 06:02:30 -0800 (PST) From: Fred Templin Subject: Re: isatap-07 draft offered as last-call To: Pekka Savola Cc: v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.2 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --- Pekka Savola wrote: > On Thu, 21 Nov 2002, Fred Templin wrote: > > As per Harald Alvestrand's message "On NGTRANS, transition mechanisms and consortia", > > I would like to offer the current isatap version as immediate last-call candidate for > > experimental track. The document can be found at: > > > > http://www.geocities.com/osprey67/isatap-07.txt > > Please be specific what you mean. > > I took Harald's message as to signify "you can always submit a draft for > experimental as an individual submission". Specifically, Harald's message states: > There are several ways around this if you want things published: > - Publish through other mechanisms than the RFC process > - Publish as Experimental RFC > - Plead with the ADs to sponsor the mechanisms for standards track based on their obvious merits (identifying the mechanisms they obsolete) Thus, I am seeking to publish as an Experimental RFC and also pleading with the ADs to sponsor the mechanism for standards track based on obsoleting RFC 2529 (6over4). > It's not clear to me whether you interpreted it as something else (like, > wg can automatically adjust the charter to accept documents to be > published as experimental). > > btw. the draft does not mention there have been IPR claims. IMO it's a > good practise to state that. > > btw.2. security considerations wrt. disclosing the potentially NAT'ed > addresses is still not mentioned. Thanks, Please upload the new version found at: http://www.geocities.com/osprey67/isatap-07.txt Fred Templin > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com From owner-v6ops@ops.ietf.org Thu Nov 21 09:23:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03835 for ; Thu, 21 Nov 2002 09:23:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EsFN-000IYj-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 06:24:01 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EsFK-000IYW-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 06:23:58 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gALENkB22431; Thu, 21 Nov 2002 16:23:46 +0200 Date: Thu, 21 Nov 2002 16:23:45 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Alain Durand , Erik Nordmark , Jason Goldschmidt , Subject: Re: 6to4 security questions In-Reply-To: <200211210153.gAL1rwte036975@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 21 Nov 2002, Francis Dupont wrote: > The amount of harm one can do is similar, but the model seems otherwise a > bit different. > > Mobile nodes _were able to_ (speaking about the old spec where unverified > HAO was still ok) communicate without HAO's. Your regular honest 6to4 > node can't as it's its only address; they have no care-of addresses for > bootstrapping, regular/no-frills operation, etc. > > => I don't buy this argument: 6to4 is not the only transition technology. Yes, it isn't -- but when 6to4 is used, there are no other, concurrently used transition technologies. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 10:00:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04988 for ; Thu, 21 Nov 2002 10:00:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EspI-000KmW-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 07:01:08 -0800 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #2) id 18Esp6-000KfI-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 07:00:57 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id gALExSJT109364; Thu, 21 Nov 2002 15:59:37 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gALExP71052342; Thu, 21 Nov 2002 15:59:26 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58720 from ; Thu, 21 Nov 2002 15:59:17 +0100 Message-Id: <3DDCF4AE.D6F16937@hursley.ibm.com> Date: Thu, 21 Nov 2002 15:58:54 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Jeroen Massar Cc: "'Laurent Dumont'" , v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: <001001c290e2$f13ab3c0$210d640a@unfix.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=MARKET_SOLUTION,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As I keep having to remind people, 6to4 wasn't designed as a mass market end-host solution, so if you use it for that and have problems, well, I'm not too surprised. Brian Jeroen Massar wrote: > > Laurent Dumont wrote: > > > We're planning to offer 6to4 as an auto configured fallback > > for getting home > > Mac users on IPv6. This of course if we don't get a RA and > > only in the case we're the Mac is not behind a NAT... But that's > another issue. > > I think that making that a default option will lead into _many_ helpdesk > phonecalls. > The actual upstream ISP will get phonecalls like: > "www.example.org doesn't work" > > Even though the upstream (ISP) can reach it quite well over IPv4. > Ofcourse one will have IPv6 -> IPv4 fallback. But the latency for > falling > back will be quite big. Also note that, unless 6to4 relays suddenly pop > out > of nowhere, the traffic of these users will go through a couple of > different > countries without the user probably wanting it. > > It would be a good thing to do to 'force' upstreams to get IPv6 in their > networks. > But I really don't think it will scale and it will deliver a load of > headaches. > If you added this option as an option in the network settings with a big > help doc > alongside with it describing the problems which could arise this would > be great. > "Go to network config and hit that 'enable 6to4' button to enable it" or > something > similar. A warning on a non-responded RA could also be a good idea but > one has > to remember that most users will blindly click "Yes" on most forms they > don't understand. > > People really wanting IPv6 will get it from their upstream or a > transitional method > and they can pick out of a lot: 6to4, configured using a tunnelbroker or > their upstream. > Note also that current tunnelbroker systems have quite intuitive > websites and for example > freenet6 delivers an automatic configuration tool. > At least then they will be begging their upstream to get it supported :) > > Greets, > Jeroen From owner-v6ops@ops.ietf.org Thu Nov 21 10:36:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06730 for ; Thu, 21 Nov 2002 10:36:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EtOh-000N4f-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 07:37:43 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18EtOf-000N4T-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 07:37:41 -0800 Received: from jurassic.eng.sun.com ([129.146.17.55]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24940; Thu, 21 Nov 2002 08:37:41 -0700 (MST) Received: from eng.sun.com (vpn-129-152-201-69.East.Sun.COM [129.152.201.69]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gALFbbbS224799; Thu, 21 Nov 2002 07:37:39 -0800 (PST) Message-ID: <3DDCFD94.9050606@eng.sun.com> Date: Thu, 21 Nov 2002 07:36:52 -0800 From: Jason Goldschmidt User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Templin CC: v6ops@ops.ietf.org Subject: Re: isatap-07 draft offered as last-call References: <20021121130041.19107.qmail@web13008.mail.yahoo.com> In-Reply-To: <20021121130041.19107.qmail@web13008.mail.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,MAILTO_TO_SPAM_ADDR,MEMBER_2, REFERENCES,SPAM_PHRASE_02_03,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Fred Templin wrote: >Hello, > >As per Harald Alvestrand's message "On NGTRANS, transition mechanisms and consortia", >I would like to offer the current isatap version as immediate last-call candidate for >experimental track. The document can be found at: > > http://www.geocities.com/osprey67/isatap-07.txt > >Fred Templin >osprey67@yahoo.com > >__________________________________________________ >Do you Yahoo!? >Yahoo! Mail Plus – Powerful. Affordable. Sign up now. >http://mailplus.yahoo.com > > > Fred, Thank you for providing this updated draft. I have a question regarding text added to section 5.2.4 (Host Specification). This sections says that "Hosts select one and only one member of the PRL ("PRL(i)") and ...". How should this one member be selected from the PRL? A related question, after selecting the one member and RS's sent to this member are not replied, should another member be selected? If so, how long should the host wait before trying a new member? What are the implications of having a PRL with length > 1? Is it that only one entry is used to act as the "active" router and thus the default route, but other entries define policy for receiving packets? An ACL if you will. thanks, -Jason From owner-v6ops@ops.ietf.org Thu Nov 21 10:46:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07053 for ; Thu, 21 Nov 2002 10:46:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EtZn-000Nor-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 07:49:11 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #2) id 18EtZa-000NlM-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 07:48:58 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gALFmEC3031968; Thu, 21 Nov 2002 16:48:14 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gALFmEd1026064; Thu, 21 Nov 2002 16:48:14 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45002 from ; Thu, 21 Nov 2002 16:48:11 +0100 Message-Id: <3DDD0027.B00B6FE9@hursley.ibm.com> Date: Thu, 21 Nov 2002 16:47:51 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Fred Templin Cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: isatap-07 draft offered as last-call References: <20021121140230.95412.qmail@web13001.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit below... Fred Templin wrote: > > --- Pekka Savola wrote: > > On Thu, 21 Nov 2002, Fred Templin wrote: > > > As per Harald Alvestrand's message "On NGTRANS, transition mechanisms and consortia", > > > I would like to offer the current isatap version as immediate last-call candidate for > > > experimental track. The document can be found at: > > > > > > http://www.geocities.com/osprey67/isatap-07.txt > > > > Please be specific what you mean. > > > > I took Harald's message as to signify "you can always submit a draft for > > experimental as an individual submission". > > Specifically, Harald's message states: > > > There are several ways around this if you want things published: > > - Publish through other mechanisms than the RFC process > > - Publish as Experimental RFC > > - Plead with the ADs to sponsor the mechanisms for standards track based on their obvious merits > (identifying the mechanisms they obsolete) > > Thus, I am seeking to publish as an Experimental RFC and also pleading with the ADs to > sponsor the mechanism for standards track based on obsoleting RFC 2529 (6over4). That is egregious and irrelevant. I would object very strongly. 6over4 is is self-contained and there is no reason to couple its future to that of ISATAP. As a matter of fact, 6over4 has no affiliation with either NGTRANS or V6OPS; it was an IPNGWG document and if any WG owns it today, it would be IPV6. 2529 should sleep harmlessly as a Proposed Standard. Its day may come, and it is harmless. Brian From owner-v6ops@ops.ietf.org Thu Nov 21 11:12:03 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08180 for ; Thu, 21 Nov 2002 11:12:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ety6-000PWj-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 08:14:18 -0800 Received: from mail-out2.apple.com ([17.254.0.51]) by psg.com with esmtp (Exim 3.36 #2) id 18Ety1-000PVy-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 08:14:13 -0800 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gALGEAI08728 for ; Thu, 21 Nov 2002 08:14:10 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 21 Nov 2002 08:14:06 -0800 Received: from [204.42.72.166] (vpn-scv-x0-168.apple.com [17.219.192.168]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id gALGE3916906; Thu, 21 Nov 2002 08:14:03 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 21 Nov 2002 08:13:57 -0800 Subject: Re: 6to4 deployement issues - was 6to4 security questions From: Laurent Dumont To: Brian E Carpenter , Jeroen Massar CC: Message-ID: In-Reply-To: <3DDCF4AE.D6F16937@hursley.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-1.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,MARKET_SOLUTION, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_ENTOURAGE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, I know it's not the best solution, but it's the best tool we currently have to give our end nodes sitting at home on a DSL or cable modem an IPv6 address. I'd much rather have the ISPs advertise or delegate a prefix, but realistically it won't happen because they have no incentive to make it happen. In order to boot strap the process and get a wide application deployment, we need some user perceived advantage for IPv6, and peer to peer maybe the way. To get peer to peer to work easily, IPv6 is a good tool, but to get an IPv6 address, 6to4/Teredo seem like the only possible route at this point for a home Mac user. I'm not sure that the relay model will collapse if many 6to4 users are using it, because the reality is that a 6to4 node will most likely be talking to another 6to4 peer and will really not go through any relay for most of its traffic. Why? because there is nothing of interest for them on the 6bone, so that won't change much to the current situation... The alternative, the way I see it, is just to ignore IPv6 for now and wait for providers to wake up one day and magically start giving out IPv6 prefixes. Is that what we want? --Laurent on 11/21/02 06:58, Brian E Carpenter at brian@hursley.ibm.com wrote: > As I keep having to remind people, 6to4 wasn't designed as > a mass market end-host solution, so if you use it for that > and have problems, well, I'm not too surprised. > > Brian From owner-v6ops@ops.ietf.org Thu Nov 21 11:16:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08581 for ; Thu, 21 Nov 2002 11:16:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Eu2g-000PuX-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 08:19:02 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18Eu2d-000Pu8-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 08:18:59 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 7428B7E38; Thu, 21 Nov 2002 17:19:19 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 172827976; Thu, 21 Nov 2002 17:19:13 +0100 (CET) From: "Jeroen Massar" To: "'Brian E Carpenter'" Cc: "'Laurent Dumont'" , Subject: RE: 6to4 security questions Date: Thu, 21 Nov 2002 17:19:28 +0100 Organization: Unfix Message-ID: <000701c29179$c5a488c0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3DDCF4AE.D6F16937@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-1.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,MARKET_SOLUTION,NOSPAM_INC, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA08581 Brian E Carpenter wrote: > As I keep having to remind people, 6to4 wasn't designed as > a mass market end-host solution, so if you use it for that > and have problems, well, I'm not too surprised. Which is exactly what I wanted to point out to Laurent though I did it probably with the wrong wordings ;) I think that 6to4 could work if the upstream ISP delivered the relay. Eg.. the client-machine tries to RA, if unsuccesfull it tries the upstreams 6to4 using the anycast address. The big assumption here is the fact that all upstreams need to either: - have a 6to4 announced to their clients using the anycast address. - block the route to the 6to4 anycast. If neither of these two points are met one will fall back into the scaling problems and will see people using IPv6 over a completely different country. I don't see this as a viable solution though :( Greets, Jeroen > Jeroen Massar wrote: > > > > Laurent Dumont wrote: > > > > > We're planning to offer 6to4 as an auto configured fallback > > > for getting home > > > Mac users on IPv6. This of course if we don't get a RA and > > > only in the case we're the Mac is not behind a NAT... But that's > > another issue. > > > > I think that making that a default option will lead into > _many_ helpdesk > > phonecalls. > > The actual upstream ISP will get phonecalls like: > > "www.example.org doesn't work" > > > > Even though the upstream (ISP) can reach it quite well over IPv4. > > Ofcourse one will have IPv6 -> IPv4 fallback. But the latency for > > falling > > back will be quite big. Also note that, unless 6to4 relays > suddenly pop > > out > > of nowhere, the traffic of these users will go through a couple of > > different > > countries without the user probably wanting it. > > > > It would be a good thing to do to 'force' upstreams to get > IPv6 in their > > networks. > > But I really don't think it will scale and it will deliver a load of > > headaches. > > If you added this option as an option in the network > settings with a big > > help doc > > alongside with it describing the problems which could arise > this would > > be great. > > "Go to network config and hit that 'enable 6to4' button to > enable it" or > > something > > similar. A warning on a non-responded RA could also be a > good idea but > > one has > > to remember that most users will blindly click "Yes" on > most forms they > > don't understand. > > > > People really wanting IPv6 will get it from their upstream or a > > transitional method > > and they can pick out of a lot: 6to4, configured using a > tunnelbroker or > > their upstream. > > Note also that current tunnelbroker systems have quite intuitive > > websites and for example > > freenet6 delivers an automatic configuration tool. > > At least then they will be begging their upstream to get it > supported :) > > > > Greets, > > Jeroen > > > From owner-v6ops@ops.ietf.org Thu Nov 21 12:23:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11328 for ; Thu, 21 Nov 2002 12:23:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ev0K-0004FY-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 09:20:40 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #2) id 18Ev0I-0004AU-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 09:20:38 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gALF8UC3007466; Thu, 21 Nov 2002 16:08:43 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gALF8K71094740; Thu, 21 Nov 2002 16:08:21 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA67534 from ; Thu, 21 Nov 2002 16:08:09 +0100 Message-Id: <3DDCF6C3.C89153B@hursley.ibm.com> Date: Thu, 21 Nov 2002 16:07:47 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Francis Dupont Cc: Alain Durand , Erik Nordmark , Jason Goldschmidt , Pekka Savola , v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: <200211202228.gAKMS0te036273@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > In your previous mail you wrote: > > There are in my opinion 4 ways forward: > > 1- Revisit 6to4 architecture to have bi-directional communication > between the 6to4 router and the 6to4 relay. That way the decapsulating > 6to4 router could apply some checks and make sure packets are comming > from a legitimate 6to4 relay. > > => this is the solution for the home address option similar issue > (the option is checked against the binding cache, i.e., is validated > only when two-way communication is used). Actually, what is wrong with the model in bullet 2.2 of section 5.2 of RFC 3056, i.e. require a BGP4+ peer relationship between a 6to4 router and the 6to4 relay routers it deals with? (OK, I can see some reachability issues but 6to4 is not supposed to be the universal answer.) As I said a moment ago, 6to4 wasn't designed for end hosts. I've always felt the BGP4+ scenario was the best one. Brian From owner-v6ops@ops.ietf.org Thu Nov 21 12:24:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11398 for ; Thu, 21 Nov 2002 12:24:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ev6X-0004j2-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 09:27:05 -0800 Received: from web13008.mail.yahoo.com ([216.136.174.18]) by psg.com with smtp (Exim 3.36 #2) id 18Ev6V-0004ip-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 09:27:03 -0800 Message-ID: <20021121172702.94889.qmail@web13008.mail.yahoo.com> Received: from [204.42.68.8] by web13008.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 09:27:02 PST Date: Thu, 21 Nov 2002 09:27:02 -0800 (PST) From: Fred Templin Subject: Re: isatap-07 draft offered as last-call To: Jason Goldschmidt Cc: v6ops@ops.ietf.org In-Reply-To: <3DDCFD94.9050606@eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=1.1 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,MAILTO_TO_SPAM_ADDR,MEMBER_2, QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jason, Thanks for the comments. I can see the points where clarification is needed. For an ACL function, we would like some indication that the other entries in the list share the same trust model and the PRL provides this. Administratively this works out. But, if we're not actively polling the routers we have no prefix and/or default router lifetime information from them. Thus, we need to stick with the one we are polling and autoconfig addresses only from it. I'll make sure this is made clear in the text. Thanks, Fred ftemplin@iprg.nokia.com --- Jason Goldschmidt wrote: > Fred Templin wrote: > > >Hello, > > > >As per Harald Alvestrand's message "On NGTRANS, transition mechanisms and consortia", > >I would like to offer the current isatap version as immediate last-call candidate for > >experimental track. The document can be found at: > > > > http://www.geocities.com/osprey67/isatap-07.txt > > > >Fred Templin > >osprey67@yahoo.com > > > >__________________________________________________ > >Do you Yahoo!? > >Yahoo! Mail Plus – Powerful. Affordable. Sign up now. > >http://mailplus.yahoo.com > > > > > > > Fred, > > Thank you for providing this updated draft. > > I have a question regarding text added to section 5.2.4 (Host > Specification). This sections says that "Hosts select one and only one > member of the PRL ("PRL(i)") and ...". How should this one member be > selected from the PRL? > > A related question, after selecting the one member and RS's sent to this > member are not replied, should another member be selected? If so, how > long should the host wait before trying a new member? > > What are the implications of having a PRL with length > 1? Is it that > only one entry is used to act as the "active" router and thus the > default route, but other entries define policy for receiving packets? An > ACL if you will. > > thanks, > > -Jason > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-v6ops@ops.ietf.org Thu Nov 21 12:29:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11597 for ; Thu, 21 Nov 2002 12:29:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EvAl-00054u-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 09:31:27 -0800 Received: from web13008.mail.yahoo.com ([216.136.174.18]) by psg.com with smtp (Exim 3.36 #2) id 18EvAh-00054R-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 09:31:24 -0800 Message-ID: <20021121173123.96086.qmail@web13008.mail.yahoo.com> Received: from [204.42.68.8] by web13008.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 09:31:23 PST Date: Thu, 21 Nov 2002 09:31:23 -0800 (PST) From: Fred Templin Subject: Re: isatap-07 draft offered as last-call To: Brian E Carpenter Cc: Pekka Savola , v6ops@ops.ietf.org In-Reply-To: <3DDD0027.B00B6FE9@hursley.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.1 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Brian, Apologies; I should have checked with you first on this. With the comments received, I intend to revisit the last-call and repost when we have the process and technical details worked out. Fred --- Brian E Carpenter wrote: > below... > > Fred Templin wrote: > > > > --- Pekka Savola wrote: > > > On Thu, 21 Nov 2002, Fred Templin wrote: > > > > As per Harald Alvestrand's message "On NGTRANS, transition mechanisms and consortia", > > > > I would like to offer the current isatap version as immediate last-call candidate for > > > > experimental track. The document can be found at: > > > > > > > > http://www.geocities.com/osprey67/isatap-07.txt > > > > > > Please be specific what you mean. > > > > > > I took Harald's message as to signify "you can always submit a draft for > > > experimental as an individual submission". > > > > Specifically, Harald's message states: > > > > > There are several ways around this if you want things published: > > > - Publish through other mechanisms than the RFC process > > > - Publish as Experimental RFC > > > - Plead with the ADs to sponsor the mechanisms for standards track based on their obvious > merits > > (identifying the mechanisms they obsolete) > > > > Thus, I am seeking to publish as an Experimental RFC and also pleading with the ADs to > > sponsor the mechanism for standards track based on obsoleting RFC 2529 (6over4). > > That is egregious and irrelevant. I would object very strongly. 6over4 is > is self-contained and there is no reason to couple its future to that > of ISATAP. As a matter of fact, 6over4 has no affiliation with either > NGTRANS or V6OPS; it was an IPNGWG document and if any WG owns it > today, it would be IPV6. > > 2529 should sleep harmlessly as a Proposed Standard. Its day may come, and > it is harmless. > > Brian __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-v6ops@ops.ietf.org Thu Nov 21 13:07:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13105 for ; Thu, 21 Nov 2002 13:07:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EvlU-0007n0-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 10:09:24 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EvlR-0007mk-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 10:09:21 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gALI96t24519; Thu, 21 Nov 2002 20:09:06 +0200 Date: Thu, 21 Nov 2002 20:09:06 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Francis Dupont , Alain Durand , Erik Nordmark , Jason Goldschmidt , Subject: Re: 6to4 security questions In-Reply-To: <3DDCF6C3.C89153B@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 21 Nov 2002, Brian E Carpenter wrote: > Actually, what is wrong with the model in bullet 2.2 of section 5.2 > of RFC 3056, i.e. require a BGP4+ peer relationship between a 6to4 > router and the 6to4 relay routers it deals with? (OK, I can see some > reachability issues but 6to4 is not supposed to be the universal answer.) That, in itself, helps little. Relay routers must also be connected using BGP4+ and advertising more specific routes. > As I said a moment ago, 6to4 wasn't designed for end hosts. I've > always felt the BGP4+ scenario was the best one. Well, the reasons 6to4 is used are usualy either/and: 1) ease of taking into use 2) takes dynamic v4 address into account For SOHO/home use, both conditions are usually fulfilled. Also, for bigger enterprise networks, which are usually able to run BGP etc., are only concerned about _at most_ 1). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 13:30:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14601 for ; Thu, 21 Nov 2002 13:30:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ew72-0009Tk-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 10:31:40 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18Ew6y-0009TX-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 10:31:36 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 75C9F7E24; Thu, 21 Nov 2002 19:31:57 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 562C07763; Thu, 21 Nov 2002 19:31:52 +0100 (CET) From: "Jeroen Massar" To: "'Jim Fleming'" Cc: Subject: Jim Fla^Heming's IPv8/IPv16 stupidities (Was: RE: 6to4 deployement issues - was 6to4 security questions) Date: Thu, 21 Nov 2002 19:32:08 +0100 Organization: Unfix Message-ID: <003f01c2918c$4d030e10$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <092c01c2917c$435bff30$b8bf2443@repligate> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-1.4 required=5.0 tests=DEAR_SOMEBODY,EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC, SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim Fleming [mailto:JimFleming@ameritech.net] wrote: > 128-bit DNS AAAA Record Flag Day Formats > 2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 > Persistent Address] > [YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Dear Mister Jim Fleming, You might read up on your IPv8 ideas and check: http://www.iana.org/assignments/version-numbers there you will notice the following piece: 8<------------ Assigned Internet Version Numbers Decimal Keyword Version References ------- ------- ------- ---------- 0 Reserved [JBP] 1-3 Unassigned [JBP] 4 IP Internet Protocol [RFC791,JBP] 5 ST ST Datagram Mode [RFC1190,JWF] 6 IPv6 Internet Protocol version 6 [RFC1752] 7 TP/IX TP/IX: The Next Internet [RXU] 8 PIP The P Internet Protocol [PXF] 9 TUBA TUBA [RXC] 10-14 Unassigned [JBP] 15 Reserved [JBP] ------------>8 IPv8 == PIP (The P internet Protocol), check for instance: http://ntrg.cs.tcd.ie/undergrad/4ba2/ipng/ian.pip.html Quote: "PIP has provider rooted variable length hierarchical addressing. IP has static 32 bit addresses." Thus you are absolutely missing the point with your 64 bits and 128 bits. As for your imaginary IPv16, it won't even fit in the version field. Nor are there any documents to be found about it. Now go make up your own namingscheme, create the documents for the protocols you invented and then submit those to the IETF, which will review them and maybe then you will be taken serious and not taken for the spammer which you currently are. Greets, Jeroen From owner-v6ops@ops.ietf.org Thu Nov 21 14:04:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15842 for ; Thu, 21 Nov 2002 14:04:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ewf0-000C93-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 11:06:46 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18Ewex-000C8o-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 11:06:43 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id A45577E3C; Thu, 21 Nov 2002 20:07:04 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 2831C776D; Thu, 21 Nov 2002 20:06:59 +0100 (CET) From: "Jeroen Massar" To: "'Laurent Dumont'" , "'Brian E Carpenter'" Cc: Subject: RE: 6to4 deployement issues - was 6to4 security questions Date: Thu, 21 Nov 2002 20:07:15 +0100 Organization: Unfix Message-ID: <004701c29191$34c4bfb0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA15842 Laurent Dumont [mailto:laurent@apple.com] wrote: This is more turning into a "How to push IPv6" thread ;) > Brian, > > I know it's not the best solution, but it's the best tool we > currently have to give our end nodes sitting at home on a DSL or cable modem an IPv6 > address. I'd much rather have the ISPs advertise or delegate > a prefix, but realistically it won't happen because they have no incentive > to make it happen. > > In order to boot strap the process and get a wide application > deployment, we need some user perceived advantage for IPv6, and peer to peer > maybe the way. To get peer to peer to work easily, IPv6 is a good tool, but > to get an IPv6 address, 6to4/Teredo seem like the only possible route at > this point for a home Mac user. IMHO most users wanting too use IPv6 _now_ will sign up directly with a tunnelbroker. One will see that signing up using a webinterface is really not that hard. eg: MSN/ICQ/Yahoo//, Most users will work it out quite easily if they know what they want. Unfortunatly there are not many applications that currently support IPv6. And as you and I and some others already said it's a chicken and egg problem ;) Using tools such as provided by freenet6 gives quite a tremendous ease of use. One thing to note is that many commonly-used programs that don't really depend on IPv6 features like security etc are not ported yet either. Even though porting those applications is quite easy, one simply needs to run through Itojun's excelent doc (http://www.kame.net/newsletter/19980604/) And those applications (webbrowsers, email clients, mailservers) will be IPv4 and IPv6 capable. At least this will give webhosters the incentitive to start providing an IPv6 google/altavista/* and more. > I'm not sure that the relay model will collapse if many 6to4 > users are using it, because the reality is that a 6to4 node will most likely > be talking to another 6to4 peer and will really not go through any relay > for most of its traffic. Why? because there is nothing of interest for them > on the 6bone, so that won't change much to the current situation... One should not look at the 6bone, end-user deployment is not experimental nor a test. These should happen in RIR space. > The alternative, the way I see it, is just to ignore IPv6 for > now and wait for providers to wake up one day and magically start giving out IPv6 > prefixes. Is that what we want? No ofcourse not :) Thats why we held the AMS-IX IPv6 Awareness Day to kick a little life into those ISP's, checking the assignment list* one will see that Luna, Cistron, Trueserver, Interned, TooFast, Demon and Hubris all got an allocation because of that event. Hubris even got it working on the same day! RIPE/ARIN/APNIC could pro-actively "spam" their LIR's and push them into the right direction or by organizing IPv6 days like this. Notez bien that the current stats for allocations (see * also) is: RIPE : 132 ARIN : 39 APNIC : 90 Now what really should happen is that the US wakes up :) Where is a company like RoadRunner or many of the other very large US ISP's? Even _if_ there was an ability for people to use 6to4 relays automatically why should they use it if there isn't any content to connect too? And with content I mean simple things which can be easily dual-stacked like: HTTP, SMTP, POP3/IMAP, NNTP, eg the basic services one uses. * = http://www.ripe.net/ipv6/ipv6allocs.html Btw: $ host -t aaaa www.apple.com www.apple.com CNAME www.apple.com.akadns.net www.apple.com.akadns.net AAAA record currently not present $ host -t aaaa www.ipv6.apple.com www.ipv6.apple.com has no AAAA record (Authoritative answer) You could give all those users a 6to4 by default, but then they can't even use the, imho, magnificent trailers part of the apple website over IPv6 ;( Greets, Jeroen PS: before anyone speaks up, indeed unfix.org is v4 only too :( From owner-v6ops@ops.ietf.org Thu Nov 21 14:14:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16268 for ; Thu, 21 Nov 2002 14:14:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ewoy-000Cv8-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 11:17:04 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18Ewov-000Cuk-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 11:17:01 -0800 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25733 for ; Thu, 21 Nov 2002 12:17:01 -0700 (MST) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5X004MZXKCKY@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 12:17:00 -0700 (MST) Received: from sun.com ([204.42.66.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H5X00JQ4XK9OE@mail.sun.net> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 12:17:00 -0700 (MST) Date: Thu, 21 Nov 2002 11:17:03 -0800 From: Alain Durand Subject: Re: 6to4 deployement issues - was 6to4 security questions To: Laurent Dumont Cc: Brian E Carpenter , Jeroen Massar , v6ops@ops.ietf.org Message-id: <3DDD312F.1060605@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_02_03,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Laurent Dumont wrote: >I'm not sure that the relay model will collapse if many 6to4 users are using >it, because the reality is that a 6to4 node will most likely be talking to >another 6to4 peer and will really not go through any relay for most of its >traffic. Why? because there is nothing of interest for them on the 6bone, so >that won't change much to the current situation... > Either you leave the relay model or you remove it. If you leave it as it is, you open serious security issues If you remove relays from the architecture, you create a partition of the Internet. Sure, today there is no content reachable though native IPv6, but one day, there will. That day, you do not want to prevent those gazilliions 6to4 users from reaching it. The only wat forward is either to deprecate 6to4 alltogether (and use another conncetivity for the masses approach until IPv6 ISPs are generally available) or to fix the security problem. My take is go back to the white board and try to fix it. - Alain. From owner-v6ops@ops.ietf.org Thu Nov 21 14:23:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16580 for ; Thu, 21 Nov 2002 14:23:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ewxb-000DeZ-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 11:25:59 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18EwxZ-000DeK-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 11:25:57 -0800 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01260 for ; Thu, 21 Nov 2002 12:25:56 -0700 (MST) Received: from xpa-fe1 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5X00NWXXZ84I@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 12:25:56 -0700 (MST) Received: from sun.com ([204.42.66.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H5X00DP8XZ4N9@mail.sun.net> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 12:25:56 -0700 (MST) Date: Thu, 21 Nov 2002 11:25:58 -0800 From: Alain Durand Subject: Re: isatap-07 draft offered as last-call To: Fred Templin Cc: v6ops@ops.ietf.org Message-id: <3DDD3346.4010401@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: <20021121130041.19107.qmail@web13008.mail.yahoo.com> X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT Fred Templin wrote: >Hello, > >As per Harald Alvestrand's message "On NGTRANS, transition mechanisms and consortia", >I would like to offer the current isatap version as immediate last-call candidate for >experimental track. > I strongly object to the publication of this document. When a node enables an ISATAP link, it initializes the Potential Router List (PRL) for that link. Unless other information is avail­ able (e.g., manual address configuration, a vendor-specific DHCP option, etc.), the DNS SHOULD be consulted (e.g., by resolving the name "isatap.domainname" where "domainname" MUST be relative to the node's physical point of attachment.) a) domainname is a information that is relative to the name space and gives no information whatsoever about the physical location of the machine. For example, at Sun, we use many domains like eng.sun.com, uk.sun.com, east.sun.com.... Some of them a somehow loosely linked to a particular geography (east.sun.com, uk.sun.com) while some other are organisational domains (eng.sun.com) that may span across geography. b) You are using something that does not belong to you. The name isatap could very well have been already assigned in my DNS zone. - Alain. From owner-v6ops@ops.ietf.org Thu Nov 21 14:26:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16681 for ; Thu, 21 Nov 2002 14:26:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ex0J-000DtI-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 11:28:47 -0800 Received: from web13003.mail.yahoo.com ([216.136.174.13]) by psg.com with smtp (Exim 3.36 #2) id 18Ex0G-000Dt4-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 11:28:44 -0800 Message-ID: <20021121192842.58190.qmail@web13003.mail.yahoo.com> Received: from [204.42.68.8] by web13003.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 11:28:42 PST Date: Thu, 21 Nov 2002 11:28:42 -0800 (PST) From: Fred Templin Subject: Re: isatap-07 draft offered as last-call To: Alain Durand Cc: v6ops@ops.ietf.org In-Reply-To: <3DDD3346.4010401@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.2 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Alain, I agree with your concerns, and you raise good points. I also have comments from Brian Carpenter and Jason Goldschmidt; I'd like to back off on the last call until the issues are addressed. Fred ftemplin@iprg.nokia.com --- Alain Durand wrote: > > > Fred Templin wrote: > > >Hello, > > > >As per Harald Alvestrand's message "On NGTRANS, transition mechanisms and consortia", > >I would like to offer the current isatap version as immediate last-call candidate for > >experimental track. > > > > I strongly object to the publication of this document. > > When a node enables an ISATAP link, it initializes the Potential > Router List (PRL) for that link. Unless other information is avail­ > able (e.g., manual address configuration, a vendor-specific DHCP > option, etc.), the DNS SHOULD be consulted (e.g., by resolving the > name "isatap.domainname" where "domainname" MUST be relative to the > node's physical point of attachment.) > > a) domainname is a information that is relative to the name space and > gives no information > whatsoever about the physical location of the machine. > For example, at Sun, we use many domains like eng.sun.com, > uk.sun.com, east.sun.com.... > Some of them a somehow loosely linked to a particular geography > (east.sun.com, uk.sun.com) > while some other are organisational domains (eng.sun.com) that may > span across geography. > > b) You are using something that does not belong to you. > The name isatap could very well have been already assigned in my > DNS zone. > > - Alain. > __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com From owner-v6ops@ops.ietf.org Thu Nov 21 14:47:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17555 for ; Thu, 21 Nov 2002 14:47:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ExK4-000FYx-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 11:49:12 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18ExK0-000FYG-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 11:49:09 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 566237E3C; Thu, 21 Nov 2002 20:49:30 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id DAB277763; Thu, 21 Nov 2002 20:49:24 +0100 (CET) From: "Jeroen Massar" To: Cc: Subject: RE: 6to4 deployement issues - was 6to4 security questions Date: Thu, 21 Nov 2002 20:49:40 +0100 Organization: Unfix Message-ID: <005101c29197$2228e5b0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3DDD312F.1060605@sun.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA17555 Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM] wrote: > Either you leave the relay model or you remove it. > If you leave it as it is, you open serious security issues > If you remove relays from the architecture, you create > a partition of the Internet. Sure, today there is no content > reachable though native IPv6, but one day, there will. > That day, you do not want to prevent those gazilliions > 6to4 users from reaching it. 6to4 is a good transition method that works, but as you say below it needs some reworking so the abuse possibilities are limited as far as possible. > The only wat forward is either to deprecate 6to4 alltogether > (and use another conncetivity for the masses approach until > IPv6 ISPs are generally available) > or to fix the security problem. > > My take is go back to the white board and try to fix it. Some of my thoughts about this: * Limit 6to4 to 1 ISP. This way an ISP could setup a 6to4 service for their clients and provide it to the parts of their networks which are not capable of native IPv6 at that moment. I would implement that 'limit' by using carefull source address filtering. A ISP should know from which ranges clients could come which are not capable of native IPv6. For example the following network structure: IX-a --- brd - 6to4 relay --- customer access \ | / IX-b --- brd --- ISP core backbone --- * --- customer access / \ IX-c --- brd - --- customer access { ISP } Thus the 6to4 relay is just another router in the network of the ISP Source address verification should be enabled on all incoming connections anyways if they are sane people and want to protect themselves against DoS's. Because of that the ISP can know that any traffic coming out of that prefix and which is on their network is from a client and that it is a valid prefix. Ofcourse a client could spoof inside the ranges on which the borders get filtered. But that is a local problem which can be found out. As the 6to4 relay is inside the ISP's network it will only be reachable for their own clients. This has the following advantages: - Spoofing is kept to the ISP level. - And ofcourse the disadvantages: - Every ISP needs to setup a 6to4 router or ask another ISP access to theirs. This setup could easily make use of the anycast address. One should then restrict the announcement of this anycast address to the ISP or to the ISP's one trust to filter correctly on incoming connections. Having no route to the 6to4 relay from the outside will makes this work quite easily too :) One will have to announce all the 2002:::: prefixes one has and is serving too into the IPv6 routing cloud to make this work and make the paths shorter. Greets, Jeroen From owner-v6ops@ops.ietf.org Thu Nov 21 14:58:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17947 for ; Thu, 21 Nov 2002 14:58:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ExVl-000GYA-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 12:01:17 -0800 Received: from web13002.mail.yahoo.com ([216.136.174.12]) by psg.com with smtp (Exim 3.36 #2) id 18ExVj-000GXX-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 12:01:15 -0800 Message-ID: <20021121200115.79076.qmail@web13002.mail.yahoo.com> Received: from [204.42.68.8] by web13002.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 12:01:15 PST Date: Thu, 21 Nov 2002 12:01:15 -0800 (PST) From: Fred Templin Subject: Re: isatap-07 draft offered as last-call To: Alain Durand Cc: v6ops@ops.ietf.org In-Reply-To: <3DDD3346.4010401@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.8 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,MAILTO_TO_SPAM_ADDR, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Alain, --- Alain Durand wrote: > > > Fred Templin wrote: > > >Hello, > > > >As per Harald Alvestrand's message "On NGTRANS, transition mechanisms and consortia", > >I would like to offer the current isatap version as immediate last-call candidate for > >experimental track. > > > > I strongly object to the publication of this document. > > When a node enables an ISATAP link, it initializes the Potential > Router List (PRL) for that link. Unless other information is avail­ > able (e.g., manual address configuration, a vendor-specific DHCP > option, etc.), the DNS SHOULD be consulted (e.g., by resolving the > name "isatap.domainname" where "domainname" MUST be relative to the > node's physical point of attachment.) > > a) domainname is a information that is relative to the name space and > gives no information > whatsoever about the physical location of the machine. > For example, at Sun, we use many domains like eng.sun.com, > uk.sun.com, east.sun.com.... > Some of them a somehow loosely linked to a particular geography > (east.sun.com, uk.sun.com) > while some other are organisational domains (eng.sun.com) that may > span across geography. You know, on further thought we've been down this road many times before. I am specifically *not* meaning to infer that the node magically locates the topologically closest domainname by geography/topology. Instead, the text includes flexibility to allow automatic discovery when a node rarely travels around and manual config when the node goes mobile. > b) You are using something that does not belong to you. > The name isatap could very well have been already assigned in my > DNS zone. Again, we've talked about this before. This seems like a rare enough occurence, such that the existing nameholder would: 1. already be an isatap router and answer the RAs 2. be a non-isatap router and NOT answer the RAs 3. be an existing, but undesired ISATAP router I believe cases 1) and 2) would predominate, and case 3) would be extremely rare. In either cases 2) or 3), we simply have a deployment consideration note - not true? Fred Templin osprey67@yahoo.com > - Alain. > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-v6ops@ops.ietf.org Thu Nov 21 15:02:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18076 for ; Thu, 21 Nov 2002 15:02:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ExZQ-000Gq6-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 12:05:04 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18ExZM-000GpW-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 12:05:00 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gALK4tk25702; Thu, 21 Nov 2002 22:04:55 +0200 Date: Thu, 21 Nov 2002 22:04:55 +0200 (EET) From: Pekka Savola To: Jeroen Massar cc: Alain.Durand@Sun.COM, Subject: RE: 6to4 deployement issues - was 6to4 security questions In-Reply-To: <005101c29197$2228e5b0$210d640a@unfix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk please think that to the end, it will not want without re-specification _globally_. We don't want to restrict 6to4 to ISPs' walled gardens. On Thu, 21 Nov 2002, Jeroen Massar wrote: > Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM] wrote: > > > > Either you leave the relay model or you remove it. > > If you leave it as it is, you open serious security issues > > If you remove relays from the architecture, you create > > a partition of the Internet. Sure, today there is no content > > reachable though native IPv6, but one day, there will. > > That day, you do not want to prevent those gazilliions > > 6to4 users from reaching it. > > 6to4 is a good transition method that works, but as you say below > it needs some reworking so the abuse possibilities are limited > as far as possible. > > > The only wat forward is either to deprecate 6to4 alltogether > > (and use another conncetivity for the masses approach until > > IPv6 ISPs are generally available) > > or to fix the security problem. > > > > My take is go back to the white board and try to fix it. > > Some of my thoughts about this: > > * Limit 6to4 to 1 ISP. > > This way an ISP could setup a 6to4 service for their clients > and provide it to the parts of their networks which are not > capable of native IPv6 at that moment. > > I would implement that 'limit' by using carefull source address > filtering. > A ISP should know from which ranges clients could come which are not > capable of native IPv6. > > For example the following network structure: > > IX-a --- brd - 6to4 relay --- customer access > \ | / > IX-b --- brd --- ISP core backbone --- * --- customer access > / \ > IX-c --- brd - --- customer access > { ISP } > > Thus the 6to4 relay is just another router in the network of the ISP > Source address verification should be enabled on all incoming > connections > anyways if they are sane people and want to protect themselves against > DoS's. > Because of that the ISP can know that any traffic coming out of that > prefix > and which is on their network is from a client and that it is a valid > prefix. > Ofcourse a client could spoof inside the ranges on which the borders get > filtered. > But that is a local problem which can be found out. > As the 6to4 relay is inside the ISP's network it will only be reachable > for their > own clients. > > This has the following advantages: > - Spoofing is kept to the ISP level. > - > > And ofcourse the disadvantages: > - Every ISP needs to setup a 6to4 router or ask another ISP access to > theirs. > > This setup could easily make use of the anycast address. > One should then restrict the announcement of this anycast address to the > ISP > or to the ISP's one trust to filter correctly on incoming connections. > > Having no route to the 6to4 relay from the outside will makes this work > quite easily too :) > > One will have to announce all the 2002:::: prefixes one has and > is serving too > into the IPv6 routing cloud to make this work and make the paths > shorter. > > Greets, > Jeroen > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 15:46:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19455 for ; Thu, 21 Nov 2002 15:46:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EyFV-000KEh-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 12:48:33 -0800 Received: from isrv4.isc.org ([204.152.184.27]) by psg.com with esmtp (Exim 3.36 #2) id 18EyFQ-000KEV-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 12:48:28 -0800 Received: by isrv4.isc.org (Postfix, from userid 88) id 16C896C6; Thu, 21 Nov 2002 20:48:28 +0000 (UTC) To: v6ops@ops.ietf.org From: ggm@apnic.net (George Michaelson) Subject: Microsoft uses 'darknet' to refer to PTP overlays: what do we call misuse of unallocated address space? Organization: APNIC Pty Ltd Message-ID: <20021122055033.6f166023.ggm@apnic.net> NNTP-Posting-Host: localhost X-Trace: isrv4.isc.org 1037911707 373004 127.0.0.1 (21 Nov 2002 20:48:27 GMT) X-Complaints-To: abuse@isc.org NNTP-Posting-Date: 21 Nov 2002 20:48:27 GMT X-Delivered-To: local-mail-net-ietf@isrv4.isc.org X-Received: from vesuvio.ipv6.cselt.it (vesuvio.ipv6.cselt.it [163.162.170.199]) by isrv4.isc.org (Postfix) with ESMTP id 341C26C6; Thu, 21 Nov 2002 20:48:25 +0000 (UTC) (envelope-from owner-ietf_censored@vesuvio.ipv6.cselt.it) X-Received: from vesuvio.ipv6.cselt.it (localhost.ipv6.cselt.it [127.0.0.1]) by vesuvio.ipv6.cselt.it (8.12.6/8.12.6) with ESMTP id gALKNMM4081738 for ; Thu, 21 Nov 2002 21:23:22 +0100 (CET) (envelope-from owner-ietf_censored@ngnet.it) X-Received: (from majordomo@localhost) by vesuvio.ipv6.cselt.it (8.12.6/8.12.6/Submit) id gALKNMEG081737 for ietf_censored-ovtgoing; Thu, 21 Nov 2002 21:23:22 +0100 (CET) X-Authentication-Warning: vesuvio.ipv6.cselt.it: majordomo set sender to owner-ietf_censored@ngnet.it using -f X-Received: from carmen.ipv6.tilab.com (carmen.ipv6.cselt.it [163.162.170.198]) by vesuvio.ipv6.cselt.it (8.12.6/8.12.6) with ESMTP id gALKNMM4081733 for ; Thu, 21 Nov 2002 21:23:22 +0100 (CET) (envelope-from owner-ietf_censored@ngnet.it) X-Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by carmen.ipv6.tilab.com (8.12.3/8.12.3) with ESMTP id gALKYFT9020445 for ; Thu, 21 Nov 2002 21:34:16 +0100 (MET) X-Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA09661 for ietf-outbound.07@loki.ietf.org; Thu, 21 Nov 2002 15:00:01 -0500 (EST) X-Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id OAA09609 for ; Thu, 21 Nov 2002 14:52:49 -0500 (EST) X-Received: by ietf.org (8.9.1a/8.9.1a) id OAA17658 for ietf-mainout@loki.ietf.org; Thu, 21 Nov 2002 14:50:08 -0500 (EST) X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f X-Received: from dhcp-204-42-71-237.ietf55.ops.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17626 for ; Thu, 21 Nov 2002 14:48:59 -0500 (EST) X-Received: (from ggm@localhost) by dhcp-204-42-71-237.ietf55.ops.ietf.org (8.11.6/8.11.6) id gALJoXr01650; Fri, 22 Nov 2002 05:50:33 +1000 (EST) X-To: ietf@ietf.org X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) X-Mime-Version: 1.0 X-Content-Type: text/plain; charset=US-ASCII X-Content-Transfer-Encoding: 7bit X-Content-Transfer-Encoding: 7bit X-Content-Transfer-Encoding: 7bit X-Loop: ietf@ietf.org X-Precedence: bulk X-List-Unsubscribe: X-Filter-Ruleset: ietf_censored 38 Xref: news.isc.org local.mail.net.ietf:26050 Date: Thu, 21 Nov 2002 20:48:28 +0000 (UTC) X-Spam-Status: No, hits=1.3 required=5.0 tests=NOSPAM_INC,SPAM_PHRASE_02_03,X_AUTH_WARNING, X_LIST_UNSUBSCRIBE,X_LOOP version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Microsoft is now using the name 'darknet' to refer to the overlay networks of point to point filesharing in their Digital Rights Management (DRM) position papers in conferences. So, in the public eye, this neologism has probably now been taken to mean this activity, Rather than descend into hacker/cracker discussions, what is a good label to use when referring to people who usurp unallocated IPv4 address space, and arrange for it to be BGP visible in the classic DFZ network? I had thought that *this* was being called the dark net, but I'm not confident that tag will survive the behemoth... -George - This message was passed through ietf_censored@carmen.ipv6.cselt.it, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio. From owner-v6ops@ops.ietf.org Thu Nov 21 15:52:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19690 for ; Thu, 21 Nov 2002 15:52:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EyLI-000Kif-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 12:54:32 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18EyLF-000Khd-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 12:54:30 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 0CF167E3C; Thu, 21 Nov 2002 21:54:49 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 3E1027C17; Thu, 21 Nov 2002 21:54:43 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" Cc: , Subject: RE: 6to4 deployement issues - was 6to4 security questions Date: Thu, 21 Nov 2002 21:54:59 +0100 Organization: Unfix Message-ID: <005d01c291a0$42396dd0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA19690 Pekka Savola wrote: > Sent: Thursday, 21 November, 2002 21:05 > To: Jeroen Massar > Cc: Alain.Durand@Sun.COM; v6ops@ops.ietf.org > Subject: RE: 6to4 deployement issues - was 6to4 security questions > > > please think that to the end, it will not want without > re-specification _globally_. > We don't want to restrict 6to4 to ISPs' walled gardens. One ISP can have a trust relation with another ISP and announce the anycast prefix only to that other ISP so it can make use of it too. Source address verification should then ofcourse be extended by the other ISP's. This could be seen as a 'transit' type service, but then between the v4 and v6 world ;) > On Thu, 21 Nov 2002, Jeroen Massar wrote: > > > Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM] wrote: > > > > > > > Either you leave the relay model or you remove it. > > > If you leave it as it is, you open serious security issues > > > If you remove relays from the architecture, you create > > > a partition of the Internet. Sure, today there is no content > > > reachable though native IPv6, but one day, there will. > > > That day, you do not want to prevent those gazilliions > > > 6to4 users from reaching it. > > > > 6to4 is a good transition method that works, but as you say below > > it needs some reworking so the abuse possibilities are limited > > as far as possible. > > > > > The only wat forward is either to deprecate 6to4 alltogether > > > (and use another conncetivity for the masses approach until > > > IPv6 ISPs are generally available) > > > or to fix the security problem. > > > > > > My take is go back to the white board and try to fix it. > > > > Some of my thoughts about this: > > > > * Limit 6to4 to 1 ISP. > > > > This way an ISP could setup a 6to4 service for their clients > > and provide it to the parts of their networks which are not > > capable of native IPv6 at that moment. > > > > I would implement that 'limit' by using carefull source address > > filtering. > > A ISP should know from which ranges clients could come which are not > > capable of native IPv6. > > > > For example the following network structure: > > > > IX-a --- brd - 6to4 relay --- customer access > > \ | / > > IX-b --- brd --- ISP core backbone --- * --- customer access > > / \ > > IX-c --- brd - --- customer access > > { ISP } > > > > Thus the 6to4 relay is just another router in the network of the ISP > > Source address verification should be enabled on all incoming > > connections > > anyways if they are sane people and want to protect > themselves against > > DoS's. > > Because of that the ISP can know that any traffic coming out of that > > prefix > > and which is on their network is from a client and that it > is a valid > > prefix. > > Ofcourse a client could spoof inside the ranges on which > the borders get > > filtered. > > But that is a local problem which can be found out. > > As the 6to4 relay is inside the ISP's network it will only > be reachable > > for their > > own clients. > > > > This has the following advantages: > > - Spoofing is kept to the ISP level. > > - > > > > And ofcourse the disadvantages: > > - Every ISP needs to setup a 6to4 router or ask another > ISP access to > > theirs. > > > > This setup could easily make use of the anycast address. > > One should then restrict the announcement of this anycast > address to the > > ISP > > or to the ISP's one trust to filter correctly on incoming > connections. > > > > Having no route to the 6to4 relay from the outside will > makes this work > > quite easily too :) > > > > One will have to announce all the 2002:::: prefixes > one has and > > is serving too > > into the IPv6 routing cloud to make this work and make the paths > > shorter. > > > > Greets, > > Jeroen > > > > > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > From owner-v6ops@ops.ietf.org Thu Nov 21 16:01:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20187 for ; Thu, 21 Nov 2002 16:01:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18EyTx-000LWs-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 13:03:29 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18EyTv-000LWJ-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 13:03:27 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gALL3ME26284; Thu, 21 Nov 2002 23:03:22 +0200 Date: Thu, 21 Nov 2002 23:03:22 +0200 (EET) From: Pekka Savola To: Jeroen Massar cc: Alain.Durand@Sun.COM, Subject: RE: 6to4 deployement issues - was 6to4 security questions In-Reply-To: <005d01c291a0$42396dd0$210d640a@unfix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 21 Nov 2002, Jeroen Massar wrote: > > please think that to the end, it will not work without > > re-specification _globally_. > > We don't want to restrict 6to4 to ISPs' walled gardens. > > One ISP can have a trust relation with another ISP and announce > the anycast prefix only to that other ISP so it can make use of it too. > Source address verification should then ofcourse be extended by the > other ISP's. This could be seen as a 'transit' type service, but then > between the v4 and v6 world ;) How will you send traffic from 2001:dead:beef::1 to 2002:0103:0405::1, if 2001:dead:beef::/48 is not within the trust boundary? If the answer if "no, you can't", this seems close to my "limited distribution of more specific routes" solution, except being more restrictive for deployment. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 17:59:48 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24981 for ; Thu, 21 Nov 2002 17:59:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F0KE-00055h-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 15:01:34 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18F0KC-00055V-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 15:01:32 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gALN1Rm10819; Fri, 22 Nov 2002 00:01:27 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gALN1Rte040627; Fri, 22 Nov 2002 00:01:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211212301.gALN1Rte040627@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: Alain Durand , Erik Nordmark , Jason Goldschmidt , Pekka Savola , v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-reply-to: Your message of Thu, 21 Nov 2002 16:07:47 +0100. <3DDCF6C3.C89153B@hursley.ibm.com> Date: Fri, 22 Nov 2002 00:01:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: Actually, what is wrong with the model in bullet 2.2 of section 5.2 of RFC 3056, i.e. require a BGP4+ peer relationship between a 6to4 router and the 6to4 relay routers it deals with? (OK, I can see some reachability issues but 6to4 is not supposed to be the universal answer.) => this is a heavy solution (6to4 is supposed to be automatic and not require BGP4+ skills) which secures only one way. The security issue is a rogue 6to4 relay which uses 6to4 boxes behind 6to4 routers to reflect traffic to poor IPv6 nodes. I am afraid this is the other way (as Alain said, the problem is in the asymmetrical routing between 6to4 and native IPv6 Internets). As I said a moment ago, 6to4 wasn't designed for end hosts. I've always felt the BGP4+ scenario was the best one. => of course, bullet 2.2 of section 5.2 is an option of a scenario... Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Thu Nov 21 18:14:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25572 for ; Thu, 21 Nov 2002 18:14:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F0ZP-0006Oe-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 15:17:15 -0800 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #2) id 18F0ZM-0006Mo-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 15:17:12 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id gALNGcMj153068; Fri, 22 Nov 2002 00:16:39 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gALNGc71161530; Fri, 22 Nov 2002 00:16:38 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA73080 from ; Fri, 22 Nov 2002 00:16:36 +0100 Message-Id: <3DDD5854.FB93EB2D@hursley.ibm.com> Date: Thu, 21 Nov 2002 23:04:04 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Jeroen Massar Cc: Alain.Durand@Sun.COM, v6ops@ops.ietf.org Subject: Re: 6to4 deployement issues - was 6to4 security questions References: <005101c29197$2228e5b0$210d640a@unfix.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.7 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jeroen, The RFC 3056 model is to limit the visibility of a relay by BGP policy - that allows it to be wider (or narrower) than one ISP; As I said to Pekka Savola, you do that by scoping the advertisement of 2002::/16 using normal BGP policy mechanisms. But that isn't the spoofing solution; for that you need a peer relationship of some kind between the 6to4 "customer" router and the set of trustworthy relays. Brian Jeroen Massar wrote: > > Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM] wrote: > > > > Either you leave the relay model or you remove it. > > If you leave it as it is, you open serious security issues > > If you remove relays from the architecture, you create > > a partition of the Internet. Sure, today there is no content > > reachable though native IPv6, but one day, there will. > > That day, you do not want to prevent those gazilliions > > 6to4 users from reaching it. > > 6to4 is a good transition method that works, but as you say below > it needs some reworking so the abuse possibilities are limited > as far as possible. > > > The only wat forward is either to deprecate 6to4 alltogether > > (and use another conncetivity for the masses approach until > > IPv6 ISPs are generally available) > > or to fix the security problem. > > > > My take is go back to the white board and try to fix it. > > Some of my thoughts about this: > > * Limit 6to4 to 1 ISP. > > This way an ISP could setup a 6to4 service for their clients > and provide it to the parts of their networks which are not > capable of native IPv6 at that moment. > > I would implement that 'limit' by using carefull source address > filtering. > A ISP should know from which ranges clients could come which are not > capable of native IPv6. > > For example the following network structure: > > IX-a --- brd - 6to4 relay --- customer access > \ | / > IX-b --- brd --- ISP core backbone --- * --- customer access > / \ > IX-c --- brd - --- customer access > { ISP } > > Thus the 6to4 relay is just another router in the network of the ISP > Source address verification should be enabled on all incoming > connections > anyways if they are sane people and want to protect themselves against > DoS's. > Because of that the ISP can know that any traffic coming out of that > prefix > and which is on their network is from a client and that it is a valid > prefix. > Ofcourse a client could spoof inside the ranges on which the borders get > filtered. > But that is a local problem which can be found out. > As the 6to4 relay is inside the ISP's network it will only be reachable > for their > own clients. > > This has the following advantages: > - Spoofing is kept to the ISP level. > - > > And ofcourse the disadvantages: > - Every ISP needs to setup a 6to4 router or ask another ISP access to > theirs. > > This setup could easily make use of the anycast address. > One should then restrict the announcement of this anycast address to the > ISP > or to the ISP's one trust to filter correctly on incoming connections. > > Having no route to the 6to4 relay from the outside will makes this work > quite easily too :) > > One will have to announce all the 2002:::: prefixes one has and > is serving too > into the IPv6 routing cloud to make this work and make the paths > shorter. > > Greets, > Jeroen From owner-v6ops@ops.ietf.org Thu Nov 21 18:15:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25588 for ; Thu, 21 Nov 2002 18:15:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F0ZY-0006QZ-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 15:17:24 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #2) id 18F0ZO-0006Mp-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 15:17:14 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gALNGZeW077000; Fri, 22 Nov 2002 00:16:35 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gALNGYd1022830; Fri, 22 Nov 2002 00:16:35 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23326 from ; Fri, 22 Nov 2002 00:16:32 +0100 Message-Id: <3DDD5821.5953FA26@hursley.ibm.com> Date: Thu, 21 Nov 2002 23:03:13 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.7 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > On Thu, 21 Nov 2002, Brian E Carpenter wrote: > > Actually, what is wrong with the model in bullet 2.2 of section 5.2 > > of RFC 3056, i.e. require a BGP4+ peer relationship between a 6to4 > > router and the 6to4 relay routers it deals with? (OK, I can see some > > reachability issues but 6to4 is not supposed to be the universal answer.) > > That, in itself, helps little. Relay routers must also be connected using > BGP4+ and advertising more specific routes. No, the model is that they will advertise 2002::/16, but only inside a limited set of AS's. That is mentioned in RFC 3056 - you use BGP policy to scope which relay serves which part of the native IPv6 network. That in itself doesn't protect against spoofing however; for that you need peering between the 6to4 router and a set of trustworthy relays. > > > As I said a moment ago, 6to4 wasn't designed for end hosts. I've > > always felt the BGP4+ scenario was the best one. > > Well, the reasons 6to4 is used are usualy either/and: > 1) ease of taking into use > 2) takes dynamic v4 address into account > > For SOHO/home use, both conditions are usually fulfilled. Also, for > bigger enterprise networks, which are usually able to run BGP etc., are > only concerned about _at most_ 1). The third reason is 3) no IPv6 ISP offering configured tunnels near enough in the topology. Brian From owner-v6ops@ops.ietf.org Thu Nov 21 18:22:52 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25866 for ; Thu, 21 Nov 2002 18:22:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F0hC-00074I-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 15:25:18 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18F0hA-00073E-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 15:25:16 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gALNPD727598; Fri, 22 Nov 2002 01:25:13 +0200 Date: Fri, 22 Nov 2002 01:25:13 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-Reply-To: <3DDD5821.5953FA26@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 21 Nov 2002, Brian E Carpenter wrote: > > On Thu, 21 Nov 2002, Brian E Carpenter wrote: > > > Actually, what is wrong with the model in bullet 2.2 of section 5.2 > > > of RFC 3056, i.e. require a BGP4+ peer relationship between a 6to4 > > > router and the 6to4 relay routers it deals with? (OK, I can see some > > > reachability issues but 6to4 is not supposed to be the universal answer.) > > > > That, in itself, helps little. Relay routers must also be connected using > > BGP4+ and advertising more specific routes. > > No, the model is that they will advertise 2002::/16, but only inside a limited set > of AS's. That is mentioned in RFC 3056 - you use BGP policy to scope > which relay serves which part of the native IPv6 network. A very and heavy and unreliable (the unpredictable return routing) model. I don't believe there are any of these deployed. > That in itself doesn't protect against spoofing however; Indeed. > for that you need > peering between the 6to4 router and a set of trustworthy relays. You're creating a separate, rather small 6to4 internets using this model, unless the relay routers will relay more specific routes between them. I can't regard that as an acceptable deployment scenario: this seems like creating semi-global addresses, and isolate yourself from the rest. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 18:46:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26599 for ; Thu, 21 Nov 2002 18:46:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F13v-00095y-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 15:48:47 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #2) id 18F13s-00091J-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 15:48:44 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gALNmBkL065544; Fri, 22 Nov 2002 00:48:11 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gALNmA71107182; Fri, 22 Nov 2002 00:48:11 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA69692 from ; Fri, 22 Nov 2002 00:48:08 +0100 Message-Id: <3DDD70A3.9504FF11@hursley.ibm.com> Date: Fri, 22 Nov 2002 00:47:47 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: Jeroen Massar , Alain.Durand@Sun.COM, v6ops@ops.ietf.org Subject: Re: 6to4 deployement issues - was 6to4 security questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > On Thu, 21 Nov 2002, Jeroen Massar wrote: > > > please think that to the end, it will not work without > > > re-specification _globally_. > > > We don't want to restrict 6to4 to ISPs' walled gardens. > > > > One ISP can have a trust relation with another ISP and announce > > the anycast prefix only to that other ISP so it can make use of it too. > > Source address verification should then ofcourse be extended by the > > other ISP's. This could be seen as a 'transit' type service, but then > > between the v4 and v6 world ;) > > How will you send traffic from 2001:dead:beef::1 to 2002:0103:0405::1, if > 2001:dead:beef::/48 is not within the trust boundary? Wrong question. The question is, does *any* 2002::/16 announcement reach dead:beef's ISP? If yes, whichever relay is the origin of that announcement will relay the traffic. The 2nd question is whether that particular relay is trusted by 0103:0405's 6to4 router. Brian > > If the answer if "no, you can't", this seems close to my "limited > distribution of more specific routes" solution, except being more > restrictive for deployment. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-v6ops@ops.ietf.org Thu Nov 21 18:50:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26750 for ; Thu, 21 Nov 2002 18:50:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F18G-0009WP-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 15:53:16 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #2) id 18F18D-0009RS-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 15:53:13 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gALNqJeW037894; Fri, 22 Nov 2002 00:52:19 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gALNqJd1094596; Fri, 22 Nov 2002 00:52:19 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA73210 from ; Fri, 22 Nov 2002 00:52:15 +0100 Message-Id: <3DDD719A.A2E0D306@hursley.ibm.com> Date: Fri, 22 Nov 2002 00:51:54 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Francis Dupont Cc: Alain Durand , Erik Nordmark , Jason Goldschmidt , Pekka Savola , v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: <200211212301.gALN1Rte040627@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > In your previous mail you wrote: > > Actually, what is wrong with the model in bullet 2.2 of section 5.2 > of RFC 3056, i.e. require a BGP4+ peer relationship between a 6to4 > router and the 6to4 relay routers it deals with? (OK, I can see some > reachability issues but 6to4 is not supposed to be the universal answer.) > > => this is a heavy solution (6to4 is supposed to be automatic and > not require BGP4+ skills) This author of 6to4 *never* said that. > which secures only one way. Indeed. You need BGP peering on both sides of the relay. > The security issue is a rogue 6to4 relay which uses 6to4 boxes behind > 6to4 routers to reflect traffic to poor IPv6 nodes. Exactly. So the 6to4 routers should only accept packets from BGP peers. It may be heavyweight, but it is not mysterious. Brian > I am afraid > this is the other way (as Alain said, the problem is in the asymmetrical > routing between 6to4 and native IPv6 Internets). > > As I said a moment ago, 6to4 wasn't designed for end hosts. I've > always felt the BGP4+ scenario was the best one. > > => of course, bullet 2.2 of section 5.2 is an option of a scenario... > > Regards > > Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Thu Nov 21 18:52:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26812 for ; Thu, 21 Nov 2002 18:52:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F1AB-0009iK-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 15:55:15 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18F1A8-0009hZ-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 15:55:12 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gALNt5N27883; Fri, 22 Nov 2002 01:55:06 +0200 Date: Fri, 22 Nov 2002 01:55:05 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Jeroen Massar , , Subject: Re: 6to4 deployement issues - was 6to4 security questions In-Reply-To: <3DDD70A3.9504FF11@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 22 Nov 2002, Brian E Carpenter wrote: > > On Thu, 21 Nov 2002, Jeroen Massar wrote: > > > > please think that to the end, it will not work without > > > > re-specification _globally_. > > > > We don't want to restrict 6to4 to ISPs' walled gardens. > > > > > > One ISP can have a trust relation with another ISP and announce > > > the anycast prefix only to that other ISP so it can make use of it too. > > > Source address verification should then ofcourse be extended by the > > > other ISP's. This could be seen as a 'transit' type service, but then > > > between the v4 and v6 world ;) > > > > How will you send traffic from 2001:dead:beef::1 to 2002:0103:0405::1, if > > 2001:dead:beef::/48 is not within the trust boundary? > > Wrong question. The question is, does *any* 2002::/16 announcement > reach dead:beef's ISP? If yes, whichever relay is the origin of > that announcement will relay the traffic. The 2nd question is whether > that particular relay is trusted by 0103:0405's 6to4 router. Exactly. In Jeroen's model, I believe, the particular relay would particully never be trusted. Any such model model is broken. 6to4 routers do not have any ways of knowing where traffic will be coming from, so discarding packets because they didn't come from your two favourite relays is *wrong*. Propagating more specific routes etc. avoids this problem as you have only one "home" relay. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 18:53:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26875 for ; Thu, 21 Nov 2002 18:53:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F1BH-0009ps-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 15:56:23 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18F1BC-0009oQ-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 15:56:18 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id B5F1778D0; Fri, 22 Nov 2002 00:56:39 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 103AA7819; Fri, 22 Nov 2002 00:56:33 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" , "'Brian E Carpenter'" Cc: Subject: RE: 6to4 deployement issues - was 6to4 security questions Date: Fri, 22 Nov 2002 00:56:49 +0100 Organization: Unfix Message-ID: <000801c291b9$a8980eb0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA26875 [Also answering Brian's comment below ] Pekka Savola [mailto:pekkas@netcore.fi] wrote: > On Thu, 21 Nov 2002, Jeroen Massar wrote: > > > please think that to the end, it will not work without > > > re-specification _globally_. > > > We don't want to restrict 6to4 to ISPs' walled gardens. > > > > One ISP can have a trust relation with another ISP and announce > > the anycast prefix only to that other ISP so it can make > use of it too. > > Source address verification should then ofcourse be extended by the > > other ISP's. This could be seen as a 'transit' type > service, but then > > between the v4 and v6 world ;) > > How will you send traffic from 2001:dead:beef::1 to > 2002:0103:0405::1, if > 2001:dead:beef::/48 is not within the trust boundary? > > If the answer if "no, you can't", this seems close to my "limited > distribution of more specific routes" solution, except being more > restrictive for deployment. That's indeed something one doesn't want as it doesn't help a bit indeed. Cut&Paste from the big mail: > One will have to announce all the 2002:::: prefixes one has and > is serving too into the IPv6 routing cloud to make this work and make > the paths shorter. Ofcourse most of the bigger ISP's can fortunatly aggregate most of their prefixes. Probably a big disadvantage would be that sites employing this idea will have the same number of prefixes currently being announced into the IPv4 world also being announced to the 6to4 (2002::/16) counterpart. Mind you that many ISP's won't setup a 6to4 relays and hopefully will be using neighboring ISP's relays, maybe with a bit more aggregateble space. People not having a 6to4 relay can ofcourse take '6to4 transit' from other ISP's though '6to4 transit' should go over native connections wherever possible ofcourse. Biggest advantage of announcing these multiple prefixes is also that the IPv4 path over which the 6to4 tunnel goes stays short. Reaching a IPv6 site thus would mostly take the same route as the IPv4 path which latency and stability-wise is a good thing. Brian wrote: > The RFC 3056 model is to limit the visibility of a relay by BGP > policy - that allows it to be wider (or narrower) than one ISP; > As I said to Pekka Savola, you do that by scoping the > advertisement of 2002::/16 using normal BGP policy mechanisms. Which is what I meant also :) > But that isn't the spoofing solution; for that you need a peer > relationship of some kind between the 6to4 "customer" router > and the set of trustworthy relays. See the comment above about '6to4 transit' which, I think, could solve this problem. It will indeed create 6to4 islands hanging onto the RIR/6bone space as leaf sites but that isn't much of a problem as it gives connectivity. It should never be used for transit. Greets, Jeroen From owner-v6ops@ops.ietf.org Thu Nov 21 19:21:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27726 for ; Thu, 21 Nov 2002 19:21:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F1ao-000C1S-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 16:22:46 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #2) id 18F1al-000C0j-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 16:22:43 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAM0M6eW072396; Fri, 22 Nov 2002 01:22:06 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAM0M6d1044082; Fri, 22 Nov 2002 01:22:06 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA73114 from ; Fri, 22 Nov 2002 01:22:04 +0100 Message-Id: <3DDD7898.65D52F5@hursley.ibm.com> Date: Fri, 22 Nov 2002 01:21:44 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.7 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > On Thu, 21 Nov 2002, Brian E Carpenter wrote: > > > On Thu, 21 Nov 2002, Brian E Carpenter wrote: > > > > Actually, what is wrong with the model in bullet 2.2 of section 5.2 > > > > of RFC 3056, i.e. require a BGP4+ peer relationship between a 6to4 > > > > router and the 6to4 relay routers it deals with? (OK, I can see some > > > > reachability issues but 6to4 is not supposed to be the universal answer.) > > > > > > That, in itself, helps little. Relay routers must also be connected using > > > BGP4+ and advertising more specific routes. > > > > No, the model is that they will advertise 2002::/16, but only inside a limited set > > of AS's. That is mentioned in RFC 3056 - you use BGP policy to scope > > which relay serves which part of the native IPv6 network. > > A very and heavy and unreliable (the unpredictable return routing) model. > I don't believe there are any of these deployed. > > > That in itself doesn't protect against spoofing however; > > Indeed. > > > for that you need > > peering between the 6to4 router and a set of trustworthy relays. > > You're creating a separate, rather small 6to4 internets using this model, > unless the relay routers will relay more specific routes between them. > > I can't regard that as an acceptable deployment scenario: this seems like > creating semi-global addresses, and isolate yourself from the rest. There are some balkanization risks in the RFC 3056 BGP-based model. There are spoofing/DDOS risks in the host-based anycast 6to4 model that has been implemented but never fully specified. Take your pick. Brian From owner-v6ops@ops.ietf.org Thu Nov 21 19:32:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28329 for ; Thu, 21 Nov 2002 19:32:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F1m6-000Crh-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 16:34:26 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18F1lw-000Cr2-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 16:34:16 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAM0YDV28224; Fri, 22 Nov 2002 02:34:13 +0200 Date: Fri, 22 Nov 2002 02:34:13 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-Reply-To: <3DDD7898.65D52F5@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 22 Nov 2002, Brian E Carpenter wrote: > There are spoofing/DDOS risks in the host-based anycast 6to4 model > that has been implemented but never fully specified. Do not classify this as "host-based". There is nothing particularly host-based in this. And you said you're not aware of anything in the spec that'd need modification. Right.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 19:33:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28345 for ; Thu, 21 Nov 2002 19:33:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F1mr-000CzN-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 16:35:13 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18F1mn-000Cye-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 16:35:09 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 2337F779E; Fri, 22 Nov 2002 01:35:30 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 9670078D0; Fri, 22 Nov 2002 01:35:06 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" , "'Brian E Carpenter'" Cc: , Subject: RE: 6to4 deployement issues - was 6to4 security questions Date: Fri, 22 Nov 2002 01:35:21 +0100 Organization: Unfix Message-ID: <001001c291bf$0baec7a0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA28345 Pekka Savola [mailto:pekkas@netcore.fi] wrote: > On Fri, 22 Nov 2002, Brian E Carpenter wrote: > > > On Thu, 21 Nov 2002, Jeroen Massar wrote: > > > > > please think that to the end, it will not work without > > > > > re-specification _globally_. > > > > > We don't want to restrict 6to4 to ISPs' walled gardens. > > > > > > > > One ISP can have a trust relation with another ISP and announce > > > > the anycast prefix only to that other ISP so it can > make use of it too. > > > > Source address verification should then ofcourse be > extended by the > > > > other ISP's. This could be seen as a 'transit' type > service, but then > > > > between the v4 and v6 world ;) > > > > > > How will you send traffic from 2001:dead:beef::1 to > 2002:0103:0405::1, if > > > 2001:dead:beef::/48 is not within the trust boundary? > > > > Wrong question. The question is, does *any* 2002::/16 announcement > > reach dead:beef's ISP? If yes, whichever relay is the origin of > > that announcement will relay the traffic. The 2nd question > is whether > > that particular relay is trusted by 0103:0405's 6to4 router. > > Exactly. In Jeroen's model, I believe, the particular relay would > particully never be trusted. That is exactly what I mean. > > Any such model model is broken. Eek :) > 6to4 routers do not have any ways of knowing where traffic > will be coming > from, so discarding packets because they didn't come from your two > favourite relays is *wrong*. Thats indeed true, fortunatly in the setup depicted below one knows where packets should be coming from. > Propagating more specific routes etc. avoids this problem as > you have only one "home" relay. Which where my thoughts exactly. Indeed the origin 6to4 relay's ISP will announce the prefixes it is willing to relay for, so the others can now where this relay is located and send all the return traffic directly there. That 6to4 relay can then send the traffic directly to the 6to4 node. One thing is that "local" traffic will go over that same relay too even if it's in the same subnet. Maybe a check for "local subnet" could be devised to overcome this problem. Eg, box-A = 10.1.2.3/24, box-B = 10.1.2.4/24, these are directly connected and should send the 6to4 packets directly too each other. But when box-C has 192.168.1.2 this should go over the relay. Basically it comes down to: 10.100.2.5/24 [6to4 node A] <---+ | 10.100.1.1 +-----> [6to4 relay] <------> [IPv6 Internet] 10.100.2.6/24 | [6to4 node B] <---+ The relay announces 2002:0A64::/32 (10.100.0.0/16) - Any node on the internet knows how to reach it. - It only serves 10.100.0.0/16. - "6to4 Transit" goes over native (or configured tunnels) IPv6. - "Spoofing" is limited to the ISP, or the prefixes the 6to4 relay trusts. - 6to4 Anycast route is only available inside the ISP, or the ISPs it trusts. - Local traffic (6to4 node A <-> 6to4 node B) travels locally only. This should save some traffic on the relay though it is not 100% required. Ofcourse 10.x.x.x addresses can be replaced by real IP's, these are examples. One could also see this approach as aggregating 6to4 traffic. Eg I imagine a 6to4 relay one hop more to the right of the above picture which carries for instance 10.0.0.0/8 which it announces to the internet. Hope this clears it up a bit :) Greets, Jeroen From owner-v6ops@ops.ietf.org Thu Nov 21 20:09:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29519 for ; Thu, 21 Nov 2002 20:09:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F2LI-000GHo-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 17:10:48 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18F2LF-000GHa-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 17:10:45 -0800 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22568 for ; Thu, 21 Nov 2002 18:10:44 -0700 (MST) Received: from xpa-fe1 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5Y00N4PDXV4I@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 18:10:44 -0700 (MST) Received: from sun.com ([204.42.66.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H5Y00DFPDXQN5@mail.sun.net> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 18:10:43 -0700 (MST) Date: Thu, 21 Nov 2002 17:10:45 -0800 From: Alain Durand Subject: Re: 6to4 deployement issues - was 6to4 security questions To: Jeroen Massar Cc: "'Pekka Savola'" , "'Brian E Carpenter'" , v6ops@ops.ietf.org Message-id: <3DDD8415.3080907@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: <001001c291bf$0baec7a0$210d640a@unfix.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT You understand that the model you suggest will: - not scale because it basically requires advertizing /32 in IPv4 BGP tables... - will not enable an automatic deployment model a la Microsoft where any host in the Internet can automatically be turned into a 6to4 router. - Alain. Jeroen Massar wrote: >Pekka Savola [mailto:pekkas@netcore.fi] wrote: > > > >>On Fri, 22 Nov 2002, Brian E Carpenter wrote: >> >> >>>>On Thu, 21 Nov 2002, Jeroen Massar wrote: >>>> >>>> >>>>>>please think that to the end, it will not work without >>>>>>re-specification _globally_. >>>>>>We don't want to restrict 6to4 to ISPs' walled gardens. >>>>>> >>>>>> >>>>>One ISP can have a trust relation with another ISP and announce >>>>>the anycast prefix only to that other ISP so it can >>>>> >>>>> >>make use of it too. >> >> >>>>>Source address verification should then ofcourse be >>>>> >>>>> >>extended by the >> >> >>>>>other ISP's. This could be seen as a 'transit' type >>>>> >>>>> >>service, but then >> >> >>>>>between the v4 and v6 world ;) >>>>> >>>>> >>>>How will you send traffic from 2001:dead:beef::1 to >>>> >>>> >>2002:0103:0405::1, if >> >> >>>>2001:dead:beef::/48 is not within the trust boundary? >>>> >>>> >>>Wrong question. The question is, does *any* 2002::/16 announcement >>>reach dead:beef's ISP? If yes, whichever relay is the origin of >>>that announcement will relay the traffic. The 2nd question >>> >>> >>is whether >> >> >>>that particular relay is trusted by 0103:0405's 6to4 router. >>> >>> >>Exactly. In Jeroen's model, I believe, the particular relay would >>particully never be trusted. >> >> > >That is exactly what I mean. > > > >>Any such model model is broken. >> >> > >Eek :) > > > >>6to4 routers do not have any ways of knowing where traffic >>will be coming >>from, so discarding packets because they didn't come from your two >>favourite relays is *wrong*. >> >> > >Thats indeed true, fortunatly in the setup depicted below one >knows where packets should be coming from. > > > >>Propagating more specific routes etc. avoids this problem as >>you have only one "home" relay. >> >> > >Which where my thoughts exactly. >Indeed the origin 6to4 relay's ISP will announce the prefixes it >is willing to relay for, so the others can now where this relay >is located and send all the return traffic directly there. >That 6to4 relay can then send the traffic directly to the 6to4 node. > >One thing is that "local" traffic will go over that same relay too >even if it's in the same subnet. Maybe a check for "local subnet" >could be devised to overcome this problem. > >Eg, box-A = 10.1.2.3/24, box-B = 10.1.2.4/24, these are directly >connected >and should send the 6to4 packets directly too each other. >But when box-C has 192.168.1.2 this should go over the relay. >Basically it comes down to: > >10.100.2.5/24 >[6to4 node A] <---+ > | 10.100.1.1 > +-----> [6to4 relay] <------> [IPv6 Internet] >10.100.2.6/24 | >[6to4 node B] <---+ > >The relay announces 2002:0A64::/32 (10.100.0.0/16) >- Any node on the internet knows how to reach it. >- It only serves 10.100.0.0/16. >- "6to4 Transit" goes over native (or configured tunnels) IPv6. >- "Spoofing" is limited to the ISP, or the prefixes the 6to4 relay >trusts. >- 6to4 Anycast route is only available inside the ISP, or the ISPs it >trusts. >- Local traffic (6to4 node A <-> 6to4 node B) travels locally only. > This should save some traffic on the relay though it is not 100% >required. > >Ofcourse 10.x.x.x addresses can be replaced by real IP's, these are >examples. > >One could also see this approach as aggregating 6to4 traffic. >Eg I imagine a 6to4 relay one hop more to the right of the above picture >which carries for instance 10.0.0.0/8 which it announces to the >internet. > >Hope this clears it up a bit :) > >Greets, > Jeroen > > > > From owner-v6ops@ops.ietf.org Thu Nov 21 20:17:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29819 for ; Thu, 21 Nov 2002 20:17:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F2TJ-000GzD-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 17:19:05 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #2) id 18F2TH-000Gyi-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 17:19:03 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAM1IOC3063614; Fri, 22 Nov 2002 02:18:24 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAM1IO71092734; Fri, 22 Nov 2002 02:18:24 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA68664 from ; Fri, 22 Nov 2002 02:18:22 +0100 Message-Id: <3DDD85C8.6FE89102@hursley.ibm.com> Date: Fri, 22 Nov 2002 02:18:00 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > On Fri, 22 Nov 2002, Brian E Carpenter wrote: > > There are spoofing/DDOS risks in the host-based anycast 6to4 model > > that has been implemented but never fully specified. > > Do not classify this as "host-based". There is nothing particularly > host-based in this. Yes there is, because hosts don't generally support BGP4+ > > And you said you're not aware of anything in the spec that'd need > modification. Right.. My original preference was to *only* specify the BGP4+ model for 6to4. I was talked out of it. Brian From owner-v6ops@ops.ietf.org Thu Nov 21 20:20:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29897 for ; Thu, 21 Nov 2002 20:20:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F2We-000HAN-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 17:22:32 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18F2Wc-000HA7-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 17:22:30 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAM1MRo28669; Fri, 22 Nov 2002 03:22:27 +0200 Date: Fri, 22 Nov 2002 03:22:27 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-Reply-To: <3DDD85C8.6FE89102@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 22 Nov 2002, Brian E Carpenter wrote: > Pekka Savola wrote: > > > > On Fri, 22 Nov 2002, Brian E Carpenter wrote: > > > There are spoofing/DDOS risks in the host-based anycast 6to4 model > > > that has been implemented but never fully specified. > > > > Do not classify this as "host-based". There is nothing particularly > > host-based in this. > > Yes there is, because hosts don't generally support BGP4+ Wrong analogy. Very small amount of routers use BGP4+, and even fewer (none?) use it in the 6to4 context. > > And you said you're not aware of anything in the spec that'd need > > modification. Right.. > > My original preference was to *only* specify the BGP4+ model > for 6to4. I was talked out of it. That would have been an *entirely* different 6to4. One that would have gone the way to the 6over4, most probably. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 20:21:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29991 for ; Thu, 21 Nov 2002 20:21:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F2Xn-000HMv-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 17:23:43 -0800 Received: from d12lmsgate-4.de.ibm.com ([194.196.100.237]) by psg.com with esmtp (Exim 3.36 #2) id 18F2Xk-000HDk-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 17:23:40 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAM1N3eW073880; Fri, 22 Nov 2002 02:23:08 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAM1N3d1048906; Fri, 22 Nov 2002 02:23:03 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA69866 from ; Fri, 22 Nov 2002 02:22:54 +0100 Message-Id: <3DDD86CF.475BA56A@hursley.ibm.com> Date: Fri, 22 Nov 2002 02:22:23 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Jeroen Massar Cc: "'Pekka Savola'" , Alain.Durand@Sun.COM, v6ops@ops.ietf.org Subject: Re: 6to4 deployement issues - was 6to4 security questions References: <001001c291bf$0baec7a0$210d640a@unfix.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit RFC 3056 forbids announcing prefixes longer than 2002::/16, and instructs ISPs to filter them, to avoid polluting the IPv6 DFZ with IPv4 specifics. Brian Jeroen Massar wrote: > > Pekka Savola [mailto:pekkas@netcore.fi] wrote: > > > On Fri, 22 Nov 2002, Brian E Carpenter wrote: > > > > On Thu, 21 Nov 2002, Jeroen Massar wrote: > > > > > > please think that to the end, it will not work without > > > > > > re-specification _globally_. > > > > > > We don't want to restrict 6to4 to ISPs' walled gardens. > > > > > > > > > > One ISP can have a trust relation with another ISP and announce > > > > > the anycast prefix only to that other ISP so it can > > make use of it too. > > > > > Source address verification should then ofcourse be > > extended by the > > > > > other ISP's. This could be seen as a 'transit' type > > service, but then > > > > > between the v4 and v6 world ;) > > > > > > > > How will you send traffic from 2001:dead:beef::1 to > > 2002:0103:0405::1, if > > > > 2001:dead:beef::/48 is not within the trust boundary? > > > > > > Wrong question. The question is, does *any* 2002::/16 announcement > > > reach dead:beef's ISP? If yes, whichever relay is the origin of > > > that announcement will relay the traffic. The 2nd question > > is whether > > > that particular relay is trusted by 0103:0405's 6to4 router. > > > > Exactly. In Jeroen's model, I believe, the particular relay would > > particully never be trusted. > > That is exactly what I mean. > > > > > Any such model model is broken. > > Eek :) > > > 6to4 routers do not have any ways of knowing where traffic > > will be coming > > from, so discarding packets because they didn't come from your two > > favourite relays is *wrong*. > > Thats indeed true, fortunatly in the setup depicted below one > knows where packets should be coming from. > > > Propagating more specific routes etc. avoids this problem as > > you have only one "home" relay. > > Which where my thoughts exactly. > Indeed the origin 6to4 relay's ISP will announce the prefixes it > is willing to relay for, so the others can now where this relay > is located and send all the return traffic directly there. > That 6to4 relay can then send the traffic directly to the 6to4 node. > > One thing is that "local" traffic will go over that same relay too > even if it's in the same subnet. Maybe a check for "local subnet" > could be devised to overcome this problem. > > Eg, box-A = 10.1.2.3/24, box-B = 10.1.2.4/24, these are directly > connected > and should send the 6to4 packets directly too each other. > But when box-C has 192.168.1.2 this should go over the relay. > Basically it comes down to: > > 10.100.2.5/24 > [6to4 node A] <---+ > | 10.100.1.1 > +-----> [6to4 relay] <------> [IPv6 Internet] > 10.100.2.6/24 | > [6to4 node B] <---+ > > The relay announces 2002:0A64::/32 (10.100.0.0/16) > - Any node on the internet knows how to reach it. > - It only serves 10.100.0.0/16. > - "6to4 Transit" goes over native (or configured tunnels) IPv6. > - "Spoofing" is limited to the ISP, or the prefixes the 6to4 relay > trusts. > - 6to4 Anycast route is only available inside the ISP, or the ISPs it > trusts. > - Local traffic (6to4 node A <-> 6to4 node B) travels locally only. > This should save some traffic on the relay though it is not 100% > required. > > Ofcourse 10.x.x.x addresses can be replaced by real IP's, these are > examples. > > One could also see this approach as aggregating 6to4 traffic. > Eg I imagine a 6to4 relay one hop more to the right of the above picture > which carries for instance 10.0.0.0/8 which it announces to the > internet. > > Hope this clears it up a bit :) > > Greets, > Jeroen From owner-v6ops@ops.ietf.org Thu Nov 21 20:26:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00129 for ; Thu, 21 Nov 2002 20:26:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F2cD-000Ho8-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 17:28:17 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18F2c9-000HnK-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 17:28:14 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAM1S7h28716; Fri, 22 Nov 2002 03:28:07 +0200 Date: Fri, 22 Nov 2002 03:28:07 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Jeroen Massar , , Subject: Re: 6to4 deployement issues - was 6to4 security questions In-Reply-To: <3DDD86CF.475BA56A@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 22 Nov 2002, Brian E Carpenter wrote: > RFC 3056 forbids announcing prefixes longer than 2002::/16, > and instructs ISPs to filter them, to avoid polluting the > IPv6 DFZ with IPv4 specifics. Yes. .. which is why I proposed a model where 6to4 relays are interconnected using eBGP multihop peerings, and IPv6 DFZ would be safe, and everyone would be happy :-). > Jeroen Massar wrote: > > > > Pekka Savola [mailto:pekkas@netcore.fi] wrote: > > > > > On Fri, 22 Nov 2002, Brian E Carpenter wrote: > > > > > On Thu, 21 Nov 2002, Jeroen Massar wrote: > > > > > > > please think that to the end, it will not work without > > > > > > > re-specification _globally_. > > > > > > > We don't want to restrict 6to4 to ISPs' walled gardens. > > > > > > > > > > > > One ISP can have a trust relation with another ISP and announce > > > > > > the anycast prefix only to that other ISP so it can > > > make use of it too. > > > > > > Source address verification should then ofcourse be > > > extended by the > > > > > > other ISP's. This could be seen as a 'transit' type > > > service, but then > > > > > > between the v4 and v6 world ;) > > > > > > > > > > How will you send traffic from 2001:dead:beef::1 to > > > 2002:0103:0405::1, if > > > > > 2001:dead:beef::/48 is not within the trust boundary? > > > > > > > > Wrong question. The question is, does *any* 2002::/16 announcement > > > > reach dead:beef's ISP? If yes, whichever relay is the origin of > > > > that announcement will relay the traffic. The 2nd question > > > is whether > > > > that particular relay is trusted by 0103:0405's 6to4 router. > > > > > > Exactly. In Jeroen's model, I believe, the particular relay would > > > particully never be trusted. > > > > That is exactly what I mean. > > > > > > > > Any such model model is broken. > > > > Eek :) > > > > > 6to4 routers do not have any ways of knowing where traffic > > > will be coming > > > from, so discarding packets because they didn't come from your two > > > favourite relays is *wrong*. > > > > Thats indeed true, fortunatly in the setup depicted below one > > knows where packets should be coming from. > > > > > Propagating more specific routes etc. avoids this problem as > > > you have only one "home" relay. > > > > Which where my thoughts exactly. > > Indeed the origin 6to4 relay's ISP will announce the prefixes it > > is willing to relay for, so the others can now where this relay > > is located and send all the return traffic directly there. > > That 6to4 relay can then send the traffic directly to the 6to4 node. > > > > One thing is that "local" traffic will go over that same relay too > > even if it's in the same subnet. Maybe a check for "local subnet" > > could be devised to overcome this problem. > > > > Eg, box-A = 10.1.2.3/24, box-B = 10.1.2.4/24, these are directly > > connected > > and should send the 6to4 packets directly too each other. > > But when box-C has 192.168.1.2 this should go over the relay. > > Basically it comes down to: > > > > 10.100.2.5/24 > > [6to4 node A] <---+ > > | 10.100.1.1 > > +-----> [6to4 relay] <------> [IPv6 Internet] > > 10.100.2.6/24 | > > [6to4 node B] <---+ > > > > The relay announces 2002:0A64::/32 (10.100.0.0/16) > > - Any node on the internet knows how to reach it. > > - It only serves 10.100.0.0/16. > > - "6to4 Transit" goes over native (or configured tunnels) IPv6. > > - "Spoofing" is limited to the ISP, or the prefixes the 6to4 relay > > trusts. > > - 6to4 Anycast route is only available inside the ISP, or the ISPs it > > trusts. > > - Local traffic (6to4 node A <-> 6to4 node B) travels locally only. > > This should save some traffic on the relay though it is not 100% > > required. > > > > Ofcourse 10.x.x.x addresses can be replaced by real IP's, these are > > examples. > > > > One could also see this approach as aggregating 6to4 traffic. > > Eg I imagine a 6to4 relay one hop more to the right of the above picture > > which carries for instance 10.0.0.0/8 which it announces to the > > internet. > > > > Hope this clears it up a bit :) > > > > Greets, > > Jeroen > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 20:42:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00764 for ; Thu, 21 Nov 2002 20:42:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F2rs-000JLl-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 17:44:28 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18F2rp-000JKh-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 17:44:25 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 5D46C78DD; Fri, 22 Nov 2002 02:44:45 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id B0F2C78D0; Fri, 22 Nov 2002 02:44:40 +0100 (CET) From: "Jeroen Massar" To: Cc: "'Pekka Savola'" , "'Brian E Carpenter'" , Subject: RE: 6to4 deployement issues - was 6to4 security questions Date: Fri, 22 Nov 2002 02:44:55 +0100 Organization: Unfix Message-ID: <002001c291c8$c2e24290$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: <3DDD8415.3080907@sun.com> X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA00764 Alain.Durand@Sun.COM [mailto:Alain.Durand@Sun.COM] wrote: > You understand that the model you suggest will: > - not scale because it basically requires advertizing /32 in IPv4 BGP > tables... For what do you want to advertise a /32 ? The anycast address is local, so that doesn't cause any problems and is already being deployed, except for the fact that they serve globally. One will have to 'replicate' all IPv4 routes into the IPv6 routing table, which is as I mentioned in the other mails one of the disadvantages. Fortunatly I expect, though ofcourse that has to be seen and time would tell, that not many ISP's will setup a 6to4 router, especially if it goes on like current events. Note also that links that have native capability won't have to be announced. But this is indeed a serious disadvantage. > - will not enable an automatic deployment model a la Microsoft > where any host in the Internet can automatically be turned into a > 6to4 router. No, it will as long as the upstream ISP works along, if they don't one indeed can't use it. One could see this is an adminstrative policy where an ISP doens't allow certain traffic etc. Unfortunatly this blocks the spreading and use of IPv6 by using 6to4, but abuse-solutions usually inhibits use of good technologies. ISP's who really want to do IPv6 will need to have a upstream IPv6 connection. Otherwise the 6to4 traffic would travel over several third party networks anyways. And seeing the current deployment of 6to4 relays that doesn't seem very good. I personally don't see another way to solve the problem at hand, being the abuse. This trick does have a couple of advantages but ofcourse those come along with disadvantages. I also think that people who really want to use IPv6 can have the incentive to sign up at the various tunnelbrokering systems. 6to4 in this way though would be really nice for what Joshua described, just plug it in, no RA response, then try and reach a 6to4 router. At least when it's 'hosted' by the ISP itself (or a neighbouring one) it will quite close. Tunnelbrokering systems can ofcourse also be deployed this way. Freenet6 for example can do it all automatically with their so called 'anonymous' tunnels and a handy tool which the user installs. If anyone has a good idea yell it out, ofcourse this is just one of my mind rumblings. Greets, Jeroen From owner-v6ops@ops.ietf.org Thu Nov 21 20:43:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00796 for ; Thu, 21 Nov 2002 20:43:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F2tW-000JRH-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 17:46:10 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18F2tU-000JR4-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 17:46:08 -0800 Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05082 for ; Thu, 21 Nov 2002 18:46:07 -0700 (MST) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5Y00N91FKU4I@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 18:46:07 -0700 (MST) Received: from sun.com ([204.42.66.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H5Y00J1WFKGOE@mail.sun.net> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 18:46:06 -0700 (MST) Date: Thu, 21 Nov 2002 17:45:58 -0800 From: Alain Durand Subject: Re: 6to4 deployement issues - was 6to4 security questions To: Pekka Savola Cc: Brian E Carpenter , Jeroen Massar , v6ops@ops.ietf.org Message-id: <3DDD8C56.4030608@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Pekka Savola wrote: >On Fri, 22 Nov 2002, Brian E Carpenter wrote: > > >>RFC 3056 forbids announcing prefixes longer than 2002::/16, >>and instructs ISPs to filter them, to avoid polluting the >>IPv6 DFZ with IPv4 specifics. >> >> > >Yes. > >.. which is why I proposed a model where 6to4 relays are interconnected >using eBGP multihop peerings, and IPv6 DFZ would be safe, and everyone >would be happy :-). > How does this help a 6to4 router to check if the packet is coming from a legitimate 6to4 relay? - Alain. From owner-v6ops@ops.ietf.org Thu Nov 21 20:48:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01020 for ; Thu, 21 Nov 2002 20:48:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F2y4-000Joy-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 17:50:52 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18F2y0-000JoX-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 17:50:48 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAM1og828921; Fri, 22 Nov 2002 03:50:42 +0200 Date: Fri, 22 Nov 2002 03:50:42 +0200 (EET) From: Pekka Savola To: Alain Durand cc: Brian E Carpenter , Jeroen Massar , Subject: Re: 6to4 deployement issues - was 6to4 security questions In-Reply-To: <3DDD8C56.4030608@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 21 Nov 2002, Alain Durand wrote: > >>RFC 3056 forbids announcing prefixes longer than 2002::/16, > >>and instructs ISPs to filter them, to avoid polluting the > >>IPv6 DFZ with IPv4 specifics. > >> > >> > > > >Yes. > > > >.. which is why I proposed a model where 6to4 relays are interconnected > >using eBGP multihop peerings, and IPv6 DFZ would be safe, and everyone > >would be happy :-). > > > > How does this help a 6to4 router to check if the packet is coming from > a legitimate 6to4 relay? Read the draft. Under this assumption, (most) packets from native internet are only tunneled from your home relay -- some IP address you've configured, some security association you've done etc. This assumes enough relays take part in this more-specifics mesh, and outright discarding packets could not be done in the startup phase. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 20:49:34 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01056 for ; Thu, 21 Nov 2002 20:49:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F2zF-000JvF-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 17:52:05 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18F2zC-000Jus-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 17:52:03 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gAM1ptm12800; Fri, 22 Nov 2002 02:51:55 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gAM1ptte041146; Fri, 22 Nov 2002 02:51:55 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211220151.gAM1ptte041146@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: Alain Durand , Erik Nordmark , Jason Goldschmidt , Pekka Savola , v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-reply-to: Your message of Fri, 22 Nov 2002 00:51:54 +0100. <3DDD719A.A2E0D306@hursley.ibm.com> Date: Fri, 22 Nov 2002 02:51:55 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > => this is a heavy solution (6to4 is supposed to be automatic and > not require BGP4+ skills) This author of 6to4 *never* said that. => I know but many 6to4 supporters said exactly that. > which secures only one way. Indeed. You need BGP peering on both sides of the relay. => I'd like to know how? > The security issue is a rogue 6to4 relay which uses 6to4 boxes behind > 6to4 routers to reflect traffic to poor IPv6 nodes. Exactly. So the 6to4 routers should only accept packets from BGP peers. It may be heavyweight, but it is not mysterious. => how you can archieve this: - a random native IPv6 source with a packet for a 6to4 node knows the 6to4 relay associated to the 6to4 destination. The obvious way to do this is to inject a part of the IPv4 routing into the 2002:: prefix, i.e., something we must not do. - same but between 6to4 relays (i.e., the pollution is constraint to the 6to4 relay set). It should work but it will become very hard to find ISPs which accept to run a 6to4 relay. IMHO this relay problem makes 6to4 usable only to transit (?) an IPv4 internet to IPv6 (all IPv6 islands will be 6to4, no need for relays) (cf a comment from a Sun guy doing exactly this for the internal Sun internet) Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Thu Nov 21 21:12:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01891 for ; Thu, 21 Nov 2002 21:12:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F3KJ-000Lvn-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 18:13:51 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18F3KG-000LvT-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 18:13:49 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAM2DkS29302 for ; Fri, 22 Nov 2002 04:13:46 +0200 Date: Fri, 22 Nov 2002 04:13:46 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 6to4 usage scenarios Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, It seems like the 6to4 security discussion degenerated into argument on how it was meant to be used. There are two basic models of connecting 6to4 routers to relays: 1) simple static route to your relay 2) BGP sessions to your relay and all the other relays where you want to receive native IPv6 packets from I know of _no_ deployments of 2) even though Brian insists on that being the only "real" 6to4 usage scenario. Does anyone know this being used? If not, I think we must acknowledge that 2) is not really right-tool-for-the-job (think of 6over4 **), and that 1) is the primary (only?) applicability target of 6to4. The alternative is that we have gaping holes in Home/SOHO and partially maybe enterprise transition scenarios, and nothing to fill them at the moment. **) 6over4 is a nice technique, and we could even use it -- but we don't want stuff like that. The same IMO applies to 6to4+BGP. There is no use specifying mechanisms for the audience who does not want them. P.S. I only came to the wg after 6to4 had just gone RFC, this internal bickering really took me off surprise and made me both frustrated and angry about refusing to accept the reality. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 21:27:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02319 for ; Thu, 21 Nov 2002 21:27:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F3Yp-000NPq-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 18:28:51 -0800 Received: from web13007.mail.yahoo.com ([216.136.174.17]) by psg.com with smtp (Exim 3.36 #2) id 18F3Yn-000NPe-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 18:28:49 -0800 Message-ID: <20021122022848.62415.qmail@web13007.mail.yahoo.com> Received: from [204.42.68.8] by web13007.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 18:28:48 PST Date: Thu, 21 Nov 2002 18:28:48 -0800 (PST) From: Fred Templin Subject: Re: 6to4 deployement issues - was 6to4 security questions To: Alain Durand , Pekka Savola Cc: Brian E Carpenter , Jeroen Massar , v6ops@ops.ietf.org In-Reply-To: <3DDD8C56.4030608@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.5 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,MAILTO_TO_SPAM_ADDR, QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Alain, --- Alain Durand wrote: > How does this help a 6to4 router to check if the packet is coming from > a legitimate 6to4 relay? > > - Alain. Tim Gleeson and I were just talking about the 6to4 open relay issue. If router A sends traffic out thru relay B but gets return traffic back thru relay C we have the open relay situation. Since everything is just IPv6 over IPv4 as a link layer, can we possibly leverage neighbor discovery to set up some sort of security association along the forward and reverse paths? I've been working on a scheme that can provide path mtu discovery based on a "three way handshake" using neighbor discovery, and I've wondered if/how a security association could be added to the negotiation. Any thoughts on this? Fred Templin osprey67@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-v6ops@ops.ietf.org Thu Nov 21 21:29:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02461 for ; Thu, 21 Nov 2002 21:29:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F3bn-000NhF-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 18:31:55 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18F3bk-000Ngr-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 18:31:52 -0800 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26848 for ; Thu, 21 Nov 2002 19:31:51 -0700 (MST) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5Y00JEJHP3XC@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 19:31:51 -0700 (MST) Received: from sun.com ([204.42.66.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H5Y00J8THP1OE@mail.sun.net> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 19:31:51 -0700 (MST) Date: Thu, 21 Nov 2002 18:31:56 -0800 From: Alain Durand Subject: Re: 6to4 usage scenarios To: Pekka Savola Cc: v6ops@ops.ietf.org Message-id: <3DDD971C.9050708@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT You're basically right. - Alain. Pekka Savola wrote: >Hello, > >It seems like the 6to4 security discussion degenerated into argument on >how it was meant to be used. > >There are two basic models of connecting 6to4 routers to relays: > >1) simple static route to your relay >2) BGP sessions to your relay and all the other relays where you want to >receive native IPv6 packets from > >I know of _no_ deployments of 2) even though Brian insists on that being >the only "real" 6to4 usage scenario. Does anyone know this being used? > >If not, I think we must acknowledge that 2) is not really >right-tool-for-the-job (think of 6over4 **), and that 1) is the primary >(only?) applicability target of 6to4. > >The alternative is that we have gaping holes in Home/SOHO and partially >maybe enterprise transition scenarios, and nothing to fill them at the >moment. > >**) 6over4 is a nice technique, and we could even use it -- but we don't >want stuff like that. The same IMO applies to 6to4+BGP. There is no use >specifying mechanisms for the audience who does not want them. > >P.S. I only came to the wg after 6to4 had just gone RFC, this internal >bickering really took me off surprise and made me both frustrated and >angry about refusing to accept the reality. > > > From owner-v6ops@ops.ietf.org Thu Nov 21 21:36:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02871 for ; Thu, 21 Nov 2002 21:36:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F3hg-000OGk-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 18:38:00 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #2) id 18F3hd-000OEO-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 18:37:57 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAM2bJC3018868; Fri, 22 Nov 2002 03:37:19 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAM2bI71093186; Fri, 22 Nov 2002 03:37:19 +0100 Received: from gsine08.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA66354 from ; Fri, 22 Nov 2002 03:37:15 +0100 Message-Id: <3DDD9845.9F40F9E7@hursley.ibm.com> Date: Fri, 22 Nov 2002 03:36:53 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: 6to4 usage scenarios References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, I'm not blind- I am quite aware that the BGP4+ scenario is not deployed. I simply wanted to make it clear that when we designed 6to4, we did think about the need to establish some sort of relationship between relays and their "customer" routers. It doesn't surprise me that we've now discovered that such a relationship is needed to reduce the spoofing risk. Any suggestions on how to create such a relationship? Brian Pekka Savola wrote: > > Hello, > > It seems like the 6to4 security discussion degenerated into argument on > how it was meant to be used. > > There are two basic models of connecting 6to4 routers to relays: > > 1) simple static route to your relay > 2) BGP sessions to your relay and all the other relays where you want to > receive native IPv6 packets from > > I know of _no_ deployments of 2) even though Brian insists on that being > the only "real" 6to4 usage scenario. Does anyone know this being used? > > If not, I think we must acknowledge that 2) is not really > right-tool-for-the-job (think of 6over4 **), and that 1) is the primary > (only?) applicability target of 6to4. > > The alternative is that we have gaping holes in Home/SOHO and partially > maybe enterprise transition scenarios, and nothing to fill them at the > moment. > > **) 6over4 is a nice technique, and we could even use it -- but we don't > want stuff like that. The same IMO applies to 6to4+BGP. There is no use > specifying mechanisms for the audience who does not want them. > > P.S. I only came to the wg after 6to4 had just gone RFC, this internal > bickering really took me off surprise and made me both frustrated and > angry about refusing to accept the reality. From owner-v6ops@ops.ietf.org Thu Nov 21 21:38:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02928 for ; Thu, 21 Nov 2002 21:38:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F3l2-000Oe3-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 18:41:28 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18F3l0-000OdB-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 18:41:26 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id gAM2fMm13454; Fri, 22 Nov 2002 03:41:22 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id gAM2fMte041591; Fri, 22 Nov 2002 03:41:22 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200211220241.gAM2fMte041591@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Fred Templin cc: Alain Durand , Pekka Savola , Brian E Carpenter , Jeroen Massar , v6ops@ops.ietf.org Subject: Re: 6to4 deployement issues - was 6to4 security questions In-reply-to: Your message of Thu, 21 Nov 2002 18:28:48 PST. <20021122022848.62415.qmail@web13007.mail.yahoo.com> Date: Fri, 22 Nov 2002 03:41:22 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: I've been working on a scheme that can provide path mtu discovery based on a "three way handshake" using neighbor discovery, and I've wondered if/how a security association could be added to the negotiation. Any thoughts on this? => have a look on opportunistic encryption? (draft-richardson-ipsec-opportunistic-10.txt) Francis.Dupont@enst-bretagne.fr PS: there was a demo of a running implemetation of OE some days ago. From owner-v6ops@ops.ietf.org Thu Nov 21 21:52:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03150 for ; Thu, 21 Nov 2002 21:52:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F3xl-000Prb-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 18:54:37 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18F3xj-000PrN-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 18:54:35 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAM2sWY29651; Fri, 22 Nov 2002 04:54:32 +0200 Date: Fri, 22 Nov 2002 04:54:32 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: v6ops@ops.ietf.org Subject: Re: 6to4 usage scenarios In-Reply-To: <3DDD9845.9F40F9E7@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 22 Nov 2002, Brian E Carpenter wrote: > I'm not blind- I am quite aware that the BGP4+ scenario is > not deployed. I simply wanted to make it clear that when we > designed 6to4, we did think about the need to establish some sort > of relationship between relays and their "customer" routers. > It doesn't surprise me that we've now discovered that such > a relationship is needed to reduce the spoofing risk. Ok -- such stressing seemed like denying the problem, "this should not have happened if you did XXX like we were supposed to ". It seems apparent that static routes were probably added as a patch at a later stage, and peopled failed to see a change in the big picture. But this is irrelevant. > Any suggestions on how to create such a relationship? I think section 6.3.2 of my draft discusses (very roughly) one approach at the problem. Of course, it still needs a lot of work if it's seen as an approach worth investigating more. This is something I'd like feedback on. Some others have been proposed too. (IMO, I believe a solution like neighbor affiliation is not really scalable in the global case.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 22:15:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03579 for ; Thu, 21 Nov 2002 22:15:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F4JL-00025L-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 19:16:55 -0800 Received: from web13002.mail.yahoo.com ([216.136.174.12]) by psg.com with smtp (Exim 3.36 #2) id 18F4JI-00024y-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 19:16:52 -0800 Message-ID: <20021122031651.94128.qmail@web13002.mail.yahoo.com> Received: from [204.42.68.8] by web13002.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 19:16:51 PST Date: Thu, 21 Nov 2002 19:16:51 -0800 (PST) From: Fred Templin Subject: Re: 6to4 deployement issues - was 6to4 security questions To: Francis Dupont Cc: Alain Durand , Pekka Savola , Brian E Carpenter , Jeroen Massar , v6ops@ops.ietf.org In-Reply-To: <200211220241.gAM2fMte041591@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.1 required=5.0 tests=FROM_ENDS_IN_NUMS,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Francis, Thanks for this - I've pulled the draft. I'm wondering if it will be light-weight enough for what I have in mind, however. Fred Templin --- Francis Dupont wrote: > In your previous mail you wrote: > > I've been working on a scheme that can provide path mtu discovery based > on a "three way handshake" using neighbor discovery, and I've wondered > if/how a security association could be added to the negotiation. > > Any thoughts on this? > > => have a look on opportunistic encryption? > (draft-richardson-ipsec-opportunistic-10.txt) > > Francis.Dupont@enst-bretagne.fr > > PS: there was a demo of a running implemetation of OE some days ago. > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From owner-v6ops@ops.ietf.org Thu Nov 21 22:38:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04192 for ; Thu, 21 Nov 2002 22:38:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F4f4-0004EA-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 19:39:22 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18F4f2-0004DZ-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 19:39:20 -0800 Received: from esunmail ([129.147.58.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA00755 for ; Thu, 21 Nov 2002 20:39:19 -0700 (MST) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5Y004R7KTIKY@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 20:39:19 -0700 (MST) Received: from sun.com ([204.42.66.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H5Y00D6VKTDN9@mail.sun.net> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 20:39:17 -0700 (MST) Date: Thu, 21 Nov 2002 19:39:20 -0800 From: Alain Durand Subject: Re: 6to4 usage scenarios To: Pekka Savola Cc: Brian E Carpenter , v6ops@ops.ietf.org Message-id: <3DDDA6E8.7000902@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: X-Spam-Status: No, hits=-1.0 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Pekka Savola wrote >>Any suggestions on how to create such a relationship? >> >> > >I think section 6.3.2 of my draft discusses (very roughly) one approach at >the problem. > This could be done by forming eBGP [BGP] multi-hop peerings between Relays, and advertising more specific routes (e.g. the same superblocks of IPv4 addresses one expects to service) to all the other Routers. This is where I doubt it works. As you pointed out in your draft, it requires (strong)cooperation among all the relays, but worse, it requires complete coverage of the IPv4 space. And again, how will the 6to4 router knows the valid IPv4 address of the relay it is associated with (if the router has used the well known anycast addr to discover the relay)? - Alain. From owner-v6ops@ops.ietf.org Thu Nov 21 22:52:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04521 for ; Thu, 21 Nov 2002 22:52:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F4tB-0005bi-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 19:53:57 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18F4t8-0005af-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 19:53:55 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAM3rnZ30161; Fri, 22 Nov 2002 05:53:49 +0200 Date: Fri, 22 Nov 2002 05:53:49 +0200 (EET) From: Pekka Savola To: Alain Durand cc: Brian E Carpenter , Subject: Re: 6to4 usage scenarios In-Reply-To: <3DDDA6E8.7000902@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 21 Nov 2002, Alain Durand wrote: > >I think section 6.3.2 of my draft discusses (very roughly) one approach at > >the problem. > > > This could be done by forming eBGP > [BGP] multi-hop peerings between Relays, and advertising more > specific routes (e.g. the same superblocks of IPv4 addresses one > expects to service) to all the other Routers. > > This is where I doubt it works. As you pointed out in your draft, > it requires (strong)cooperation among all the relays, but worse, > it requires complete coverage of the IPv4 space. Yeah, this is a problem. But you can approach this many ways, my view is: 1) identify the current status, document the threats 2) make up a way to lessen these threats (they cannot completely go away) 3) if people are worried about the spoofing problem, _expect them to contact their home relay, and make it to advertise their prefix_. If the person doesn't care.. can't help anyway. But there are some ways to help here a bit: - it is desirable to have strong co-operation, but it's not _necessary_, only if you want a higher level of security (the rest just work as before) - ISP's providing 6to4 relay as a real service are more likely to have a stricter list of prefixes the ISP serves -- and configuring static routes is easier - some more specifics can even be automatically generated e.g. from RADB/RIPE route databases - we could develop a very simple protocol/process (could be just a triggering packet or whatnot) to make the home relay start automatically advertise a prefix > And again, how will the 6to4 router knows the valid IPv4 address > of the relay it is associated with (if the router has used the well > known anycast addr > to discover the relay)? 1) the relay may use 192.88.99.1 as the souce address (our relay does that) 2) if not, a simple ping to that address or manual equivalent should reveal this As you note, there are quite a few problems to be ironed out, but it just _might_ work. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 21 23:02:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04788 for ; Thu, 21 Nov 2002 23:02:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18F537-0006XZ-00 for v6ops-data@psg.com; Thu, 21 Nov 2002 20:04:13 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18F533-0006XD-00 for v6ops@ops.ietf.org; Thu, 21 Nov 2002 20:04:09 -0800 Received: from esunmail ([129.147.58.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29699 for ; Thu, 21 Nov 2002 21:04:09 -0700 (MST) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H5Y00027LYWRI@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 21:04:09 -0700 (MST) Received: from sun.com ([204.42.66.42]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H5Y00JKCLYTOE@mail.sun.net> for v6ops@ops.ietf.org; Thu, 21 Nov 2002 21:04:07 -0700 (MST) Date: Thu, 21 Nov 2002 20:04:12 -0800 From: Alain Durand Subject: Re: 6to4 usage scenarios To: Pekka Savola Cc: Brian E Carpenter , v6ops@ops.ietf.org Message-id: <3DDDACBC.1080202@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Pekka Savola wrote: >But there are some ways to help here a bit: > - it is desirable to have strong co-operation, but it's not _necessary_, >only if you want a higher level of security (the rest just work as before) > - ISP's providing 6to4 relay as a real service are more likely to have a >stricter list of prefixes the ISP serves -- and configuring static routes >is easier > Remember: the threat that we are discussing is not impacting _my_ 6to4 site. It enables an attacker to abuse my and many other 6to4 hosts elsewhere in the Internet to arm a victim in the native v6 Internet. - Alain. From owner-v6ops@ops.ietf.org Fri Nov 22 09:02:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25143 for ; Fri, 22 Nov 2002 09:02:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FELu-000PIn-00 for v6ops-data@psg.com; Fri, 22 Nov 2002 06:00:14 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18FELr-000PIN-00 for v6ops@ops.ietf.org; Fri, 22 Nov 2002 06:00:11 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAMDxwf02004; Fri, 22 Nov 2002 15:59:58 +0200 Date: Fri, 22 Nov 2002 15:59:57 +0200 (EET) From: Pekka Savola To: Alain Durand cc: Brian E Carpenter , Subject: Re: 6to4 usage scenarios In-Reply-To: <3DDDACBC.1080202@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 21 Nov 2002, Alain Durand wrote: > >But there are some ways to help here a bit: > > - it is desirable to have strong co-operation, but it's not _necessary_, > >only if you want a higher level of security (the rest just work as before) > > - ISP's providing 6to4 relay as a real service are more likely to have a > >stricter list of prefixes the ISP serves -- and configuring static routes > >is easier > > > > Remember: the threat that we are discussing is not impacting _my_ 6to4 site. The threat I'm discussing has many implications. One is that it allows unidirectional, untraceable address spoofing (consider e.g. an exploit for a security vulnerability in a UDP service). The other is that it allows sites to be used as packet reflectors, as you said... (this is really similar to HAO/RH spoofing but more difficult to fix; see the expired draft-savola-ipv6-rh-ha-security-02.txt for more text on that. Thanks Francis.) > It enables an attacker to abuse my and many other 6to4 hosts > elsewhere in the Internet to arm a victim in the native v6 Internet. .. but that's not really nothing new -- pretty much what you can do today with regular spoofing, and we'll probably never be able to eliminate all of that. The difference is that it is more difficult to trace and it can be initiated by the hosts who are v4 or v6 ingress filtered. I don't think all the threats in _any_ automatic tunneling mechanism can be neutralized except by heavy packet exchange which usually makes the mechanism unusable. We'll just have to analyse what those are and decide the acceptable level security (or consider the whole mechanism a no-go). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Fri Nov 22 14:58:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02903 for ; Fri, 22 Nov 2002 14:58:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FJwQ-000Nos-00 for v6ops-data@psg.com; Fri, 22 Nov 2002 11:58:18 -0800 Received: from nat-63-99-114-2.tahoenetworks.com ([63.99.114.2] helo=TNEXVS01.tahoenetworks.com) by psg.com with esmtp (Exim 3.36 #2) id 18FJwO-000Nog-00 for v6ops@ops.ietf.org; Fri, 22 Nov 2002 11:58:16 -0800 Received: from TNEXVS02.tahoenetworks.com ([10.10.1.132]) by TNEXVS01.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 22 Nov 2002 11:58:15 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 6to4 usage scenarios x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 22 Nov 2002 11:58:09 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A340@TNEXVS02.tahoenetworks.com> Thread-Topic: 6to4 usage scenarios Thread-Index: AcKSMjyrGj0MRrx2TqSnW+LKGqSiQQAI6JSg From: "Mohan Parthasarathy" To: "Pekka Savola" , "Alain Durand" Cc: "Brian E Carpenter" , X-OriginalArrivalTime: 22 Nov 2002 19:58:15.0479 (UTC) FILETIME=[7EB0BC70:01C29261] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA02903 Pekka, > > On Thu, 21 Nov 2002, Alain Durand wrote: > > >But there are some ways to help here a bit: > > > - it is desirable to have strong co-operation, but it's not > > >_necessary_, > > >only if you want a higher level of security (the rest just > work as before) > > > - ISP's providing 6to4 relay as a real service are more > likely to have a > > >stricter list of prefixes the ISP serves -- and > configuring static routes > > >is easier > > > > > > > Remember: the threat that we are discussing is not > impacting _my_ 6to4 > > site. > > The threat I'm discussing has many implications. One is that > it allows unidirectional, untraceable address spoofing > (consider e.g. an exploit for a security vulnerability in a > UDP service). The other is that it allows sites to be used > as packet reflectors, as you said... > > (this is really similar to HAO/RH spoofing but more difficult > to fix; see the expired > draft-savola-ipv6-rh-ha-security-02.txt for more text on that. > Thanks Francis.) > I looked at your examples in section A.3, which talks about reflection attack against IPv4 nodes and IPv6 nodes using relay routers : src = X dst = Y src_v4 = 8.0.0.1 dst_v4 = 9.0.0.2 If Y is 2002:0500:0001::1, you mention that target 5.0.0.1 would be bombed with reflected packets from 6to4 relay router. This happens because the relay router decapsulated the packet (removing src_v4 and dst_v4) and then *again* encapsulated in 6to4. As a relay router SHOULD not be doing this, can we not catch this case ? I agree that sending to a native V6 address with a forged source V6 address is a problem. But it is essentially the same problem as not being able to trace back as mentioned in A.1. I am just trying to understand which threats we are trying to address here. The only thing that seems seruous to me is the IPv6 spoofing and access control avoidance threat in your draft. (It might be better if you can move all the attacks to the main section and list the possible solution together with it). -mohan > > It enables an attacker to abuse my and many other 6to4 > hosts elsewhere > > in the Internet to arm a victim in the native v6 Internet. > > .. but that's not really nothing new -- pretty much what you > can do today with regular spoofing, and we'll probably never > be able to eliminate all of that. The difference is that it > is more difficult to trace and it can be initiated by the > hosts who are v4 or v6 ingress filtered. > > I don't think all the threats in _any_ automatic tunneling > mechanism can be neutralized except by heavy packet exchange > which usually makes the mechanism unusable. We'll just have > to analyse what those are and decide the acceptable level > security (or consider the whole mechanism a no-go). > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > From owner-v6ops@ops.ietf.org Fri Nov 22 16:41:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04803 for ; Fri, 22 Nov 2002 16:41:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FLZr-0005UQ-00 for v6ops-data@psg.com; Fri, 22 Nov 2002 13:43:07 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18FLZQ-0005U7-00 for v6ops@ops.ietf.org; Fri, 22 Nov 2002 13:42:40 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18FLZP-0000Ip-00 for v6ops@ops.ietf.org; Fri, 22 Nov 2002 13:42:39 -0800 Message-ID: <20021121183850.9135.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 21 Nov 2002 18:38:50 -0000 Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: v6ops@ops.ietf.org Subject: why I'm not implementing IPv6 X-Spam-Status: No, hits=3.7 required=5.0 tests=NO_MX_FOR_FROM,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: *** Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] In short: the same reasons I didn't implement OSI. In detail: http://cr.yp.to/djbdns/ipv6mess.html ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago From owner-v6ops@ops.ietf.org Fri Nov 22 16:41:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04818 for ; Fri, 22 Nov 2002 16:41:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FLa5-0005Un-00 for v6ops-data@psg.com; Fri, 22 Nov 2002 13:43:21 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18FLa3-0005Ua-00 for v6ops@ops.ietf.org; Fri, 22 Nov 2002 13:43:19 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18FLa2-0000Iu-00 for v6ops@ops.ietf.org; Fri, 22 Nov 2002 13:43:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021121185329.GB2128@SBRIM-W2K1> References: <10253366.1037879557@Klensin-VAIO.ietf55.ops.ietf.org> To: v6ops@ops.ietf.org From: sbrim@cisco.com (Scott W Brim) Subject: Re: Comments and alternatives to draftt-huston-ietf-pact-00 (long) NNTP-Posting-Date: 21 Nov 2002 19:32:42 GMT Date: Thu, 21 Nov 2002 19:32:43 +0000 (UTC) X-Spam-Status: No, hits=0.1 required=5.0 tests=REFERENCES,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] John, I like what you say, but I would like to see it less formal. I have encouraged ADs to have groups of personal trusted professional assistants (not just area secretariats, although there could be overlap), who could take care of all the tasks you suggest for offloading. ..Scott - This message was passed through ietf_censored@carmen.ipv6.cselt.it, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio. From owner-v6ops@ops.ietf.org Fri Nov 22 21:32:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09986 for ; Fri, 22 Nov 2002 21:32:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FQ73-0002OU-00 for v6ops-data@psg.com; Fri, 22 Nov 2002 18:33:41 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with esmtp (Exim 3.36 #2) id 18FQ6z-0002J0-00 for v6ops@ops.ietf.org; Fri, 22 Nov 2002 18:33:37 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 22 Nov 2002 18:32:57 -0800 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Nov 2002 18:33:10 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Fri, 22 Nov 2002 18:32:52 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 22 Nov 2002 18:33:04 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Fri, 22 Nov 2002 18:33:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 6to4 security questions Date: Fri, 22 Nov 2002 18:33:03 -0800 Message-ID: Thread-Topic: 6to4 security questions Thread-Index: AcKR+OtYtasEX6+yTBWEZpHln4sVYAAnIL8w From: "Christian Huitema" To: "Brian E Carpenter" , "Pekka Savola" Cc: X-OriginalArrivalTime: 23 Nov 2002 02:33:10.0847 (UTC) FILETIME=[AA3AF4F0:01C29298] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA09986 Reading this thread, it seems that many people are confusing several aspects of the 6to4 security issue. Maybe we should start by writing a complete security analysis, something a bit more detailed than the current draft. In any case, let's look at the reflection attack. The attack to which we kept being pointed is the following: a random host sends a packet to an IPv6 server listening to a 6to4 address through a 6to4 router (not to a 6to4 relay); the IPv6 server sends a response packet to the (forged) IPv6 source address of the incoming packet. The vulnerability is that, with this mechanism, a DOS attacker can use an IPv6 server listening on a 6to4 address to "launder" a DOS attack launched against an IPv6 site: the IPv6 packets will not contain any trace of the original IPv4 address from which the attack was launched. Clearly, that is bad. There are however a number of mitigating factors: 1) The attack does not include a multiplier effect; the amount of traffic directed at the target will be about equal to the amount of traffic sent by the attacker. 2) The attack packets go through a choke point, the 6to4 relay between the laundering site and the target. 3) The packets received by the target contain the address of the relaying 6to4 site. 4) The payload of the packets received by the target will be a response generated by the laundering server, which limits any "magic packet" issue. 5) The attack only provides value if the attacker's IPv4 connection was subject to ingress filtering, which is alas not a very common case. Because of the absence of a magic packet effect, this attack is only really powerful if it is practiced by a "fleet of zombies" using a large number of reflectors. I personally don't think that fleets of zombies can be practically eliminated by simply observing their IPv4 addresses. I also don't think that the attacker whose virus managed to enslave a large number of zombies particularly cares that these zombies will be eventually discovered; in practice, the zombies are expandable. I suspect that the attacker will rather forgo the reflection exercise, because an attack in which the content of packets can be chosen is more powerful than an attack in which the source of packets can be hidden. In any case, given a large enough fleet of zombies, it is statistically likely that many zombies will not be submitted to IPv4 ingress filtering; those who are can very often randomize at least some bits of their source address, mimicking another fellow on the same LAN. In short, yes it is a vulnerability, but it is not a terribly dangerous one, and it is a vulnerability that will in any case disappear with 6to4, when sites receive native IPv6 connectivity. So, yes, a fix is welcome; however, the fix should not be so drastic as to impede the "autonomous deployment" advantage of 6to4. -- Christian Huitema From owner-v6ops@ops.ietf.org Sat Nov 23 09:52:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29726 for ; Sat, 23 Nov 2002 09:52:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Fbdl-000HAt-00 for v6ops-data@psg.com; Sat, 23 Nov 2002 06:52:13 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Fbdi-000HAe-00 for v6ops@ops.ietf.org; Sat, 23 Nov 2002 06:52:10 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gANEpYD12364; Sat, 23 Nov 2002 16:51:34 +0200 Date: Sat, 23 Nov 2002 16:51:33 +0200 (EET) From: Pekka Savola To: Mohan Parthasarathy cc: Alain Durand , Brian E Carpenter , Subject: RE: 6to4 usage scenarios In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A340@TNEXVS02.tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 22 Nov 2002, Mohan Parthasarathy wrote: > I looked at your examples in section A.3, which talks about > reflection attack against IPv4 nodes and IPv6 nodes using > relay routers : > > src = X > dst = Y > src_v4 = 8.0.0.1 > dst_v4 = 9.0.0.2 > > If Y is 2002:0500:0001::1, you mention that target 5.0.0.1 > would be bombed with reflected packets from 6to4 relay router. > This happens because the relay router decapsulated the packet > (removing src_v4 and dst_v4) and then *again* encapsulated > in 6to4. Right. > As a relay router SHOULD not be doing this, can > we not catch this case ? I agree that sending to a native > V6 address with a forged source V6 address is a problem. Yes, this can be caught easily (the way is shown in the draft), but practise has shown most relays don't do this. > But it is essentially the same problem as not being able > to trace back as mentioned in A.1. I am just trying to understand > which threats we are trying to address here. > > The only thing that seems seruous to me is the IPv6 spoofing > and access control avoidance threat in your draft. (It might > be better if you can move all the attacks to the main section > and list the possible solution together with it). Right, I'm not that worried about some of those DoS attacks myself either. A problem with the draft is that it tries to address: 1) problems which happen when no proper check haven't been implemented 2) problems which happen when all proper checks have been implemented 3) some solutions to 6to4 relay problem So it may be a bit confusing, perhaps I should try to reorganize them somehow... > > > It enables an attacker to abuse my and many other 6to4 > > hosts elsewhere > > > in the Internet to arm a victim in the native v6 Internet. > > > > .. but that's not really nothing new -- pretty much what you > > can do today with regular spoofing, and we'll probably never > > be able to eliminate all of that. The difference is that it > > is more difficult to trace and it can be initiated by the > > hosts who are v4 or v6 ingress filtered. > > > > I don't think all the threats in _any_ automatic tunneling > > mechanism can be neutralized except by heavy packet exchange > > which usually makes the mechanism unusable. We'll just have > > to analyse what those are and decide the acceptable level > > security (or consider the whole mechanism a no-go). > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sat Nov 23 10:41:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00556 for ; Sat, 23 Nov 2002 10:40:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FcQd-000JEO-00 for v6ops-data@psg.com; Sat, 23 Nov 2002 07:42:43 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18FcQa-000JE7-00 for v6ops@ops.ietf.org; Sat, 23 Nov 2002 07:42:41 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gANFgc612680 for ; Sat, 23 Nov 2002 17:42:39 +0200 Date: Sat, 23 Nov 2002 17:42:38 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: why I'm not implementing IPv6 In-Reply-To: <20021121183850.9135.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On 21 Nov 2002, D. J. Bernstein wrote: > In short: the same reasons I didn't implement OSI. In detail: > > http://cr.yp.to/djbdns/ipv6mess.html Speaking of which, I'll add my private (but smaller, more constrained) rant. IMO, it was a serious mistake to make the system libraries sort AAAA DNS replies before A records (btw: I'm not aware of any implementation where you could actually specify the order) when using getaddrinfo and AF_UNSPEC. This is because now people are afraid of deploying v6-enabled software because v6 connectivity is not really there, and contacting dual-stack servers is only likely to cause problems when done over v6. Only when explicitly configured, v6 would be used over v4, until some more or less "magic moment" (at different times in different regions etc.) If this would have been different, we migh have a significantly higher number of v6-enabled applications etc. enabled in the mainstream distributions. Further, this will affect the transition scenarios. I surely wouldn't like regular customers' getting v6-enabled yet with this bad connectivity. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sat Nov 23 19:57:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08924 for ; Sat, 23 Nov 2002 19:57:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Fl6k-000Cxi-00 for v6ops-data@psg.com; Sat, 23 Nov 2002 16:58:46 -0800 Received: from nat-63-99-114-2.tahoenetworks.com ([63.99.114.2] helo=TNEXVS01.tahoenetworks.com) by psg.com with esmtp (Exim 3.36 #2) id 18Fl6i-000Cx0-00 for v6ops@ops.ietf.org; Sat, 23 Nov 2002 16:58:44 -0800 Received: from adithya ([10.8.2.71]) by TNEXVS01.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 23 Nov 2002 16:58:40 -0800 Message-ID: <001901c29355$9962fde0$2539ac40@tahoenetworks.com> From: "Mohan Parthasarathy" To: "Pekka Savola" Cc: "Alain Durand" , "Brian E Carpenter" , References: Subject: Re: 6to4 usage scenarios Date: Sat, 23 Nov 2002 17:05:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 24 Nov 2002 00:58:40.0925 (UTC) FILETIME=[A11B44D0:01C29354] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > On Fri, 22 Nov 2002, Mohan Parthasarathy wrote: > > I looked at your examples in section A.3, which talks about > > reflection attack against IPv4 nodes and IPv6 nodes using > > relay routers : > > > > src = X > > dst = Y > > src_v4 = 8.0.0.1 > > dst_v4 = 9.0.0.2 > > > > If Y is 2002:0500:0001::1, you mention that target 5.0.0.1 > > would be bombed with reflected packets from 6to4 relay router. > > This happens because the relay router decapsulated the packet > > (removing src_v4 and dst_v4) and then *again* encapsulated > > in 6to4. > > Right. > > > As a relay router SHOULD not be doing this, can > > we not catch this case ? I agree that sending to a native > > V6 address with a forged source V6 address is a problem. > > Yes, this can be caught easily (the way is shown in the draft), but > practise has shown most relays don't do this. > Do we really care about those relays ? All we can do at the ietf is to provide those hints which will help do a robust implementation. If there are implementations that don't do this, they will get fixed sooner or later. > > But it is essentially the same problem as not being able > > to trace back as mentioned in A.1. I am just trying to understand > > which threats we are trying to address here. > > > > The only thing that seems seruous to me is the IPv6 spoofing > > and access control avoidance threat in your draft. (It might > > be better if you can move all the attacks to the main section > > and list the possible solution together with it). > > Right, I'm not that worried about some of those DoS attacks myself either. > > A problem with the draft is that it tries to address: > > 1) problems which happen when no proper check haven't been implemented > 2) problems which happen when all proper checks have been implemented > 3) some solutions to 6to4 relay problem > > So it may be a bit confusing, perhaps I should try to reorganize them > somehow... > Yes, please. Then, it will be clear as to what problems we need to solve. IMO, i don't think we should really care about implementations that don't do all the checks mentioned in the draft. -mohan > > > > It enables an attacker to abuse my and many other 6to4 > > > hosts elsewhere > > > > in the Internet to arm a victim in the native v6 Internet. > > > > > > .. but that's not really nothing new -- pretty much what you > > > can do today with regular spoofing, and we'll probably never > > > be able to eliminate all of that. The difference is that it > > > is more difficult to trace and it can be initiated by the > > > hosts who are v4 or v6 ingress filtered. > > > > > > I don't think all the threats in _any_ automatic tunneling > > > mechanism can be neutralized except by heavy packet exchange > > > which usually makes the mechanism unusable. We'll just have > > > to analyse what those are and decide the acceptable level > > > security (or consider the whole mechanism a no-go). > > > > > > -- > > > Pekka Savola "Tell me of difficulties surmounted, > > > Netcore Oy not those you stumble over and fall" > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > > > > > > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > From owner-v6ops@ops.ietf.org Sat Nov 23 20:10:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09157 for ; Sat, 23 Nov 2002 20:10:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FlJl-000DGI-00 for v6ops-data@psg.com; Sat, 23 Nov 2002 17:12:13 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18FlJi-000DEr-00 for v6ops@ops.ietf.org; Sat, 23 Nov 2002 17:12:10 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA25802; Sat, 23 Nov 2002 17:11:10 -0800 (PST) Message-Id: <5.1.0.14.0.20021123200541.029cde28@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 23 Nov 2002 20:08:17 -0500 To: Pekka Savola From: Margaret Wasserman Subject: Re: why I'm not implementing IPv6 Cc: v6ops@ops.ietf.org In-Reply-To: References: <20021121183850.9135.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, >IMO, it was a serious mistake to make the system libraries sort AAAA DNS >replies before A records (btw: I'm not aware of any implementation where >you could actually specify the order) when using getaddrinfo and >AF_UNSPEC. Specifically, what problem does this cause? Are there many hosts that have IPv6 AAAA records in the DNS, but no connectivity via IPv6? >This is because now people are afraid of deploying v6-enabled software >because v6 connectivity is not really there, and contacting dual-stack >servers is only likely to cause problems when done over v6. Only when >explicitly configured, v6 would be used over v4, until some more or less >"magic moment" (at different times in different regions etc.) I don't believe in a "magic moment"... In order for IPv6 to get deployed, we have to make dual stack nodes work properly throughout the transition AND build an IPv6 protocol and network architecture that has sufficient benefits for some situations, users and/or applications that it gets deployed and used. >If this would have been different, we migh have a significantly higher >number of v6-enabled applications etc. enabled in the mainstream >distributions. How would specifying a different order for DNS records achieve this? Margaret From owner-v6ops@ops.ietf.org Sat Nov 23 22:26:48 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10830 for ; Sat, 23 Nov 2002 22:26:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FnQU-000Gk6-00 for v6ops-data@psg.com; Sat, 23 Nov 2002 19:27:18 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #2) id 18FnQP-000Gjt-00 for v6ops@ops.ietf.org; Sat, 23 Nov 2002 19:27:13 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 40FCD4DFE; Sat, 23 Nov 2002 22:27:12 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 23 Nov 2002 22:27:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 6to4 usage scenarios Date: Sat, 23 Nov 2002 22:27:11 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9C33@tayexc13.americas.cpqcorp.net> Thread-Topic: 6to4 usage scenarios Thread-Index: AcKRzR7Ira5YhhSmQG6MAl+sqOSNSgBnDAfw From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 24 Nov 2002 03:27:12.0066 (UTC) FILETIME=[608F7A20:01C29369] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA10830 It should be used as Brian stated and with the intention brian stated. This is a gigantic rathole with no need to be here. /jim [Honor, Commitment, Integrity] > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, November 21, 2002 9:14 PM > To: v6ops@ops.ietf.org > Subject: 6to4 usage scenarios > > > Hello, > > It seems like the 6to4 security discussion degenerated into > argument on > how it was meant to be used. > > There are two basic models of connecting 6to4 routers to relays: > > 1) simple static route to your relay > 2) BGP sessions to your relay and all the other relays where > you want to > receive native IPv6 packets from > > I know of _no_ deployments of 2) even though Brian insists on > that being the only "real" 6to4 usage scenario. Does anyone > know this being used? > > If not, I think we must acknowledge that 2) is not really > right-tool-for-the-job (think of 6over4 **), and that 1) is > the primary > (only?) applicability target of 6to4. > > The alternative is that we have gaping holes in Home/SOHO and > partially > maybe enterprise transition scenarios, and nothing to fill > them at the > moment. > > **) 6over4 is a nice technique, and we could even use it -- > but we don't > want stuff like that. The same IMO applies to 6to4+BGP. > There is no use > specifying mechanisms for the audience who does not want them. > > P.S. I only came to the wg after 6to4 had just gone RFC, this > internal bickering really took me off surprise and made me > both frustrated and angry about refusing to accept the reality. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > From owner-v6ops@ops.ietf.org Sun Nov 24 04:22:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24190 for ; Sun, 24 Nov 2002 04:22:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Fswr-0002nG-00 for v6ops-data@psg.com; Sun, 24 Nov 2002 01:21:05 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Fswp-0002n0-00 for v6ops@ops.ietf.org; Sun, 24 Nov 2002 01:21:03 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAO9Kwd27015; Sun, 24 Nov 2002 11:20:58 +0200 Date: Sun, 24 Nov 2002 11:20:57 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: RE: 6to4 usage scenarios In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9C33@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 23 Nov 2002, Bound, Jim wrote: > It should be used as Brian stated and with the intention brian stated. > This is a gigantic rathole with no need to be here. Do you have an idea what to use instead of 6to4 for smaller deployments? Tunnel brokers are a possibility, about the only one I think. But those require more configuration and aren't really that commonplace today either. > > -----Original Message----- From: Pekka Savola > > [mailto:pekkas@netcore.fi] Sent: Thursday, November 21, 2002 9:14 PM > > To: v6ops@ops.ietf.org Subject: 6to4 usage scenarios > > > > > > Hello, > > > > It seems like the 6to4 security discussion degenerated into > > argument on > > how it was meant to be used. > > > > There are two basic models of connecting 6to4 routers to relays: > > > > 1) simple static route to your relay > > 2) BGP sessions to your relay and all the other relays where > > you want to > > receive native IPv6 packets from > > > > I know of _no_ deployments of 2) even though Brian insists on > > that being the only "real" 6to4 usage scenario. Does anyone > > know this being used? > > > > If not, I think we must acknowledge that 2) is not really > > right-tool-for-the-job (think of 6over4 **), and that 1) is > > the primary > > (only?) applicability target of 6to4. > > > > The alternative is that we have gaping holes in Home/SOHO and > > partially > > maybe enterprise transition scenarios, and nothing to fill > > them at the > > moment. > > > > **) 6over4 is a nice technique, and we could even use it -- > > but we don't > > want stuff like that. The same IMO applies to 6to4+BGP. > > There is no use > > specifying mechanisms for the audience who does not want them. > > > > P.S. I only came to the wg after 6to4 had just gone RFC, this > > internal bickering really took me off surprise and made me > > both frustrated and angry about refusing to accept the reality. > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > > > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sun Nov 24 04:28:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24261 for ; Sun, 24 Nov 2002 04:28:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ft3l-0002yR-00 for v6ops-data@psg.com; Sun, 24 Nov 2002 01:28:13 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Ft3j-0002y9-00 for v6ops@ops.ietf.org; Sun, 24 Nov 2002 01:28:11 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAO9S4q27044; Sun, 24 Nov 2002 11:28:05 +0200 Date: Sun, 24 Nov 2002 11:28:04 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: v6ops@ops.ietf.org Subject: Re: why I'm not implementing IPv6 In-Reply-To: <5.1.0.14.0.20021123200541.029cde28@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 23 Nov 2002, Margaret Wasserman wrote: > >IMO, it was a serious mistake to make the system libraries sort AAAA DNS > >replies before A records (btw: I'm not aware of any implementation where > >you could actually specify the order) when using getaddrinfo and > >AF_UNSPEC. > > Specifically, what problem does this cause? Applications which support v4 and v6 try to use v6 first when trying to contact dual-stack nodes. > Are there many hosts > that have IPv6 AAAA records in the DNS, but no connectivity via > IPv6? How many hosts are there that have IPv6 AAAA records in the DNS, but connectivity is *not* significantly worse than with IPv4? > I don't believe in a "magic moment"... In order for IPv6 to get > deployed, we have to make dual stack nodes work properly throughout > the transition AND build an IPv6 protocol and network architecture > that has sufficient benefits for some situations, users and/or > applications that it gets deployed and used. I agree -- I had a different meaning for "magic moment" than djb. To me it was the moment a site's operator feels confident enough to prefer v6 connectivity to dual-stack nodes instead of v4. Somewhere, this is today. At production networks, I don't feel it's time for that yet. > >If this would have been different, we migh have a significantly higher > >number of v6-enabled applications etc. enabled in the mainstream > >distributions. > > How would specifying a different order for DNS records achieve > this? People could deploy v6-enabled applications and enable v6 by default on their boxes without a fear of it interfering with v4. That'd be a *huge* benefit. I've already expressed my fear about this, see e.g. http://staff.csc.fi/psavola/residential.html "Migration and Co-existence Scenarios" section. That section would have been entirely different if the sort order had been reversed. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sun Nov 24 06:43:48 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25546 for ; Sun, 24 Nov 2002 06:43:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FvBp-00067l-00 for v6ops-data@psg.com; Sun, 24 Nov 2002 03:44:41 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18FvBn-00067Z-00 for v6ops@ops.ietf.org; Sun, 24 Nov 2002 03:44:39 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAOBibu27956 for ; Sun, 24 Nov 2002 13:44:37 +0200 Date: Sun, 24 Nov 2002 13:44:36 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: IPv6 transition architecture discussion Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.4 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, Triggered by extended discussion at the IETF meeting on NAT-PT, I think we should try to discuss more about the _core_ matters of the transition, for example: 1) how to start enabling v6-capable software in the operating systems, and having operating systems v6-enabled, in such a fashion that it does not hinder the current usability of v4? A starter for discussion: v6 connectivity is very poor (see draft-savola-v6ops-6bone-mess-01 for more). Vendors are rightfully afraid (I sure don't want them doing it) to enable v6 by default, as connections could easily switch to using (badly working) v6. Do we need to do something about this or just wait N years to operators to do something. Note: this is a chicken-and-egg problem, ISP's don't deploy v6 before it's requested (and paid for, in some way or another), and the connectivity remains poor because v6 isn't really production yet. 2) are there some cases in the transition which we could ignore, to make it simpler? In particular, this includes v6-only and v4-only interoperation. A starter for discussion: v4-only <-> v6-only in a general case is complex. IMO we perhaps shouldn't try to solve the general problem, as it draws the attention away from more important issues. Is it ok to require v6-only nodes will only be deployed when they don't need connectivity to v4-only nodes (except by proxies -- e.g. TCP/UDP relay or ALG level thing is IMO just fine)? For example, in home networking scenario, enabling v6-only printers etc. should be trivial _if we require_ TCP/UDP proxy e.g. in one dual-stack computer in the network. On the other hand, I would imagine it could be ok to just say, if you want to use that printer, upgrade your OS, period. Is it required to be able to communicate between v6-only node in your network to v4-only nodes in the general internet? The need for this can be mitigated by dual-stack ALG's, like web proxies. My suggestion would be that don't deploy v6-only nodes, requiring v4 internet access, then. Such could still be deployed in internal networks -- most v6-only gadgets today don't really require to be accessible or to access v4 internet anyway -- and even v4 in the local network is also a bit arguable. x) there are probably many other "really important" issues we need to have some idea of. It's not all that useful to meddle with scenario details until we have some idea how the big picture should work itself out. I think this is something we need to properly discuss now and possibly at the next meeting. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sun Nov 24 06:47:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25572 for ; Sun, 24 Nov 2002 06:47:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18FvG2-0006F5-00 for v6ops-data@psg.com; Sun, 24 Nov 2002 03:49:02 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #2) id 18FvFz-0006Et-00 for v6ops@ops.ietf.org; Sun, 24 Nov 2002 03:49:00 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA10525 for ; Sun, 24 Nov 2002 11:48:58 GMT Received: from login.ecs.soton.ac.uk (IDENT:ZKZDzFma1RXM9uQIN+hDe+tbpzPFJUtu@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id gAOBmsWX027414 for ; Sun, 24 Nov 2002 11:48:54 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id gAOBmrD23920 for v6ops@ops.ietf.org; Sun, 24 Nov 2002 11:48:53 GMT Date: Sun, 24 Nov 2002 11:48:53 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: why I'm not implementing IPv6 Message-ID: <20021124114853.GA23711@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20021121183850.9135.qmail@cr.yp.to> <5.1.0.14.0.20021123200541.029cde28@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20021123200541.029cde28@mail.windriver.com> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, Nov 23, 2002 at 08:08:17PM -0500, Margaret Wasserman wrote: > > Specifically, what problem does this cause? Are there many hosts > that have IPv6 AAAA records in the DNS, but no connectivity via > IPv6? Maybe you missed the 6bone thread on this :) If you take the IETF meeting example my IPv4 RTT home was 100ms, but my IPv6 RTT home was 400-500ms. I was trying to run IPv6-only (including DNS transport) at the site, but ended up using IPv4 (except when due to the L2/L3 local WLAN issues we had this year IPv6 was present when IPv4 was not :) Note in some cases it is not a problem, e.g. between the UK and Abilene west coast via 6NET and SURFnet I have a 20+ hop path for IPv4 and IPv6, and both perform equally well. But those paths are dual-stack and similar, whereas "in the wild" your connectivity is not predictable or reliable enough to use IPv6 day-to-day (or at least enough that you wish to use IPv4 ahead of IPv6 to reach a dual-stack service). While it was great of Itojun et al to get IIJ connectivity for IETF, it was ironic that we were a few blocks from an Abilene gigapop, but that traffic still went via Japan to Abilene sites (and this path also doubled the RTT to the UK research networks). I think Itojun fixed this before the end of the event, which was good :) I appreciate the intent of preferring v6 ahead of v4 where a host has A and AAAA records, but the reality is dictated by the 6bone-mess as written down by Pekka in draft-savola-v6ops-6bone-mess-01 and discussed at the Atlanta 6bone meeting. It is a problem we are trying to tackle between 6NET, Euro6IX and Abilene (and WIDE) by getting some sane policy and community tagging running, to get a stable and well-connected international research network that may connect some 6bone sites but that is relatively shielded from the "6bone-mess". We had a meeting about this in Atlanta, and will be trying some new policies soon. In short, we need to unravel the 6bone mess or, more realistically, build some good policies between connected networks and transit providers, to begin to make IPv6 usable internationally. Note I am talking here about Pekka's 6bone-mess thesis, and not Dan's ipv6-mess document which started this thread and which I largely don't agree with. Cheers, Tim From owner-v6ops@ops.ietf.org Sun Nov 24 21:39:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07752 for ; Sun, 24 Nov 2002 21:39:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18G98t-0009n7-00 for v6ops-data@psg.com; Sun, 24 Nov 2002 18:38:35 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18G98r-0009mv-00 for v6ops@ops.ietf.org; Sun, 24 Nov 2002 18:38:33 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 7439F4B22; Mon, 25 Nov 2002 11:38:30 +0900 (JST) To: Alain Durand Cc: dns op wg , v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Mon, 11 Nov 2002 13:32:12 PST. <3DD021DC.70400@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-ymbk-6to4-arpa-delegation-00.txt From: itojun@iijlab.net Date: Mon, 25 Nov 2002 11:38:30 +0900 Message-Id: <20021125023830.7439F4B22@coconut.itojun.org> X-Spam-Status: No, hits=1.0 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> i would prefer it if you impose no changes to getaddrinfo/getnameinfo >> with your proposal. arrangements within server side would be better >> at this stage >> (we can't change deployed codebase any longer, there are huge number >> of Solaris 8 boxen out there). >I would like not to change it too, but the alternative to create records >on the fly in the DNS servers is an invitation for DOS attack on DNSsec... i don't understand why you would want to sign synthesized (generated- on-the-fly) record with DNSSEC. if you don't sign it, the server should be able to respond proptly enough (= no worry for DoS). itojun From owner-v6ops@ops.ietf.org Sun Nov 24 23:45:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09695 for ; Sun, 24 Nov 2002 23:45:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GB90-000FDl-00 for v6ops-data@psg.com; Sun, 24 Nov 2002 20:46:50 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #2) id 18GB8x-000FDZ-00 for v6ops@ops.ietf.org; Sun, 24 Nov 2002 20:46:47 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2E730A1AF; Sun, 24 Nov 2002 23:46:46 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 24 Nov 2002 23:46:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 transition architecture discussion Date: Sun, 24 Nov 2002 23:46:45 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240C5B@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 transition architecture discussion Thread-Index: AcKTr7trD6+oVaGgTA6JFnBlx5EUPAAjA24A From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 25 Nov 2002 04:46:46.0012 (UTC) FILETIME=[A87793C0:01C2943D] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA09695 Pekka, Inline responses. /jim [A people who would give up their freedom out of fear did not deserve it in the first place. Ben Franklin] > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Sunday, November 24, 2002 6:45 AM > To: v6ops@ops.ietf.org > Subject: IPv6 transition architecture discussion > > > Hello, > > Triggered by extended discussion at the IETF meeting on > NAT-PT, I think we should try to discuss more about the > _core_ matters of the transition, for > example: > > 1) how to start enabling v6-capable software in the operating > systems, and having operating systems v6-enabled, in such a > fashion that it does not hinder the current usability of v4? None of the IETFs business you can't tell vendors what and what not to do in their products. This is not specifying standards. You cannot tell vendors what to do with their operating systems either. > > A starter for discussion: v6 connectivity is very poor (see > draft-savola-v6ops-6bone-mess-01 for more). Vendors are > rightfully afraid (I sure don't want them doing it) to enable > v6 by default, as connections could easily switch to using > (badly working) v6. What vendor told you they are afraid? If you cannot state who that is then please retract this statement. All vendors shipping products have web pages and kits to install IPv6. You might go buy them and test them for yourself. Also all our interoperability labs are doing this now UNH, ETSI, TAHI, and now China. This is none of the IETFs businss or v6ops unless that works points to a protocol or operations problem on the network. If you know of such cases I am sure the chairs would love to hear them. > > Do we need to do something about this or just wait N years to > operators to do something. Note: this is a chicken-and-egg > problem, ISP's don't deploy v6 before it's requested (and > paid for, in some way or another), and the connectivity > remains poor because v6 isn't really production yet. ISPs are deploying IPv6 you simply don't know what your talking about. Right now it is in test bed mode and that will last awhile and it has nothing to do with anything we can do in the IETF to help at this point. The one thing we could do is stop wasting mail messages with mail like this and get some decisions made about SLs, Scenarios, et al. That is the IETF's job not this diatribe you spew out here all to often, that is totally irrelevant to the building of standards. If you want to be part of the deployment mission and effort there are places to do that and I would be glad to give you pointers offline as this is not an IETF matter. > > 2) are there some cases in the transition which we could > ignore, to make > it simpler? In particular, this includes v6-only and v4-only > interoperation. This is a valid discussion I agree. > > A starter for discussion: v4-only <-> v6-only in a general > case is complex. IMO we perhaps shouldn't try to solve the > general problem, as it draws the attention away from more > important issues. Is it ok to require v6-only nodes will > only be deployed when they don't need connectivity to v4-only > nodes (except by proxies -- e.g. TCP/UDP relay or ALG level > thing is IMO just fine)? You cannot require anything Pekka. You can only build a draft and propose a standard. The IETF cannot mandate anything at all to the market or to those who have built and continuing to build IPv6 features in products. > > For example, in home networking scenario, enabling v6-only > printers etc. should be trivial _if we require_ TCP/UDP proxy > e.g. in one dual-stack computer in the network. On the other > hand, I would imagine it could be ok to just say, if you want > to use that printer, upgrade your OS, period. You have to be kidding right? Have you ever shipped a product that a customer is using? If so you should know that no one in this standards body or any standards body or even any deployment forum (which has far more influence and power than the IETF to affect deployment) will EVER tell a vendors customer what to do with their OS. This is silliness and borders on outright confusion on your role in the IETF and the role the IETF will support you in. This will not happen here. > > Is it required to be able to communicate between v6-only node > in your network to v4-only nodes in the general internet? > The need for this can be mitigated by dual-stack ALG's, like > web proxies. My suggestion would be that don't deploy v6-only > nodes, requiring v4 internet access, then. > Such could still be deployed in internal networks -- most > v6-only gadgets today don't really require to be accessible > or to access v4 internet anyway -- and even v4 in the local > network is also a bit arguable. Then right a spec for transition. I would hope the chairs tell you to wait for the scenarios as everyone else is told. Why don't you work on the scenarios as a working group member. > > x) there are probably many other "really important" issues we > need to have > some idea of. It's not all that useful to meddle with > scenario details > until we have some idea how the big picture should work itself out. What your asking is the kind of discussions one has when building products. But I don't agree and the chairs have made it pretty clear we must work on scenarios. I have come to support that and it makes some logical sense. The scenarios are about use cases and people deploying now and that is the big picture. > > I think this is something we need to properly discuss now and > possibly at > the next meeting. I simply disagree and strongly do not support this and ask the chairs to kill 90% of what you suggest as out of scope for this mail list and the IETF. /jim > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > From owner-v6ops@ops.ietf.org Mon Nov 25 03:26:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22468 for ; Mon, 25 Nov 2002 03:26:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GEaK-000KsX-00 for v6ops-data@psg.com; Mon, 25 Nov 2002 00:27:16 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18GEaH-000KsD-00 for v6ops@ops.ietf.org; Mon, 25 Nov 2002 00:27:13 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAP8R5w04603; Mon, 25 Nov 2002 10:27:06 +0200 Date: Mon, 25 Nov 2002 10:27:05 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: RE: IPv6 transition architecture discussion In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03240C5B@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 24 Nov 2002, Bound, Jim wrote: > > 1) how to start enabling v6-capable software in the operating > > systems, and having operating systems v6-enabled, in such a > > fashion that it does not hinder the current usability of v4? > > None of the IETFs business you can't tell vendors what and what not to > do in their products. This is not specifying standards. You cannot tell > vendors what to do with their operating systems either. Of course, it's not IETF's business to say what to do. But I believe it's in the interests of most of IPv6 community if we develop IPv6 standards and techiques, which can be used in the most non-intrusive manner suitable. v6ops charter is not limited to specifying standards, I believe. > > A starter for discussion: v6 connectivity is very poor (see > > draft-savola-v6ops-6bone-mess-01 for more). Vendors are > > rightfully afraid (I sure don't want them doing it) to enable > > v6 by default, as connections could easily switch to using > > (badly working) v6. > > What vendor told you they are afraid? If you cannot state who that is > then please retract this statement. They haven't done the enabling yet but support is there, so they're afraid. > All vendors shipping products have web pages and kits to install IPv6. I didn't dispute this, and it wasn't the point. > You might go buy them and test them for yourself. Also all our > interoperability labs are doing this now UNH, ETSI, TAHI, and now China. > This is none of the IETFs businss or v6ops unless that works points to a > protocol or operations problem on the network. If you know of such > cases I am sure the chairs would love to hear them. I already pointed out the operational problem here. > > Do we need to do something about this or just wait N years to > > operators to do something. Note: this is a chicken-and-egg > > problem, ISP's don't deploy v6 before it's requested (and > > paid for, in some way or another), and the connectivity > > remains poor because v6 isn't really production yet. > > ISPs are deploying IPv6 you simply don't know what your talking about. You've no idea. I have 4 hats: 1) ISP; we run a dual-stack STM-16 backbone, and believe me, I think I know full well about problems of ISP's 2) Home user; I use IPv6 at home using 6to4 etc. and have set up many such networks for others 3) Enterprise; I've designed and implemented IPv6 in several managed enterprise networks, and I'm currently managing one 4) Vendor; I do volunteer work for a vendor and have pretty much a say in all IPv6-related issues With my ISP hat on, please don't try to be authorative of problems (or lack of thereof) in ISP networks. > Right now it is in test bed mode and that will last awhile and it has > nothing to do with anything we can do in the IETF to help at this point. > The one thing we could do is stop wasting mail messages with mail like > this and get some decisions made about SLs, Scenarios, et al. That is > the IETF's job not this diatribe you spew out here all to often, that is > totally irrelevant to the building of standards. I think it's our responsibility to react if we see problems with IPv6 deployment. > > A starter for discussion: v4-only <-> v6-only in a general > > case is complex. IMO we perhaps shouldn't try to solve the > > general problem, as it draws the attention away from more > > important issues. Is it ok to require v6-only nodes will > > only be deployed when they don't need connectivity to v4-only > > nodes (except by proxies -- e.g. TCP/UDP relay or ALG level > > thing is IMO just fine)? > > You cannot require anything Pekka. You can only build a draft and > propose a standard. The IETF cannot mandate anything at all to the > market or to those who have built and continuing to build IPv6 features > in products. We have a very strong say in which standard we produce, and we don't need to produce more of those than we want to. > > For example, in home networking scenario, enabling v6-only > > printers etc. should be trivial _if we require_ TCP/UDP proxy > > e.g. in one dual-stack computer in the network. On the other > > hand, I would imagine it could be ok to just say, if you want > > to use that printer, upgrade your OS, period. > > You have to be kidding right? Have you ever shipped a product that a > customer is using? If so you should know that no one in this standards > body or any standards body or even any deployment forum (which has far > more influence and power than the IETF to affect deployment) will EVER > tell a vendors customer what to do with their OS. This is silliness > and borders on outright confusion on your role in the IETF and the role > the IETF will support you in. This will not happen here. We have the right to restrict our focus if we believe that's the best thing to do. Of course, we can't forbid people from doing something, but we may document the way our proposed solution will work out. > > Is it required to be able to communicate between v6-only node > > in your network to v4-only nodes in the general internet? > > The need for this can be mitigated by dual-stack ALG's, like > > web proxies. My suggestion would be that don't deploy v6-only > > nodes, requiring v4 internet access, then. > > Such could still be deployed in internal networks -- most > > v6-only gadgets today don't really require to be accessible > > or to access v4 internet anyway -- and even v4 in the local > > network is also a bit arguable. > > Then right a spec for transition. I would hope the chairs tell you to > wait for the scenarios as everyone else is told. There are fundamental issues which affect all the transition scenarios. I believe we should try to figure out some answers to those; this is what I noted in the meeting when the NAT-PT discussion turned to IMO critical core issues. > Why don't you work on > the scenarios as a working group member. I believe I've contributed to all of the scenarios, it seems some of them are ignoring my contributions though. Waiting for next revisions of the documents so I can keep on contributing... > > x) there are probably many other "really important" issues we > > need to have > > some idea of. It's not all that useful to meddle with > > scenario details > > until we have some idea how the big picture should work itself out. > > What your asking is the kind of discussions one has when building > products. But I don't agree and the chairs have made it pretty clear we > must work on scenarios. I have come to support that and it makes some > logical sense. The scenarios are about use cases and people deploying > now and that is the big picture. Some people have already deployed and noticed problems. We need to make deployment scenarios that will work. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Nov 25 04:10:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22990 for ; Mon, 25 Nov 2002 04:10:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GFGM-000M1a-00 for v6ops-data@psg.com; Mon, 25 Nov 2002 01:10:42 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #2) id 18GFGJ-000M0T-00 for v6ops@ops.ietf.org; Mon, 25 Nov 2002 01:10:39 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAP99rt2019990; Mon, 25 Nov 2002 10:09:54 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAP99omH039624; Mon, 25 Nov 2002 10:09:50 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA74402 from ; Mon, 25 Nov 2002 10:09:49 +0100 Message-Id: <3DE1E8C9.6A537738@hursley.ibm.com> Date: Mon, 25 Nov 2002 10:09:29 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Christian Huitema Cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: 6to4 security questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Christian, that articulates what I have been feeling. In fact, it suggests that rate-limiting mechanisms in 6to4 relays would strongly mitigate the attack - i.e. don't allow more than N new flows per unit time to a given native IPv6 destination via a given relay. I think we are going to see rate-limiting defences anyway, not just in this context. Brian Christian Huitema wrote: > > Reading this thread, it seems that many people are confusing several > aspects of the 6to4 security issue. Maybe we should start by writing a > complete security analysis, something a bit more detailed than the > current draft. In any case, let's look at the reflection attack. > > The attack to which we kept being pointed is the following: a random > host sends a packet to an IPv6 server listening to a 6to4 address > through a 6to4 router (not to a 6to4 relay); the IPv6 server sends a > response packet to the (forged) IPv6 source address of the incoming > packet. > > The vulnerability is that, with this mechanism, a DOS attacker can use > an IPv6 server listening on a 6to4 address to "launder" a DOS attack > launched against an IPv6 site: the IPv6 packets will not contain any > trace of the original IPv4 address from which the attack was launched. > Clearly, that is bad. There are however a number of mitigating factors: > > 1) The attack does not include a multiplier effect; the amount of > traffic directed at the target will be about equal to the amount of > traffic sent by the attacker. > > 2) The attack packets go through a choke point, the 6to4 relay between > the laundering site and the target. > > 3) The packets received by the target contain the address of the > relaying 6to4 site. > > 4) The payload of the packets received by the target will be a response > generated by the laundering server, which limits any "magic packet" > issue. > > 5) The attack only provides value if the attacker's IPv4 connection was > subject to ingress filtering, which is alas not a very common case. > > Because of the absence of a magic packet effect, this attack is only > really powerful if it is practiced by a "fleet of zombies" using a large > number of reflectors. I personally don't think that fleets of zombies > can be practically eliminated by simply observing their IPv4 addresses. > I also don't think that the attacker whose virus managed to enslave a > large number of zombies particularly cares that these zombies will be > eventually discovered; in practice, the zombies are expandable. I > suspect that the attacker will rather forgo the reflection exercise, > because an attack in which the content of packets can be chosen is more > powerful than an attack in which the source of packets can be hidden. In > any case, given a large enough fleet of zombies, it is statistically > likely that many zombies will not be submitted to IPv4 ingress > filtering; those who are can very often randomize at least some bits of > their source address, mimicking another fellow on the same LAN. > > In short, yes it is a vulnerability, but it is not a terribly dangerous > one, and it is a vulnerability that will in any case disappear with > 6to4, when sites receive native IPv6 connectivity. So, yes, a fix is > welcome; however, the fix should not be so drastic as to impede the > "autonomous deployment" advantage of 6to4. > > -- Christian Huitema From owner-v6ops@ops.ietf.org Mon Nov 25 07:29:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25356 for ; Mon, 25 Nov 2002 07:29:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GIO8-0001ZG-00 for v6ops-data@psg.com; Mon, 25 Nov 2002 04:30:56 -0800 Received: from maya20.nic.fr ([192.134.4.152]) by psg.com with esmtp (Exim 3.36 #2) id 18GIO5-0001Z3-00 for v6ops@ops.ietf.org; Mon, 25 Nov 2002 04:30:54 -0800 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id gAPCUn7I1279865; Mon, 25 Nov 2002 13:30:50 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1000) id 8574510F7A; Mon, 25 Nov 2002 13:30:49 +0100 (CET) Date: Mon, 25 Nov 2002 13:30:49 +0100 From: Stephane Bortzmeyer To: Margaret Wasserman Cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: why I'm not implementing IPv6 Message-ID: <20021125123049.GA5007@nic.fr> References: <20021121183850.9135.qmail@cr.yp.to> <5.1.0.14.0.20021123200541.029cde28@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20021123200541.029cde28@mail.windriver.com> User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ X-Spam-Status: No, hits=-3.2 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, Nov 23, 2002 at 08:08:17PM -0500, Margaret Wasserman wrote a message of 34 lines which said: > Specifically, what problem does this cause? Are there many hosts > that have IPv6 AAAA records in the DNS, but no connectivity via > IPv6? Even if the *server* has an IPv6 connection, the *client* may not. And there is no easy way for its resolver to ask only A records when there is no IPv6 connectivity. That's why many people put all their AAAA records in an ipv6.example.com subdomain. From owner-v6ops@ops.ietf.org Mon Nov 25 09:26:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29663 for ; Mon, 25 Nov 2002 09:26:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GKDP-0005fS-00 for v6ops-data@psg.com; Mon, 25 Nov 2002 06:27:59 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18GKDK-0005el-00 for v6ops@ops.ietf.org; Mon, 25 Nov 2002 06:27:54 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18GKDK-000Pg3-00 for v6ops@ops.ietf.org; Mon, 25 Nov 2002 06:27:54 -0800 Message-ID: <20021125124015.GB5007@nic.fr> References: <9C422444DE99BC46B3AD3C6EAFC9711B03240C5B@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03240C5B@tayexc13.americas.cpqcorp.net> Date: Mon, 25 Nov 2002 13:40:15 +0100 From: Stephane Bortzmeyer To: "Bound, Jim" Cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: IPv6 transition architecture discussion X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On Sun, Nov 24, 2002 at 11:46:45PM -0500, Bound, Jim wrote a message of 154 lines which said: > > rightfully afraid (I sure don't want them doing it) to enable > > v6 by default, as connections could easily switch to using > > (badly working) v6. > > What vendor told you they are afraid? If you cannot state who that is > then please retract this statement. There was a discussion in Debian a while ago and this issue was raised several times. Sorry, I do not find the entry of the thread right now. > ISPs are deploying IPv6 you simply don't know what your talking about. ... > You have to be kidding right? Have you ever shipped a product that a > customer is using? ... > I simply disagree and strongly do not support this and ask the chairs to > kill 90% of what you suggest as out of scope for this mail list and the > IETF. Such a reply to the perfectly reasonable and well-documented draft of Pekka about the current IPv6 situation helps me to understand why the IPv6 transition is so slow (I connected my employer to the 6bone in 1996 and I saw very little progress since). If all the IPv6 zealots believe and act the same, IPv6 will stay a small island for many years to come. If you treat such concerns like you do and with words like this one, we will soon only have trolls like Dan Bernstein to tell the simple truth about IPv6. From owner-v6ops@ops.ietf.org Mon Nov 25 11:57:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08764 for ; Mon, 25 Nov 2002 11:57:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GMYn-000CBK-00 for v6ops-data@psg.com; Mon, 25 Nov 2002 08:58:13 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #2) id 18GMYi-000CAZ-00 for v6ops@ops.ietf.org; Mon, 25 Nov 2002 08:58:08 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 03FA46972; Mon, 25 Nov 2002 11:58:07 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Nov 2002 11:58:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 transition architecture discussion Date: Mon, 25 Nov 2002 11:58:06 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240C5F@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 transition architecture discussion Thread-Index: AcKUXHW0MZh9ejb5T3ejwI/S2QLEggARetIQ From: "Bound, Jim" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 25 Nov 2002 16:58:06.0902 (UTC) FILETIME=[D3840560:01C294A3] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA08764 Pekka, I don't disagree on building scenarios, mechanisms, etc. It is your statements about implementations and how my product should work. That is where I disagree. More below. > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, November 25, 2002 3:27 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: RE: IPv6 transition architecture discussion > > > On Sun, 24 Nov 2002, Bound, Jim wrote: > > > 1) how to start enabling v6-capable software in the operating > > > systems, and having operating systems v6-enabled, in such a > > > fashion that it does not hinder the current usability of v4? > > > > None of the IETFs business you can't tell vendors what and > what not to > > do in their products. This is not specifying standards. You cannot > > tell vendors what to do with their operating systems either. > > Of course, it's not IETF's business to say what to do. > > But I believe it's in the interests of most of IPv6 community if we > develop IPv6 standards and techiques, which can be used in the most > non-intrusive manner suitable. 100% agree. But not telling me what is or not enabled in my operating system. > > v6ops charter is not limited to specifying standards, I believe. I think if you mean also Info, BCP, et al I agree if it is telling us what our products do its not in the IETF charter let alone the v6ops charter. > > > > A starter for discussion: v6 connectivity is very poor (see > > > draft-savola-v6ops-6bone-mess-01 for more). Vendors are > > > rightfully afraid (I sure don't want them doing it) to enable > > > v6 by default, as connections could easily switch to using > > > (badly working) v6. > > > > What vendor told you they are afraid? If you cannot state > who that is > > then please retract this statement. > > They haven't done the enabling yet but support is there, so > they're afraid. With the chairs permission I can forward to this list a very good paper that discusses this that is for public consumption. If you were talking about ISPs that is not who I was referencing. . > > > > Do we need to do something about this or just wait N years to > > > operators to do something. Note: this is a chicken-and-egg > > > problem, ISP's don't deploy v6 before it's requested (and > > > paid for, in some way or another), and the connectivity > > > remains poor because v6 isn't really production yet. > > > > ISPs are deploying IPv6 you simply don't know what your > talking about. > > You've no idea. When you said no one is deploying IPv6 was my response. That is not true. I do not dispute your hands on knowledge and did not above in my statements. > > I have 4 hats: > > 1) ISP; we run a dual-stack STM-16 backbone, and believe me, > I think I > know full well about problems of ISP's > 2) Home user; I use IPv6 at home using 6to4 etc. and have set > up many such > networks for others > 3) Enterprise; I've designed and implemented IPv6 in several managed > enterprise networks, and I'm currently managing one > 4) Vendor; I do volunteer work for a vendor and have pretty > much a say in > all IPv6-related issues > > With my ISP hat on, please don't try to be authorative of > problems (or lack of thereof) in ISP networks. I never mentioned ISP network just that many of them do have IPv6 test beds and pTLAs. It is in process. > > > Right now it is in test bed mode and that will last awhile > and it has > > nothing to do with anything we can do in the IETF to help at this > > point. The one thing we could do is stop wasting mail > messages with mail like > > this and get some decisions made about SLs, Scenarios, et > al. That is > > the IETF's job not this diatribe you spew out here all to > often, that > > is totally irrelevant to the building of standards. > > I think it's our responsibility to react if we see problems with IPv6 > deployment. Of course again I did not say that. Just don't tell vendors what to do that is all. > > > > A starter for discussion: v4-only <-> v6-only in a general > > > case is complex. IMO we perhaps shouldn't try to solve the > > > general problem, as it draws the attention away from more > > > important issues. Is it ok to require v6-only nodes will > > > only be deployed when they don't need connectivity to v4-only > > > nodes (except by proxies -- e.g. TCP/UDP relay or ALG level > > > thing is IMO just fine)? > > > > You cannot require anything Pekka. You can only build a draft and > > propose a standard. The IETF cannot mandate anything at all to the > > market or to those who have built and continuing to build IPv6 > > features in products. > > We have a very strong say in which standard we produce, and > we don't need > to produce more of those than we want to. For our standards and operational statements yes. I agree. But above you say the following "v6only and deployed with some type of statement for compliance". The IETF cannot mandate or should suggest what customers do with their deployment. We cannot possibly walk in customers shoes. That is the crux of my mail. > > Why don't you work on > > the scenarios as a working group member. > > I believe I've contributed to all of the scenarios, it seems > some of them > are ignoring my contributions though. That's too bad. All participants should get a response from the design teams. You should complain to the chairs privately. Have not seen any for our enterprise draft from you and would like to. Regards, /jim From owner-v6ops@ops.ietf.org Mon Nov 25 11:57:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08791 for ; Mon, 25 Nov 2002 11:57:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GMaa-000CKy-00 for v6ops-data@psg.com; Mon, 25 Nov 2002 09:00:04 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #2) id 18GMaU-000CKE-00 for v6ops@ops.ietf.org; Mon, 25 Nov 2002 08:59:58 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D42204041; Mon, 25 Nov 2002 11:59:56 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Nov 2002 11:59:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 transition architecture discussion Date: Mon, 25 Nov 2002 11:59:56 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9C7B@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 transition architecture discussion Thread-Index: AcKUjyQMVd/lvyj3RoeVdS6/Uz22rAAFLAbA From: "Bound, Jim" To: "Stephane Bortzmeyer" Cc: "Pekka Savola" , X-OriginalArrivalTime: 25 Nov 2002 16:59:56.0637 (UTC) FILETIME=[14EC40D0:01C294A4] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA08791 > > I simply disagree and strongly do not support this and ask > the chairs > > to kill 90% of what you suggest as out of scope for this > mail list and > > the IETF. > > Such a reply to the perfectly reasonable and well-documented > draft of Pekka about the current IPv6 situation helps me to > understand why the IPv6 transition is so slow (I connected my > employer to the 6bone in 1996 and I saw very little progress > since). If all the IPv6 zealots believe and act the same, > IPv6 will stay a small island for many years to come. > > If you treat such concerns like you do and with words like > this one, we will soon only have trolls like Dan Bernstein to > tell the simple truth about IPv6. Please see reply I just sent to Pekka. I am saying we should not tell product developers how to deliver their products in this community it is not our job here. Is that better? I fully agree we need to work on the charter of v6ops. That does not include making suggestions how my OS handles a printer for IPv6. Regards, /jim From owner-v6ops@ops.ietf.org Mon Nov 25 15:24:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23519 for ; Mon, 25 Nov 2002 15:24:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GPn7-000MvB-00 for v6ops-data@psg.com; Mon, 25 Nov 2002 12:25:13 -0800 Received: from mail-out1.apple.com ([17.254.0.52]) by psg.com with esmtp (Exim 3.36 #2) id 18GPn2-000MuT-00 for v6ops@ops.ietf.org; Mon, 25 Nov 2002 12:25:08 -0800 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gAPKP3w18741 for ; Mon, 25 Nov 2002 12:25:08 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 25 Nov 2002 12:25:02 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id gAPKP2p24516 for ; Mon, 25 Nov 2002 12:25:02 -0800 (PST) Date: Mon, 25 Nov 2002 12:25:02 -0800 Subject: Re: IPv6 transition architecture discussion Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) From: Joshua Graessley To: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03240C5B@tayexc13.americas.cpqcorp.net> Message-Id: X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-4.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday, November 24, 2002, at 08:46 PM, Bound, Jim wrote: >> -----Original Message----- >> From: Pekka Savola [mailto:pekkas@netcore.fi] >> Sent: Sunday, November 24, 2002 6:45 AM >> To: v6ops@ops.ietf.org >> Subject: IPv6 transition architecture discussion >> >> >> Hello, >> >> Triggered by extended discussion at the IETF meeting on >> NAT-PT, I think we should try to discuss more about the >> _core_ matters of the transition, for >> example: >> >> 1) how to start enabling v6-capable software in the operating >> systems, and having operating systems v6-enabled, in such a >> fashion that it does not hinder the current usability of v4? > > None of the IETFs business you can't tell vendors what and what not to > do in their products. > This is not specifying standards. You cannot tell vendors what to do > with their operating systems either. The IETF and vendors are not two separate entities. Vendors send people to participate in the IETF to help establish standards so we can all cooperate and release products that will work together. The IETF certainly can't tell any vendor what to do or what not to do in a product. That doesn't mean that vendors don't look to the IETF for suggestions. Suggestions on how to deploy IPv6 from the operating system perspective seem to be lacking. 6to4 looks like a good solution, but it doesn't work behind NAT. In addition, people in this working group have strongly advised against any wide deployment of 6to4 hosts. Apple would like to ship a version of our operating system that does everything it can to get an IPv6 address. This would give our developers an opportunity to make use of IPv6. This strategy only works if we can figure out how to get IPv6 addresses to the majority of our customers. Solutions such as 6to4 and Teredo would allow us to achieve this goal. The vocal people in this working group say that 6to4 and Teredo are bad solutions. They rightly point out that the few 6to4 relays will probably melt down or people will stop running them. In addition, there is no such thing as a Teredo relay deployed today. Teredo and 6to4 work well when there are many relays, which is not the case today. We look to the IETF for a solution because we can't solve this problem alone. I get the impression from this working group that the working group is of the opinion that the transition mechanism will not work and we should just sit on our thumbs until the ISPs provide us IPv6 connectivity. >> A starter for discussion: v6 connectivity is very poor (see >> draft-savola-v6ops-6bone-mess-01 for more). Vendors are >> rightfully afraid (I sure don't want them doing it) to enable >> v6 by default, as connections could easily switch to using >> (badly working) v6. > > What vendor told you they are afraid? If you cannot state who that is > then please retract this statement. We are concerned, I'm not sure I'd say afraid. We have shipped Mac OS X 10.2, with support for IPv6. It isn't really well integrated yet, but it's there. It will assign link-local addresses, listen for routing advertisements, and assign addresses. This is fine because almost no one has IPv6 connectivity. We were considering turning on 6to4 by default when there are no routing advertisements. This working group has dissuaded us from doing so. If we did turn on 6to4, we would want to add some extra smarts to getaddrinfo to list IPv4 addresses first when 6to4 is in use to reduce the load on the relays. If we didn't modify getaddrinfos behavior, websites that used to work, may not work if the relays are down, or it may be very inefficient to communicate with such hosts since 6to4 could send the tunneled packets to a relay just about anywhere. Based on feedback in this working group and some feedback at the recent IETF in Atlanta, we will probably not be working to get IPv6 connectivity on all Mac OS X hosts. > All vendors shipping products have web pages and kits to install IPv6. > You might go buy them and test them for yourself. Also all our > interoperability labs are doing this now UNH, ETSI, TAHI, and now > China. > This is none of the IETFs businss or v6ops unless that works points to > a > protocol or operations problem on the network. If you know of such > cases I am sure the chairs would love to hear them. Why are these optional kits to install IPv6? If vendors really felt comfortable about IPv6, they would ship support built in to the product and it would be enabled by default. The fact is, very few people have IPv6 connectivity. IPv6 connectivity is the exception, not the rule. >> Do we need to do something about this or just wait N years to >> operators to do something. Note: this is a chicken-and-egg >> problem, ISP's don't deploy v6 before it's requested (and >> paid for, in some way or another), and the connectivity >> remains poor because v6 isn't really production yet. > > ISPs are deploying IPv6 you simply don't know what your talking about. > Right now it is in test bed mode and that will last awhile and it has > nothing to do with anything we can do in the IETF to help at this > point. > The one thing we could do is stop wasting mail messages with mail like > this and get some decisions made about SLs, Scenarios, et al. That is > the IETF's job not this diatribe you spew out here all to often, that > is > totally irrelevant to the building of standards. Is there any evidence to suggest that IPv6 will some day make the move from testbed to wide deployment? The IETF has a huge amount to do with how quickly IPv6 moves from testbed to deployment. The IETF has drafts defining transition strategies. These transition strategies are important. Without them, IPv6 will never move on from test bed deployment. If people continue to ignore the transition problem and insult those who bring it up, perhaps IPv6 will go the way of OSI. >> x) there are probably many other "really important" issues we >> need to have >> some idea of. It's not all that useful to meddle with >> scenario details >> until we have some idea how the big picture should work itself out. > > What your asking is the kind of discussions one has when building > products. But I don't agree and the chairs have made it pretty clear > we > must work on scenarios. I have come to support that and it makes some > logical sense. The scenarios are about use cases and people deploying > now and that is the big picture. Yes, scenarios are more important since people participating in the IETF will be building scenarios instead of products. After all, it doesn't matter that a something be implemented in a product so long as there's a scenario in which the protocol could be used. >> I think this is something we need to properly discuss now and >> possibly at >> the next meeting. > > I simply disagree and strongly do not support this and ask the chairs > to > kill 90% of what you suggest as out of scope for this mail list and the > IETF. Perhaps it is too early to be folding the ng-trans working group efforts in to v6-ops? -josh From owner-v6ops@ops.ietf.org Mon Nov 25 16:09:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25919 for ; Mon, 25 Nov 2002 16:09:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GQVv-000PMu-00 for v6ops-data@psg.com; Mon, 25 Nov 2002 13:11:31 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18GQVs-000PMg-00 for v6ops@ops.ietf.org; Mon, 25 Nov 2002 13:11:28 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gAPLA9l12170; Mon, 25 Nov 2002 16:10:09 -0500 (EST) Message-Id: <200211252110.gAPLA9l12170@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley cc: v6ops@ops.ietf.org Subject: Re: IPv6 transition architecture discussion In-reply-to: (Your message of "Mon, 25 Nov 2002 12:25:02 PST.") Date: Mon, 25 Nov 2002 16:10:09 -0500 X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Suggestions on how to deploy IPv6 from the operating > system perspective seem to be lacking. 6to4 looks like a good solution, > but it doesn't work behind NAT. In addition, people in this working > group have strongly advised against any wide deployment of 6to4 hosts. I don't think there's consensus about that, only that there are some questions or problems associated with 6to4 on a host level that haven't been fully resolved. Personally I find "host 6to4" essential both to provide access to machines at home (where a single host serves both as an IPv4 presence and as a v6 router) and to allow me to access my v6 hosts from v4-only net connections. I'm really disappointed that so few host OSes support it. For instance the lack of 6to4 support in 10.2 probably means I'll end up running NetBSD on my new 1Ghz powerbook g4. > Apple would like to ship a version of our operating system that does > everything it can to get an IPv6 address. I'd love for MacOS to support 6to4, though I'm not sure that having it automagically enabled is a good idea. (there's such a thing as a machine being too clever or having too high an opinion of its own cleverness) > The vocal people in this working group say that 6to4 and > Teredo are bad solutions. They rightly point out that the few 6to4 > relays will probably melt down or people will stop running them. 6to4 works wonderfully if you have v4 connectivity (perhaps indirectly) and are talking to other 6to4 sites. if you want to talk to other sites over v4, right now you generally need to set up an explicit tunnel for that. the anycast based relay routers don't work well enough to be used, IMHO. at least not right now. attempts to talk to v6 sites typically time out (which is annoying because the v6 addresses are tried first - another thing which needs to be fixed) > We look to the IETF for a solution because we can't solve this problem > alone. I get the impression from this working group that the working > group is of the opinion that the transition mechanism will not work and > we should just sit on our thumbs until the ISPs provide us IPv6 > connectivity. be assured that not everyone here shares that opinion. IMHO we need to define a host profile for 6to4, and perhaps another one for NAT boxes that wish to support 6to4. yes there are problems. let's fix them. > We were considering turning on 6to4 by > default when there are no routing advertisements. This working group > has dissuaded us from doing so. If we did turn on 6to4, we would want > to add some extra smarts to getaddrinfo to list IPv4 addresses first > when 6to4 is in use to reduce the load on the relays. it turns out that you need the address ordering to be sensitive to both network configuration and to the particular application. some apps will be v4 by default, others will be v6 default, others will be exclusively one or the other. Keith From owner-v6ops@ops.ietf.org Mon Nov 25 16:23:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26364 for ; Mon, 25 Nov 2002 16:23:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GQjP-000059-00 for v6ops-data@psg.com; Mon, 25 Nov 2002 13:25:27 -0800 Received: from mail-out1.apple.com ([17.254.0.52]) by psg.com with esmtp (Exim 3.36 #2) id 18GQjM-00004x-00 for v6ops@ops.ietf.org; Mon, 25 Nov 2002 13:25:25 -0800 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gAPLPOw00360 for ; Mon, 25 Nov 2002 13:25:24 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Nov 2002 13:25:03 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gAPLPNu21840; Mon, 25 Nov 2002 13:25:23 -0800 (PST) Date: Mon, 25 Nov 2002 13:25:23 -0800 Subject: Re: IPv6 transition architecture discussion Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: v6ops@ops.ietf.org To: Keith Moore From: Joshua Graessley In-Reply-To: <200211252110.gAPLA9l12170@astro.cs.utk.edu> Message-Id: <684E3F52-00BC-11D7-A762-000393760260@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, November 25, 2002, at 01:10 PM, Keith Moore wrote: >> Suggestions on how to deploy IPv6 from the operating >> system perspective seem to be lacking. 6to4 looks like a good >> solution, >> but it doesn't work behind NAT. In addition, people in this working >> group have strongly advised against any wide deployment of 6to4 hosts. > > I don't think there's consensus about that, only that there are some > questions or problems associated with 6to4 on a host level that haven't > been fully resolved. Personally I find "host 6to4" essential both to > provide access to machines at home (where a single host serves both > as an IPv4 presence and as a v6 router) and to allow me to access my > v6 hosts from v4-only net connections. I'm really disappointed that so > few host OSes support it. For instance the lack of 6to4 support in > 10.2 > probably means I'll end up running NetBSD on my new 1Ghz powerbook g4. 6to4 does exist on Mac OS X 10.2. It just isn't integrated in to the user interface. If you run the command line (Terminal application), you can use the script ip6config to turn on 6to4 (i.e. sudo ip6config start-stf en0). 10.2 also comes with rtadvd for advertising routes. IPv6 support is in 10.2, it's just isn't available through the user interface. -josh From owner-v6ops@ops.ietf.org Mon Nov 25 17:08:17 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28343 for ; Mon, 25 Nov 2002 17:08:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GRQ2-0002UN-00 for v6ops-data@psg.com; Mon, 25 Nov 2002 14:09:30 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18GRPy-0002U8-00 for v6ops@ops.ietf.org; Mon, 25 Nov 2002 14:09:27 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 8207D85A6; Mon, 25 Nov 2002 23:09:06 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id CD97985A5; Mon, 25 Nov 2002 23:09:00 +0100 (CET) From: "Jeroen Massar" To: "'Joshua Graessley'" , Subject: RE: IPv6 transition architecture discussion Date: Mon, 25 Nov 2002 23:09:58 +0100 Organization: Unfix Message-ID: <000701c294cf$66879d60$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA28343 Joshua Graessley wrote: > On Sunday, November 24, 2002, at 08:46 PM, Bound, Jim wrote: > > >> -----Original Message----- > >> From: Pekka Savola [mailto:pekkas@netcore.fi] > >> Hello, > The vocal people in this working group say that 6to4 and > Teredo are bad solutions. They rightly point out that the few 6to4 > relays will probably melt down or people will stop running them. In > addition, there is no such thing as a Teredo relay deployed today. > Teredo and 6to4 work well when there are many relays, which > is not the case today. My opinion is certainly NOT that it is a _bad_ solution au contrair. But you did want are to use it for the wrong thing. > We look to the IETF for a solution because we can't solve > this problem > alone. I get the impression from this working group that the working > group is of the opinion that the transition mechanism will > not work and we should just sit on our thumbs until the ISPs provide us IPv6 > connectivity. This is the right approach indeed. Discussing this with multiple vendors and people who have experience in deployment already does help find out what is going on. IMHO for IPv6 to get a big push at this moment one needs two things: 1) Application support. 2) ISP support. Application support is being worked on, many programmers change their current IPv4-only applications to support IPv6 simply by using getaddrinfo(). ISP support should be pushed by RIPE/ARIN/APNIC. The APNIC and RIPE regions are working quite hard. Taking a look at the ARIN region though makes me worry a bit. > >> A starter for discussion: v6 connectivity is very poor (see > >> draft-savola-v6ops-6bone-mess-01 for more). Vendors are > >> rightfully afraid (I sure don't want them doing it) to enable > >> v6 by default, as connections could easily switch to using > >> (badly working) v6. 6bone-mess is named 6bone mess as it's the mess of the 6bone. The 6bone will fade away. RIR space will be left. There are talks under a group of ISP's to clean up the RIR/6bone > > What vendor told you they are afraid? If you cannot state > who that is > > then please retract this statement. > > We are concerned, I'm not sure I'd say afraid. We have > shipped Mac OS X > 10.2, with support for IPv6. It isn't really well integrated yet, but > it's there. It will assign link-local addresses, listen for routing > advertisements, and assign addresses. This is fine because almost no > one has IPv6 connectivity. We were considering turning on 6to4 by > default when there are no routing advertisements. This working group > has dissuaded us from doing so. If we did turn on 6to4, we would want > to add some extra smarts to getaddrinfo to list IPv4 addresses first > when 6to4 is in use to reduce the load on the relays. Pekka mentioned a certain thing (prefer IPv4 over IPv6 dns queries). This would lessen the use of IPv6 where it could be used IMHO. Another approach to this is to test for IPv6 connectivity every N times a month* or something like that and turn on the above feature. *= ping6/connect to a certain host on the internet which is well connected. Eg "testforipv6.apple.com" :) > If we didn't modify getaddrinfos behavior, websites that used to work, may > not work if the relays are down, or it may be very inefficient to communicate > with such hosts since 6to4 could send the tunneled packets to a relay > just about anywhere. > > Based on feedback in this working group and some feedback at the recent > IETF in Atlanta, we will probably not be working to get IPv6 > connectivity on all Mac OS X hosts. > > > All vendors shipping products have web pages and kits to > install IPv6. > > You might go buy them and test them for yourself. Also all our > > interoperability labs are doing this now UNH, ETSI, TAHI, and now > > China. > > This is none of the IETFs businss or v6ops unless that > works points to > > a > > protocol or operations problem on the network. If you know of such > > cases I am sure the chairs would love to hear them. > > Why are these optional kits to install IPv6? If vendors really felt > comfortable about IPv6, they would ship support built in to > the product > and it would be enabled by default. The fact is, very few people have > IPv6 connectivity. IPv6 connectivity is the exception, not the rule. > > >> Do we need to do something about this or just wait N years to > >> operators to do something. Note: this is a chicken-and-egg > >> problem, ISP's don't deploy v6 before it's requested (and > >> paid for, in some way or another), and the connectivity > >> remains poor because v6 isn't really production yet. > > > > ISPs are deploying IPv6 you simply don't know what your > talking about. > > Right now it is in test bed mode and that will last awhile > and it has > > nothing to do with anything we can do in the IETF to help at this > > point. > > The one thing we could do is stop wasting mail messages > with mail like > > this and get some decisions made about SLs, Scenarios, et > al. That is > > the IETF's job not this diatribe you spew out here all to > often, that > > is > > totally irrelevant to the building of standards. > > Is there any evidence to suggest that IPv6 will some day make > the move > from testbed to wide deployment? The IETF has a huge amount > to do with > how quickly IPv6 moves from testbed to deployment. The IETF > has drafts > defining transition strategies. These transition strategies are > important. Without them, IPv6 will never move on from test bed > deployment. If people continue to ignore the transition problem and > insult those who bring it up, perhaps IPv6 will go the way of OSI. > > > > >> x) there are probably many other "really important" issues we > >> need to have > >> some idea of. It's not all that useful to meddle with > >> scenario details > >> until we have some idea how the big picture should work itself out. > > > > What your asking is the kind of discussions one has when building > > products. But I don't agree and the chairs have made it > pretty clear > > we > > must work on scenarios. I have come to support that and it > makes some > > logical sense. The scenarios are about use cases and > people deploying > > now and that is the big picture. > > Yes, scenarios are more important since people participating > in the IETF will be building scenarios instead of products. > After all, > it doesn't matter that a something be implemented in a > product so long > as there's a scenario in which the protocol could be used. > > >> I think this is something we need to properly discuss now and > >> possibly at > >> the next meeting. > > > > I simply disagree and strongly do not support this and ask the chairs to > > kill 90% of what you suggest as out of scope for this mail list and the > > IETF. > > Perhaps it is too early to be folding the ng-trans working group > efforts in to v6-ops? Maybe in the US, but not in Europe and Asia! :) Greets, Jeroen From owner-v6ops@ops.ietf.org Tue Nov 26 04:33:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25599 for ; Tue, 26 Nov 2002 04:33:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Gc79-000FEI-00 for v6ops-data@psg.com; Tue, 26 Nov 2002 01:34:43 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Gc76-000FE6-00 for v6ops@ops.ietf.org; Tue, 26 Nov 2002 01:34:41 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAQ9YVq17541; Tue, 26 Nov 2002 11:34:32 +0200 Date: Tue, 26 Nov 2002 11:34:31 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: Brian E Carpenter , Subject: RE: 6to4 security questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 22 Nov 2002, Christian Huitema wrote: > Reading this thread, it seems that many people are confusing several > aspects of the 6to4 security issue. Indeed. > Maybe we should start by writing a > complete security analysis, something a bit more detailed than the > current draft. I agree. I intend to try to do a proper threat analysis as one section of the draft. It could very well be a separate draft too. [...] -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Nov 26 05:01:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26093 for ; Tue, 26 Nov 2002 05:01:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GcZd-000GNy-00 for v6ops-data@psg.com; Tue, 26 Nov 2002 02:04:09 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #2) id 18GcZY-000GNg-00 for v6ops@ops.ietf.org; Tue, 26 Nov 2002 02:04:04 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAQA3JC3023802; Tue, 26 Nov 2002 11:03:23 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAQA3GQa035632; Tue, 26 Nov 2002 11:03:16 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34238 from ; Tue, 26 Nov 2002 11:03:13 +0100 Message-Id: <3DE346CB.C0977C87@hursley.ibm.com> Date: Tue, 26 Nov 2002 11:02:51 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Joshua Graessley Cc: v6ops@ops.ietf.org Subject: Re: IPv6 transition architecture discussion References: <200211252110.gAPLA9l12170@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To add to what Keith said, which I fully agree with, let's be clear that 6to4 was invented as a supplementary mechanism, for the case where a user site wants to support IPv6 and its ISP doesn't, and where for whatever practical reason a configured tunnel or tunnel broker solution isn't applicable. 6to4 shouldn't dominate the debate. It happens to be the youngest of the techniques in the V6OPS charter, so it's no surprise that it has open questions. That doesn't prevent it from working. Brian Keith Moore wrote: > > > Suggestions on how to deploy IPv6 from the operating > > system perspective seem to be lacking. 6to4 looks like a good solution, > > but it doesn't work behind NAT. In addition, people in this working > > group have strongly advised against any wide deployment of 6to4 hosts. > > I don't think there's consensus about that, only that there are some > questions or problems associated with 6to4 on a host level that haven't > been fully resolved. Personally I find "host 6to4" essential both to > provide access to machines at home (where a single host serves both > as an IPv4 presence and as a v6 router) and to allow me to access my > v6 hosts from v4-only net connections. I'm really disappointed that so > few host OSes support it. For instance the lack of 6to4 support in 10.2 > probably means I'll end up running NetBSD on my new 1Ghz powerbook g4. > > > Apple would like to ship a version of our operating system that does > > everything it can to get an IPv6 address. > > I'd love for MacOS to support 6to4, though I'm not sure that having > it automagically enabled is a good idea. (there's such a thing as > a machine being too clever or having too high an opinion of its > own cleverness) > > > The vocal people in this working group say that 6to4 and > > Teredo are bad solutions. They rightly point out that the few 6to4 > > relays will probably melt down or people will stop running them. > > 6to4 works wonderfully if you have v4 connectivity (perhaps indirectly) > and are talking to other 6to4 sites. if you want to talk to other sites > over v4, right now you generally need to set up an explicit tunnel for > that. the anycast based relay routers don't work well enough to be used, > IMHO. at least not right now. attempts to talk to v6 sites typically > time out (which is annoying because the v6 addresses are tried first - > another thing which needs to be fixed) > > > We look to the IETF for a solution because we can't solve this problem > > alone. I get the impression from this working group that the working > > group is of the opinion that the transition mechanism will not work and > > we should just sit on our thumbs until the ISPs provide us IPv6 > > connectivity. > > be assured that not everyone here shares that opinion. IMHO we need > to define a host profile for 6to4, and perhaps another one for NAT boxes > that wish to support 6to4. yes there are problems. let's fix them. > > > We were considering turning on 6to4 by > > default when there are no routing advertisements. This working group > > has dissuaded us from doing so. If we did turn on 6to4, we would want > > to add some extra smarts to getaddrinfo to list IPv4 addresses first > > when 6to4 is in use to reduce the load on the relays. > > it turns out that you need the address ordering to be sensitive to both > network configuration and to the particular application. some apps will > be v4 by default, others will be v6 default, others will be exclusively > one or the other. > > Keith From owner-v6ops@ops.ietf.org Tue Nov 26 12:37:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12462 for ; Tue, 26 Nov 2002 12:37:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Gjft-000Bz9-00 for v6ops-data@psg.com; Tue, 26 Nov 2002 09:39:05 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18Gjfr-000Byw-00 for v6ops@ops.ietf.org; Tue, 26 Nov 2002 09:39:03 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29576; Tue, 26 Nov 2002 10:39:01 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAQHckH12319; Tue, 26 Nov 2002 18:38:47 +0100 (MET) Date: Tue, 26 Nov 2002 18:35:32 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 6to4 security questions To: Alain Durand Cc: Erik Nordmark , Jason Goldschmidt , Pekka Savola , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3DDBDD07.7030903@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > There are in my opinion 4 ways forward: > > 1- Revisit 6to4 architecture to have bi-directional communication > between the 6to4 router and the 6to4 relay. That way the decapsulating > 6to4 router could apply some checks and make sure packets are comming > from a legitimate 6to4 relay. But doesn't such a revisit result in the prefix needing to be associated with the tunnel endpoint in order for routing to scale i.e. this becomes just a variant of the tunnel broker? (Not that this would necessarily be bad, I think the tunnel broker is a much overlooked piece of work.) But if #1 and #4 are essentially the same choice we only have 3 real choices. Erik From owner-v6ops@ops.ietf.org Tue Nov 26 17:35:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23997 for ; Tue, 26 Nov 2002 17:35:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GoJ5-0001Sd-00 for v6ops-data@psg.com; Tue, 26 Nov 2002 14:35:51 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18GoJ3-0001SP-00 for v6ops@ops.ietf.org; Tue, 26 Nov 2002 14:35:49 -0800 Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07688 for ; Tue, 26 Nov 2002 15:35:48 -0700 (MST) Received: from xpa-fe1 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H67005CMG3ON9@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 26 Nov 2002 15:35:48 -0700 (MST) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H6700C8LG3N4Q@mail.sun.net> for v6ops@ops.ietf.org; Tue, 26 Nov 2002 15:35:47 -0700 (MST) Date: Tue, 26 Nov 2002 14:35:44 -0800 From: Alain Durand Subject: 6to4 and Teredo vs Tunnel broker (was Re: 6to4 security questions) To: Erik Nordmark Cc: v6ops@ops.ietf.org Message-id: <3DE3F740.6040106@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: X-Spam-Status: No, hits=-3.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: >>There are in my opinion 4 ways forward: >> >>1- Revisit 6to4 architecture to have bi-directional communication >> between the 6to4 router and the 6to4 relay. That way the decapsulating >> 6to4 router could apply some checks and make sure packets are comming >> from a legitimate 6to4 relay. >> >> > >But doesn't such a revisit result in the prefix needing to be >associated with the tunnel endpoint in order for routing to scale >i.e. this becomes just a variant of the tunnel broker? > >(Not that this would necessarily be bad, I think the tunnel broker > is a much overlooked piece of work.) > I take this as a compliment! :-) >But if #1 and #4 are essentially the same choice we only have 3 real >choices. > Yes. The question is now to understand if we can live with this threat or not, or in other words, does full automatic connection to IPv6 networks from anywhere in IPv4 land outweight the security threat of what is the logical equivalent of open relays. Same question applies for NAT traversial solutions like Teredo. The alternative is deploying virtual ISPs through tunnel brokers that also accept IPv6 over UDP (or TCP, or PPP) over IPv4, at the cost of giving up full automation and creating sub optimal topologies. I think this is a fundamental question for the 'unmanaged environment'. - Alain. From owner-v6ops@ops.ietf.org Tue Nov 26 17:55:49 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24645 for ; Tue, 26 Nov 2002 17:55:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GodF-0002OL-00 for v6ops-data@psg.com; Tue, 26 Nov 2002 14:56:41 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18GodC-0002O8-00 for v6ops@ops.ietf.org; Tue, 26 Nov 2002 14:56:38 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAQMuad24701 for ; Wed, 27 Nov 2002 00:56:36 +0200 Date: Wed, 27 Nov 2002 00:56:35 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: SUMMARY: 6to4 security Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, I was asked to try to summarize the thread a bit. Most important points, with regard to how to go forward, I think: 1) it is not yet clear whether the current 6to4 security situation is acceptable (and with what kind of disclaimers); some of these issues may only be considered as DoS attacks like any others possible today. 2) due to that, I'll do a more complete and explicit threat analysis of 6to4 and add it as a section in the draft; this should help in trying to figure out where we stand and where to go (if necessary). 3) "using 192.88.99.0/24 as source address" -model does not buy much to reliably detect the real relay, so I'll add more disclaimers on that to the draft. 4) I'll also add some text on static vs. BGP configuration of 6to4 routers, in the 6to4 usage cases (also naturally included in the threat analysis above). 5) I'll add very short piece of text about the "6to4 used for tunnel end-point addressing only (compare to compatible addresses)" in the usage cases. 6) "more specific routes between 6to4 relays" -issue might work (at least for some cases); the text could be improved a bit, but as other things (like the security) is still open, I'll keep it as is for now [option two here would be to remove all but core text and publish it as a separate I-D -- this is the long-term goal anyway -- comments?]. I'll try to make a new draft available within 1.5 weeks, but we'll see. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Nov 26 18:01:54 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24918 for ; Tue, 26 Nov 2002 18:01:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GojM-0002dY-00 for v6ops-data@psg.com; Tue, 26 Nov 2002 15:03:00 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18GojJ-0002dL-00 for v6ops@ops.ietf.org; Tue, 26 Nov 2002 15:02:57 -0800 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16604 for ; Tue, 26 Nov 2002 16:02:57 -0700 (MST) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H6700MC9HCWQY@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 26 Nov 2002 16:02:57 -0700 (MST) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H6700CLCHCV4Q@mail.sun.net> for v6ops@ops.ietf.org; Tue, 26 Nov 2002 16:02:56 -0700 (MST) Date: Tue, 26 Nov 2002 15:02:52 -0800 From: Alain Durand Subject: Re: 6to4 security questions To: Christian Huitema Cc: Brian E Carpenter , Pekka Savola , v6ops@ops.ietf.org Message-id: <3DE3FD9C.7050301@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Christian Huitema wrote: >There are however a number of mitigating factors: > >1) The attack does not include a multiplier effect; the amount of >traffic directed at the target will be about equal to the amount of >traffic sent by the attacker. > Not necessarely. It depend on the protocol used on the reflectors. If you can find a UDP protocol that echos n packets to an original short incoming packet, you have a multiplier effect. >2) The attack packets go through a choke point, the 6to4 relay between >the laundering site and the target. > Not necessarely. If thousands of refletors are used, they will used different relays. >3) The packets received by the target contain the address of the >relaying 6to4 site. > If (many) thousands of reflectors are used, each reflector can be exercized only once and still create a massive DDOS. Such an attack will be even harder to detect using packet sampling techniques. >4) The payload of the packets received by the target will be a response >generated by the laundering server, which limits any "magic packet" >issue. > If many reflectors are exercised, depending on the protocol used, each DDOS packet may be different. >5) The attack only provides value if the attacker's IPv4 connection was >subject to ingress filtering, which is alas not a very common case. > True. But this will create disincentive for ISP to put ingress filtering in place and ruin the effort of those who did. > >Because of the absence of a magic packet effect, this attack is only >really powerful if it is practiced by a "fleet of zombies" using a large >number of reflectors. > Not really, you can use only a limited number of zombies (even a well connected one is enough) if you can discover thousands of valid 6to4 addresses. As the packets will be 'landered' by the 6to4 routers, it will be very hard to trace the attack back to the zombie. >In short, yes it is a vulnerability, but it is not a terribly dangerous >one, and it is a vulnerability that will in any case disappear with >6to4, when sites receive native IPv6 connectivity. So, yes, a fix is >welcome; however, the fix should not be so drastic as to impede the >"autonomous deployment" advantage of 6to4. > See my comment in the other thread on 6to4 & Teredo vs Tunnel Broker. - Alain. > > From owner-v6ops@ops.ietf.org Wed Nov 27 02:21:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24764 for ; Wed, 27 Nov 2002 02:21:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GwWW-000NA7-00 for v6ops-data@psg.com; Tue, 26 Nov 2002 23:22:16 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18GwWU-000N9v-00 for v6ops@ops.ietf.org; Tue, 26 Nov 2002 23:22:14 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAR7M4h28584; Wed, 27 Nov 2002 09:22:04 +0200 Date: Wed, 27 Nov 2002 09:22:04 +0200 (EET) From: Pekka Savola To: Keith Moore cc: Joshua Graessley , Subject: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-Reply-To: <200211252110.gAPLA9l12170@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_05_08,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 25 Nov 2002, Keith Moore wrote: [...] > at least not right now. attempts to talk to v6 sites typically > time out (which is annoying because the v6 addresses are tried first - > another thing which needs to be fixed) Do I sense this as a voice for support to modify or at least explore the current de-facto standard ordering? > > We were considering turning on 6to4 by > > default when there are no routing advertisements. This working group > > has dissuaded us from doing so. If we did turn on 6to4, we would want > > to add some extra smarts to getaddrinfo to list IPv4 addresses first > > when 6to4 is in use to reduce the load on the relays. > > it turns out that you need the address ordering to be sensitive to both > network configuration and to the particular application. some apps will > be v4 by default, others will be v6 default, others will be exclusively > one or the other. There are already some variables that affect this, namely: 1) whether the DNS lookup produces A, AAAA, or both; ie "remote site configuration" 2) what ordering for DNS records is used when both are used (default is AAAA first everywhere I know, no possibility to change that) 3) whether the application uses AF_INET, AF_INET6 or AF_UNSPEC (with server apps, this is even a bit muddier.) These help quite a bit, but I guess adding some getaddrinfo hint like AI_PREFERV4 or AI_PREFERV6 could be added in the case that DNS lookup returns both addresses, you use AF_UNSPEC and you want to influence the default DNS record ordering. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 27 02:24:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29213 for ; Wed, 27 Nov 2002 02:24:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GwbS-000NOe-00 for v6ops-data@psg.com; Tue, 26 Nov 2002 23:27:22 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18GwbQ-000NOK-00 for v6ops@ops.ietf.org; Tue, 26 Nov 2002 23:27:20 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 907C84B22; Wed, 27 Nov 2002 16:27:18 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org In-reply-to: pekkas's message of Wed, 27 Nov 2002 09:22:04 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] From: itojun@iijlab.net Date: Wed, 27 Nov 2002 16:27:18 +0900 Message-Id: <20021127072718.907C84B22@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >These help quite a bit, but I guess adding some getaddrinfo hint like >AI_PREFERV4 or AI_PREFERV6 could be added in the case that DNS lookup >returns both addresses, you use AF_UNSPEC and you want to influence the >default DNS record ordering. i don't think it wise to have flag bit - if you pass AI_PREFERV4 you will stuck with IPv4 even when IPv6 provides much better connectivity, and the curse won't go away until you recompile. leave it to default address selection rule and logic in getaddrinfo(3). itojun From owner-v6ops@ops.ietf.org Wed Nov 27 02:30:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02239 for ; Wed, 27 Nov 2002 02:30:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Gwgv-000NdH-00 for v6ops-data@psg.com; Tue, 26 Nov 2002 23:33:01 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Gwgt-000Nd5-00 for v6ops@ops.ietf.org; Tue, 26 Nov 2002 23:32:59 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gAR7Wqi28659; Wed, 27 Nov 2002 09:32:52 +0200 Date: Wed, 27 Nov 2002 09:32:51 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-Reply-To: <20021127072718.907C84B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 27 Nov 2002 itojun@iijlab.net wrote: > >These help quite a bit, but I guess adding some getaddrinfo hint like > >AI_PREFERV4 or AI_PREFERV6 could be added in the case that DNS lookup > >returns both addresses, you use AF_UNSPEC and you want to influence the > >default DNS record ordering. > > i don't think it wise to have flag bit - if you pass AI_PREFERV4 > you will stuck with IPv4 even when IPv6 provides much better > connectivity, and the curse won't go away until you recompile. That's still better than apps shipping with AF_INET or no getaddrinfo at all, right? > leave it to default address selection rule and logic in getaddrinfo(3). I'm not sure how default address selection, at least ones I've seen would help with this. Perhaps they don't implement _destination_ address selection. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 27 02:35:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02420 for ; Wed, 27 Nov 2002 02:35:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Gwlu-000Nqc-00 for v6ops-data@psg.com; Tue, 26 Nov 2002 23:38:10 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18Gwlp-000NqO-00 for v6ops@ops.ietf.org; Tue, 26 Nov 2002 23:38:05 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0F2094B24; Wed, 27 Nov 2002 16:38:04 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org In-reply-to: pekkas's message of Wed, 27 Nov 2002 09:32:51 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] From: itojun@iijlab.net Date: Wed, 27 Nov 2002 16:38:04 +0900 Message-Id: <20021127073804.0F2094B24@coconut.itojun.org> X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> leave it to default address selection rule and logic in getaddrinfo(3). >I'm not sure how default address selection, at least ones I've seen would >help with this. >Perhaps they don't implement _destination_ address selection. they do. see draft-ietf-ipngwg-default-addr-select-06.txt section 5. itojun From owner-v6ops@ops.ietf.org Wed Nov 27 03:14:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03125 for ; Wed, 27 Nov 2002 03:14:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GxN8-000PGk-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 00:16:38 -0800 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by psg.com with esmtp (Exim 3.36 #2) id 18GxN6-000PGY-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 00:16:36 -0800 Received: from localhost ([3ffe:501:4819:2000:2582:d9dc:ecbd:4c15]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id gAR8GYd80131 for ; Wed, 27 Nov 2002 17:16:34 +0900 (JST) Date: Wed, 27 Nov 2002 17:16:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-Reply-To: <20021127073804.0F2094B24@coconut.itojun.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <20021127073804.0F2094B24@coconut.itojun.org> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 21 X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Wed, 27 Nov 2002 16:38:04 +0900, >>>>> itojun@iijlab.net said: >>> leave it to default address selection rule and logic in getaddrinfo(3). >> I'm not sure how default address selection, at least ones I've seen would >> help with this. >> Perhaps they don't implement _destination_ address selection. > they do. see draft-ietf-ipngwg-default-addr-select-06.txt section 5. Section 10.3 of draft-ietf-ipv6-default-addr-select-09.txt (this is the latest draft I believe) may also help. KAME snaps have getaddrinfo considering the policy table and a tool to modify the policy table. I guess Windows XP support the feature, too. Whether we should change the default is, of course, another issue. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Wed Nov 27 03:49:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03638 for ; Wed, 27 Nov 2002 03:49:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GxuB-000Psy-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 00:50:47 -0800 Received: from moebius2.space.net ([195.30.1.100] ident=qmailr) by psg.com with smtp (Exim 3.36 #2) id 18Gxu9-000Psf-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 00:50:45 -0800 Received: (qmail 79476 invoked by uid 1007); 27 Nov 2002 08:50:43 -0000 Date: Wed, 27 Nov 2002 09:50:43 +0100 From: Gert Doering To: Pekka Savola Cc: Keith Moore , Joshua Graessley , v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] Message-ID: <20021127095043.Q15927@Space.Net> References: <200211252110.gAPLA9l12170@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from pekkas@netcore.fi on Wed, Nov 27, 2002 at 09:22:04AM +0200 X-NCC-RegID: de.space X-Spam-Status: No, hits=-5.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Wed, Nov 27, 2002 at 09:22:04AM +0200, Pekka Savola wrote: > These help quite a bit, but I guess adding some getaddrinfo hint like > AI_PREFERV4 or AI_PREFERV6 could be added in the case that DNS lookup > returns both addresses, you use AF_UNSPEC and you want to influence the > default DNS record ordering. In addition to that, provide a system configuration item that will set the default preference in case the application doesn't specify AI_PREFER* Usually it's not something the application would care about, but more the system administrator - "I want to have IPv6 but I do not trust it enough to be the default" vs. "I know IPv6 is now working well enough". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 50279 (49875) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Wed Nov 27 05:14:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04975 for ; Wed, 27 Nov 2002 05:14:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18GzEs-0001Re-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 02:16:14 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18GzEq-0001RS-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 02:16:12 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gARAG3a29906; Wed, 27 Nov 2002 12:16:03 +0200 Date: Wed, 27 Nov 2002 12:16:03 +0200 (EET) From: Pekka Savola To: Gert Doering cc: Keith Moore , Joshua Graessley , Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-Reply-To: <20021127095043.Q15927@Space.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 27 Nov 2002, Gert Doering wrote: > On Wed, Nov 27, 2002 at 09:22:04AM +0200, Pekka Savola wrote: > > These help quite a bit, but I guess adding some getaddrinfo hint like > > AI_PREFERV4 or AI_PREFERV6 could be added in the case that DNS lookup > > returns both addresses, you use AF_UNSPEC and you want to influence the > > default DNS record ordering. > > In addition to that, provide a system configuration item that will > set the default preference in case the application doesn't specify > AI_PREFER* Yes, that could be the policy table (or my suggestion) actually implementing the toggle in the resolver, often in /etc/resolv.conf. > Usually it's not something the application would care about, but more > the system administrator - "I want to have IPv6 but I do not trust it > enough to be the default" vs. "I know IPv6 is now working well enough". Totally agree -- some apps can be exceptions though. I want to be able to start enabling v6 by default, to build the user base, but I don't want it to cause _any_ ill effects to apps or the user yet. Currently there is no way to do this, and I believe it's critical when we really want to deploy v6 to the masses. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 27 07:04:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06809 for ; Wed, 27 Nov 2002 07:04:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H0wx-00044g-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 04:05:51 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18H0wu-00044T-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 04:05:48 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 404E57C3D; Wed, 27 Nov 2002 13:05:29 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id C769A7764; Wed, 27 Nov 2002 13:05:23 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" , "'Gert Doering'" Cc: "'Keith Moore'" , "'Joshua Graessley'" , Subject: RE: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] Date: Wed, 27 Nov 2002 13:06:22 +0100 Organization: Unfix Message-ID: <000801c2960d$676308c0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA06809 Pekka Savola wrote: > On Wed, 27 Nov 2002, Gert Doering wrote: > > On Wed, Nov 27, 2002 at 09:22:04AM +0200, Pekka Savola wrote: > > > These help quite a bit, but I guess adding some > getaddrinfo hint like > > > AI_PREFERV4 or AI_PREFERV6 could be added in the case > that DNS lookup > > > returns both addresses, you use AF_UNSPEC and you want to > influence the > > > default DNS record ordering. > > > > In addition to that, provide a system configuration item that will > > set the default preference in case the application doesn't specify > > AI_PREFER* > > Yes, that could be the policy table (or my suggestion) actually > implementing the toggle in the resolver, often in /etc/resolv.conf. > > > Usually it's not something the application would care > about, but more > > the system administrator - "I want to have IPv6 but I do > not trust it > > enough to be the default" vs. "I know IPv6 is now working > well enough". > > Totally agree -- some apps can be exceptions though. > > I want to be able to start enabling v6 by default, to build > the user base, > but I don't want it to cause _any_ ill effects to apps or the > user yet. > > Currently there is no way to do this, and I believe it's > critical when we really want to deploy v6 to the masses. The OS or actually the resolver part of the OS should be able to be configured with an option exactly like above. Programs should _never_ have a preference, if they do they should ask for an AF_INET or AF_INET6 that's enough preference already :) I am against having the AI_PREFER4/6 as this would be too program specific and one needs to recompile to get it out. The resolver could/should have a setting in f.e /etc/resolv.conf or in the registry: "prefer AAAA,A" This would first try IPv6, then IPv4. I think I once saw a discussion on the debian-ipv6 lists talking about such a mechanism which would be implemented into the glibc resolver library. One could also have a tool which periodically, say once a week, or on-boot checks if there is a working IPv6 uplink. Eg by sending a ping packet to a well known host by doing this in IPv4 and IPv6 this toggle could be flipped automatically. Ofcourse due to privacy there should be an easy way to turn this off and to change the host. Greets, Jeroen From owner-v6ops@ops.ietf.org Wed Nov 27 07:26:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07233 for ; Wed, 27 Nov 2002 07:26:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H1Ig-0004bD-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 04:28:18 -0800 Received: from tyholt.uninett.no ([158.38.60.10]) by psg.com with esmtp (Exim 3.36 #2) id 18H1Id-0004b1-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 04:28:16 -0800 Received: from sverresborg.uninett.no (sverresborg.uninett.no [158.38.62.92]) by tyholt.uninett.no (8.12.6/8.12.6) with ESMTP id gARCS2Dd015783; Wed, 27 Nov 2002 13:28:02 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.11.6/8.11.2) id gARCS2V13190; Wed, 27 Nov 2002 13:28:02 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 27 Nov 2002 13:28:02 +0100 From: Stig Venaas To: Jeroen Massar Cc: "'Pekka Savola'" , "'Gert Doering'" , "'Keith Moore'" , "'Joshua Graessley'" , v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] Message-ID: <20021127132801.A13186@sverresborg.uninett.no> References: <000801c2960d$676308c0$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000801c2960d$676308c0$210d640a@unfix.org>; from jeroen@unfix.org on Wed, Nov 27, 2002 at 01:06:22PM +0100 X-Spam-Status: No, hits=-3.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT,X_AUTH_WARNING version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Nov 27, 2002 at 01:06:22PM +0100, Jeroen Massar wrote: > The OS or actually the resolver part of the OS should be able > to be configured with an option exactly like above. Yes, that is a good idea. > Programs should _never_ have a preference, if they do they > should ask for an AF_INET or AF_INET6 that's enough preference already > :) > I am against having the AI_PREFER4/6 as this would be too program > specific and one needs to recompile to get it out. I agree, we really should avoid this. I think adding even more complexity to getaddrinfo() is a bad idea. And not only does it take time to deploy, but it might also be hard to change the applications later. This is really something the sysadmin should be able to choose, there is no default that fits all. Stig From owner-v6ops@ops.ietf.org Wed Nov 27 08:40:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09091 for ; Wed, 27 Nov 2002 08:40:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H2Rs-0006TV-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 05:41:52 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18H2Rp-0006TJ-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 05:41:50 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARDdDl28938; Wed, 27 Nov 2002 08:39:13 -0500 (EST) Message-Id: <200211271339.gARDdDl28938@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Keith Moore , Joshua Graessley , v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-reply-to: (Your message of "Wed, 27 Nov 2002 09:22:04 +0200.") Date: Wed, 27 Nov 2002 08:39:13 -0500 X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > at least not right now. attempts to talk to v6 sites typically > > time out (which is annoying because the v6 addresses are tried first - > > another thing which needs to be fixed) > > Do I sense this as a voice for support to modify or at least explore the > current de-facto standard ordering? I'm certainly going to change it on the machines that I use (it helps that I have source code) > > it turns out that you need the address ordering to be sensitive to both > > network configuration and to the particular application. some apps will > > be v4 by default, others will be v6 default, others will be exclusively > > one or the other. > > There are already some variables that affect this, namely: > > 1) whether the DNS lookup produces A, AAAA, or both; ie "remote > site configuration" I don't see how this affects ordering - if you don't get back A records are you going to put the AAAA records in a different order relative to one another than if you do get them back? > 2) what ordering for DNS records is used when both are used > (default is AAAA first everywhere I know, no possibility to change that) > > 3) whether the application uses AF_INET, AF_INET6 or AF_UNSPEC > (with server apps, this is even a bit muddier.) > > These help quite a bit, but I guess adding some getaddrinfo hint like > AI_PREFERV4 or AI_PREFERV6 could be added in the case that DNS lookup > returns both addresses, you use AF_UNSPEC and you want to influence the > default DNS record ordering. it's fairly easy for an app to reorder addresses that it gets back between IPv4 and IPv6. but I often find myself wanting to specify a mixed preference like: 6to4 addresses native IPv4 other IPv6 Keith From owner-v6ops@ops.ietf.org Wed Nov 27 08:42:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09151 for ; Wed, 27 Nov 2002 08:42:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H2VT-0006ag-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 05:45:35 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18H2VR-0006aU-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 05:45:33 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gARDjPp31788; Wed, 27 Nov 2002 15:45:25 +0200 Date: Wed, 27 Nov 2002 15:45:25 +0200 (EET) From: Pekka Savola To: Keith Moore cc: Joshua Graessley , Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-Reply-To: <200211271339.gARDdDl28938@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 27 Nov 2002, Keith Moore wrote: > > There are already some variables that affect this, namely: > > > > 1) whether the DNS lookup produces A, AAAA, or both; ie "remote > > site configuration" > > I don't see how this affects ordering - if you don't get back A > records are you going to put the AAAA records in a different > order relative to one another than if you do get them back? Of course you're right -- the ordering described here is only relevant when both are used. The point was that, because of current ordering, people don't really put v6 addresses in AAAA fields that much, so this is no problem (address resolves to either A or AAAA (under e.g. ipv6 subdomain)). But we'd like it to be different.. > > 2) what ordering for DNS records is used when both are used > > (default is AAAA first everywhere I know, no possibility to change that) > > > > 3) whether the application uses AF_INET, AF_INET6 or AF_UNSPEC > > (with server apps, this is even a bit muddier.) > > > > These help quite a bit, but I guess adding some getaddrinfo hint like > > AI_PREFERV4 or AI_PREFERV6 could be added in the case that DNS lookup > > returns both addresses, you use AF_UNSPEC and you want to influence the > > default DNS record ordering. > > it's fairly easy for an app to reorder addresses that it gets back > between IPv4 and IPv6. but I often find myself wanting to specify > a mixed preference like: > > 6to4 addresses .. particularly if you use 6to4 addresses yourself; otherwise you really don't buy much by separating them from other v6. > native IPv4 > other IPv6 Yeah -- but that's something that we must not try to plug into every app -- it should really be done by lower layers (at least, by functions provided by lower layers). No need to write the code 1000 times :-). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 27 08:59:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09662 for ; Wed, 27 Nov 2002 08:59:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H2kb-000754-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 06:01:13 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18H2kY-00074s-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 06:01:10 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARDwWl29166; Wed, 27 Nov 2002 08:58:32 -0500 (EST) Message-Id: <200211271358.gARDwWl29166@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Keith Moore , Joshua Graessley , v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-reply-to: (Your message of "Wed, 27 Nov 2002 15:45:25 +0200.") Date: Wed, 27 Nov 2002 08:58:32 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > it's fairly easy for an app to reorder addresses that it gets back > > between IPv4 and IPv6. but I often find myself wanting to specify > > a mixed preference like: > > > > 6to4 addresses > > .. particularly if you use 6to4 addresses yourself; otherwise you really > don't buy much by separating them from other v6. > > > native IPv4 > > other IPv6 > > Yeah -- but that's something that we must not try to plug into every app > -- it should really be done by lower layers (at least, by functions > provided by lower layers). No need to write the code 1000 times :-). personally I intend to rewrite the library routine so that it references a config file that specifies preferred ordering. eventually it might be nice if the host could get that preference list from the local network. Keith From owner-v6ops@ops.ietf.org Wed Nov 27 09:52:05 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12840 for ; Wed, 27 Nov 2002 09:52:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H3ZA-0008ZG-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 06:53:28 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18H3Z7-0008Yn-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 06:53:25 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gARErCX32467; Wed, 27 Nov 2002 16:53:12 +0200 Date: Wed, 27 Nov 2002 16:53:12 +0200 (EET) From: Pekka Savola To: Stig Venaas cc: Jeroen Massar , "'Gert Doering'" , "'Keith Moore'" , "'Joshua Graessley'" , Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-Reply-To: <20021127132801.A13186@sverresborg.uninett.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 27 Nov 2002, Stig Venaas wrote: > > Programs should _never_ have a preference, if they do they > > should ask for an AF_INET or AF_INET6 that's enough preference already > > :) > > I am against having the AI_PREFER4/6 as this would be too program > > specific and one needs to recompile to get it out. > > I agree, we really should avoid this. I think adding even more > complexity to getaddrinfo() is a bad idea. And not only does it > take time to deploy, but it might also be hard to change the > applications later. This is really something the sysadmin should > be able to choose, there is no default that fits all. There are more layers than that, e.g. - "if I have an app and install it anywhere at all, I have no way of knowing whether the system has implemented A,AAA preferation method -- so I'll just ship it with AF_UNSPEC + AI_PREFERV4, so people can run it with 'app v6host', 'app -6 v46host' or 'app v46host' without problems, it'll always fall back to v4 if it doesn't know better" - "my app is special and is really only usable in v6 context; I'd prefer it to use v6 even though whatever's configured in A,AAAA preferation method. AF_UNSPEC + AI_PREFERV6 could handle that" Ie. I'd like the app writers to be able to write "v6-safe" code. Code that, when run or compiled on nearly any system, would produce code that's safe to be used in v4-preferring environments _regardless of_ whether the app user's box even has any A,AAAA preferation method. But I can very well like with stuff like AI_PREFER* -- we just need the toggle to change the ordering of A,AAAA records when using AF_UNSPEC ASAP, if not yesterday. If we could manage to get that deployed fast enough, and v4 preferred widely enough, perhaps in 1-2 years people could start shipping v6-enabled apps, waiting for the site admins decision to prefer v6 instead when they're confident enough to do so. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 27 10:38:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15076 for ; Wed, 27 Nov 2002 10:38:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H4IJ-0009ua-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 07:40:07 -0800 Received: from avarice.inner.net ([199.33.248.2] helo=inner.net) by psg.com with esmtp (Exim 3.36 #2) id 18H4IG-0009uN-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 07:40:04 -0800 Received: (from smtpd@localhost) by inner.net (8.12.5/8.12.5) id gAREWOnF009847; Wed, 27 Nov 2002 14:32:24 GMT Message-Id: <200211271432.gAREWOnF009847@inner.net> Received: from ministry-of-love.inner.net(63.215.138.186), claiming to be "inner.net" via SMTP by inner.net, id smtpd8gYDjr; Wed Nov 27 09:32:21 2002 To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-reply-to: Your message of "Wed, 27 Nov 2002 09:22:04 +0200." Date: Wed, 27 Nov 2002 10:39:57 -0500 From: Craig Metz X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,SPAM_PHRASE_05_08 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In message , you write: >Do I sense this as a voice for support to modify or at least explore the >current de-facto standard ordering? There is no specified standard, deliberately. This is an implementation issue. Not all implementations have this problem, but many people on this list don't seem to understand that and instead blame getaddrinfo() or blame IPv6. >These help quite a bit, but I guess adding some getaddrinfo hint like >AI_PREFERV4 or AI_PREFERV6 could be added in the case that DNS lookup >returns both addresses, you use AF_UNSPEC and you want to influence the >default DNS record ordering. NO! NO! NO! getaddrinfo is a PROTOCOL INDEPENDENT API. It is NEVER appropriate to cruft ANY protocol-specific options into getaddrinfo. Protocol-specific hacks belong in protocol-specific APIs. If the protocol-independent APIs do not give you the features you want, then use the protocol-dependent APIs instead, which will give you more specific controls. If an application wants to have getaddrinfo() return things in a particular order, it should call getaddrinfo() multiple times in the order it wants, i.e., call it first for req.ai_addr=AF_INET, second for req.ai_addr=AF_INET6, etc. HOWEVER, this behavior would be TOTALLY BROKEN as it first defeats protocol independence (the whole point; if you're not using getaddrinfo in a protocol independent way, why are you using it at all?), and second because it limits you to IPv4 and IPv6. BSDI did this right. BSD/OS had a configurable resolver return order, I believe through a file and an environment variable. Didn't like the system default? Users can request things be done in a different order. Problem solved. I think BSDI gave their code to ISC for use in BIND, but it appears that this feature got lost in the transition. Still, if someone with clues asked the old BSDI folks nicely, you might be able to get their code for this and fold it into your favorite implementation. -Craig From owner-v6ops@ops.ietf.org Wed Nov 27 11:11:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16785 for ; Wed, 27 Nov 2002 11:11:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H4o0-000Avt-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 08:12:52 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18H4nu-000Ava-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 08:12:46 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gARGCgr01047; Wed, 27 Nov 2002 18:12:42 +0200 Date: Wed, 27 Nov 2002 18:12:41 +0200 (EET) From: Pekka Savola To: Craig Metz cc: v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-Reply-To: <200211271432.gAREWOnF009847@inner.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 27 Nov 2002, Craig Metz wrote: > In message , you write: > >Do I sense this as a voice for support to modify or at least explore the > >current de-facto standard ordering? > > There is no specified standard, deliberately. This is an implementation > issue. Not all implementations have this problem, but many people on this list > don't seem to understand that and instead blame getaddrinfo() or blame IPv6. Yes, this is implementation specific. But most do have this _operational_ _deployment_ _problem_. And sitting on our thumbs does little to help with getting v6 out there. I'd like to see it one day :-) > >These help quite a bit, but I guess adding some getaddrinfo hint like > >AI_PREFERV4 or AI_PREFERV6 could be added in the case that DNS lookup > >returns both addresses, you use AF_UNSPEC and you want to influence the > >default DNS record ordering. > > NO! NO! NO! > > getaddrinfo is a PROTOCOL INDEPENDENT API. It is NEVER appropriate to cruft > ANY protocol-specific options into getaddrinfo. Protocol-specific hacks belong > in protocol-specific APIs. If the protocol-independent APIs do not give you > the features you want, then use the protocol-dependent APIs instead, which > will give you more specific controls. I'm sorry to wake you up from the wonderland, but getaddrinfo has already been encumbered with protocol-specific options (think AI_MAPPED..). Whether anything can or should be salvaged is another issue.. > If an application wants to have getaddrinfo() return things in a particular > order, it should call getaddrinfo() multiple times in the order it wants, i.e., > call it first for req.ai_addr=AF_INET, second for req.ai_addr=AF_INET6, etc. > HOWEVER, this behavior would be TOTALLY BROKEN as it first defeats protocol > independence (the whole point; if you're not using getaddrinfo in a protocol > independent way, why are you using it at all?), and second because it limits > you to IPv4 and IPv6. Right. (I prefer some deliberate ordering for AF_UNSPEC of course.) > BSDI did this right. BSD/OS had a configurable resolver return order, I > believe through a file and an environment variable. Didn't like the system > default? Users can request things be done in a different order. Problem solved. That's nice, but as more folks haven't done it -- it helps little in this operational problem. This is probably caused by the fact that most many not have considered this problem serious at all, worth spending time on -- and there are many strategies how v6 could be deployed, some of which aren't affected by the lack of the option. I believe it's our job to raise awareness on this. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 27 11:19:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17045 for ; Wed, 27 Nov 2002 11:19:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H4wG-000BCh-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 08:21:24 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18H4wC-000BCU-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 08:21:20 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 452477CD9; Wed, 27 Nov 2002 17:21:02 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id D2C9C7B93; Wed, 27 Nov 2002 17:20:56 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" , "'Stig Venaas'" Cc: "'Gert Doering'" , "'Keith Moore'" , "'Joshua Graessley'" , Subject: RE: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] Date: Wed, 27 Nov 2002 17:21:53 +0100 Organization: Unfix Message-ID: <000901c29631$1a6166b0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-reply-to: Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA17045 Pekka Savola [mailto:pekkas@netcore.fi] wrote: > On Wed, 27 Nov 2002, Stig Venaas wrote: > > > Programs should _never_ have a preference, if they do they > > > should ask for an AF_INET or AF_INET6 that's enough > preference already > > > :) > > > I am against having the AI_PREFER4/6 as this would be too program > > > specific and one needs to recompile to get it out. > > > > I agree, we really should avoid this. I think adding even more > > complexity to getaddrinfo() is a bad idea. And not only does it > > take time to deploy, but it might also be hard to change the > > applications later. This is really something the sysadmin should > > be able to choose, there is no default that fits all. > > There are more layers than that, e.g. > > - "if I have an app and install it anywhere at all, I have no way of > knowing whether the system has implemented A,AAA preferation > method -- so > I'll just ship it with AF_UNSPEC + AI_PREFERV4, so people can > run it with > 'app v6host', 'app -6 v46host' or 'app v46host' without > problems, it'll > always fall back to v4 if it doesn't know better" It will currently always fall back to v4 if one wrote it correctly: - tries AAAA (if dns returned it) - tries A (if dns returned it) > - "my app is special and is really only usable in v6 > context; I'd prefer > it to use v6 even though whatever's configured in A,AAAA preferation > method. AF_UNSPEC + AI_PREFERV6 could handle that" One should use AF_INET6 for that. And this is what currently happens. But indeed if the resolver reorders A's in front of AAAA this doesn't work anymore. Then again the application can request a getaddrinfo() for AF_INET6 and if those didn't connect go for the AF_INET addresses. I don't think that there are many, even better name me 1, application that would want to do it. Even though it could be a quite plausible example one day. I don't think it will happen. > Ie. I'd like the app writers to be able to write "v6-safe" > code. Code > that, when run or compiled on nearly any system, would > produce code that's > safe to be used in v4-preferring environments _regardless of_ > whether the > app user's box even has any A,AAAA preferation method. Ofcourse this should be true. And currently it nicely falls back to v4. if the resolver doesn't support preferring they should push their resolver coder to upgrade it. If people don't upgrade reguraly they won't have IPv6 support anyways on most platforms > But I can very well like with stuff like AI_PREFER* -- we > just need the toggle to change the ordering of A,AAAA records when using > AF_UNSPEC ASAP, if not yesterday. > If we could manage to get that deployed fast enough, > and v4 preferred widely enough, perhaps in 1-2 years people > could start shipping v6-enabled apps, waiting for the site admins > decision to prefer v6 instead when they're confident enough to do so. IMHO the toggle should go into the resolver and NOT in the application. If the application is specific enough to always request eg IPv6 then it should do getaddrinfo(AF_INET6) and then fallback to getaddrinfo(AF_INET). As been said getaddrinfo is for AF independence if you depend on something request specifically that type of protocol. Greets, Jeroen From owner-v6ops@ops.ietf.org Wed Nov 27 11:30:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17499 for ; Wed, 27 Nov 2002 11:30:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H56Y-000BbL-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 08:32:02 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18H56U-000Bb5-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 08:31:58 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gARGVlt01335; Wed, 27 Nov 2002 18:31:47 +0200 Date: Wed, 27 Nov 2002 18:31:46 +0200 (EET) From: Pekka Savola To: Jeroen Massar cc: "'Stig Venaas'" , "'Gert Doering'" , "'Keith Moore'" , "'Joshua Graessley'" , Subject: RE: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-Reply-To: <000901c29631$1a6166b0$210d640a@unfix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 27 Nov 2002, Jeroen Massar wrote: > > On Wed, 27 Nov 2002, Stig Venaas wrote: > > > > Programs should _never_ have a preference, if they do they > > > > should ask for an AF_INET or AF_INET6 that's enough > > preference already > > > > :) > > > > I am against having the AI_PREFER4/6 as this would be too program > > > > specific and one needs to recompile to get it out. > > > > > > I agree, we really should avoid this. I think adding even more > > > complexity to getaddrinfo() is a bad idea. And not only does it > > > take time to deploy, but it might also be hard to change the > > > applications later. This is really something the sysadmin should > > > be able to choose, there is no default that fits all. > > > > There are more layers than that, e.g. > > > > - "if I have an app and install it anywhere at all, I have no way of > > knowing whether the system has implemented A,AAA preferation > > method -- so > > I'll just ship it with AF_UNSPEC + AI_PREFERV4, so people can > > run it with > > 'app v6host', 'app -6 v46host' or 'app v46host' without > > problems, it'll > > always fall back to v4 if it doesn't know better" > > It will currently always fall back to v4 if one wrote it correctly: > - tries AAAA (if dns returned it) > - tries A (if dns returned it) Sure.. but in this case www.google.com will not have AAAA records in, well, about 5-10 years. They have no incentive to do so, _at all_ -- quite the contrary -- as their v4-enabled users would get worse service. Or many more such sites. If try A first would be the option, www.google.com (etc.) folks would have _no_ reason not to put the AAAA record in www.google.com in a year or two. But this is just v6 deployment strategy. Both ways could work.. but it seems to me that we must go and take 1). > > - "my app is special and is really only usable in v6 > > context; I'd prefer > > it to use v6 even though whatever's configured in A,AAAA preferation > > method. AF_UNSPEC + AI_PREFERV6 could handle that" > > One should use AF_INET6 for that. And this is what currently happens. > But indeed if the resolver reorders A's in front of AAAA this doesn't > work anymore. > Then again the application can request a getaddrinfo() for AF_INET6 and > if those didn't connect go for the AF_INET addresses. > I don't think that there are many, even better name me 1, application > that would want to do it. Even though it could be a quite plausible > example one day. I don't think it will happen. This is a bit dubious case, I agree -- but e.g. future peer-to-peer, end-to-end applications could profit from trying v6 first, then falling back to v4 if necessary. > > Ie. I'd like the app writers to be able to write "v6-safe" > > code. Code > > that, when run or compiled on nearly any system, would > > produce code that's > > safe to be used in v4-preferring environments _regardless of_ > > whether the > > app user's box even has any A,AAAA preferation method. > > Ofcourse this should be true. And currently it nicely falls back > to v4. You're missing the point. > if the resolver doesn't support preferring they should > push their resolver coder to upgrade it. A lot of pushing is needed, it seems. > > But I can very well like with stuff like AI_PREFER* -- we > > just need the toggle to change the ordering of A,AAAA records when > using > > AF_UNSPEC ASAP, if not yesterday. > > If we could manage to get that deployed fast enough, > > and v4 preferred widely enough, perhaps in 1-2 years people > > could start shipping v6-enabled apps, waiting for the site admins > > decision to prefer v6 instead when they're confident enough to do so. > > IMHO the toggle should go into the resolver and NOT in the application. > If the application is specific enough to always request eg IPv6 then it > should do getaddrinfo(AF_INET6) and then fallback to > getaddrinfo(AF_INET). I kinda agree with this. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 27 12:01:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19149 for ; Wed, 27 Nov 2002 12:01:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H5bd-000CyN-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 09:04:09 -0800 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #2) id 18H5bZ-000CxB-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 09:04:05 -0800 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 27 Nov 2002 09:03:33 -0800 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Nov 2002 09:03:33 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 27 Nov 2002 09:03:34 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 27 Nov 2002 09:03:33 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Wed, 27 Nov 2002 09:03:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 6to4 security questions Date: Wed, 27 Nov 2002 09:03:35 -0800 Message-ID: Thread-Topic: 6to4 security questions Thread-Index: AcKVn/rYG71eR6klQvy6QPrcmFfkPAAlHDbA From: "Christian Huitema" To: "Alain Durand" Cc: "Brian E Carpenter" , "Pekka Savola" , X-OriginalArrivalTime: 27 Nov 2002 17:03:34.0397 (UTC) FILETIME=[EB8B4AD0:01C29636] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA19149 > >There are however a number of mitigating factors: > > > >1) The attack does not include a multiplier effect; the amount of > >traffic directed at the target will be about equal to the amount of > >traffic sent by the attacker. > > > Not necessarely. It depend on the protocol used on the reflectors. > If you can find a UDP protocol that echos n packets to an original > short incoming packet, you have a multiplier effect. The problem there is with the applications, not with 6to4. Deploying a protocol that is ready to blast packets without some form of initial handshake is a truly bad idea. Let's face it: as an application, you can never trust that the source address is not forged. > >2) The attack packets go through a choke point, the 6to4 relay between > >the laundering site and the target. > > > Not necessarely. If thousands of refletors are used, they will used > different relays. Well, it is still mitigation: it forces the attacker to find thousand of relays, and thousands of applications. > >3) The packets received by the target contain the address of the > >relaying 6to4 site. > > > If (many) thousands of reflectors are used, each reflector can be > exercized only once and still create a massive DDOS. > Such an attack will be even harder to detect using packet sampling > techniques. I am not sure that we cannot use packet sampling techniques, actually. Suppose that each 6to4 router, with a low probability of e.g. 1%, sends an ITRACE or equivalent to the IPv6 source of the encapsulated packet, and that the ITRACE contains the indication of the actual IPv4 source. If thousands of relays are used, tens of them will send an ITRACE packet towards the target of the attack, thus exposing the IPv4 origin. I guess we ought to study this ITRACE idea further. > >4) The payload of the packets received by the target will be a response > >generated by the laundering server, which limits any "magic packet" > >issue. > > > If many reflectors are exercised, depending on the protocol used, > each DDOS packet may be different. No, that is not true in practice. Even if they are different, they cannot be "chosen". The "magic packet" terminology refers to attacks such as "ping of death", in which a carefully crafted packet triggers an abnormal condition in the receiving host. In a reflection attack, the packet received by the target is a response packet, produced by a normally behaving server. Such packets are likely to be discarded without much processing, since the target did not initiate the transaction and is not expecting a response; they are also very unlikely to be crafted in the specific way that may trigger a software bug. For example, you cannot mount a SYN attack using a reflector: the target will receive a SYN ACK, that will be immediately discarded since there is no corresponding half-open connection. The consequence is that a reflected attack has to be brute force, aiming simply at the bandwidth of the target. Such attacks require massive amounts of packets, and are thus much more susceptible to detection using ITRACE. > >5) The attack only provides value if the attacker's IPv4 connection was > >subject to ingress filtering, which is alas not a very common case. > > > True. But this will create disincentive for ISP to put ingress filtering > in place and ruin the effort of those who did. Uh? If you are saying that the ISP can somehow guarantee to their customers that all source addresses are genuine, you are seriously misguided. For example, an attacker could hack into a router, from were it can send packets from virtually any source addresses. There are thousands of routers in the Internet; are you willing to assume that none of them will ever be cracked? > >Because of the absence of a magic packet effect, this attack is only > >really powerful if it is practiced by a "fleet of zombies" using a large > >number of reflectors. > > > Not really, you can use only a limited number of zombies (even a well > connected one is enough) if you can discover thousands of valid 6to4 > addresses. > As the packets will be 'landered' by the 6to4 routers, it will be very > hard > to trace the attack back to the zombie. If you have a limited number of zombies, then the ITRACE approach will work. > >In short, yes it is a vulnerability, but it is not a terribly dangerous > >one, and it is a vulnerability that will in any case disappear with > >6to4, when sites receive native IPv6 connectivity. So, yes, a fix is > >welcome; however, the fix should not be so drastic as to impede the > >"autonomous deployment" advantage of 6to4. > > > See my comment in the other thread on 6to4 & Teredo vs Tunnel Broker. I believe that 6to4 and tunnel broker have some very different characteristics. Opposing one to the other as the ultimate solution is probably a bad idea. It is much more reasonable to acknowledge the difference and let the market sort it out. -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Nov 27 12:05:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19264 for ; Wed, 27 Nov 2002 12:05:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H5et-000D6M-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 09:07:31 -0800 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #2) id 18H5eo-000D5L-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 09:07:26 -0800 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 27 Nov 2002 09:06:55 -0800 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Nov 2002 09:06:54 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Wed, 27 Nov 2002 09:06:51 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 27 Nov 2002 09:06:54 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Wed, 27 Nov 2002 09:06:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] Date: Wed, 27 Nov 2002 09:06:56 -0800 Message-ID: Thread-Topic: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] Thread-Index: AcKWNPJjmAgJM5+JTOuKzMQE95oZaQAAgRcA From: "Christian Huitema" To: "Pekka Savola" , "Jeroen Massar" Cc: "Stig Venaas" , "Gert Doering" , "Keith Moore" , "Joshua Graessley" , X-OriginalArrivalTime: 27 Nov 2002 17:06:55.0072 (UTC) FILETIME=[6327DE00:01C29637] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA19264 > > It will currently always fall back to v4 if one wrote it correctly: > > - tries AAAA (if dns returned it) > > - tries A (if dns returned it) > > Sure.. but in this case www.google.com will not have AAAA records in, > well, about 5-10 years. They have no incentive to do so, _at all_ -- > quite the contrary -- as their v4-enabled users would get worse service. A nice point of 6to4 as a transition strategy is that its performance are guaranteed to be very close from those of the underlying IPv4. A normal evolution for sites like Google would be to multihome and expose both a native IPv6 connection and a 6to4 connection. Address selection rules will guarantee that "transition" users pick the 6to4 destination, while native users pick the native address. This will largely deal with your performance concern. -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Nov 27 12:12:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19760 for ; Wed, 27 Nov 2002 12:12:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H5lI-000DOI-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 09:14:08 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18H5lE-000DNb-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 09:14:04 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gARHDhi01990; Wed, 27 Nov 2002 19:13:43 +0200 Date: Wed, 27 Nov 2002 19:13:42 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: Jeroen Massar , Stig Venaas , Gert Doering , Keith Moore , Joshua Graessley , Subject: RE: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 27 Nov 2002, Christian Huitema wrote: > > > It will currently always fall back to v4 if one wrote it correctly: > > > - tries AAAA (if dns returned it) > > > - tries A (if dns returned it) > > > > Sure.. but in this case www.google.com will not have AAAA records in, > > well, about 5-10 years. They have no incentive to do so, _at all_ -- > > quite the contrary -- as their v4-enabled users would get worse > service. > > A nice point of 6to4 as a transition strategy is that its performance > are guaranteed to be very close from those of the underlying IPv4. A > normal evolution for sites like Google would be to multihome and expose > both a native IPv6 connection and a 6to4 connection. Address selection > rules will guarantee that "transition" users pick the 6to4 destination, > while native users pick the native address. This will largely deal with > your performance concern. This would help only if all v6 users, v6-native included, would enable 6to4 as an "optimization technique", as proposed previously. Doesn't seem like a scalable solution. (why v6-native? v6 native connection, here meaning non-6to4 global addresses, cannot be guaranteed to reach google in an optimal fashion -- quite far from it.) Another transition strategy would be to _not_ use any native v6 _at all_ yet, only 6to4 -- or feed the hosts only native more specific routes to those networks that are "well-connected" (where you wouldn't use 6to4). Reminds too much of Jim Flemings ideas, too scary to even contemplate. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Nov 27 12:13:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19797 for ; Wed, 27 Nov 2002 12:12:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H5m5-000DSQ-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 09:14:57 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18H5lu-000DRA-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 09:14:46 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARHC2l01120; Wed, 27 Nov 2002 12:12:03 -0500 (EST) Message-Id: <200211271712.gARHC2l01120@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Craig Metz cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-reply-to: (Your message of "Wed, 27 Nov 2002 10:39:57 EST.") <200211271432.gAREWOnF009847@inner.net> Date: Wed, 27 Nov 2002 12:12:02 -0500 X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > NO! NO! NO! > > getaddrinfo is a PROTOCOL INDEPENDENT API. It is NEVER appropriate to cruft > ANY protocol-specific options into getaddrinfo. Protocol-specific hacks belong > in protocol-specific APIs. If the protocol-independent APIs do not give you > the features you want, then use the protocol-dependent APIs instead, which > will give you more specific controls. you're absolutely correct. thank you for saying that. Keith From owner-v6ops@ops.ietf.org Wed Nov 27 12:24:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20312 for ; Wed, 27 Nov 2002 12:24:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H5wg-000Dxw-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 09:25:54 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18H5wd-000Dxg-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 09:25:51 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gARHN6l01185; Wed, 27 Nov 2002 12:23:06 -0500 (EST) Message-Id: <200211271723.gARHN6l01185@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Christian Huitema , Jeroen Massar , Stig Venaas , Gert Doering , Keith Moore , Joshua Graessley , v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-reply-to: (Your message of "Wed, 27 Nov 2002 19:13:42 +0200.") Date: Wed, 27 Nov 2002 12:23:06 -0500 X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > A nice point of 6to4 as a transition strategy is that its performance > > are guaranteed to be very close from those of the underlying IPv4. A > > normal evolution for sites like Google would be to multihome and expose > > both a native IPv6 connection and a 6to4 connection. Address selection > > rules will guarantee that "transition" users pick the 6to4 destination, > > while native users pick the native address. This will largely deal with > > your performance concern. > > This would help only if all v6 users, v6-native included, would enable > 6to4 as an "optimization technique", as proposed previously. I don't buy it because it's an all-or-nothing argument. v6 deployment isn't going to be uniform across the world, or across applications. Some places will deploy native v6 aggressively; other places will feel more satisfied with their existing v4 infrastructures. Some applications will naturally favor v6, others will favor v4, others will be agnostic about it. Keith From owner-v6ops@ops.ietf.org Wed Nov 27 12:35:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20820 for ; Wed, 27 Nov 2002 12:35:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H68J-000ETP-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 09:37:55 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18H68H-000ETC-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 09:37:53 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18H68G-0009ln-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 09:37:53 -0800 Message-Id: <20021128.023740.07233604.yoshfuji@wide.ad.jp> In-Reply-To: References: <000901c29631$1a6166b0$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 28 Nov 2002 02:37:40 +0900 (JST) To: pekkas@netcore.fi Cc: jeroen@unfix.org, Stig.Venaas@uninett.no, gert@space.net, moore@cs.utk.edu, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] In article (at Wed, 27 Nov 2002 18:31:46 +0200 (EET)), Pekka Savola says: > > It will currently always fall back to v4 if one wrote it correctly: > > - tries AAAA (if dns returned it) > > - tries A (if dns returned it) > > Sure.. but in this case www.google.com will not have AAAA records in, > well, about 5-10 years. They have no incentive to do so, _at all_ -- > quite the contrary -- as their v4-enabled users would get worse service. This problem is NOT only ipv6 and/or getaddrinfo thing at all. If one of IPv4 address on a DNS for a single FQDN were down, what would be happened? (You might have recognized similar problem with h_addr_list[] in struct hostent{} :-)) What should be to blame is poor programming of application. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From owner-v6ops@ops.ietf.org Wed Nov 27 12:57:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21723 for ; Wed, 27 Nov 2002 12:57:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18H6TK-000FMQ-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 09:59:38 -0800 Received: from avarice.inner.net ([199.33.248.2] helo=inner.net) by psg.com with esmtp (Exim 3.36 #2) id 18H6TH-000FMD-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 09:59:35 -0800 Received: (from smtpd@localhost) by inner.net (8.12.5/8.12.5) id gARGkD9C010113; Wed, 27 Nov 2002 16:46:13 GMT Message-Id: <200211271646.gARGkD9C010113@inner.net> Received: from localhost.inner.net(127.0.0.1), claiming to be "inner.net" via SMTP by inner.net, id smtpdlFDpWN; Wed Nov 27 11:46:10 2002 To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering [Re: IPv6 transition architecture discussion] In-reply-to: Your message of "Wed, 27 Nov 2002 18:12:41 +0200." Date: Wed, 27 Nov 2002 11:46:10 -0500 From: Craig Metz X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In message , you write: >I'm sorry to wake you up from the wonderland, but getaddrinfo has already >been encumbered with protocol-specific options (think AI_MAPPED..). > >Whether anything can or should be salvaged is another issue.. Last time I checked, AI_MAPPED was not a valid req.ai_flags argument to getaddrinfo(), only to the IPv6-specific API getnodeinfo(). That was a reasonable way to do things -- protocol independent APIs are protocol independent, and protocol-specific features are available through protocol specific APIs. Admittedly, the last time I checked was a long time ago, so I should check to see whether there has been devolution in this way in the mean time. >That's nice, but as more folks haven't done it -- it helps little in this >operational problem. > >This is probably caused by the fact that most many not have considered >this problem serious at all, worth spending time on -- and there are many >strategies how v6 could be deployed, some of which aren't affected by the >lack of the option. I believe it's our job to raise awareness on this. Raising awareness is fine. But that twenty, thirty, forty emails on this mailing list on this topic don't actually cause the changes to happen. A polite email to your implementation's authors ("vendor") pointing out this problem, pointing out how it was solved years ago, and pointing out where the code might be freely available (I don't know that it is for certain, that's a slightly informed speculation), would do far more good towards getting your implementation to fix the problem. Now, I don't know whether there are security implications with this solution, and expect that there are, but that they're problems we know how to deal with. -Craig From owner-v6ops@ops.ietf.org Wed Nov 27 22:09:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06990 for ; Wed, 27 Nov 2002 22:09:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HF4H-000At4-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 19:10:21 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18HF4F-000Ass-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 19:10:19 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 9B0E44B22; Thu, 28 Nov 2002 12:10:15 +0900 (JST) To: micklesc@aol.net Cc: "V6ops" In-reply-to: micklesck's message of Wed, 20 Nov 2002 21:46:38 EST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ISP Cases Draft: Which sections have too much information? From: itojun@iijlab.net Date: Thu, 28 Nov 2002 12:10:15 +0900 Message-Id: <20021128031015.9B0E44B22@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >From the WG meeting today there was consensus that there >was too much information in the draft. Can we get specific >feedback on which sections should be paired back? >http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-02.txt i understand your motive to document the operational details, but i don't think the detail all down to the copper level will help readers - readers will need a proper level of abstraction. for instance: page 20, figure 3.3.2 page 22, figure 3.3.3 page 23, figure 3.3.4 do you really need to go into ATM/AAL5? i don't think it make any difference even if we remove all ATM/AAL5 details (there's no real reference to ATM/AAL5 in the text). there's no reference to PPPoE, or PPPoA - there's no difference in the description. the most important points are (1) there are 3 IP devices - customer hosts, customer router, and ISP edge router (2) customer router and ISP edge router will establish a point-to-point connectivity, either by ATM PVC, PPPoE, or PPPoA. (3) in some cases, ISP edge router uses L2TP to aggregate connections (4) customer router may implement NAT (sigh) if you abstract it to proper level, subsections in 3.3.2 will become a single diagram. <--customer------> <--ISP----------> +-----+ +-------+ +----+------+ |Hosts|--+Router +----------------+ ISP | C +-----+ +-------+ | Edge +=>O | Router | R +-----------+ E same goes to section 3.6 (public access wireless LAN). i don't think there's any difference between 802.11b-based solution and 802.11x-based solution, with respect to IPv6 transition. itojun From owner-v6ops@ops.ietf.org Wed Nov 27 23:46:17 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08942 for ; Wed, 27 Nov 2002 23:46:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HGZY-000Ee4-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 20:46:44 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18HGZV-000Eds-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 20:46:41 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id BC9C24B22 for ; Thu, 28 Nov 2002 13:46:37 +0900 (JST) To: v6ops@ops.ietf.org Subject: on NAT-PT X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Thu, 28 Nov 2002 13:46:37 +0900 Message-Id: <20021128044637.BC9C24B22@coconut.itojun.org> X-Spam-Status: No, hits=1.0 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk there are some concerns raised in the working group meeting with respect to NAT-PT. it seems to me that the concerns does not have enough technical ground (or there are some confusions in understanding how NAT-PT works). i don't see the need for revising NAT-PT at all. some clarifications on the document might be nice, but no major re-work is needed, IMHO. itojun draft-wiljakka-3gpp-ipv6-transition-01.txt, page 9: > NAPT-PT introduces a number of limitations that are expected to be > magnified within the 3GPP architecture. Some of these limitations > are listed here: > 1. NAPT-PT is a single point of failure for all ongoing > connections. > 2. Additional forwarding delays due to further processing, when > compared to normal IP forwarding. > 3. Problems with source address selection due to the inclusion of > a DNS ALG on the same node [NATPT-DNS]. > 4. NAPT-PT does not work (without application level gateways) for > applications that embed IP addresses in their payload. > 5. NAPT-PT breaks DNSSEC. > 6. NAPT-PT does not scale very well in large networks. (1), (2), and (4) are inherent problem with NAT. it is unavoidable. if you wish to avoid this, you'll need to make cellular node a dual stack node and make them use IPv4 directly (instead of using IPv6-to- IPv4 translation). (3) is incorrect, see below. (5) - when you rely upon DNS responses created on the fly, as well as a box that rewrites your data traffic, why this is a show-stopper? (6) - see below. > To minimize the problems associated with NAPT-PT, the following > actions are recommended: > 1. Separate the DNS ALG from the NAPT-PT node. > 2. Ensure that NAPT-PT does not become a single point of > failure. > 3. Allow for load sharing between different translators. That > is, it should be possible for different connections to go > through different translators. Note that load sharing alone > does not prevent NAPT-PT from becoming a single point of > failure. > There are certain ways to fix the problems with NAPT-PT, one > suggestion is [NAT64]. (1) is not correct. NAT-PT RFC does not specify where to place DNS-ALG. DNS-ALG and NAT-PT translation part can reside on different boxes. when there's only one IPv4 address available to the site, there's no other choice than to collocate DNS-ALG and the translation part. (RFC2766 seems to talk about this situation only, which might be the source of the confusion) (2) is not avoidable with NAT-PT, as it is a NAT (keeps state in translation part). SIIT could be another choice, but there are some concerns like draft-itojun-v6ops-v4mapped-harmful-01.txt in the use of IPv4 mapped address on wire. (3) is not correct. you can place the following boxes and perform load balancing between NAT-PT translation part. see RFC3142 page 5 for more details. - multiple NAT-PT translation part, configured with different NAT-PT translation prefix, and - DNS-ALG that returns addresses crafted from multiple different NAT-PT translation prefix randomly draft-huitema-ngtrans-unmaneval-01.txt, page 4: >This section makes an important assumption: it assumes that the NAT- >PT acts as a bridge between two networks, one IPv6-only and the >other IPv6-only. As a result, the DNS-ALG will translate a DNS "and the other IPv4-only", i suppose. >request for a AAAA record coming from the IPv6 host into a request >for an A record, and vice versa. The problem is that address >translation does not know if the traffic originates from an IPv4 >only/IPv6 only node or from a dual stack node. When a dual stack >node A wants to communicate with an IPv4 only host B, the dual stack >host A gets either the IPv4 address of B (preferred) or an IPv6 >address which is some kind of translation of the IPv4 address of B. >This latter situation is not wanted, because it means unnecessary >translation between IPv4 and IPv6. This is shown in the table below. the answer is simple - don't use DNS-ALG if you are a dual stack node. use DNS-ALG as your recursive resolver only when you are IPv6 only node (hence you use NAT-PT translation part if the ultimate destionation is IPv4-only). From owner-v6ops@ops.ietf.org Thu Nov 28 01:12:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10727 for ; Thu, 28 Nov 2002 01:12:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HHvr-000HsF-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 22:13:51 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18HHvo-000Hr9-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 22:13:49 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id B1F1F4B23 for ; Thu, 28 Nov 2002 15:13:46 +0900 (JST) To: v6ops@ops.ietf.org In-reply-to: itojun's message of Thu, 28 Nov 2002 13:46:37 +0900. <20021128044637.BC9C24B22@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Thu, 28 Nov 2002 15:13:46 +0900 Message-Id: <20021128061346.B1F1F4B23@coconut.itojun.org> X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > there are some concerns raised in the working group meeting > with respect to NAT-PT. it seems to me that the concerns does not > have enough technical ground (or there are some confusions in > understanding how NAT-PT works). i don't see the need for revising > NAT-PT at all. some clarifications on the document might be nice, > but no major re-work is needed, IMHO. more comments on other drafts. i'm not really defending NAT-PT itself, actually i would like to see less use of NAT-PT (i prefer dual stack approach). i just don't see the technical ground for the voices like "NAT-PT is evil, need a revised version". itojun draft-durand-natpt-dns-alg-issues-00.txt 1.1 > RFC2766 is not clear on how a DNS-ALG should treat answers to A > queries made by internal nodes. As a matter of fact, one could > fear that a careless a DNS-ALG would also intercept them and translate > them into a AAAA form. In other words, nodes asking for a A record > could be returned a AAAA record. Although this may not be a problem > for simple IPv6 only applications, it may be a concern for applications > that 'walk through' the DNS structure and may pas information to peers. if you are an IPv6-only node and would like to communicate with IPv4- only node within the same site, you will still want to use NAT-PT translator, therefore it is okay for DNS-ALG to translate A responses into AAAA responses. > Second, the application has no way of knowing that the returned AAAA > address is actually not a real IPv6 one, but a IPv4 translated one. > It may be led to believe that it's a real one and think "It's IPv6, > so it has End to End IP connectivity, thus there will be no NAT in > the middle and I can use any IPv6 specific options" This is the whole point of NAT - you want NAT box be invisible from the NAT customers (in NAT-PT case, IPv6-only nodes). if the NAT is visible to the NAT customer, it is more like RSIP. 1.2 > => The communication between a node within the NAT-PT domain and a > external dual stack host will select the translated path over the > native IPv6 path. It really depends on how your DNS-ALG treats dual stack FQDN. As far as I understand, DNS-ALG won't perform address rewrite (from A to AAAA) if an FQDN has both A and AAAA records. Therefore, the point made in 1.2 looks moot. 1.3 > NAT-PT ALG makes the assumption that the DNS traffic goes through the > NAT-PT box. > > This is OK is DNS resolution is done over IPv4. However, if it is > done over IPv6, there is no reason why the DNS traffic will still go > through the NAT-PT box unless the NAT-PT box is also the default IPv6 > router of the site. not necessary. what NAT-PT really want are: - the translated prefix (P::/96) used by DNS-ALG gets routed towards NAT-PT translator box. - NAT-PT translator box, as well as DNS-ALG be dual stack there's no requirement at all for NAT-PT translator box, nor DNS-ALG box, being a default router. i guess RFC2766 is a bit unclear about this point - you may want to check RFC3142 for better documentation. 1.4 > Section 7.5 of RFC2766 says that NAT-PT is not deployable with DNS- > sec. It would work if all the DNS resolution were done over IPv6, > but in a mixed environment as described in draf-ietf-ngtrans-dns- > ops-req-03.txt, this will be a problem. as written in the previous email meesage, why bother. >> (5) - when you rely upon DNS responses created on the fly, as well as >> a box that rewrites your data traffic, why this is a show-stopper? From owner-v6ops@ops.ietf.org Thu Nov 28 02:51:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22227 for ; Thu, 28 Nov 2002 02:50:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HJTd-000LnI-00 for v6ops-data@psg.com; Wed, 27 Nov 2002 23:52:49 -0800 Received: from tyholt.uninett.no ([158.38.60.10]) by psg.com with esmtp (Exim 3.36 #2) id 18HJTa-000Lm5-00 for v6ops@ops.ietf.org; Wed, 27 Nov 2002 23:52:46 -0800 Received: from sverresborg.uninett.no (sverresborg.uninett.no [158.38.62.92]) by tyholt.uninett.no (8.12.6/8.12.6) with ESMTP id gAS7qaDd032148; Thu, 28 Nov 2002 08:52:36 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.11.6/8.11.2) id gAS7qaG29955; Thu, 28 Nov 2002 08:52:36 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 28 Nov 2002 08:52:35 +0100 From: Stig Venaas To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B" Cc: pekkas@netcore.fi, jeroen@unfix.org, gert@space.net, moore@cs.utk.edu, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering Message-ID: <20021128085235.A29940@sverresborg.uninett.no> References: <000901c29631$1a6166b0$210d640a@unfix.org> <20021128.023740.07233604.yoshfuji@wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021128.023740.07233604.yoshfuji@wide.ad.jp>; from yoshfuji@wide.ad.jp on Thu, Nov 28, 2002 at 02:37:40AM +0900 X-Spam-Status: No, hits=-3.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT,X_AUTH_WARNING version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Nov 28, 2002 at 02:37:40AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote: > This problem is NOT only ipv6 and/or getaddrinfo thing at all. > If one of IPv4 address on a DNS for a single FQDN were down, > what would be happened? > > (You might have recognized similar problem with h_addr_list[] in > struct hostent{} :-)) > > What should be to blame is poor programming of application. I think applications should try all addresses returned if necessary to make a tcp connection. This solves the problem of unreachability (except that it might take a while to establish a connection), but you still have a problem that the IPv6 path might be poor. Stig From owner-v6ops@ops.ietf.org Thu Nov 28 04:16:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23604 for ; Thu, 28 Nov 2002 04:16:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HKo6-000Nd5-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 01:18:02 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18HKnz-000Ncs-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 01:17:56 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Nov 2002 14:47:27 +0530 Message-ID: From: "Thakur, Anand" To: juha.wiljakka@nokia.com Cc: "Ajay Jain (E-mail)" Subject: RE: About draft-thakur-v6oanand.thakur@hpsglobal.comps-3gpp-cases -00.txt Date: Thu, 28 Nov 2002 14:53:37 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.9 required=5.0 tests=EMAIL_ATTRIBUTION,EXCHANGE_SERVER,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk dear juha wiljakka, on 27th nov,2002 juha wiljakka wrote: >In Atlanta meeting, draft-wiljakka-3gpp-ipv6-transition-02.txt was approved >to become a working group document for v6ops wg, and I am planning to >publish it as -00 v6ops draft next week. I am proposing that we could use >your document as an input document for the v6ops wg doc and mention your >names in the acknowledgement section. How would you like that idea? >The best way to give input would be commenting our latest draft - work is >currently being done to update that. Deadline for comments would be Sunday >01.12.02. i guess that is the best thing to do. though i find that our basic idea is the same (logic behind the choice of different transition mechanisms) here are some general comments on your latest draft: 1) section 3.2 : i don't think any of the tunneling mechanisms discussed so far is good/reliable enough. what i suggest is that a NAPT + DNS_ALG like mechanism be used to create a new ipv4 header and tunnel the original ipv6 packet inside this header.this mechanism will be valid & efficient when v6 has been deployed at a small as well as at a large scale unlike some of the other tunneling mechanisms. also since napt-pt usage is suggested in (3.4)therefore these translators will be all that is required in either scenario (3.3 and 3.4). whether tunneling is done or translation is done with the gathered information will be decided by the edge router depending on whether the final destination is v6(tunneling) or v4(translation). 2)section 3.4 : i think the suggestion to use multiple translators for load sharing is a very good idea as it not only does away with the problem of forwarding delays but also to a certain extent solves the 'single point of failure' problem. though the multiple translators will have to share address pools and configuration information. one very important point that i find missing here is : since usage of napt + dns_alg is transparent to the mobile ipv6 node, it will 'think' that it is communicating with a mobile ipv6 node only and tend to send it binding updates at regular intervals of time. the destination being an ipv4 node(mobile or otherwise) will not understand it and drop the bu packets. so what i suggest is that the BA (binding acknowledge) bit be always set when a v6 node sends binding updates.if no acknowledgement is received after a configurable number of attempts(e.g 3), the mobile node will assume one or more of the following 3 conditions must be true: 1)destination is a v4 node(mobile or otherwise) 2)destination is v6 but not mobility enabled or 3)network congestion so,the v6 node will,as a solution to any of the above mentioned cases, reroute it's packets through it's home agents for the remainder of the session. thanks anand thakur HCL Perot Systems p.s : thanks for your comments From owner-v6ops@ops.ietf.org Thu Nov 28 04:16:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23629 for ; Thu, 28 Nov 2002 04:16:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HKni-000NcI-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 01:17:38 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #2) id 18HKne-000Nc4-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 01:17:35 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAS9Gplp011736; Thu, 28 Nov 2002 10:16:52 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gAS9GiwW065154; Thu, 28 Nov 2002 10:16:45 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA52114 from ; Thu, 28 Nov 2002 10:16:41 +0100 Message-Id: <3DE5DEE3.10B63AFB@hursley.ibm.com> Date: Thu, 28 Nov 2002 10:16:19 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: itojun@iijlab.net Cc: v6ops@ops.ietf.org Subject: Re: on NAT-PT References: <20021128061346.B1F1F4B23@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think we need an RFC which discusses the issues with NAT-PT that are discussed for NAT-v4 in RFC 2993 and RFC 3027. Maybe it could be quite short, if the issues are the same, but it needs to be written. Brian itojun@iijlab.net wrote: > > > there are some concerns raised in the working group meeting > > with respect to NAT-PT. it seems to me that the concerns does not > > have enough technical ground (or there are some confusions in > > understanding how NAT-PT works). i don't see the need for revising > > NAT-PT at all. some clarifications on the document might be nice, > > but no major re-work is needed, IMHO. > > more comments on other drafts. > > i'm not really defending NAT-PT itself, actually i would like to see > less use of NAT-PT (i prefer dual stack approach). i just don't see > the technical ground for the voices like "NAT-PT is evil, need a > revised version". > > itojun > > draft-durand-natpt-dns-alg-issues-00.txt > 1.1 > > > RFC2766 is not clear on how a DNS-ALG should treat answers to A > > queries made by internal nodes. As a matter of fact, one could > > fear that a careless a DNS-ALG would also intercept them and translate > > them into a AAAA form. In other words, nodes asking for a A record > > could be returned a AAAA record. Although this may not be a problem > > for simple IPv6 only applications, it may be a concern for applications > > that 'walk through' the DNS structure and may pas information to peers. > > if you are an IPv6-only node and would like to communicate with IPv4- > only node within the same site, you will still want to use NAT-PT > translator, therefore it is okay for DNS-ALG to translate A responses > into AAAA responses. > > > Second, the application has no way of knowing that the returned AAAA > > address is actually not a real IPv6 one, but a IPv4 translated one. > > It may be led to believe that it's a real one and think "It's IPv6, > > so it has End to End IP connectivity, thus there will be no NAT in > > the middle and I can use any IPv6 specific options" > > This is the whole point of NAT - you want NAT box be invisible > from the NAT customers (in NAT-PT case, IPv6-only nodes). > if the NAT is visible to the NAT customer, it is more like RSIP. > > 1.2 > > > => The communication between a node within the NAT-PT domain and a > > external dual stack host will select the translated path over the > > native IPv6 path. > > It really depends on how your DNS-ALG treats dual stack FQDN. > As far as I understand, DNS-ALG won't perform address rewrite (from A > to AAAA) if an FQDN has both A and AAAA records. Therefore, the > point made in 1.2 looks moot. > > 1.3 > > > NAT-PT ALG makes the assumption that the DNS traffic goes through the > > NAT-PT box. > > > > This is OK is DNS resolution is done over IPv4. However, if it is > > done over IPv6, there is no reason why the DNS traffic will still go > > through the NAT-PT box unless the NAT-PT box is also the default IPv6 > > router of the site. > > not necessary. what NAT-PT really want are: > - the translated prefix (P::/96) used by DNS-ALG gets routed towards > NAT-PT translator box. > - NAT-PT translator box, as well as DNS-ALG be dual stack > there's no requirement at all for NAT-PT translator box, nor DNS-ALG > box, being a default router. > > i guess RFC2766 is a bit unclear about this point - you may want to > check RFC3142 for better documentation. > > 1.4 > > > Section 7.5 of RFC2766 says that NAT-PT is not deployable with DNS- > > sec. It would work if all the DNS resolution were done over IPv6, > > but in a mixed environment as described in draf-ietf-ngtrans-dns- > > ops-req-03.txt, this will be a problem. > > as written in the previous email meesage, why bother. > >> (5) - when you rely upon DNS responses created on the fly, as well as > >> a box that rewrites your data traffic, why this is a show-stopper? From owner-v6ops@ops.ietf.org Thu Nov 28 07:13:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26282 for ; Thu, 28 Nov 2002 07:13:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HNZP-0001YW-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 04:15:03 -0800 Received: from yue.hongo.wide.ad.jp ([203.178.139.94]) by psg.com with esmtp (Exim 3.36 #2) id 18HNZM-0001Y4-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 04:15:00 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian -4) with ESMTP id gASCFNGR000892; Thu, 28 Nov 2002 21:15:24 +0900 Date: Thu, 28 Nov 2002 21:15:23 +0900 (JST) Message-Id: <20021128.211523.66347844.yoshfuji@linux-ipv6.org> To: Stig.Venaas@uninett.no Cc: pekkas@netcore.fi, jeroen@unfix.org, gert@space.net, moore@cs.utk.edu, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20021128085235.A29940@sverresborg.uninett.no> References: <20021128.023740.07233604.yoshfuji@wide.ad.jp> <20021128085235.A29940@sverresborg.uninett.no> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In article <20021128085235.A29940@sverresborg.uninett.no> (at Thu, 28 Nov 2002 08:52:35 +0100), Stig Venaas says: > (except that it might take a while to establish a connection), but > you still have a problem that the IPv6 path might be poor. Each different "IP" performs differently from each other. I believe what you need is some (dynamic) server selection method. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From owner-v6ops@ops.ietf.org Thu Nov 28 08:02:43 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27159 for ; Thu, 28 Nov 2002 08:02:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HOLI-0002pO-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 05:04:32 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18HOLF-0002pC-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 05:04:29 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gASD1dj08288; Thu, 28 Nov 2002 08:01:41 -0500 (EST) Message-Id: <200211281301.gASD1dj08288@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: Stig.Venaas@uninett.no, pekkas@netcore.fi, jeroen@unfix.org, gert@space.net, moore@cs.utk.edu, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: getaddrinfo address ordering In-reply-to: (Your message of "Thu, 28 Nov 2002 21:15:23 +0900.") <20021128.211523.66347844.yoshfuji@linux-ipv6.org> Date: Thu, 28 Nov 2002 08:01:39 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > (except that it might take a while to establish a connection), but > > you still have a problem that the IPv6 path might be poor. > > Each different "IP" performs differently from each other. > I believe what you need is some (dynamic) server selection > method. I believe what is needed is to stop relying so much on applications/hosts choosing destination addresses. Hosts should have as few addresses as possible. The network should make a best effort to deliver the traffic to whatever address is used over the links permitted for such use. From owner-v6ops@ops.ietf.org Thu Nov 28 08:11:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27293 for ; Thu, 28 Nov 2002 08:11:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HOTX-00034P-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 05:13:03 -0800 Received: from node147c0.a2000.nl ([24.132.71.192] helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #2) id 18HOTU-00034C-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 05:13:01 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id gASDCoE18215; Thu, 28 Nov 2002 14:12:50 +0100 (CET) Date: Thu, 28 Nov 2002 14:12:50 +0100 From: Ronald van der Pol To: Joshua Graessley Cc: v6ops@ops.ietf.org Subject: Re: IPv6 transition architecture discussion Message-ID: <20021128131250.GB16983@rvdp.org> References: <9C422444DE99BC46B3AD3C6EAFC9711B03240C5B@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Nov 25, 2002 at 12:25:02 -0800, Joshua Graessley wrote: > We look to the IETF for a solution because we can't solve this problem > alone. I get the impression from this working group that the working > group is of the opinion that the transition mechanism will not work and > we should just sit on our thumbs until the ISPs provide us IPv6 > connectivity. I don't think you should sit on your thumbs. If you agree with the IETF and believe IPv6 is the way to go, you should do your part. Otherwise, everybody will wait for others. It would be good when OS and application vendors shipped some nice IPv6 applications that would create end user demand for IPv6. > Is there any evidence to suggest that IPv6 will some day make the move > from testbed to wide deployment? Yes, IPv6 is already widely deployed in research networks like WIDE, 6NET and Abilene. Remember how the IPv4 internet started? There are also many internet exchanges that support IPv6. The commercial ISPs will follow. Many have already got an IPv6 prefix from their RIR. rvdp From owner-v6ops@ops.ietf.org Thu Nov 28 08:42:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27815 for ; Thu, 28 Nov 2002 08:42:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HOwQ-0003ut-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 05:42:54 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18HOwN-0003u1-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 05:42:51 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 917E74B22; Thu, 28 Nov 2002 22:42:48 +0900 (JST) To: Ronald van der Pol Cc: Joshua Graessley , v6ops@ops.ietf.org In-reply-to: Ronald.vanderPol's message of Thu, 28 Nov 2002 14:12:50 +0100. <20021128131250.GB16983@rvdp.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 transition architecture discussion From: itojun@iijlab.net Date: Thu, 28 Nov 2002 22:42:48 +0900 Message-Id: <20021128134248.917E74B22@coconut.itojun.org> X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> Is there any evidence to suggest that IPv6 will some day make the move >> from testbed to wide deployment? >Yes, IPv6 is already widely deployed in research networks like WIDE, >6NET and Abilene. Remember how the IPv4 internet started? There are >also many internet exchanges that support IPv6. The commercial ISPs >will follow. Many have already got an IPv6 prefix from their RIR. IPv6 is not just in academia, also in commercial. for instance: - 5+ ISPs in japan, more than 1 in sweden, and some other ISPs offer commercial connectivity services - 25+ ISPs in japan offer experimental connectivity services - 50 IPv6 ASes are connected at NSPIXP6 (IPv6 IX in tokyo) - there are *at least* 1500 /48 sites in japan alone - at IIJ and WIDE we get lots of support calls/emails whenever there's any routing issues or whatever - that means, people depends on ipv6 network so it's a good sign. i understand there are multiple chicken-and-egg problems (and it's irritating), but i'm sure it will get solved. itojun From owner-v6ops@ops.ietf.org Thu Nov 28 08:55:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27931 for ; Thu, 28 Nov 2002 08:55:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HPAJ-0004Mo-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 05:57:15 -0800 Received: from node147c0.a2000.nl ([24.132.71.192] helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #2) id 18HPAH-0004Mb-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 05:57:14 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id gASDuj218463; Thu, 28 Nov 2002 14:56:46 +0100 (CET) Date: Thu, 28 Nov 2002 14:56:45 +0100 From: Ronald van der Pol To: Brian E Carpenter Cc: itojun@iijlab.net, v6ops@ops.ietf.org Subject: Re: on NAT-PT Message-ID: <20021128135645.GC16983@rvdp.org> References: <20021128061346.B1F1F4B23@coconut.itojun.org> <3DE5DEE3.10B63AFB@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DE5DEE3.10B63AFB@hursley.ibm.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Nov 28, 2002 at 10:16:19 +0100, Brian E Carpenter wrote: > I think we need an RFC which discusses the issues with NAT-PT > that are discussed for NAT-v4 in RFC 2993 and RFC 3027. > Maybe it could be quite short, if the issues are the same, > but it needs to be written. I think we should also descibe the specific issues of translating between address families. With dual stack hosts, there is the issue of getting a translated address when un-translated communication is possible. There is also the issue where to put these boxes (near the v4-only host, near the v6-only host or somewhere in between). And probably others. rvdp From owner-v6ops@ops.ietf.org Thu Nov 28 10:50:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29390 for ; Thu, 28 Nov 2002 10:50:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HQxg-0007id-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 07:52:20 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18HQxe-0007iL-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 07:52:18 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gASFpsK12561; Thu, 28 Nov 2002 17:51:55 +0200 Date: Thu, 28 Nov 2002 17:51:54 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: Ronald van der Pol , Joshua Graessley , Subject: Re: IPv6 transition architecture discussion In-Reply-To: <20021128134248.917E74B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 28 Nov 2002 itojun@iijlab.net wrote: > >> Is there any evidence to suggest that IPv6 will some day make the move > >> from testbed to wide deployment? > >Yes, IPv6 is already widely deployed in research networks like WIDE, > >6NET and Abilene. Remember how the IPv4 internet started? There are > >also many internet exchanges that support IPv6. The commercial ISPs > >will follow. Many have already got an IPv6 prefix from their RIR. > > IPv6 is not just in academia, also in commercial. for instance: > - 5+ ISPs in japan, more than 1 in sweden, and some other ISPs > offer commercial connectivity services > - 25+ ISPs in japan offer experimental connectivity services > - 50 IPv6 ASes are connected at NSPIXP6 (IPv6 IX in tokyo) > - there are *at least* 1500 /48 sites in japan alone > - at IIJ and WIDE we get lots of support calls/emails whenever there's > any routing issues or whatever - that means, people depends on > ipv6 network My take is that you really can't get reliably-ish v6 outside of Far East areas (excluding some regions with e.g. acedemic networks and some single companies). That's not enough as lots of traffic does not go inside these regions. The point of no return is when _global_ v6 works, not just within (isolated) islands + some points of interconnections. > so it's a good sign. i understand there are multiple chicken-and-egg > problems (and it's irritating), but i'm sure it will get solved. Do you consider AAAA records tried first (in some regions like US/Europe) a problem that needs solving? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 28 11:03:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29525 for ; Thu, 28 Nov 2002 11:03:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HRBG-0008FM-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 08:06:22 -0800 Received: from node147c0.a2000.nl ([24.132.71.192] helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #2) id 18HRBD-0008F8-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 08:06:20 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id gASG62i19130; Thu, 28 Nov 2002 17:06:02 +0100 (CET) Date: Thu, 28 Nov 2002 17:06:02 +0100 From: Ronald van der Pol To: Pekka Savola Cc: itojun@iijlab.net, Ronald van der Pol , Joshua Graessley , v6ops@ops.ietf.org Subject: Re: IPv6 transition architecture discussion Message-ID: <20021128160602.GI16983@rvdp.org> References: <20021128134248.917E74B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Nov 28, 2002 at 17:51:54 +0200, Pekka Savola wrote: > Do you consider AAAA records tried first (in some regions like US/Europe) > a problem that needs solving? No, because it is not a problem. The problem is bad routing. We should fix that. As was pointed out earlier, when you have several A records, one of them might be unreachable too by bad (v4) routing. rvdp From owner-v6ops@ops.ietf.org Thu Nov 28 11:08:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29582 for ; Thu, 28 Nov 2002 11:08:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HRG5-0008Qb-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 08:11:21 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18HRG3-0008QO-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 08:11:19 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gASGB3712721; Thu, 28 Nov 2002 18:11:03 +0200 Date: Thu, 28 Nov 2002 18:11:03 +0200 (EET) From: Pekka Savola To: Ronald van der Pol cc: itojun@iijlab.net, Joshua Graessley , Subject: Re: IPv6 transition architecture discussion In-Reply-To: <20021128160602.GI16983@rvdp.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 28 Nov 2002, Ronald van der Pol wrote: > On Thu, Nov 28, 2002 at 17:51:54 +0200, Pekka Savola wrote: > > > Do you consider AAAA records tried first (in some regions like US/Europe) > > a problem that needs solving? > > No, because it is not a problem. The problem is bad routing. We should > fix that. _Can_ we fix that in some reasonable time? I'm not so sure.. If we fix most of the IPv6 routing problems (doubtful) in 1-2 years, people can start start placing AAAA records in their main DNS zones in 2-4 years. Is that enough? > As was pointed out earlier, when you have several A records, > one of them might be unreachable too by bad (v4) routing. So? Bad IPv6 routing happens all the time, for about every non-local destination. Bad IPv4 routing almost never happens. They aren't comparable. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 28 11:27:39 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29873 for ; Thu, 28 Nov 2002 11:27:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HRYE-00094O-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 08:30:06 -0800 Received: from yue.hongo.wide.ad.jp ([203.178.139.94]) by psg.com with esmtp (Exim 3.36 #2) id 18HRYC-000944-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 08:30:04 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.12.3+3.5Wbeta/8.12.3/Debian -4) with ESMTP id gASGUSGR001936; Fri, 29 Nov 2002 01:30:28 +0900 Date: Fri, 29 Nov 2002 01:30:28 +0900 (JST) Message-Id: <20021129.013028.45032056.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: Ronald.vanderPol@rvdp.org, itojun@iijlab.net, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: IPv6 transition architecture discussion From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20021128160602.GI16983@rvdp.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In article (at Thu, 28 Nov 2002 18:11:03 +0200 (EET)), Pekka Savola says: > So? Bad IPv6 routing happens all the time, for about every non-local > destination. Bad IPv4 routing almost never happens. They aren't > comparable. IPv6 routing is as stable as IPv4 routing. Or, they're comparable at least. What is "Bad routing," BTW? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From owner-v6ops@ops.ietf.org Thu Nov 28 12:02:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00453 for ; Thu, 28 Nov 2002 12:02:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HS5c-000AEq-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 09:04:36 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18HS5a-000AEc-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 09:04:34 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gASGw5j09785; Thu, 28 Nov 2002 11:58:06 -0500 (EST) Message-Id: <200211281658.gASGw5j09785@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ronald van der Pol cc: Pekka Savola , itojun@iijlab.net, Joshua Graessley , v6ops@ops.ietf.org Subject: Re: IPv6 transition architecture discussion In-reply-to: (Your message of "Thu, 28 Nov 2002 17:06:02 +0100.") <20021128160602.GI16983@rvdp.org> Date: Thu, 28 Nov 2002 11:58:05 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > Do you consider AAAA records tried first (in some regions like US/Europe) > > a problem that needs solving? > > No, because it is not a problem. The problem is bad routing. I guess I disagree. Yes, the problem is bad routing. No, it's not reasonable to assume that routing for v6 can be as good as or better than routing for v4 - at least not for many years. From owner-v6ops@ops.ietf.org Thu Nov 28 12:03:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00518 for ; Thu, 28 Nov 2002 12:03:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HS7L-000AKa-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 09:06:23 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18HS7J-000AKN-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 09:06:21 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gASGxtj09839; Thu, 28 Nov 2002 11:59:55 -0500 (EST) Message-Id: <200211281659.gASGxtj09839@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: itojun@iijlab.net, Ronald van der Pol , Joshua Graessley , v6ops@ops.ietf.org Subject: Re: IPv6 transition architecture discussion In-reply-to: (Your message of "Thu, 28 Nov 2002 17:51:54 +0200.") Date: Thu, 28 Nov 2002 11:59:55 -0500 X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > My take is that you really can't get reliably-ish v6 outside of Far East > areas (excluding some regions with e.g. acedemic networks and some single > companies). > > That's not enough as lots of traffic does not go inside these regions. I suspect we'll see 6to4 being used more often in regions where you can't (yet) get reliable v6. The problem then becomes how to get better interoperation between 6to4 and native v6. From owner-v6ops@ops.ietf.org Thu Nov 28 12:05:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00634 for ; Thu, 28 Nov 2002 12:05:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HS8p-000AOd-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 09:07:55 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18HS8m-000ANz-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 09:07:52 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gASH7XK13162; Thu, 28 Nov 2002 19:07:33 +0200 Date: Thu, 28 Nov 2002 19:07:33 +0200 (EET) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: Ronald.vanderPol@rvdp.org, , , Subject: Re: IPv6 transition architecture discussion In-Reply-To: <20021129.013028.45032056.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 29 Nov 2002, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In article (at Thu, 28 Nov 2002 18:11:03 +0200 (EET)), Pekka Savola says: > > > So? Bad IPv6 routing happens all the time, for about every non-local > > destination. Bad IPv4 routing almost never happens. They aren't > > comparable. > > IPv6 routing is as stable as IPv4 routing. > Or, they're comparable at least. Perhaps in some restricted scope (it certainly is in our network and my home network in Finland), but not globally. > What is "Bad routing," BTW? draft-savola-v6ops-6bone-mess-01.txt -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 28 12:39:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01149 for ; Thu, 28 Nov 2002 12:39:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HSfU-000Bms-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 09:41:40 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18HSfR-000Bmf-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 09:41:38 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gASHepm13502; Thu, 28 Nov 2002 19:40:51 +0200 Date: Thu, 28 Nov 2002 19:40:51 +0200 (EET) From: Pekka Savola To: Keith Moore cc: itojun@iijlab.net, Ronald van der Pol , Joshua Graessley , Subject: Re: IPv6 transition architecture discussion In-Reply-To: <200211281659.gASGxtj09839@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_03_05,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 28 Nov 2002, Keith Moore wrote: > > My take is that you really can't get reliably-ish v6 outside of Far East > > areas (excluding some regions with e.g. acedemic networks and some single > > companies). > > > > That's not enough as lots of traffic does not go inside these regions. > > I suspect we'll see 6to4 being used more often in regions where you can't > (yet) get reliable v6. The problem then becomes how to get better > interoperation between 6to4 and native v6. Well, this has a few problems. If there is no good v6 support, it's very likely that the closest 6to4 relay is also far away, thus causing extra RTT and instability. And in many areas you _do_ get v6 -- via a tunnel or whatever -- and it seems to be preferred to 6to4 (I'd agree, but only to a degree). So a rule of thumb "bad ipv6 connectivity or none at all -- use 6to4" doesn't probably hold. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Nov 28 12:42:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01245 for ; Thu, 28 Nov 2002 12:42:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HSif-000Bv3-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 09:44:57 -0800 Received: from moebius2.space.net ([195.30.1.100] ident=qmailr) by psg.com with smtp (Exim 3.36 #2) id 18HSid-000Bu9-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 09:44:55 -0800 Received: (qmail 28277 invoked by uid 1007); 28 Nov 2002 17:44:53 -0000 Date: Thu, 28 Nov 2002 18:44:53 +0100 From: Gert Doering To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@?\(B" Cc: pekkas@netcore.fi, Ronald.vanderPol@rvdp.org, itojun@iijlab.net, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: IPv6 transition architecture discussion Message-ID: <20021128184453.F15927@Space.Net> References: <20021128160602.GI16983@rvdp.org> <20021129.013028.45032056.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021129.013028.45032056.yoshfuji@linux-ipv6.org>; from yoshfuji@linux-ipv6.org on Fri, Nov 29, 2002 at 01:30:28AM +0900 X-NCC-RegID: de.space X-Spam-Status: No, hits=-4.3 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, Nov 29, 2002 at 01:30:28AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote: > IPv6 routing is as stable as IPv4 routing. > Or, they're comparable at least. Maybe in the APNIC region. In the RIPE and ARIN region, IPv6 routing is very much worse due to lots of "bad tunnels", ASes without proper equipment giving full transit to everybody else, and so on. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 50279 (49875) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Thu Nov 28 13:11:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01788 for ; Thu, 28 Nov 2002 13:11:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HTAK-000DBh-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 10:13:32 -0800 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #2) id 18HTAI-000DBV-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 10:13:30 -0800 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gASI70j10257; Thu, 28 Nov 2002 13:07:00 -0500 (EST) Message-Id: <200211281807.gASI70j10257@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: Keith Moore , itojun@iijlab.net, Ronald van der Pol , Joshua Graessley , v6ops@ops.ietf.org Subject: Re: IPv6 transition architecture discussion In-reply-to: (Your message of "Thu, 28 Nov 2002 19:40:51 +0200.") Date: Thu, 28 Nov 2002 13:07:00 -0500 X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > I suspect we'll see 6to4 being used more often in regions where you can't > > (yet) get reliable v6. The problem then becomes how to get better > > interoperation between 6to4 and native v6. > > Well, this has a few problems. > > If there is no good v6 support, it's very likely that the closest 6to4 > relay is also far away, thus causing extra RTT and instability. depends on how well the relays are connected. but yes, part of the key to making 6to4<->native work better seems to be getting more relays deployed. either that or arranging for more tunnel endpoints. is the latter easier than the former? Keith From owner-v6ops@ops.ietf.org Thu Nov 28 18:00:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06040 for ; Thu, 28 Nov 2002 18:00:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18HXfU-000Ppa-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 15:02:00 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18HXfO-000PpD-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 15:01:54 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 7AABB4B22; Fri, 29 Nov 2002 08:01:52 +0900 (JST) To: Pekka Savola Cc: Ronald van der Pol , Joshua Graessley , v6ops@ops.ietf.org In-reply-to: pekkas's message of Thu, 28 Nov 2002 17:51:54 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 transition architecture discussion From: itojun@iijlab.net Date: Fri, 29 Nov 2002 08:01:52 +0900 Message-Id: <20021128230152.7AABB4B22@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >Do you consider AAAA records tried first (in some regions like US/Europe) >a problem that needs solving? not at all. and if your implementation supports default-addr-select policy table, you can tweak it (so the problem is fixed already). itojun From owner-v6ops@ops.ietf.org Fri Nov 29 01:56:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13154 for ; Fri, 29 Nov 2002 01:56:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Hf5q-000OTJ-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 22:57:42 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18Hf5o-000OT6-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 22:57:40 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0FF9F4B22; Fri, 29 Nov 2002 15:57:36 +0900 (JST) To: "Thakur, Anand" Cc: "V6ops (E-mail)" , srisuresh@yahoo.com In-reply-to: Anand.Thakur's message of Fri, 29 Nov 2002 12:31:51 +0530. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Fri, 29 Nov 2002 15:57:36 +0900 Message-Id: <20021129065736.0FF9F4B22@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >has any way been found as yet to accomplish end to end ipsec with nat.if >not, will this require a modification in the way ipsec ah and ipsec esp >works or will nat-pt will have to be revised alltogether (which i don't >think is a very good proposition)? i think an urgent solution to this is >required if nat/napt-pt is to be used at a larger scale. ipsec does not work over NAT. period. (there are efforts in ipsec wg, but...) itojun From owner-v6ops@ops.ietf.org Fri Nov 29 01:56:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13168 for ; Fri, 29 Nov 2002 01:56:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Hf4K-000OLD-00 for v6ops-data@psg.com; Thu, 28 Nov 2002 22:56:08 -0800 Received: from [203.200.72.56] (helo=hpsexgw03.hpsglobal.com) by psg.com with esmtp (Exim 3.36 #2) id 18Hf4H-000OJD-00 for v6ops@ops.ietf.org; Thu, 28 Nov 2002 22:56:05 -0800 Received: by HPSEXGW03 with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Nov 2002 12:25:57 +0530 Message-ID: From: "Thakur, Anand" To: itojun@iijlab.net Cc: "V6ops (E-mail)" , srisuresh@yahoo.com Subject: RE: on NAT-PT Date: Fri, 29 Nov 2002 12:31:51 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk has any way been found as yet to accomplish end to end ipsec with nat.if not, will this require a modification in the way ipsec ah and ipsec esp works or will nat-pt will have to be revised alltogether (which i don't think is a very good proposition)? i think an urgent solution to this is required if nat/napt-pt is to be used at a larger scale. regards anand > -----Original Message----- > From: itojun@iijlab.net [SMTP:itojun@iijlab.net] > Sent: Thursday, November 28, 2002 11:44 AM > To: v6ops@ops.ietf.org > Subject: Re: on NAT-PT > > > there are some concerns raised in the working group meeting > > with respect to NAT-PT. it seems to me that the concerns does not > > have enough technical ground (or there are some confusions in > > understanding how NAT-PT works). i don't see the need for revising > > NAT-PT at all. some clarifications on the document might be nice, > > but no major re-work is needed, IMHO. > > more comments on other drafts. > > i'm not really defending NAT-PT itself, actually i would like to see > less use of NAT-PT (i prefer dual stack approach). i just don't > see > the technical ground for the voices like "NAT-PT is evil, need a > revised version". > > itojun > > > draft-durand-natpt-dns-alg-issues-00.txt > 1.1 > > > RFC2766 is not clear on how a DNS-ALG should treat answers to A > > queries made by internal nodes. As a matter of fact, one could > > fear that a careless a DNS-ALG would also intercept them and translate > > them into a AAAA form. In other words, nodes asking for a A record > > could be returned a AAAA record. Although this may not be a problem > > for simple IPv6 only applications, it may be a concern for > applications > > that 'walk through' the DNS structure and may pas information to > peers. > > if you are an IPv6-only node and would like to communicate with > IPv4- > only node within the same site, you will still want to use NAT-PT > translator, therefore it is okay for DNS-ALG to translate A > responses > into AAAA responses. > > > Second, the application has no way of knowing that the returned AAAA > > address is actually not a real IPv6 one, but a IPv4 translated one. > > It may be led to believe that it's a real one and think "It's IPv6, > > so it has End to End IP connectivity, thus there will be no NAT in > > the middle and I can use any IPv6 specific options" > > This is the whole point of NAT - you want NAT box be invisible > from the NAT customers (in NAT-PT case, IPv6-only nodes). > if the NAT is visible to the NAT customer, it is more like RSIP. > > 1.2 > > > => The communication between a node within the NAT-PT domain and a > > external dual stack host will select the translated path over the > > native IPv6 path. > > It really depends on how your DNS-ALG treats dual stack FQDN. > As far as I understand, DNS-ALG won't perform address rewrite (from > A > to AAAA) if an FQDN has both A and AAAA records. Therefore, the > point made in 1.2 looks moot. > > 1.3 > > > NAT-PT ALG makes the assumption that the DNS traffic goes through the > > NAT-PT box. > > > > This is OK is DNS resolution is done over IPv4. However, if it is > > done over IPv6, there is no reason why the DNS traffic will still go > > through the NAT-PT box unless the NAT-PT box is also the default IPv6 > > router of the site. > > not necessary. what NAT-PT really want are: > - the translated prefix (P::/96) used by DNS-ALG gets routed towards > NAT-PT translator box. > - NAT-PT translator box, as well as DNS-ALG be dual stack > there's no requirement at all for NAT-PT translator box, nor DNS-ALG > box, being a default router. > > i guess RFC2766 is a bit unclear about this point - you may want to > check RFC3142 for better documentation. > > 1.4 > > > Section 7.5 of RFC2766 says that NAT-PT is not deployable with DNS- > > sec. It would work if all the DNS resolution were done over IPv6, > > but in a mixed environment as described in draf-ietf-ngtrans-dns- > > ops-req-03.txt, this will be a problem. > > as written in the previous email meesage, why bother. > >> (5) - when you rely upon DNS responses created on the fly, as well > as > >> a box that rewrites your data traffic, why this is a show-stopper? From owner-v6ops@ops.ietf.org Sat Nov 30 17:20:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13684 for ; Sat, 30 Nov 2002 17:20:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IFx2-0007HW-00 for v6ops-data@psg.com; Sat, 30 Nov 2002 14:19:04 -0800 Received: from nat-63-99-114-2.tahoenetworks.com ([63.99.114.2] helo=TNEXVS01.tahoenetworks.com) by psg.com with esmtp (Exim 3.36 #2) id 18IFwz-0007HK-00 for v6ops@ops.ietf.org; Sat, 30 Nov 2002 14:19:01 -0800 Received: from adithya ([10.8.2.217]) by TNEXVS01.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Sat, 30 Nov 2002 14:18:59 -0800 Message-ID: <006301c298bf$777f4480$d902080a@tahoenetworks.com> From: "Mohan Parthasarathy" To: "Thakur, Anand" , Cc: "V6ops \(E-mail\)" , References: <20021129065736.0FF9F4B22@coconut.itojun.org> Subject: Re: on NAT-PT Date: Sat, 30 Nov 2002 14:26:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 30 Nov 2002 22:18:59.0567 (UTC) FILETIME=[7B104FF0:01C298BE] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >has any way been found as yet to accomplish end to end ipsec with nat.if > >not, will this require a modification in the way ipsec ah and ipsec esp > >works or will nat-pt will have to be revised alltogether (which i don't > >think is a very good proposition)? i think an urgent solution to this is > >required if nat/napt-pt is to be used at a larger scale. > > ipsec does not work over NAT. period. > (there are efforts in ipsec wg, but...) > Some of the routers supports IPsec pass through mode and works fine (at least with my limited experience) with ESP tunnel mode. As far as i can tell no one cares about AH. IPsec pass through mode seems to work fine for home scenarios (my PC behind the NAT establishing a IPsec ESP tunnel to the corporate). Its limitations might prevent its use in large scale though. -mohan -mohan > itojun > >