From ietfc@btconnect.com Tue Mar 1 04:13:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E063A67DB for ; Tue, 1 Mar 2011 04:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYIhyCPfJEC8 for ; Tue, 1 Mar 2011 04:13:14 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id 534913A67CC for ; Tue, 1 Mar 2011 04:13:13 -0800 (PST) Received: from host86-141-16-12.range86-141.btcentralplus.com (HELO pc6) ([86.141.16.12]) by c2beaomr10.btconnect.com with SMTP id BWG31843; Tue, 01 Mar 2011 12:14:13 +0000 (GMT) Message-ID: <00e601cbd801$2cebaa00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Fred Baker" References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com><056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.com> <4D6C000B.1090704@bogus.com><056B511A55F8AA42A3E492B7DD19A3193C19A8@008-AM1MPN1-015.mgdnok.nokia.com> <00DFEA69-DD43-49C0-A012-360BDCB41171@cisco.com> Date: Tue, 1 Mar 2011 12:09:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4D6CE315.00E0, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4D6CE316.01C8,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 12:13:15 -0000 ----- Original Message ----- From: "Fred Baker" To: "savolainen teemu" ; "Randy Bush" Sent: Monday, February 28, 2011 10:02 PM > On Feb 28, 2011, at 12:19 PM, wrote: > > > For what I know multihoming is very commonly used to describe a scenario where a host has simultaneously multiple uplink ISP connections active. > > There are 185 RFCs and I-don't-know-how-many Internet Drafts (that may or may not ever become RFCs) that discuss multihoming. And five IENs. > > The oldest use of the term I could find is in IEN 110, dated 1979. It uses the term without definition (it must have been in the air at the time), but states that > > 3. Hosts which are deliberately multihomed on distinct networks > should be able to recover from interface failures, but by mechanisms > above the TCP/internet layer, not within them. > > So, clearly the expectation there was that "multihomed" implied "[multiple] distinct networks" and the ability for a host to recover from failures. > > IEN 178 has a section with that title. It's introductory comment is that > > A subscriber may want to have multiple connections to a > communication system for reliability or performance reasons. > > It goes on to describe having multiple addresses, the ability to use any of them, and the ability to optimize its use of them, among other things. > > The first definition I find that can be described as a "definition" is in RFC 1122; RFC 1123 continues the discussion. Fred Prior to RFC1122, I find a definition of multi-homing in RFC791, which is what I usually use as a reference. Tom Petch > A host is generally said to be multihomed if it has more than > one interface to the same or to different networks. See > Section 1.1.3 on "Terminology". > > And by the way has a second 3.3.4 on "local multihoming". Since RFC 1122 is "host" requirements, it doesn't discuss the multihoming of a network. What it addresses (no pun intended) is a host that is part of two or more subnets, whether that means two or more interfaces or one interface with multiple subnets. > > RFC 1127, which is Bob Braden's "Perspective on the Host Requirements RFCs", goes on to discuss "AS Multihoming", which he defines as > > multihomed AS: an AS that has more than one connection to other ASs, > but refuses to carry transit traffic. > > > > > Bringing this back to the draft in question, my understanding is that the authors are working from the model in which: > > a) a residential/SOHO/other-edge-network has multiple upstreams > b) said network has at least one CPE > c) the multiple upstreams provide a prefix each > d) as a result, the residential/SOHO/other-edge-network has multiple prefixes overlaid in it. > > Every host, by RFC 1122's definition, is multihomed (it has more than one subnet, regardless of physical connectivity), and the network is multihomed (it has more than one upstream. > > > Did I miss something? Randy's description of multihomed networks he runes is perfectly accurate. But BGP is not a requirement for multihoming; what is a requirement is "multiple addresses" or "multiple upstreams". > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From simon.perreault@viagenie.ca Tue Mar 1 04:37:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279673A67EF for ; Tue, 1 Mar 2011 04:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIQ-ruxYJfCV for ; Tue, 1 Mar 2011 04:37:22 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 0B2903A67D8 for ; Tue, 1 Mar 2011 04:37:22 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B595121BBC; Tue, 1 Mar 2011 07:38:23 -0500 (EST) Message-ID: <4D6CE8BF.3050507@viagenie.ca> Date: Tue, 01 Mar 2011 07:38:23 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Andrew Yourtchenko , Dan Wing X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: [v6ops] Open-Source Happy Eyeballs Implementation in Erlang X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 12:37:24 -0000 Hi, I made an implementation of Happy Eyeballs in Erlang. This programming language makes it very easy to express asynchronous algorithms. Total lines of code are less than 100. So I think it is perfect for early-stage experimentation and tweaking algorithms. Maybe it could even be considered the "reference" implementation, or included in an appendix since it is so short. Full announcement: http://www.viagenie.ca/news/index.html#happy_eyeballs_erlang Code: http://www.viagenie.ca/ipv6/he-0.1.tar.gz See the README file for instructions. Doing this, I found two bugs with the spec: Bug #1: An application-wide P value is a broken idea. Today, most servers are IPv4-only. This means that as we establish connections and IPv4 "wins", P will decrease to the minimum value. This will cause IPv6 to not win when attempting a connection to a dual-stack server. In the future, when the situation is reversed and IPv6 is prevalent, P will tend to increase to the maximum value, and IPv4 will almost never be used. Some would consider this a good thing, but it effectively makes happy eyeballs useless. I thought that we could simply not update P when connecting to a single-stack server. But it turns out that we don't know if a server is single- or dual-stack when we just go with the first attempt without even having started resolving for the other address family. So I suggest removing the application-wide P value. Relying only on per-destination P values along with a reasonable default (e.g. favour IPv6 by 100m) works just fine. Bug #2: When resolution fails for an address family, we should start resolving for the other address family right away. E.g. if we favour IPv6 by 100ms and we receive an empty answer section within 20ms, there's no point waiting another 80ms before resolving for IPv4. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From scott.brim@gmail.com Tue Mar 1 05:26:29 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE883A68D3 for ; Tue, 1 Mar 2011 05:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb7LCM1KVpkj for ; Tue, 1 Mar 2011 05:26:28 -0800 (PST) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by core3.amsl.com (Postfix) with ESMTP id 651F23A68CF for ; Tue, 1 Mar 2011 05:26:28 -0800 (PST) Received: by gwj22 with SMTP id 22so2627983gwj.27 for ; Tue, 01 Mar 2011 05:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tqb62AdW1iIZPWeGXhXqYj3eIC/ffc+maCdR1B4Uens=; b=gjN1FveHHEEvKHXuQVpeH+Rf6aqU2voQXoNLIw5HdoFRXQms3vnbNa8YcWMcXKddrN UHR6xJq3knUavnbq0nuodjVTHdgLjcBkEg7cbn2LxTmiV4o12jnSjGEDV5RoNlzvnYsD qGpREDf9QBlWY0NIi0idwJmYoXLJA/OvkLdKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=km5W8sIOwd+ohMa8AbYkFORCNKPrQIxzFGoDPN70gJEJBXoPwTcjNxPyZAZIDVtgdZ gn9zdWgpKmDGWrXRVE58DBgi0D/O1PvVeGTBMVoz0tSMq2YXxcor6jW/8CZHNB5kyjRs by0cJp5lG9Wsjtk7nSQcP/ozqZAFp61TDkIxE= MIME-Version: 1.0 Received: by 10.90.232.6 with SMTP id e6mr9279216agh.52.1298986051177; Tue, 01 Mar 2011 05:27:31 -0800 (PST) Received: by 10.90.40.25 with HTTP; Tue, 1 Mar 2011 05:27:31 -0800 (PST) In-Reply-To: <4D6CE8BF.3050507@viagenie.ca> References: <4D6CE8BF.3050507@viagenie.ca> Date: Tue, 1 Mar 2011 08:27:31 -0500 Message-ID: From: Scott W Brim To: Simon Perreault Content-Type: multipart/alternative; boundary=001636284f60260c78049d6bc21d Cc: IPv6 Ops WG , Andrew Yourtchenko Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in Erlang X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 13:26:29 -0000 --001636284f60260c78049d6bc21d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 1, 2011 at 07:38, Simon Perreault wrote: > Bug #1: An application-wide P value is a broken idea. Today, most > servers are IPv4-only. This means that as we establish connections and > IPv4 "wins", P will decrease to the minimum value. This will cause IPv6 > to not win when attempting a connection to a dual-stack server. > So I suggest removing the application-wide P value. Relying only on > per-destination P values along with a reasonable default (e.g. favour > IPv6 by 100m) works just fine. > In an environment with v4 and dual-stack, it is difficult to move aggressively to v6 ... but consider what an average user would do in that situation, without happy eyeballs: just use v4 for everything. Also, when v6 wins, the algorithm aggressively moves back toward zero (and then slowly out to favor v6). Finally, most users connect to a cacheable number of sites, so the destination-specific P value will dominate the app-specific one. So I see the draft as written as a conservative approach. You could, perhaps, add configuration to "seed" P values for specific destinations, or even prefixes, to favor v6 (but allowing the algorithm to adjust P over time). > Bug #2: When resolution fails for an address family, we should start > resolving for the other address family right away. E.g. if we favour > IPv6 by 100ms and we receive an empty answer section within 20ms, > there's no point waiting another 80ms before resolving for IPv4. > Good. Scott --001636284f60260c78049d6bc21d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 1, 2011 at 07:38, Simon Perreault <simon.perreault@viagenie.ca>= wrote:
Bug #1: An application-wide P value is a broken idea. Today, most
servers are IPv4-only. This means that as we establish connections and
IPv4 "wins", P will decrease to the minimum value. This will caus= e IPv6
to not win when attempting a connection to a dual-stack server.

So = I suggest removing the application-wide P value. Relying only on
per-destination P values along with a reasonable default (e.g. favour
IPv6 by 100m) works just fine.

In an enviro= nment with v4 and dual-stack, it is difficult to move aggressively to v6 ..= . but consider what an average user would do in that situation, without hap= py eyeballs: just use v4 for everything.=A0 Also, when v6 wins, the algorit= hm aggressively moves back toward zero (and then slowly out to favor v6).= =A0 Finally, most users connect to a cacheable number of sites, so the dest= ination-specific P value will dominate the app-specific one.=A0 So I see th= e draft as written as a conservative approach.=A0 You could, perhaps, add c= onfiguration to "seed" P values for specific destinations, or eve= n prefixes, to favor v6 (but allowing the algorithm to adjust P over time).=
=A0
Bug #2: When resolution fails for an address family, we should start
resolving for the other address family right away. E.g. if we favour
IPv6 by 100ms and we receive an empty answer section within 20ms,
there's no point waiting another 80ms before resolving for IPv4.

Good.

Scott
--001636284f60260c78049d6bc21d-- From simon.perreault@viagenie.ca Tue Mar 1 05:38:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97863A6D30 for ; Tue, 1 Mar 2011 05:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAfugc+b8wyM for ; Tue, 1 Mar 2011 05:38:21 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id B0AC93A7171 for ; Tue, 1 Mar 2011 05:37:47 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 76C6F20CC3; Tue, 1 Mar 2011 08:38:49 -0500 (EST) Message-ID: <4D6CF6E8.6090903@viagenie.ca> Date: Tue, 01 Mar 2011 08:38:48 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Scott W Brim References: <4D6CE8BF.3050507@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG , Andrew Yourtchenko Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in Erlang X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 13:38:23 -0000 On 2011-03-01 08:27, Scott W Brim wrote: > In an environment with v4 and dual-stack, it is difficult to move > aggressively to v6 ... but consider what an average user would do in > that situation, without happy eyeballs: just use v4 for everything. I'm not following you. In a dual-stack environment, most current apps prefer IPv6. If IPv6 times out, they try IPv4. > Also, when v6 wins, the algorithm aggressively moves back toward zero > (and then slowly out to favor v6). The point is that once P reaches "favour IPv4 by 4 seconds", IPv6 will *never* win unless when connecting to an IPv6-only server. That's not helping the transition to IPv6. > Finally, most users connect to a > cacheable number of sites, so the destination-specific P value will > dominate the app-specific one. That's true. But the app-specific one will inherit from the global one, and then it will continue the same behaviour: IPv4 will always win. Initially my implementation had a global P. I quickly saw that it does not work. IPv4 always wins. So practice agrees with theory. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From teemu.savolainen@nokia.com Tue Mar 1 05:42:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B663A67C1 for ; Tue, 1 Mar 2011 05:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1jNR7+fOXt8 for ; Tue, 1 Mar 2011 05:42:20 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id D6E613A67A1 for ; Tue, 1 Mar 2011 05:42:19 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p21Dh3BJ002305; Tue, 1 Mar 2011 15:43:14 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 15:43:07 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 1 Mar 2011 14:43:07 +0100 Received: from 008-AM1MPN1-015.mgdnok.nokia.com ([169.254.5.61]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Tue, 1 Mar 2011 14:43:06 +0100 From: To: , Thread-Topic: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC Thread-Index: AQHL15GStS6rDrKywUmdLQdNcrszg5QYej6A Date: Tue, 1 Mar 2011 13:43:06 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3193C207B@008-AM1MPN1-015.mgdnok.nokia.com> References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <4D6C18BE.2020606@gmail.com> In-Reply-To: <4D6C18BE.2020606@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.93.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2011 13:43:07.0382 (UTC) FILETIME=[98C07160:01CBD816] X-Nokia-AV: Clean Cc: v6ops@ietf.org, ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 13:42:21 -0000 Chairs, Brian, I thought we agreed there is no *the* model for IPv6 multihoming term, but = the term is overloaded with multiple meanings? Anyhow, many of the topics have been already discussed in MIF, e.g. multipl= e namespaces of DNS. Should we repeat the discussion here (for v6ops' educa= tion?)? Best regards, Teemu > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= ext > Brian E Carpenter > Sent: 28. helmikuuta 2011 23:51 > To: Fred Baker > Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica > Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC >=20 > Hi, >=20 > I think this draft still needs a lot of work. >=20 > First, quite a bit of rewriting is needed in the Introduction. >=20 > > Multihoming is a blanket term to describe a host or small network > > that is connected to more than one upstream network. >=20 > I suggest a reference to RFC 3582 here, where the IPv6 requirements > are listed. >=20 > > For example, a remote access user may use a VPN to > > simultaneously connect to a remote network and retain a default rout= e > > to the Internet for other purposes. >=20 > I don't think this is really a red herring. It's a very common scenario > but it does amount to MIF rather than multihoming, since the > VPN usually appears as a virtual interface. The draft should focus > on MH not on MIF, I think. >=20 > > In IPv4 a common solution to the multihoming problem is to employ > > NAPT... >=20 > Probably this should start by saying that RFC 4116 is the most common > method. It should be made clear that avoiding that method, with its > built-in scaling problem, is of equal importance to avoiding NAPT. >=20 > There should also be a discussion of NPTv6, which also avoids NAPT and > RFC 4116. Explain why the proposed approach is a better choice than NPT6. >=20 > There needs to be a clear statement that the underlying model is > that having multiple PA prefixes for a site is normal. (And once > you say that, you also need to explain why the proposed solution is > better than shim6, or how it will interact with shim6). >=20 > > 2. Terminology > ... > > NAT66 or IPv6 NAT The terms "NAT66" and "IPv6 NAT" refer to > > [I-D.mrw-nat66]. >=20 > That is plain wrong. Now I don't understand whether you are trying > to avoid NAPT66 (which is evil) or NPT6 (which is much less evil, and > is the actual topic of draft-mrw-nat66). This needs cleaning up > throughout the draft. >=20 > > 3.2. Multihomed network environment > > > > In an IPv6 multihomed network, a host is assigned two or more IPv6 > > addresses and DNS resolvers from independent service provider > > networks. >=20 > Here I have to agree with Randy - this is not *the* model for IPv6 MH, > it is only one model (which you define earlier as MHMP). >=20 > And why mention separate DNS resolvers? Since DNS is a single namespace, > you should get the same (multiple) AAAA records from any resolver. > If not, there's a bug in DNS. >=20 > > ...or use a DNS response from an incorrect > > service provider that may result in impaired IP connectivity. >=20 > No, no, no. Not unless you intend to recommend DNS cheating by > CDNs. Making DNS cheating work should never be an IETF goal. >=20 > > 4.3. DNS server selection >=20 > I am very worried by this section. I think this draft should focus > on routing issues; just assume that you get back all the AAAA records > for the target in random order, and go from there. >=20 > > 5. Requirements > > > > This section describes requirements that any solution multi-address > > and multi-uplink architectures need to meet. >=20 > I'm puzzled by this section. >=20 > 1. It seems to cover all kinds of solutions and not just the solution > proposed by this document. >=20 > 2. It should be much earlier in the document, right after the Introductio= n. >=20 > 3. It mixes MH and MIF issues. >=20 > 4. It needs to explain what is added or changed compared to RFC 3582. >=20 > > 6.3. DNS resolver selection >=20 > See above. I think this should be out of scope. >=20 > > 7.1. IPv6 NAT >=20 > Drop this except for a reference to NPT6. >=20 > > 7.2. Co-exisitence consideration >=20 > I think this is no use as it stands because of the last sentence: >=20 > > The implementation of identifying non-MHMP hosts and NAT policy is > > outside the scope of this document. >=20 > I think all you can say is that hosts that don't support MHMP MAY be > supported by NPT6 or shim6, and if they don't have either of those > they will not get the benefit of multihoming. That is today's > situation anyway, so you have done no harm. >=20 > > 8. Security Considerations > > > > This document does not define any new mechanisms. Each solution > > mechanisms should consider security risks independently. Security > > risks that occur as a result of combining solution mechanisms should > > be considered in another document. >=20 > Er, no. Those risks should be analysed right here in this document. >=20 > Also, refer to RFC 4218. Which of those threats apply, and are there > any new ones? >=20 > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ek@google.com Tue Mar 1 05:44:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC4C3A684B for ; Tue, 1 Mar 2011 05:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJP6hFMp8NKC for ; Tue, 1 Mar 2011 05:44:00 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 9AD7B3A6781 for ; Tue, 1 Mar 2011 05:43:44 -0800 (PST) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p21DilJh022857 for ; Tue, 1 Mar 2011 05:44:47 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298987087; bh=5Jv3y01epMZyrrQzobUFeXUoc2s=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=LV3M/XBw8V1jhunqvkxjQo08nfJdqyiTmbvbijexpiccGQgqyWX4DLcrX85mE5kwl mMTGSMNSA2dRgDlXbgMiA== Received: from qwd6 (qwd6.prod.google.com [10.241.193.198]) by kpbe12.cbf.corp.google.com with ESMTP id p21DijXo029165 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 1 Mar 2011 05:44:46 -0800 Received: by qwd6 with SMTP id 6so4309420qwd.21 for ; Tue, 01 Mar 2011 05:44:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kgpEsUHS3dSq9q+t4BzUJEFXgqRQHLW0QtZ7DT6HrKs=; b=XC7WIWDzmi2YvgcqcP7DiePnZA/ALl/ZQ2eBPqHbkv/IX6COubkx3U4G9b4iX3EbsQ hE3b/Xd8TldMDyrOEfoQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YQtgcOU+FOF1tC4Pqxn8sA+7bebyy7XPvEY7YaCj4Gnh1Oci+32Q5/zUQjjsBVe8tp HNgafSjXJuh5Bk5AyEbg== MIME-Version: 1.0 Received: by 10.229.188.21 with SMTP id cy21mr5395517qcb.16.1298987084912; Tue, 01 Mar 2011 05:44:44 -0800 (PST) Received: by 10.229.121.8 with HTTP; Tue, 1 Mar 2011 05:44:44 -0800 (PST) In-Reply-To: <4D6CF6E8.6090903@viagenie.ca> References: <4D6CE8BF.3050507@viagenie.ca> <4D6CF6E8.6090903@viagenie.ca> Date: Tue, 1 Mar 2011 22:44:44 +0900 Message-ID: From: Erik Kline To: Simon Perreault Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: Andrew Yourtchenko , IPv6 Ops WG , Scott W Brim Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in Erlang X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 13:44:03 -0000 On 1 March 2011 22:38, Simon Perreault wrote: > On 2011-03-01 08:27, Scott W Brim wrote: >> In an environment with v4 and dual-stack, it is difficult to move >> aggressively to v6 ... but consider what an average user would do in >> that situation, without happy eyeballs: just use v4 for everything. > > I'm not following you. In a dual-stack environment, most current apps > prefer IPv6. If IPv6 times out, they try IPv4. > >> Also, when v6 wins, the algorithm aggressively moves back toward zero >> (and then slowly out to favor v6). > > The point is that once P reaches "favour IPv4 by 4 seconds", IPv6 will > *never* win unless when connecting to an IPv6-only server. That's not > helping the transition to IPv6. So in a world where only a small percentage of the destinations even have AAAAs the application P value will be so heavily IPv4-dominant that the poor one off destinations that are dualstacked will never see IPv6 traffic? If I understand you correctly I agree, this would make IPv6 deployment nearly pointless. From ayourtch@cisco.com Tue Mar 1 05:44:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8A73A681B for ; Tue, 1 Mar 2011 05:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzUmwEetWTez for ; Tue, 1 Mar 2011 05:44:37 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 9E31C3A67A1 for ; Tue, 1 Mar 2011 05:44:36 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p21DYNJ4015478; Tue, 1 Mar 2011 14:34:23 +0100 (CET) Received: from sweet-brew-2.cisco.com (sweet-brew-2.cisco.com [144.254.10.203]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p21DYNSf024397; Tue, 1 Mar 2011 14:34:23 +0100 (CET) Date: Tue, 1 Mar 2011 14:34:23 +0100 (CET) From: Andrew Yourtchenko To: Simon Perreault In-Reply-To: <4D6CE8BF.3050507@viagenie.ca> Message-ID: References: <4D6CE8BF.3050507@viagenie.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG , Andrew Yourtchenko Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in Erlang X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 13:44:38 -0000 Hi Simon, thanks! This looks very cool! ('erl -make' dumps with "init terminating in do_boot" on two of my machines with ubuntu, so it looks like I've some environment problem - I'll try on a different box later tonight and try to hack on it a bit. Barring that, some comments below inline in just english) On Tue, 1 Mar 2011, Simon Perreault wrote: > Hi, > > I made an implementation of Happy Eyeballs in Erlang. This programming > language makes it very easy to express asynchronous algorithms. Total > lines of code are less than 100. So I think it is perfect for > early-stage experimentation and tweaking algorithms. Maybe it could even > be considered the "reference" implementation, or included in an appendix > since it is so short. > > Full announcement: > http://www.viagenie.ca/news/index.html#happy_eyeballs_erlang > > Code: > http://www.viagenie.ca/ipv6/he-0.1.tar.gz > > See the README file for instructions. > > > Doing this, I found two bugs with the spec: > > Bug #1: An application-wide P value is a broken idea. Today, most > servers are IPv4-only. This means that as we establish connections and > IPv4 "wins", P will decrease to the minimum value. This will cause IPv6 > to not win when attempting a connection to a dual-stack server. > > In the future, when the situation is reversed and IPv6 is prevalent, P > will tend to increase to the maximum value, and IPv4 will almost never > be used. Some would consider this a good thing, but it effectively makes > happy eyeballs useless. > > I thought that we could simply not update P when connecting to a > single-stack server. But it turns out that we don't know if a server is > single- or dual-stack when we just go with the first attempt without > even having started resolving for the other address family. > > So I suggest removing the application-wide P value. Relying only on > per-destination P values along with a reasonable default (e.g. favour > IPv6 by 100m) works just fine. What about this: if we did not even start the resolution for the other AF, and the first connection already finished - should kick off that the name resolution alone - and see if it succeeds before updating P ? (this would resolve the single-stack/dual-stack question - and then would avoid updating the P for single-stack hosts *or* broken DNS ?) > > > Bug #2: When resolution fails for an address family, we should start > resolving for the other address family right away. E.g. if we favour > IPv6 by 100ms and we receive an empty answer section within 20ms, > there's no point waiting another 80ms before resolving for IPv4. Agreed. And then if we were to go with the above logic and keep global P - we would not need to touch it *and* would fall back pretty quick too ? cheers, andrew > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From simon.perreault@viagenie.ca Tue Mar 1 05:44:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C46A3A688B for ; Tue, 1 Mar 2011 05:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqWSHZBI7ZyT for ; Tue, 1 Mar 2011 05:44:43 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 28EB63A689A for ; Tue, 1 Mar 2011 05:44:43 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 685EB21F3C; Tue, 1 Mar 2011 08:45:43 -0500 (EST) Message-ID: <4D6CF886.8040206@viagenie.ca> Date: Tue, 01 Mar 2011 08:45:42 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Erik Kline References: <4D6CE8BF.3050507@viagenie.ca> <4D6CF6E8.6090903@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Andrew Yourtchenko , IPv6 Ops WG , Scott W Brim Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in Erlang X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 13:44:45 -0000 On 2011-03-01 08:44, Erik Kline wrote: > So in a world where only a small percentage of the destinations even > have AAAAs the application P value will be so heavily IPv4-dominant > that the poor one off destinations that are dualstacked will never see > IPv6 traffic? If I understand you correctly I agree, this would make > IPv6 deployment nearly pointless. Yes, you got it exactly right. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Mar 1 05:52:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491E23A67B3 for ; Tue, 1 Mar 2011 05:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgl4FPURe6sT for ; Tue, 1 Mar 2011 05:52:55 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 76EE23A685D for ; Tue, 1 Mar 2011 05:52:54 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BB65321F23; Tue, 1 Mar 2011 08:53:56 -0500 (EST) Message-ID: <4D6CFA74.5040709@viagenie.ca> Date: Tue, 01 Mar 2011 08:53:56 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Andrew Yourtchenko References: <4D6CE8BF.3050507@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in Erlang X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 13:52:56 -0000 On 2011-03-01 08:34, Andrew Yourtchenko wrote: > thanks! This looks very cool! ('erl -make' dumps with "init terminating > in do_boot" on two of my machines with ubuntu, so it looks like I've > some environment problem - I'll try on a different box later tonight and > try to hack on it a bit. Yeah, I did not test on Ubuntu, but it definitely looks like something is odd with your environment. > What about this: if we did not even start the resolution for the other > AF, and the first connection already finished - should kick off that the > name resolution alone - and see if it succeeds before updating P ? (this > would resolve the single-stack/dual-stack question - and then would > avoid updating the P for single-stack hosts *or* broken DNS ?) Good idea. That's exactly the kind of experiment I want to make quickly feasible with an Erlang implementation! :) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Mar 1 05:58:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4C4F3A67A5 for ; Tue, 1 Mar 2011 05:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSEQ4gpVKN9R for ; Tue, 1 Mar 2011 05:58:22 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id A50673A685D for ; Tue, 1 Mar 2011 05:58:14 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E13C321F23; Tue, 1 Mar 2011 08:59:16 -0500 (EST) Message-ID: <4D6CFBB4.1030909@viagenie.ca> Date: Tue, 01 Mar 2011 08:59:16 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Andrew Yourtchenko References: <4D6CE8BF.3050507@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in Erlang X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 13:58:23 -0000 On 2011-03-01 08:34, Andrew Yourtchenko wrote: > ('erl -make' dumps with "init terminating in do_boot" on two of my > machines with ubuntu, so it looks like I've some environment problem Try this: sudo apt-get install erlang-tools Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ayourtch@cisco.com Tue Mar 1 06:01:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5813A67B3 for ; Tue, 1 Mar 2011 06:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MANGLED_YOUR=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk0mdmSeZ3AA for ; Tue, 1 Mar 2011 06:01:49 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 5310A3A67A5 for ; Tue, 1 Mar 2011 06:01:49 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p21E2pef018100; Tue, 1 Mar 2011 15:02:51 +0100 (CET) Received: from sweet-brew-2.cisco.com (sweet-brew-2.cisco.com [144.254.10.203]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p21E2lb6004816; Tue, 1 Mar 2011 15:02:47 +0100 (CET) Date: Tue, 1 Mar 2011 15:02:47 +0100 (CET) From: Andrew Yourtchenko To: Javier Ubillos In-Reply-To: <1298901184.2099.320.camel@dab> Message-ID: References: <1298643392.2045.137.camel@dab> <1298901184.2099.320.camel@dab> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, 'Rashmi' Subject: Re: [v6ops] Happy-eyeballs - P-value & behavior X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 14:01:50 -0000 Hi Javier, On Mon, 28 Feb 2011, Javier Ubillos wrote: > On Fri, 2011-02-25 at 18:35 +0100, Andrew Yourtchenko wrote: > *cut* >> >>> Also, if both connections fail, I suggest we reset P to 0. >> >> Seems like it won't be a big deal - but do you have more details on the >> motivation behind ? If both connections failed, that would say either about the >> very sketchy connectivity of the target, or possibly that the source has lost >> their connectivity on that interface. >> >> If the latter, then I think resetting would make sense under the assumption that >> we have a different attachment later. If that happens more often than either the >> target total unreachability or the 'spurious connectivity losses' (like, bad >> connectivity on wireless). > > Perhaps that's a more sensible approach. > If the hosts IPs change, reset P (we *might* have changed networks). Thinking of this more - if we converge aggressively and quickly enough, this might even be a smaller optimization. All will depend on how much code it is vs. how much is at stake to just let it "fix itself" vs. "restart". > >> >>> >>> Multiplying with -1, consider the scenario: >>> P is high, favouring IPv6 and delaying IPv4 connections. >>> If IPv4 still wins, it means that suddenly is significantly better than >>> IPv6 (it won dispite IPv6's headstart). >>> Shouldn't we multiply P by -1? >>> Does it matter if we start "flapping" between IPv4/6? >>> If it does matter, e.g. we want SSL, wouldn't a slow-flapping >>> ("normal"-P management) be just as bad? >> >> I think this would optimize the case where we switched a link - but deoptimize >> the case where we had a one-time blip in the connectivity ? > > After some closer consideration.. Yes, you'r right. > I commented on that in the mail to/from Simon Perreault. > So, as mentioned above, perhaps a better method to achieve what I'm > trying to get at is to detect local address changes. > >>> >>> >>> * Why should we keep a P-value at all? >>> >>> After a mail-exchange with Dan Wing, my conclusion is basically, to >>> avoid unnecessary SYN-spamming. Which makes sense to me, SYNs don't have >>> a back-off mechanism as an "ordinary" TCP flow has. However, using a >> >> I think not only SYN-spamming - but also accept()-spamming on the server side I think. >> >> Arguably from the capacity planning a host should be able to support 2x >> accept()-load - but if this is normal scenario, that seems like a bit of a >> waste. >> >> (This is a theoretical view 'in case everyone implemented this', obviously do >> not apply in the beginning) >> > > Correct me if I'm mistaken, but... > If the responder dosen't allocate the TCB until it recieves the ACK > (third handshake packet), then the implementation shouldn't consume much > resources until that point (protecting against SYN-floods). > And, the initiator, shouldn't be sending two ACKs, but rather one ACK > and one RST (as it has chosen a winning socket). You mean the syncookies, right ? I thought by default they are inactive - only kicking in when the host has a lot of incomplete connections ? (I would need to verify about the second accept - I do not remember how the server-side select loop behaves if the connection-in-progress gets terminated). > >>> P-value, where P is a delay to be introduced before trying the "other" >>> AF seems sub-optimal to me. >>> Perhaps some other congestion-control for SYNs is more appropriate? >>> A trivial algorithm _could_ be: >>> >>> | Always send a SYN for both IPv4 & IPv6 (be aggressive) >>> | If some SYN does _not_ receive a SYN-ACK begin >>> SYN-congestion-control >>> --> Select the best AF (v4 or v6) according to some criteria >>> | During time T, only use the best AF >>> |* When time T expires, test sending a SYN on the other AF, and see >>> if it gets through (multiple tests?) >>> | If the congestion is gone go to start (i.e resume an aggressive >>> approach) >>> | Else - reset T and resume the timid approach. >>> >>> The reason I'm suggesting a "default" aggressive approach, that I don't >>> think that SYN packets make out a noticeable large fraction of the total >>> amount of traffic. I've started some captures to compare our offices >>> ratio of tcp/tcp-syn packets (overall and for www traffic). >> >> While we're thinking radically different ideas: how about a "zebra retransmit". >> >> Start with your "favourite" AF, and if you need to retransmit - then send the >> SYN for a different AF. This way the amount of SYNs will always be exactly the >> same. If more than 50% of the time over a certain period you fallback - change >> your favourite protocol. >> >> This idea would get nuked by the purists, I suspect :-) > > Isn't the core problem that we don't want to start with AF_INET6 (our > favourite protocol) and have to wait for it to time-out before we switch > over to AF_INET? > Isn't it that which is what's causing service-providers to start use > whitelisting for their AAAA records? Sorry if I was unclear. The current problem looks roughly like this: 

|- 0sec        SYN(AF_INET6)
|
|- 2sec        SYN(AF_INET6)
|
|- 4sec        SYN(AF_INET6)
|
|- 8sec        SYN(AF_INET6)
|
...  lunch time ...
|
|- [a lot] sec SYN(AF_INET) 
|
v
time
What I suggested above is either: 
|- 0sec        SYN(AF_INET6)
|
|- 2sec        SYN(AF_INET)
|
|- 4sec        SYN(AF_INET6)
|
|- 8sec        SYN(AF_INET)
|
... no lunch! ...
|
|- [a lot] sec: does not matter. We tested both AFs quickly.
|
v
or: 
|- 0sec        SYN(AF_INET)
|
|- 2sec        SYN(AF_INET6)
|
|- 4sec        SYN(AF_INET) 
|
|- 8sec        SYN(AF_INET6)
|
... no lunch! ...
|
|- [a lot] sec: does not matter. We tested both AFs quickly.
|
v
So rate-wise we would send exactly the same # of packets. But it's very impure approach since the timings would depend on the connections from each other. > >>> >>> >>> * P-scope >>> Currently we're choosing the easy-way out, and keeping a system-wide P. >>> However, I'm assuming that a per-destination P is more relevant. Perhaps >>> even destination+service. I think destination+service is overkill. We >>> _want_ to re-use P and not have to re-init/test too many times. >>> We'll continue with a system wide P for now, but we'll likely go the >>> per-destination P, hopefully with some nice aggregation feature too. >> >> How is the PMTUD info stored ? I think that the connectivity >> characteristics may be related to the PMTUD. P might then sit nicely >> in one of the address families alongside with MSS ? > > I'm not sure I understand what you're getting at. > The name-based socket will keep a readable P value. We could allow an > interface which could access AF_INET6 data (such as PMTUD). > In the happy-eyeballs case, we could also make an interface to get the > MSS and have it point to the active socket (IPv4/v6). it was just a thought on a possible place to store the aggregated P values, together with whereever the cached MSS values are stored (if.) sorry I should have been clearer in the wording. cheers, andrew From ayourtch@cisco.com Tue Mar 1 06:43:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43B03A6821 for ; Tue, 1 Mar 2011 06:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftRCrNyGV3TK for ; Tue, 1 Mar 2011 06:43:04 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 4D6133A67E9 for ; Tue, 1 Mar 2011 06:43:02 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p21Ei4PK021843; Tue, 1 Mar 2011 15:44:04 +0100 (CET) Received: from sweet-brew-2.cisco.com (sweet-brew-2.cisco.com [144.254.10.203]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p21Ei4hJ009180; Tue, 1 Mar 2011 15:44:04 +0100 (CET) Date: Tue, 1 Mar 2011 15:44:04 +0100 (CET) From: Andrew Yourtchenko To: Simon Perreault In-Reply-To: <4D6CFBB4.1030909@viagenie.ca> Message-ID: References: <4D6CE8BF.3050507@viagenie.ca> <4D6CFBB4.1030909@viagenie.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in Erlang X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 14:43:05 -0000 On Tue, 1 Mar 2011, Simon Perreault wrote: > On 2011-03-01 08:34, Andrew Yourtchenko wrote: >> ('erl -make' dumps with "init terminating in do_boot" on two of my >> machines with ubuntu, so it looks like I've some environment problem > > Try this: > > sudo apt-get install erlang-tools That works, thanks a lot! Strange that it complained about max/2 not being there, so I had to roll in my own: --- a/he.erl +++ b/he.erl @@ -29,6 +29,13 @@ -module(he). -export([new/0, new/1, connect/3]). +% For some odd reason it complained about not having max/2. Here's my own. +max(X, Y) -> + if + X > Y -> X; + true -> Y + end. + % Constructs a Happy Eyeballs "instance" which holds state across connections. % This state consists of per-destination P values. The default P value is 10, % meaning that IPv6 is favoured by 100ms. Now it seems the erlang that the apt-get installs has the IPv6 support disabled ;-) $ erl -noinput -s he_test =ERROR REPORT==== 1-Mar-2011::15:25:03 === Error in process <0.35.0> with exit value: {{badmatch,{error,eafnosupport}},[{he,'-connect_loop/5-fun-1-',3}]} I wonder if the shot I found in http://forum.trapexit.org/viewtopic.php?p=43831&sid=e0e7e2a21acf53f391b43429de0df828 is somewhere close - and together with the missing max/2 it may point that R13B03 is too old for IPv6 tricks ? cheers, andrew > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > From simon.perreault@viagenie.ca Tue Mar 1 07:04:52 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2673C3A683D for ; Tue, 1 Mar 2011 07:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZR7lrowVK4S for ; Tue, 1 Mar 2011 07:04:51 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id C27623A681B for ; Tue, 1 Mar 2011 07:04:50 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EF56921F1B; Tue, 1 Mar 2011 10:05:51 -0500 (EST) Message-ID: <4D6D0B4F.2040308@viagenie.ca> Date: Tue, 01 Mar 2011 10:05:51 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Andrew Yourtchenko References: <4D6CE8BF.3050507@viagenie.ca> <4D6CFBB4.1030909@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in Erlang X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:04:52 -0000 On 2011-03-01 09:44, Andrew Yourtchenko wrote: > I wonder if the shot I found in > http://forum.trapexit.org/viewtopic.php?p=43831&sid=e0e7e2a21acf53f391b43429de0df828 > is somewhere close - and together with the missing max/2 it may point > that R13B03 is too old for IPv6 tricks ? Yuck! I tested on Fedora 14, which comes with R14B. Maybe the syntax is different. The release notes do contain some IPv6-related changes. *sigh* Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From fred@cisco.com Tue Mar 1 08:00:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564B93A6996 for ; Tue, 1 Mar 2011 08:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.231 X-Spam-Level: X-Spam-Status: No, score=-110.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6UhbnC9-fUM for ; Tue, 1 Mar 2011 08:00:40 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 102343A6946 for ; Tue, 1 Mar 2011 08:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=885; q=dns/txt; s=iport; t=1298995302; x=1300204902; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ELf/1y69hAT9/TgpnIjAJe1NVkwTCrdMGN99seq621Y=; b=e7fRLpyaFFZePk1YcwE1/NpIs1a5Zw5k4ITGu5wa1YyEiDYED0HbyLiP LqvMoSJhEtvsRP/nwtOyRYrd5htxqQ8d41tqMlCa/8Cj5G36r+fWH2siW gzJ7cNSKqvBsp7aZLfsyk1nUQY1IQ94+jO+EfCmQazsYMZ7P0JpjMAmOz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAqnbE2rRN+K/2dsb2JhbACmTHSgMZwxhWEEhRKHDQ X-IronPort-AV: E=Sophos;i="4.62,247,1297036800"; d="scan'208";a="272266417" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 01 Mar 2011 16:01:42 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p21G1gBr011607; Tue, 1 Mar 2011 16:01:42 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker X-Priority: 3 In-Reply-To: <00e601cbd801$2cebaa00$4001a8c0@gateway.2wire.net> Date: Tue, 1 Mar 2011 08:01:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0148392A-9BE8-411F-B464-10AC893B472D@cisco.com> References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com><056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.com> <4D6C000B.1090704@bogus.com><056B511A55F8AA42A3E492B7DD19A3193C19A8@008-AM1MPN1-015.mgdnok.nokia.com> <00DFEA69-DD43-49C0-A012-360BDCB41171@cisco.com> <00e601cbd801$2cebaa00$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 16:00:41 -0000 On Mar 1, 2011, at 3:09 AM, t.petch wrote: > Prior to RFC1122, I find a definition of multi-homing in RFC791, which = is what I > usually use as a reference. Care must be taken in mapping internet addresses to local net addresses; a single physical host must be able to act as if it were several distinct hosts to the extent of using several distinct internet addresses. Some hosts will also have several physical interfaces (multi-homing). Grep didn't find it because of the dash... I actually have a problem with that definition, though. Yes, a host can = act as if it were multiple; virtual hosts do that. But in MultiTCP and = shim6, the host behaves as if it has more than one address, and the = address is (correctly) understood to be a determiner of a route. I = understand what Jon was getting at, but I think it is too limiting.= From jav@sics.se Tue Mar 1 09:49:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A8E3A6A15 for ; Tue, 1 Mar 2011 09:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1nlSVkgjXzB for ; Tue, 1 Mar 2011 09:49:08 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 317FE3A68CC for ; Tue, 1 Mar 2011 09:49:08 -0800 (PST) Received: from [192.168.10.102] (h206n3-haes-a12.ias.bredband.telia.com [78.72.156.206]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 43C29400E0; Tue, 1 Mar 2011 18:50:10 +0100 (CET) From: Javier Ubillos To: IPv6 Ops WG In-Reply-To: <4D6CFA74.5040709@viagenie.ca> References: <4D6CE8BF.3050507@viagenie.ca> <4D6CFA74.5040709@viagenie.ca> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Mar 2011 18:50:09 +0100 Message-ID: <1299001809.2099.363.camel@dab> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in Erlang X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 17:49:09 -0000 On Tue, 2011-03-01 at 08:53 -0500, Simon Perreault wrote: > > What about this: if we did not even start the resolution for the > other > > AF, and the first connection already finished - should kick off that > the > > name resolution alone - and see if it succeeds before updating P ? > (this > > would resolve the single-stack/dual-stack question - and then would > > avoid updating the P for single-stack hosts *or* broken DNS ?) > > Good idea. That's exactly the kind of experiment I want to make > quickly > feasible with an Erlang implementation! :) We chose to do resolutions simultaneously. If we only get one reply, we don't do happy-eye balls and hence don't consider P. Is there a particular reason to why resolutions should be done separately (other than that "the spec says so") ? // Javier From dwing@cisco.com Tue Mar 1 10:27:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79AFB3A6A16 for ; Tue, 1 Mar 2011 10:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.569 X-Spam-Level: X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDKyChaEqH+c for ; Tue, 1 Mar 2011 10:27:39 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 74B623A698E for ; Tue, 1 Mar 2011 10:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1190; q=dns/txt; s=iport; t=1299004123; x=1300213723; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=vEa2R5dCmZlLBFvbI9wXr/gWg2oIIYZmj0r840f+pXU=; b=jO3zCK+j+h7kDAK0Uu2+c+0No9FwLDa3bYxkyCMoBAVWALO/317efp1C vztIG2AM+63RNOSYCkBhoHJbL0C4r4iu0PY1fj3K157UXr6GvgC2PosrJ urPCxsG/WyEv3tvXliicTNMnJAD2d7yBPnRil/feLuKZRLM+GEx9P+yvt w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAALvJbE2rR7Hu/2dsb2JhbACXeYFljHB0oFicI4VhBIUS X-IronPort-AV: E=Sophos;i="4.62,248,1297036800"; d="scan'208";a="316268183" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 01 Mar 2011 18:28:37 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p21ISYCw027170; Tue, 1 Mar 2011 18:28:34 GMT From: "Dan Wing" To: "'Javier Ubillos'" , "'IPv6 Ops WG'" References: <4D6CE8BF.3050507@viagenie.ca> <4D6CFA74.5040709@viagenie.ca> <1299001809.2099.363.camel@dab> In-Reply-To: <1299001809.2099.363.camel@dab> Date: Tue, 1 Mar 2011 10:28:34 -0800 Message-ID: <064d01cbd83e$79976cd0$6cc64670$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvYOSSpzNELAcMTRGauJH3hb5CqoAABTexQ Content-Language: en-us Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in Erlang X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 18:27:40 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Javier Ubillos > Sent: Tuesday, March 01, 2011 9:50 AM > To: IPv6 Ops WG > Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in > Erlang > > On Tue, 2011-03-01 at 08:53 -0500, Simon Perreault wrote: > > > What about this: if we did not even start the resolution for the > > other > > > AF, and the first connection already finished - should kick off > that > > the > > > name resolution alone - and see if it succeeds before updating P ? > > (this > > > would resolve the single-stack/dual-stack question - and then would > > > avoid updating the P for single-stack hosts *or* broken DNS ?) > > > > Good idea. That's exactly the kind of experiment I want to make > > quickly > > feasible with an Erlang implementation! :) > > We chose to do resolutions simultaneously. If we only get one reply, we > don't do happy-eye balls and hence don't consider P. > > Is there a particular reason to why resolutions should be done > separately (other than that "the spec says so") ? Primarily a concern about local RFC4074 broken resolvers. -d From dwing@cisco.com Tue Mar 1 10:28:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D392E3A698E for ; Tue, 1 Mar 2011 10:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.366 X-Spam-Level: X-Spam-Status: No, score=-110.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM--sGFuSpKH for ; Tue, 1 Mar 2011 10:28:38 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 09BD33A6A10 for ; Tue, 1 Mar 2011 10:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1558; q=dns/txt; s=iport; t=1299004172; x=1300213772; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=/wixkTXYZnLFCXOVZpdKOMWqL8YCsvE0qWIVtkgCHK8=; b=eI/H1CKdEHDItY7yzBx4eaDJw/RdJ5Dt9o+ttaLSLNdpWBNceG01TTTK 40dz0a1fWS1EQXOtDCBBN7d7K076uXz1qyVQcJ3Wae2cMA9ofzNygbKZi 6ES69Fb0nAeI++kBVozO6+t3ThH7w/pTDPl7tK6eU9HToSZb2WjXX3nU8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAG/KbE2rRN+J/2dsb2JhbACXeYFljHB0oE6cI4VhBIUS X-IronPort-AV: E=Sophos;i="4.62,248,1297036800"; d="scan'208";a="337160725" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2011 18:29:32 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p21ITWuW008969; Tue, 1 Mar 2011 18:29:32 GMT From: "Dan Wing" To: "'Erik Kline'" , "'Simon Perreault'" References: <4D6CE8BF.3050507@viagenie.ca> <4D6CF6E8.6090903@viagenie.ca> In-Reply-To: Date: Tue, 1 Mar 2011 10:29:31 -0800 Message-ID: <064e01cbd83e$9bbc9330$d335b990$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvYFumW96W91bJxRfyFwaQNmGGDygAJ5XqQ Content-Language: en-us Cc: 'Scott W Brim' , 'IPv6 Ops WG' , 'Andrew Yourtchenko' Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in Erlang X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 18:28:39 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Erik Kline > Sent: Tuesday, March 01, 2011 5:45 AM > To: Simon Perreault > Cc: Andrew Yourtchenko; IPv6 Ops WG; Scott W Brim > Subject: Re: [v6ops] Open-Source Happy Eyeballs Implementation in > Erlang > > On 1 March 2011 22:38, Simon Perreault > wrote: > > On 2011-03-01 08:27, Scott W Brim wrote: > >> In an environment with v4 and dual-stack, it is difficult to move > >> aggressively to v6 ... but consider what an average user would do in > >> that situation, without happy eyeballs: just use v4 for everything. > > > > I'm not following you. In a dual-stack environment, most current apps > > prefer IPv6. If IPv6 times out, they try IPv4. > > > >> Also, when v6 wins, the algorithm aggressively moves back toward > zero > >> (and then slowly out to favor v6). > > > > The point is that once P reaches "favour IPv4 by 4 seconds", IPv6 > will > > *never* win unless when connecting to an IPv6-only server. That's not > > helping the transition to IPv6. > > So in a world where only a small percentage of the destinations even > have AAAAs the application P value will be so heavily IPv4-dominant > that the poor one off destinations that are dualstacked will never see > IPv6 traffic? If I understand you correctly I agree, this would make > IPv6 deployment nearly pointless. So, "P" should be prevented from trending towards IPv4 more than milliseconds. -d From brian.e.carpenter@gmail.com Tue Mar 1 13:19:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71803A6A16 for ; Tue, 1 Mar 2011 13:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.156 X-Spam-Level: X-Spam-Status: No, score=-103.156 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5s7+41V+Tr3 for ; Tue, 1 Mar 2011 13:19:07 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 395A33A6AD8 for ; Tue, 1 Mar 2011 13:19:06 -0800 (PST) Received: by fxm15 with SMTP id 15so5411505fxm.31 for ; Tue, 01 Mar 2011 13:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=U86+jm6nTcMwWlGxW5XdCWJuL6rmQG1474EuGCSXj9E=; b=jDCPo5HKTvdcxZQzujaeeTvF12AXr8k/g2yiXpWrUxD0/0Q+wVemOZ5KFcQHDhCq0C kYZaC4Gz21Im9WDdvOz08qaNxuTZo7JLnyK1qhlg0mPLy+4IjdHxMZtKp0Soc6VGWMTd zpa9cnPUjjvWale4/SVaPdg+pUzYTa3agYmXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=t1oUjRYQtPeDZZ0chA6inr6ZMATgendbhbOhE8116rEcKDCBL0NjrqG9FHf1imrWc+ cep9fqageuXPQgE5KlT2xXAeNMBvN/Hk5bec2bWrPqowQ9D4P4fzv+BMkVXsICKcdW4T Bgh8ENYhn06NX9CXiJLBE7hFd7/lkr03buHIY= Received: by 10.223.13.136 with SMTP id c8mr8745762faa.119.1299014409622; Tue, 01 Mar 2011 13:20:09 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id c11sm2418741fav.2.2011.03.01.13.20.05 (version=SSLv3 cipher=OTHER); Tue, 01 Mar 2011 13:20:08 -0800 (PST) Message-ID: <4D6D6302.3040101@gmail.com> Date: Wed, 02 Mar 2011 10:20:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <4D6C18BE.2020606@gmail.com> <056B511A55F8AA42A3E492B7DD19A3193C207B@008-AM1MPN1-015.mgdnok.nokia.com> In-Reply-To: <056B511A55F8AA42A3E492B7DD19A3193C207B@008-AM1MPN1-015.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 21:19:09 -0000 On 2011-03-02 02:43, teemu.savolainen@nokia.com wrote: > Chairs, Brian, > > I thought we agreed there is no *the* model for IPv6 multihoming term, but the term is overloaded with multiple meanings? Who is "we"? The nearest we have to an IETF consensus is RFC 3582. But yes, there is no single model and probably never will be. > Anyhow, many of the topics have been already discussed in MIF, e.g. multiple namespaces of DNS. Should we repeat the discussion here (for v6ops' education?)? Having multiple interfaces is not the same thing as multihoming. You can have multiple interfaces that connect you to the same ISP; if you happen to have two simultaneous addresses from the same ISP, you are not multihomed in any useful way. I haven't had time to review the MIF documents, but if MIF intends to recommend splitting the DNS namespace, I think there will be an enormous fight at IETF level. Brian > > Best regards, > > Teemu > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of ext >> Brian E Carpenter >> Sent: 28. helmikuuta 2011 23:51 >> To: Fred Baker >> Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica >> Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC >> >> Hi, >> >> I think this draft still needs a lot of work. >> >> First, quite a bit of rewriting is needed in the Introduction. >> >>> Multihoming is a blanket term to describe a host or small network >>> that is connected to more than one upstream network. >> I suggest a reference to RFC 3582 here, where the IPv6 requirements >> are listed. >> >>> For example, a remote access user may use a VPN to >>> simultaneously connect to a remote network and retain a default route >>> to the Internet for other purposes. >> I don't think this is really a red herring. It's a very common scenario >> but it does amount to MIF rather than multihoming, since the >> VPN usually appears as a virtual interface. The draft should focus >> on MH not on MIF, I think. >> >>> In IPv4 a common solution to the multihoming problem is to employ >>> NAPT... >> Probably this should start by saying that RFC 4116 is the most common >> method. It should be made clear that avoiding that method, with its >> built-in scaling problem, is of equal importance to avoiding NAPT. >> >> There should also be a discussion of NPTv6, which also avoids NAPT and >> RFC 4116. Explain why the proposed approach is a better choice than NPT6. >> >> There needs to be a clear statement that the underlying model is >> that having multiple PA prefixes for a site is normal. (And once >> you say that, you also need to explain why the proposed solution is >> better than shim6, or how it will interact with shim6). >> >>> 2. Terminology >> ... >>> NAT66 or IPv6 NAT The terms "NAT66" and "IPv6 NAT" refer to >>> [I-D.mrw-nat66]. >> That is plain wrong. Now I don't understand whether you are trying >> to avoid NAPT66 (which is evil) or NPT6 (which is much less evil, and >> is the actual topic of draft-mrw-nat66). This needs cleaning up >> throughout the draft. >> >>> 3.2. Multihomed network environment >>> >>> In an IPv6 multihomed network, a host is assigned two or more IPv6 >>> addresses and DNS resolvers from independent service provider >>> networks. >> Here I have to agree with Randy - this is not *the* model for IPv6 MH, >> it is only one model (which you define earlier as MHMP). >> >> And why mention separate DNS resolvers? Since DNS is a single namespace, >> you should get the same (multiple) AAAA records from any resolver. >> If not, there's a bug in DNS. >> >>> ...or use a DNS response from an incorrect >>> service provider that may result in impaired IP connectivity. >> No, no, no. Not unless you intend to recommend DNS cheating by >> CDNs. Making DNS cheating work should never be an IETF goal. >> >>> 4.3. DNS server selection >> I am very worried by this section. I think this draft should focus >> on routing issues; just assume that you get back all the AAAA records >> for the target in random order, and go from there. >> >>> 5. Requirements >>> >>> This section describes requirements that any solution multi-address >>> and multi-uplink architectures need to meet. >> I'm puzzled by this section. >> >> 1. It seems to cover all kinds of solutions and not just the solution >> proposed by this document. >> >> 2. It should be much earlier in the document, right after the Introduction. >> >> 3. It mixes MH and MIF issues. >> >> 4. It needs to explain what is added or changed compared to RFC 3582. >> >>> 6.3. DNS resolver selection >> See above. I think this should be out of scope. >> >>> 7.1. IPv6 NAT >> Drop this except for a reference to NPT6. >> >>> 7.2. Co-exisitence consideration >> I think this is no use as it stands because of the last sentence: >> >>> The implementation of identifying non-MHMP hosts and NAT policy is >>> outside the scope of this document. >> I think all you can say is that hosts that don't support MHMP MAY be >> supported by NPT6 or shim6, and if they don't have either of those >> they will not get the benefit of multihoming. That is today's >> situation anyway, so you have done no harm. >> >>> 8. Security Considerations >>> >>> This document does not define any new mechanisms. Each solution >>> mechanisms should consider security risks independently. Security >>> risks that occur as a result of combining solution mechanisms should >>> be considered in another document. >> Er, no. Those risks should be analysed right here in this document. >> >> Also, refer to RFC 4218. Which of those threats apply, and are there >> any new ones? >> >> Brian >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From teemu.savolainen@nokia.com Tue Mar 1 13:38:46 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797FE3A6AE4 for ; Tue, 1 Mar 2011 13:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmjTcQzo5Yt3 for ; Tue, 1 Mar 2011 13:38:45 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id F11783A6ADF for ; Tue, 1 Mar 2011 13:38:44 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p21LdPxK009853; Tue, 1 Mar 2011 23:39:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 23:39:34 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 1 Mar 2011 22:39:34 +0100 Received: from 008-AM1MPN1-015.mgdnok.nokia.com ([169.254.5.61]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0270.002; Tue, 1 Mar 2011 22:39:33 +0100 From: To: Thread-Topic: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC Thread-Index: AQHL15GStS6rDrKywUmdLQdNcrszg5QYej6AgABytQCAABH4Fw== Date: Tue, 1 Mar 2011 21:39:32 +0000 Message-ID: <056B511A55F8AA42A3E492B7DD19A3193C24AD@008-AM1MPN1-015.mgdnok.nokia.com> References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <4D6C18BE.2020606@gmail.com> <056B511A55F8AA42A3E492B7DD19A3193C207B@008-AM1MPN1-015.mgdnok.nokia.com>, <4D6D6302.3040101@gmail.com> In-Reply-To: <4D6D6302.3040101@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.115.224.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2011 21:39:34.0473 (UTC) FILETIME=[27FC5B90:01CBD859] X-Nokia-AV: Clean Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 21:38:46 -0000 Maybe best example of host multihoming, in MIF/NETEXT/MEXT vocabulary at le= ast, is a mobile device that is attached simultaneously to WLAN (provided b= y one ISP) and cellular (provided by another ISP). The addresses received f= rom those interfaces are completely different, and so may be the level of I= nternet connectivity provided by each access. In some cases it may be the s= ame corporation providing both accesses (several cellular ISPs have also WL= AN hotspot network), but in many cases they are not.=0A= =0A= That kind of multihoming causes several issues (not limited to Internet Pro= tocol suite), which is why your current smartphone very likely uses only on= e interface at a time. But it does not have to be that way in the future - = and it will definitely not be so. =0A= =0A= These private DNS namespaces may appear on WLAN, e.g. if that is closed cor= porate WLAN, or cellular as well. Of course if VPNs are thrown into soup, a= lso corporation behind VPN tunnel may employ private namespaces.=0A= =0A= MIF WG is not promoting multiple DNS namespaces, but recognizes such exist = in real life and that hosts need to cope with that. Coping in form of sendi= ng DNS queries to nameservers on all interfaces suboptimal and unwanted app= roach. Interestingly, it seems that in multihoming cases DNSSEC with host b= ased validation is becoming increasingly important feature to support. Anyh= ow, before any meaningful address and interface selections can be made, IP = addresses are needed. Hence need to have means to select which DNS server t= o contact in order to get IP address.=0A= =0A= Best regards,=0A= =0A= Teemu=0A= ________________________________________=0A= From: ext Brian E Carpenter [brian.e.carpenter@gmail.com]=0A= Sent: Tuesday, March 01, 2011 11:20 PM=0A= To: Savolainen Teemu (Nokia-MS/Tampere)=0A= Cc: v6ops-chairs@tools.ietf.org; v6ops@ietf.org; ron@bonica.org; fred@cisco= .com=0A= Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC=0A= =0A= On 2011-03-02 02:43, teemu.savolainen@nokia.com wrote:=0A= > Chairs, Brian,=0A= >=0A= > I thought we agreed there is no *the* model for IPv6 multihoming term, bu= t the term is overloaded with multiple meanings?=0A= =0A= Who is "we"? The nearest we have to an IETF consensus is RFC 3582.=0A= But yes, there is no single model and probably never will be.=0A= =0A= > Anyhow, many of the topics have been already discussed in MIF, e.g. multi= ple namespaces of DNS. Should we repeat the discussion here (for v6ops' edu= cation?)?=0A= =0A= Having multiple interfaces is not the same thing as multihoming. You can ha= ve multiple=0A= interfaces that connect you to the same ISP; if you happen to have two simu= ltaneous=0A= addresses from the same ISP, you are not multihomed in any useful way.=0A= =0A= I haven't had time to review the MIF documents, but if MIF intends to recom= mend=0A= splitting the DNS namespace, I think there will be an enormous fight at IET= F level.=0A= =0A= Brian=0A= =0A= >=0A= > Best regards,=0A= >=0A= > Teemu=0A= >=0A= >> -----Original Message-----=0A= >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf O= f ext=0A= >> Brian E Carpenter=0A= >> Sent: 28. helmikuuta 2011 23:51=0A= >> To: Fred Baker=0A= >> Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica=0A= >> Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC=0A= >>=0A= >> Hi,=0A= >>=0A= >> I think this draft still needs a lot of work.=0A= >>=0A= >> First, quite a bit of rewriting is needed in the Introduction.=0A= >>=0A= >>> Multihoming is a blanket term to describe a host or small network=0A= >>> that is connected to more than one upstream network.=0A= >> I suggest a reference to RFC 3582 here, where the IPv6 requirements=0A= >> are listed.=0A= >>=0A= >>> For example, a remote access user may use a VPN to=0A= >>> simultaneously connect to a remote network and retain a default rout= e=0A= >>> to the Internet for other purposes.=0A= >> I don't think this is really a red herring. It's a very common scenario= =0A= >> but it does amount to MIF rather than multihoming, since the=0A= >> VPN usually appears as a virtual interface. The draft should focus=0A= >> on MH not on MIF, I think.=0A= >>=0A= >>> In IPv4 a common solution to the multihoming problem is to employ=0A= >>> NAPT...=0A= >> Probably this should start by saying that RFC 4116 is the most common=0A= >> method. It should be made clear that avoiding that method, with its=0A= >> built-in scaling problem, is of equal importance to avoiding NAPT.=0A= >>=0A= >> There should also be a discussion of NPTv6, which also avoids NAPT and= =0A= >> RFC 4116. Explain why the proposed approach is a better choice than NPT6= .=0A= >>=0A= >> There needs to be a clear statement that the underlying model is=0A= >> that having multiple PA prefixes for a site is normal. (And once=0A= >> you say that, you also need to explain why the proposed solution is=0A= >> better than shim6, or how it will interact with shim6).=0A= >>=0A= >>> 2. Terminology=0A= >> ...=0A= >>> NAT66 or IPv6 NAT The terms "NAT66" and "IPv6 NAT" refer to=0A= >>> [I-D.mrw-nat66].=0A= >> That is plain wrong. Now I don't understand whether you are trying=0A= >> to avoid NAPT66 (which is evil) or NPT6 (which is much less evil, and=0A= >> is the actual topic of draft-mrw-nat66). This needs cleaning up=0A= >> throughout the draft.=0A= >>=0A= >>> 3.2. Multihomed network environment=0A= >>>=0A= >>> In an IPv6 multihomed network, a host is assigned two or more IPv6= =0A= >>> addresses and DNS resolvers from independent service provider=0A= >>> networks.=0A= >> Here I have to agree with Randy - this is not *the* model for IPv6 MH,= =0A= >> it is only one model (which you define earlier as MHMP).=0A= >>=0A= >> And why mention separate DNS resolvers? Since DNS is a single namespace,= =0A= >> you should get the same (multiple) AAAA records from any resolver.=0A= >> If not, there's a bug in DNS.=0A= >>=0A= >>> ...or use a DNS response from an incorrect=0A= >>> service provider that may result in impaired IP connectivity.=0A= >> No, no, no. Not unless you intend to recommend DNS cheating by=0A= >> CDNs. Making DNS cheating work should never be an IETF goal.=0A= >>=0A= >>> 4.3. DNS server selection=0A= >> I am very worried by this section. I think this draft should focus=0A= >> on routing issues; just assume that you get back all the AAAA records=0A= >> for the target in random order, and go from there.=0A= >>=0A= >>> 5. Requirements=0A= >>>=0A= >>> This section describes requirements that any solution multi-address= =0A= >>> and multi-uplink architectures need to meet.=0A= >> I'm puzzled by this section.=0A= >>=0A= >> 1. It seems to cover all kinds of solutions and not just the solution=0A= >> proposed by this document.=0A= >>=0A= >> 2. It should be much earlier in the document, right after the Introducti= on.=0A= >>=0A= >> 3. It mixes MH and MIF issues.=0A= >>=0A= >> 4. It needs to explain what is added or changed compared to RFC 3582.=0A= >>=0A= >>> 6.3. DNS resolver selection=0A= >> See above. I think this should be out of scope.=0A= >>=0A= >>> 7.1. IPv6 NAT=0A= >> Drop this except for a reference to NPT6.=0A= >>=0A= >>> 7.2. Co-exisitence consideration=0A= >> I think this is no use as it stands because of the last sentence:=0A= >>=0A= >>> The implementation of identifying non-MHMP hosts and NAT policy is= =0A= >>> outside the scope of this document.=0A= >> I think all you can say is that hosts that don't support MHMP MAY be=0A= >> supported by NPT6 or shim6, and if they don't have either of those=0A= >> they will not get the benefit of multihoming. That is today's=0A= >> situation anyway, so you have done no harm.=0A= >>=0A= >>> 8. Security Considerations=0A= >>>=0A= >>> This document does not define any new mechanisms. Each solution=0A= >>> mechanisms should consider security risks independently. Security= =0A= >>> risks that occur as a result of combining solution mechanisms should= =0A= >>> be considered in another document.=0A= >> Er, no. Those risks should be analysed right here in this document.=0A= >>=0A= >> Also, refer to RFC 4218. Which of those threats apply, and are there=0A= >> any new ones?=0A= >>=0A= >> Brian=0A= >> _______________________________________________=0A= >> v6ops mailing list=0A= >> v6ops@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/v6ops=0A= >=0A= From brian.e.carpenter@gmail.com Tue Mar 1 14:08:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A183A69FE for ; Tue, 1 Mar 2011 14:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.153 X-Spam-Level: X-Spam-Status: No, score=-103.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOlgtmBsnoRY for ; Tue, 1 Mar 2011 14:08:37 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B42733A6AD2 for ; Tue, 1 Mar 2011 14:08:36 -0800 (PST) Received: by fxm15 with SMTP id 15so5460572fxm.31 for ; Tue, 01 Mar 2011 14:09:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Jujr1ncafIEEToAvhW4Q6swRqI/IsJS545TO7AAsZ/I=; b=Pihcu+Q9QNB45vhHeeXR1BNeIM8FFKGCSMtMu0tCyAQAUuUqSh/LVgzLADI0hR4LTW 3HDt3SN4hae31Z4w9/1PWmqANdJtsQb/A2R47hFddq6tJLNuPQGbY+fchk3lqThJTgGI DuWoej1e8NKTGx1Sra1oV9+ANdky0d1xYPRdQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=MQ/YI1WWTUMzbuXDYIZvSJyAZvZIankxmdm0AfYMAHsVCaCbLldIB4U6n3QgF1BJt1 S0cm2ZTSZCr1j4puxDF2gDVzXX7TUKFii3Gauk2GmF7Elmapi9OrJ7gVhCiBpR7vRmLY uwoNPlMpLuDNCNsaMZ4uyzTf4NcZEDcGV3V3M= Received: by 10.223.93.139 with SMTP id v11mr7834410fam.101.1299017333408; Tue, 01 Mar 2011 14:08:53 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id n2sm2446383fam.4.2011.03.01.14.08.48 (version=SSLv3 cipher=OTHER); Tue, 01 Mar 2011 14:08:52 -0800 (PST) Message-ID: <4D6D6E6D.8020904@gmail.com> Date: Wed, 02 Mar 2011 11:08:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <4D6C18BE.2020606@gmail.com> <056B511A55F8AA42A3E492B7DD19A3193C207B@008-AM1MPN1-015.mgdnok.nokia.com>, <4D6D6302.3040101@gmail.com> <056B511A55F8AA42A3E492B7DD19A3193C24AD@008-AM1MPN1-015.mgdnok.nokia.com> In-Reply-To: <056B511A55F8AA42A3E492B7DD19A3193C24AD@008-AM1MPN1-015.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 22:08:38 -0000 On 2011-03-02 10:39, teemu.savolainen@nokia.com wrote: > Maybe best example of host multihoming, in MIF/NETEXT/MEXT vocabulary at least, is a mobile device that is attached simultaneously to WLAN (provided by one ISP) and cellular (provided by another ISP). The addresses received from those interfaces are completely different, and so may be the level of Internet connectivity provided by each access. In some cases it may be the same corporation providing both accesses (several cellular ISPs have also WLAN hotspot network), but in many cases they are not. > > That kind of multihoming causes several issues (not limited to Internet Protocol suite), which is why your current smartphone very likely uses only one interface at a time. But it does not have to be that way in the future - and it will definitely not be so. Sure. But I think it's very important to separate the issues that apply to multihoming from the issues that are specific to multiple interfaces (and both from the issues that are specific to mobility). If we don't solve these problems separately we will end up with one big mess. > These private DNS namespaces may appear on WLAN, e.g. if that is closed corporate WLAN, or cellular as well. Of course if VPNs are thrown into soup, also corporation behind VPN tunnel may employ private namespaces. Unfortunately this is reality and I'm not suggesting we should ignore reality. > MIF WG is not promoting multiple DNS namespaces, but recognizes such exist in real life and that hosts need to cope with that. Coping in form of sending DNS queries to nameservers on all interfaces suboptimal and unwanted approach. Interestingly, it seems that in multihoming cases DNSSEC with host based validation is becoming increasingly important feature to support. Anyhow, before any meaningful address and interface selections can be made, IP addresses are needed. Hence need to have means to select which DNS server to contact in order to get IP address. Yes, but nevertheless, you will end up with multiple AAAA records if the remote host itself is multihomed - you can't avoid the address pair selection problem. Brian > Best regards, > > Teemu > ________________________________________ > From: ext Brian E Carpenter [brian.e.carpenter@gmail.com] > Sent: Tuesday, March 01, 2011 11:20 PM > To: Savolainen Teemu (Nokia-MS/Tampere) > Cc: v6ops-chairs@tools.ietf.org; v6ops@ietf.org; ron@bonica.org; fred@cisco.com > Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC > > On 2011-03-02 02:43, teemu.savolainen@nokia.com wrote: >> Chairs, Brian, >> >> I thought we agreed there is no *the* model for IPv6 multihoming term, but the term is overloaded with multiple meanings? > > Who is "we"? The nearest we have to an IETF consensus is RFC 3582. > But yes, there is no single model and probably never will be. > >> Anyhow, many of the topics have been already discussed in MIF, e.g. multiple namespaces of DNS. Should we repeat the discussion here (for v6ops' education?)? > > Having multiple interfaces is not the same thing as multihoming. You can have multiple > interfaces that connect you to the same ISP; if you happen to have two simultaneous > addresses from the same ISP, you are not multihomed in any useful way. > > I haven't had time to review the MIF documents, but if MIF intends to recommend > splitting the DNS namespace, I think there will be an enormous fight at IETF level. > > Brian > >> Best regards, >> >> Teemu >> >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of ext >>> Brian E Carpenter >>> Sent: 28. helmikuuta 2011 23:51 >>> To: Fred Baker >>> Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica >>> Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC >>> >>> Hi, >>> >>> I think this draft still needs a lot of work. >>> >>> First, quite a bit of rewriting is needed in the Introduction. >>> >>>> Multihoming is a blanket term to describe a host or small network >>>> that is connected to more than one upstream network. >>> I suggest a reference to RFC 3582 here, where the IPv6 requirements >>> are listed. >>> >>>> For example, a remote access user may use a VPN to >>>> simultaneously connect to a remote network and retain a default route >>>> to the Internet for other purposes. >>> I don't think this is really a red herring. It's a very common scenario >>> but it does amount to MIF rather than multihoming, since the >>> VPN usually appears as a virtual interface. The draft should focus >>> on MH not on MIF, I think. >>> >>>> In IPv4 a common solution to the multihoming problem is to employ >>>> NAPT... >>> Probably this should start by saying that RFC 4116 is the most common >>> method. It should be made clear that avoiding that method, with its >>> built-in scaling problem, is of equal importance to avoiding NAPT. >>> >>> There should also be a discussion of NPTv6, which also avoids NAPT and >>> RFC 4116. Explain why the proposed approach is a better choice than NPT6. >>> >>> There needs to be a clear statement that the underlying model is >>> that having multiple PA prefixes for a site is normal. (And once >>> you say that, you also need to explain why the proposed solution is >>> better than shim6, or how it will interact with shim6). >>> >>>> 2. Terminology >>> ... >>>> NAT66 or IPv6 NAT The terms "NAT66" and "IPv6 NAT" refer to >>>> [I-D.mrw-nat66]. >>> That is plain wrong. Now I don't understand whether you are trying >>> to avoid NAPT66 (which is evil) or NPT6 (which is much less evil, and >>> is the actual topic of draft-mrw-nat66). This needs cleaning up >>> throughout the draft. >>> >>>> 3.2. Multihomed network environment >>>> >>>> In an IPv6 multihomed network, a host is assigned two or more IPv6 >>>> addresses and DNS resolvers from independent service provider >>>> networks. >>> Here I have to agree with Randy - this is not *the* model for IPv6 MH, >>> it is only one model (which you define earlier as MHMP). >>> >>> And why mention separate DNS resolvers? Since DNS is a single namespace, >>> you should get the same (multiple) AAAA records from any resolver. >>> If not, there's a bug in DNS. >>> >>>> ...or use a DNS response from an incorrect >>>> service provider that may result in impaired IP connectivity. >>> No, no, no. Not unless you intend to recommend DNS cheating by >>> CDNs. Making DNS cheating work should never be an IETF goal. >>> >>>> 4.3. DNS server selection >>> I am very worried by this section. I think this draft should focus >>> on routing issues; just assume that you get back all the AAAA records >>> for the target in random order, and go from there. >>> >>>> 5. Requirements >>>> >>>> This section describes requirements that any solution multi-address >>>> and multi-uplink architectures need to meet. >>> I'm puzzled by this section. >>> >>> 1. It seems to cover all kinds of solutions and not just the solution >>> proposed by this document. >>> >>> 2. It should be much earlier in the document, right after the Introduction. >>> >>> 3. It mixes MH and MIF issues. >>> >>> 4. It needs to explain what is added or changed compared to RFC 3582. >>> >>>> 6.3. DNS resolver selection >>> See above. I think this should be out of scope. >>> >>>> 7.1. IPv6 NAT >>> Drop this except for a reference to NPT6. >>> >>>> 7.2. Co-exisitence consideration >>> I think this is no use as it stands because of the last sentence: >>> >>>> The implementation of identifying non-MHMP hosts and NAT policy is >>>> outside the scope of this document. >>> I think all you can say is that hosts that don't support MHMP MAY be >>> supported by NPT6 or shim6, and if they don't have either of those >>> they will not get the benefit of multihoming. That is today's >>> situation anyway, so you have done no harm. >>> >>>> 8. Security Considerations >>>> >>>> This document does not define any new mechanisms. Each solution >>>> mechanisms should consider security risks independently. Security >>>> risks that occur as a result of combining solution mechanisms should >>>> be considered in another document. >>> Er, no. Those risks should be analysed right here in this document. >>> >>> Also, refer to RFC 4218. Which of those threats apply, and are there >>> any new ones? >>> >>> Brian >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops > From dr@cluenet.de Tue Mar 1 14:14:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0A63A6AC6 for ; Tue, 1 Mar 2011 14:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZN11jG7yjRC for ; Tue, 1 Mar 2011 14:14:55 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 4A57D3A6B05 for ; Tue, 1 Mar 2011 14:14:55 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id CC62B1080B7; Tue, 1 Mar 2011 23:15:58 +0100 (CET) Date: Tue, 1 Mar 2011 23:15:58 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110301221558.GA22199@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 22:14:56 -0000 On Mon, Jan 31, 2011 at 06:54:01AM +0000, Fred Baker wrote: > What do people want to see happen in draft-wbeebee-v6ops-ipv6-cpe-router-bis? Speaking with an operator point of view: get the areas it covers polished up as quickly as possible and get it out of the door as RFC so we can start pointing vendors to it. There's always the option to update the RFC later with more topics covered and operational experience feedback incorporated. > Part of the outcome of IETF 79 was a discussion around Tom Herbst's > draft regarding interactions with the Smart Grid's Home Area Network. > This is something that is not mandatory in a next generation > residential router, but I suspect will have utility. See above. If not really required now, I'd favor not to consider it for cpe-router-bis in order to avoid further delays. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From jhw@apple.com Tue Mar 1 14:34:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C1B3A6A30 for ; Tue, 1 Mar 2011 14:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t232emxVeD7d for ; Tue, 1 Mar 2011 14:34:37 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 34E973A6A46 for ; Tue, 1 Mar 2011 14:34:37 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 61271D5A41D9 for ; Tue, 1 Mar 2011 14:35:41 -0800 (PST) X-AuditID: 1180711d-b7b1cae000002701-c5-4d6d74bddf99 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with SMTP id EC.D1.09985.DB47D6D4; Tue, 1 Mar 2011 14:35:41 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.13.64] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LHE0013MHFGXX60@gertie.apple.com> for v6ops@ietf.org; Tue, 01 Mar 2011 14:35:41 -0800 (PST) From: james woodyatt In-reply-to: <20110301221558.GA22199@srv03.cluenet.de> Date: Tue, 01 Mar 2011 14:35:40 -0800 Message-id: References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <20110301221558.GA22199@srv03.cluenet.de> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1203) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 22:34:38 -0000 On Mar 1, 2011, at 2:15 PM, Daniel Roesen wrote: > On Mon, Jan 31, 2011 at 06:54:01AM +0000, Fred Baker wrote: >> What do people want to see happen in draft-wbeebee-v6ops-ipv6-cpe-router-bis? > > Speaking with an operator point of view: get the areas it covers > polished up as quickly as possible and get it out of the door as RFC so > we can start pointing vendors to it. [...] It's not currently on the agenda for IETF 80. Do the authors plan to ask the working group to adopt it? I hope they update it to remove sections 5.4, 5.5 and 5.9 before they do that. (Amend the figure in section 4, too.) Otherwise, I predict, the draft will be more contentious than operators probably want it to be. If you want it published quickly, then get rid of all the talk about routed subscriber networks and prefix delegation on the LAN. -- james woodyatt member of technical staff, core os networking From teemu.savolainen@nokia.com Tue Mar 1 14:38:54 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4BDB3A6A30 for ; Tue, 1 Mar 2011 14:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7WyPLqB9Aj9 for ; Tue, 1 Mar 2011 14:38:53 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id BD0853A6908 for ; Tue, 1 Mar 2011 14:38:53 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p21Mdp2T022701; Wed, 2 Mar 2011 00:39:53 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 00:39:46 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 1 Mar 2011 23:39:46 +0100 Received: from 008-AM1MPN1-015.mgdnok.nokia.com ([169.254.5.61]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Tue, 1 Mar 2011 23:39:46 +0100 From: To: Thread-Topic: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC Thread-Index: AcvYYY/xtS6rDrKywUmdLQdNcrszgw== Date: Tue, 1 Mar 2011 22:39:44 +0000 Message-ID: <1299019169.4283.42.camel@Nokia-N900> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1299019169428342camelNokiaN900_" MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2011 22:39:46.0850 (UTC) FILETIME=[91215820:01CBD861] X-Nokia-AV: Clean Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, ron@bonica.org Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: teemu.savolainen@nokia.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 22:38:54 -0000 --_000_1299019169428342camelNokiaN900_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBTdXJlLiBCdXQgSSB0aGluayBpdCdzIHZlcnkgaW1wb3J0YW50IHRvIHNlcGFyYXRlIHRoZSBp c3N1ZXMNCj4gdGhhdCBhcHBseSB0byBtdWx0aWhvbWluZyBmcm9tIHRoZSBpc3N1ZXMgdGhhdCBh cmUgc3BlY2lmaWMgdG8NCj4gbXVsdGlwbGUgaW50ZXJmYWNlcyAoYW5kIGJvdGggZnJvbSB0aGUg aXNzdWVzIHRoYXQgYXJlIHNwZWNpZmljDQo+IHRvIG1vYmlsaXR5KS4gSWYgd2UgZG9uJ3Qgc29s dmUgdGhlc2UgcHJvYmxlbXMgc2VwYXJhdGVseSB3ZSB3aWxsDQo+IGVuZCB1cCB3aXRoIG9uZSBi aWcgbWVzcy4NCg0KSnVzdCB0byBjbGFyaWZ5OiBuZWVkIHRvIHNlcGFyYXRlIGlzc3VlcyBzcGVj aWZpYyB0byBoYXZpbmcgbXVsdGlwbGUgcHJlZml4ZXMgb24gYSBzaW5nbGUgaW50ZXJmYWNlIGZy b20gaXNzdWVzIGhhdmluZyBtdWx0aXBsZSBwcmVmaXhlcyBvbiBkaWZmZXJlbnQgaW50ZXJmYWNl cz8gQm90aCBvZiB3aGljaCBhcmUgb2Z0ZW50aW1lcyBjYWxsZWQgbXVsdGlob21pbmcuLg0KDQpX b3VsZCB0aGUgdGVybWlub2xvZ3kgc291bmQgbW9yZSBzZW5zaWJsZSBpZiB3ZSB3b3VsZCB0YWxr IGUuZy4gYWJvdXQgYSBjYXNlIHdoZXJlOiBtdWx0aS1pbnRlcmZhY2VkIHNtYXJ0cGhvbmUgaXMg aGF2aW5nIHNpbXVsdGFuZW91cyBjb25uZWN0aW9uIHRvIG11bHRpaG9tZWQgY29ycG9yYXRlIFdM QU4gbmV0d29yayBhbmQgdG8gY2VsbHVsYXIgY29ubmVjdGlvbiB3aXRoIGEgc2luZ2xlIC82ND8N Cg0KKE1vYmlsaXR5IGlzc3VlcyBhcmUgY2xlYXJseSBzZXBhcmF0ZSkuDQoNCj4gWWVzLCBidXQg bmV2ZXJ0aGVsZXNzLCB5b3Ugd2lsbCBlbmQgdXAgd2l0aCBtdWx0aXBsZSBBQUFBIHJlY29yZHMg aWYNCj4gdGhlIHJlbW90ZSBob3N0IGl0c2VsZiBpcyBtdWx0aWhvbWVkIC0geW91IGNhbid0IGF2 b2lkIHRoZSBhZGRyZXNzDQo+IHBhaXIgc2VsZWN0aW9uIHByb2JsZW0uDQoNCk5vdCBldmVuIHRy eWluZyB0by4gSSBjb3VudCB0aGF0IDZtYW4ncyByZXZpc2l0ZWQtUkZDMzQ4NCBzdXBwb3J0ZWQg YnkgdGhlIGFkZHJlc3Mgc2VsZWN0aW9uIHBvbGljeSBkaXN0cmlidXRpb24gYW5kIHY2b3BzIEhh cHB5IEV5ZWJhbGxzIGhlbHBzIGluIHRoYXQgYXJlYS4NCg0KSS5lLiB3aXRoIGltcHJvdmVkIE1J RiBETlMgc2VsZWN0aW9uIGhvc3RzIHJlc29sdmUgRlFETnMgdG8gYWRkcmVzc2VzLCB0aGVuIHdp dGggTUlGK1JGQzQxOTEgdG9vbHMgZ2V0IHNvbWUgcm91dGluZyBpbmZvIGFuZCByb3V0ZXIgcHJl ZmVyZW5jZXMgb25ib2FyZCAoY292ZXJpbmcgbXVsdGlwbGUgaW50ZXJmYWNlcyksIHRoZW4gd2l0 aCByZXZpc2l0ZWQgNm1hbiBSRkMzNDg0K3JlbGF0ZWQgcG9saWN5IGRpc3RyaWJ1dGlvbiBoYXMg YWxzbyBpbXByb3ZlZCBhZGRyZXNzIHNlbGVjdGlvbiBjYXBhYmlsaXRpZXMsIGFuZCB3aGVuIGFs bCB0aGF0IGlzIGNvdmVyZWQgd2l0aCBzb21lIHY2b3BzIEhhcHB5IEV5ZWJhbGxzLWNyZWFtIHdl IHNob3VsZCBoYXZlIHF1aXRlIGEgY2FrZSB0byB0YXN0ZTotKQ0KDQpUZWVtdQ0K --_000_1299019169428342camelNokiaN900_ Content-Type: text/html; charset="utf-8" Content-ID: <1299019168.4283.41.camel@Nokia-N900> Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+DQo8aHRtbD4NCjxo ZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJPc3NvIE5v dGVzIj4NCjx0aXRsZT48L3RpdGxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8cD4mZ3Q7IFN1cmUuIEJ1 dCBJIHRoaW5rIGl0J3MgdmVyeSBpbXBvcnRhbnQgdG8gc2VwYXJhdGUgdGhlIGlzc3VlcyA8YnI+ DQomZ3Q7IHRoYXQgYXBwbHkgdG8gbXVsdGlob21pbmcgZnJvbSB0aGUgaXNzdWVzIHRoYXQgYXJl IHNwZWNpZmljIHRvIDxicj4NCiZndDsgbXVsdGlwbGUgaW50ZXJmYWNlcyAoYW5kIGJvdGggZnJv bSB0aGUgaXNzdWVzIHRoYXQgYXJlIHNwZWNpZmljIDxicj4NCiZndDsgdG8gbW9iaWxpdHkpLiBJ ZiB3ZSBkb24ndCBzb2x2ZSB0aGVzZSBwcm9ibGVtcyBzZXBhcmF0ZWx5IHdlIHdpbGwgPGJyPg0K Jmd0OyBlbmQgdXAgd2l0aCBvbmUgYmlnIG1lc3MuIDxicj4NCjxicj4NCkp1c3QgdG8gY2xhcmlm eTogbmVlZCB0byBzZXBhcmF0ZSBpc3N1ZXMgc3BlY2lmaWMgdG8gaGF2aW5nIG11bHRpcGxlIHBy ZWZpeGVzIG9uIGEgc2luZ2xlIGludGVyZmFjZSBmcm9tIGlzc3VlcyBoYXZpbmcgbXVsdGlwbGUg cHJlZml4ZXMgb24gZGlmZmVyZW50IGludGVyZmFjZXM/IEJvdGggb2Ygd2hpY2ggYXJlIG9mdGVu dGltZXMgY2FsbGVkIG11bHRpaG9taW5nLi4NCjxicj4NCjxicj4NCldvdWxkIHRoZSB0ZXJtaW5v bG9neSBzb3VuZCBtb3JlIHNlbnNpYmxlIGlmIHdlIHdvdWxkIHRhbGsgZS5nLiBhYm91dCBhIGNh c2Ugd2hlcmU6IG11bHRpLWludGVyZmFjZWQgc21hcnRwaG9uZSBpcyBoYXZpbmcgc2ltdWx0YW5l b3VzIGNvbm5lY3Rpb24gdG8gbXVsdGlob21lZCBjb3Jwb3JhdGUgV0xBTiBuZXR3b3JrIGFuZCB0 byBjZWxsdWxhciBjb25uZWN0aW9uIHdpdGggYSBzaW5nbGUgLzY0Pw0KPGJyPg0KPGJyPg0KKE1v YmlsaXR5IGlzc3VlcyBhcmUgY2xlYXJseSBzZXBhcmF0ZSkuIDxicj4NCjxicj4NCiZndDsgWWVz LCBidXQgbmV2ZXJ0aGVsZXNzLCB5b3Ugd2lsbCBlbmQgdXAgd2l0aCBtdWx0aXBsZSBBQUFBIHJl Y29yZHMgaWYgPGJyPg0KJmd0OyB0aGUgcmVtb3RlIGhvc3QgaXRzZWxmIGlzIG11bHRpaG9tZWQg LSB5b3UgY2FuJ3QgYXZvaWQgdGhlIGFkZHJlc3MgPGJyPg0KJmd0OyBwYWlyIHNlbGVjdGlvbiBw cm9ibGVtLiA8YnI+DQo8YnI+DQpOb3QgZXZlbiB0cnlpbmcgdG8uIEkgY291bnQgdGhhdCA2bWFu J3MgcmV2aXNpdGVkLVJGQzM0ODQgc3VwcG9ydGVkIGJ5IHRoZSBhZGRyZXNzIHNlbGVjdGlvbiBw b2xpY3kgZGlzdHJpYnV0aW9uIGFuZCB2Nm9wcyBIYXBweSBFeWViYWxscyBoZWxwcyBpbiB0aGF0 IGFyZWEuDQo8YnI+DQo8YnI+DQpJLmUuIHdpdGggaW1wcm92ZWQgTUlGIEROUyBzZWxlY3Rpb24g aG9zdHMgcmVzb2x2ZSBGUUROcyB0byBhZGRyZXNzZXMsIHRoZW4gd2l0aCBNSUYmIzQzO1JGQzQx OTEgdG9vbHMgZ2V0IHNvbWUgcm91dGluZyBpbmZvIGFuZCByb3V0ZXIgcHJlZmVyZW5jZXMgb25i b2FyZCAoY292ZXJpbmcgbXVsdGlwbGUgaW50ZXJmYWNlcyksIHRoZW4gd2l0aCByZXZpc2l0ZWQg Nm1hbiBSRkMzNDg0JiM0MztyZWxhdGVkIHBvbGljeSBkaXN0cmlidXRpb24gaGFzIGFsc28gaW1w cm92ZWQNCiBhZGRyZXNzIHNlbGVjdGlvbiBjYXBhYmlsaXRpZXMsIGFuZCB3aGVuIGFsbCB0aGF0 IGlzIGNvdmVyZWQgd2l0aCBzb21lIHY2b3BzIEhhcHB5IEV5ZWJhbGxzLWNyZWFtIHdlIHNob3Vs ZCBoYXZlIHF1aXRlIGEgY2FrZSB0byB0YXN0ZTotKQ0KPGJyPg0KPGJyPg0KVGVlbXU8L3A+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_1299019169428342camelNokiaN900_-- From brian.e.carpenter@gmail.com Tue Mar 1 14:52:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A23C3A6B02 for ; Tue, 1 Mar 2011 14:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.151 X-Spam-Level: X-Spam-Status: No, score=-103.151 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXpz+ZVebrZM for ; Tue, 1 Mar 2011 14:52:14 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4C1AA3A6908 for ; Tue, 1 Mar 2011 14:52:14 -0800 (PST) Received: by wwb22 with SMTP id 22so3787403wwb.13 for ; Tue, 01 Mar 2011 14:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JeuKSuPOrr/YOCVIDLt6WlXoUmUcxa6ONN9JHmyDQ5M=; b=T8gm/c5pfCjP1gNQFG4FhXyBhLq1VOllVVrUuSvFBUZN6GtAMpMoyezoJxKe6y+y3M IPAr9IxQ0NTTphCbHrKha/HZjNH+YyXGgAX5x8PB7LYHd6MkcRr/YOIDAq2GTDf4tqih wDlUJyQb1aFobdsvrTeDeHGfg6wkQ5/isRpck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=l4Gsj+174HzODo1mOLBRl8V+rAau3q66KHyRYlsADhE1yQMqvbdMIgDK5KQnVQe5al 3y/e2Yf6BUVkKV1nZg30odtxCOB5112ndiF4uLRzn3rAN/X2hSylCJdeT2yQcK61XYfx hILgW1q4o/uVer1CUaTizfWWlu6ODMVItWpBI= Received: by 10.217.1.198 with SMTP id n48mr6555674wes.59.1299019997099; Tue, 01 Mar 2011 14:53:17 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id r80sm2761144wei.39.2011.03.01.14.53.13 (version=SSLv3 cipher=OTHER); Tue, 01 Mar 2011 14:53:16 -0800 (PST) Message-ID: <4D6D78D6.7080106@gmail.com> Date: Wed, 02 Mar 2011 11:53:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <1299019169.4283.42.camel@Nokia-N900> In-Reply-To: <1299019169.4283.42.camel@Nokia-N900> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 22:52:16 -0000 On 2011-03-02 11:39, teemu.savolainen@nokia.com wrote: >> Sure. But I think it's very important to separate the issues >> that apply to multihoming from the issues that are specific to >> multiple interfaces (and both from the issues that are specific >> to mobility). If we don't solve these problems separately we will >> end up with one big mess. > > Just to clarify: need to separate issues specific to having multiple prefixes on a single interface from issues having multiple prefixes on different interfaces? Both of which are oftentimes called multihoming.. Oh dear. This gets us back to an old discussion about stacks and virtual interfaces and why draft-irtf-nsrg-report was never published. Maybe we can just say: host-based multihoming is when a host has addresses in more than one separately routed prefix, regardless of interfaces. > Would the terminology sound more sensible if we would talk e.g. about a case where: multi-interfaced smartphone is having simultaneous connection to multihomed corporate WLAN network and to cellular connection with a single /64? That is certainly a scenario to be expected. Brian > (Mobility issues are clearly separate). > >> Yes, but nevertheless, you will end up with multiple AAAA records if >> the remote host itself is multihomed - you can't avoid the address >> pair selection problem. > > Not even trying to. I count that 6man's revisited-RFC3484 supported by the address selection policy distribution and v6ops Happy Eyeballs helps in that area. > > I.e. with improved MIF DNS selection hosts resolve FQDNs to addresses, then with MIF+RFC4191 tools get some routing info and router preferences onboard (covering multiple interfaces), then with revisited 6man RFC3484+related policy distribution has also improved address selection capabilities, and when all that is covered with some v6ops Happy Eyeballs-cream we should have quite a cake to taste:-) > > Teemu From d.sturek@att.net Tue Mar 1 15:53:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351F43A6BF2 for ; Tue, 1 Mar 2011 15:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hlld0PJuhvHO for ; Tue, 1 Mar 2011 15:53:00 -0800 (PST) Received: from nm21-vm0.bullet.mail.ne1.yahoo.com (nm21-vm0.bullet.mail.ne1.yahoo.com [98.138.90.94]) by core3.amsl.com (Postfix) with SMTP id 3C2953A6BF1 for ; Tue, 1 Mar 2011 15:53:00 -0800 (PST) Received: from [98.138.90.49] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 01 Mar 2011 23:54:01 -0000 Received: from [98.138.89.175] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 01 Mar 2011 23:54:01 -0000 Received: from [127.0.0.1] by omp1031.mail.ne1.yahoo.com with NNFMP; 01 Mar 2011 23:54:01 -0000 X-Yahoo-Newman-Id: 594477.17229.bm@omp1031.mail.ne1.yahoo.com Received: (qmail 46519 invoked from network); 1 Mar 2011 23:54:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1299023641; bh=queDrxtx95gweD5mHRB2XL+mVMmw5xDAzSBHQOmhfv4=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=Vn+yi3xUx8IbscbAhN0PLopUBgUaVGbw8Pde1stiz8f/G6f4sj9I7BbWY/gDGJ6u/wzQ2/9Fpasy4BoPWgNxAJiuZsypfkySToBK8JkS1SyZ9542jJQXH1tuKJrHUMcazUe7G7dbt+8rTmp7f3tF2fFhwRo/1xTve0EkFsOvrqQ= Received: from Studio (d.sturek@174.78.56.227 with login) by smtp103.sbc.mail.ne1.yahoo.com with SMTP; 01 Mar 2011 15:53:58 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: DQ5OZQQVM1nvU_GoGNxoZzbPyb709Jua16YyX3jhOepmqeo mIAGQySSaS6vGU1U3XM5rVZ7qZY1Z5CqyL5wubgFTzOyldAtrqArYoUFT__V Hch.nUWS5jNGJUEmXd1PJThw9pS7aRaPYtRc1LQc48ojMRiUk.3nMtJBG92J mQIRA6bSAMVyTLywZmU.fxwzgNkZGqnPdEvL53J646X0MJMMZeQXbyDEXsQH 2XKciJAfApAvApekxJn_fXlmWzKn804lgagMa6nsHcwCHEcT4CklfUXCjtte b.jcNswaqLMHp.0unlQ-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'james woodyatt'" , "'IPv6 Ops WG'" References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <20110301221558.GA22199@srv03.cluenet.de> In-Reply-To: Date: Tue, 1 Mar 2011 15:53:55 -0800 Message-ID: <027501cbd86b$ed15f2d0$c741d870$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvYYQGSP37qoCnwQnO8ueHdX8fpgwACnRRA Content-Language: en-us Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 23:53:01 -0000 Hi James, Question: Who then addresses routed subscriber networks and prefix delegation in the HAN? I think these topics need to be addressed someplace before internetworked CPEs are deployed and the topic becomes a major oversight. For our application (Smart Energy) we already have groups like WiFi, HomePlug and HomeGrid planning exactly such deployments next year. Don -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Tuesday, March 01, 2011 2:36 PM To: IPv6 Ops WG Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here On Mar 1, 2011, at 2:15 PM, Daniel Roesen wrote: > On Mon, Jan 31, 2011 at 06:54:01AM +0000, Fred Baker wrote: >> What do people want to see happen in draft-wbeebee-v6ops-ipv6-cpe-router-bis? > > Speaking with an operator point of view: get the areas it covers > polished up as quickly as possible and get it out of the door as RFC so > we can start pointing vendors to it. [...] It's not currently on the agenda for IETF 80. Do the authors plan to ask the working group to adopt it? I hope they update it to remove sections 5.4, 5.5 and 5.9 before they do that. (Amend the figure in section 4, too.) Otherwise, I predict, the draft will be more contentious than operators probably want it to be. If you want it published quickly, then get rid of all the talk about routed subscriber networks and prefix delegation on the LAN. -- james woodyatt member of technical staff, core os networking _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Tue Mar 1 16:13:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349E83A6BF8 for ; Tue, 1 Mar 2011 16:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOH9YUUKNF5o for ; Tue, 1 Mar 2011 16:13:02 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EBC9E3A6A21 for ; Tue, 1 Mar 2011 16:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=3019; q=dns/txt; s=iport; t=1299024846; x=1300234446; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Vf7JvepVew9XzNQqY+QFMPtCPADkF4a8gWQ60oMbqe4=; b=AO+ZMCamSGNt9nYgBZHF97Mz4bMZvfSiySrxnDT0XZZBRZzOg2SRDOev 964rTvJKEZbyx2sybI0VhVrvaTR8jKO0Ti3n4I6ZbXkLP4a8x5a75/Iio OJszGPHNCd3lMx3Cpp5MrIsRQ5+UFZHMFyGOAPaTp4Tj1R1zsIKjCwIS6 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJcabU2tJXG//2dsb2JhbACmVHSiKZt5hWEEhRKKUw X-IronPort-AV: E=Sophos;i="4.62,250,1297036800"; d="scan'208";a="221308243" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rtp-iport-1.cisco.com with ESMTP; 02 Mar 2011 00:14:05 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p220E5s6000999; Wed, 2 Mar 2011 00:14:05 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 18:14:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2011 18:14:03 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3D68E1A@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here Thread-Index: AcvYYQgKWrVjdJ1KSzKcuyVeRnmMkgABeReQ References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com><20110301221558.GA22199@srv03.cluenet.de> From: "Hemant Singh (shemant)" To: "james woodyatt" , "IPv6 Ops WG" X-OriginalArrivalTime: 02 Mar 2011 00:14:05.0540 (UTC) FILETIME=[BDF8EA40:01CBD86E] Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:13:03 -0000 Folks, At least at the Beijing IETF, I believe there was a some consensus in the room to adopt this document to work on Advanced IPv6 CE router features. James, thanks for your comments - we will look into catering to your comments in the next version we plan to release by March 4th, 2011. After the -00 version is submitted, we authors (and our expanded IPv6 CE router design team) can certainly look into polishing the document and then see if a -01 copy can be submitted by mid-March, 2011. I am going by the dates I received in email from v6ops Chair in Fred. The text in double quotes below is what I received as dates from the Chair. "The final date for submission of new (-00) drafts is 7 March. Final date for updated documents is 14 March. With one exception (a testing report, for which the proceedings will be the enduring documentation), any draft that will be discussed in this working group at IETF-80 needs a draft posted since IETF-79, and should have corresponded with v6ops-chairs@tools.ietf.org on the topic." A bit of news to share with folks. During the week of February 14th, there was a week-long IPv6 CE Router Interop held at the UNH Interop Labs and organized by CableLabs in the U.S. The summary of this Interop was that IPv6 CE Routers would be tested behind a cable modem and the cable modem is connected to a CMTS (Cable Modem Termination System). A CMTS is akin to DSLAM and first hop L3 router functionality in DSL. Since UNH is a short drive from where I work at Cisco in the CMTS router business unit, I expedited an IPv6 ready CMTS system for this Interop. The Cisco provisioning server team expedited the Cisco Network Registrar DHCPv4/DHCPv6 server and provisioning system for the Interop as well. Thus our totally test-ready system reached the Interop ready to start testing within the first hour of the Interop to test any IPv6 router plugged behind a cable modem. A good number of IPv6 CE router vendors came to this Interop. My thanks also go to Cablelabs and Chris Donley whom I requested during the past IETFs that we should have more that two IPv6 CE router Interops per year because then we flush IPv6 CE Router and also IPv6 CMTS issues faster. Thus Cablelabs organized this event during February of this year. =20 http://www.iol.unh.edu/services/testing/ipv6/grouptest/feb_14_2010_cable labs/ Two other Interops occur during April and September at CableLabs in Denver area. Amongst other tests, this Interop also focused on testing our IETF Basic IPV6 CE Router document which is in RFC Editor queue in Edit state. http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router/ Some issues that I have noticed from the Interop will also cause us to add more text to the Advanced IPv6 CE router document. Also, it is up to the Cablelabs (http://cablelabs.com) and the UNH labs to publish any testing results and complete list of participants to a wide mailer such as this one. Thanks, Hemant From jhw@apple.com Tue Mar 1 16:43:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E733A6A21 for ; Tue, 1 Mar 2011 16:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8nkqnhldb2i for ; Tue, 1 Mar 2011 16:43:57 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 28D343A6965 for ; Tue, 1 Mar 2011 16:43:57 -0800 (PST) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id A8AABD5B0075 for ; Tue, 1 Mar 2011 16:45:01 -0800 (PST) X-AuditID: 11807130-b7b5eae000005ccb-76-4d6d930d4544 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay11.apple.com (Apple SCV relay) with SMTP id 80.C3.23755.D039D6D4; Tue, 1 Mar 2011 16:45:01 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.13.64] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LHE00BNTNF17I50@et.apple.com> for v6ops@ietf.org; Tue, 01 Mar 2011 16:45:01 -0800 (PST) From: james woodyatt In-reply-to: <027501cbd86b$ed15f2d0$c741d870$%sturek@att.net> Date: Tue, 01 Mar 2011 16:45:01 -0800 Message-id: References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <20110301221558.GA22199@srv03.cluenet.de> <027501cbd86b$ed15f2d0$c741d870$%sturek@att.net> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1203) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:43:57 -0000 On Mar 1, 2011, at 3:53 PM, Don Sturek wrote: > > I think these topics need to be addressed someplace before internetworked CPEs are deployed and the topic becomes a major oversight. For our application (Smart Energy) we already have groups like WiFi, HomePlug and HomeGrid planning exactly such deployments next year. Understood. Do any of those organizations have a recommendation for a suitable interior routing protocol for residential IPv6 networks? I'm pretty sure IETF doesn't have one to recommend right now, and I'm pessimistic that it will have one by next year to satisfy the plans of the Smart Energy community. Is there are reason that application proxies and neighbor discovery proxies are unsatisfactory solutions? -- james woodyatt member of technical staff, core os networking From twinters@iol.unh.edu Tue Mar 1 17:28:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7CF33A6AC3 for ; Tue, 1 Mar 2011 17:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocoBBZCDq2lN for ; Tue, 1 Mar 2011 17:28:40 -0800 (PST) Received: from exprod5og116.obsmtp.com (exprod5og116.obsmtp.com [64.18.0.147]) by core3.amsl.com (Postfix) with SMTP id BEEAC3A6A30 for ; Tue, 1 Mar 2011 17:28:39 -0800 (PST) Received: from source ([132.177.123.84]) by exprod5ob116.postini.com ([64.18.4.12]) with SMTP ID DSNKTW2dh4a5P7t/khyR5nGVN/PzuGOEJTBz@postini.com; Tue, 01 Mar 2011 17:29:44 PST Received: from [10.0.1.5] (c-24-63-15-128.hsd1.nh.comcast.net [24.63.15.128]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id 97E4321F022; Tue, 1 Mar 2011 20:29:42 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Timothy Winters In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3D68E1A@XMB-RCD-109.cisco.com> Date: Tue, 1 Mar 2011 20:29:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9DCFD9AA-C49C-4FF9-9ED4-809BFED1C7E9@iol.unh.edu> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com><20110301221558.GA22199@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3D68E1A@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 01:28:41 -0000 Hello, As Hemant pointed out the UNH-IOL held a IPv6 CE Plugfest on = Feb. 14, 2011. A whitepaper will be released about our finds from the = event. We expect this to be out in the next couple of weeks, and we are = also planning a second event for May 9th, 2011 at the UNH-IOL. The IPv6 = Forum is looking into creating a IPv6 Ready Logo around the the draft = mentioned below. I will post updated test specifications and the = whitepaper to the list. Please feel free to contact me if you have any = questions about the plugfest or IPv6 Ready program. Regards, Tim On Mar 1, 2011, at 7:14 PM, Hemant Singh (shemant) wrote: > Folks, >=20 > At least at the Beijing IETF, I believe there was a some consensus in > the room to adopt this document to work on Advanced IPv6 CE router > features. James, thanks for your comments - we will look into = catering > to your comments in the next version we plan to release by March 4th, > 2011. After the -00 version is submitted, we authors (and our = expanded > IPv6 CE router design team) can certainly look into polishing the > document and then see if a -01 copy can be submitted by mid-March, = 2011. > I am going by the dates I received in email from v6ops Chair in Fred. > The text in double quotes below is what I received as dates from the > Chair. >=20 > "The final date for submission of new (-00) drafts is 7 March. Final > date for updated documents is 14 March. With one exception (a testing > report, for which the proceedings will be the enduring documentation), > any draft that will be discussed in this working group at IETF-80 = needs > a draft posted since IETF-79, and should have corresponded with > v6ops-chairs@tools.ietf.org on the topic." >=20 > A bit of news to share with folks. During the week of February 14th, > there was a week-long IPv6 CE Router Interop held at the UNH Interop > Labs and organized by CableLabs in the U.S. The summary of this = Interop > was that IPv6 CE Routers would be tested behind a cable modem and the > cable modem is connected to a CMTS (Cable Modem Termination System). = A > CMTS is akin to DSLAM and first hop L3 router functionality in DSL. > Since UNH is a short drive from where I work at Cisco in the CMTS = router > business unit, I expedited an IPv6 ready CMTS system for this Interop. > The Cisco provisioning server team expedited the Cisco Network = Registrar > DHCPv4/DHCPv6 server and provisioning system for the Interop as well. > Thus our totally test-ready system reached the Interop ready to start > testing within the first hour of the Interop to test any IPv6 router > plugged behind a cable modem. A good number of IPv6 CE router vendors > came to this Interop. My thanks also go to Cablelabs and Chris Donley > whom I requested during the past IETFs that we should have more that = two > IPv6 CE router Interops per year because then we flush IPv6 CE Router > and also IPv6 CMTS issues faster. Thus Cablelabs organized this event > during February of this year. =20 >=20 > = http://www.iol.unh.edu/services/testing/ipv6/grouptest/feb_14_2010_cable > labs/ >=20 > Two other Interops occur during April and September at CableLabs in > Denver area. Amongst other tests, this Interop also focused on = testing > our IETF Basic IPV6 CE Router document which is in RFC Editor queue in > Edit state. >=20 > http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router/ >=20 > Some issues that I have noticed from the Interop will also cause us to > add more text to the Advanced IPv6 CE router document. Also, it is up > to the Cablelabs (http://cablelabs.com) and the UNH labs to publish = any > testing results and complete list of participants to a wide mailer = such > as this one. >=20 > Thanks, >=20 > Hemant >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Tue Mar 1 17:46:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5C63A6A30 for ; Tue, 1 Mar 2011 17:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyWoWSZI+JVZ for ; Tue, 1 Mar 2011 17:46:23 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 658993A6A21 for ; Tue, 1 Mar 2011 17:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=212; q=dns/txt; s=iport; t=1299030448; x=1300240048; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1dzrwkETeCPIWY34DwElqQ2aRhwdQdjDxxdCeoUE3wI=; b=OCHJ4ZKx+W2FJkGvT6GCTSIFm3DpOgXpI3bkWYPq7Omq3GJwX09jIUyg VQJbrR/FF2H5fJzpfai8v7d0efCxspCqM+pft7fS5djnQ1e0xXTtRfAkJ iu21ChW210Ac9USAD+DT/9GW5k/d1lGh1X0R3cmp/STZPKcLcJE4z5d1k o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANowbU2tJV2Y/2dsb2JhbACmVHSiKpt1hWEEhRKKU4hN X-IronPort-AV: E=Sophos;i="4.62,250,1297036800"; d="scan'208";a="221324115" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 02 Mar 2011 01:47:27 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p221lR7l026867; Wed, 2 Mar 2011 01:47:27 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 19:47:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2011 19:47:24 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3D68E55@XMB-RCD-109.cisco.com> In-Reply-To: <9DCFD9AA-C49C-4FF9-9ED4-809BFED1C7E9@iol.unh.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here Thread-Index: AcvYeVZqiIC/lNj4R56/DtmBrs2phgAAhlyg References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com><20110301221558.GA22199@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3D68E1A@XMB-RCD-109.cisco.com> <9DCFD9AA-C49C-4FF9-9ED4-809BFED1C7E9@iol.unh.edu> From: "Hemant Singh (shemant)" To: "Timothy Winters" X-OriginalArrivalTime: 02 Mar 2011 01:47:27.0369 (UTC) FILETIME=[C8EC2F90:01CBD87B] Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 01:46:24 -0000 Incidentally, I must also thank Timothy Winters and all other folks of the UNH-IOL Lab for their great organization and hospitality during the February Interop.=20 Good to hear from you Timothy. Hemant From randy@psg.com Tue Mar 1 19:12:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF2583A6C14 for ; Tue, 1 Mar 2011 19:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PovHhhv66NDt for ; Tue, 1 Mar 2011 19:12:22 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id BBED43A6B5D for ; Tue, 1 Mar 2011 19:12:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PucV8-00025h-62; Wed, 02 Mar 2011 03:13:22 +0000 Date: Wed, 02 Mar 2011 12:13:21 +0900 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: <0148392A-9BE8-411F-B464-10AC893B472D@cisco.com> References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <056B511A55F8AA42A3E492B7DD19A3193C14BB@008-AM1MPN1-015.mgdnok.nokia.com> <4D6C000B.1090704@bogus.com> <056B511A55F8AA42A3E492B7DD19A3193C19A8@008-AM1MPN1-015.mgdnok.nokia.com> <00DFEA69-DD43-49C0-A012-360BDCB41171@cisco.com> <00e601cbd801$2cebaa00$4001a8c0@gateway.2wire.net> <0148392A-9BE8-411F-B464-10AC893B472D@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 03:12:22 -0000 > I actually have a problem with that definition, though. Yes, a host > can act as if it were multiple; virtual hosts do that. But in MultiTCP > and shim6, the host behaves as if it has more than one address, and > the address is (correctly) understood to be a determiner of a route. I > understand what Jon was getting at, but I think it is too limiting. a lot of what jon was getting at was too limiting. some consider that a feature not a bug. It's perfectly appropriate to be upset. I thought of it in a slightly different way--like a space that we were exploring and, in the early days, we figured out this consistent path through the space: IP, TCP, and so on. What's been happening over the last few years is that the IETF is filling the rest of the space with every alternative approach, not necessarily any better. Every possible alternative is now being written down. And it's not useful. -- Jon Postel (the summer before he died) randy From fred@cisco.com Tue Mar 1 19:41:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264383A6B5D for ; Tue, 1 Mar 2011 19:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.469 X-Spam-Level: X-Spam-Status: No, score=-110.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvOK4Cuag13s for ; Tue, 1 Mar 2011 19:41:05 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1D00D3A6A21 for ; Tue, 1 Mar 2011 19:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=565; q=dns/txt; s=iport; t=1299037330; x=1300246930; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uYQ6RguMT6xiWZL52uw63swYfg0arhyCQFN0r4tt7mg=; b=UMJIdN+5pi5MPEZqSrr01QAT3d8zXPpXsMGRGp69Be91Nk6ojtCviby6 NNe01rTapicbSP5mwbgw8XRykYveQKXhJw0wRXlkR+H6mXKE9v8frTDVR t96JaORdHTAF1MzTHJQZVZy3T+yTBfaKncnLfaHKz2LSssBcAIto8RyYh k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABpLbU2rR7Hu/2dsb2JhbACmVXSiF5t0hWEEhRKHDQ X-IronPort-AV: E=Sophos;i="4.62,251,1297036800"; d="scan'208";a="272535348" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 02 Mar 2011 03:42:08 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p223g84d019534; Wed, 2 Mar 2011 03:42:08 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Tue, 1 Mar 2011 19:42:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <16BC7386-769C-46E3-A6E4-6EA957268E06@cisco.com> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <20110301221558.GA22199@srv03.cluenet.de> <027501cbd86b$ed15f2d0$c741d870$%sturek@att.net> To: james woodyatt X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 03:41:06 -0000 On Mar 1, 2011, at 4:45 PM, james woodyatt wrote: > Understood. Do any of those organizations have a recommendation for a = suitable interior routing protocol for residential IPv6 networks? I'm = pretty sure IETF doesn't have one to recommend right now, and I'm = pessimistic that it will have one by next year to satisfy the plans of = the Smart Energy community. Well, one could discuss ZOSPF, or OSPFv3 with a default configuration, = or RIPng, or IS-IS with a default configuration. Why would, picking one = at random, RIPng be inappropriate?= From ayourtch@cisco.com Tue Mar 1 21:00:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56FD13A6C23 for ; Tue, 1 Mar 2011 21:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.572 X-Spam-Level: * X-Spam-Status: No, score=1.572 tagged_above=-999 required=5 tests=[AWL=-3.471, BAYES_40=-0.185, FRT_STOCK2=3.988, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwC1iuw5hf-E for ; Tue, 1 Mar 2011 21:00:51 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id DA9263A6C18 for ; Tue, 1 Mar 2011 21:00:50 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p224M1ZU001778; Wed, 2 Mar 2011 05:22:01 +0100 (CET) Received: from sweet-brew-3.cisco.com (sweet-brew-3.cisco.com [144.254.10.204]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p224Lv61006690; Wed, 2 Mar 2011 05:21:58 +0100 (CET) Date: Wed, 2 Mar 2011 05:21:57 +0100 (CET) From: Andrew Yourtchenko To: "Bjoern A. Zeeb" In-Reply-To: <20110127094607.A39951@maildrop.int.zabbadoz.net> Message-ID: References: <20110127094607.A39951@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-wing-v6ops-happy-eyeballs-ipv6-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 05:00:53 -0000 Hi Bjoern, Apologies for the latency, just got to editing everything... First of all - thanks a lot for the very detailed comments! On Thu, 27 Jan 2011, Bjoern A. Zeeb wrote: > Hi, > > (ignore the things that have been said since October already) > > General comments upfront: > > - I don't like the name of compnay-of-the-days being used as samples > in standards, especially when there is no reference attached to it > and if it's just one in a zillion. You should generalize this. > s/Facebook/social networks/; s/Google/content provider/. > - I left some private notes (XXX-BZ) in there that I had at the time > of reading. They may either provide information or be addressed at > the end. > thanks! > >> 1. Introduction >> >> In order to use HTTP successfully over IPv6, it is necessary that the >> user enjoys nearly identical performance as compared to IPv4. A >> combination of today's applications, IPv6 tunneling and IPv6 service >> providers, and some of today's content providers all cause the user >> experience to suffer (Section 3). For IPv6, Google ensures a > > The thing that makes me currently suffer the most wrt to IPv6 is > `magic (or call it bug) in a commercial OS resolver tralala` forcing me > to flush caches up to 70 times a day to be able to get to ipv6 enabled > sites. This comment to my best understanding is very related to the > roots of your draft (but I have yet limited understanding of the actual > problem causing this bug to show up for people; it's been reported by > multiple, yet not fixed). if you have time in Prague, would be very interesting to debug together. I use don't use that resolver, so no means to debug. > > >> While the application recommendations in this document are described >> in the context of HTTP clients ("web browsers"), but is useful and >> applicable to other time-sensitive applications. > > I'd remove the `other` here as "web browsing" is all but time-sensitive > in the classical meaning. The 300ms you will not really notice for a > page-load-time can for some other network usage ruin entire entire > companies or cost them fortunes. s/time-sensitive/interactive/ > > >> 3. Problem Statement >> .. >> As discussed in more detail in Section 3.2, IPv6 connectivity is >> sometimes broken entirely or slower than native IPv4 connectivity. > > Contrary to my findings over the last years, where IPv6 often was > faster or more reliable especially on trans-continental links between > the same two dual-stack systems (as seen from DE to CA.US, DE to CA and > DE to AU). > I have even found that going via some 3rd party IPv6 rather than directly > into the destination network at the next IXP using their internal IPv4 > transport, IPv6 was still faster. I also like the variance, especially > as in the following samples the IPv6 is actually tunnelled and still > better. > > (DE - AU) > round-trip min/avg/max/stddev = 332.616/357.183/408.802/28.150 ms > round-trip min/avg/max/std-dev = 336.952/338.048/340.461/0.973 ms > > (DE - CA [east coast]) > round-trip min/avg/max/stddev = 129.852/136.686/145.283/5.634 ms > round-trip min/avg/max/std-dev = 118.636/120.272/121.628/0.996 ms > > [I wonder if someone may have the data of a lot more probes somewhere?] > Interesting. In my measurements the IPv6 was usually a little bit slower, but then I had quite some of tunneled IPv6... > So I think, even though pointing to the other section, the above > should be a lot more precise or limit things to "very special > circumstances" as I think it's just the very obvious brokeness you try > to address but you'll also catch the 10ms deltas in other areas > unfortunately. Yeah, in the beginning it may catch and amplify the noise. Means to be preferred, one service must be better than the other one (possibly with some headstart for IPv6). I don't have a good idea on what specifically to change - not putting edits for now, let's talk this more. > > >> 3.2. IPv6 >> >> ... >> Reasons for such failure include no connection to the IPv6 Internet, >> broken 6to4 or Teredo tunnels, and broken IPv6 peering. > > Hmm, if there is no connection you should get the almost instant > notification back and move on. Broken IPv6 peering as much in > broken IPv4 peering (I don't think the legacy world is any better). > > >> 1. |<--www.example.com A?-----| | >> 2. |<--www.example.com AAAA?--| | >> 3. |---192.0.2.1------------->| | >> 4. |---2001:dba::1----------->| | > > Hmm, www.example.com has A and AAAA records; either use those or > better 2001:db8:: rather than 2001:dba:: (here and throughout the document). > > > The problem described here, really is not that much IPv6 specific and > not much different to just multiple-A records, is it? correct - though the assumption is that the connectivity properties within the AF are more homogenous than between different AFs, and that at a given point of time one AF will have better connectivity than the other. > > >> The client attempts to connect using IPv6 to the server, but the IPv6 >> path is broken (6-8), which consumes several seconds of time. > > The entire thing strikes me as as general TCP behaviour (often tunable > by global MIB variables or per socket options depending on the OS) > told how to handle since at least RFC1122 (STD3) section 4.2.3.5. > Yes. Seems like the defaults are not very friendly to the user, though. > >> 4.1. IPv6 > > I think the section title, if not already for 3.2, at least here is > misleading. The very best it descripes "Dual Stack" behaviour. > > >> In diagram above, ... > > Add 'the'. > > XXX-BZ revisit (what if there is more than one record returned per address > family (AF)) Whatever happens today (first of the answers?) seems to work in IPv4. Whether the same approach would work with IPv6 - maybe, maybe not. Agree we should talk more about this. > >> using IPv4. The IPv6 path is retried until the application gives up >> (10). > > I think given the diagram you should s/the application gives up/TCP > times out/ here. No. It's when IPv4 happened to work all right and we give up on trying the IPv6 for this connection. > > >> The absolute value of >> P is the measure of a delay before initiating a connection attempt on >> the other address family. > > A 'connection attempt' in literature seems to be more the one of the > real upper layer protocoal (ULP) connection but what you want to say is > "the DNS lookup and connection attempt ..." s//a DNS lookup and / > > >> The TCP client application starts two threads in order to minimize >> the user-noticeable delay ("dead time") during the connection >> attempts: > > I think the draft should not enforce how to implement things. > Threads are just one way to implement the expected (concurrent) > behaviour. I would love to see the word 'thread' to go away from the > draft completely or detailed that other ways to implement the expected > behaviour may equally be chosen. Erik also had the same comment. I've put it this way: "The TCP client application starts two concurrent execution flows (they will be referred to as "threads" but this reference does not imply the implementation detail of using the threading library, merely the property of mutual concurrency) in order to minimize the user-noticeable delay ("dead time") during the connection attempts:" The "flow" is used in other contexts as well in other places, so really we need a third word. I don't have a good one to do a global search/replace with. > > >> * If P<0, wait for absolute value of p*10 milliseconds > > Mix of 'P' and 'p'. Should be all upper-case? > > XXX-BZ revist - which P is this - the per destination or the global? > (should be disambiguated throughout the entire draft Ps (P socket) and > Pa (P application) or similar and one or the other or both mentioned > explicitly where appropriate. That's something which should really be marked as "to be experimented with". Back when we did the very first experiments, I simply had a single value that gave decent user experience. > > >> The value of P >> is incremented (decremented) each time an IPv6 (IPv4) connection is >> successfully made. > > I felt this is inaccurate. Both IPv4 and IPv6 connections could > succeed, even before you can cancel the other (connection|thread), > so I think you mean s/is successfully made/wins the race/. Yes. > > >> When a connection using the less-preferred >> address family is successful, it indicates the wrong address family >> was used and the P is halved: >> ... > > For the two items: >> o If P>0 ... >> o If P<0 ... > > I'd prefer to have the exact same wording with just s/[46]/[64]/ > s/[<>]/[><]/. Is is more about the order of the two paragraphs ? The 'elevator pitch' is for all of these: The value of P is incremented (decremented) each time an IPv6 (IPv4) connection wins the race if it was preferred originally, and halved if an AF wins the race while not being the preferred protocol. > >> o If P=0 (indicating equal preference), P is incremented if the >> first thread to complete was the IPv6 thread, or decremented if >> the first thread to complete was the IPv4 thread. > > "incremented by 1" "decremented by 1" > >> which >> is similar to the value used by many IPv6-capable TCP client >> applications to switch to an alternate A or AAAA record. > > Again, it's not the application usually (unless using setsockopt) but > the intial connection setup timeout of the TCP stack. > > >> Note: Proof of concept tests on fast networks show that even >> smaller value (around 0.5 seconds) is practical. More extensive >> testing would be useful to find the best upper boundary that still >> ensures a good user experience. > > I think in both cases here and the paragraph above a value of P should > not be in seconds but the absolute value of 400 or 50 (given it's > |P|==400 [ * 10ms = 4s ] ). > > > I feel that |P|==50 is optimistic given that it can easily be 450+ms > from Europe to Australia meaning losing the race twice the application > would immediately favour the other AF. I've done s/is/may be/. Indeed more testing is needed. > > XXX-BZ revist and explain the general problem with the maths in here > as I understand it; general failover, larger caches, bad expiry > > XXX-BZ again, what about multiple AAAA or multiple A records and how > to count that if the first records wins but we move on to the second > for an application failure on that AF? You mean the connection succeeds but we decide to drop it by the application and reestablish ? > > >> 4.2.3. Flush or Expire Cache >> ... >> However, in some instances the >> application and the host are unaware the network connectivity has >> changed so it is RECOMMENDED that per-destination values expire after >> 10 minutes of inactivity. > > XXX-BZ see further down > >> 4.2.4. Determining Address Type > > I would remove that section entirely. It would mean just more magic > that might not be needed at all. If replacement transition technolgy > would work better than native, so be it;-) > This needs more discussion since I got both the "keep" and "remove" opinions :-) On one hand, it does look logical, but then if we're preferring a client-facing NAT64 prefix IPv6 address it is not a whole lot different than preferring IPv4 to IPv6 as far as the rest of the Internet is concerned. > >> 4.2.5. Debugging and Troubleshooting >> ... >> mechanism to temporarily use only one address family. > > The much I'll love once we are there, this is somewhat out of scope I fear > as you can write an entire draft about the pros and cons of just that if > you have the time. I'd much rather like to see the fallback to revert to > the well-known beviour without this draft (whatever it is, mostly usually > disabling the concurrency and trying on after the other). > If you disable one address family a debug trace will usually only show you > half of the information you may want/need. "... that regard, the applications implementing the proposal in this document SHOULD also provide a mechanism to revert the behavior to that of a default provided by the operating system." I've also added this blurb, which I think can help make the troubleshooting a more automated process for those who care: [[[ To be discussed. Some sites may wish to be informed when the the hosts adjust their "P" value, in order to troubleshoot the underlying cause. To help these sites, a strawman proposal is to send a syslog message or other notification to an address that may be configured by a site administrator in a centralized fashion. (The exact method TBD - DHCP option, domain name, etc.) This syslog message should be sent only first N times that the host expects to prefer IPv6 but has to use IPv4. I.e. the first N times it decreases the value of P. N - TBD. ]]] i.e. give the host an ability to send the cry for help if the administrator instructed it to. Given that the whole idea is around the user experience, the operator then can: 1) aggregate: measure the number of "cries for help" to see how bad the problem is (how many heads to fix it) 2) look at specifics and proactively contact those users. This makes a troubleshooting part of me think that this is an improvement compared to what we have now. > > > > Ok, some of the XXX-BZ to be addressed still in general outside the > scope of a specific paragraph: > > "Which P?" > > I feel the two 'P's need to be better explained, as in when to update > which one and when to pick which one. If I had to guess I would go > for a specific implementation but that does not mean anyone else would > go for the same. Be more explicit about that. > Let's hash this out in the bar BoF in Prague (or if there are good arguments on this topic before that, would be good as well on-list). > > "What about multiple AAAA or A records?" > > I know the abstract says "dual stack client" to "dual stack server" > but while in a majority of the cases that might still be true, it's an > ideal world that seems to be especially untrue for the top n sites. > > What should an application do if it gets back only two AAAA records > or 2 AAAA and 4 A records? > > It may well be one of the machines is in Europe and the other is in the > Asia? Do you want to try those in sequence only if one fails or do > you also want to measure the 150ms out that the other one could be > faster? When, in your model, will you then start more threads? No. It'll be up to the DNS server to serve me a decently suitable answer as the first answer within the AF. > > What if the first A wins your match above but the ULP errors? How will > the retry work or the moving on to another record? Will we try the > other AF then depsite having clsoed the conneciton there? > > Depsite they usually should do not expect application to behave exactly > the same no matter which AF you are using. > hm. why ? I thought the whole point of dualstackness was more or less to treat both protocols the same way from the logical point of view. > > "general failover, larger caches, bad expiry" > > Flushing entries from the cache after 10 min. of inactivity has multiple > problems: > > - Say my browser has about the same uptime as my machine. > - Say I keep random-modern-ajax-website open in a window all the time. > - The website will refresh itself every minute or even have "pseudo" > persistent connections (there's a lot of variance in there what > you can observe). > > The result of this will be kind of like: my preference will grow to the > max until there is a network hickup. The question then is will it > last long enough so the preference will flip or will I just see the > 3s delay? Or will it cause the converse and put me on the other > address family for the next week despite my conenctivity in my > actually prefered address family would be all fine again after a > couple of minutes? That will depend. You might indeed get on a different address family for the next week, if they work comparatively the same. > > Next problem is that you are creating a shadow cache in each > application on (hostname,port,P,timeout) which can easily get > into the thousands in 10 minute sliding window of inactivity depending > on the application. That seems wrong to me but I guess people will fix > it with a more intelligent purging strategy (depending on application) -- > say I close my browser tab for a site, purge the entry if it's the last > tab with a connection to the host. Too bad if it was my "home page". > People will be creative once they hit an in-application specific "upper > bound" of cache size despite memory being cheap. > > > Another thing I am worried is that the experience in the non-"fast" > networks in the non-ideal world will kill IPv6 more often than you > wished, especially in the early transition time as it will be for > most users. The reason for that is: while these days you often > get a local A mirror close by for the larger sites, the AAAA machine(s) > are more often further away (which can be in another state or country or > even continent). This will impose extra delay for IPv6 > "lookup+connection attempt" times possibly quickly degrading P to be > IPv4 friendly. It's unpredictable how the content will move to IPv6 > yet, as I see it but I am almost sure the world wide global "IPv6 day" > turn on switch everywhere will not happen. The preference will slowly > change towards v6 but in the mean time you want to push it rather than > slowing it down. > Again, as said at the beginning, it will work well for the really broken > cases but it will also affect the "10 ms difference" setups. > Okay. So, I am a user. Why do I (in a user hat) have to suffer a slower internet then ? Will I get a discount because of the worse experience ? Again - users are not buying IPv4 or IPv6. They buy the chance to do their other "stuff". We want to nudge the IPv6 a bit - but not get too overzealous in it. This also has a property that if a dataplane for a particular AF is less of a capacity than the other one, the excess load will quietly "leak over" to the other AF. This is good for avoiding the short term disasters, is a pain from the troubleshooting side - but, the above "cries for help" should help on the edge ISP. > So will it be a better user experience for me if I'll go through a CGN > which may still is quicker than the native IPv6? You said in one of the paragraphs above "if the transition technology faster than native, could as well use it" :-) - This is the contradiction with that. Besides the details of whether it is AFT or CGN - the result for the world is the same. > > > One way to circumvent the aforementioned weekly flap would be to flush > every cached record every n minutes (a time also long enough for a route > flap to happen and propagate, or just an hour or a day or worst the > TTL of the record returned the application will never learn). It's > something that you can spend a year of research on to properly tune that > for most places around the globe. Time noone has, which makes this bad. > > > I said that a |P|==50 sounds too optimistic for me. What will be a good > absolute value of P? Should the be a static recommendation or not? > Can we have a dynamic value here ? What would it be ? Something like a median time required to establish the X-percentile of TCP connections on the host can be a good value ? > > What about non-TCP? The first mention of TCP is in 4.1 (ignoring the > earlier diagram). Should it equally apply to non-TCP or should TCP be > mentioned already in the abstract? The overall approach does not have to be TCP-specific. But, seems the TCP is the most active problem ? > > > The very last thing is that the winning address you can connect to > fastest does not have to be the address that gives you the best user > experience as it could be the least loaded machine for other reasons: > the application could hang there, ... the application could still have > problems with connections on this address family, ... Will that help > user experience? Yes it's another problem domain but "user > experience" doesn't see the difference. Agreed - this is not perfect. It's just the only approximation that is close enough to the network/transport layer to talk about. Should we have a knob for the L7 to tweak P ? To disable it ? Do the two GET /favicon.ico in case it is HTTP, over two AFs, to determine which of the two is better ? Or try to measure the user's behaviour while browsing, and correlate that with single- or dualstack- nature of the servers ? (far stretch, but presumably there might be some correlation there). Could be - the connection setup time is by far not perfect. It's just that it was the only thing that looked tractable as opposed to "Bad connectivity ? too bad. your internet is off!" approach. Again, thanks for the detailed feedback - these are certainly very useful discussions to have. cheers, andrew > > > /bz > > -- > Bjoern A. Zeeb You have to have visions! > Going to jail sucks -- All my daemons like it! > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html > From jhw@apple.com Wed Mar 2 07:56:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841FE3A6824 for ; Wed, 2 Mar 2011 07:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sglgBVcH-uIs for ; Wed, 2 Mar 2011 07:56:26 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id C38E53A6816 for ; Wed, 2 Mar 2011 07:56:26 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 01036D5DB14B for ; Wed, 2 Mar 2011 07:57:23 -0800 (PST) X-AuditID: 1180711d-b7b1cae000002701-2f-4d6e68e26114 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with SMTP id 21.01.09985.2E86E6D4; Wed, 2 Mar 2011 07:57:22 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [172.16.1.20] ([75.101.54.88]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LHF00JGETNM1600@gertie.apple.com> for v6ops@ietf.org; Wed, 02 Mar 2011 07:57:22 -0800 (PST) From: james woodyatt In-reply-to: <16BC7386-769C-46E3-A6E4-6EA957268E06@cisco.com> Date: Wed, 02 Mar 2011 07:57:22 -0800 Message-id: <0B0B1D69-37A1-4BDC-A473-D574C087F3A0@apple.com> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <20110301221558.GA22199@srv03.cluenet.de> <027501cbd86b$ed15f2d0$c741d870$%sturek@att.net> <16BC7386-769C-46E3-A6E4-6EA957268E06@cisco.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 15:56:27 -0000 On Mar 1, 2011, at 7:42 PM, Fred Baker wrote: > On Mar 1, 2011, at 4:45 PM, james woodyatt wrote: > >> Understood. Do any of those organizations have a recommendation for a suitable interior routing protocol for residential IPv6 networks? I'm pretty sure IETF doesn't have one to recommend right now, and I'm pessimistic that it will have one by next year to satisfy the plans of the Smart Energy community. > > Well, one could discuss ZOSPF, or OSPFv3 with a default configuration, or RIPng, or IS-IS with a default configuration. Why would, picking one at random, RIPng be inappropriate? Unacceptable human interface burden, for starters. Beyond that, I have no technical contributions I can make here. -- james woodyatt member of technical staff, core os networking From fred@cisco.com Wed Mar 2 08:13:29 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B773A67AE for ; Wed, 2 Mar 2011 08:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.511 X-Spam-Level: X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8C9mqfALiJQO for ; Wed, 2 Mar 2011 08:13:28 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5E3083A67A5 for ; Wed, 2 Mar 2011 08:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1629; q=dns/txt; s=iport; t=1299082474; x=1300292074; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=da1D7rdzzdy+/6Ic4fXCYOU8sw10s6wlxMFMKdTedds=; b=Gkyop34sC5H7ASZNE1lKwIjHfiwmHIMxenGt/NHezS0e50oq281xodYX wHfzEVTwFkJ7NY0M5xM8t2WA7Sh1F+NcPaiHHeoscsKdaA2uWWt/TLcJr hSrgmAtRu2trGKq7uWtBoEcd3MUCnJin/SOvB2GHZ9g1jbATJzkWNoeRf Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEr8bU2rRN+J/2dsb2JhbACmWHShd5tyhWEEhReHDw X-IronPort-AV: E=Sophos;i="4.62,253,1297036800"; d="scan'208";a="337847853" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2011 16:14:27 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p22GDVDd019566; Wed, 2 Mar 2011 16:14:27 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <0B0B1D69-37A1-4BDC-A473-D574C087F3A0@apple.com> Date: Wed, 2 Mar 2011 08:14:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <06B3A5FE-6BA7-46C1-86D1-19AA80321628@cisco.com> References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <20110301221558.GA22199@srv03.cluenet.de> <027501cbd86b$ed15f2d0$c741d870$%sturek@att.net> <16BC7386-769C-46E3-A6E4-6EA957268E06@cisco.com> <0B0B1D69-37A1-4BDC-A473-D574C087F3A0@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 16:13:29 -0000 On Mar 2, 2011, at 7:57 AM, james woodyatt wrote: > On Mar 1, 2011, at 7:42 PM, Fred Baker wrote: >> On Mar 1, 2011, at 4:45 PM, james woodyatt wrote: >>=20 >>> Understood. Do any of those organizations have a recommendation for = a suitable interior routing protocol for residential IPv6 networks? I'm = pretty sure IETF doesn't have one to recommend right now, and I'm = pessimistic that it will have one by next year to satisfy the plans of = the Smart Energy community. >>=20 >> Well, one could discuss ZOSPF, or OSPFv3 with a default = configuration, or RIPng, or IS-IS with a default configuration. Why = would, picking one at random, RIPng be inappropriate? >=20 > Unacceptable human interface burden, for starters. Beyond that, I = have no technical contributions I can make here. I dunno. On my Linksys router (which I don't use anymore, but there is = one here at the house), there is a radio button that says "on" or "off" = for RIP. If OSPF comes with a default configuration such as described in = the MIB document, it can do the same; at the job I had before coming to = Cisco (ACC), our configuration design required that when you turned a = feature on it had to be operational, and from there configuration = commands would change it, and so "SET OSPF ON" (ACC's equivalent of that = radio button) had to result in a usable configuration. It worked quite = well, actually. I don't see a radio button as "unacceptable UI burden"; = a lot of people seem to be able to handle it. I would agree if we were asking people to navigate IOS CLI. That's a = punishment, not a UI :-)= From joelja@bogus.com Wed Mar 2 08:26:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F4D3A6816 for ; Wed, 2 Mar 2011 08:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.924 X-Spam-Level: X-Spam-Status: No, score=-101.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeZXpnVmpQiV for ; Wed, 2 Mar 2011 08:26:44 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 1FA203A67A5 for ; Wed, 2 Mar 2011 08:26:43 -0800 (PST) Received: from 23173jjaeggli.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p22GRfhs059267 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 2 Mar 2011 16:27:42 GMT (envelope-from joelja@bogus.com) Message-ID: <4D6E6FF8.8000008@bogus.com> Date: Wed, 02 Mar 2011 08:27:36 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Fred Baker References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <20110301221558.GA22199@srv03.cluenet.de> <027501cbd86b$ed15f2d0$c741d870$%sturek@att.net> <16BC7386-769C-46E3-A6E4-6EA957268E06@cisco.com> <0B0B1D69-37A1-4BDC-A473-D574C087F3A0@apple.com> <06B3A5FE-6BA7-46C1-86D1-19AA80321628@cisco.com> In-Reply-To: <06B3A5FE-6BA7-46C1-86D1-19AA80321628@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Wed, 02 Mar 2011 16:27:42 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 16:26:45 -0000 buffalo aps that I was using a couple of years ago came with rip enabled by default. That was to support the extension of the network using their bridges or mesh APs. similarly I've seen OLSR deployed in a similar fashion in both cases it was meant to be done without user intervention. When two devices are plugged together today they form an l2 adjacency, why not an l3 one? joel On 3/2/11 8:14 AM, Fred Baker wrote: > > On Mar 2, 2011, at 7:57 AM, james woodyatt wrote: > >> On Mar 1, 2011, at 7:42 PM, Fred Baker wrote: >>> On Mar 1, 2011, at 4:45 PM, james woodyatt wrote: >>> >>>> Understood. Do any of those organizations have a recommendation for a suitable interior routing protocol for residential IPv6 networks? I'm pretty sure IETF doesn't have one to recommend right now, and I'm pessimistic that it will have one by next year to satisfy the plans of the Smart Energy community. >>> >>> Well, one could discuss ZOSPF, or OSPFv3 with a default configuration, or RIPng, or IS-IS with a default configuration. Why would, picking one at random, RIPng be inappropriate? >> >> Unacceptable human interface burden, for starters. Beyond that, I have no technical contributions I can make here. > > I dunno. On my Linksys router (which I don't use anymore, but there is one here at the house), there is a radio button that says "on" or "off" for RIP. If OSPF comes with a default configuration such as described in the MIB document, it can do the same; at the job I had before coming to Cisco (ACC), our configuration design required that when you turned a feature on it had to be operational, and from there configuration commands would change it, and so "SET OSPF ON" (ACC's equivalent of that radio button) had to result in a usable configuration. It worked quite well, actually. I don't see a radio button as "unacceptable UI burden"; a lot of people seem to be able to handle it. > > I would agree if we were asking people to navigate IOS CLI. That's a punishment, not a UI :-) > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From therbst@silverspringnet.com Wed Mar 2 11:28:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7413A6823 for ; Wed, 2 Mar 2011 11:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxR53ODF559O for ; Wed, 2 Mar 2011 11:28:41 -0800 (PST) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by core3.amsl.com (Postfix) with ESMTP id EC4CD3A6800 for ; Wed, 2 Mar 2011 11:28:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAEspbk0KyAE+/2dsb2JhbACnYb4+hWEEhReKaQ X-IronPort-AV: E=Sophos;i="4.62,254,1297065600"; d="scan'208";a="3339604" Received: from unknown (HELO IT-EXCA-02.silverspringnet.com) ([10.200.1.62]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 02 Mar 2011 11:29:44 -0800 Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-02.silverspringnet.com ([::1]) with mapi; Wed, 2 Mar 2011 11:29:45 -0800 From: Thomas Herbst To: Daniel Roesen , "v6ops@ietf.org" Date: Wed, 2 Mar 2011 11:29:43 -0800 Thread-Topic: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here Thread-Index: AcvZEC8/oYLc1keMS7SKkUc5GqKtww== Message-ID: In-Reply-To: <20110301221558.GA22199@srv03.cluenet.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 19:28:43 -0000 As one of the people pushing for a simple first v6 cpe document in my old role as=20 "cisco guy hanging out at Linksys", I agree this document should go forward and the=20 "herbst/sturek" draft should be in advanced. tom On 3/1/11 2:15 PM, "Daniel Roesen" wrote: >On Mon, Jan 31, 2011 at 06:54:01AM +0000, Fred Baker wrote: >> What do people want to see happen in >>draft-wbeebee-v6ops-ipv6-cpe-router-bis? > >Speaking with an operator point of view: get the areas it covers >polished up as quickly as possible and get it out of the door as RFC so >we can start pointing vendors to it. There's always the option to update >the RFC later with more topics covered and operational experience >feedback incorporated. > >> Part of the outcome of IETF 79 was a discussion around Tom Herbst's >> draft regarding interactions with the Smart Grid's Home Area Network. >> This is something that is not mandatory in a next generation >> residential router, but I suspect will have utility. > >See above. If not really required now, I'd favor not to consider it for >cpe-router-bis in order to avoid further delays. > >Best regards, >Daniel > >--=20 >CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From therbst@silverspringnet.com Wed Mar 2 11:34:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90733A6869 for ; Wed, 2 Mar 2011 11:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sVg18raGH95 for ; Wed, 2 Mar 2011 11:34:38 -0800 (PST) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by core3.amsl.com (Postfix) with ESMTP id EA97A3A6868 for ; Wed, 2 Mar 2011 11:34:38 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAHcqbk0KyAE8/2dsb2JhbACnYr5BhWEEhReKaQ X-IronPort-AV: E=Sophos;i="4.62,254,1297065600"; d="scan'208";a="3339718" Received: from unknown (HELO IT-EXCA-01.silverspringnet.com) ([10.200.1.60]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 02 Mar 2011 11:35:44 -0800 Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-01.silverspringnet.com ([::1]) with mapi; Wed, 2 Mar 2011 11:35:45 -0800 From: Thomas Herbst To: Joel Jaeggli , Fred Baker Date: Wed, 2 Mar 2011 11:35:43 -0800 Thread-Topic: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here Thread-Index: AcvZEQXD7ooJXwLURPi757zPplfnWg== Message-ID: In-Reply-To: <4D6E6FF8.8000008@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 19:34:39 -0000 In the CPE subgroup discussion in Beijing I'd proposed a default of RIPng on.=20 =20 Ole preferred OSPF with all area 0. If we could pick one, I wouldn't really care which one it was. Picking at random would be more expedient than our normal process. tom On 3/2/11 8:27 AM, "Joel Jaeggli" wrote: >buffalo aps that I was using a couple of years ago came with rip enabled >by default. That was to support the extension of the network using their >bridges or mesh APs. similarly I've seen OLSR deployed in a similar >fashion in both cases it was meant to be done without user intervention. > >When two devices are plugged together today they form an l2 adjacency, >why not an l3 one? > >joel > >On 3/2/11 8:14 AM, Fred Baker wrote: >>=20 >> On Mar 2, 2011, at 7:57 AM, james woodyatt wrote: >>=20 >>> On Mar 1, 2011, at 7:42 PM, Fred Baker wrote: >>>> On Mar 1, 2011, at 4:45 PM, james woodyatt wrote: >>>> >>>>> Understood. Do any of those organizations have a recommendation for >>>>>a suitable interior routing protocol for residential IPv6 networks? >>>>>I'm pretty sure IETF doesn't have one to recommend right now, and I'm >>>>>pessimistic that it will have one by next year to satisfy the plans >>>>>of the Smart Energy community. >>>> >>>> Well, one could discuss ZOSPF, or OSPFv3 with a default >>>>configuration, or RIPng, or IS-IS with a default configuration. Why >>>>would, picking one at random, RIPng be inappropriate? >>> >>> Unacceptable human interface burden, for starters. Beyond that, I >>>have no technical contributions I can make here. >>=20 >> I dunno. On my Linksys router (which I don't use anymore, but there is >>one here at the house), there is a radio button that says "on" or "off" >>for RIP. If OSPF comes with a default configuration such as described in >>the MIB document, it can do the same; at the job I had before coming to >>Cisco (ACC), our configuration design required that when you turned a >>feature on it had to be operational, and from there configuration >>commands would change it, and so "SET OSPF ON" (ACC's equivalent of that >>radio button) had to result in a usable configuration. It worked quite >>well, actually. I don't see a radio button as "unacceptable UI burden"; >>a lot of people seem to be able to handle it. >>=20 >> I would agree if we were asking people to navigate IOS CLI. That's a >>punishment, not a UI :-) >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Wed Mar 2 22:22:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812263A68EC for ; Wed, 2 Mar 2011 22:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.354 X-Spam-Level: X-Spam-Status: No, score=-110.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcVzKBW2CUrN for ; Wed, 2 Mar 2011 22:22:54 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 60C733A67AE for ; Wed, 2 Mar 2011 22:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=974; q=dns/txt; s=iport; t=1299133441; x=1300343041; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=qh9cB2TcjoaVxj1aHi5kgyDncw26j21/ki+cFIMA6kE=; b=aqEJVNHzECAY6DJY3xuIVc6rXi3kISFJ8L8MISzREkOpRUHb24mBiHh6 qSKOziUW4e730yf2ptspegVW7ZCjzR/LLG8syOzyL+21gBlFvX+NPDVs6 GjuKxy3TiEHmsfmmisip/O1o6AkXleOBR3vKU1bWhZVlKNlRiEpR09zFa o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACvBbk2rR7Ht/2dsb2JhbACmdHSiRZt6hWEEhRqHEg X-IronPort-AV: E=Sophos;i="4.62,257,1297036800"; d="scan'208";a="338390060" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 03 Mar 2011 06:19:21 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p236JLuR018709; Thu, 3 Mar 2011 06:19:21 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Wed, 2 Mar 2011 22:19:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Thomas Herbst X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 06:22:55 -0000 On Mar 2, 2011, at 11:35 AM, Thomas Herbst wrote: > Ole preferred OSPF with all area 0. You might take a look at http://tools.ietf.org/id/draft-dimitri-zospf. = You might also take a look at section 2.5 of RFC 1850, which has been = superseded by RFC 4750 but describes the default configuration of an = OSPF entity as defined in the MIB. If you do what it says, it configures a valid and interesting OSPF = configuration. It also has an interesting sid-effect. On every LAN, a = Designated Router is elected. Given that, one can conclude that we know = for sure what LANs exist in the house. Add one more bit of information - = a bit in a Router LSA or a new LSA - indicating that the router in = question is acting as a DHCP server and has been given a prefix by its = upstream, and the Designated Router on a LAN can now obtain a subnet = prefix for the LAN. As a result, we now have a way to uniquely allocate = one more specific prefix per LAN.= From Internet-Drafts@ietf.org Thu Mar 3 08:15:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7EAE3A69ED; Thu, 3 Mar 2011 08:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwWJiGS-bqIi; Thu, 3 Mar 2011 08:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC51E3A69A1; Thu, 3 Mar 2011 08:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110303161501.9479.83801.idtracker@localhost> Date: Thu, 03 Mar 2011 08:15:01 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-happy-eyeballs-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 16:15:05 -0000 --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 : Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts Author(s) : D. Wing, A. Yourtchenko Filename : draft-ietf-v6ops-happy-eyeballs-00.txt Pages : 13 Date : 2011-03-03 This document describes how a dual-stack client can determine the functioning path to a dual-stack server. This provides a seamless user experience during initial deployment of dual-stack networks and during outages of IPv4 or outages of IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-happy-eyeballs-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-v6ops-happy-eyeballs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-03080638.I-D@ietf.org> --NextPart-- From tena@huawei.com Thu Mar 3 13:16:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DBF33A6A25 for ; Thu, 3 Mar 2011 13:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.88 X-Spam-Level: X-Spam-Status: No, score=-105.88 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFYJ9+iZNm86 for ; Thu, 3 Mar 2011 13:16:02 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 237513A6893 for ; Thu, 3 Mar 2011 13:16:02 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHI001QY34L03@usaga02-in.huawei.com> for v6ops@ietf.org; Thu, 03 Mar 2011 13:17:10 -0800 (PST) Received: from TingZousc1 ([10.212.246.186]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHI006IT34K4T@usaga02-in.huawei.com> for v6ops@ietf.org; Thu, 03 Mar 2011 13:17:09 -0800 (PST) Date: Thu, 03 Mar 2011 13:17:11 -0800 From: Tina Tsou In-reply-to: <4D66D92B.5010701@bogus.com> To: 'Joel Jaeggli' Message-id: <029e01cbd9e8$5ca2bc00$15e83400$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvUcMb7V9dPluWOQcm/cm+Ny5B0XAFd4OgA References: <026f01cbd214$a1b71420$e5253c60$@com> <00e901cbd45a$de6a88a0$9b3f99e0$@com> <4D66D92B.5010701@bogus.com> Cc: 'IPv6 Ops WG' , "'Livingood, Jason'" Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 21:16:03 -0000 As I said, I think the Section 10.1 text Jason has further below is OK. I suggested a few words to add *if* someone complains that it should be more specific. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Joel Jaeggli [mailto:joelja@bogus.com] Sent: Thursday, February 24, 2011 2:18 PM To: Tina Tsou Cc: 'Livingood, Jason'; 'IPv6 Ops WG' Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 I don't think we need to be that specific about how people sort out the issue of signing their zones. if 4470 is required for a particular deployment it's probably because you have some condition or desire other than two differing views of the same zone. On 2/24/11 11:41 AM, Tina Tsou wrote: > Hi Jason, > > I think the wording below is OK. I would see if anyone complains about > the wording. It could be a bit more specific. For example, you could add > a few words right at the end so instead of > > > > ... may present incremental operational and/or technical > challenges. > > > > itsaid > > > > ... may present incremental operational and/or technical > challenges such as a requirement for on-line signing. > > > > < /span>We keep our promises with one another - no matter what! > > > > Best Regards, > > Tina TSOU > > http://tinatsou.weebly.com/contact.html > > > > *From:*Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > *Sent:* Tuesday, February 22, 2011 8:24 PM > *To:* Tina Tsou > *Cc:* 'IPv6 Ops WG' > *Subject:* Re: [v6ops] WGLC > draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 > > > > < al>Hi Tina - Thank you for your review and specific feedback below. > These changes will be in the -03 update soon. See my specific responses > inline below. > > > > Thanks! > > Jason > > > > On 2/21/11 5:13 PM, "Tina Tsou" > wrote: > > > > Hi, > > I generally support this document as attempt on real operational > issues involved in the deployment of IPv6. > > < p class= > nt-family:"Calibri","sans-serif";mso-fareast-font-family:"Times New > Roman";color:black'> > > [JL] Thanks! :-) > > > > Comments on section 10.1 "DNSSEC Considerations" are below. > > It says e sent to different querying hosts. If those are all known > in advance, and the server has the DNS zone signing key, it can > separately sign the various alternative answer data sets however you > want. If they are not known in advance, then you have to have the > keys on-line so you can sign answer data in real time. > > > > [JL] Good point. I have attempted to make this more clear. Here is how > that section now appears. If you think this needs further modification, > just say so. > > /DNS security extensions defined in /*/[RFC4033]/* > <#RFC4033>/, /*/[RFC4034]/* <#RFC4034>/, and /*/[RFC4035]/* > <#RFC4035>/ use cryptographic digital signatures to provide origin > authentication and integrity assurance for DNS data. This is done by > creating signatures for DNS data on a Security-Aware Authoritative Name > Server that can be used by Secu rity-Awa e answers. //Since DNS > whitelisting is implemented on an authoritative server, which provides > different answers depending upon which resolver server has sent a query, > the DNSSEC chain of trust is not altered. Even though the authoritative > server will not always return a AAAA resource record when one exists, > respective A resource records and AAAA resource records can and should > both be signed. Therefore there are no DNSSEC implications per se. > However, any implementer of DNS whitelisting should be careful if they > implement both DNSSEC signing of their domain and also DNS whitelisting > of that same domain. Specifically, those domains should ensure that > resource records are being appropriately and reliably signed, which may > present incremental operational and/or technical challenges./ > > > > > > Thank you again, > > Jason > > > > > > > > We keep our promises with one another - no matter what! > > > > Best Regards, > > Tina TSOU < > > http://tinatsou.weebly.com/contact.html > > > > *From:*v6ops-bounces@ietf.org > [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Livingood, Jason > *Sent:* Monday, February 21, 2011 1:57 PM > *To:* Joel Jaeggli; Doug Barton > *Cc:* t: Re: [v6ops] WGLC > draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 > > > > > I proposed a series of edits (sent to jason first due to their > length) > > that neutralize the tone a bit but without I think altering the > content. > > I think that the characterization of the problems with a > whitelistingapproach is useful and important. It's going to > (has) happened anyway > > and it's not a "we told you so" it's "these are the issues you > have to > > contend with." > > > > [JL] I am mid-way through those edits (will take another day or so > to factor them all in). These suggestions will be ad opted in g with > the other specific feedback received in the past few days of WGLC. > > > > Regards > > Jason > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From dougb@dougbarton.us Thu Mar 3 16:18:50 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF773A68B7 for ; Thu, 3 Mar 2011 16:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m7mjmUU6BaR for ; Thu, 3 Mar 2011 16:18:49 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 3B6983A68B5 for ; Thu, 3 Mar 2011 16:18:49 -0800 (PST) Received: (qmail 3865 invoked by uid 399); 4 Mar 2011 00:19:52 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 4 Mar 2011 00:19:52 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D703027.8090902@dougbarton.us> Date: Thu, 03 Mar 2011 16:19:51 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.14) Gecko/20110301 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Livingood, Jason" References: <4D656DE2.8090903@dougbarton.us> In-Reply-To: <4D656DE2.8090903@dougbarton.us> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 00:18:50 -0000 On 02/23/2011 12:28, Doug Barton wrote: > But this is also an excellent example of why I think people are likely > to find this draft offensive rather than helpful. Do you(pl.) honestly > believe that operators are so incredibly stupid that the need to have it > explained to them that, "If you put up a v6-only host, and then do > whitelisting, some people with v6 transport won't be able to reach it." > And if you _do_ believe that it's necessary to explain that, can you > explain to me why you believe it? In case anyone cares, this was not a rhetorical question. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From dougb@dougbarton.us Thu Mar 3 16:25:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20A23A68B7 for ; Thu, 3 Mar 2011 16:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=-0.634, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW605yGNtNgp for ; Thu, 3 Mar 2011 16:25:56 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 6ECBE3A68B5 for ; Thu, 3 Mar 2011 16:25:56 -0800 (PST) Received: (qmail 15010 invoked by uid 399); 4 Mar 2011 00:27:01 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 4 Mar 2011 00:27:01 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D7031D4.70007@dougbarton.us> Date: Thu, 03 Mar 2011 16:27:00 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.14) Gecko/20110301 Thunderbird/3.1.8 MIME-Version: 1.0 References: <758F8FCE-73EA-4CB7-9B61-0BBF4434784C@cisco.com> <4D6C08F6.6040400@gmail.com> In-Reply-To: <4D6C08F6.6040400@gmail.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 00:25:57 -0000 On 02/28/2011 12:43, Brian E Carpenter wrote: > (Although the topic belongs to 6man I am replying > here one last time for consistency.) > > On 2011-02-28 23:49, Richard Hartmann wrote: >> (Seems I sent this email to Brian directly and not to the list. >> Re-sending as is) >> >> On Fri, Feb 25, 2011 at 20:56, Brian E Carpenter >> wrote: >> >>> I don't believe there is an error in the RFC that is worth correcting. >>> It is completely clear what it means by a 16 bit field. >> >> Is it clear because it's obvious to you or is it clear because it's >> defined explicitly? Should RFCs depend on "well, I am pretty sure >> that's what they meant" or "I know what they meant"? > > " 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to > four hexadecimal digits of the eight 16-bit pieces of the address. " > > That is very clear to me about what it means by a 16-bit piece: there > are 8 of them. > >> >> >> And to reduce email load in this thread, but break thread view: >> >> On 02/25/2011 11:56, Brian E Carpenter wrote: >> >>> Isn't 5952 clear enough on this issue? > > (Not me in fact, but never mind...) Blame me. :) >> Unfortunately not. You are free to start and end the sequence of zeros >> wherever you please. > > The above sentence in 4291 makes it clear that the edge is a 16-bit > boundary in each case. > > BTW, the ABNF discussed in RFC 5954 may interest you. > > However, you're correct: 5952 and 5954 are only about syntax. It is > only 4291 that makes it clear that the : is always on a 16-bit > boundary. Brian's description of the situation matches my understanding as well. Particularly I think Section 2.2 of 5952 is clear that compression only applies to "one or more groups of 16 bits of zeros." Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From ek@google.com Thu Mar 3 16:59:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1988D3A68AE for ; Thu, 3 Mar 2011 16:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0b+I-ZtXiklP for ; Thu, 3 Mar 2011 16:59:01 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 33DE93A687C for ; Thu, 3 Mar 2011 16:59:01 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p2410981007335 for ; Thu, 3 Mar 2011 17:00:09 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299200409; bh=wC3yI2ylnQqMyp6GBY1uqgm9ups=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=hB4YPD3r0yIMMI9WxKak1jBEJME7ZkYVO6mosqezyp2N1V/chJjfIH1HLjPjujoHk v6LRQ9xKDev2z89fP1VCg== Received: from qwd6 (qwd6.prod.google.com [10.241.193.198]) by wpaz37.hot.corp.google.com with ESMTP id p240xRJ5016292 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 3 Mar 2011 17:00:08 -0800 Received: by qwd6 with SMTP id 6so1715768qwd.15 for ; Thu, 03 Mar 2011 17:00:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Whky/wiEx/QcG796SPRiMOcdWfwIbWBRseSC3yyQr6o=; b=AsQL3+FX/e1FSsSOU7Oaz4vn3Mm6tCAx218z5xKkWOl5iBs8rlYUobnPgnwTIsiPQD /BhveMNHCek/hOAGBGlA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Z3RNVJoDvB7766WtSPcVUZSS2rRZEo2hov0ehYk6ZFzDeb6fPXMUr1DH7KU/QVqkwU atghSc5pMo4uOfYeU+8w== MIME-Version: 1.0 Received: by 10.229.26.209 with SMTP id f17mr5086qcc.59.1299200407737; Thu, 03 Mar 2011 17:00:07 -0800 (PST) Received: by 10.229.121.8 with HTTP; Thu, 3 Mar 2011 17:00:07 -0800 (PST) In-Reply-To: <4D7031D4.70007@dougbarton.us> References: <758F8FCE-73EA-4CB7-9B61-0BBF4434784C@cisco.com> <4D6C08F6.6040400@gmail.com> <4D7031D4.70007@dougbarton.us> Date: Fri, 4 Mar 2011 10:00:07 +0900 Message-ID: From: Erik Kline To: Doug Barton Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: IPv6 Operations Subject: Re: [v6ops] Errata 2735 for RFC4291 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 00:59:02 -0000 >> However, you're correct: 5952 and 5954 are only about syntax. It is >> only 4291 that makes it clear that the : is always on a 16-bit >> boundary. > > Brian's description of the situation matches my understanding as well. > Particularly I think Section 2.2 of 5952 is clear that compression only > applies to "one or more groups of 16 bits of zeros." Of course parsers will still need to be liberal in what they accept. From danny@tcb.net Thu Mar 3 19:54:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622E83A6923 for ; Thu, 3 Mar 2011 19:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.593 X-Spam-Level: X-Spam-Status: No, score=-109.593 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfEUObje6GvJ for ; Thu, 3 Mar 2011 19:54:03 -0800 (PST) Received: from farnsworth.verisignlabs.com (farnsworth.verisignlabs.com [72.13.58.64]) by core3.amsl.com (Postfix) with ESMTP id 6E4153A6922 for ; Thu, 3 Mar 2011 19:54:03 -0800 (PST) Received: from monsoon.verisignlabs.com (h87.s239.verisign.com [216.168.239.87]) by farnsworth.verisignlabs.com (Postfix) with ESMTP id 96952A538 for ; Fri, 4 Mar 2011 03:55:11 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (dul1dmcphers-m2.vcorp.ad.vrsn.com [10.100.0.103]) by monsoon.verisignlabs.com (Postfix) with ESMTP id 5510A242526 for ; Thu, 3 Mar 2011 22:55:11 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Danny McPherson In-Reply-To: <4D703027.8090902@dougbarton.us> Date: Thu, 3 Mar 2011 22:55:11 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <4D656DE2.8090903@dougbarton.us> <4D703027.8090902@dougbarton.us> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1082) Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 03:54:04 -0000 A belated support from me to this WG LC as well, I think it's useful to document this and provided Jason feedback on earlier versions of the draft. FWIW, I've already personally observed the awareness that this draft and periphery discussions on this issue from Yahoo!, Google, and others generated and believe the operational community is collectively better informed as a result. Publication in v6OPs as an Informational RFC seems quite sensible to me, and I'm also happy to see such a spectrum of operators weigh in on this very discussion. -danny From shemant@cisco.com Fri Mar 4 11:05:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44323A6818 for ; Fri, 4 Mar 2011 11:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLSsyMEWg448 for ; Fri, 4 Mar 2011 11:05:25 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B22A23A6A15 for ; Fri, 4 Mar 2011 11:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1594; q=dns/txt; s=iport; t=1299265595; x=1300475195; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=S0y+XQzqRduyzj5sbb0yy7yQKkom1ny93bRixsPTKRA=; b=GkaEg9ATGU6oenFW2Ep1wNwbQlOriRGfuWULphqDOmrKBxRWLzyik3cK 38tr75rUUxKGVtv/NOmvmlOlJis0whe6FlWXs+YO/PrhQirvr6LwUgpPO WW0AgYlqNsUxzhRrmyhG+K5c1yTdZ3swxIiVqK69OeW2FoRTah4nAdmbJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8AAHDGcE2tJV2c/2dsb2JhbACYJo49dKNem2SFYQSFHIpc X-IronPort-AV: E=Sophos;i="4.62,265,1297036800"; d="scan'208";a="222679828" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 04 Mar 2011 19:06:34 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p24J6YL5010613; Fri, 4 Mar 2011 19:06:34 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 13:06:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 13:06:33 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A27D@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] small concern about CPE advanced requirements Thread-Index: AQHLgHZJJ8j1dKMqzkm7Bkb6NtqtSpNqDBCAgLQwcHA= References: <201011100126.oAA1QCNc011270@givry.fdupont.fr> From: "Hemant Singh (shemant)" To: "Lee, Yiu" , "Francis Dupont" , X-OriginalArrivalTime: 04 Mar 2011 19:06:34.0829 (UTC) FILETIME=[47BB17D0:01CBDA9F] Subject: Re: [v6ops] small concern about CPE advanced requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 19:05:26 -0000 I am planning to submit a new copy of the CPE advanced requirements document. Please let me know if this new text works for you guys. DLW-4: If the IPv6 CE Router is configured with a IPv4 address within a specific addressing range on its WAN interface the IPv6 CE Router MUST disable the DS-Lite B4 element. The specific addressing range is the set of addresses specified in [RFC1918] and the well-known IPv4 address specified in [I-D.ietf-softwire-dual-stack-lite]. Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lee, Yiu Sent: Tuesday, November 09, 2010 10:22 PM To: Francis Dupont; v6ops@ietf.org Subject: Re: [v6ops] small concern about CPE advanced requirements Agreed. On 11/9/10 8:26 PM, "Francis Dupont" wrote: >In draft-wbeebee-v6ops-ipv6-cpe-router-bis-04.txt, >'5.6.1. Dual-Stack(DS)-Lite' page 9: > > DLW-4: If the IPv6 CE Router is configured with an non-RFC1918 IPv4 > address on its WAN interface, the IPv6 CE Router MUST disable > the DS-Lite B4 element. > >The 192.0.0.0/29 from draft-ietf-softwire-dual-stack-lite-06.txt >'5.7. Well-known IPv4 address' page 9 must be added to >RFC 1918 addresses. > >Regards > >Francis.Dupont@fdupont.fr >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Fri Mar 4 11:54:18 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF23B3A6818 for ; Fri, 4 Mar 2011 11:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.4 X-Spam-Level: X-Spam-Status: No, score=-110.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49LXx+BLZX9Y for ; Fri, 4 Mar 2011 11:54:18 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9CE473A6830 for ; Fri, 4 Mar 2011 11:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=700; q=dns/txt; s=iport; t=1299268527; x=1300478127; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NvXzZRqJLf91mzDlw1fgbN9VQ5S8cYyrRNYccfug41U=; b=Mp3y1i52OiLZiGeuByM8q/HnUzW06PPKEvoWtifU0wfzXkcO/Cuh9+7/ qWt+tmaGz/saA9BSF7F0izc4PdXBjrp2LPL6dHIet0TLMiNycVL/7jaJv AgichRwfTEmXF2U4M8Cn/BxsIgNncUx1BOtNLmleTxBtAfQvrSNbn9YxY I=; X-IronPort-AV: E=Sophos;i="4.62,265,1297036800"; d="scan'208";a="412221044" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 04 Mar 2011 19:55:25 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p24JstTK005261; Fri, 4 Mar 2011 19:55:25 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A27D@XMB-RCD-109.cisco.com> Date: Fri, 4 Mar 2011 11:55:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201011100126.oAA1QCNc011270@givry.fdupont.fr> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A27D@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, "Lee, Yiu" Subject: Re: [v6ops] small concern about CPE advanced requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 19:54:19 -0000 On Mar 4, 2011, at 11:06 AM, Hemant Singh (shemant) wrote: > DLW-4: If the IPv6 CE Router is configured with a IPv4 address within = a > specific addressing range on its WAN interface the IPv6 CE Router MUST > disable the DS-Lite B4 element. The specific addressing range is the > set of addresses specified in [RFC1918] and the well-known IPv4 = address > specified in [I-D.ietf-softwire-dual-stack-lite]. I had to read that a couple of times before I thought I understood. The = problem is the ambiguity of "a specific addressing range". ARe you trying to say "if the IPv6 CE Router is configured with an = [RFC1918] address..."? Or are you referring to a different address?= From shemant@cisco.com Fri Mar 4 12:51:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A36A3A69BE for ; Fri, 4 Mar 2011 12:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.699 X-Spam-Level: X-Spam-Status: No, score=-10.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oafa96aKLX0P for ; Fri, 4 Mar 2011 12:51:34 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2A0123A67EF for ; Fri, 4 Mar 2011 12:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1375; q=dns/txt; s=iport; t=1299271963; x=1300481563; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=kTvrvpjYiAp6ZkerXBBSXvvYOVsinBnbNwxwGs2m0vE=; b=dL1nZFtCZz984irOHPccSxi8gMTUuE7KUsyUs1d/wo8hRnC74Kce0Zbw YeTbBb2NyXp9I/2VadFg+NhbRGZsrYxcMDzw8ys1dgrNX/qEbc39gxfCW tX7UWCYUVq1/feqcNEh0LV4UqofdeVG49dv/RU+Ud3Lm8Vcqm0cSgGKrT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAL7fcE2tJXG8/2dsb2JhbACYKo48dKNmm1yFYQSFHIpc X-IronPort-AV: E=Sophos;i="4.62,266,1297036800"; d="scan'208";a="412235090" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-1.cisco.com with ESMTP; 04 Mar 2011 20:52:43 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p24Kqhgl025519; Fri, 4 Mar 2011 20:52:43 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 14:52:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 14:52:41 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A363@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] small concern about CPE advanced requirements Thread-Index: AcvaphvqLooxb8PuRwyvI5U820l8iQAAapjw References: <201011100126.oAA1QCNc011270@givry.fdupont.fr> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A27D@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" X-OriginalArrivalTime: 04 Mar 2011 20:52:43.0664 (UTC) FILETIME=[1BDA3100:01CBDAAE] Cc: v6ops@ietf.org, "Lee, Yiu" Subject: Re: [v6ops] small concern about CPE advanced requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 20:51:36 -0000 -----Original Message----- From: Fred Baker (fred)=20 Sent: Friday, March 04, 2011 2:55 PM To: Hemant Singh (shemant) Cc: Lee, Yiu; Francis Dupont; v6ops@ietf.org Subject: Re: [v6ops] small concern about CPE advanced requirements >I had to read that a couple of times before I thought I understood. The problem is the ambiguity of "a specific addressing range". >ARe you trying to say "if the IPv6 CE Router is configured with an [RFC1918] address..."? Or are you referring to a different address? Sorry, I screwed up the text. For one, I am trying to say if the IPv6 CE router is configured with a public (non-RFC 1918) IPv4 address on its WAN interface, the IPv6 CE Router MUST disable the DS-Lite B4 element. However, the private RFC 1918 address range has to be expanded to include reserved IPv4 address(es) from section 5.7 of draft-ietf-softwire-dual-stack-lite-06. How about this new text that borrows terminology from RFC 1918.=20 DLW-4: If the IPv6 CE Router is configured with a public IPv4 address on its WAN interface, where public IPv4 address is defined as any address which is not in the private IP address space specified in [RFC1918] and also not in the reserved IP address space specified in [I-D.ietf-softwire-dual-stack-lite], then the IPv6 CE Router MUST disable the DS-Lite B4 element.=20 Thanks, Hemant From rdroms@cisco.com Fri Mar 4 13:18:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6004E3A6A17 for ; Fri, 4 Mar 2011 13:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNO3Wc1000tN for ; Fri, 4 Mar 2011 13:18:54 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3D9403A6A0E for ; Fri, 4 Mar 2011 13:18:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=1938; q=dns/txt; s=iport; t=1299273604; x=1300483204; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tTrF8ATpnNTtB3JamBSt03NNRSfbQEbO9igzH4v8zXQ=; b=J+biP2Sld6LwaaXzHiOdb75i4+ZoIKPHS0yt9Ji49R5YATi3VJVI5gaa HFKl26tDYCxRtu/8mlYX/x8zgzXoHzbITO025mqUgMH06xYRhpKb5cmmw CVPxswriZXQ11G0rUZ4vYPVrlIoMCqNkhwzaXDHgsKMUBIa27hGI+wY2X k=; X-IronPort-AV: E=Sophos;i="4.62,266,1297036800"; d="scan'208";a="222368758" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 04 Mar 2011 21:20:03 +0000 Received: from [161.44.65.117] ([161.44.65.117]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p24LK3xX006886; Fri, 4 Mar 2011 21:20:03 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A363@XMB-RCD-109.cisco.com> Date: Fri, 4 Mar 2011 16:20:03 -0500 Content-Transfer-Encoding: 7bit Message-Id: <52F038FE-F040-43A0-B76C-05601679D0CC@cisco.com> References: <201011100126.oAA1QCNc011270@givry.fdupont.fr> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A27D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A363@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, "Lee, Yiu" Subject: Re: [v6ops] small concern about CPE advanced requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 21:18:55 -0000 How about: DLW-4: If the IPv6 CE Router is configured with an address from the private IP address space specified in [RFC1918] or the reserved IP address space specified in [I-D.ietf-softwire-dual-stack-lite], then the IPv6 CE Router MUST disable the DS-Lite B4 element. - Ralph On Mar 4, 2011, at 3:52 PM 3/4/11, Hemant Singh (shemant) wrote: > > > -----Original Message----- > From: Fred Baker (fred) > Sent: Friday, March 04, 2011 2:55 PM > To: Hemant Singh (shemant) > Cc: Lee, Yiu; Francis Dupont; v6ops@ietf.org > Subject: Re: [v6ops] small concern about CPE advanced requirements > > >> I had to read that a couple of times before I thought I understood. The > problem is the ambiguity of "a specific addressing range". > >> ARe you trying to say "if the IPv6 CE Router is configured with an > [RFC1918] address..."? Or are you referring to a different address? > > Sorry, I screwed up the text. For one, I am trying to say if the IPv6 > CE router is configured with a public (non-RFC 1918) IPv4 address on its > WAN interface, the IPv6 CE Router MUST disable the DS-Lite B4 element. > However, the private RFC 1918 address range has to be expanded to > include reserved IPv4 address(es) from section 5.7 of > draft-ietf-softwire-dual-stack-lite-06. How about this new text that > borrows terminology from RFC 1918. > > > DLW-4: If the IPv6 CE Router is configured with a public IPv4 address on > its WAN interface, where public IPv4 address is defined as any address > which is not in the private IP address space specified in [RFC1918] and > also not in the reserved IP address space specified in > [I-D.ietf-softwire-dual-stack-lite], then the IPv6 CE Router MUST > disable the DS-Lite B4 element. > > > Thanks, > > Hemant > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Fri Mar 4 13:24:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75C33A6A2B for ; Fri, 4 Mar 2011 13:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.679 X-Spam-Level: X-Spam-Status: No, score=-10.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mmhe0WVdnGjQ for ; Fri, 4 Mar 2011 13:24:22 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2DBE63A67EF for ; Fri, 4 Mar 2011 13:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=731; q=dns/txt; s=iport; t=1299273932; x=1300483532; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BXIlB744Na3gSDS6XGx6I+q8b2zH2rK6I8QK2OlXlbs=; b=mNCjkNMKSPl0RKXu7kRD2wGZbEAR3vFQtzSaw6tE729kuDy/04M/UXoV lIe9JyGBrEupg3ARiAWz7xBDzwxlzLAPONRNAwKG5+KWF2SNR5vf8Zpm6 2ZpFAkKsNUAiiy+PK6WIpG8iT1Q9o4LkNjVVGlNQ1q7DdqyI0MZpmRjkd U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAD7ncE2tJXG8/2dsb2JhbACYKo48dKNYm1+FYQSFHIpc X-IronPort-AV: E=Sophos;i="4.62,266,1297036800"; d="scan'208";a="269795478" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-4.cisco.com with ESMTP; 04 Mar 2011 21:25:31 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p24LPVRZ030993; Fri, 4 Mar 2011 21:25:31 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 15:25:31 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 15:25:30 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A398@XMB-RCD-109.cisco.com> In-Reply-To: <52F038FE-F040-43A0-B76C-05601679D0CC@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] small concern about CPE advanced requirements Thread-Index: AcvasfBtIYoVxKI5RLi4kIIG28bG7AAAEfvQ References: <201011100126.oAA1QCNc011270@givry.fdupont.fr> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A27D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A363@XMB-RCD-109.cisco.com> <52F038FE-F040-43A0-B76C-05601679D0CC@cisco.com> From: "Hemant Singh (shemant)" To: "Ralph Droms (rdroms)" X-OriginalArrivalTime: 04 Mar 2011 21:25:31.0805 (UTC) FILETIME=[B0F4ACD0:01CBDAB2] Cc: v6ops@ietf.org, "Lee, Yiu" Subject: Re: [v6ops] small concern about CPE advanced requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 21:24:23 -0000 -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Friday, March 04, 2011 4:20 PM To: Hemant Singh (shemant) Cc: Ralph Droms (rdroms); Fred Baker (fred); v6ops@ietf.org; Lee, Yiu Subject: Re: [v6ops] small concern about CPE advanced requirements >How about: >DLW-4: If the IPv6 CE Router is configured with an address from the >private IP address space specified in [RFC1918] or the reserved IP >address space specified in [I-D.ietf-softwire-dual-stack-lite], then >the IPv6 CE Router MUST disable the DS-Lite B4 element. Text above won't work because the B4 element has to be disabled only if a "public" IPv4 address is configured on the WAN interface of the IPv6 CE router. Thanks, Hemant From fred@cisco.com Fri Mar 4 13:29:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058A53A6A36 for ; Fri, 4 Mar 2011 13:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.546 X-Spam-Level: X-Spam-Status: No, score=-110.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEHcMwCnG1nq for ; Fri, 4 Mar 2011 13:29:04 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CDECD3A6A32 for ; Fri, 4 Mar 2011 13:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1636; q=dns/txt; s=iport; t=1299274213; x=1300483813; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=YmGxymf6cLCPzlnxWzz2tAdrLbvtvTgfxSXUVyPGWbg=; b=cZi6xWAAnVffvALD2/iOOr8rwBWuAsZ0+i/w6+7ZymXyVtAiXJzvcEVt Cv/9SFqRpftLZAckUyhDXvGn/olprrcC0d3zFBdKMPWApzMSeVj6wnUMX r17tBWpDSVy8npxcS+O2zkbpCQIs/xoUxe/ZOjhoEpJEYc1GJxt2yMA+f 0=; X-IronPort-AV: E=Sophos;i="4.62,266,1297036800"; d="scan'208";a="269797437" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 04 Mar 2011 21:30:13 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p24LUDWh015147; Fri, 4 Mar 2011 21:30:13 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A363@XMB-RCD-109.cisco.com> Date: Fri, 4 Mar 2011 13:30:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <25C0E3BE-0969-4723-8264-B5670C6B2E80@cisco.com> References: <201011100126.oAA1QCNc011270@givry.fdupont.fr> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A27D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A363@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, "Lee, Yiu" Subject: Re: [v6ops] small concern about CPE advanced requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 21:29:05 -0000 The text makes more sense. As to the requirement - I'll leave that = question to others. On Mar 4, 2011, at 12:52 PM, Hemant Singh (shemant) wrote: >=20 >=20 > -----Original Message----- > From: Fred Baker (fred)=20 > Sent: Friday, March 04, 2011 2:55 PM > To: Hemant Singh (shemant) > Cc: Lee, Yiu; Francis Dupont; v6ops@ietf.org > Subject: Re: [v6ops] small concern about CPE advanced requirements >=20 >=20 >> I had to read that a couple of times before I thought I understood. = The > problem is the ambiguity of "a specific addressing range". >=20 >> ARe you trying to say "if the IPv6 CE Router is configured with an > [RFC1918] address..."? Or are you referring to a different address? >=20 > Sorry, I screwed up the text. For one, I am trying to say if the IPv6 > CE router is configured with a public (non-RFC 1918) IPv4 address on = its > WAN interface, the IPv6 CE Router MUST disable the DS-Lite B4 element. > However, the private RFC 1918 address range has to be expanded to > include reserved IPv4 address(es) from section 5.7 of > draft-ietf-softwire-dual-stack-lite-06. How about this new text that > borrows terminology from RFC 1918.=20 >=20 >=20 > DLW-4: If the IPv6 CE Router is configured with a public IPv4 address = on > its WAN interface, where public IPv4 address is defined as any address > which is not in the private IP address space specified in [RFC1918] = and > also not in the reserved IP address space specified in > [I-D.ietf-softwire-dual-stack-lite], then the IPv6 CE Router MUST > disable the DS-Lite B4 element.=20 >=20 >=20 > Thanks, >=20 > Hemant From rdroms@cisco.com Fri Mar 4 13:31:29 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514683A6A38 for ; Fri, 4 Mar 2011 13:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+2s-v4uXaWX for ; Fri, 4 Mar 2011 13:31:25 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 95F873A6A2D for ; Fri, 4 Mar 2011 13:31:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=1320; q=dns/txt; s=iport; t=1299274355; x=1300483955; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=QhpRHhgACKG+fE3inlNVpDAvbMvh6nkdM0CD5KPJ3DU=; b=PtZxoDLVQ4/RPlwW/QgJF1h2xG0Amd2BiDLRSg9FaQvWCyT4Cne/nlO3 sKKPZm8LgW+4A/kHD53Tp31WmZrdB7q9jMIeKKOExsrKSvFs0TYoGfN5d BFgfKVYouPXETv0Gn+OBnsCfF2AeiFIcMLHK3QQNf2ivrwWqO+i4O0Cfd U=; X-IronPort-AV: E=Sophos;i="4.62,266,1297036800"; d="scan'208";a="222371649" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 04 Mar 2011 21:32:35 +0000 Received: from [161.44.65.117] ([161.44.65.117]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p24LWYXj012625; Fri, 4 Mar 2011 21:32:34 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A398@XMB-RCD-109.cisco.com> Date: Fri, 4 Mar 2011 16:32:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5B7B6652-689E-4516-8674-706AAEC9AE60@cisco.com> References: <201011100126.oAA1QCNc011270@givry.fdupont.fr> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A27D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A363@XMB-RCD-109.cisco.com> <52F038FE-F040-43A0-B76C-05601679D0CC@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A398@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, "Lee, Yiu" Subject: Re: [v6ops] small concern about CPE advanced requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 21:31:29 -0000 Oops, I got the sense of the test backwards. Let's try: DLW-4: If the IPv6 CE Router is configured with an address which is not in the private IP address space specified in [RFC1918] or which is in the reserved IP address space specified in [I-D.ietf-softwire-dual-stack-lite], then the IPv6 CE Router MUST disable the DS-Lite B4 element. Goal is to minimize the text; your call as to whether it's easier to = understand. - Ralph On Mar 4, 2011, at 4:25 PM 3/4/11, Hemant Singh (shemant) wrote: >=20 > -----Original Message----- > From: Ralph Droms (rdroms)=20 > Sent: Friday, March 04, 2011 4:20 PM > To: Hemant Singh (shemant) > Cc: Ralph Droms (rdroms); Fred Baker (fred); v6ops@ietf.org; Lee, Yiu > Subject: Re: [v6ops] small concern about CPE advanced requirements >=20 >> How about: >=20 >> DLW-4: If the IPv6 CE Router is configured with an address from the >> private IP address space specified in [RFC1918] or the reserved IP >> address space specified in [I-D.ietf-softwire-dual-stack-lite], then >> the IPv6 CE Router MUST disable the DS-Lite B4 element. >=20 > Text above won't work because the B4 element has to be disabled only = if > a "public" IPv4 address is configured on the WAN interface of the IPv6 > CE router. >=20 > Thanks, >=20 > Hemant >=20 >=20 From shemant@cisco.com Fri Mar 4 13:33:07 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2573A6A30 for ; Fri, 4 Mar 2011 13:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.666 X-Spam-Level: X-Spam-Status: No, score=-10.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wm2QoD++cJ19 for ; Fri, 4 Mar 2011 13:33:06 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 692C43A6A2D for ; Fri, 4 Mar 2011 13:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=787; q=dns/txt; s=iport; t=1299274456; x=1300484056; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=b8PqpZdY5iYl5paWrYHU91isxh0/Q36pcCa75laI/ds=; b=N5kjcMvUe7cYjziN5l7uGQ+5NVNRNT7IakrrpkLKpJB4x7KwYS1cUqvI ZfU7UhdhJ3xcMLWhXDTLXTrwRd7TxC1StdlzZ/xXWlXyv9vuirgnTc2ol qFq05IVjWZNJDkxwB+cFNVN9wr2aX/QPESoJKYd97vUIpLrTAGusvwKj1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAA7qcE2tJV2c/2dsb2JhbACYKo48dKNSm1mFYQSFHIpc X-IronPort-AV: E=Sophos;i="4.62,266,1297036800"; d="scan'208";a="339594271" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-5.cisco.com with ESMTP; 04 Mar 2011 21:34:15 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p24LYFCv003038; Fri, 4 Mar 2011 21:34:15 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 15:34:15 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 15:34:14 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A39F@XMB-RCD-109.cisco.com> In-Reply-To: <5B7B6652-689E-4516-8674-706AAEC9AE60@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] small concern about CPE advanced requirements Thread-Index: Acvas6093yvbZ9MGRqC3CW7GAnd7fwAABGpQ References: <201011100126.oAA1QCNc011270@givry.fdupont.fr> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A27D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A363@XMB-RCD-109.cisco.com> <52F038FE-F040-43A0-B76C-05601679D0CC@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A398@XMB-RCD-109.cisco.com> <5B7B6652-689E-4516-8674-706AAEC9AE60@cisco.com> From: "Hemant Singh (shemant)" To: "Ralph Droms (rdroms)" X-OriginalArrivalTime: 04 Mar 2011 21:34:15.0888 (UTC) FILETIME=[E9556500:01CBDAB3] Cc: v6ops@ietf.org, "Lee, Yiu" Subject: Re: [v6ops] small concern about CPE advanced requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 21:33:07 -0000 -----Original Message----- From: Ralph Droms (rdroms)=20 Sent: Friday, March 04, 2011 4:33 PM To: Hemant Singh (shemant) Cc: Ralph Droms (rdroms); Fred Baker (fred); v6ops@ietf.org; Lee, Yiu Subject: Re: [v6ops] small concern about CPE advanced requirements >Oops, I got the sense of the test backwards. >Let's try: >DLW-4: If the IPv6 CE Router is configured with an address which is >not in the private IP address space specified in [RFC1918] or which is >in the reserved IP address space specified in >[I-D.ietf-softwire-dual-stack-lite], then the IPv6 CE Router MUST >disable the DS-Lite B4 element. >Goal is to minimize the text; your call as to whether it's easier to understand. Your new text is super! Will take the text. Thanks much! Hemant From shemant@cisco.com Fri Mar 4 13:43:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4900F3A69FA for ; Fri, 4 Mar 2011 13:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.656 X-Spam-Level: X-Spam-Status: No, score=-10.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L980cUW4NLeV for ; Fri, 4 Mar 2011 13:43:37 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 215FB3A6869 for ; Fri, 4 Mar 2011 13:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=593; q=dns/txt; s=iport; t=1299275087; x=1300484687; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=HAFPEIpSRnXsQbSQSkH4R5rFSj7J0Ed3otERDcISY9M=; b=gTj6k25dhVL5F2qMp3Sv0oOjVSz902cePx00tTLbT3OckU9GLymHlREr 63QhTiQhMreBLwUdG8ReWLLlX6rtvoFQ5DsffS/H0nw8BSienEMaXW9YI 0842fSE59OGKuyfUsZKcey1zcSCDrYgghuamq1S0slUauMY/Ek1/2aOKC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAPnrcE2tJV2c/2dsb2JhbACYKo48dKNQm1WFYQSFHIpc X-IronPort-AV: E=Sophos;i="4.62,266,1297036800"; d="scan'208";a="222748551" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 04 Mar 2011 21:44:46 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p24LikjA006014; Fri, 4 Mar 2011 21:44:46 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 15:44:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 15:44:45 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A3B0@XMB-RCD-109.cisco.com> In-Reply-To: <25C0E3BE-0969-4723-8264-B5670C6B2E80@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] small concern about CPE advanced requirements Thread-Index: Acvas1u43Hlnq0vSREaNZdJc2svEzwAAKEhQ References: <201011100126.oAA1QCNc011270@givry.fdupont.fr> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A27D@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3E2A363@XMB-RCD-109.cisco.com> <25C0E3BE-0969-4723-8264-B5670C6B2E80@cisco.com> From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" X-OriginalArrivalTime: 04 Mar 2011 21:44:46.0248 (UTC) FILETIME=[610EB280:01CBDAB5] Cc: v6ops@ietf.org, "Lee, Yiu" Subject: Re: [v6ops] small concern about CPE advanced requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 21:43:38 -0000 -----Original Message----- From: Fred Baker (fred)=20 Sent: Friday, March 04, 2011 4:30 PM To: Hemant Singh (shemant) Cc: Lee, Yiu; Francis Dupont; v6ops@ietf.org Subject: Re: [v6ops] small concern about CPE advanced requirements >The text makes more sense. As to the requirement - I'll leave that question to others. If one has a public IPv4 address configured on the WAN interface of the IPv6 CE router, the SP has native IPv4 service available and thus why would the CE use DS-Lite which encapsulates IPv4 in IPv6. That is why this requirement came about. Hemant=20 From joelja@bogus.com Fri Mar 4 13:50:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD153A6A3A for ; Fri, 4 Mar 2011 13:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.939 X-Spam-Level: X-Spam-Status: No, score=-101.939 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+J3vZenxgtn for ; Fri, 4 Mar 2011 13:50:26 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 86A913A6A2D for ; Fri, 4 Mar 2011 13:50:25 -0800 (PST) Received: from 23173jjaeggli.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p24LpUlk027471 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 4 Mar 2011 21:51:31 GMT (envelope-from joelja@bogus.com) Message-ID: <4D715EDD.40403@bogus.com> Date: Fri, 04 Mar 2011 13:51:25 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Fred Baker References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> In-Reply-To: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Fri, 04 Mar 2011 21:51:32 +0000 (UTC) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 21:50:27 -0000 Just a reminder this working-group last call ends to the 10th. joel On 2/24/11 5:18 AM, Fred Baker wrote: > This is to initiate a two week working group last call of > draft-ietf-v6ops-multihoming-without-nat66. Please read it now. If > you find nits (spelling errors, minor suggested wording changes, > etc), comment to the authors; if you find greater issues, such as > disagreeing with a statement or finding additional issues that need > to be addressed, please post your comments to the list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. _______________________________________________ > v6ops mailing list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Fri Mar 4 13:56:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75FE3A6A2D for ; Fri, 4 Mar 2011 13:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqd3vQSSLHym for ; Fri, 4 Mar 2011 13:56:30 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 2DD8B3A6A42 for ; Fri, 4 Mar 2011 13:56:29 -0800 (PST) Received: from 23173jjaeggli.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p24LvcZB027767 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 4 Mar 2011 21:57:38 GMT (envelope-from joelja@bogus.com) Message-ID: <4D71604C.7020609@bogus.com> Date: Fri, 04 Mar 2011 13:57:32 -0800 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Danny McPherson References: <4D656DE2.8090903@dougbarton.us> <4D703027.8090902@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Fri, 04 Mar 2011 21:57:39 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 21:56:31 -0000 Kicked it into the publication requested queue on tuesday. If necessary I'll rubberband this note to a brick and toss it through the IESG's window. thanks joel On 3/3/11 7:55 PM, Danny McPherson wrote: > > A belated support from me to this WG LC as well, I think it's useful to > document this and provided Jason feedback on earlier versions of > the draft. > > FWIW, I've already personally observed the awareness that this draft > and periphery discussions on this issue from Yahoo!, Google, and > others generated and believe the operational community is collectively > better informed as a result. > > Publication in v6OPs as an Informational RFC seems quite sensible > to me, and I'm also happy to see such a spectrum of operators weigh in > on this very discussion. > > -danny > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Internet-Drafts@ietf.org Sat Mar 5 10:45:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BF23A6AA4; Sat, 5 Mar 2011 10:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26M6bCDEq-ZM; Sat, 5 Mar 2011 10:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9A13A6946; Sat, 5 Mar 2011 10:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110305184502.18531.25548.idtracker@localhost> Date: Sat, 05 Mar 2011 10:45:02 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 18:45:02 -0000 --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 : Advanced Requirements for IPv6 Customer Edge Routers Author(s) : H. Singh, et al. Filename : draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Pages : 16 Date : 2011-03-05 This document continues the work undertaken by the IPv6 CE Router Phase I work in the IETF v6ops Working Group. Advanced requirements or Phase II work is covered in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-05104444.I-D@ietf.org> --NextPart-- From swmike@swm.pp.se Sun Mar 6 04:18:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399DB3A677E for ; Sun, 6 Mar 2011 04:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb-OyIe16-av for ; Sun, 6 Mar 2011 04:18:00 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 8532B3A676A for ; Sun, 6 Mar 2011 04:17:58 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0DF709F; Sun, 6 Mar 2011 13:19:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0CC959C for ; Sun, 6 Mar 2011 13:19:09 +0100 (CET) Date: Sun, 6 Mar 2011 13:19:09 +0100 (CET) From: Mikael Abrahamsson To: v6ops@ietf.org Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [v6ops] would like feedback on behaviour seen in the field X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 12:18:01 -0000 Hi. I just did some testing of IPv6 behaviour of a home routing scenario and how units behaved. The units used was a Win7 Home premium SP1, and a Cisco 7200 router running IOS 15.0(1)M4. I will call them C1 and W1. C1 has a IPv6 /48 and an IPv4 /28 routed to itself and has on the local interface the IPv4 /28 and DHCP, and for IPv6 it has a /64 with M and O bit set, plus DHCPv6 server for handing out addresses. It is configured to do DHCPv6-PD with /64 prefix. The Win7 machine is running with (afaik) default settings for Teredo and 6to4 and since it has a globally unique IPv4 address, both are active. Internet - C1 - LAN1 - W1 - LAN2 - Linux machine (ubuntu 10.10) The Win7 machine boots up, does SLAAC with EUI64 address on LAN1, does DHCPv6 and gets one address from the Cisco router, and also creates a privacy address for itself using SLAAC, for a total of 3 IPv6 addresses. It also gets one IPv4 address using DHCP, plus gets DNS servers etc for both IPv4 and IPv6. This is all fine and dandy. Now, I turn on Internet Connection sharing on the Win7 machine. It now does DHCPv6-PD on LAN1 and gets a globally unique /64 out of the /56 PD pool of /64s I have assigned the cisco router to hand out from the /48 available. It also creates a 192.168.x.y/24 on LAN2 and starts running a DHCP server and hands out these and does v4-NAT. What happens is that it actually hands out a 6to4 based prefix on LAN2 to the linux machine, and all IPv6 traffic (I have to force it to go to an AAAA only address) uses 6to4 prefix. This seems weird. Fine, I disable teredo and 6to4 manually on W1 using "netsh", but the 6to4 based address is still in the linux machine, so when I turned off 6to4, I guess no 0 lifetime RA was sent for the 6to4 prefix on LAN2 (or if it was, linux didn't honour it). I clear these addresses manually on the linux machine, unplug/replug the LAN2 cable and now IPv6 works properly with the globally unique addresses from the /64 PD prefix. I then try to change the PD pool handout prefix size to /60 on the Cisco. This doesn't work, because there are things already handed out from the pool, so I have to clear it first and then change to /60 (from the same /56). This means the static /64 route pointing to the W1 machine on LAN1 is now gone and the PD binding is cleared. W1 is unaware of this. Is there a mechanism for telling it that should be used? I then unplug the windows machine LAN1 cable and plug it in again. I see the /64 in the routing table, but nothing on the Cisco. I guess W1 doesn't do any kind of refresh on the DHCPv6-PD prefix when it brings up the LAN interface. I try reboot, same thing. This seems to be the same way for stateful DHCPv6 addressing as well, no refresh (I am not 100% sure here though). I'm used to DHCPv4 being refreshed upon connect, is this different in DHCPv6? Oki, anyhow, I disable ICS and enable it again to make the /64 go away, W1 aquires a /60 from the Cisco router and hands out a different /64 on LAN2 within this /60. Fine. The only problem is that it doesn't null route the /60 internally, so this causes pingpong routing for the other 15 /64s in the /60. This seems undesireable. I see quite a lot of operational problems in the above text and I'd like some input on whether the behaviour seen is actually violating some RFCs and if they're doing things not mentioned in RFCs at all, that would be good as well because then we can improve the standards. I did all of this in approximately 45-60 minutes and I had some more problems than I described, but those problems are out of scope for v6ops. -- Mikael Abrahamsson email: swmike@swm.pp.se From oej@edvina.net Mon Mar 7 01:39:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A773A693D for ; Mon, 7 Mar 2011 01:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WI6RlyfBo4Vv for ; Mon, 7 Mar 2011 01:39:09 -0800 (PST) Received: from ns.webway.se (ns.webway.se [87.96.134.125]) by core3.amsl.com (Postfix) with ESMTP id 393BE3A6827 for ; Mon, 7 Mar 2011 01:39:08 -0800 (PST) Received: from [192.168.40.17] (unknown [192.168.40.17]) by ns.webway.se (Postfix) with ESMTP id 6392128426 for ; Mon, 7 Mar 2011 10:40:21 +0100 (CET) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Mar 2011 10:40:20 +0100 Message-Id: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 09:39:10 -0000 Hi! Has anyone considered the issues covered in the happy-eyeballs draft for = SIP? A 19 or 32 second time out when placing a call is not a good user = experience... I think this applies to SIP over TCP, and possibly also = needs to be handled for UDP. I don't see this handled in the draft for IPv6 transition in the Session = Initiation Protocol (soon-to-be RFC 6157) Seems like the scope of the happy eyeballs draft is HTTP, so the = question is if this should be expanded or if we need other drafts for = other protocols. Regards, /Olle Ref: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07= From mohamed.boucadair@orange-ftgroup.com Mon Mar 7 04:50:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C7828C108 for ; Mon, 7 Mar 2011 04:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7QG9gqvHJ1g for ; Mon, 7 Mar 2011 04:50:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 0880F28C101 for ; Mon, 7 Mar 2011 04:50:37 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 6315EC01DD; Mon, 7 Mar 2011 13:51:50 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 3E16F158060; Mon, 7 Mar 2011 13:51:50 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 7 Mar 2011 13:51:50 +0100 From: To: "Olle E. Johansson" , "v6ops@ietf.org" Date: Mon, 7 Mar 2011 13:51:48 +0100 Thread-Topic: [v6ops] Happy Eyeballs and SIP Thread-Index: Acvcq7O26d3b4A+4Tp6GfIW3lGUMSQAGeMOw Message-ID: <24436_1299502310_4D74D4E6_24436_185484_1_94C682931C08B048B7A8645303FDC9F33C4DA50BCA@PUEXCB1B.nanterre.francetelecom.fr> References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> In-Reply-To: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.7.120320 Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 12:50:40 -0000 Dear Olle, For the SIP case, if you don't need connectivity checks (e.g., closed netwo= rks, which is in France the majority of SIP traffic) you can just use the A= LTC attribute defined in http://tools.ietf.org/html/draft-boucadair-mmusic-= altc-01. In case connectivity checks are needed, a variant of the happy eyeballs for= SIP (called Happy Eardrums) has been proposed in http://tools.ietf.org/htm= l/draft-wing-dispatch-v6-migration-00 but still you need to be sure you IPv= 4 connectivity is working ;-). Cheers, Med =20 -----Message d'origine----- De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de O= lle E. Johansson Envoy=E9 : lundi 7 mars 2011 10:40 =C0 : v6ops@ietf.org Objet : [v6ops] Happy Eyeballs and SIP Hi! Has anyone considered the issues covered in the happy-eyeballs draft for SI= P? A 19 or 32 second time out when placing a call is not a good user experienc= e... I think this applies to SIP over TCP, and possibly also needs to be ha= ndled for UDP. I don't see this handled in the draft for IPv6 transition in the Session In= itiation Protocol (soon-to-be RFC 6157) Seems like the scope of the happy eyeballs draft is HTTP, so the question i= s if this should be expanded or if we need other drafts for other protocols. Regards, /Olle Ref: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From ichiroumakino@gmail.com Mon Mar 7 06:20:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C123A69A6 for ; Mon, 7 Mar 2011 06:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOXZIs9beWsL for ; Mon, 7 Mar 2011 06:20:02 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 2F3283A696B for ; Mon, 7 Mar 2011 06:20:02 -0800 (PST) Received: by eye13 with SMTP id 13so1716312eye.31 for ; Mon, 07 Mar 2011 06:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=V6JUUHl2oxHmN/2/2ZNk2fLCgshBZYmBcvuqU0rQeQw=; b=VB5k6tXdJv7ksT1qq9SHXlUrtQdx6QZ75TES684ITLs9rAmvmlKxmDfE2+XABVqHtv d23sJqqVIpWbo2OSQG9omjlJ6//BcXBNmlHOsiXbg740GUnBIKxYGP6WRjG04WpNPIhP 6xptRC56tb8lxKLLNmw8xCS16kvjB6+WkEKOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=MMwc5eWSOh3m2AhvVO0a7PyC2s7bCReGtLVf5c6ZLSJ5YgqyBoc7i7LOh4A+abYd/O WfIXiElxYrze6XXsYZTlse2j7nkbcRyEoCuddUDEEC9F/UrDhg4kI0EQm5HPCll0FCK7 XBAUm1CCH6A7enRB4zKpfTiZzzltR3fMBm53I= Received: by 10.216.240.141 with SMTP id e13mr3341530wer.105.1299507674651; Mon, 07 Mar 2011 06:21:14 -0800 (PST) Received: from dhcp-osl-vl300-64-103-53-114.cisco.com (dhcp-osl-vl300-64-103-53-114.cisco.com [64.103.53.114]) by mx.google.com with ESMTPS id g8sm1296194wej.47.2011.03.07.06.21.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2011 06:21:13 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 7 Mar 2011 15:21:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6F1B36ED-31A9-48A5-A25B-BEFC8AA1ABA2@employees.org> References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] would like feedback on behaviour seen in the field X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 14:20:03 -0000 Mikael, > I just did some testing of IPv6 behaviour of a home routing scenario = and how units behaved. The units used was a Win7 Home premium SP1, and a = Cisco 7200 router running IOS 15.0(1)M4. >=20 > I will call them C1 and W1. >=20 > C1 has a IPv6 /48 and an IPv4 /28 routed to itself and has on the = local interface the IPv4 /28 and DHCP, and for IPv6 it has a /64 with M = and O bit set, plus DHCPv6 server for handing out addresses. It is = configured to do DHCPv6-PD with /64 prefix. The Win7 machine is running = with (afaik) default settings for Teredo and 6to4 and since it has a = globally unique IPv4 address, both are active. >=20 > Internet - C1 - LAN1 - W1 - LAN2 - Linux machine (ubuntu 10.10) >=20 > The Win7 machine boots up, does SLAAC with EUI64 address on LAN1, does = DHCPv6 and gets one address from the Cisco router, and also creates a = privacy address for itself using SLAAC, for a total of 3 IPv6 addresses. = It also gets one IPv4 address using DHCP, plus gets DNS servers etc for = both IPv4 and IPv6. This is all fine and dandy. >=20 > Now, I turn on Internet Connection sharing on the Win7 machine. It now = does DHCPv6-PD on LAN1 and gets a globally unique /64 out of the /56 PD = pool of /64s I have assigned the cisco router to hand out from the /48 = available. It also creates a 192.168.x.y/24 on LAN2 and starts running a = DHCP server and hands out these and does v4-NAT. >=20 > What happens is that it actually hands out a 6to4 based prefix on LAN2 = to the linux machine, and all IPv6 traffic (I have to force it to go to = an AAAA only address) uses 6to4 prefix. This seems weird. >=20 > Fine, I disable teredo and 6to4 manually on W1 using "netsh", but the = 6to4 based address is still in the linux machine, so when I turned off = 6to4, I guess no 0 lifetime RA was sent for the 6to4 prefix on LAN2 (or = if it was, linux didn't honour it). I clear these addresses manually on = the linux machine, unplug/replug the LAN2 cable and now IPv6 works = properly with the globally unique addresses from the /64 PD prefix. >=20 > I then try to change the PD pool handout prefix size to /60 on the = Cisco. This doesn't work, because there are things already handed out = from the pool, so I have to clear it first and then change to /60 (from = the same /56). This means the static /64 route pointing to the W1 = machine on LAN1 is now gone and the PD binding is cleared. W1 is unaware = of this. Is there a mechanism for telling it that should be used? >=20 > I then unplug the windows machine LAN1 cable and plug it in again. I = see the /64 in the routing table, but nothing on the Cisco. I guess W1 = doesn't do any kind of refresh on the DHCPv6-PD prefix when it brings up = the LAN interface. I try reboot, same thing. This seems to be the same = way for stateful DHCPv6 addressing as well, no refresh (I am not 100% = sure here though). I'm used to DHCPv4 being refreshed upon connect, is = this different in DHCPv6? >=20 > Oki, anyhow, I disable ICS and enable it again to make the /64 go = away, W1 aquires a /60 from the Cisco router and hands out a different = /64 on LAN2 within this /60. Fine. The only problem is that it doesn't = null route the /60 internally, so this causes pingpong routing for the = other 15 /64s in the /60. This seems undesireable. >=20 > I see quite a lot of operational problems in the above text and I'd = like some input on whether the behaviour seen is actually violating some = RFCs and if they're doing things not mentioned in RFCs at all, that = would be good as well because then we can improve the standards. >=20 > I did all of this in approximately 45-60 minutes and I had some more = problems than I described, but those problems are out of scope for = v6ops. at least it appears to violate RFC3633 and = http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09 for the lack of verification that the binding is correct when connecting = the cable to the delegating router as well as the lack of a blackhole = route. with regards to the sending of RA with lifetime of 0 on reconfiguration, = the default to 6to4 and the lack of a DHCPv6 reconfigure message on = changing the pool size. well, that's implementation specific, but it = clearly creates operational problems when implemented as you have shown = above. cheers, Ole= From Ted.Lemon@nominum.com Mon Mar 7 07:02:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17AF23A69A9 for ; Mon, 7 Mar 2011 07:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.899 X-Spam-Level: X-Spam-Status: No, score=-105.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxhDQG9LKpbE for ; Mon, 7 Mar 2011 07:02:20 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 2804B3A67E1 for ; Mon, 7 Mar 2011 07:02:20 -0800 (PST) Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTXTzxIvV5vV4MQBzKyRHZQpWkMTjfmyK@postini.com; Mon, 07 Mar 2011 07:03:34 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8E9BC1B8627 for ; Mon, 7 Mar 2011 07:03:32 -0800 (PST) Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 501E819006D; Mon, 7 Mar 2011 07:03:32 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from [10.1.10.12] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 7 Mar 2011 07:03:32 -0800 MIME-Version: 1.0 (Apple Message framework v1203) Content-Type: text/plain; charset="windows-1252" From: Ted Lemon In-Reply-To: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> Date: Mon, 7 Mar 2011 10:03:29 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> To: Olle E.Johansson X-Mailer: Apple Mail (2.1203) Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 15:02:21 -0000 On Mar 7, 2011, at 4:40 AM, Olle E. Johansson wrote: > A 19 or 32 second time out when placing a call is not a good user = experience... I think this applies to SIP over TCP, and possibly also = needs to be handled for UDP. A 30-second timeout when starting an http connection isn't a good user = experience either, so it could be argued that your objection is not = SIP-specific=85 :) From jav@sics.se Mon Mar 7 07:36:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77DFF3A67D3 for ; Mon, 7 Mar 2011 07:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqqerD9hDoDR for ; Mon, 7 Mar 2011 07:36:02 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 537653A67E7 for ; Mon, 7 Mar 2011 07:36:02 -0800 (PST) Received: from [192.168.10.102] (h206n3-haes-a12.ias.bredband.telia.com [78.72.156.206]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id A408240005; Mon, 7 Mar 2011 16:37:14 +0100 (CET) From: Javier Ubillos To: Ted Lemon In-Reply-To: References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Mar 2011 16:37:00 +0100 Message-ID: <1299512220.3225.25.camel@dab> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 15:36:03 -0000 On Mon, 2011-03-07 at 10:03 -0500, Ted Lemon wrote: > On Mar 7, 2011, at 4:40 AM, Olle E. Johansson wrote: > > A 19 or 32 second time out when placing a call is not a good user experience... I think this applies to SIP over TCP, and possibly also needs to be handled for UDP. > > A 30-second timeout when starting an http connection isn't a good user experience either, so it could be argued that your objection is not SIP-specific… :) > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops Why are you guys discussing delays over 4s? The draft (IIRC) states 400ms as a maximum delay. // Javier From dwing@cisco.com Mon Mar 7 07:40:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B603D3A6906 for ; Mon, 7 Mar 2011 07:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.271 X-Spam-Level: X-Spam-Status: No, score=-110.271 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZU-HYZwporq for ; Mon, 7 Mar 2011 07:40:57 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8F5C63A67EE for ; Mon, 7 Mar 2011 07:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1811; q=dns/txt; s=iport; t=1299512531; x=1300722131; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=JkuJB9rZ+R7zkegH3+2ILTpjMgljW8Fxr3mwcwoEiPc=; b=UlyRx4OuY1NdUiV4vlyWrBc01dxhVxDrMd9F6N/o86MX+uWHQzlSzYiO +ccNtJ2Z3NaM8x9GXMrMs2GZklvtau3rZzdRvwCAY60m5nEUw8T0qsQpp xPAL8wXdPy7UbFh4Kvy3UMTFhKpxcdMUb0LzfZP61PrYpQgGUlvPmDIEa w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoBAFqLdE2rR7Hu/2dsb2JhbACYDYFljGJ0ol+bQ4ViBIUc X-IronPort-AV: E=Sophos;i="4.62,277,1297036800"; d="scan'208";a="341498328" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 07 Mar 2011 15:37:21 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p27FbLe5002130; Mon, 7 Mar 2011 15:37:21 GMT From: "Dan Wing" To: "'Olle E. Johansson'" , References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> In-Reply-To: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> Date: Mon, 7 Mar 2011 07:37:21 -0800 Message-ID: <117401cbdcdd$8c9ccac0$a5d66040$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvcq7XuZ+NaVaOrSXu8JEopopSxOAAMFwIQ Content-Language: en-us Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 15:40:58 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Olle E. Johansson > Sent: Monday, March 07, 2011 1:40 AM > To: v6ops@ietf.org > Subject: [v6ops] Happy Eyeballs and SIP > > Hi! > > Has anyone considered the issues covered in the happy-eyeballs draft > for SIP? > > A 19 or 32 second time out when placing a call is not a good user > experience... I think this applies to SIP over TCP, and possibly also > needs to be handled for UDP. > I don't see this handled in the draft for IPv6 transition in the > Session Initiation Protocol (soon-to-be RFC 6157) > > Seems like the scope of the happy eyeballs draft is HTTP, so the > question is if this should be expanded or if we need other drafts for > other protocols. ICE (RFC5245) resolves the problem perfectly, and is the plan-of-record for how to support the transition to IPv6 for SIP (draft-ietf-sipping-v6-transition). ICE does connectivity checks, so it figures out if IPv4 or IPv6 (or UDP, or TCP) is working between two peers, and uses that path. ICE can be performed while the phone is ringing, so does not delay call set up. ICE was one of the inspirations for Happy Eyeballs. There is resistance to ICE because of (a) its complexity and (b) a perception that "IPv6 works fine on my network", which has fostered the creation of several other solutions, including an idea we nicknamed "Happy Eardrums", draft-wing-dispatch-v6-migration, which we have since abandoned. ICE does more, and it does a better job. -d > Regards, > /Olle > > Ref: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Mon Mar 7 10:03:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47373A67EC for ; Mon, 7 Mar 2011 10:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.428 X-Spam-Level: X-Spam-Status: No, score=-110.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YtblmeW8ik3 for ; Mon, 7 Mar 2011 10:03:22 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 597A228C0E2 for ; Mon, 7 Mar 2011 10:03:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=6522; q=dns/txt; s=iport; t=1299521076; x=1300730676; h=from:reply-to:subject:date:message-id:to:mime-version; bh=MoQaoTL8BINMDLSbyOaUsPwQ+bqN17mwaiEshRUoER0=; b=e7EpG+Z9CpssHS/uukjtNI9qWP+H4NMiA9erTN9qPtQMr2gIOfX8hXai LP3Lgq8fz2ZaCH13XywSjz+i0YOOWUswaFY43NVubUIJkRMDf6aCVItAk UdHgYQ2aa9bGMn2IEB2h/LsIeGENb0i93kKKGRwrWWC9olYl56sewI7EM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FAKSsdE2rR7Ht/2dsb2JhbACCT5t8AYgCdKJYm2GFYgSFHIcU X-IronPort-AV: E=Sophos;i="4.62,278,1297036800"; d="scan'208,217";a="412394021" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 07 Mar 2011 18:04:36 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p27I3u83008219 for ; Mon, 7 Mar 2011 18:04:35 GMT From: Fred Baker Content-Type: multipart/alternative; boundary=Apple-Mail-275--908671380 Date: Mon, 7 Mar 2011 10:04:35 -0800 Message-Id: <6DE401E6-B06F-4A21-8721-53179C706A9C@cisco.com> To: IPv6 Ops WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [v6ops] IPv6 Operations - IETF 80 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: V6ops Chairs List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 18:03:23 -0000 --Apple-Mail-275--908671380 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have just posted a draft working group agenda. Please advise of any = changes needed. I will need slides from each presenter by 27 March, for = posting at the IETF meeting materials site, and for the proceedings. IPv6 Operations - IETF 80 Thursday 31 March, 9:00-11:30 Agenda bashing =20 Happy Eyeballs Testing Report Teemu Savolainen Happy Eyeballs Implementation Report Simon Perreault Operational Experience with Dual Stack Servers Geoff Huston Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts 3-Mar-11, IPv6 Multihoming without Network Address Translation 6-Dec-10, Advanced Requirements for IPv6 Customer Edge Routers 5-Mar-11, 6to4 Provider Managed Tunnels 1-Feb-11, Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to = Historic status 7-Feb-11, Thursday 31 March, 17:40-19:40 Advisory Guidelines for 6to4 Deployment 23-Feb-11, Considerations for Stateless Translation (IVI/dIVI) in Large SP Network 6-Mar-11, LAFT6: Lightweight address family transition for IPv6 7-Mar-11, Experience from NAT64 applications 7-Mar-11, IPv6 in 3GPP Evolved Packet System 9-Feb-11, RADIUS issues in IPv6 deployments 9-Feb-11, Solution Model of Source Address Tracing for Carrier Grade NAT (CGN) 16-Feb-11, --Apple-Mail-275--908671380 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii IPv6 Operations - IETF 80
I have just posted a draft working group agenda. Please advise of any changes needed. I will need slides from each presenter by 27 March, for posting at the IETF meeting materials site, and for the proceedings.

IPv6 Operations - IETF 80

Thursday 31 March, 9:00-11:30

Agenda bashing
 
Happy Eyeballs Testing Report
Teemu Savolainen
Happy Eyeballs Implementation Report
Simon Perreault
Operational Experience with Dual Stack Servers
Geoff Huston
Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts
3-Mar-11, <draft-ietf-v6ops-happy-eyeballs-00.txt>
IPv6 Multihoming without Network Address Translation
6-Dec-10, <draft-ietf-v6ops-multihoming-without-nat66-00.txt>
Advanced Requirements for IPv6 Customer Edge Routers
5-Mar-11, <draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt>
6to4 Provider Managed Tunnels
1-Feb-11, <draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-01.txt>
Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status
7-Feb-11, <draft-troan-v6ops-6to4-to-historic-00.txt>

Thursday 31 March, 17:40-19:40

Advisory Guidelines for 6to4 Deployment
23-Feb-11, <draft-carpenter-v6ops-6to4-teredo-advisory-02.txt>
Considerations for Stateless Translation (IVI/dIVI) in Large SP Network
6-Mar-11, <draft-sunq-v6ops-ivi-sp-02.txt>
LAFT6: Lightweight address family transition for IPv6
7-Mar-11, <draft-sun-v6ops-laft6-00.txt>
Experience from NAT64 applications
7-Mar-11, <draft-tan-v6ops-nat64-experiences-00.txt>
IPv6 in 3GPP Evolved Packet System
9-Feb-11, <draft-korhonen-v6ops-3gpp-eps-06.txt>
RADIUS issues in IPv6 deployments
9-Feb-11, <draft-hu-v6ops-radius-issues-ipv6-00.txt>
Solution Model of Source Address Tracing for Carrier Grade NAT (CGN)
16-Feb-11, <draft-zhang-v6ops-cgn-source-trace-00.txt>

--Apple-Mail-275--908671380-- From oej@edvina.net Mon Mar 7 11:57:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16B83A635F for ; Mon, 7 Mar 2011 11:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7r0Ne6QIjOWh for ; Mon, 7 Mar 2011 11:57:44 -0800 (PST) Received: from smtp6.webway.se (smtp2.webway.se [87.96.134.128]) by core3.amsl.com (Postfix) with ESMTP id 8E8803A6407 for ; Mon, 7 Mar 2011 11:57:42 -0800 (PST) Received: from [192.168.40.12] (ns.webway.se [87.96.134.125]) by smtp6.webway.se (Postfix) with ESMTPA id EE067552F5A; Mon, 7 Mar 2011 19:58:54 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <24436_1299502310_4D74D4E6_24436_185484_1_94C682931C08B048B7A8645303FDC9F33C4DA50BCA@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 7 Mar 2011 20:58:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D3BB91A-B173-45D1-B891-71FF72DB503E@edvina.net> References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <24436_1299502310_4D74D4E6_24436_185484_1_94C682931C08B048B7A8645303FDC9F33C4DA50BCA@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 19:57:45 -0000 7 mar 2011 kl. 13.51 skrev : > Dear Olle, >=20 > For the SIP case, if you don't need connectivity checks (e.g., closed = networks, which is in France the majority of SIP traffic) you can just = use the ALTC attribute defined in = http://tools.ietf.org/html/draft-boucadair-mmusic-altc-01. >=20 > In case connectivity checks are needed, a variant of the happy = eyeballs for SIP (called Happy Eardrums) has been proposed in = http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 but still = you need to be sure you IPv4 connectivity is working ;-). >=20 Thanks for the reply! I will look into these documents to learn more. If = I have any questions, is it ok to mail you? Best regards, /Olle > Cheers, > Med >=20 >=20 > -----Message d'origine----- > De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part = de Olle E. Johansson > Envoy=E9 : lundi 7 mars 2011 10:40 > =C0 : v6ops@ietf.org > Objet : [v6ops] Happy Eyeballs and SIP >=20 > Hi! >=20 > Has anyone considered the issues covered in the happy-eyeballs draft = for SIP? >=20 > A 19 or 32 second time out when placing a call is not a good user = experience... I think this applies to SIP over TCP, and possibly also = needs to be handled for UDP. > I don't see this handled in the draft for IPv6 transition in the = Session Initiation Protocol (soon-to-be RFC 6157) >=20 > Seems like the scope of the happy eyeballs draft is HTTP, so the = question is if this should be expanded or if we need other drafts for = other protocols. >=20 > Regards, > /Olle >=20 > Ref: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > = **************************************************************************= ****** > IMPORTANT.Les informations contenues dans ce message electronique y = compris les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) = destinataire(s) mentionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas = destine, veuillez immediatement le signaler a l expediteur et effacer = ce message=20 > et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite = notamment s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de = tout virus. >=20 > IMPORTANT.This e-mail message and any attachments are strictly = confidential and may be protected by law. This message is > intended only for the named recipient(s) above. > If you have received this message in error, or are not the named = recipient(s), please immediately notify the sender and delete this = e-mail message. > Any unauthorized view, usage or disclosure ofthis message is = prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall = not be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > = **************************************************************************= ****** --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From oej@edvina.net Mon Mar 7 12:05:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EDC3A677E for ; Mon, 7 Mar 2011 12:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzYVpNWdAXPJ for ; Mon, 7 Mar 2011 12:05:09 -0800 (PST) Received: from ns.webway.se (ns.webway.se [87.96.134.125]) by core3.amsl.com (Postfix) with ESMTP id D2EFA3A6407 for ; Mon, 7 Mar 2011 12:04:59 -0800 (PST) Received: from [192.168.40.12] (unknown [192.168.40.12]) by ns.webway.se (Postfix) with ESMTP id E0CC32841F; Mon, 7 Mar 2011 21:06:11 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <117401cbdcdd$8c9ccac0$a5d66040$@com> Date: Mon, 7 Mar 2011 21:06:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E7989D3-B865-4D5A-ACE9-A74567BAD065@edvina.net> References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <117401cbdcdd$8c9ccac0$a5d66040$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 20:05:10 -0000 7 mar 2011 kl. 16.37 skrev Dan Wing: >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >> Of Olle E. Johansson >> Sent: Monday, March 07, 2011 1:40 AM >> To: v6ops@ietf.org >> Subject: [v6ops] Happy Eyeballs and SIP >>=20 >> Hi! >>=20 >> Has anyone considered the issues covered in the happy-eyeballs draft >> for SIP? >>=20 >> A 19 or 32 second time out when placing a call is not a good user >> experience... I think this applies to SIP over TCP, and possibly also >> needs to be handled for UDP. >> I don't see this handled in the draft for IPv6 transition in the >> Session Initiation Protocol (soon-to-be RFC 6157) >>=20 >> Seems like the scope of the happy eyeballs draft is HTTP, so the >> question is if this should be expanded or if we need other drafts for >> other protocols. >=20 > ICE (RFC5245) resolves the problem perfectly, and is the = plan-of-record for > how to support the transition to IPv6 for SIP > (draft-ietf-sipping-v6-transition). ICE does connectivity checks, so = it > figures out if IPv4 or IPv6 (or UDP, or TCP) is working between two = peers, > and uses that path. ICE can be performed while the phone is ringing, = so > does not delay call set up. ICE was one of the inspirations for Happy > Eyeballs. >=20 > There is resistance to ICE because of (a) its complexity and (b) a > perception that "IPv6 works fine on my network", which has fostered = the > creation of several other solutions, including an idea we nicknamed = "Happy > Eardrums", draft-wing-dispatch-v6-migration, which we have since = abandoned. > ICE does more, and it does a better job. >=20 Thanks for the feedback. Please tell me how Ice solves the issue of a phone calling a SIP domain = with both A and AAAA records for the first selected host. The proxy or the UA will try to contact first over one connection, time = out after T1*64 and then maybe retry. As far as I know ICE handles media, but not the signalling. But I may be = misunderstanding something. Cheers, /O From simon.perreault@viagenie.ca Mon Mar 7 12:24:56 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619B33A676A for ; Mon, 7 Mar 2011 12:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y52zYKKJY5M for ; Mon, 7 Mar 2011 12:24:53 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 9766D3A65A6 for ; Mon, 7 Mar 2011 12:24:52 -0800 (PST) Received: from balaise.nomis80.org (unknown [IPv6:2001:470:1f11:783:218:f3ff:fe3d:1af4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E20B721C25; Mon, 7 Mar 2011 15:26:03 -0500 (EST) Message-ID: <4D753F5B.5000601@viagenie.ca> Date: Mon, 07 Mar 2011 15:26:03 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Olle E. Johansson" References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <117401cbdcdd$8c9ccac0$a5d66040$@com> <2E7989D3-B865-4D5A-ACE9-A74567BAD065@edvina.net> In-Reply-To: <2E7989D3-B865-4D5A-ACE9-A74567BAD065@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 20:24:56 -0000 On 03/07/2011 03:06 PM, Olle E. Johansson wrote: > Please tell me how Ice solves the issue of a phone calling a SIP domain with both A and AAAA records for the first selected host. > The proxy or the UA will try to contact first over one connection, time out after T1*64 and then maybe retry. > > As far as I know ICE handles media, but not the signalling. But I may be misunderstanding something. You're right. Dual-stack for signalling is handled by sip-outbound. This is a gold mine: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From fred@cisco.com Mon Mar 7 13:40:28 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1EEE3A6844 for ; Mon, 7 Mar 2011 13:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.813 X-Spam-Level: X-Spam-Status: No, score=-109.813 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3hJwp3rJfaN for ; Mon, 7 Mar 2011 13:40:27 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B71D43A682C for ; Mon, 7 Mar 2011 13:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1305; q=dns/txt; s=iport; t=1299534102; x=1300743702; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=ZDthKWMQmxTzTW9wzQMmouUDX1RbfnwkUQkg9Qt9yQY=; b=UEaxVLk0oUKFE3wY8/A+03On94uGJJb79c0x+E4OVUG26QskLuEyWgi0 9hJB6PMANPUKOOPUqzuqlLkwja/duKXghA9ABMgjdSeJk/yBP7rHMt8u+ //0MxdA8JH77PdLmXeLCrNTHdgwICMBUrBWPB5vdgbeAVW1VsB9ad9bYt c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEPfdE2rR7H+/2dsb2JhbACmV3SiQ5wChWIEhRyHFA X-IronPort-AV: E=Sophos;i="4.62,279,1297036800"; d="scan'208";a="272089615" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 07 Mar 2011 21:41:41 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p27Lff4D025947 for ; Mon, 7 Mar 2011 21:41:41 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D6FE6F5.2040200@gmail.com> Date: Mon, 7 Mar 2011 13:41:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456B774BC0EED@EMBX01-WF.jnpr.net> <4D6EA100.1060809@gmail.com> <47C53154-8EEF-47AB-9A7C-8E5BB76B9899@cisco.com> <4D6FE6F5.2040200@gmail.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1082) Subject: [v6ops] Status of draft-ietf-v6ops-v4v6tran-framework X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 21:40:28 -0000 The chairs and Ron Bonica had a brief discussion about=20 http://tools.ietf.org/html/draft-ietf-v6ops-v4v6tran-framework "Framework for IP Version Transition Scenarios", Brian Carpenter, = Sheng Jiang, Victor Kuarsingh, 1-Feb-11 In short, the working group agreed to take the draft on as a working = group document and had a last call, and I sent it to Ron. However, the = other documents that it suggests were discussed at IETF-79 and panned, = and have not been updated. On that basis, Ron questions the utility of = publishing the framework.=20 What we agreed is that the Framework ID will be treated as a short term = agreement within the WG, binding for the period of time that the WG is = producing transition documents. If the WG sees a subsequent transition = document that does not abide by the guideline, if will fix the = subsequent document before sending it on. When the last transition = document has been published, we will let the Framework ID expire. Because the Framework ID is a short term agreement within the WG, it = doesn't require IETF consensus. It requires WG consensus only (which it = already has). Furthermore, the document might not be very interesting to = anyone outside of the WG. Ron From oej@edvina.net Mon Mar 7 13:47:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52C628C0F4 for ; Mon, 7 Mar 2011 13:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU+ojQobgyzY for ; Mon, 7 Mar 2011 13:47:58 -0800 (PST) Received: from ns.webway.se (ns.webway.se [87.96.134.125]) by core3.amsl.com (Postfix) with ESMTP id 011213A6870 for ; Mon, 7 Mar 2011 13:47:58 -0800 (PST) Received: from [192.168.40.12] (unknown [192.168.40.12]) by ns.webway.se (Postfix) with ESMTP id D9AAB28445; Mon, 7 Mar 2011 22:49:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4D753F5B.5000601@viagenie.ca> Date: Mon, 7 Mar 2011 22:48:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <49224017-DB62-472C-BC5A-F5A5E163AAA1@edvina.net> References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <117401cbdcdd$8c9ccac0$a5d66040$@com> <2E7989D3-B865-4D5A-ACE9-A74567BAD065@edvina.net> <4D753F5B.5000601@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs/Eardrums and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 21:47:59 -0000 7 mar 2011 kl. 21.26 skrev Simon Perreault: > On 03/07/2011 03:06 PM, Olle E. Johansson wrote: >> Please tell me how Ice solves the issue of a phone calling a SIP = domain with both A and AAAA records for the first selected host. >> The proxy or the UA will try to contact first over one connection, = time out after T1*64 and then maybe retry. >>=20 >> As far as I know ICE handles media, but not the signalling. But I may = be misunderstanding something. >=20 > You're right. Dual-stack for signalling is handled by sip-outbound. >=20 > This is a gold mine: > http://tools.ietf.org/html/draft-ietf-sipping-v6-transition SIP-outbound is between the UA and the first proxy/b2bua, right? So if Edvina.net's proxy calls viagenie's proxy - can't we stumble on = the same issue there? My proxy can't handle open connections to all proxys I might be able to = call... ;-) Sorry for being persistant, but I have a feeling we're not done yet. I'd = like to be convinced about the opposite :-) So far, the responses I get on SIP/IPv6 migration point to Turn, SIP = outbound and ICE. Most of the UA's and proxys I'm using haven't got that = set of solutions. It will take time until we get there. Maybe IPv6 can = add more pressure on developers to implement these new functions. I am = afraid they will quickly install b2bua's or SBCs to handle the issue = instead and then we're back two steps instead of moving forward... /O= From tena@huawei.com Mon Mar 7 13:54:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1543D3A6843 for ; Mon, 7 Mar 2011 13:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.472 X-Spam-Level: X-Spam-Status: No, score=-106.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3KsT6Wnc+DZ for ; Mon, 7 Mar 2011 13:53:57 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 463323A677C for ; Mon, 7 Mar 2011 13:53:57 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHP006F8JJYX5@usaga02-in.huawei.com> for v6ops@ietf.org; Mon, 07 Mar 2011 13:55:10 -0800 (PST) Received: from TingZousc1 ([10.193.34.192]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHP000PIJJXLY@usaga02-in.huawei.com> for v6ops@ietf.org; Mon, 07 Mar 2011 13:55:10 -0800 (PST) Date: Mon, 07 Mar 2011 13:55:09 -0800 From: Tina Tsou To: 'IPv6 Ops WG' Message-id: <001f01cbdd12$543413c0$fc9c3b40$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvdElOnhD0tJAAQTEW/pjfKqARNGA== Subject: [v6ops] V4tov6transition Applicability Statement I-Ds and Transition Guide I-Ds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 21:54:00 -0000 Dear interested party on V4tov6transition, To get the best effect, may I suggest submitting the Internet Draft final submission by 17:00 PT, to reference each other for the following drafts? .2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 PT (01:00 Tuesday, March 15 UTC), upload using IETF ID Submission Tool. Your contribution is invited. Problem Statement and Framework: draft-lee-v4v6tran-problem-02 draft-ietf-v6ops-v4v6tran-framework-01 (formerly draft-carpenter-v4v6tran-framework-00) Broadband: draft-huang-v6ops-v4v6tran-bb-usecase-01 (formerly draft-tian-v4v6tran-broadband-sp-usecase-00) draft-yang-v6ops-v4v6tran-bb-transition-guide-01 (formerly draft-yang-v4v6tran-ipv6-transition-guide-00) Cable: draft-lee-v6ops-tran-cable-usecase-00 (formerly draft-lee-v4v6tran-usecase-cable-00) Mobile: draft-tsou-v6ops-mobile-transition-guide (formerly draft-tsou-v4v6tran-mobile-transition-guide-00) draft-zhou-v6ops-mobile-use-case (formerly draft-zhou-v4v6tran-mobile-use-case-00 ) Applicability Statements: http://tools.ietf.org/html/draft-tan-v6ops-nat64-experiences-00 https://datatracker.ietf.org/doc/draft-tsou-v6ops-multicast-transition-v6onl y/ We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From tena@huawei.com Mon Mar 7 13:57:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F5A3A682C for ; Mon, 7 Mar 2011 13:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.48 X-Spam-Level: X-Spam-Status: No, score=-106.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJ2E3ujFkwmH for ; Mon, 7 Mar 2011 13:57:39 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id BA10A3A677C for ; Mon, 7 Mar 2011 13:57:39 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHP006V1JQ5X5@usaga02-in.huawei.com> for v6ops@ietf.org; Mon, 07 Mar 2011 13:58:53 -0800 (PST) Received: from TingZousc1 ([10.193.34.192]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHP0003JJQ4LY@usaga02-in.huawei.com> for v6ops@ietf.org; Mon, 07 Mar 2011 13:58:53 -0800 (PST) Date: Mon, 07 Mar 2011 13:58:53 -0800 From: Tina Tsou To: 'IPv6 Ops WG' , 'V6ops Chairs' Message-id: <002401cbdd12$d9544700$8bfcd500$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvdElOnhD0tJAAQTEW/pjfKqARNGAAAF2Wg Subject: [v6ops] FW: V4tov6transition Applicability Statement I-Ds and Transition Guide I-Ds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 21:57:40 -0000 -----Original Message----- From: postmaster@kisa.or.kr [mailto:postmaster@kisa.or.kr] Sent: Monday, March 07, 2011 1:56 PM To: tena@huawei.com Subject: [ERR] [v6ops] V4tov6transition Applicability Statement I-Ds and Transition Guide I-Ds Transmit Report: To: coredns@gmail.com, 2011/03/08 06:55:35, 500, LOOP MAIL DETECTED -----Original Message----- From: Tina Tsou [mailto:tena@huawei.com] Sent: Monday, March 07, 2011 1:55 PM To: 'IPv6 Ops WG' Subject: V4tov6transition Applicability Statement I-Ds and Transition Guide I-Ds Dear interested party on V4tov6transition, To get the best effect, may I suggest submitting the Internet Draft final submission by 17:00 PT, to reference each other for the following drafts? .2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 PT (01:00 Tuesday, March 15 UTC), upload using IETF ID Submission Tool. Your contribution is invited. Problem Statement and Framework: draft-lee-v4v6tran-problem-02 draft-ietf-v6ops-v4v6tran-framework-01 (formerly draft-carpenter-v4v6tran-framework-00) Broadband: draft-huang-v6ops-v4v6tran-bb-usecase-01 (formerly draft-tian-v4v6tran-broadband-sp-usecase-00) draft-yang-v6ops-v4v6tran-bb-transition-guide-01 (formerly draft-yang-v4v6tran-ipv6-transition-guide-00) Cable: draft-lee-v6ops-tran-cable-usecase-00 (formerly draft-lee-v4v6tran-usecase-cable-00) Mobile: draft-tsou-v6ops-mobile-transition-guide (formerly draft-tsou-v4v6tran-mobile-transition-guide-00) draft-zhou-v6ops-mobile-use-case (formerly draft-zhou-v4v6tran-mobile-use-case-00 ) Applicability Statements: http://tools.ietf.org/html/draft-tan-v6ops-nat64-experiences-00 https://datatracker.ietf.org/doc/draft-tsou-v6ops-multicast-transition-v6onl y/ We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From oej@edvina.net Mon Mar 7 14:02:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2FE28C0E3 for ; Mon, 7 Mar 2011 14:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BihrwHv6BbML for ; Mon, 7 Mar 2011 14:02:26 -0800 (PST) Received: from ns.webway.se (ns.webway.se [87.96.134.125]) by core3.amsl.com (Postfix) with ESMTP id 8DA4328C0F0 for ; Mon, 7 Mar 2011 14:02:26 -0800 (PST) Received: from [192.168.40.12] (unknown [192.168.40.12]) by ns.webway.se (Postfix) with ESMTP id 9DEB428449; Mon, 7 Mar 2011 23:03:39 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <24436_1299502310_4D74D4E6_24436_185484_1_94C682931C08B048B7A8645303FDC9F33C4DA50BCA@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 7 Mar 2011 23:03:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <24436_1299502310_4D74D4E6_24436_185484_1_94C682931C08B048B7A8645303FDC9F33C4DA50BCA@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1082) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 22:02:27 -0000 7 mar 2011 kl. 13.51 skrev : > Dear Olle, >=20 > For the SIP case, if you don't need connectivity checks (e.g., closed = networks, which is in France the majority of SIP traffic) you can just = use the ALTC attribute defined in = http://tools.ietf.org/html/draft-boucadair-mmusic-altc-01. That is a simple fix for the media issue - and something I think = developers can easily implement. We still have the issue with signalling = and registrations. >=20 > In case connectivity checks are needed, a variant of the happy = eyeballs for SIP (called Happy Eardrums) has been proposed in = http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 but still = you need to be sure you IPv4 connectivity is working ;-). Will look at this tomorrow... :-) Thanks for the ALTC proposal. I am a bit hesitant to the = ICE/TURN/SIP-outbound combo, it will take a long time to convince = developers and the market to implement that package...=20 /O >=20 > Cheers, > Med >=20 >=20 > -----Message d'origine----- > De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part = de Olle E. Johansson > Envoy=E9 : lundi 7 mars 2011 10:40 > =C0 : v6ops@ietf.org > Objet : [v6ops] Happy Eyeballs and SIP >=20 > Hi! >=20 > Has anyone considered the issues covered in the happy-eyeballs draft = for SIP? >=20 > A 19 or 32 second time out when placing a call is not a good user = experience... I think this applies to SIP over TCP, and possibly also = needs to be handled for UDP. > I don't see this handled in the draft for IPv6 transition in the = Session Initiation Protocol (soon-to-be RFC 6157) >=20 > Seems like the scope of the happy eyeballs draft is HTTP, so the = question is if this should be expanded or if we need other drafts for = other protocols. >=20 > Regards, > /Olle >=20 > Ref: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > = **************************************************************************= ****** > IMPORTANT.Les informations contenues dans ce message electronique y = compris les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. > Ce message electronique est destine exclusivement au(x) = destinataire(s) mentionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas = destine, veuillez immediatement le signaler a l expediteur et effacer = ce message=20 > et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations contenues = dans ce message est interdite. > Tout message electronique est susceptible d alteration. > A ce titre, le Groupe France Telecom decline toute responsabilite = notamment s il a ete altere, deforme ou falsifie. > De meme, il appartient au destinataire de s assurer de l absence de = tout virus. >=20 > IMPORTANT.This e-mail message and any attachments are strictly = confidential and may be protected by law. This message is > intended only for the named recipient(s) above. > If you have received this message in error, or are not the named = recipient(s), please immediately notify the sender and delete this = e-mail message. > Any unauthorized view, usage or disclosure ofthis message is = prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall = not be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus free. > = **************************************************************************= ****** --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From dwing@cisco.com Mon Mar 7 15:45:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C137E28C133 for ; Mon, 7 Mar 2011 15:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.565 X-Spam-Level: X-Spam-Status: No, score=-110.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02XVoXy0Gfiw for ; Mon, 7 Mar 2011 15:45:56 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9516E3A6878 for ; Mon, 7 Mar 2011 15:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4733; q=dns/txt; s=iport; t=1299541630; x=1300751230; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=p6ncwbnTIC66W4jRU/xrWWvjN4D0qRRHts00lWLgYJw=; b=l44XleIe249pMm8qlsm+nJqP1EK2KGXeInG3y0GJEoE3IJBPjgV2Z2kI MCau62ILiRQKkFtlaCDdQk6HV7LHpdKEVNY9bbJaq8RtiOxjnHJvAd98/ sfwPLXGvA0jAmIByHTrsWdTxKcHclupv7BOKGWGNNPqBZ7HOvpJsK/JKy M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAH/9dE2rR7Hu/2dsb2JhbACYEIFljGJ0oiiMd48thWIEhRw X-IronPort-AV: E=Sophos;i="4.62,280,1297036800"; d="scan'208";a="412444331" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 07 Mar 2011 23:45:35 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p27NjZSa011072; Mon, 7 Mar 2011 23:45:35 GMT From: "Dan Wing" To: "'Olle E. Johansson'" References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <117401cbdcdd$8c9ccac0$a5d66040$@com> <2E7989D3-B865-4D5A-ACE9-A74567BAD065@edvina.net> In-Reply-To: <2E7989D3-B865-4D5A-ACE9-A74567BAD065@edvina.net> Date: Mon, 7 Mar 2011 15:45:35 -0800 Message-ID: <168101cbdd21$c137a5e0$43a6f1a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvdAzQqcVBnLqCnRou/xSQbKRkdDQAHbMyQ Content-Language: en-us Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 23:45:57 -0000 > -----Original Message----- > From: Olle E. Johansson [mailto:oej@edvina.net] > Sent: Monday, March 07, 2011 12:06 PM > To: Dan Wing > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Happy Eyeballs and SIP > > > 7 mar 2011 kl. 16.37 skrev Dan Wing: > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf > >> Of Olle E. Johansson > >> Sent: Monday, March 07, 2011 1:40 AM > >> To: v6ops@ietf.org > >> Subject: [v6ops] Happy Eyeballs and SIP > >> > >> Hi! > >> > >> Has anyone considered the issues covered in the happy-eyeballs draft > >> for SIP? > >> > >> A 19 or 32 second time out when placing a call is not a good user > >> experience... I think this applies to SIP over TCP, and possibly > also > >> needs to be handled for UDP. > >> I don't see this handled in the draft for IPv6 transition in the > >> Session Initiation Protocol (soon-to-be RFC 6157) > >> > >> Seems like the scope of the happy eyeballs draft is HTTP, so the > >> question is if this should be expanded or if we need other drafts > for > >> other protocols. > > > > ICE (RFC5245) resolves the problem perfectly, and is the plan-of- > record for > > how to support the transition to IPv6 for SIP > > (draft-ietf-sipping-v6-transition). ICE does connectivity checks, so > it > > figures out if IPv4 or IPv6 (or UDP, or TCP) is working between two > peers, > > and uses that path. ICE can be performed while the phone is ringing, > so > > does not delay call set up. ICE was one of the inspirations for > Happy > > Eyeballs. > > > > There is resistance to ICE because of (a) its complexity and (b) a > > perception that "IPv6 works fine on my network", which has fostered > the > > creation of several other solutions, including an idea we nicknamed > "Happy > > Eardrums", draft-wing-dispatch-v6-migration, which we have since > abandoned. > > ICE does more, and it does a better job. > > Thanks for the feedback. > > Please tell me how Ice solves the issue of a phone calling a SIP domain > with both A and AAAA records for the first selected host. > The proxy or the UA will try to contact first over one connection, time > out after T1*64 and then maybe retry. > > As far as I know ICE handles media, but not the signalling. But I may > be misunderstanding something. You're right, ICE is just about media. I didn't realize you were asking about SIP signaling -- most folks don't worry themselves with the SIP signaling. Yes, we need to do Happy Eyeballs for the SIP signaling. I have engaged our internal XMPP experts for doing Happy Eyeballs with XMPP, which wants to avoid the delay to connect to your instant messaging server when you join a new network (e.g., open the laptop). I have text which we plan to incorporate into -01 which discusses how to do Happy Eyeballs with an SRV service, such as XMPP. This would apply equally to SIP, which also uses SRV (RFC3263). Current outline is this: For the purposes of this section, "client" is defined as the entity initiating the connection. For protocols which support DNS SRV[xxxx], the client performs the IN SRV query (e.g. IN SRV _xmpp-client._tcp.example.com) as normal. The client MUST perform the following steps: 1. Sort all SRV records according to priority (lowest priority first) 2. Process all of the SRV targets of the same priority with a weight greater than 0: 2.1. Perform A/AAAA queries for each SRV target in parallel, as described in [SECTION x.1.] 2.2. Connect to the IPv4/IPv6 addresses 2.3. If at least one connection succeeds, stop processing SRV records 3. If there is no connection, process all of the SRV targets of the same priority with a weight of 0, as per steps 2.1 through 2.3 above 4. Repeat steps 2.1 through 2.3 for the next priority, until a connection is established or all SRV records have been exhausted 5. If there is still no connection, fallback to using the domain (e.g. example.com), following steps 2.1 through 2.3 above It is RECOMMENDED, but not required, for the client to cache the winning connection's address information and reuse it on subsequent connections. If a significant network event occurs (e.g. network interface is activated/deactivated, IP address changes), the client MUST forget the cached address information and perform all of the steps from above. The definition of "significant network event" is intentionally vague. I believe that's the sort of thing you're looking for? -d From oej@edvina.net Mon Mar 7 22:57:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620843A68C2 for ; Mon, 7 Mar 2011 22:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UASW4xQAQ3AJ for ; Mon, 7 Mar 2011 22:57:37 -0800 (PST) Received: from ns.webway.se (ns.webway.se [87.96.134.125]) by core3.amsl.com (Postfix) with ESMTP id 5A3473A6832 for ; Mon, 7 Mar 2011 22:57:28 -0800 (PST) Received: from [192.168.40.12] (unknown [192.168.40.12]) by ns.webway.se (Postfix) with ESMTP id 427012845D; Tue, 8 Mar 2011 07:58:31 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <168101cbdd21$c137a5e0$43a6f1a0$@com> Date: Tue, 8 Mar 2011 07:58:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <117401cbdcdd$8c9ccac0$a5d66040$@com> <2E7989D3-B865-4D5A-ACE9-A74567BAD065@edvina.net> <168101cbdd21$c137a5e0$43a6f1a0$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 06:57:49 -0000 8 mar 2011 kl. 00.45 skrev Dan Wing: >> -----Original Message----- >> From: Olle E. Johansson [mailto:oej@edvina.net] >> Sent: Monday, March 07, 2011 12:06 PM >> To: Dan Wing >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] Happy Eyeballs and SIP >>=20 >>=20 >> 7 mar 2011 kl. 16.37 skrev Dan Wing: >>=20 >>>> -----Original Message----- >>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On >> Behalf >>>> Of Olle E. Johansson >>>> Sent: Monday, March 07, 2011 1:40 AM >>>> To: v6ops@ietf.org >>>> Subject: [v6ops] Happy Eyeballs and SIP >>>>=20 >>>> Hi! >>>>=20 >>>> Has anyone considered the issues covered in the happy-eyeballs = draft >>>> for SIP? >>>>=20 >>>> A 19 or 32 second time out when placing a call is not a good user >>>> experience... I think this applies to SIP over TCP, and possibly >> also >>>> needs to be handled for UDP. >>>> I don't see this handled in the draft for IPv6 transition in the >>>> Session Initiation Protocol (soon-to-be RFC 6157) >>>>=20 >>>> Seems like the scope of the happy eyeballs draft is HTTP, so the >>>> question is if this should be expanded or if we need other drafts >> for >>>> other protocols. >>>=20 >>> ICE (RFC5245) resolves the problem perfectly, and is the plan-of- >> record for >>> how to support the transition to IPv6 for SIP >>> (draft-ietf-sipping-v6-transition). ICE does connectivity checks, = so >> it >>> figures out if IPv4 or IPv6 (or UDP, or TCP) is working between two >> peers, >>> and uses that path. ICE can be performed while the phone is = ringing, >> so >>> does not delay call set up. ICE was one of the inspirations for >> Happy >>> Eyeballs. >>>=20 >>> There is resistance to ICE because of (a) its complexity and (b) a >>> perception that "IPv6 works fine on my network", which has fostered >> the >>> creation of several other solutions, including an idea we nicknamed >> "Happy >>> Eardrums", draft-wing-dispatch-v6-migration, which we have since >> abandoned. >>> ICE does more, and it does a better job. >>=20 >> Thanks for the feedback. >>=20 >> Please tell me how Ice solves the issue of a phone calling a SIP = domain >> with both A and AAAA records for the first selected host. >> The proxy or the UA will try to contact first over one connection, = time >> out after T1*64 and then maybe retry. >>=20 >> As far as I know ICE handles media, but not the signalling. But I may >> be misunderstanding something. >=20 > You're right, ICE is just about media. I didn't realize you were = asking > about SIP signaling -- most folks don't worry themselves with the SIP > signaling. >=20 > Yes, we need to do Happy Eyeballs for the SIP signaling. I have=20 > engaged our internal XMPP experts for doing Happy Eyeballs with > XMPP, which wants to avoid the delay to connect to your instant > messaging server when you join a new network (e.g., open the=20 > laptop). >=20 > I have text which we plan to incorporate into -01 which discusses > how to do Happy Eyeballs with an SRV service, such as XMPP. This > would apply equally to SIP, which also uses SRV (RFC3263). >=20 > Current outline is this: >=20 > For the purposes of this section, "client" is defined as the > entity initiating the connection. >=20 > For protocols which support DNS SRV[xxxx], the client > performs the IN SRV query (e.g. IN SRV > _xmpp-client._tcp.example.com) as normal. The client MUST > perform the following steps: >=20 > 1. Sort all SRV records according to priority (lowest > priority first) > 2. Process all of the SRV targets of the same priority with a > weight greater than 0: > 2.1. Perform A/AAAA queries for each SRV target in parallel, > as described in [SECTION x.1.] > 2.2. Connect to the IPv4/IPv6 addresses > 2.3. If at least one connection succeeds, stop processing > SRV records > 3. If there is no connection, process all of the SRV targets > of the same priority with a weight of 0, as per steps 2.1 > through 2.3 above > 4. Repeat steps 2.1 through 2.3 for the next priority, > until a connection is established or all SRV records > have been exhausted > 5. If there is still no connection, fallback to using > the domain (e.g. example.com), following steps 2.1 > through 2.3 above >=20 > It is RECOMMENDED, but not required, for the client to > cache the winning connection's address information and > reuse it on subsequent connections. If a significant > network event occurs (e.g. network interface is > activated/deactivated, IP address changes), the client MUST > forget the cached address information and perform all of > the steps from above. The definition of "significant > network event" is intentionally vague. >=20 > I believe that's the sort of thing you're looking for? >=20 That's good stuff, Dan. I will look through it and come back after I = cleared my thoughts. I've been discussing using SRV for showing my = preference of address family, which impacts also single stack clients. = Your algorithm seems to work there too. The question in that case is = that some UAs fail the connection attempt if they can't find records = matching their address family for the top priority SRV records - they do = not proceed to the next level. In SIP we also have UDP, which is a different issue that requires a = solution. If I transmit two UDP messages - one over IPv4 and one over IPv6, = hopefully the other side gets both and sees one as a simple retransmit. The UA will get one or two answers and stick with the one that responded = first and just forget the other one. I don't see an issue with this behaviour from the server side - do you? Regards, /O From dwing@cisco.com Mon Mar 7 23:12:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B7A3A6832 for ; Mon, 7 Mar 2011 23:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.568 X-Spam-Level: X-Spam-Status: No, score=-110.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfWnlZbUxDz3 for ; Mon, 7 Mar 2011 23:12:07 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 404EC3A68FD for ; Mon, 7 Mar 2011 23:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3349; q=dns/txt; s=iport; t=1299568349; x=1300777949; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=21varxelDLTyBz/+xisJ1M9/p21TshuXMh/7zFifvTc=; b=C+HgvnRA20IpjSvMWBJHaWX7e1yvjgqEUWE72pm69OyJ8LWuWHiP2OE4 8Yf6YlSBb9onCyoRTCRA2h2rhEL/w08qRKbrf8Ni8KbOHs7EKGMocA4Ei lntRsluNnsDAd3BFUbG2ln31KMS/FGD6f4/WHF/OvaePPfBEufR3gGGK7 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAI5ldU2rR7Hu/2dsb2JhbACZeIxFdKFYjHePNIViBIUd X-IronPort-AV: E=Sophos;i="4.62,283,1297036800"; d="scan'208";a="274620215" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2011 07:12:27 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p287CRRm012280; Tue, 8 Mar 2011 07:12:27 GMT From: "Dan Wing" To: "'Olle E. Johansson'" References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <117401cbdcdd$8c9ccac0$a5d66040$@com> <2E7989D3-B865-4D5A-ACE9-A74567BAD065@edvina.net> <168101cbdd21$c137a5e0$43a6f1a0$@com> In-Reply-To: Date: Mon, 7 Mar 2011 23:12:27 -0800 Message-ID: <184701cbdd60$2e935ec0$8bba1c40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvdXj7F4kl0YiEWQRSUxaJRNrlZMQAAO/Mw Content-Language: en-us Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 07:12:23 -0000 ... > > Current outline is this: > > > > For the purposes of this section, "client" is defined as the > > entity initiating the connection. > > > > For protocols which support DNS SRV[xxxx], the client > > performs the IN SRV query (e.g. IN SRV > > _xmpp-client._tcp.example.com) as normal. The client MUST > > perform the following steps: > > > > 1. Sort all SRV records according to priority (lowest > > priority first) > > 2. Process all of the SRV targets of the same priority with a > > weight greater than 0: > > 2.1. Perform A/AAAA queries for each SRV target in parallel, > > as described in [SECTION x.1.] > > 2.2. Connect to the IPv4/IPv6 addresses > > 2.3. If at least one connection succeeds, stop processing > > SRV records > > 3. If there is no connection, process all of the SRV targets > > of the same priority with a weight of 0, as per steps 2.1 > > through 2.3 above > > 4. Repeat steps 2.1 through 2.3 for the next priority, > > until a connection is established or all SRV records > > have been exhausted > > 5. If there is still no connection, fallback to using > > the domain (e.g. example.com), following steps 2.1 > > through 2.3 above > > > > It is RECOMMENDED, but not required, for the client to > > cache the winning connection's address information and > > reuse it on subsequent connections. If a significant > > network event occurs (e.g. network interface is > > activated/deactivated, IP address changes), the client MUST > > forget the cached address information and perform all of > > the steps from above. The definition of "significant > > network event" is intentionally vague. > > > > I believe that's the sort of thing you're looking for? > > > > That's good stuff, Dan. I didn't write it, but we expect to get that into -01 of happy eyeballs. Afterall, the problem is not confined to just HTTP clients. > I will look through it and come back after I > cleared my thoughts. I've been discussing using SRV for showing my > preference of address family, which impacts also single stack clients. > Your algorithm seems to work there too. The question in that case is > that some UAs fail the connection attempt if they can't find records > matching their address family for the top priority SRV records - they > do not proceed to the next level. > > In SIP we also have UDP, which is a different issue that requires a > solution. > > If I transmit two UDP messages - one over IPv4 and one over IPv6, > hopefully the other side gets both and sees one as a simple retransmit. > The UA will get one or two answers and stick with the one that > responded first and just forget the other one. I don't see an issue > with this behaviour from the server side - do you? That is relying on the matching Call-IDs to be perceived as a simple re-transmit by the receiving side. I imagine most of the time one of them would be discarded, but we really want "the right one" to be discarded -- presumably, the IPv4 one should be discarded (assuming it went through a NAT44 or NAT64, consuming state). This is something we should bring over to one of the SIP working groups, probably SIPCORE, to consider. -d From dwing@cisco.com Mon Mar 7 23:52:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5423B3A6902 for ; Mon, 7 Mar 2011 23:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.268 X-Spam-Level: X-Spam-Status: No, score=-110.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1LfKaiUzPai for ; Mon, 7 Mar 2011 23:52:38 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6C6163A6849 for ; Mon, 7 Mar 2011 23:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4998; q=dns/txt; s=iport; t=1299570832; x=1300780432; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=TVuqyBaavcodK4L5Yvnqc/KuIO5UhmqgOW9fnBEwzm0=; b=QQkcCnkd5ve47TIRBIM7yad3DKOP2Wp6fXXlo8AwDzr9t30/I2CPsRqS PmYxpMgbu66e9/qlrJdci9B93C/iXRjd4TI8okdCpzH2Bl+DpiiEAhcdn Io161dhY5nr2VgCcyzQrgUwc3PP6JknV4mW69PTEgkZeDZrM6UdY5zppo o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAO9udU2rR7H+/2dsb2JhbACYE4FljEV0oWucMQKFYASFHQ X-IronPort-AV: E=Sophos;i="4.62,283,1297036800"; d="scan'208";a="274643669" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2011 07:53:52 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p287rpkj005896; Tue, 8 Mar 2011 07:53:51 GMT From: "Dan Wing" To: "'Olle E. Johansson'" , References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <24436_1299502310_4D74D4E6_24436_185484_1_94C682931C08B048B7A8645303FDC9F33C4DA50BCA@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Date: Mon, 7 Mar 2011 23:53:51 -0800 Message-ID: <18c501cbdd65$f7428bc0$e5c7a340$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvdE6TZEwE2yB+mTieYG1rzY/K5GgAUdHsA Content-Language: en-us Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 07:52:41 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Olle E. Johansson > Sent: Monday, March 07, 2011 2:04 PM > To: mohamed.boucadair@orange-ftgroup.com > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Happy Eyeballs and SIP >=20 >=20 > 7 mar 2011 kl. 13.51 skrev : >=20 > > Dear Olle, > > > > For the SIP case, if you don't need connectivity checks (e.g., = closed > networks, which is in France the majority of SIP traffic) you can just > use the ALTC attribute defined in http://tools.ietf.org/html/draft- > boucadair-mmusic-altc-01. > That is a simple fix for the media issue - and something I think > developers can easily implement. We still have the issue with > signalling and registrations. > > > > In case connectivity checks are needed, a variant of the happy > eyeballs for SIP (called Happy Eardrums) has been proposed in > http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 but > still you need to be sure you IPv4 connectivity is working ;-). > Will look at this tomorrow... :-) >=20 > Thanks for the ALTC proposal. I am a bit hesitant to the ICE/TURN/SIP- > outbound combo, it will take a long time to convince developers and = the > market to implement that package... I agree that ICE is a big pill to swallow. (If we're talking only IPv4/IPv6 selection, though, TURN is not part of that equation.) However, industry experience with IPv6 on the Internet shows that we cannot rely on the "we both have an IPv6 address, therefore we have connectivty" assumption. There are IPv6 islands (on purpose or on accident) which are permanent or temporary (failure of a=20 link or a router), and because IPv4 is predominant the IPv6 failure is not immediately noticed or corrected -- but impacts users that support IPv6. -d > /O > > > > Cheers, > > Med > > > > > > -----Message d'origine----- > > De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la > part de Olle E. Johansson > > Envoy=E9 : lundi 7 mars 2011 10:40 > > =C0 : v6ops@ietf.org > > Objet : [v6ops] Happy Eyeballs and SIP > > > > Hi! > > > > Has anyone considered the issues covered in the happy-eyeballs draft > for SIP? > > > > A 19 or 32 second time out when placing a call is not a good user > experience... I think this applies to SIP over TCP, and possibly also > needs to be handled for UDP. > > I don't see this handled in the draft for IPv6 transition in the > Session Initiation Protocol (soon-to-be RFC 6157) > > > > Seems like the scope of the happy eyeballs draft is HTTP, so the > question is if this should be expanded or if we need other drafts for > other protocols. > > > > Regards, > > /Olle > > > > Ref: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > = *********************************************************************** > ********* > > IMPORTANT.Les informations contenues dans ce message electronique y > compris les fichiers attaches sont strictement confidentielles > > et peuvent etre protegees par la loi. > > Ce message electronique est destine exclusivement au(x) > destinataire(s) mentionne(s) ci-dessus. > > Si vous avez recu ce message par erreur ou s il ne vous est pas > destine, veuillez immediatement le signaler a l expediteur et effacer > ce message > > et tous les fichiers eventuellement attaches. > > Toute lecture, exploitation ou transmission des informations > contenues dans ce message est interdite. > > Tout message electronique est susceptible d alteration. > > A ce titre, le Groupe France Telecom decline toute responsabilite > notamment s il a ete altere, deforme ou falsifie. > > De meme, il appartient au destinataire de s assurer de l absence de > tout virus. > > > > IMPORTANT.This e-mail message and any attachments are strictly > confidential and may be protected by law. This message is > > intended only for the named recipient(s) above. > > If you have received this message in error, or are not the named > recipient(s), please immediately notify the sender and delete this e- > mail message. > > Any unauthorized view, usage or disclosure ofthis message is > prohibited. > > Since e-mail messages may not be reliable, France Telecom Group = shall > not be liable for any message if modified, changed or falsified. > > Additionally the recipient should ensure they are actually virus > free. > > > = *********************************************************************** > ********* >=20 > --- > * Olle E Johansson - oej@edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From satoru.matsushima@gmail.com Tue Mar 8 00:48:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365923A685A for ; Tue, 8 Mar 2011 00:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0R92tBS-v7PH for ; Tue, 8 Mar 2011 00:48:01 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 33F5E3A6822 for ; Tue, 8 Mar 2011 00:48:01 -0800 (PST) Received: by iwl42 with SMTP id 42so5873738iwl.31 for ; Tue, 08 Mar 2011 00:49:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=sl5QZ5Gw1lOFnGpjsugI+eVMeduJUGH05VzrKIHnDLk=; b=dDhbt2GPOuuwSgOdrqTzUMsmq3IkykCY4Hed2dFpx/8Yu3/zSMZT79NEQs0WX0P2+r U76+oZxMwfiw9/039zUuD+bUIxHZpIBDMtVbh/BvG2aXB5X7Tx8X0oVojBEcPR/JT5wL VNOmQSisQ6vEigb8P/JxZFBib8Y40kMt6xFkA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=pot/XVR33W3yvBz7qxD3fU4CoTHuyrB75JV5naV+a8lmv79q95PZKKRB2Ydz22hZob PtP5pwDSxTH4IiECWXfey7WfpjX6eXuOgXlKCDtBHfiWF+J4pNfycCoUEDUR9MCXtI7h 2SIetFQ9RVboZaEUmS5fRLeqDxIG3l4HkbSmU= Received: by 10.231.142.35 with SMTP id o35mr3820164ibu.64.1299574155697; Tue, 08 Mar 2011 00:49:15 -0800 (PST) Received: from [10.201.81.18] ([202.45.12.174]) by mx.google.com with ESMTPS id d10sm447435ibb.12.2011.03.08.00.49.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2011 00:49:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <001f01cbdd12$543413c0$fc9c3b40$@com> Date: Tue, 8 Mar 2011 17:49:11 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2860B221-ECA1-482E-92FF-3D11813B4699@gmail.com> References: <001f01cbdd12$543413c0$fc9c3b40$@com> To: Tina Tsou , IPv6 Ops WG X-Mailer: Apple Mail (2.1082) Subject: Re: [v6ops] V4tov6transition Applicability Statement I-Ds and Transition Guide I-Ds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 08:48:02 -0000 Hello, We've submitted two documents, in which v4tov6transition related topics. 1). = http://tools.ietf.org/id/draft-matsushima-v6ops-transition-experience-00.t= xt 2). http://tools.ietf.org/id/draft-sun-intarea-4rd-applicability-00.txt 1) is a transition experience and considerations for the transition from = another aspect. 2) is posted to intarea-wg, but it would be interested in this area. Best regards, --satoru On 2011/03/08, at 6:55, Tina Tsou wrote: > Dear interested party on V4tov6transition, > To get the best effect, may I suggest submitting the Internet Draft = final > submission by 17:00 PT, to reference each other for the following = drafts? > .2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 = PT > (01:00 Tuesday, March 15 UTC), upload using IETF ID Submission Tool. >=20 > Your contribution is invited. >=20 > Problem Statement and Framework: > draft-lee-v4v6tran-problem-02=20 > draft-ietf-v6ops-v4v6tran-framework-01 (formerly > draft-carpenter-v4v6tran-framework-00) >=20 > Broadband: > draft-huang-v6ops-v4v6tran-bb-usecase-01 (formerly > draft-tian-v4v6tran-broadband-sp-usecase-00)=20 > draft-yang-v6ops-v4v6tran-bb-transition-guide-01 (formerly > draft-yang-v4v6tran-ipv6-transition-guide-00)=20 >=20 > Cable: > draft-lee-v6ops-tran-cable-usecase-00 (formerly > draft-lee-v4v6tran-usecase-cable-00)=20 >=20 > Mobile: > draft-tsou-v6ops-mobile-transition-guide (formerly > draft-tsou-v4v6tran-mobile-transition-guide-00) > draft-zhou-v6ops-mobile-use-case (formerly > draft-zhou-v4v6tran-mobile-use-case-00 ) >=20 > Applicability Statements: > http://tools.ietf.org/html/draft-tan-v6ops-nat64-experiences-00 > = https://datatracker.ietf.org/doc/draft-tsou-v6ops-multicast-transition-v6o= nl > y/ >=20 >=20 >=20 > We keep our promises with one another - no matter what! >=20 > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From oej@edvina.net Tue Mar 8 01:54:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787BB3A6818 for ; Tue, 8 Mar 2011 01:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvXxjC3kr+M6 for ; Tue, 8 Mar 2011 01:54:41 -0800 (PST) Received: from smtp6.webway.se (smtp2.webway.se [87.96.134.128]) by core3.amsl.com (Postfix) with ESMTP id 223D83A67ED for ; Tue, 8 Mar 2011 01:54:40 -0800 (PST) Received: from [192.168.20.218] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp6.webway.se (Postfix) with ESMTPA id 164E4552E64; Tue, 8 Mar 2011 09:55:54 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <184701cbdd60$2e935ec0$8bba1c40$@com> Date: Tue, 8 Mar 2011 10:55:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <117401cbdcdd$8c9ccac0$a5d66040$@com> <2E7989D3-B865-4D5A-ACE9-A74567BAD065@edvina.net> <168101cbdd21$c137a5e0$43a6f1a0$@com> <184701cbdd60$2e935ec0$8bba1c40$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 09:54:42 -0000 8 mar 2011 kl. 08.12 skrev Dan Wing: > ... >>> Current outline is this: >>>=20 >>> For the purposes of this section, "client" is defined as the >>> entity initiating the connection. >>>=20 >>> For protocols which support DNS SRV[xxxx], the client >>> performs the IN SRV query (e.g. IN SRV >>> _xmpp-client._tcp.example.com) as normal. The client MUST >>> perform the following steps: >>>=20 >>> 1. Sort all SRV records according to priority (lowest >>> priority first) >>> 2. Process all of the SRV targets of the same priority with a >>> weight greater than 0: >>> 2.1. Perform A/AAAA queries for each SRV target in parallel, >>> as described in [SECTION x.1.] >>> 2.2. Connect to the IPv4/IPv6 addresses >>> 2.3. If at least one connection succeeds, stop processing >>> SRV records >>> 3. If there is no connection, process all of the SRV targets >>> of the same priority with a weight of 0, as per steps 2.1 >>> through 2.3 above >>> 4. Repeat steps 2.1 through 2.3 for the next priority, >>> until a connection is established or all SRV records >>> have been exhausted >>> 5. If there is still no connection, fallback to using >>> the domain (e.g. example.com), following steps 2.1 >>> through 2.3 above >>>=20 >>> It is RECOMMENDED, but not required, for the client to >>> cache the winning connection's address information and >>> reuse it on subsequent connections. If a significant >>> network event occurs (e.g. network interface is >>> activated/deactivated, IP address changes), the client MUST >>> forget the cached address information and perform all of >>> the steps from above. The definition of "significant >>> network event" is intentionally vague. >>>=20 >>> I believe that's the sort of thing you're looking for? >>>=20 >>=20 >> That's good stuff, Dan. >=20 > I didn't write it, but we expect to get that into -01 of happy = eyeballs. > Afterall, the problem is not confined to just HTTP clients. >=20 >> I will look through it and come back after I >> cleared my thoughts. I've been discussing using SRV for showing my >> preference of address family, which impacts also single stack = clients. >> Your algorithm seems to work there too. The question in that case is >> that some UAs fail the connection attempt if they can't find records >> matching their address family for the top priority SRV records - they >> do not proceed to the next level. >>=20 >> In SIP we also have UDP, which is a different issue that requires a >> solution. >>=20 >> If I transmit two UDP messages - one over IPv4 and one over IPv6, >> hopefully the other side gets both and sees one as a simple = retransmit. >> The UA will get one or two answers and stick with the one that >> responded first and just forget the other one. I don't see an issue >> with this behaviour from the server side - do you? >=20 > That is relying on the matching Call-IDs to be perceived as a=20 > simple re-transmit by the receiving side. I imagine most of=20 > the time one of them would be discarded, but we really want > "the right one" to be discarded -- presumably, the IPv4 one > should be discarded (assuming it went through a NAT44 or NAT64, > consuming state). >=20 > This is something we should bring over to one of the SIP working=20 > groups, probably SIPCORE, to consider. I would say that it's up to the UA and not the server to discard. The = server needs to handle it as a normal retransmit and respond. Agree that we need to take it over to the SIP side. Thanks all for = answering and participating! /O= From oej@edvina.net Tue Mar 8 01:57:32 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAAE93A6774 for ; Tue, 8 Mar 2011 01:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEw-yjeH0Qqb for ; Tue, 8 Mar 2011 01:57:31 -0800 (PST) Received: from smtp6.webway.se (smtp2.webway.se [87.96.134.128]) by core3.amsl.com (Postfix) with ESMTP id 0D0713A67C0 for ; Tue, 8 Mar 2011 01:57:30 -0800 (PST) Received: from [192.168.20.218] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp6.webway.se (Postfix) with ESMTPA id CBB48552C41; Tue, 8 Mar 2011 09:58:44 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <18c501cbdd65$f7428bc0$e5c7a340$@com> Date: Tue, 8 Mar 2011 10:58:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3CFAED05-4FB9-4596-90A5-E73CB4DC717C@edvina.net> References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <24436_1299502310_4D74D4E6_24436_185484_1_94C682931C08B048B7A8645303FDC9F33C4DA50BCA@PUEXCB1B.nanterre.francetelecom.fr> <18c501cbdd65$f7428bc0$e5c7a340$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 09:57:32 -0000 8 mar 2011 kl. 08.53 skrev Dan Wing: >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >> Of Olle E. Johansson >> Sent: Monday, March 07, 2011 2:04 PM >> To: mohamed.boucadair@orange-ftgroup.com >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] Happy Eyeballs and SIP >>=20 >>=20 >> 7 mar 2011 kl. 13.51 skrev : >>=20 >>> Dear Olle, >>>=20 >>> For the SIP case, if you don't need connectivity checks (e.g., = closed >> networks, which is in France the majority of SIP traffic) you can = just >> use the ALTC attribute defined in http://tools.ietf.org/html/draft- >> boucadair-mmusic-altc-01. >> That is a simple fix for the media issue - and something I think >> developers can easily implement. We still have the issue with >> signalling and registrations. >>>=20 >>> In case connectivity checks are needed, a variant of the happy >> eyeballs for SIP (called Happy Eardrums) has been proposed in >> http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 but >> still you need to be sure you IPv4 connectivity is working ;-). >> Will look at this tomorrow... :-) >>=20 >> Thanks for the ALTC proposal. I am a bit hesitant to the = ICE/TURN/SIP- >> outbound combo, it will take a long time to convince developers and = the >> market to implement that package... >=20 > I agree that ICE is a big pill to swallow. (If we're talking only > IPv4/IPv6 selection, though, TURN is not part of that equation.) Turn is part of the whole IPv6 migration scenario according to the = soon-to-become-RFC. >=20 > However, industry experience with IPv6 on the Internet shows that > we cannot rely on the "we both have an IPv6 address, therefore we > have connectivty" assumption. There are IPv6 islands (on purpose > or on accident) which are permanent or temporary (failure of a=20 > link or a router), and because IPv4 is predominant the IPv6 failure > is not immediately noticed or corrected -- but impacts users > that support IPv6. Fully agree - that's why I'm insisting on the happy eyeballs approach = :-) More info about IPv6 and SIP on http://edvina.net/sipv6 and = http://www.facebook.com/sipv6 for those who wants to follow, help or = point out my mistakes in thoughts! I appreciate all feedback. Cheers /O >=20 > -d >=20 >> /O >>>=20 >>> Cheers, >>> Med >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la >> part de Olle E. Johansson >>> Envoy=E9 : lundi 7 mars 2011 10:40 >>> =C0 : v6ops@ietf.org >>> Objet : [v6ops] Happy Eyeballs and SIP >>>=20 >>> Hi! >>>=20 >>> Has anyone considered the issues covered in the happy-eyeballs draft >> for SIP? >>>=20 >>> A 19 or 32 second time out when placing a call is not a good user >> experience... I think this applies to SIP over TCP, and possibly also >> needs to be handled for UDP. >>> I don't see this handled in the draft for IPv6 transition in the >> Session Initiation Protocol (soon-to-be RFC 6157) >>>=20 >>> Seems like the scope of the happy eyeballs draft is HTTP, so the >> question is if this should be expanded or if we need other drafts for >> other protocols. >>>=20 >>> Regards, >>> /Olle >>>=20 >>> Ref: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>=20 >> = *********************************************************************** >> ********* >>> IMPORTANT.Les informations contenues dans ce message electronique y >> compris les fichiers attaches sont strictement confidentielles >>> et peuvent etre protegees par la loi. >>> Ce message electronique est destine exclusivement au(x) >> destinataire(s) mentionne(s) ci-dessus. >>> Si vous avez recu ce message par erreur ou s il ne vous est pas >> destine, veuillez immediatement le signaler a l expediteur et = effacer >> ce message >>> et tous les fichiers eventuellement attaches. >>> Toute lecture, exploitation ou transmission des informations >> contenues dans ce message est interdite. >>> Tout message electronique est susceptible d alteration. >>> A ce titre, le Groupe France Telecom decline toute responsabilite >> notamment s il a ete altere, deforme ou falsifie. >>> De meme, il appartient au destinataire de s assurer de l absence de >> tout virus. >>>=20 >>> IMPORTANT.This e-mail message and any attachments are strictly >> confidential and may be protected by law. This message is >>> intended only for the named recipient(s) above. >>> If you have received this message in error, or are not the named >> recipient(s), please immediately notify the sender and delete this e- >> mail message. >>> Any unauthorized view, usage or disclosure ofthis message is >> prohibited. >>> Since e-mail messages may not be reliable, France Telecom Group = shall >> not be liable for any message if modified, changed or falsified. >>> Additionally the recipient should ensure they are actually virus >> free. >>>=20 >> = *********************************************************************** >> ********* >>=20 >> --- >> * Olle E Johansson - oej@edvina.net >> * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From mohamed.boucadair@orange-ftgroup.com Tue Mar 8 02:11:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80B03A6835 for ; Tue, 8 Mar 2011 02:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VPG6ldS53Zs for ; Tue, 8 Mar 2011 02:11:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 99D853A6834 for ; Tue, 8 Mar 2011 02:11:28 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id C1B57264112; Tue, 8 Mar 2011 11:12:39 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A62CD23804B; Tue, 8 Mar 2011 11:12:39 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 8 Mar 2011 11:12:39 +0100 From: To: "Olle E. Johansson" , Dan Wing Date: Tue, 8 Mar 2011 11:12:38 +0100 Thread-Topic: [v6ops] Happy Eyeballs and SIP Thread-Index: Acvdd2vOfI0kopjRTfKYjI9o0gT6pgAALoVA Message-ID: <14620_1299579159_4D760117_14620_182275_1_94C682931C08B048B7A8645303FDC9F33C4DA5106C@PUEXCB1B.nanterre.francetelecom.fr> References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <24436_1299502310_4D74D4E6_24436_185484_1_94C682931C08B048B7A8645303FDC9F33C4DA50BCA@PUEXCB1B.nanterre.francetelecom.fr> <18c501cbdd65$f7428bc0$e5c7a340$@com> <3CFAED05-4FB9-4596-90A5-E73CB4DC717C@edvina.net> In-Reply-To: <3CFAED05-4FB9-4596-90A5-E73CB4DC717C@edvina.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.8.84219 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 10:11:37 -0000 Dear Olle, Thank you for the link. You might mention also the following: * IPv6 IP ABNF is not correct. Rules defined in RFC3986 should be used inst= ead for encoding IPv6 address in SIP URI. * For the comparison of SIP URIs enclosing an IPv6 address, the rules defin= ed in RFC3261 are broken; you need use those in RFC5954 * SIP Proxy Servers can not rely on the AoC to determine the IP capabilitie= s of the SIP UA. A candidate solution is documented in http://tools.ietf.or= g/html/draft-boucadair-dispatch-ipv6-atypes-00. * IPv6 SIP Torture Tests are documented in RFC5118.=20 For other points, we can discuss this offline. Cheers, Med=20 -----Message d'origine----- De : Olle E. Johansson [mailto:oej@edvina.net]=20 Envoy=E9 : mardi 8 mars 2011 10:59 =C0 : Dan Wing Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; v6ops@ietf.org Objet : Re: [v6ops] Happy Eyeballs and SIP 8 mar 2011 kl. 08.53 skrev Dan Wing: >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of Olle E. Johansson >> Sent: Monday, March 07, 2011 2:04 PM >> To: mohamed.boucadair@orange-ftgroup.com >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] Happy Eyeballs and SIP >>=20 >>=20 >> 7 mar 2011 kl. 13.51 skrev : >>=20 >>> Dear Olle, >>>=20 >>> For the SIP case, if you don't need connectivity checks (e.g., closed >> networks, which is in France the majority of SIP traffic) you can just >> use the ALTC attribute defined in http://tools.ietf.org/html/draft- >> boucadair-mmusic-altc-01. >> That is a simple fix for the media issue - and something I think >> developers can easily implement. We still have the issue with >> signalling and registrations. >>>=20 >>> In case connectivity checks are needed, a variant of the happy >> eyeballs for SIP (called Happy Eardrums) has been proposed in >> http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 but >> still you need to be sure you IPv4 connectivity is working ;-). >> Will look at this tomorrow... :-) >>=20 >> Thanks for the ALTC proposal. I am a bit hesitant to the ICE/TURN/SIP- >> outbound combo, it will take a long time to convince developers and the >> market to implement that package... >=20 > I agree that ICE is a big pill to swallow. (If we're talking only > IPv4/IPv6 selection, though, TURN is not part of that equation.) Turn is part of the whole IPv6 migration scenario according to the soon-to-= become-RFC. >=20 > However, industry experience with IPv6 on the Internet shows that > we cannot rely on the "we both have an IPv6 address, therefore we > have connectivty" assumption. There are IPv6 islands (on purpose > or on accident) which are permanent or temporary (failure of a=20 > link or a router), and because IPv4 is predominant the IPv6 failure > is not immediately noticed or corrected -- but impacts users > that support IPv6. Fully agree - that's why I'm insisting on the happy eyeballs approach :-) More info about IPv6 and SIP on http://edvina.net/sipv6 and http://www.face= book.com/sipv6 for those who wants to follow, help or point out my mistakes= in thoughts! I appreciate all feedback. Cheers /O >=20 > -d >=20 >> /O >>>=20 >>> Cheers, >>> Med >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la >> part de Olle E. Johansson >>> Envoy=E9 : lundi 7 mars 2011 10:40 >>> =C0 : v6ops@ietf.org >>> Objet : [v6ops] Happy Eyeballs and SIP >>>=20 >>> Hi! >>>=20 >>> Has anyone considered the issues covered in the happy-eyeballs draft >> for SIP? >>>=20 >>> A 19 or 32 second time out when placing a call is not a good user >> experience... I think this applies to SIP over TCP, and possibly also >> needs to be handled for UDP. >>> I don't see this handled in the draft for IPv6 transition in the >> Session Initiation Protocol (soon-to-be RFC 6157) >>>=20 >>> Seems like the scope of the happy eyeballs draft is HTTP, so the >> question is if this should be expanded or if we need other drafts for >> other protocols. >>>=20 >>> Regards, >>> /Olle >>>=20 >>> Ref: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>=20 >> *********************************************************************** >> ********* >>> IMPORTANT.Les informations contenues dans ce message electronique y >> compris les fichiers attaches sont strictement confidentielles >>> et peuvent etre protegees par la loi. >>> Ce message electronique est destine exclusivement au(x) >> destinataire(s) mentionne(s) ci-dessus. >>> Si vous avez recu ce message par erreur ou s il ne vous est pas >> destine, veuillez immediatement le signaler a l expediteur et effacer >> ce message >>> et tous les fichiers eventuellement attaches. >>> Toute lecture, exploitation ou transmission des informations >> contenues dans ce message est interdite. >>> Tout message electronique est susceptible d alteration. >>> A ce titre, le Groupe France Telecom decline toute responsabilite >> notamment s il a ete altere, deforme ou falsifie. >>> De meme, il appartient au destinataire de s assurer de l absence de >> tout virus. >>>=20 >>> IMPORTANT.This e-mail message and any attachments are strictly >> confidential and may be protected by law. This message is >>> intended only for the named recipient(s) above. >>> If you have received this message in error, or are not the named >> recipient(s), please immediately notify the sender and delete this e- >> mail message. >>> Any unauthorized view, usage or disclosure ofthis message is >> prohibited. >>> Since e-mail messages may not be reliable, France Telecom Group shall >> not be liable for any message if modified, changed or falsified. >>> Additionally the recipient should ensure they are actually virus >> free. >>>=20 >> *********************************************************************** >> ********* >>=20 >> --- >> * Olle E Johansson - oej@edvina.net >> * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From remi.despres@free.fr Tue Mar 8 03:05:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F6E3A67DA; Tue, 8 Mar 2011 03:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.192 X-Spam-Level: X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNbIFF+0v0n1; Tue, 8 Mar 2011 03:05:21 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by core3.amsl.com (Postfix) with ESMTP id 556AE3A6834; Tue, 8 Mar 2011 03:05:21 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 060517000082; Tue, 8 Mar 2011 12:06:35 +0100 (CET) Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 70B5E700008D; Tue, 8 Mar 2011 12:06:32 +0100 (CET) X-SFR-UUID: 20110308110634461.70B5E700008D@msfrf2216.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2011 12:06:31 +0100 Message-Id: <9D784E45-EC2C-4D11-8D92-1F5380CEA692@free.fr> To: Internet Area Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: v6ops Subject: [v6ops] New I-D on 4rd X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 11:05:22 -0000 Hello everybody, We have submitted tools.ietf.org/html/draft-despres-intarea-4rd-00 and = plan to present it and discuss it in Prague. It specifies the 4rd architecture and protocol for IPv4 Residual = Deployment across IPv6 (4rd). It is an update from the previous proposal addressed to Softwire for = IETF 79, but concluded there to be out of scope. Two other recent drafts refer to the 4rd specification: - tools.ietf.org/id/draft-matsushima-v6ops-transition-experience-00 - tools.ietf.org/id/draft-sun-intarea-4rd-applicability-00.txt Comments are most welcome. Regards, RD <<< Internet Engineering Task Force R. Despres, Ed. Internet-Draft RD-IPtech Intended status: Standards Track S. Matsushima Expires: September 8, 2011 SoftBank T. Murakami IP Infusion O. Troan Cisco March 7, 2011 IPv4 Residual Deployment across IPv6-Service networks (4rd) ISP-NAT's made optional draft-despres-intarea-4rd-00 Abstract This document specifies an automatic tunneling mechanism for providing IPv4 connectivity service to end users over a service provider's IPv6 network infrastructure. During the long transition period from IPv4-only to IPv6-only, a service provider's network infrastructure will have to deploy IPv6. But it will also have to maintain some IPv4 connectivity for a number of customers, for both outgoing and incoming connections, and for both customer-individual and shared IPv4 addresses. The 4rd solution (IPv4 Residual Deployment) is designed as a lightweight solution for this. In some scenarios, 4rd can dispense ISPs from supporting any NAT in their infrastructures. In some others it can be used in parallel with NAT-based solutions such as DS-lite and/or NAT64/DNS4.=20 ... Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Mapping Rules . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. =46rom an IPv6 Prefix to a 4rd Prefix . . . . . . . . . . . = 5 4.2. =46rom a 4rd Prefix longer than 32 bits to a Port-set ID . . = 6 4.3. =46rom a Port-Set ID to a Port Set . . . . . . . . . . . . . = 6 4.4. =46rom an IPv4 Address or IPv4 address + Port to a CE IPv6 address . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. MTU Considerations . . . . . . . . . . . . . . . . . . . . 9 5. 4rd Configuration . . . . . . . . . . . . . . . . . . . . . . 9 6. BR and CE behaviors . . . . . . . . . . . . . . . . . . . . . 10 6.1. Encapsulation and IPv6 Fragmentations . . . . . . . . . . 10 6.2. Domains having only One Mapping rule . . . . . . . . . . . 11 6.2.1. BR reception of an IPv4 packet . . . . . . . . . . . . 11 6.2.2. BR reception of an IPv4/IPv6 packet . . . . . . . . . 12 6.2.3. CE reception of an IPv4 packet . . . . . . . . . . . . 12 6.2.4. CE reception of an IPv4/IPv6 packet . . . . . . . . . 13 6.3. Domains having Multiple Mapping Rules (TBD) . . . . . . . 13 7. Security considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 >>> From Internet-Drafts@ietf.org Wed Mar 9 14:15:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7293A6AF8; Wed, 9 Mar 2011 14:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYebRbgQu9G3; Wed, 9 Mar 2011 14:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8DD3A6778; Wed, 9 Mar 2011 14:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110309221502.3599.40037.idtracker@localhost> Date: Wed, 09 Mar 2011 14:15:02 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-tunnel-loops-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 22:15:03 -0000 --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 : Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations Author(s) : G. Nakibly, F. Templin Filename : draft-ietf-v6ops-tunnel-loops-04.txt Pages : 26 Date : 2011-03-09 This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop which can be abused as a vehicle for traffic amplification to facilitate DoS attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-loops-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-v6ops-tunnel-loops-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-09141217.I-D@ietf.org> --NextPart-- From fred@cisco.com Wed Mar 9 15:08:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1A33A6781; Wed, 9 Mar 2011 15:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.422 X-Spam-Level: X-Spam-Status: No, score=-110.422 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgpD9NR8aoiv; Wed, 9 Mar 2011 15:08:47 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D8B2A3A6768; Wed, 9 Mar 2011 15:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=21698; q=dns/txt; s=iport; t=1299712205; x=1300921805; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=cnmUAX551LxsLbRyFmniHThCeu46xWlqRJ3dpnt4Gdc=; b=T4aTHNeSbzG06oxwfxLkHRPYRm6J+3nISfddCNrXd+/1Epdcn7vrtQNk p24z+H42yKYlhsH1gviS9/GGC5uyUEtuYfcB39SI4ul4HI/XwrHokyvpr eAHz8kPbJFtwgnm1+RlOQEJMYY94q2t8DDRPQlW1fpSD8VU170oXCgWhH 4=; X-IronPort-AV: E=Sophos;i="4.62,292,1297036800"; d="scan'208,217";a="666213935" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 09 Mar 2011 23:10:04 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p29NA4k7026048; Wed, 9 Mar 2011 23:10:04 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-830--717543153 From: Fred Baker In-Reply-To: <763486.51211.qm@web161616.mail.bf1.yahoo.com> Date: Wed, 9 Mar 2011 15:10:03 -0800 Message-Id: <38B5E8D4-E858-4B97-9367-D4C0AF700531@cisco.com> References: <763486.51211.qm@web161616.mail.bf1.yahoo.com> To: Fred Templin X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG , draft-ietf-v6ops-tunnel-loops@tools.ietf.org, The IESG , Stewart Bryant Subject: Re: [v6ops] New draft version (was: Re: Stewart Bryant's Discuss on draft-ietf-v6ops-tunnel-loops-03: (with DISCUSS)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 23:08:49 -0000 --Apple-Mail-830--717543153 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Well, as you requested, we'll discuss the updates at IETF-80 in the = working group, and then advise the AD to continue if the working group = buys into the updated draft. On Mar 9, 2011, at 2:30 PM, Fred Templin wrote: > Hello, >=20 > We have submitted a -04 draft version: >=20 > = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-loops-04.txt >=20 > Changes in this version are: >=20 > 1) Section 1: clarification that only non-link-local prefixes are = vulnerable, since > link-locals cannot be forwarded by an IPv6 router. >=20 > 2) Section 2: text and diagram updates to clarify packet flows >=20 > 3) New Section 3.2.4 added. >=20 > Items 1) and 2) above represent only very minor changes to what has = already > been reviewed by this distribution. Item 3) however includes a major = new > section with a mitigation that avoids the looping scenario by not = assigning > non-link-local IPv6 prefixes to the tunnel. This method is available = only to > ISATAP, and requires updates to RFC5214. >=20 > Please advise as to next steps, >=20 > Fred & Gabi >=20 > From: Fred Templin > To: Gabi Nakibly ; stbryant@cisco.com > Cc: The IESG ; v6ops-chairs@tools.ietf.org; = draft-ietf-v6ops-tunnel-loops@tools.ietf.org > Sent: Tue, February 22, 2011 5:31:27 AM > Subject: Re: Stewart Bryant's Discuss on = draft-ietf-v6ops-tunnel-loops-03: (with DISCUSS) >=20 > Hi Gabi, >=20 > As we are working on a major new subsection for the document that may = well > address the remaining concerns, I would rather we not press Stewart or = the > other reviewers until we agree on a way forward after I return from my = vacation > on 2/28 - OK? >=20 > Thanks - Fred >=20 > From: Gabi Nakibly > To: stbryant@cisco.com > Cc: The IESG ; v6ops-chairs@tools.ietf.org; = draft-ietf-v6ops-tunnel-loops@tools.ietf.org > Sent: Mon, February 21, 2011 9:17:22 AM > Subject: Re: Stewart Bryant's Discuss on = draft-ietf-v6ops-tunnel-loops-03: (with DISCUSS) >=20 > Hi Stewart, > We have yet to receive from you a response to our last email. >=20 > Gabi=20 >=20 >=20 >=20 > ----- Original Message ---- > > From: Gabi Nakibly > > To: stbryant@cisco.com > > Cc: The IESG ; v6ops-chairs@tools.ietf.org;=20 > >draft-ietf-v6ops-tunnel-loops@tools.ietf.org > > Sent: Sun, February 13, 2011 8:48:37 PM > > Subject: Re: Stewart Bryant's Discuss on = draft-ietf-v6ops-tunnel-loops-03:=20 > >(with DISCUSS) > >=20 > > Hi Stewart, > >=20 > > >So are you saying that R1 lies to R2 about what it can reach, then = when R1=20 >=20 > > >actually gets a packet addressed to the address it lied about, = it forwards=20 >=20 > > >the packet to another router? > >=20 > > No. This is not what we are saying. Let me try again. R2 receives = an IPv6=20 > > attack packet (this is packet #0 in the draft). The IPv6 destination = address of=20 > > > > the packet has the prefix of T2. This is why R2 automatically = encapsulates the=20 >=20 > > packet with the corresponding IPv4 destination address and forwards = it. It does=20 > > > > so while not being aware of the fact that a node with that IPv6 = destination=20 > > address does not exist. The attacker chooses this IPv6 address so = that the=20 > > corresponding IPv4 address will be that of R1. R1 is passive. In = particular it=20 >=20 > > does not lie about its IPv6 reachability. Once the packet reaches R1 = it=20 > > decapsulates it and examines the IPv6 destination address. Since = this address=20 > >is=20 > > > > not its own it forwards it. > >=20 > > > > > >Of course that will form a loop, and the fix is either (preferably) = for R1=20 >=20 > > >not to tell lies, or if it must tell lies, to have the good = grace to drop=20 > > >the packet who's address it lied about. That is just routing = 101. > > > > > >However the problem with the original sentence is that it is not = parsable > > >English. =20 > > > > > > > > >Are you saying: > > > > > >The attacker exploits the fact that R2 is unaware that R1 is = indicating=20 > > >reachability for an address (a subset of the prefix it is ) that = it is=20 > > >actually unable to reach. > > > > > >or maybe=20 > > > > > >Although R1 is indicating to R2 that it can reach a prefix (T2), = unbeknown=20 >=20 > > >to R2, R1 can only actually reach a subset of the addresses = contained=20 > >within=20 > > > > > > > >that prefix. The attacker exploits the fact that under these = circumstances=20 > > > >=20 > > >R1 will forward the unreachable packets that it claimed it could = reach into=20 > > > >=20 > > >a part of the network such that they will loop back to R1. > > > > >=20 > > >You have two diagrams - a connectivity diagram and an encapsulation > > >diagram. It would be a lot clearer if you had a single diagram > > >showing the packet at each stage of its lifecycle round the loop. = Then > > >of course words to match. > > > > > >At the moment the reader needs to hold too much in your head to = see what=20 > >is=20 > > > > > > > >happening. > >=20 > > To make this easier to read we shall add the packet ids on Figure 1 = and their=20 > > direction in which they traverse. > > > > > >Yes, but a router must never advertise an address that it cannot = reach=20 > > >(period). > >=20 > > As I said above, R1 does not advertise an IPv6 prefix (at least not = one that=20 > > relates to the attack). R2 advertises an IPv6 prefix as assigned to = him by the=20 >=20 > > administrator. This advertisement is valid since R2 can reach hosts = having=20 > > addresses within this prefix. However, as all other routers on the = Internet it=20 >=20 > > does not check whether all the addresses of this prefix are indeed = assigned to=20 >=20 > > valid hosts. The attacker takes advantage of the fact that there are = some=20 > > addresses (at least one) in this prefix which are not assigned to = valid hosts. > >=20 > >=20 > >=20 > = >_________________________________________________________________________= ___________ > >_ > > Sucker-punch spam with award-winning protection.=20 > > Try the free Yahoo! Mail Beta. > > http://advision.webevents.yahoo.com/mailbeta/features_spam.html > >=20 >=20 >=20 >=20 --Apple-Mail-830--717543153 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Well, as you requested, we'll discuss the updates = at IETF-80 in the working group, and then advise the AD to continue if = the working group buys into the updated draft.

On Mar = 9, 2011, at 2:30 PM, Fred Templin wrote:

Hello,

We have = submitted a -04 draft version:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-loops-= 04.txt

Changes in this version are:

  1) = Section 1: clarification that only non-link-local prefixes are = vulnerable, since
      link-locals cannot be = forwarded by an IPv6 router.

  2) Section 2: text and = diagram updates to clarify packet flows

  3) New Section = 3.2.4 added.

Items 1) and 2) above represent only very minor = changes to what has already
been reviewed by this distribution. Item = 3) however includes a major new
section with a mitigation that avoids = the looping scenario by not assigning
non-link-local IPv6 prefixes to = the tunnel. This method is available only to
ISATAP, and requires = updates to RFC5214.

Please advise as to next steps,

Fred = & Gabi

From: Fred Templin <fltemplin@yahoo.com>
To: Gabi Nakibly <gnakibly@yahoo.com>; stbryant@cisco.com
Cc: The IESG <iesg@ietf.org>; v6ops-chairs@tools.ietf.org; draft-ietf-v6= ops-tunnel-loops@tools.ietf.org
Sent: Tue, February 22, 2011 = 5:31:27 AM
 Re: Stewart Bryant's = Discuss on draft-ietf-v6ops-tunnel-loops-03: (with = DISCUSS)

Hi = Gabi,

As we are working on a major new subsection for the = document that may well
address the remaining concerns, I would rather = we not press Stewart or the
other reviewers until we agree on a way = forward after I return from my vacation
on 2/28 - OK?

Thanks - = Fred

From: Gabi Nakibly <gnakibly@yahoo.com>
To: stbryant@cisco.com
Cc: The IESG <iesg@ietf.org>; v6ops-chairs@tools.ietf.org; draft-ietf-v6= ops-tunnel-loops@tools.ietf.org
Sent: Mon, February 21, 2011 = 9:17:22 AM
 Re: Stewart Bryant's = Discuss on draft-ietf-v6ops-tunnel-loops-03: (with = DISCUSS)

Hi Stewart,
We have yet = to receive from you a response to our last = email.

Gabi 



----- Original Message = ----
> From: Gabi Nakibly <gnakibly@yahoo.com>
> = To: stbryant@cisco.com
> Cc: = The IESG <iesg@ietf.org>; v6ops-chairs@tools.ietf.org; 
>draft-ietf-v6= ops-tunnel-loops@tools.ietf.org
> Sent: Sun, February 13, 2011 = 8:48:37 PM
> Subject: Re: Stewart Bryant's Discuss on = draft-ietf-v6ops-tunnel-loops-03: 
>(with = DISCUSS)
> 
> Hi = Stewart,
> 
> >So are you = saying that R1 lies to R2 about what it can reach, then    = when R1 

> = >actually gets a packet addressed to the address it lied    = about, it forwards 

> >the packet = to another router?
> 
> No. This is not = what we are saying. Let me try again.  R2 receives an IPv6 
> attack packet = (this is packet #0 in the draft). The IPv6 destination address of 
>
> the packet = has the prefix of T2. This is why R2 automatically encapsulates the 

> packet with = the corresponding IPv4 destination address and forwards it. It does 
>
> so while = not being aware of the fact that a node with that IPv6 destination 
> address does not = exist. The attacker chooses this IPv6 address so that the 
> corresponding IPv4 = address will be that of R1. R1 is passive. In particular it 

> does not lie = about its IPv6 reachability. Once the packet reaches R1 it 
> decapsulates it = and examines the IPv6 destination address. Since this address 
>is 
>
> not its = own it forwards it.
> 
> >
> = >Of course that will form a loop, and the fix is either = (preferably)    for R1 

> >not to = tell lies, or if it must tell lies, to have the good    grace = to drop 
> = >the packet who's address it lied about. That is just    = routing 101.
> >
> >However the problem with the = original sentence is that it is not    parsable
> = >English.  
> >
> = >
> >Are you saying:
> >
> >The attacker = exploits the fact that R2 is unaware that R1 is    = indicating 
> = >reachability for an address (a subset of the prefix it is  =   ) that it is 
> >actually = unable to reach.
> >
> >or maybe 
> >
> = >Although R1 is indicating to R2 that it can reach a prefix = (T2),    unbeknown 

> >to R2, R1 = can only actually reach a subset of the    addresses = contained 
>within 
>
> = >
> >that  prefix. The attacker exploits the  =   fact that under these circumstances 
>
> 
> >R1 will = forward the unreachable    packets that it claimed it could = reach into 
>
> 
> >a part of the = network    such that they will loop back to R1.
> = >
> 
> = >You have two diagrams - a connectivity diagram and an = encapsulation
> >diagram. It would be a lot clearer if you had = a single diagram
> >showing the packet at each stage of its = lifecycle round the loop.    Then
> >of course words = to match.
> >
> >At the moment the reader  needs = to hold too much in your head to see    what 
>is 
>
> = >
> >happening.
> 
> To make this = easier to read we shall add the packet ids on Figure 1 and their 
> direction in which = they traverse.
> >
> >Yes, but a router must never = advertise an address that it cannot    reach 
> = >(period).
> 
> As I said above, = R1 does not advertise an IPv6 prefix (at least not one that 
> relates to the = attack). R2 advertises an IPv6 prefix as assigned to him by the 

> administrator. = This advertisement is valid since R2 can reach hosts having 
> addresses within = this prefix. However, as all other routers on the Internet it 

> does not check = whether all the addresses of this prefix are indeed assigned to 

> valid hosts. = The attacker takes advantage of the fact that there are some 
> addresses (at = least one) in this prefix which are not assigned to valid = hosts.
> 
> 
> 
>_____________________= _______________________________________________________________
>_> Sucker-punch spam with award-winning protection. 
> Try the free = Yahoo! Mail Beta.
> h= ttp://advision.webevents.yahoo.com/mailbeta/features_spam.html
>=  



<= /div>

= --Apple-Mail-830--717543153-- From satoru.matsushima@gmail.com Thu Mar 10 02:03:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B8D3A68F6 for ; Thu, 10 Mar 2011 02:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctIU6escWW3S for ; Thu, 10 Mar 2011 02:03:24 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 8768A3A689A for ; Thu, 10 Mar 2011 02:03:20 -0800 (PST) Received: by iyj8 with SMTP id 8so1726507iyj.31 for ; Thu, 10 Mar 2011 02:04:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=UNzCet7VTEI+NonIfAiWhqjQzsv5sYHCul3A0uc5F7A=; b=F3xK0tEcgaGOT08JJDGYJYtL+uhfsEwpbtELA0Rh+RfmWlUzgSD4ZbBhaD+cHqQy3A bTb0clmaZzSwHsqPNxIIaMvAI3jI6v2yAg4ZCtsIUDrLfiTYRb56v3Fwb0l6SNRSVztP 46sbRZUGTama1KHb1+7tWyO6IWQVoGtaOaACE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Preu3TvyQ6Ig5D//o798exKCN8n4nrmuAfq8Rk2Ib5ZALPoo1ai+b4hmekgqBNFGwm OKJXnur/O2eoW8bw14n9ukyojN0dkgTCDfzY9zI9cKAz2Bz6cdNW5DqQ4A3wEydshOYj Csdh+V+IP98yfbskDawixrkoe6Y5ucD4B8XTw= Received: by 10.43.69.132 with SMTP id yc4mr9901578icb.221.1299751477862; Thu, 10 Mar 2011 02:04:37 -0800 (PST) Received: from [10.201.81.18] ([202.45.12.174]) by mx.google.com with ESMTPS id y8sm2138208ica.2.2011.03.10.02.04.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Mar 2011 02:04:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <4D715EDD.40403@bogus.com> Date: Thu, 10 Mar 2011 19:04:32 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E87AEAD-8476-499E-8946-C8E31D2E21E9@cisco.com> <4D715EDD.40403@bogus.com> To: Joel Jaeggli , Fred Baker , IPv6 WG Ops X-Mailer: Apple Mail (2.1082) Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-multihoming-without-nat66 WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 10:03:24 -0000 Fred, Joel, Brian, Bob, Randy, Teemu, Tom and all, Thanks to all of you for your review and useful feedback during the last = call. We're working on the draft to update with the feedback so then we'll = post a revised version. Best regards, -- Satoru Matsushima On 2011/03/05, at 6:51, Joel Jaeggli wrote: > Just a reminder this working-group last call ends to the 10th. >=20 > joel >=20 > On 2/24/11 5:18 AM, Fred Baker wrote: >> This is to initiate a two week working group last call of >> draft-ietf-v6ops-multihoming-without-nat66. Please read it now. If >> you find nits (spelling errors, minor suggested wording changes, >> etc), comment to the authors; if you find greater issues, such as >> disagreeing with a statement or finding additional issues that need >> to be addressed, please post your comments to the list. >>=20 >> We are looking specifically for comments on the importance of the >> document as well as its content. If you have read the document and >> believe it to be of operational utility, that is also an important >> comment to make. _______________________________________________=20 >> v6ops mailing list v6ops@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Sun Mar 13 13:40:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16A1F3A6A51 for ; Sun, 13 Mar 2011 13:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.444 X-Spam-Level: X-Spam-Status: No, score=-103.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48Fg0paI-xP1 for ; Sun, 13 Mar 2011 13:40:08 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id AB2193A6A7C for ; Sun, 13 Mar 2011 13:40:07 -0700 (PDT) Received: by ywi6 with SMTP id 6so2396377ywi.31 for ; Sun, 13 Mar 2011 13:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=okIJwipSkJhaanlMz7IsNopXKgjJTap8Tgve1YPixas=; b=UgOoE3CzB2cTM97QivrZLkT8jbjecsMX1tIkWwYhdAm5ek4RSQUkI4wDghXQ9o4ty7 DlTZV2ojBqeXY2WB0RdHgwH2nZe+cF3Jc+kv5JWG1lPBPuH/WXwoD105usWMewpaz4UM J2rb6+J7vlibtgctY9fapDU4yq98NnKd7ukLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=gTKGhgKr6Mlw9gfAr+FlUEarJ0MHWPVeEcMCQZmQFHjAkUMg9xzMlTeR3rgJCsvZU9 BmEU3JxmHS/2NiXzzDVLhGfDqSrMv13TYJR+Qd2GwU9xKOoqxHiHQgqIpJcuRetKAy+e DiP7WLJaAq5GdV+uLuqBMCB3/8AeFjPhIzBj0= Received: by 10.236.139.233 with SMTP id c69mr5690282yhj.141.1300048889859; Sun, 13 Mar 2011 13:41:29 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id y21sm4681782yhc.18.2011.03.13.13.41.27 (version=SSLv3 cipher=OTHER); Sun, 13 Mar 2011 13:41:28 -0700 (PDT) Message-ID: <4D7D2BF5.9020400@gmail.com> Date: Mon, 14 Mar 2011 09:41:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: v6ops@ietf.org References: <20110305184502.18531.25548.idtracker@localhost> In-Reply-To: <20110305184502.18531.25548.idtracker@localhost> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 20:40:09 -0000 Hi, > 3. Conceptual Configuration Variables > > The CE Router maintains such a list of conceptual optional > configuration variables. > > 1. Enable an IGP on the LAN. This section seems very strange with just one item sitting there on its own, and no discussion in the draft of which IGPs are candidates for support. > 5.1. DNS > > D-1: For local DNS queries for configuration, the CE Router MAY > include a DNS server to handle local queries. What is the reason to include the words "for configuration"? What is the meaning of "local queries"? Is this intended to imply that there are names such as printer1.example.com that are only meaningful and visible "inside" the CPE boundary? If so, what is the domain name? Is the CPE supposed to know an appropriate domain name and if so, how? > D-2: The local DNS server MAY also handle renumbering from the > Service Provider provided prefix for local names used > exclusively inside the home (the local AAAA and PTR records are > updated). This capability provides connectivity using local > DNS names in the home after a Service Provider renumbering. A This is the only mention of renumbering in the draft. Is renumbering support a goal? If so, please look at draft-jiang-ipv6-site-renum-guideline. It is clearly not enough to just mention it as part of DNS support. > CE Router MAY add local DNS entries based on dynamic requests > from the LAN segment(s). The protocol to carry such requests > from hosts to the CE Router is yet to be described. Surely it should be RFC 3007? > LNDP-1: If the CE Router has only one /64 prefix to be used across > multiple LAN interfaces and the CE Router supports any two > LAN interfaces that cannot bridge data between them because > the two interfaces have disparate MAC layers, then the CE > Router MUST support Proxying Neighbor Advertisements as > specified in Section 7.2.8 of [RFC4861]. If any two LAN > interfaces support bridging between the interfaces, then > Proxying Neighbor Advertisements is not necessary between > the two interfaces. Legacy 3GPP networks have the following > requirements: There needs to be a paragraph break before "Legacy 3GPP..." Just below: > 4. No NAT66 is to be used. Is this referring to NPTv6 or something else? It's important to be clear, since trying to stop stateful NAPT66 is one battle, and trying to stop NPTv6 is another. > The IPv6 CE Router SHOULD implement DS-Lite functionality as > specified in [I-D.ietf-softwire-dual-stack-lite]. ... > The IPv6 CE Router SHOULD implement 6rd functionality as specified in > [RFC5969]. I'm really not sure about these SHOULDs. It's not they are bad things to include, but there may be situations where they are insufficient and some other form of tunnel is needed. At the very least say that other backhaul tunnel mechanisms MAY be supported, without specifying them. Then add a corresponding point in the next section: > 5.5.3. Transition Technologies Coexistence > > Run the following four in parallel to provision CPE router > connectivity to the Service Provider: > > 1. Initiate IPv4 address acquisition. > > 2. Initiate IPv6 address acquisition as specified by > [I-D.ietf-v6ops-ipv6-cpe-router]. > > 3. If 6rd is provisioned, initiate 6rd. > > 4. If DS-Lite is provisioned, initiate DS-Lite. If this procedure fails, some other form of tunnel MAY be initiated. Also, I think section 5.5.3 should recommend that the CPE be configurable to block protocol 41 v6-in-v4 mechanisms when IPv6 connectivity is available. > 6. Security Considerations > > None. I think you need a few more words there, e.g. This document introduces no security concerns that are not discussed in the referenced specifications. Finally, idnits shows about 20 unused references. Regards Brian Carpenter From tom111.taylor@bell.net Sun Mar 13 16:09:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1D33A6BE4 for ; Sun, 13 Mar 2011 16:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.156 X-Spam-Level: X-Spam-Status: No, score=-101.156 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eVlLSswnmmw for ; Sun, 13 Mar 2011 16:09:39 -0700 (PDT) Received: from blu0-omc4-s35.blu0.hotmail.com (blu0-omc4-s35.blu0.hotmail.com [65.55.111.174]) by core3.amsl.com (Postfix) with ESMTP id 8CD533A6BBD for ; Sun, 13 Mar 2011 16:09:39 -0700 (PDT) Received: from BLU0-SMTP87 ([65.55.111.137]) by blu0-omc4-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 16:11:01 -0700 X-Originating-IP: [174.94.11.167] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([174.94.11.167]) by BLU0-SMTP87.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 16:11:01 -0700 Date: Sun, 13 Mar 2011 19:11:01 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <24436_1299502310_4D74D4E6_24436_185484_1_94C682931C08B048B7A8645303FDC9F33C4DA50BCA@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <24436_1299502310_4D74D4E6_24436_185484_1_94C682931C08B048B7A8645303FDC9F33C4DA50BCA@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Mar 2011 23:11:01.0307 (UTC) FILETIME=[EB59C8B0:01CBE1D3] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 23:09:40 -0000 Mind, altc has been rejected by RAI area. The official solution is to use ICE or ICE Lite. On 07/03/2011 7:51 AM, mohamed.boucadair@orange-ftgroup.com wrote: > Dear Olle, > > For the SIP case, if you don't need connectivity checks (e.g., closed > networks, which is in France the majority of SIP traffic) you can > just use the ALTC attribute defined in > http://tools.ietf.org/html/draft-boucadair-mmusic-altc-01. > > In case connectivity checks are needed, a variant of the happy > eyeballs for SIP (called Happy Eardrums) has been proposed in > http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 but > still you need to be sure you IPv4 connectivity is working ;-). > > Cheers, Med > > > -----Message d'origine----- De : v6ops-bounces@ietf.org > [mailto:v6ops-bounces@ietf.org] De la part de Olle E. Johansson > Envoyé : lundi 7 mars 2011 10:40 À : v6ops@ietf.org Objet : [v6ops] > Happy Eyeballs and SIP > > Hi! > > Has anyone considered the issues covered in the happy-eyeballs draft > for SIP? > > A 19 or 32 second time out when placing a call is not a good user > experience... I think this applies to SIP over TCP, and possibly also > needs to be handled for UDP. I don't see this handled in the draft > for IPv6 transition in the Session Initiation Protocol (soon-to-be > RFC 6157) > > Seems like the scope of the happy eyeballs draft is HTTP, so the > question is if this should be expanded or if we need other drafts for > other protocols. > > Regards, /Olle > > Ref: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07 > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > ******************************************************************************** > > IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. Ce message electronique est > destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas > destine, veuillez immediatement le signaler a l expediteur et > effacer ce message et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations > contenues dans ce message est interdite. Tout message electronique > est susceptible d alteration. A ce titre, le Groupe France Telecom > decline toute responsabilite notamment s il a ete altere, deforme ou > falsifie. De meme, il appartient au destinataire de s assurer de l > absence de tout virus. > > IMPORTANT.This e-mail message and any attachments are strictly > confidential and may be protected by law. This message is intended > only for the named recipient(s) above. If you have received this > message in error, or are not the named recipient(s), please > immediately notify the sender and delete this e-mail message. Any > unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall > not be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus > free. > ******************************************************************************** > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From shemant@cisco.com Sun Mar 13 19:06:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B33C3A6ABF for ; Sun, 13 Mar 2011 19:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.091 X-Spam-Level: X-Spam-Status: No, score=-11.091 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBflIYyPmby1 for ; Sun, 13 Mar 2011 19:06:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7B9893A6ACA for ; Sun, 13 Mar 2011 19:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2480; q=dns/txt; s=iport; t=1300068497; x=1301278097; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=3C8u7Ms+27gJaPOOMKnBLMJXBjOCUd45qa+C/Pwv7yA=; b=aGnplX/Fao0DivUTEDbOShIMKjoJ2eFYdAxQYX2t5txGbGsztrsiR8rm 5qpsM7CLXF8fOfMdl1ZS+3dTJHCosLRHQLHG5DwryKKtI6EusEFVI1cpc /T+wkRsMv3Rp0mT5Ekg1mqaOfIfg8JQ8Q+pCDLGqPxhm+/xwy4ZVoJuWw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAF4VfU2tJV2Z/2dsb2JhbACYP41Qd6UMmnGFYgSFK4p7 X-IronPort-AV: E=Sophos;i="4.62,312,1297036800"; d="scan'208";a="345597545" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-5.cisco.com with ESMTP; 14 Mar 2011 02:08:17 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2E28Gmv019162; Mon, 14 Mar 2011 02:08:16 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 21:08:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Mar 2011 21:08:14 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B67E@XMB-RCD-109.cisco.com> In-Reply-To: <4D7D2BF5.9020400@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvhvxHWihCdeoFqQzWppsfT1BCrCQAJpASA References: <20110305184502.18531.25548.idtracker@localhost> <4D7D2BF5.9020400@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" , X-OriginalArrivalTime: 14 Mar 2011 02:08:16.0646 (UTC) FILETIME=[AE81BA60:01CBE1EC] Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 02:06:55 -0000 Brain, Thanks much for the review. I have responded to some of your comments below. Will send another email replying to your other comments. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Sunday, March 13, 2011 4:41 PM To: v6ops@ietf.org Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >This section seems very strange with just one item sitting >there on its own, and no discussion in the draft of which >IGPs are candidates for support. The section is a placeholder for any more variables to be added in future. Anyway, the document shies away from recommending any specific IGP in the LAN to avoid religious wars for one's favorite IGP. Old IPv4 routers do support RIP, so one IGP we could recommend is RIPng. However soon as we recommend RIPng, someone will say, no, they want OSPFv3. That is why the document is silent on what specific IGP. >What is the reason to include the words "for configuration"? By configuration we mean accessing the CE router using http. Further some other auto-configuration of the CE router in the routed LAN domains is also possible if the CE router supports a recursive DNS server. Note zeroconf works only in the IPv6 link-local domain.=20 >This is the only mention of renumbering in the draft. Is renumbering support >a goal? If so, please look at draft-jiang-ipv6-site-renum-guideline. >It is clearly not enough to just mention it as part of DNS support. RFC 3633 is already specified in the Basic IPv6 CE Router document and RFC 3633 discusses using the DHCPv6 Reconfigure message for renumbering. Thus this Advanced document does not discuss any more renumbering. However, since DNS was not included in the IPv6 CE Router document and DNS is impacted by renumbering, we have provided some text. Also, the document tries to avoid proposing any solution that is in draft form; we try and include solutions in RFC form. Thanks for the draft reference though. I will look at it. >There needs to be a paragraph break before "Legacy 3GPP..." Agreed. >I think you need a few more words there, e.g. >This document introduces no security concerns that are >not discussed in the referenced specifications. Agreed. Will add some text. >Finally, idnits shows about 20 unused references. We will remove these unused references. Thanks much, Hemant From brian.e.carpenter@gmail.com Sun Mar 13 19:58:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA643A6C32 for ; Sun, 13 Mar 2011 19:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.446 X-Spam-Level: X-Spam-Status: No, score=-103.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-2WyhXXv2IP for ; Sun, 13 Mar 2011 19:58:38 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id C71183A6C30 for ; Sun, 13 Mar 2011 19:58:37 -0700 (PDT) Received: by qwg5 with SMTP id 5so1222207qwg.31 for ; Sun, 13 Mar 2011 20:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Jva1Axh8CEECZP6hPdGcHf9UW67COJbSGVA+2LmzmD0=; b=lt7g3Y7fK7U3NvFcVgbDrt06PhFGML7dZIOsP92X5lH/m7YxYw1b7FvrQkORi3T/8U pN9SwnrlDDy6SS+elISSwMBCCfJ61fg/kFVeOy9sHAF1eeuyV/MZhUCQZ/rp1hDamL4d 9CCeTxbf84IM0g0XJtCp9ieDphBSdTH8T/v+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=bH/rXjEt3vZe6aF7XzpR7IeotSFDSvmpoOReTJ2OrBVPZi3hpm4Vnoyk9cD1Ym2AmW K/WcUc/dhjOMFfiUScbAZ2TqMSBa8NvlOMiBDUsmuEnyT3CnSTkrIJRW9bzhVkF73OxT WUcI+5EgSuvj6ZNAPqakG57A1O07yWhtx+9U8= Received: by 10.224.9.77 with SMTP id k13mr10575909qak.1.1300071600600; Sun, 13 Mar 2011 20:00:00 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id c27sm2464329qck.34.2011.03.13.19.59.59 (version=SSLv3 cipher=OTHER); Sun, 13 Mar 2011 20:00:00 -0700 (PDT) Message-ID: <4D7D84AC.40705@gmail.com> Date: Mon, 14 Mar 2011 15:59:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <20110310073001.29755.70784.idtracker@localhost> In-Reply-To: <20110310073001.29755.70784.idtracker@localhost> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action:draft-troan-v6ops-6to4-to-historic-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 02:58:39 -0000 Hi, There's a slight improvement in that this version actually mentions the culprit, RFC 3068. But that has been forgotten in the "Obsoletes: (if approved)" header. However, I still don't think it should be approved. For a start, this is untrue: > The IPv6 transitioning mechanism "Connection of IPv6 Domains via IPv4 > Clouds (6to4) described in [RFC3056] and the extension in "An Anycast > Prefix for 6to4 Relay Routers" RFC3068 [RFC3068] have been shown to > have severe practical problems being used in the Internet. Actually the mechanism described in RFC 3056 has, as far as I know, never been seriously deployed. The operational problems are analysed at some length in draft-carpenter-v6ops-6to4-teredo-advisory (based on input from about 20 people) and as far as I can see they are due to the RFC 3068 anycast mechanism, inappropriate firewall behaviour, use of bogon address space, or failure to follow the rules of RFC 3056 about announcing 2002::/16. In that situation, I can't see any justification for obsoleting RFC 3056, and I think our cycles are better spent on advising people how to configure things properly. I tend to agree that new implementations of RFC 3068 will not be helpful. But is that a real risk? Regards Brian Carpenter From newbery@gmail.com Sun Mar 13 20:41:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FEB13A6C17 for ; Sun, 13 Mar 2011 20:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehIVmHly6Sbg for ; Sun, 13 Mar 2011 20:41:09 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id E88F13A6B54 for ; Sun, 13 Mar 2011 20:41:08 -0700 (PDT) Received: by yic13 with SMTP id 13so2468755yic.31 for ; Sun, 13 Mar 2011 20:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:mime-version:content-type:subject:date :in-reply-to:to:references:message-id:x-mailer; bh=jSjoBDWfjGRjAreP4GRO5zO0YXtj6di1J6URGHJ11mI=; b=c8gg3lBLx9mrH4sbJZCpfl+KuIjqbex6Rcjr7ipPfKblltn/O2wGoHJz0NZPH1zp5q pA6Hbr5AFPV+3hTAGkelN2m3ysIS5kTYe32GRwOLAENg+8EVjvT2Z3leZOLgj9DY5DPw DkWkWUKkTVBraY39mZ2zhuDT89HNpQGWX5lo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=eiKA8cj3cYFG7uEJ4qC5JB4N0PYZJd/cE7g+TwuYrgxf9WMWZUPRX3wiKmMSH43Slv RfAKuZWfeI2jLR5ohls3+Qtkm0F96cfPlWKb5zz62k3u3Hl/74CDtk/QSqEr9IptLNvr FsAjvOvKZZGuBVGy/eXDdPrM0zsn4wkmESG0c= Received: by 10.151.29.21 with SMTP id g21mr5410650ybj.66.1300074151689; Sun, 13 Mar 2011 20:42:31 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id p33sm1641797ybk.2.2011.03.13.20.42.29 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Mar 2011 20:42:30 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-2--355601529; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 14 Mar 2011 16:42:25 +1300 In-Reply-To: <20110305184502.18531.25548.idtracker@localhost> To: IPv6 Ops WG References: <20110305184502.18531.25548.idtracker@localhost> Message-Id: <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> X-Mailer: Apple Mail (2.1082) Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 03:41:10 -0000 --Apple-Mail-2--355601529 Content-Type: multipart/alternative; boundary=Apple-Mail-1--355601600 --Apple-Mail-1--355601600 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 6/03/2011, at 7:45 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations Working Group of the = IETF. >=20 >=20 > Title : Advanced Requirements for IPv6 Customer Edge = Routers > Author(s) : H. Singh, et al. > Filename : draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > Pages : 16 > Date : 2011-03-05 >=20 > This document continues the work undertaken by the IPv6 CE Router > Phase I work in the IETF v6ops Working Group. Advanced requirements > or Phase II work is covered in this document. The diagram and the text do not seem to allow explicitly for multihoming = to more than one service provider. You refer to an IGP (only) in section 3.1. If the CPE router is not = multihomed, why bother running an IGP on it at all? It is unlikely that = the service provider will listen to any routing advertisements you = generate. There is only a binary choice for the default route: it's = there or it isn't, and that can be propagated to the LAN without needing = a full IGP. If you do allow for mulithoming though, then the CPE router surely needs = to run BGP----and have rather a lot of memory :) > D-1: For local DNS queries for configuration, the CE Router MAY > include a DNS server to handle local queries. Non-local > queries can be forwarded unchanged to a DNS server specified = in > the DNS server DHCPv6 option.=20 If the intent was to handle ".local", I thought that this was in = conflict with mDNS as it is generally implemented. If the intent is to = optional offer a lightweight DNS server built into the CPE-router then I = think that's what should be stated in the RFC, explicitly. And is that's = the case, what are its constraints? Is it authoritative for the user's = home domain (with all that implies); is is a caching only server; is it = a stealth server; is it a hidden primary? If however the desire is simply ".local" service, then why not just = suggest mDNS, possibly with provision for static entries to support = devices that can't do mDNS themselves.= --Apple-Mail-1--355601600 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Internet-Drafts@ietf.org = wrote:
A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the IPv6 = Operations Working Group of the IETF.


Title =           : Advanced = Requirements for IPv6 Customer Edge Routers
Author(s) =       : H. Singh, et al.
Filename =        : = draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt
Pages =           : = 16
= Date =            : = 2011-03-05

This document continues the work undertaken by the = IPv6 CE Router
Phase I work in the IETF v6ops Working Group. =  Advanced requirements
or Phase II work is covered in this = document.

The diagram and the text = do not seem to allow explicitly for multihoming to more than one service = provider.

You refer to an IGP (only) in section = 3.1. If the CPE router is not multihomed, why bother running an IGP on = it at all? It is unlikely that the service provider will listen to any = routing advertisements you generate. There is only a binary choice for = the default route: it's there or it isn't, and that can be propagated to = the LAN without needing a full IGP.

If you do = allow for mulithoming though, then the CPE router surely needs to run = BGP----and have rather a lot of memory = :)

   D-1:  For =
local DNS queries for configuration, the CE Router MAY
         include a DNS server to handle local queries.  Non-local
         queries can be forwarded unchanged to a DNS server specified in
         the DNS server DHCPv6 option.
If = the intent was to handle ".local", I thought that this was in conflict = with mDNS as it is generally implemented. If the intent is to optional = offer a lightweight DNS server built into the CPE-router then I think = that's what should be stated in the RFC, explicitly. And is that's the = case, what are its constraints?  Is it authoritative for the user's = home domain (with all that implies); is is a caching only server; is it = a stealth server; is it a hidden = primary?

If however the desire is simply = ".local" service, then why not just suggest mDNS, possibly with = provision for static entries to support devices that can't do mDNS = themselves.
= --Apple-Mail-1--355601600-- --Apple-Mail-2--355601529 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwm5xTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTAxMjAyMTA2MjdaFw0x MTA3MTkyMTA2MjdaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQBlGZdPhl6SR3KKK1xXL41nqIAK9To0lIZXaqxtanIa083BHH07icuV YydeekqgxqO6z0A/3HOEJOESV5eUB9bly7zHRh7CIOB++6WzaVrFTa4yoUmhXeHF3HJmaUaxJBSl R4po3vPoii81nFIg4NSRLtRQw0ClVEvaJMkipgAWGu+b42tMNQolxBF6sCh6VOzoz9Q5t+4bwu+v d94tSGoSfuyV0sBVVaIz08VZUPYKYEM6nYEMiJzDhgH09b4CtQJ46o+YyyDb59xcuEyEd00B1tWS WUfqrYehN/W60FjopddWrG9+HaZu5+2Fz3L+da8Ggjj0g1r00cRcUURUpll+yH06D+YbhbH03kP9 P7juyvO9VfDMqYNh301h1g8PM/dDaHCUthpzedwwYeNsyTFGqzcFfsuxXvK/4BkHGPcFkyxQlqTc cWGbdxXrz42zY/ndRvzEWZ5AnlIIOsWzIySEAzhmGdlc462/kCbO8SisJYfriMcGHrJKwA2X3o8E DJ5tWayiInI/mv4BpKgIKKF5lNWgMVbYcTPtUCoCOl4mefFX+yCan/bxjRL6ae8HOMyUS6fg1v61 ypEh8WoXcoYbiGPmWP5uSpDK8Y2UGJ70T59RUgjyryFTIriZKJDZUtAD6gr0QPuQn+Fidb00OKYp XrWcXFmOdxph1ZFNMgg5ETGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJucUwCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwMzE0MDM0MjI1 WjAjBgkqhkiG9w0BCQQxFgQUKSXPaDQPOzjY56+doeO+hIydgokwgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCbnFMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCbnFMA0GCSqG SIb3DQEBAQUABIIBAHsG9eF6GRB5z2UBnsdsu16WrzdqB96hhezriHHZAk/WmbLqAjOUAsnXoX9n yTvDZ7EzhFuSkVD6PRPD0myGV1rQl39jI+GL4mGemOp8g7muHMqTz26sJKKrjPAQdbFoqU7mhTEs 5gPCQotJD1K2M0cXKz5Tx/msIlAW6OwGsD+U+rGD93wZL9lhjNVY+OroQqvBZhXD1sK7IaJ6IIlr akzRDHCKRJblHJjPuOO7Uofzq1MNmrYey9aS0SXG6UjVU7i9GbXJsjP0lgbKxCow8zT6AeJbpFvh wCnBcn9l6CMZkVmxe2SqQwCWgCU08iMMOQ9vBCSOf8c92u6Di6L3FbgAAAAAAAA= --Apple-Mail-2--355601529-- From mohamed.boucadair@orange-ftgroup.com Mon Mar 14 02:52:46 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9EB63A6B1A for ; Mon, 14 Mar 2011 02:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FRAUD_X3=1.667, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lX-P-LbONY-w for ; Mon, 14 Mar 2011 02:52:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 82F9F3A6B17 for ; Mon, 14 Mar 2011 02:52:45 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id A1AA72DC294; Mon, 14 Mar 2011 10:54:08 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 86E4727C054; Mon, 14 Mar 2011 10:54:08 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 14 Mar 2011 10:54:08 +0100 From: To: Tom Taylor Date: Mon, 14 Mar 2011 10:54:06 +0100 Thread-Topic: [v6ops] Happy Eyeballs and SIP Thread-Index: Acvh0+zw+gEW9zZvQueJLchvPi5LNwAWSvkQ Message-ID: <9325_1300096448_4D7DE5C0_9325_108944_1_94C682931C08B048B7A8645303FDC9F33C4DB02501@PUEXCB1B.nanterre.francetelecom.fr> References: <83928D99-9809-4BF9-A710-28366AF46BBB@edvina.net> <24436_1299502310_4D74D4E6_24436_185484_1_94C682931C08B048B7A8645303FDC9F33C4DA50BCA@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.14.92118 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Happy Eyeballs and SIP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 09:52:46 -0000 Dear Tom, To be more accurate, there is no formal decision as a result of the discuss= ion related to this topic (available at: http://www.ietf.org/mail-archive/w= eb/mmusic/current/msg07958.html). Cheers, Med -----Message d'origine----- De : Tom Taylor [mailto:tom111.taylor@bell.net]=20 Envoy=E9 : lundi 14 mars 2011 00:11 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Olle E. Johansson; v6ops@ietf.org Objet : Re: [v6ops] Happy Eyeballs and SIP Mind, altc has been rejected by RAI area. The official solution is to=20 use ICE or ICE Lite. On 07/03/2011 7:51 AM, mohamed.boucadair@orange-ftgroup.com wrote: > Dear Olle, > > For the SIP case, if you don't need connectivity checks (e.g., closed > networks, which is in France the majority of SIP traffic) you can > just use the ALTC attribute defined in > http://tools.ietf.org/html/draft-boucadair-mmusic-altc-01. > > In case connectivity checks are needed, a variant of the happy > eyeballs for SIP (called Happy Eardrums) has been proposed in > http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 but > still you need to be sure you IPv4 connectivity is working ;-). > > Cheers, Med > > > -----Message d'origine----- De : v6ops-bounces@ietf.org > [mailto:v6ops-bounces@ietf.org] De la part de Olle E. Johansson > Envoy=E9 : lundi 7 mars 2011 10:40 =C0 : v6ops@ietf.org Objet : [v6ops] > Happy Eyeballs and SIP > > Hi! > > Has anyone considered the issues covered in the happy-eyeballs draft > for SIP? > > A 19 or 32 second time out when placing a call is not a good user > experience... I think this applies to SIP over TCP, and possibly also > needs to be handled for UDP. I don't see this handled in the draft > for IPv6 transition in the Session Initiation Protocol (soon-to-be > RFC 6157) > > Seems like the scope of the happy eyeballs draft is HTTP, so the > question is if this should be expanded or if we need other drafts for > other protocols. > > Regards, /Olle > > Ref: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07 > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > *************************************************************************= ******* > > IMPORTANT.Les informations contenues dans ce message electronique y=20 compris les fichiers attaches sont strictement confidentielles > et peuvent etre protegees par la loi. Ce message electronique est > destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. > Si vous avez recu ce message par erreur ou s il ne vous est pas > destine, veuillez immediatement le signaler a l expediteur et > effacer ce message et tous les fichiers eventuellement attaches. > Toute lecture, exploitation ou transmission des informations > contenues dans ce message est interdite. Tout message electronique > est susceptible d alteration. A ce titre, le Groupe France Telecom > decline toute responsabilite notamment s il a ete altere, deforme ou > falsifie. De meme, il appartient au destinataire de s assurer de l > absence de tout virus. > > IMPORTANT.This e-mail message and any attachments are strictly > confidential and may be protected by law. This message is intended > only for the named recipient(s) above. If you have received this > message in error, or are not the named recipient(s), please > immediately notify the sender and delete this e-mail message. Any > unauthorized view, usage or disclosure ofthis message is prohibited. > Since e-mail messages may not be reliable, France Telecom Group shall > not be liable for any message if modified, changed or falsified. > Additionally the recipient should ensure they are actually virus > free. > *************************************************************************= ******* > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From ichiroumakino@gmail.com Mon Mar 14 03:49:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 480243A6C85 for ; Mon, 14 Mar 2011 03:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX1EO-EkiQsi for ; Mon, 14 Mar 2011 03:49:56 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id D273E3A6CA3 for ; Mon, 14 Mar 2011 03:49:52 -0700 (PDT) Received: by wwa36 with SMTP id 36so3787343wwa.13 for ; Mon, 14 Mar 2011 03:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=sTXGLVE1uzcHYzfwRQc0OQ4RoTBhRulUvMBsFjlDBRQ=; b=Pb0vF2YXIYujzzLXaTXAWs98eLjMSnhdhoy8wCQDHeHeevzO5vEg7L8xrHvaC5S/hI bALfD3oq9LosL84+SScFqvBeV5TpDN5JCiSMjaDOCE8F0SWDFCb6iIKs+wScmDjg08QT ffSq0qVyKVs+u/JGM08p9H4BxtPggTEcWLVGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=eA6GjMPqrj9eTaDdBRylKKCMMq2XpIjbn5UUYHH3mv2iLVeTb9wPhS6if5m7dyS7Wt xA8r0Jgx6MG6KN/YOFl++SSjne83atMLUUOJIiwN4aAXf3DGpBxSTaXGGlBapQkb/7kf q7A/SYE0TFD1YTlRXH2jZdoElvjSnULvnStmI= Received: by 10.227.154.12 with SMTP id m12mr11151490wbw.193.1300099875602; Mon, 14 Mar 2011 03:51:15 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-109.cisco.com (dhcp-osl-vl300-64-103-53-109.cisco.com [64.103.53.109]) by mx.google.com with ESMTPS id l5sm3748837wej.32.2011.03.14.03.51.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2011 03:51:12 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4D7D84AC.40705@gmail.com> Date: Mon, 14 Mar 2011 11:51:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1CFA91DD-832D-4C50-B0E3-8550B2D69F88@employees.org> References: <20110310073001.29755.70784.idtracker@localhost> <4D7D84AC.40705@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1082) Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action:draft-troan-v6ops-6to4-to-historic-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 10:49:57 -0000 Brian, > There's a slight improvement in that this version actually > mentions the culprit, RFC 3068. But that has been forgotten > in the "Obsoletes: (if approved)" header. it hasn't, I just couldn't figure out how to put two RFCs in obsolete in = xml2rfc. 3068 isn't the only "culprit", 3056 is equally problematic. 3056 creates = the reverse-path problem, 3068 the forward-path. > However, I still don't think it should be approved. For a start, this > is untrue: >=20 >> The IPv6 transitioning mechanism "Connection of IPv6 Domains via = IPv4 >> Clouds (6to4) described in [RFC3056] and the extension in "An = Anycast >> Prefix for 6to4 Relay Routers" RFC3068 [RFC3068] have been shown to >> have severe practical problems being used in the Internet.=20 >=20 > Actually the mechanism described in RFC 3056 has, as far as I know, > never been seriously deployed. The operational problems are analysed = at > some length in draft-carpenter-v6ops-6to4-teredo-advisory (based on > input from about 20 people) and as far as I can see they are due to = the > RFC 3068 anycast mechanism, inappropriate firewall behaviour, use of > bogon address space, or failure to follow the rules of RFC 3056 about > announcing 2002::/16. _one_ of the deployment models in 3056 hasn't been deployed. possibly because it is undeployable. as it requires a mesh of BGP = sessions between consenting 6to4 relays. making 6to4 deployment equally in effort to manually configured tunnels. = those are deployed, and people run BGP over those. the 6to4 deployment = model you are referring to has little to offer here. (6to4 is also used as 'transport' for BGP tunnels, but then the = mechanism is contained within an SP network, and native addresses are = used. I don't see this use of 6to4 (where ISATAP, 6rd or others could = also work) as problematic. > In that situation, I can't see any justification for obsoleting RFC = 3056, > and I think our cycles are better spent on advising people how to > configure things properly. I think we have had this discussion already. there is nothing that can be "configured properly". unfortunately. apart = from you mean configure properly as in configure 6to4 to off. > I tend to agree that new implementations of RFC 3068 will not be > helpful. But is that a real risk? the purpose of this draft is to show that 6to4 is an evolutionary dead = end, and that one should apply extreme caution in its use. I don't think the two of us will reach agreement on this. I think there = will be two or three drafts on 6to4 presented in Prague. let's see what = the consensus is in the room for the various approaches (as opposed to = continuing the 240 mail thread that revision 00 generated. ;-)) cheers, Ole= From shemant@cisco.com Mon Mar 14 07:19:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA8323A6D72 for ; Mon, 14 Mar 2011 07:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.056 X-Spam-Level: X-Spam-Status: No, score=-11.056 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Fb5YAgiiaIl for ; Mon, 14 Mar 2011 07:19:56 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A1A9B3A6910 for ; Mon, 14 Mar 2011 07:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2310; q=dns/txt; s=iport; t=1300112480; x=1301322080; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ty7oqmMdZak97qyCF3/KXPLUakmeATDug9cgbsQ06aQ=; b=DcxUFFYKTqsA3abKgObxxLlCi8PuTiVKX9TTyYX6MYT5cGBJ28m64Thu fJKguMxXo2zB5n+EY8nprAW80q4gz5smYq5QK9rIn+uvd2A18AlWWVW7C Sqznp7MfTUbemwlowhp+xePmERmUWcgVpXTK7PCPb4a10gTQwOtVa0K/u M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAGbBfU2tJXG9/2dsb2JhbACYQY1Fd6QkjiCNQIViBIUrins X-IronPort-AV: E=Sophos;i="4.62,316,1297036800"; d="scan'208";a="276138364" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-4.cisco.com with ESMTP; 14 Mar 2011 14:21:20 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2EELJJY022583; Mon, 14 Mar 2011 14:21:19 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 09:21:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 09:21:17 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B78E@XMB-RCD-109.cisco.com> In-Reply-To: <4D7D2BF5.9020400@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvhvxHWihCdeoFqQzWppsfT1BCrCQANPrIQ References: <20110305184502.18531.25548.idtracker@localhost> <4D7D2BF5.9020400@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" , X-OriginalArrivalTime: 14 Mar 2011 14:21:20.0034 (UTC) FILETIME=[16A62020:01CBE253] Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 14:19:57 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Sunday, March 13, 2011 4:41 PM To: v6ops@ietf.org Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Brian, >What is the meaning of "local queries"? Is this intended to imply that >there are names such as printer1.example.com that are only meaningful >and visible "inside" the CPE boundary? If so, what is the domain name? >Is the CPE supposed to know an appropriate domain name and if so, how? "local" means the CE Router replies to queries from the LAN rather than forwarding the query as a recursive DNS server. The domain name can be provisioned via a DHCPv6 option from the SP or manually. =20 >Just below: >Is this referring to NPTv6 or something else? It's important to be >clear, since trying to stop stateful NAPT66 is one battle, and trying to >stop NPTv6 is another. We can clarify this bullet and remove the use of the term NAT66. What we mean is any of network port or address translation (stateful/stateless) is not used.=20 >I'm really not sure about these SHOULDs. It's not they are bad things to include, >but there may be situations where they are insufficient and some other >form of tunnel is needed. At the very least say that other backhaul tunnel >mechanisms MAY be supported, without specifying them. Then add a corresponding >point in the next section: The SP's on the CE router design team (they are contributors to the document) did not want DS-Lite nor 6rd as a MUST in the document. Thus the "SHOULD" came about.=20 > If this procedure fails, some other form of tunnel MAY be initiated. Section 5.5.3 has each mechanism try forever. Thus how does one detect failure to then try another tunneling mechanism? =20 >Also, I think section 5.5.3 should recommend that the CPE be configurable >to block protocol 41 v6-in-v4 mechanisms when IPv6 connectivity is >available. The same section also specifies routing prefers a default route over native transport vs. tunneled transport and thus whenever any mechanism succeeds, data forwarding is appropriately adjusted for default route preference. Why is there any need to block anything? Thanks, Hemant From shemant@cisco.com Mon Mar 14 10:11:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3103A6E39 for ; Mon, 14 Mar 2011 10:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.725 X-Spam-Level: X-Spam-Status: No, score=-10.725 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXzTyW0WYLHH for ; Mon, 14 Mar 2011 10:10:53 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id ACECC3A6E76 for ; Mon, 14 Mar 2011 10:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=13374; q=dns/txt; s=iport; t=1300122736; x=1301332336; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=16xCGjbQLztUwzu+cwJp+fyHV8O9muT8Hjv/HzClWr4=; b=ZO8yVAFHKy7ORqMavk5ScfPH8fmSbe85qxGzOofxxfmTtor+P9jumK+t ejKbB/NgvfPKnk0UPjprfiNUaz2jk3NUZU3kgb138cwNMORy4TUv9sL4A qbBbKDYuWQakbwri/F/U4RkvT88F5infnATelWswgf5PGJDCX+486nZ/I Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAD7pfU2tJV2a/2dsb2JhbACCXJVojUV3pCGcFYViBIUrins X-IronPort-AV: E=Sophos;i="4.62,316,1297036800"; d="scan'208,217";a="225087461" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 14 Mar 2011 17:12:12 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2EHCCc4001912; Mon, 14 Mar 2011 17:12:12 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 12:12:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE26A.F4B02B85" Date: Mon, 14 Mar 2011 12:12:08 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> In-Reply-To: <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvh+edn7hoa7vO1Qv+4pGFth0m0XwAbeG/g References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> From: "Hemant Singh (shemant)" To: "Michael Newbery" , "IPv6 Ops WG" X-OriginalArrivalTime: 14 Mar 2011 17:12:12.0300 (UTC) FILETIME=[F579C4C0:01CBE26A] Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 17:11:02 -0000 X-List-Received-Date: Mon, 14 Mar 2011 17:11:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE26A.F4B02B85 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Michael Newbery Sent: Sunday, March 13, 2011 11:42 PM To: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt =20 >The diagram and the text do not seem to allow explicitly for multihoming to more than one service provider. =20 Yes, the reason is because multihoming is not supported for a feature by the document. =20 >You refer to an IGP (only) in section 3.1. If the CPE router is not multihomed, why bother running an IGP on it at all? =20 The IGP is also mentioned in section 5.4. If the IGP is not run in the home LAN, how does a router upstream learn about routes in the downstream if the LAN topology is a graphed routed network? =20 > It is unlikely that the service provider will listen to any routing advertisements you generate. There is only a binary choice for the default route: it's there or it isn't, and that can be propagated to the LAN without needing a full IGP. =20 Not quite. If a simple recursive prefix delegation in the LAN is used (with only a tree routed) topology, the routes across various routers are known because upstream routers have aggregated the delegated prefix route. But a non-tree routed topology for which a graph is the most general case, one will need IGP. However, you do have one point. If the document only supports a specific two-router topology, then there is no graphed network and an IGP is not needed. We still decided to keep the IGP in section 5.4 to support the future work if any generic routed case and multihoming get taken up for work. =20 =20 > D-1: For local DNS queries for configuration, the CE Router MAY > include a DNS server to handle local queries. Non-local > queries can be forwarded unchanged to a DNS server specified in > the DNS server DHCPv6 option.=20 >If the intent was to handle ".local", I thought that this was in conflict with mDNS as it is generally implemented. If the intent is to optional offer a lightweight DNS server built into the CPE-router then I think that's what should be stated in the RFC, >explicitly. And is that's the case, what are its constraints? Is it authoritative for the user's home domain (with all that implies); is is a caching only server; is it a stealth server; is it a hidden primary? =20 Since the document does not mention a recursive DNS server, the device is expected to support a DNS proxy which by definition does not cache. The configuration needed with DNS is so that a user can use http to a name such as route.local. There is no need for mDNS for such basic http configuration. =20 =20 >If however the desire is simply ".local" service, then why not just suggest mDNS, possibly with provision for static entries to support devices that can't do mDNS themselves. =20 Certainly it makes sense for us to mention static entries which is manual configuration. I mentioned manual configuration in my reply to Brian Carpenter comments. We will work the DNS section some more and clarify issues. =20 Thanks much, =20 Hemant ------_=_NextPart_001_01CBE26A.F4B02B85 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Michael Newbery
Sent: Sunday, March 13, 2011 11:42 PM
To: IPv6 Ops WG
Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

 

>The = diagram and the text do not seem to allow explicitly for multihoming to more than one = service provider.

 

Yes, the reason is because multihoming is not supported = for a feature by the document.

 

>You refer = to an IGP (only) in section 3.1. If the CPE router is not multihomed, why bother = running an IGP on it at all?

 

The IGP is also mentioned in section 5.4.  If the = IGP is not run in the home LAN, how does a router upstream learn about routes = in the downstream if the LAN topology is a graphed routed = network?

 

> It is = unlikely that the service provider will listen to any routing advertisements you = generate. There is only a binary choice for the default route: it's there or it = isn't, and that can be propagated to the LAN without needing a full = IGP.

 

Not quite.  If a simple recursive prefix delegation = in the LAN is used (with only a tree routed) topology, the routes across = various routers are known because upstream routers have aggregated the delegated = prefix route.  But a non-tree routed topology for which a graph is the = most general case, one will need IGP.    However, you do have = one point.  If the document only supports a specific two-router = topology, then there is no graphed network and an IGP is not needed.   We = still decided to keep the IGP in section 5.4 to support the future work if any = generic routed case and multihoming get taken up for work.

 

 

>   D-1:  For local DNS =
queries for configuration, the CE Router MAY
>      &n=
bsp;  include a DNS server to handle local queries.  =
Non-local
>    =
     queries can be forwarded unchanged to a =
DNS server specified in
>      &n=
bsp;  the DNS server DHCPv6 option.

>If the = intent was to handle ".local", I thought that this was in conflict with mDNS = as it is generally implemented. If the intent is to optional offer a = lightweight DNS server built into the CPE-router then I think that's what should be = stated in the RFC, >explicitly. And is = that's the case, what are its constraints?  Is it authoritative for the user's = home domain (with all that implies); is is a caching only server; is it a = stealth server; is it a hidden primary?

 

Since the document does not mention a recursive DNS = server, the device is expected to support a DNS proxy which by definition does not cache.    The configuration needed with DNS is so that a = user can use http to a name such as route.local.    There is = no need for mDNS for such basic http configuration.   =

 

>If however = the desire is simply ".local" service, then why not just suggest mDNS, = possibly with provision for static entries to support devices that can't do mDNS themselves.

 

Certainly it makes sense for us to mention static entries = which is manual configuration.  I mentioned manual configuration in my = reply to Brian Carpenter comments.   We will work the DNS section some = more and  clarify issues.

 

Thanks much,

 

Hemant

------_=_NextPart_001_01CBE26A.F4B02B85-- From jhw@apple.com Mon Mar 14 10:26:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D9D3A6DBE for ; Mon, 14 Mar 2011 10:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1GqwDSc5nCr for ; Mon, 14 Mar 2011 10:26:09 -0700 (PDT) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id AC5C23A6D37 for ; Mon, 14 Mar 2011 10:26:08 -0700 (PDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 9F813D6A4F86 for ; Mon, 14 Mar 2011 10:27:32 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-6d-4d7e50048b7e Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id 64.E0.20744.4005E7D4; Mon, 14 Mar 2011 10:27:32 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.15.152] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI2009UM5TW6530@elliott.apple.com> for v6ops@ietf.org; Mon, 14 Mar 2011 10:27:32 -0700 (PDT) From: james woodyatt In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> Date: Mon, 14 Mar 2011 10:27:32 -0700 Message-id: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 17:26:11 -0000 On Mar 14, 2011, at 10:12 AM, Hemant Singh (shemant) wrote: > > We still decided to keep the IGP in section 5.4 to support the future work if any generic routed case and multihoming get taken up for work. This is a bad idea. If we don't have clear guidance on an IGP to give to equipment makers, and we don't, then we shouldn't say anything about an IGP in this draft. You run the risk equipment makers will ignore the whole document by including stuff like this. -- james woodyatt member of technical staff, core os networking From shemant@cisco.com Mon Mar 14 10:48:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035423A6E0E for ; Mon, 14 Mar 2011 10:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.98 X-Spam-Level: X-Spam-Status: No, score=-10.98 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqixcM9B-5XC for ; Mon, 14 Mar 2011 10:48:34 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id ACB563A6E2A for ; Mon, 14 Mar 2011 10:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=791; q=dns/txt; s=iport; t=1300124998; x=1301334598; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=lPU88liWw5+O5abFP6ksMqQ/NNHtTJ4UIccwRcaJfxo=; b=UAw73gBci/LG9Oi/qY2lw93nhLLw5xr4R++JO9TMr5+us5H3Vw3+r6/5 ql8FoS6LXA+csq22MC2u1Eu60nhOTK0d9JbUbnoS9g6GC99Gm/1W3NlmD BDGtLExwAlfswV86n+RmuyXc3jX26my8/uveW6oo0R8lA/SZhOgFNRRcK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAK7xfU2tJXG8/2dsb2JhbACYRI1Gd6QFnBuFYgSFK4p7 X-IronPort-AV: E=Sophos;i="4.62,317,1297036800"; d="scan'208";a="277817918" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-3.cisco.com with ESMTP; 14 Mar 2011 17:49:58 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2EHnwe4005328; Mon, 14 Mar 2011 17:49:58 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 12:49:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 12:49:56 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvibSWXGW2/YEfEQi6zpALaYZ6bkQAAgKwg References: <20110305184502.18531.25548.idtracker@localhost><76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "james woodyatt" , "IPv6 Ops WG" X-OriginalArrivalTime: 14 Mar 2011 17:49:58.0672 (UTC) FILETIME=[3C56B100:01CBE270] Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 17:48:36 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Monday, March 14, 2011 1:28 PM To: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >This is a bad idea. If we don't have clear guidance on an IGP to give to equipment makers, and we don't, then we shouldn't say anything about an IGP in this draft. You run the risk equipment makers >will ignore the whole document by including stuff like this. Two IGPs we could propose are RIPng and OSPF with all area 0. However vendors will ask which one IGP do we support if we support only one? So now what do we do? Also, what would SP's have to say, if anything, about an IGP in the LAN? =20 Thanks, Hemant From jhw@apple.com Mon Mar 14 11:11:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785483A6974 for ; Mon, 14 Mar 2011 11:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.278 X-Spam-Level: X-Spam-Status: No, score=-106.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHviBx5lutMo for ; Mon, 14 Mar 2011 11:10:58 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 3C4723A6D1C for ; Mon, 14 Mar 2011 11:10:58 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 3A2B7D6A9024 for ; Mon, 14 Mar 2011 11:12:22 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-12-4d7e5a86dd98 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay15.apple.com (Apple SCV relay) with SMTP id 98.60.18996.68A5E7D4; Mon, 14 Mar 2011 11:12:22 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.13.64] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI200ESH7WLNJ60@gertie.apple.com> for v6ops@ietf.org; Mon, 14 Mar 2011 11:12:22 -0700 (PDT) From: james woodyatt In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> Date: Mon, 14 Mar 2011 11:12:21 -0700 Message-id: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 18:11:02 -0000 On Mar 14, 2011, at 10:49 , Hemant Singh (shemant) wrote: > > Also, what would SP's have to say, if anything, about an IGP in the LAN? This, right here, is the reason this whole residential routing domain thing is a tiger's tail. The V6OPS working group should leave it alone. -- james woodyatt member of technical staff, core os networking From swmike@swm.pp.se Mon Mar 14 11:12:29 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD203A6E24 for ; Mon, 14 Mar 2011 11:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkrPcb+y5jy3 for ; Mon, 14 Mar 2011 11:12:29 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 8C1C83A6A31 for ; Mon, 14 Mar 2011 11:12:28 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 085B69C; Mon, 14 Mar 2011 19:13:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 062CE9A for ; Mon, 14 Mar 2011 19:13:50 +0100 (CET) Date: Mon, 14 Mar 2011 19:13:50 +0100 (CET) From: Mikael Abrahamsson To: IPv6 Ops WG In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> Message-ID: References: <20110305184502.18531.25548.idtracker@localhost><76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 18:12:29 -0000 On Mon, 14 Mar 2011, Hemant Singh (shemant) wrote: > Two IGPs we could propose are RIPng and OSPF with all area 0. However > vendors will ask which one IGP do we support if we support only one? So > now what do we do? Also, what would SP's have to say, if anything, > about an IGP in the LAN? As an SP, I don't really care. My handoff to the customer is going to be DHCPv6-PD induced static route without any routing protocol. As a home user, I want efficient routing so an IGP would definitely be nice. I just want it to work. RIPng and OSPF both works for me, but I think we should pick one, not two. Vendors who would implement this, what do you prefer of these two? -- Mikael Abrahamsson email: swmike@swm.pp.se From fred@cisco.com Mon Mar 14 11:57:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAEE73A69C3 for ; Mon, 14 Mar 2011 11:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.572 X-Spam-Level: X-Spam-Status: No, score=-109.572 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, SARE_BANK_URI_IP=0.653, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ils7acHAPA5W for ; Mon, 14 Mar 2011 11:57:36 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E3BB23A68AC for ; Mon, 14 Mar 2011 11:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4179; q=dns/txt; s=iport; t=1300129141; x=1301338741; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=1LAWoLGirflLhgNL4zAikgiFm4IE5Ya1YuoXAZNGps0=; b=QNiw5JZnywooOiYAteKFIS3HRGcp0lQO367cYT8xMtrPxygfTtGiaaNp n00BK1uC0O2tVNDG2VIat1u3M9eYAcwuOwZeubX8+7Aa18+iLZBtop9g0 lCIzbb3TXTweHjUDoN/+bmFBiaRU3ogBv7shPJb6t4jo/wwv9+mA9hIsM I=; X-IronPort-AV: E=Sophos;i="4.62,317,1297036800"; d="scan'208";a="277836848" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-3.cisco.com with ESMTP; 14 Mar 2011 18:59:00 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2EIwtWT019931; Mon, 14 Mar 2011 18:59:00 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Mon, 14 Mar 2011 11:59:00 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Mon, 14 Mar 2011 11:59:00 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> Date: Mon, 14 Mar 2011 11:58:45 -0700 Message-Id: <050DF59B-D021-4621-87BF-3F2041BA0CAA@cisco.com> References: <20110305184502.18531.25548.idtracker@localhost><76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 18:57:38 -0000 Good grief. Any residential IPv4 gateway worthy of the name supports at = least the version of RIP we obsoleted when we adopted CIDR. The SMC one = below describes itself as an "Ethernet Switch", which usually means = "802.1d" and not a lot more, but it supports RIP. If we can't specify = that an industry that figured out for itself that RIP existed and was a = market requirement for them in IPv4 should implement RIPng (RFC = 2080/2081) for IPv6, we deserve to be ignored. No, this has nothing to do with service providers, although some of the = ones below are "managed gateways", which is to say a residential CPE = sold and/or operated by an ISP. This is about residential networking = equipment. I looked up http://ipv6.google.com/q=3Dbroadband+router, and from that = http://compnetworking.about.com/od/broadband/tp/dslcablerouters.htm to = get a list of residential router manufacturers. The ones I came up with = were SMC, Netgear, Multitech, Asante, Linksys, 2Wire, US Robotics, = D-Link, and Nexland. I found another vendor by accident in the process, = and I probably missed several. I then executed = http://ipv6.google.com/#hl=3Den&q=3DVENDOR-NAME+RIP+routing open 'http://ipv6.google.com/#hl=3Den&q=3DSMC+RIP+routing'=20 =E2=97=86 Routing features: IP/RIP routing, CIDR=20 http://www.smc.com/files/AG/MN_SMC88xxM_MNG.pdf open 'http://ipv6.google.com/#hl=3Den&q=3DNetgear+RIP+routing'=20 RIPv1 and RIPv2 = http://documentation.netgear.com/dgfv338/enu/202-10161-01/DGFV338_RM-09-08= .html open 'http://ipv6.google.com/#hl=3Den&q=3DMultitech+RIP+routing'=20 Supports RIPv1 = http://reviews.cnet.com/routers/multi-tech-routefinder-router/1707-3319-30= 046399.html open 'http://ipv6.google.com/#hl=3Den&q=3DAsante+RIP+routing'=20 Supports Layer 3 Routing for IP with Router Standby Protocol, Router = Discovery Protocol, RIP I/II, OSPF, including static route table = (insertion/deletion) and Layer 3 IGMP multicasting=20 http://www.asante.com/downloads/datasheets/IntraCore/IC35516_DS.pdf open 'http://ipv6.google.com/#hl=3Den&q=3DLinksys+RIP+routing'=20 Supports static routes, RIPv1 and RIPv2=20 http://ui.linksys.com/files/WAG200G/1.00.09/help/h_AdvRouting.htm open 'http://ipv6.google.com/#hl=3Den&q=3D2Wire+RIP+routing'=20 Apparently does not support RIP However (google is wise and took me here...?) Corecess supports RFC 1058 RIP v1, RFC 1723 RIP v2.=20 http://www.corecess.com/eng/product/xdsl_corecess3300.asp open 'http://ipv6.google.com/#hl=3Den&q=3DRobotics+RIP+routing'=20 Supports static routes, RIPv1 and RIPv2=20 http://www.usr.com/support/9108/9108-ug/wui_lan.htm#option7 open 'http://ipv6.google.com/#hl=3Den&q=3DD-Link+RIP+routing'=20 Supports static routes, RIPv1 and RIPv2=20 = http://screenshots.portforward.com/Dlink/DSL-2640B_SEA_1.00/Routing_RIP.ht= m open 'http://ipv6.google.com/#hl=3Den&q=3DNexland+RIP+routing'=20 Supports static routes and RFC 1058 RIP=20 = http://68.67.73.20/routers/nexland-pro400-broadband-router-with-a-built-in= -161 The only one that doesn't also calls itself a "modem". On Mar 14, 2011, at 10:49 AM, Hemant Singh (shemant) wrote: > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of james woodyatt > Sent: Monday, March 14, 2011 1:28 PM > To: IPv6 Ops WG > Subject: Re: [v6ops] I-D > Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 >=20 >> This is a bad idea. If we don't have clear guidance on an IGP to = give > to equipment makers, and we don't, then we shouldn't say anything = about > an IGP in this draft. You run the risk equipment makers >will ignore > the whole document by including stuff like this. >=20 > Two IGPs we could propose are RIPng and OSPF with all area 0. However > vendors will ask which one IGP do we support if we support only one? = So > now what do we do? Also, what would SP's have to say, if anything, > about an IGP in the LAN? =20 >=20 > Thanks, >=20 > Hemant > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Mon Mar 14 12:10:09 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977293A6975 for ; Mon, 14 Mar 2011 12:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxBLCiuXhHHY for ; Mon, 14 Mar 2011 12:10:09 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 244AA3A6A1F for ; Mon, 14 Mar 2011 12:10:07 -0700 (PDT) Received: from 23173jjaeggli.local (143.sub-166-250-40.myvzw.com [166.250.40.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p2EJBS58072631 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 14 Mar 2011 19:11:29 GMT (envelope-from joelja@bogus.com) Message-ID: <4D7E685A.80202@bogus.com> Date: Mon, 14 Mar 2011 12:11:22 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: james woodyatt References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Mon, 14 Mar 2011 19:11:29 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 19:10:09 -0000 On 3/14/11 11:12 AM, james woodyatt wrote: > On Mar 14, 2011, at 10:49 , Hemant Singh (shemant) wrote: >> >> Also, what would SP's have to say, if anything, about an IGP in >> the LAN? > > This, right here, is the reason this whole residential routing > domain thing is a tiger's tail. The V6OPS working group should leave > it alone. except in the case where the cpe is literally a bridge, I see no reason why the service provider would have any interest at all unless they're managing the interior network as well. > > -- james woodyatt member of technical staff, core os > networking > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Mon Mar 14 13:09:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63C83A69A3 for ; Mon, 14 Mar 2011 13:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.152 X-Spam-Level: X-Spam-Status: No, score=-103.152 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsxZIr-sz2HG for ; Mon, 14 Mar 2011 13:09:30 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 80DCD3A6930 for ; Mon, 14 Mar 2011 13:09:30 -0700 (PDT) Received: by bwz13 with SMTP id 13so5380314bwz.31 for ; Mon, 14 Mar 2011 13:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+wThOemvB7XMdQzXA4yIH2LkT17ft3mDfhr9PFJhrp0=; b=sy/2WfbhRX2nxRoMCmnEr3gKVabBaScY4wIxNmJiOTXiJGOe6cvITPWITH1aMZHGWg Qfe6Alw6dxIyjEHcCcViSa//T4buXUvfKbnmzP6iNb5/g6oar84fD3kZ7qrGYWVG9PzA NwQJUNSt3GzBPvy7Z8KVmtt2Ym8ZBoeEI0t+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=A6vsXAiJGf9XNU6xvxq18cwAZSsrba4AaP6GkJf+7NjCOQaaO6lJP3SDsnaEoGAj3j lKTA/HOgeiNY/1AziydYVWtkQGGspMrf4QsjMC3zWVuuZwctHKEQKxG+cKyWmpNDkxx4 KAunbzW3HD1UBokD4AKIldqPVhlcYYj4iGbjE= Received: by 10.223.91.79 with SMTP id l15mr4525315fam.53.1300133414155; Mon, 14 Mar 2011 13:10:14 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id y11sm34007fam.15.2011.03.14.13.10.10 (version=SSLv3 cipher=OTHER); Mon, 14 Mar 2011 13:10:12 -0700 (PDT) Message-ID: <4D7E761F.4000002@gmail.com> Date: Tue, 15 Mar 2011 09:10:07 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joel Jaeggli References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> In-Reply-To: <4D7E685A.80202@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 20:09:31 -0000 On 2011-03-15 08:11, Joel Jaeggli wrote: > On 3/14/11 11:12 AM, james woodyatt wrote: >> On Mar 14, 2011, at 10:49 , Hemant Singh (shemant) wrote: >>> Also, what would SP's have to say, if anything, about an IGP in >>> the LAN? >> This, right here, is the reason this whole residential routing >> domain thing is a tiger's tail. The V6OPS working group should leave >> it alone. > > except in the case where the cpe is literally a bridge, I see no reason > why the service provider would have any interest at all unless they're > managing the interior network as well. Exactly. If the ISP has delegated a /56 (or whatever) to the CPE, it has absolutely no interest in the local topology that the CPE supports, therefore absolutely no interest in the IGP. I think I'm with Fred - suggest RIPng as a MAY implement. There's no reason to make it a SHOULD, and vendors will presumably know what their market wants. OSPF is for a different class of device anyway. Brian From jhw@apple.com Mon Mar 14 13:21:29 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388F73A6B71 for ; Mon, 14 Mar 2011 13:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL141ekHgMUn for ; Mon, 14 Mar 2011 13:21:28 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 284BD3A6E4D for ; Mon, 14 Mar 2011 13:21:28 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 6EBD4D6B4D9F for ; Mon, 14 Mar 2011 13:22:52 -0700 (PDT) X-AuditID: 11807137-b7c3cae0000010f5-b1-4d7e791c1c92 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay16.apple.com (Apple SCV relay) with SMTP id 58.E3.04341.C197E7D4; Mon, 14 Mar 2011 13:22:52 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.13.64] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI200I57DY4KF20@gertie.apple.com> for v6ops@ietf.org; Mon, 14 Mar 2011 13:22:52 -0700 (PDT) From: james woodyatt In-reply-to: <4D7E761F.4000002@gmail.com> Date: Mon, 14 Mar 2011 13:22:52 -0700 Message-id: <40637C1C-6DC2-49CE-B68C-F379429E21CB@apple.com> References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <4D7E761F.4000002@gmail.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 20:21:29 -0000 On Mar 14, 2011, at 13:10 , Brian E Carpenter wrote: > > I think I'm with Fred - suggest RIPng as a MAY implement. There's no reason to make it a SHOULD, and vendors will presumably know what their market wants. I would oppose making it a SHOULD recommendation. I wouldn't object to MAY. -- james woodyatt member of technical staff, core os networking From brian.e.carpenter@gmail.com Mon Mar 14 13:25:23 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9273A6E86 for ; Mon, 14 Mar 2011 13:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.15 X-Spam-Level: X-Spam-Status: No, score=-103.15 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVYoRXbvK2dZ for ; Mon, 14 Mar 2011 13:25:19 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 589613A6B79 for ; Mon, 14 Mar 2011 13:25:19 -0700 (PDT) Received: by fxm15 with SMTP id 15so3652033fxm.31 for ; Mon, 14 Mar 2011 13:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TlmxmCuIcP/TPpVSQbsUtnmMXgO1u+GNIEcJiD1NACM=; b=cM2TEvjolNXibL5G2to6VY2AOaYzaVzZxwQ8dq2yYIjmXoYZ3sRJXI+xJJ/2KMFuPm hDYh26Y/2sNpoGrcghIulM6aXZqyeR3lyqVhOsDJRpBxoGl1oG78oPxgPy2YQZ40e+st pthe9Q/knoggBgS3EfJNqbaWGgZQgRzwu7WDo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=CTCPDDM5j9lQkNwJEsSKGGdruC4tOc6DZ9+KTsD+eS8CISFCskOpkyQa/hl4KP2+ki xvH7SN+VG7yGhhem811ozHYMwmve079ReFjm4Drk0QaFzamusl7ddEGj/hi0GZHzCkJE KizwfQsdcbeI8fXh95d0ruqHx22EQYZOOhnLY= Received: by 10.223.110.206 with SMTP id o14mr11180593fap.88.1300134397825; Mon, 14 Mar 2011 13:26:37 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id o12sm3287469fav.6.2011.03.14.13.26.34 (version=SSLv3 cipher=OTHER); Mon, 14 Mar 2011 13:26:36 -0700 (PDT) Message-ID: <4D7E79F8.7000602@gmail.com> Date: Tue, 15 Mar 2011 09:26:32 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <20110305184502.18531.25548.idtracker@localhost> <4D7D2BF5.9020400@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B78E@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B78E@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 20:25:23 -0000 On 2011-03-15 03:21, Hemant Singh (shemant) wrote: > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Brian E Carpenter > Sent: Sunday, March 13, 2011 4:41 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D > Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > > Brian, > >> What is the meaning of "local queries"? Is this intended to imply that >> there are names such as printer1.example.com that are only meaningful >> and visible "inside" the CPE boundary? If so, what is the domain name? >> Is the CPE supposed to know an appropriate domain name and if so, how? > > "local" means the CE Router replies to queries from the LAN rather than > forwarding the query as a recursive DNS server. The domain name can be > provisioned via a DHCPv6 option from the SP or manually. Er, how does that work, if a host resolves printer11.example.com that doesn't happen to exist? A local resolver can only recurse such a query, because it has no way to know that it's intended to be local. This simply is not described well enough to make sense. As others have noted, you have to decide - is it genuine DNS, or a .local/mDNS style of kludge? If it's genuine DNS you have to recurse. If the idea is to recommend a DNS kludge, you'l have a very interesting discussion in IETF Last Call. > >> Just below: >> Is this referring to NPTv6 or something else? It's important to be >> clear, since trying to stop stateful NAPT66 is one battle, and trying > to >> stop NPTv6 is another. > > We can clarify this bullet and remove the use of the term NAT66. What > we mean is any of network port or address translation > (stateful/stateless) is not used. Do you really think that is viable? Trying to forbid NPTv6 is really spitting into the wind. What you can say safely is that any form of network port or address translation is not necessary. > >> I'm really not sure about these SHOULDs. It's not they are bad things > to include, >> but there may be situations where they are insufficient and some other >> form of tunnel is needed. At the very least say that other backhaul > tunnel >> mechanisms MAY be supported, without specifying them. Then add a > corresponding >> point in the next section: > > The SP's on the CE router design team (they are contributors to the > document) did not want DS-Lite nor 6rd as a MUST in the document. Thus > the "SHOULD" came about. Agreed, a MUST would be unreasonable. > > >> If this procedure fails, some other form of tunnel MAY be initiated. > > Section 5.5.3 has each mechanism try forever. Thus how does one detect > failure to then try another tunneling mechanism? That's a bug. We can't publish a model that makes other mechanisms impossible, because there may be situations where they are appropriate. You can say that other forms of tunnel MAY be supported and if so they SHOULD be included in the trial and error loop. > >> Also, I think section 5.5.3 should recommend that the CPE be > configurable >> to block protocol 41 v6-in-v4 mechanisms when IPv6 connectivity is >> available. > > The same section also specifies routing prefers a default route over > native transport vs. tunneled transport and thus whenever any mechanism > succeeds, data forwarding is appropriately adjusted for default route > preference. Why is there any need to block anything?` Protocol 41 is a special case. The IPv6 routing will not see v6-in-v4 traffic and the IPv4 routing will just route it. You can see draft-carpenter-v6ops-6to4-teredo-advisory for one aspect of this, but once you have native (or 6rd) support of IPv6, you need to block all Protocol 41 methods through the CPE. Brian From therbst@silverspringnet.com Mon Mar 14 13:40:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4A53A6B83 for ; Mon, 14 Mar 2011 13:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ba5WPhRP86X6 for ; Mon, 14 Mar 2011 13:40:39 -0700 (PDT) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by core3.amsl.com (Postfix) with ESMTP id 8724F3A6B58 for ; Mon, 14 Mar 2011 13:40:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAMMZfk0KyAE8/2dsb2JhbACnA8BVhWIEhSuLDw X-IronPort-AV: E=Sophos;i="4.62,318,1297065600"; d="scan'208";a="3548008" Received: from unknown (HELO IT-EXCA-01.silverspringnet.com) ([10.200.1.60]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 14 Mar 2011 13:42:03 -0700 Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-01.silverspringnet.com ([::1]) with mapi; Mon, 14 Mar 2011 13:42:03 -0700 From: Thomas Herbst To: james woodyatt , IPv6 Ops WG Date: Mon, 14 Mar 2011 13:42:01 -0700 Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcviiEZPwFDYGOknS4abraBOnAX3bg== Message-ID: In-Reply-To: <40637C1C-6DC2-49CE-B68C-F379429E21CB@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 20:40:40 -0000 We do need to select one IGP. I don't really care if it is RIP or OSPF. Support for the IGP should be a MUST or it is fairly pointless. On 3/14/11 1:22 PM, "james woodyatt" wrote: >On Mar 14, 2011, at 13:10 , Brian E Carpenter wrote: >>=20 >> I think I'm with Fred - suggest RIPng as a MAY implement. There's no >>reason to make it a SHOULD, and vendors will presumably know what their >>market wants. > >I would oppose making it a SHOULD recommendation. I wouldn't object to >MAY. > > >-- >james woodyatt >member of technical staff, core os networking > > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From Internet-Drafts@ietf.org Mon Mar 14 15:00:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33BF3A6F84; Mon, 14 Mar 2011 15:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCe0mv-EjUvR; Mon, 14 Mar 2011 15:00:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B363A6F5D; Mon, 14 Mar 2011 15:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314220001.1830.52746.idtracker@localhost> Date: Mon, 14 Mar 2011 15:00:01 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-happy-eyeballs-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 22:00:04 -0000 --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 : Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts Author(s) : D. Wing, A. Yourtchenko Filename : draft-ietf-v6ops-happy-eyeballs-01.txt Pages : 14 Date : 2011-03-14 This document describes how a dual-stack client can determine the functioning path to a dual-stack server. This provides a seamless user experience during initial deployment of dual-stack networks and during outages of IPv4 or outages of IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-happy-eyeballs-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-v6ops-happy-eyeballs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14144610.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 15:45:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1C13A6FB1; Mon, 14 Mar 2011 15:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnJ76nE9x7ne; Mon, 14 Mar 2011 15:45:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D623A6F67; Mon, 14 Mar 2011 15:45:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314224504.22925.54527.idtracker@localhost> Date: Mon, 14 Mar 2011 15:45:04 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action:draft-ietf-v6ops-tunnel-loops-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 22:45:11 -0000 --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 : Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations Author(s) : G. Nakibly, F. Templin Filename : draft-ietf-v6ops-tunnel-loops-05.txt Pages : 19 Date : 2011-03-14 This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop which can be abused as a vehicle for traffic amplification to facilitate DoS attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-loops-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-v6ops-tunnel-loops-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14154435.I-D@ietf.org> --NextPart-- From jhw@apple.com Mon Mar 14 16:35:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BECC13A6EE3 for ; Mon, 14 Mar 2011 16:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.262 X-Spam-Level: X-Spam-Status: No, score=-106.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM9+mUgXIKb0 for ; Mon, 14 Mar 2011 16:35:11 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id CBA7E3A6B8B for ; Mon, 14 Mar 2011 16:35:10 -0700 (PDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 37A72D8FB9E7 for ; Mon, 14 Mar 2011 16:36:35 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-e4-4d7ea6832e5c Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id 7E.23.20744.386AE7D4; Mon, 14 Mar 2011 16:36:35 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.13.64] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI200D8TMWYF960@elliott.apple.com> for v6ops@ietf.org; Mon, 14 Mar 2011 16:36:34 -0700 (PDT) From: james woodyatt In-reply-to: <4D7E79F8.7000602@gmail.com> Date: Mon, 14 Mar 2011 16:36:34 -0700 Message-id: <1D7C5819-AB6A-4ADA-8ECE-085B3BE9349C@apple.com> References: <20110305184502.18531.25548.idtracker@localhost> <4D7D2BF5.9020400@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B78E@XMB-RCD-109.cisco.com> <4D7E79F8.7000602@gmail.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 23:35:11 -0000 On Mar 14, 2011, at 13:26 , Brian E Carpenter wrote: > > If it's genuine DNS you have to recurse. > > If the idea is to recommend a DNS kludge, you'l have a very interesting > discussion in IETF Last Call. Now is probably a good time to mention that one of the ways AirPort and Time Capsule split the DNS horizon is by refusing to forward unicast queries for the "local" TLD. It might make sense if the resolving server used mDNS on the LAN bridge to resolve such queries and sent all the answers it receives in a reasonable amount of time back in a single response. The trouble is deciding what is a "reasonable" time. For the sake of expediency, at Apple, we just made the DNS forwarding server respond to such queries with NXDOMAIN, which is probably the wrong RCODE value, but it was the lowest risk way to solve an immediately pressing problem (which I'm not at liberty to disclose here) related to a consequence of forwarding such queries improperly. Suffice to say, some applications may inappropriately expect that the "local" TLD is resolved *only* by mDNS and not by unicast DNS, and they may, as a consequence, adopt an insufficiently strong security profile based on the faulty assumption that on-link destination addresses are the only ones that can ever be returned from such queries on mDNS-capable hosts. Protecting faulty applications from disclosing local information over the WAN may require splitting the DNS horizon in this way. I think I might recommend that CPE routers not forward DNS queries for the "local" TLD. They should probably return RCODE=5 (REFUSED). -- james woodyatt member of technical staff, core os networking From fred@cisco.com Mon Mar 14 16:57:21 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584A13A6977 for ; Mon, 14 Mar 2011 16:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.294 X-Spam-Level: X-Spam-Status: No, score=-110.294 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JtYtS2-HEI5 for ; Mon, 14 Mar 2011 16:57:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 066D33A6A4A for ; Mon, 14 Mar 2011 16:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3182; q=dns/txt; s=iport; t=1300147124; x=1301356724; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=wJ+qqlqJdgldjcTvsrHfCly/n8LHEHf4Ky6IqrLcypA=; b=dcf9Uam4JaFhAi+J0PY3Gh435pe0Zr7rJs6h1mg30H4F808qcIsGQmF9 bNqX5gjiRcGqUh6/9U1xt3aGa2+UKg21cMVxJxTNtP/XYSBbr7B7Ml352 SRmDj1KdQO0fEWIDof72N0zAyUZ42eN8WdUhJHbj8NR5ORGVaU/b58Vyy w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGpIfk2tJV2a/2dsb2JhbACmDXelRpxGhWIEhSuHJ4NO X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="346486625" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-5.cisco.com with ESMTP; 14 Mar 2011 23:58:44 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2ENwcpJ011099; Mon, 14 Mar 2011 23:58:43 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Mon, 14 Mar 2011 16:58:43 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Mon, 14 Mar 2011 16:58:43 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <1D7C5819-AB6A-4ADA-8ECE-085B3BE9349C@apple.com> Date: Mon, 14 Mar 2011 16:58:28 -0700 Message-Id: <7A60EE41-1493-434E-B180-8AE871CB6509@cisco.com> References: <20110305184502.18531.25548.idtracker@localhost> <4D7D2BF5.9020400@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B78E@XMB-RCD-109.cisco.com> <4D7E79F8.7000602@gmail.com> <1D7C5819-AB6A-4ADA-8ECE-085B3BE9349C@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 23:57:21 -0000 On Mar 14, 2011, at 4:36 PM, james woodyatt wrote: > I think I might recommend that CPE routers not forward DNS queries for = the "local" TLD. They should probably return RCODE=3D5 (REFUSED). Would that be at all like any of the following? http://tools.ietf.org/html/draft-bpw-pcp-dhcp "DHCP and DHCPv6 Options for Port Control Protocol (PCP)", Mohammed Boucadair, Reinaldo Penno, Dan Wing, 2-Mar-11, http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd "DNS-Based Service Discovery", Stuart Cheshire, Marc Krochmal, 27-Feb-11, http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns "Multicast DNS", Stuart Cheshire, Marc Krochmal, 14-Feb-11, http://tools.ietf.org/html/draft-cheshire-dnsext-nbp "Requirements for a Protocol to Replace AppleTalk NBP", Stuart = Cheshire, Marc Krochmal, 12-Jan-11, http://tools.ietf.org/html/draft-ietf-dnsop-default-local-zones "Locally-served DNS Zones", Mark Andrews, 21-Sep-10, http://tools.ietf.org/html/draft-ietf-mediactrl-ivr-control-package "An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework", Scott McGlashan, Tim Melanchuk, Chris Boulton, 6-Jan-11, http://tools.ietf.org/html/draft-irtf-asrg-bcp-blacklists "Overview of Email DNSBL Best Practise", Chris Lewis, Matt Sergeant, 11-Mar-11, = http://tools.ietf.org/html/draft-iulian-advanced-groupware-access-protocol= "Advanced Groupware Access Protocol", Iulian Radu, 14-Nov-10, http://tools.ietf.org/html/draft-kiesel-alto-3pdisc "ALTO Server Discovery Protocol", Sebastian Kiesel, Marco Tomsu, Nico Schwan, Michael Scharf, Martin Stiemerling, 25-Oct-10, http://tools.ietf.org/html/draft-lynn-dnsext-site-mdns "Extended Multicast DNS", Kerry Lynn, Don Sturek, 7-Mar-11, http://tools.ietf.org/html/draft-salgueiro-sipclf-indexed-ascii "Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)", Gonzalo Salgueiro, Vijay Gurbani, Adam Roach, 5-Mar-11, http://tools.ietf.org/html/draft-wbeebee-v6ops-ipv6-cpe-router-bis "Advanced Requirements for IPv6 Customer Edge Routers", Hemant Singh, Wes Beebee, Chris Donley, Barbara Stark, Ole Troan, 25-Oct-10, http://tools.ietf.org/html/draft-xwwang-ipv6-tesf "TESF Based on True IPv6 Address Access", Xingwei Wang, ZhanKao Wen, = Jun Liu, WeiDong Wang, PengCheng Liu, 7-Nov-10, http://tools.ietf.org/html/draft-xwwang-ipv6tesf "TESF Based on True IPv6 Address Access", Xingwei Wang, ZhanKao Wen, WeiDong Wang, Jun Liu, PengCheng Liu, 23-Dec-10, ?= From newbery@gmail.com Mon Mar 14 19:42:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3DB53A6A3A for ; Mon, 14 Mar 2011 19:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjmpXYjxCJyH for ; Mon, 14 Mar 2011 19:42:21 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id A7F9C3A6973 for ; Mon, 14 Mar 2011 19:42:21 -0700 (PDT) Received: by ywi6 with SMTP id 6so75218ywi.31 for ; Mon, 14 Mar 2011 19:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:mime-version:content-type:subject:date :in-reply-to:to:references:message-id:x-mailer; bh=70F1hKAz68mDX/2/FMwrtzzQIXAOj+X7VYuFj4weREo=; b=iCVXmtzXIpTSUGr37lB4iqn5ALem9NsKGpcfNUnpfz1+hEIQqkgg1FOjf0zqKvJIRc rLHvNp/ziXnSv51acBrNcHOsuRjPo0nv1cF0sVkQ3QksHghvGKz1z5wG2jFGMW5opMaO 0g77KMWd0Ju9mcr+32DIMRACR/uKrrm9URXrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=wilTccRn1w3mwRjOq5RlCmJ84gcXtPL6FTx4Fj3kxpB+ZFzZpvSoqhngf1Un1XSH82 2FzEpyiSrxcGfNloSmaqCqFRq84C151RTWXVDLv6T9TgHTmUnqooJC6XK2CsocbxpaF0 Ho+femeijxMPtc+YPNjiPpIXKGgbRp/inxWy8= Received: by 10.236.95.169 with SMTP id p29mr2786180yhf.293.1300157025694; Mon, 14 Mar 2011 19:43:45 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id h30sm5775999yhm.0.2011.03.14.19.43.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2011 19:43:44 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-1--272727107; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 15 Mar 2011 15:43:39 +1300 In-Reply-To: <4D7E79F8.7000602@gmail.com> To: IPv6 Ops WG References: <20110305184502.18531.25548.idtracker@localhost> <4D7D2BF5.9020400@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B78E@XMB-RCD-109.cisco.com> <4D7E79F8.7000602@gmail.com> Message-Id: <995A62E8-8766-4553-9B6C-13BA630623D5@gmail.com> X-Mailer: Apple Mail (2.1082) Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 02:42:22 -0000 --Apple-Mail-1--272727107 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15/03/2011, at 9:26 AM, Brian E Carpenter wrote: > On 2011-03-15 03:21, Hemant Singh (shemant) wrote: >>=20 >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >> Of Brian E Carpenter >> Sent: Sunday, March 13, 2011 4:41 PM >>=20 >>> What is the meaning of "local queries"? Is this intended to imply = that >>> there are names such as printer1.example.com that are only = meaningful >>> and visible "inside" the CPE boundary? If so, what is the domain = name? >>> Is the CPE supposed to know an appropriate domain name and if so, = how? >>=20 >> "local" means the CE Router replies to queries from the LAN rather = than >> forwarding the query as a recursive DNS server. The domain name can = be >> provisioned via a DHCPv6 option from the SP or manually. =20 >=20 > Er, how does that work, if a host resolves printer11.example.com that > doesn't happen to exist? A local resolver can only recurse such a = query, > because it has no way to know that it's intended to be local. >=20 > This simply is not described well enough to make sense. As others have = noted, > you have to decide - is it genuine DNS, or a .local/mDNS style of = kludge? >=20 > If it's genuine DNS you have to recurse. >=20 > If the idea is to recommend a DNS kludge, you'l have a very = interesting > discussion in IETF Last Call. One would include a DNS in the CPE router for three reasons: 1. As a full blown DNS server, authoritative for the customer's zone 2. As a cache, in order to speed up DNS resolution 3. In order to supply local name resolution, so the user doesn't have to = type in raw IPv6 addresses. These reasons are not necessarily mutually exclusive. I question the need for (1). I especially question the need for it in = the RFC. If a manufacturer wishes to bundle a full blown DNS server in = their CPE, that's a marketing decision. I question the need for (2). Experience with the Google DNS namebench = has shown evidence that local DNS = caching just slows down performance. I fully agree with (3). But personally I would have thought that mDNS = was a better for to this particular need. --Apple-Mail-1--272727107 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwm5xTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTAxMjAyMTA2MjdaFw0x MTA3MTkyMTA2MjdaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQBlGZdPhl6SR3KKK1xXL41nqIAK9To0lIZXaqxtanIa083BHH07icuV YydeekqgxqO6z0A/3HOEJOESV5eUB9bly7zHRh7CIOB++6WzaVrFTa4yoUmhXeHF3HJmaUaxJBSl R4po3vPoii81nFIg4NSRLtRQw0ClVEvaJMkipgAWGu+b42tMNQolxBF6sCh6VOzoz9Q5t+4bwu+v d94tSGoSfuyV0sBVVaIz08VZUPYKYEM6nYEMiJzDhgH09b4CtQJ46o+YyyDb59xcuEyEd00B1tWS WUfqrYehN/W60FjopddWrG9+HaZu5+2Fz3L+da8Ggjj0g1r00cRcUURUpll+yH06D+YbhbH03kP9 P7juyvO9VfDMqYNh301h1g8PM/dDaHCUthpzedwwYeNsyTFGqzcFfsuxXvK/4BkHGPcFkyxQlqTc cWGbdxXrz42zY/ndRvzEWZ5AnlIIOsWzIySEAzhmGdlc462/kCbO8SisJYfriMcGHrJKwA2X3o8E DJ5tWayiInI/mv4BpKgIKKF5lNWgMVbYcTPtUCoCOl4mefFX+yCan/bxjRL6ae8HOMyUS6fg1v61 ypEh8WoXcoYbiGPmWP5uSpDK8Y2UGJ70T59RUgjyryFTIriZKJDZUtAD6gr0QPuQn+Fidb00OKYp XrWcXFmOdxph1ZFNMgg5ETGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJucUwCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwMzE1MDI0MzQw WjAjBgkqhkiG9w0BCQQxFgQU8FuTfQniiKXNs4Zie6BG2ESXi0QwgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCbnFMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCbnFMA0GCSqG SIb3DQEBAQUABIIBADEin8hiL4A4DGZIj6ish2UomFA92CFzdW37iJwb2bWicLlq996fkoMnJiUY DfYzLICJG2q6tNjWQo9yajNYchMByU5pEVfTK/+Qbu3Y3ByWOCUIApf8L4Y1ZgbSq3NZUiyNUvXK CrYdf9w66Gg9HBWI7XInftczZ7k/r+FNv94LHSCs7hZO+jpmuiZa28TI9CBZ34kgu1H/noz9J/mO ZmJLu4/437hlo5DTe6Dfo1bKzLGUR18HxsCDIxLloMRplIhakiQ1NIBRL6hW+ua9wHRgKSd+7Msn 1SDnYIMyUZAoOf1UoqTF0+R/6E8NdFTmi618JFqkoeJrl89MRltw8oMAAAAAAAA= --Apple-Mail-1--272727107-- From phdgang@gmail.com Mon Mar 14 19:48:38 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A073A6A80; Mon, 14 Mar 2011 19:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CucT2tHak6M0; Mon, 14 Mar 2011 19:48:37 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C59273A6973; Mon, 14 Mar 2011 19:48:36 -0700 (PDT) Received: by bwz13 with SMTP id 13so200476bwz.31 for ; Mon, 14 Mar 2011 19:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=fZW872lejgl+oHw6TvJfZ9/pNTpZlPk2aNpFDaJ0gns=; b=V6wS9fMRiQPJup98mvbLfo3XfC1757scDdX6KEoNJ/aSPrIJBUvUWb8JAWrID008ZA tGaK0X+9UCrsF9cO4IQE75u+2r4mstDn/93AwUAExBIrjEvzZDa0Sw3bwsu6vfBTImlg JP9/qIeH08QLG5Puu/XaTkNymQ0mwCbk/CcSQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=fbY4XMzMxu02QJH3KxjCT2/8VJkq2ibXzC2ZESbBulVbV2ceRG2dw4km9uGmvaEr49 AQjws8WKzG7Ep0dMTkn7t6IZ6lfsNqc6WzYc9fV1dkR8wRQdQ3HWKNbVz6fFst4VBm+x Nu45ii8XpbFTrxx2S7TgertCsIQC4W4ajtnuA= MIME-Version: 1.0 Received: by 10.204.165.193 with SMTP id j1mr11470839bky.11.1300157400006; Mon, 14 Mar 2011 19:50:00 -0700 (PDT) Received: by 10.204.80.212 with HTTP; Mon, 14 Mar 2011 19:49:59 -0700 (PDT) In-Reply-To: <20110314154501.6000.91738.idtracker@localhost> References: <20110314154501.6000.91738.idtracker@localhost> Date: Tue, 15 Mar 2011 10:49:59 +0800 Message-ID: From: GangChen To: v6ops , Behave WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] I-D Action:draft-chen-v6ops-nat64-cpe-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 02:48:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT64-CPE Mode Operation for Opening Residential Service Author(s) : G. Chen, H. Deng Filename : draft-chen-v6ops-nat64-cpe-01.txt Pages : 10 Date : 2011-03-14 The document has proposed an approach of NAT64-CPE mode, which would give residential service opportunities to be accessed by remote subscribers going through IPv6 networks. The document captures the fundamental NAT64 Functionalities with special cares to fit into CPE scenarios and don't need cooperate with DNS64 any more. In addition, the CPE mode also allows IPv4 residential hosts to access IPv6 service. It will compatible with legacy residential hosts/servers and no further updates requirements to public DNS system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-01.txt Please kindly review. Comments are appreciated. Many thanks Gang From jacniq@gmail.com Mon Mar 14 19:49:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D663A6AD4 for ; Mon, 14 Mar 2011 19:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GvdXttNSqqB for ; Mon, 14 Mar 2011 19:49:03 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 691E43A6C3A for ; Mon, 14 Mar 2011 19:49:03 -0700 (PDT) Received: by gwb20 with SMTP id 20so74119gwb.31 for ; Mon, 14 Mar 2011 19:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vt8PKFRhO+FftMxTNaCU6DFuj/vW6yBbKOhhj7HkNhU=; b=RFbcVeLnRuCebS6bkFoY8IF10W3eMBhw8TyFYm7yy2y4roGzVmpKcBUA4MBGqNCyE7 ZVNytahDvxlAz0lkrmLhX+Nla2sBlioFBsUSZnsTi1UmOM8ztgD/p/4HHc/8IEUhSVx+ RuLfcbVxf+ZPMmFhXY9ZSjYm7HJsk5gl/x9pw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ROtG+V5ojtnFsJOVpTeiWGMEjKBDhyR19qhgAkrBnBodkJQxYsnV5bUdXDoywSlPC6 SOvaxwf0kxTJ9jZ5mvR1oltOwyY3gzw6eX8tjnFUu92zpc3AA8+vA8rmxZsJUFqGV73X QONq56Ke++VccpsnzyBKypXC0UX+cJz1zsTb0= MIME-Version: 1.0 Received: by 10.146.229.4 with SMTP id b4mr18936102yah.1.1300157427420; Mon, 14 Mar 2011 19:50:27 -0700 (PDT) Received: by 10.147.40.18 with HTTP; Mon, 14 Mar 2011 19:50:27 -0700 (PDT) In-Reply-To: <20110314232357.9983F3A701A@core3.amsl.com> References: <20110314232357.9983F3A701A@core3.amsl.com> Date: Tue, 15 Mar 2011 10:50:27 +0800 Message-ID: From: Jacni Qin To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=000e0cd4d7569d0f9b049e7c7d50 Cc: draft-hu-v6ops-radius-issues-ipv6@tools.ietf.org Subject: [v6ops] Fwd: New Version Notification for draft-hu-v6ops-radius-issues-ipv6-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 02:49:04 -0000 --000e0cd4d7569d0f9b049e7c7d50 Content-Type: text/plain; charset=ISO-8859-1 Dear all, A new version of draft-hu-v6ops-radius-issues-ipv6-01 has been posted, comments are more than welcome. Cheers, Jacni ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Tue, Mar 15, 2011 at 7:23 AM Subject: New Version Notification for draft-hu-v6ops-radius-issues-ipv6-01 To: jacniq@gmail.com Cc: huj@ctbri.com.cn, oyyl191@gmail.com, wangqian@ctbri.com.cn A new version of I-D, draft-hu-v6ops-radius-issues-ipv6-01.txt has been successfully submitted by Jacni Qin and posted to the IETF repository. Filename: draft-hu-v6ops-radius-issues-ipv6 Revision: 01 Title: RADIUS issues in IPv6 deployments Creation_date: 2011-03-15 WG ID: Independent Submission Number_of_pages: 7 Abstract: This document discusses the issues encountered when using RADIUS for AAA in IPv6 deployments. The IETF Secretariat. --000e0cd4d7569d0f9b049e7c7d50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

A new version of draft-h= u-v6ops-radius-issues-ipv6-01 has been posted, comments are more than welco= me.


Cheers,
Jacni

--= -------- Forwarded message ----------
From: IETF I-D Submission Tool <idsubmission@ietf.org= >
Date: Tue, Mar 15, 2011 at 7:23 AM
Subject: New Versi= on Notification for draft-hu-v6ops-radius-issues-ipv6-01
To: jacniq@gmail.com
Cc: huj@ctbri.com.cn, oyyl191@gmail.com, wangqian@ctbri.com.cn



A new version of I-D, draft-hu-v6ops-radius-issues-ipv6-01.txt has been suc= cessfully submitted by Jacni Qin and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-hu-v6ops-radius-issues-ipv6
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 RADIUS issues in IPv6 deployments
Creation_date: =A0 2011-03-15
WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission
Number_of_pages: 7

Abstract:
This document discusses the issues encountered when using RADIUS for
AAA in IPv6 deployments.



The IETF Secretariat.



--000e0cd4d7569d0f9b049e7c7d50-- From swmike@swm.pp.se Mon Mar 14 22:01:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD2A3A6BD6 for ; Mon, 14 Mar 2011 22:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRzTjq5baSQS for ; Mon, 14 Mar 2011 22:01:49 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id AE1193A6BCD for ; Mon, 14 Mar 2011 22:01:48 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D37899C; Tue, 15 Mar 2011 06:03:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D14899A; Tue, 15 Mar 2011 06:03:10 +0100 (CET) Date: Tue, 15 Mar 2011 06:03:10 +0100 (CET) From: Mikael Abrahamsson To: Michael Newbery In-Reply-To: <995A62E8-8766-4553-9B6C-13BA630623D5@gmail.com> Message-ID: References: <20110305184502.18531.25548.idtracker@localhost> <4D7D2BF5.9020400@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B78E@XMB-RCD-109.cisco.com> <4D7E79F8.7000602@gmail.com> <995A62E8-8766-4553-9B6C-13BA630623D5@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 05:01:50 -0000 On Tue, 15 Mar 2011, Michael Newbery wrote: > I fully agree with (3). But personally I would have thought that mDNS > was a better for to this particular need. So a local resolver basically isn't needed and may be a MAY requirement? The major reason not to have one is that a lot of the time, it seems vendors get it wrong and the local resolver causes harm instead of benefit. -- Mikael Abrahamsson email: swmike@swm.pp.se From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Mar 15 04:03:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48B53A6D35 for ; Tue, 15 Mar 2011 04:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xbQ1CpzpK8c for ; Tue, 15 Mar 2011 04:03:04 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 839D73A6D33 for ; Tue, 15 Mar 2011 04:03:03 -0700 (PDT) Received: from 114-30-119-224.ip.adam.com.au ([114.30.119.224] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PzS38-00072m-Ra; Tue, 15 Mar 2011 21:34:26 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id F11915355B; Tue, 15 Mar 2011 21:34:23 +1030 (CST) Date: Tue, 15 Mar 2011 21:34:23 +1030 From: Mark Smith To: Michael Newbery Message-ID: <20110315213423.09b10142@opy.nosense.org> In-Reply-To: <995A62E8-8766-4553-9B6C-13BA630623D5@gmail.com> References: <20110305184502.18531.25548.idtracker@localhost> <4D7D2BF5.9020400@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B78E@XMB-RCD-109.cisco.com> <4D7E79F8.7000602@gmail.com> <995A62E8-8766-4553-9B6C-13BA630623D5@gmail.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 11:03:05 -0000 On Tue, 15 Mar 2011 15:43:39 +1300 Michael Newbery wrote: > > On 15/03/2011, at 9:26 AM, Brian E Carpenter wrote: > > > On 2011-03-15 03:21, Hemant Singh (shemant) wrote: > >> > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > >> Of Brian E Carpenter > >> Sent: Sunday, March 13, 2011 4:41 PM > >> > >>> What is the meaning of "local queries"? Is this intended to imply that > >>> there are names such as printer1.example.com that are only meaningful > >>> and visible "inside" the CPE boundary? If so, what is the domain name? > >>> Is the CPE supposed to know an appropriate domain name and if so, how? > >> > >> "local" means the CE Router replies to queries from the LAN rather than > >> forwarding the query as a recursive DNS server. The domain name can be > >> provisioned via a DHCPv6 option from the SP or manually. > > > > Er, how does that work, if a host resolves printer11.example.com that > > doesn't happen to exist? A local resolver can only recurse such a query, > > because it has no way to know that it's intended to be local. > > > > This simply is not described well enough to make sense. As others have noted, > > you have to decide - is it genuine DNS, or a .local/mDNS style of kludge? > > > > If it's genuine DNS you have to recurse. > > > > If the idea is to recommend a DNS kludge, you'l have a very interesting > > discussion in IETF Last Call. > > One would include a DNS in the CPE router for three reasons: > 1. As a full blown DNS server, authoritative for the customer's zone > 2. As a cache, in order to speed up DNS resolution > 3. In order to supply local name resolution, so the user doesn't have to type in raw IPv6 addresses. > > These reasons are not necessarily mutually exclusive. > > I question the need for (1). I especially question the need for it in the RFC. If a manufacturer wishes to bundle a full blown DNS server in their CPE, that's a marketing decision. > I think there is value in this, if mDNS and DNS-SD is also available. This would allow ISPs to delegate e.g. .cust. and the delegated prefix reverse to the CPE. The customer could then use DNS-SD and optionally mDNS to populate their delegated domain. > I question the need for (2). Experience with the Google DNS namebench has shown evidence that local DNS caching just slows down performance. > > I fully agree with (3). But personally I would have thought that mDNS was a better for to this particular need. > Regards, Mark. From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Mar 15 04:16:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E23A3A6B1A for ; Tue, 15 Mar 2011 04:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHbAX5F6GHvD for ; Tue, 15 Mar 2011 04:16:03 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 3237F3A6B10 for ; Tue, 15 Mar 2011 04:16:03 -0700 (PDT) Received: from 114-30-119-224.ip.adam.com.au ([114.30.119.224] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PzSFh-0007ks-UW; Tue, 15 Mar 2011 21:47:25 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 5A0975355B; Tue, 15 Mar 2011 21:47:25 +1030 (CST) Date: Tue, 15 Mar 2011 21:47:25 +1030 From: Mark Smith To: Mikael Abrahamsson Message-ID: <20110315214725.5fdb9f2b@opy.nosense.org> In-Reply-To: References: <20110305184502.18531.25548.idtracker@localhost> <4D7D2BF5.9020400@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B78E@XMB-RCD-109.cisco.com> <4D7E79F8.7000602@gmail.com> <995A62E8-8766-4553-9B6C-13BA630623D5@gmail.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 11:16:04 -0000 On Tue, 15 Mar 2011 06:03:10 +0100 (CET) Mikael Abrahamsson wrote: > On Tue, 15 Mar 2011, Michael Newbery wrote: > > > I fully agree with (3). But personally I would have thought that mDNS > > was a better for to this particular need. > > So a local resolver basically isn't needed and may be a MAY requirement? > > The major reason not to have one is that a lot of the time, it seems > vendors get it wrong and the local resolver causes harm instead of > benefit. > A possible advantage of a local resolver would be that if it received both A and AAAA RRs (over IPv4) and the WAN interface didn't support IPv6, it could avoid supplying the AAAAs to ULA IPv6 connected end-nodes on it's LAN interfaces. I'm not completely sure, however I think a drawback is that if a new RR type is added, the DNS resolver has to be upgraded to support it (or has my knowledge of DNS just failed - is it possible to issue and cache results of queries for unknown RRs?). I'm encountering this sort of issue with stateless DHCPv6 servers on CPE LAN interfaces - I'm starting to think the LAN interface of a CPE sould be a DHCPv6 relay towards an off-site stateless DHCPv6 server, with the stateless DHCPv6 server's IPv6 address supplied with an option during the stateful DHCPv6 delegated prefix transaction, if the stateless DHCPv6 server's address isn't the same as the Delegated Prefix DHCPv6 server. That would avoid a CPE's DHCPv6 option implementation restricting what options the end-nodes can use. Regards, Mark. From gert@space.net Tue Mar 15 04:39:58 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939003A6CAA for ; Tue, 15 Mar 2011 04:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDDuMe-b-SFt for ; Tue, 15 Mar 2011 04:39:57 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by core3.amsl.com (Postfix) with ESMTP id 29A843A6C78 for ; Tue, 15 Mar 2011 04:39:56 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 02B90F81A3 for ; Tue, 15 Mar 2011 12:41:20 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id DA569F8179 for ; Tue, 15 Mar 2011 12:41:19 +0100 (CET) Received: (qmail 9755 invoked by uid 1007); 15 Mar 2011 12:41:19 +0100 Date: Tue, 15 Mar 2011 12:41:19 +0100 From: Gert Doering To: Mark Smith Message-ID: <20110315114119.GM30227@Space.Net> References: <20110305184502.18531.25548.idtracker@localhost> <4D7D2BF5.9020400@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B78E@XMB-RCD-109.cisco.com> <4D7E79F8.7000602@gmail.com> <995A62E8-8766-4553-9B6C-13BA630623D5@gmail.com> <20110315214725.5fdb9f2b@opy.nosense.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110315214725.5fdb9f2b@opy.nosense.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 11:39:58 -0000 Hi, On Tue, Mar 15, 2011 at 09:47:25PM +1030, Mark Smith wrote: > A possible advantage of a local resolver would be that if it received > both A and AAAA RRs (over IPv4) and the WAN interface didn't support > IPv6, it could avoid supplying the AAAAs to ULA IPv6 connected > end-nodes on it's LAN interfaces. I don't like that idea. If I type "host www.foo.com" on my end system, I want to see what DNS has to offer, not what $somerandomdevice in the DNS recursion path thinks I might want to see. If there is no IPv6 on the WAN side, and the client still does IPv6, send back proper ICMP unreachables - and if the client cannot handle that, fix the client. Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From shemant@cisco.com Tue Mar 15 11:55:22 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69933A6B1D for ; Tue, 15 Mar 2011 11:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.958 X-Spam-Level: X-Spam-Status: No, score=-10.958 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJFvvfuQuqKD for ; Tue, 15 Mar 2011 11:55:18 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 75BB43A6E53 for ; Tue, 15 Mar 2011 11:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1861; q=dns/txt; s=iport; t=1300215402; x=1301425002; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=CLJ0pomIigdEPblOkryrduauds9c/enp6UW4PTkaC1I=; b=BaEEbNXnnn0zxMRnHu40zIyK5ecAgjq12Gp4N2hyv2jTmkfjLf6e+pLC b2ZFoxMIwGnuxjsDuN3eQ9N7mE8bXQCcmlefA82LyDPsYYqPA4DjItWLX WzT9jayYThqr2AL5veMCgtnGKeFUWA/EyAFoJCXgwlUdtKV+AnOSIWh6t Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAKhSf02tJV2a/2dsb2JhbACYS40+d6U7nQWFYgSFMIsC X-IronPort-AV: E=Sophos;i="4.63,189,1299456000"; d="scan'208";a="225886261" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2011 18:56:38 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2FIucXl012779; Tue, 15 Mar 2011 18:56:38 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 13:56:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2011 13:56:36 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> In-Reply-To: <4D7E685A.80202@bogus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvie7KDDFwbdW7GR9+1hEjByJzpFQAxH0lg References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> From: "Hemant Singh (shemant)" To: "Joel Jaeggli" , "james woodyatt" X-OriginalArrivalTime: 15 Mar 2011 18:56:38.0735 (UTC) FILETIME=[B6F99DF0:01CBE342] Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 18:55:22 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Joel Jaeggli Sent: Monday, March 14, 2011 3:11 PM To: james woodyatt Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Joel, >except in the case where the cpe is literally a bridge, I see no reason >why the service provider would have any interest at all unless they're >managing the interior network as well. I agree most cpe routers have a bridge internal to the device between the WAN and the LAN of the device. However, when one is considering any LAN interface on the cpe, I don't see any use for the LAN interface to be a bridge. My general comment is that the cpe is an IPv6 router, so the least the device has got to support is an IGP in the LAN. Thus I agree that an IGP such as RIPng should be a MUST for support in the LAN of the cpe. If the IETF cannot get an agreement on this issue, I guess it's fine. Some cpe router vendors will implement RIPng or other IPv6 IGPs and when we have interop issues we will come back to the IETF because if it's anything that the IETF is great with is to sort out Interop issues between different vendor implementations. That is why it is best if the IETF does mandate at least one IGP for a MUST. The power grid folks already came to the Beijing IETF showing us their cpe router devices will force the home to be multihomed. Power grid aside, there are finite number of homes that are multihomed already. Thus multihomed is one use case that will use the IGP in the home to distribute routes between different routed domains.=20 If one wants the IGP in the LAN to be a MAY, please articulate why and please explain how you will solve distributing routes between routed domains in the multihomed home. Thanks, Hemant From swmike@swm.pp.se Tue Mar 15 12:18:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5F63A6E61 for ; Tue, 15 Mar 2011 12:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDozUPsAMdLJ for ; Tue, 15 Mar 2011 12:18:03 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 9383E3A6B43 for ; Tue, 15 Mar 2011 12:18:03 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BD0229E; Tue, 15 Mar 2011 20:19:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BADD79C; Tue, 15 Mar 2011 20:19:27 +0100 (CET) Date: Tue, 15 Mar 2011 20:19:27 +0100 (CET) From: Mikael Abrahamsson To: "Hemant Singh (shemant)" In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> Message-ID: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:18:04 -0000 On Tue, 15 Mar 2011, Hemant Singh (shemant) wrote: > If one wants the IGP in the LAN to be a MAY, please articulate why and > please explain how you will solve distributing routes between routed > domains in the multihomed home. If DHCPv6-PD is used in the home and only the cpe router is advertising itself as a router using RA in the LAN, then it can be the default gateway for the LAN and do forwarding between the devices that have aquired prefixes using PD from it. Yes, routing will not be optimal but it'll work, and using ICMP redirects traffic will actually not be suboptimal for long. Doesn't this work for multihoming as well, we can have multiple prefixes on the same LAN and the Customer Interior Router can get multiple PDs from the different spaces? Also when reading draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt I see no mention of multihoming, would this be done with two connections to one device, or two devices? Also, if IGP support is only needed in the multihoming scenario, do we really need to make it a MUST/SHOULD for all devices this draft is handling? Can't it be a multihoming MUST then? -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Tue Mar 15 12:32:43 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB0D3A6E62 for ; Tue, 15 Mar 2011 12:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ0gjIabQFnL for ; Tue, 15 Mar 2011 12:32:42 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 56BB73A6B44 for ; Tue, 15 Mar 2011 12:32:42 -0700 (PDT) Received: by gyf3 with SMTP id 3so453955gyf.31 for ; Tue, 15 Mar 2011 12:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GQ6VydfiGOnsF2eAcwO9/Aoiej4eHWpqBnf3Xkkgxtk=; b=CaMYyDS1hJlmkba4V8EZFYDKFXiBdZyKM12L/6/2u/D2X85ugT7Npr3mjXOrXo8Jd/ e5660+c6K1PDmsOS1fKwbWuQIwnZ2+5MKeMctTq1oGByXAyMyOLCZb7dkrbfqnKqZkdw t3sWDABP+3IiULf7kE9tRYMMLUSjKZWUafeJQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NtUm4eL0yWRZtE/ALzVsf9VI+HmVLS8Y2HvFRFxYIjwlk84NrAd9ueLODk3Q+gfSY/ dxqPte1YBzmRSbWi8WlM8vbAYDD+Li408eZ5DI791SOkQguajQmkwqD99c5TJfd2e3oi LatBk9SsHtLGLzdGSln5KXR8sZMtcFRYPShCs= MIME-Version: 1.0 Received: by 10.91.209.3 with SMTP id l3mr476947agq.29.1300217646212; Tue, 15 Mar 2011 12:34:06 -0700 (PDT) Received: by 10.90.49.17 with HTTP; Tue, 15 Mar 2011 12:34:06 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> Date: Wed, 16 Mar 2011 08:34:06 +1300 Message-ID: From: Brian Carpenter To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:32:43 -0000 On Wed, Mar 16, 2011 at 7:56 AM, Hemant Singh (shemant) wrote: ... > I agree most cpe routers have a bridge internal to the device between > the WAN and the LAN of the device. However, when one is considering any > LAN interface on the cpe, I don't see any use for the LAN interface to > be a bridge. Huh? On small CPEs in my experience, the LAN side *always* behaves as a switch (i.e. a multiport bridge). That is a very useful property. They bridge between 802.3 and 802.11, too. Bridging the LAN and WAN sides is a heresy, of course, and the sooner CPEs stop doing it, the better. > My general comment is that the cpe is an IPv6 router, so > the least the device has got to support is an IGP in the LAN. Thus I > agree that an IGP such as RIPng should be a MUST for support in the LAN > of the cpe. As I said earlier, I think a MAY is sufficient - the vendors will decide anyway. I would accept a SHOULD for RIPng too. But if someone sees a market for a cheap CPE that supports exactly one flat /64 subnet, who are we to tell them not to sell that? Brian > If the IETF cannot get an agreement on this issue, I guess > it's fine. Some cpe router vendors will implement RIPng or other IPv6 > IGPs and when we have interop issues we will come back to the IETF > because if it's anything that the IETF is great with is to sort out > Interop issues between different vendor implementations. That is why it > is best if the IETF does mandate at least one IGP for a MUST. The power > grid folks already came to the Beijing IETF showing us their cpe router > devices will force the home to be multihomed. Power grid aside, there > are finite number of homes that are multihomed already. Thus multihomed > is one use case that will use the IGP in the home to distribute routes > between different routed domains. > > If one wants the IGP in the LAN to be a MAY, please articulate why and > please explain how you will solve distributing routes between routed > domains in the multihomed home. > > Thanks, > > Hemant > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From swmike@swm.pp.se Tue Mar 15 12:40:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0183A6CAC for ; Tue, 15 Mar 2011 12:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2mo4ezlqJZM for ; Tue, 15 Mar 2011 12:40:15 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id B88BB3A6A3B for ; Tue, 15 Mar 2011 12:40:14 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A6AA39C; Tue, 15 Mar 2011 20:41:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A26D19A; Tue, 15 Mar 2011 20:41:38 +0100 (CET) Date: Tue, 15 Mar 2011 20:41:38 +0100 (CET) From: Mikael Abrahamsson To: Brian Carpenter In-Reply-To: Message-ID: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:40:15 -0000 On Wed, 16 Mar 2011, Brian Carpenter wrote: > Bridging the LAN and WAN sides is a heresy, of course, and the sooner > CPEs stop doing it, the better. I don't see any reason for such a device to be handled in this draft, anyway. It's a cpe *router* draft, if it does L2 bridging between LAN and WAN then it's not a router, it's a media converter or a switch. -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Tue Mar 15 12:43:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81AEF3A6E31 for ; Tue, 15 Mar 2011 12:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeaObRQ1WRgh for ; Tue, 15 Mar 2011 12:43:00 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id ABBAF3A6979 for ; Tue, 15 Mar 2011 12:43:00 -0700 (PDT) Received: by gwb20 with SMTP id 20so455446gwb.31 for ; Tue, 15 Mar 2011 12:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VR3pLAadJjVMtzyPQLX/pJxq8HAdZwS7N0OAJ+Be0lM=; b=vj5nLhmdBUkr1UaBmy56b4ezkterYxUrVt6NlCqtkUODRwFI2V5O3a+WKFMSTLBB4e hJSrUKffyZzvYDXASi6F72D6X2LQBm79GbbByS/9iY5tIv6JWQcNKH0+UPTcviAaNSFm D3K0KW9l27gs2R6+sdiLfSVSpKBdtSTP20tic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JU8EL5o+C1Pk00WT/O7UtyPC99BvP1niZUXzr3CqcJTp3N3wZaZsR1bkod5+7qRnV1 0NSaLmQ6D1JlDrnnrz2UB/l0nM1t4nA3oOguydxdLizvb7DBW1nmkEksgPHSSiLlGCQa sOwHkVMPKNsgBftviiCGywqkBzhtbuHhZiD6M= MIME-Version: 1.0 Received: by 10.90.250.8 with SMTP id x8mr441948agh.164.1300218265770; Tue, 15 Mar 2011 12:44:25 -0700 (PDT) Received: by 10.90.49.17 with HTTP; Tue, 15 Mar 2011 12:44:25 -0700 (PDT) In-Reply-To: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> Date: Wed, 16 Mar 2011 08:44:25 +1300 Message-ID: From: Brian Carpenter To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:43:01 -0000 On Wed, Mar 16, 2011 at 8:19 AM, Mikael Abrahamsson wrote: ... > Doesn't this work for multihoming as well, we can have multiple prefixes on > the same LAN and the Customer Interior Router can get multiple PDs from the > different spaces? > > Also when reading draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt I see no > mention of multihoming, would this be done with two connections to one > device, or two devices? It's stating the obvious that a router MUST support multiple simultaneous prefixes; see the many references to "delegated prefix(es)" in draft-ietf-v6ops-ipv6-cpe-router. Is it the business of this spec to state whether the CPE has more than one WAN interface? Brian From shemant@cisco.com Tue Mar 15 12:45:42 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C0C3A6B30 for ; Tue, 15 Mar 2011 12:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.938 X-Spam-Level: X-Spam-Status: No, score=-10.938 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoMk8RXHQ4CG for ; Tue, 15 Mar 2011 12:45:41 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 680983A6E34 for ; Tue, 15 Mar 2011 12:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=914; q=dns/txt; s=iport; t=1300218427; x=1301428027; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=La87XVxVEFOAp1j5pE2VQxR5Mf+UsXGqzQ948QMYHjc=; b=N+rkdXC6zZol03Asfyyq8fsleP9sdUanZLXBdRxe7w1ZUXb1Q2eAccob OdcdixE1ZPt+PjDuCDa1oJFj2y/PRqQgdINAXgSmo1Z1Vkt+SlywenKbn pj8wrfPaJGzFnJQfC9tkk9LAhGhGBFfKYmbAcx8o5yzKPw44tybHw+Fn7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAE5ff02tJXG//2dsb2JhbACYS40+d6UdnQiFYgSFMIsCgx8 X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="347278236" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 19:47:05 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2FJl5N5029496; Tue, 15 Mar 2011 19:47:05 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 14:47:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2011 14:47:02 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3010498F4@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvjR/j51ROVIFj8T4eY8URGVDrw/QAAFNtg References: <20110305184502.18531.25548.idtracker@localhost><76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com><4D7E685A.80202@bogus.com><5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Brian Carpenter" X-OriginalArrivalTime: 15 Mar 2011 19:47:05.0730 (UTC) FILETIME=[C3346620:01CBE349] Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:45:42 -0000 -----Original Message----- From: Brian Carpenter [mailto:brian.e.carpenter@gmail.com]=20 Sent: Tuesday, March 15, 2011 3:34 PM To: Hemant Singh (shemant) Cc: Joel Jaeggli; james woodyatt; IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >Huh? On small CPEs in my experience, the LAN side *always* behaves as a switch >(i.e. a multiport bridge). That is a very useful property. They bridge between >802.3 and 802.11, too. The "internal" does include specific hardware that bridges not just between the WAN and the LAN but as you said, any LAN interface, if necessary. This is the property of the bridged hardware.=20 >Bridging the LAN and WAN sides is a heresy, of course, and the sooner CPEs stop >doing it, the better. Not heresy. Any networking router hardware can be programmed to be a network switch or a network bridge. =20 Hemant From brian.e.carpenter@gmail.com Tue Mar 15 12:49:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6E33A6B92 for ; Tue, 15 Mar 2011 12:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knrk3OLdG6-j for ; Tue, 15 Mar 2011 12:49:19 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id F3E5C3A6B30 for ; Tue, 15 Mar 2011 12:49:18 -0700 (PDT) Received: by gwb20 with SMTP id 20so457905gwb.31 for ; Tue, 15 Mar 2011 12:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ot7yZVpemIxm08ngq7S5yZVfzqcprZbM7xsg7k7GIj0=; b=hsT/9xEs2o7rSnkzWhvVdra0zh3tANNqG8RH9xcW096JaBcKorYXzQNcqD8CKHl6yr KOeEO/eV/t3fCLiVhwrrZhB/SEatn6wPvBy9wWGISHKnVGMvNUficAfyAnbxmK246p/Z mh5RiS6dyizDjOPnVkNpKygM0L5UEu/owPcbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LxKQ/oG8f6YN9K0TGIxEO67ADFm5kx/KC0BgGP0JqZGbjfUtSJCTEMuMlqJJRkOWNN kCaQ0hTQuKZ3FPQ9SHcsbK3RQXoqruSWDVa37l1aLeNXOrN+cSFxcDbdmL8KqkcgyCzP lKa6MSxay7Wb/rNVVwbQIxrHYtWd5sKC+BkW0= MIME-Version: 1.0 Received: by 10.90.37.12 with SMTP id k12mr419049agk.191.1300218644188; Tue, 15 Mar 2011 12:50:44 -0700 (PDT) Received: by 10.90.49.17 with HTTP; Tue, 15 Mar 2011 12:50:44 -0700 (PDT) In-Reply-To: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> Date: Wed, 16 Mar 2011 08:50:44 +1300 Message-ID: From: Brian Carpenter To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:49:19 -0000 On Wed, Mar 16, 2011 at 8:41 AM, Mikael Abrahamsson wrote: > On Wed, 16 Mar 2011, Brian Carpenter wrote: > >> Bridging the LAN and WAN sides is a heresy, of course, and the sooner CPEs >> stop doing it, the better. > > I don't see any reason for such a device to be handled in this draft, > anyway. It's a cpe *router* draft, if it does L2 bridging between LAN and > WAN then it's not a router, it's a media converter or a switch. And will not work properly for IPv6, which intrinsically requires a router. I think this should be stated somehow, in a few words. Brian From swmike@swm.pp.se Tue Mar 15 12:50:10 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DD873A6E95 for ; Tue, 15 Mar 2011 12:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcrYv+eS8W47 for ; Tue, 15 Mar 2011 12:50:02 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 23D9D3A6E68 for ; Tue, 15 Mar 2011 12:50:00 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DA8329C; Tue, 15 Mar 2011 20:51:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D822F9A; Tue, 15 Mar 2011 20:51:24 +0100 (CET) Date: Tue, 15 Mar 2011 20:51:24 +0100 (CET) From: Mikael Abrahamsson To: Brian Carpenter In-Reply-To: Message-ID: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:50:11 -0000 On Wed, 16 Mar 2011, Brian Carpenter wrote: >> Also when reading draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt I see no >> mention of multihoming, would this be done with two connections to one >> device, or two devices? > > It's stating the obvious that a router MUST support multiple > simultaneous prefixes; > see the many references to "delegated prefix(es)" in > draft-ietf-v6ops-ipv6-cpe-router. Oki, I looked at the network drawing and there was only a single SP and there was only a single uplink router. If there is a scenario with multiple devices from multiple SPs that is to be included in this draft, then I think the scenario needs to be explained. > Is it the business of this spec to state whether the CPE has more than one WAN > interface? I don't know. If the IGP requirement for multihoming is because there are multiple SPs and multiple CPE routers in the home (one from each SP), doesn't that need to be explicitly stated? -- Mikael Abrahamsson email: swmike@swm.pp.se From shemant@cisco.com Tue Mar 15 12:57:49 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CEC63A6B30 for ; Tue, 15 Mar 2011 12:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.92 X-Spam-Level: X-Spam-Status: No, score=-10.92 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpW9nRHdgz4F for ; Tue, 15 Mar 2011 12:57:48 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 43E163A6A8B for ; Tue, 15 Mar 2011 12:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1302; q=dns/txt; s=iport; t=1300219153; x=1301428753; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4W0EADYl4Rwiryr2N9jl5lKyQ/1keJ2vj7PaRc8juUM=; b=RZz1fm4k50rjS39JMVZEMh3XTYLQrqB+KEuqqDF0AecFSQ10idSsLKsk OvTpYNSlx5PsWXmldFgEQosqzTDMhHhs9v/LYBfNmJeLBCk13sBhm7C8n C1ohV2oCWt0jGsHpEw9JfQfdN4Pjy/aIMOzNsgwtZRJAbO5dwjq9x9NIx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAOJhf02tJV2Y/2dsb2JhbACYTI0+d6UZnQSFYgSFMIsC X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="414684438" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-1.cisco.com with ESMTP; 15 Mar 2011 19:59:13 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2FJxD5D028061; Tue, 15 Mar 2011 19:59:13 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 14:59:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2011 14:59:11 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvjRfBQn8PfYDxgT46d7NhA99w8NQABFfYA References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Mikael Abrahamsson" X-OriginalArrivalTime: 15 Mar 2011 19:59:13.0434 (UTC) FILETIME=[74F337A0:01CBE34B] Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:57:49 -0000 -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Tuesday, March 15, 2011 3:19 PM To: Hemant Singh (shemant) Cc: Joel Jaeggli; james woodyatt; IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >Doesn't this work for multihoming as well, we can have multiple prefixes=20 >on the same LAN and the Customer Interior Router can get multiple PDs from=20 >the different spaces? How does my home computer addressed with the SP1 IPv6 global address from PD1 print to the printer addresses with the SP2 IPv6 global address from PD2 unless the PD2 subnet prefix is propagated by some means between the two network domains? An IGP is needed or one could use MSR (RFC 4191) in some cases of the home network.=20 >Also when reading draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt I see no=20 >mention of multihoming, would this be done with two connections to one=20 >device, or two devices? You are correct. The current version does not support multihoming. However multihoming is one feature that is under consideration to add to the document. One use case we have in mind is a home served by two different SP's using two different IPv6 CE routers with one WAN interface on each device.=20 Hemant From swmike@swm.pp.se Tue Mar 15 13:04:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223D73A6D9A for ; Tue, 15 Mar 2011 13:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZkEjBQjIiAp for ; Tue, 15 Mar 2011 13:04:22 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 6E7AC3A6A71 for ; Tue, 15 Mar 2011 13:04:22 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CFAB59C; Tue, 15 Mar 2011 21:05:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CB7199A; Tue, 15 Mar 2011 21:05:46 +0100 (CET) Date: Tue, 15 Mar 2011 21:05:46 +0100 (CET) From: Mikael Abrahamsson To: "Hemant Singh (shemant)" In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> Message-ID: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:04:24 -0000 On Tue, 15 Mar 2011, Hemant Singh (shemant) wrote: > How does my home computer addressed with the SP1 IPv6 global address > from PD1 print to the printer addresses with the SP2 IPv6 global address > from PD2 unless the PD2 subnet prefix is propagated by some means > between the two network domains? An IGP is needed or one could use MSR > (RFC 4191) in some cases of the home network. In this scenario an IGP is indeed needed. So for a device to support this setup, IGP is a MUST. I do though see a lot of trouble to get this kind of setup to work automatically, how do you get DNS to work for instance? > You are correct. The current version does not support multihoming. > However multihoming is one feature that is under consideration to add to > the document. One use case we have in mind is a home served by two > different SP's using two different IPv6 CE routers with one WAN > interface on each device. In that case, make this a specific deployment scenario and make an IGP a MUST, in the other cases it can be a CAN. How do we choose the IGP? From what I know, RIP (any variant) seems more prevalent than OSPF on this class of devices historically, should that be interpreted as RIP being easier to implement and that's why it should be preferred over OSPF for home use? -- Mikael Abrahamsson email: swmike@swm.pp.se From shemant@cisco.com Tue Mar 15 13:11:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D59C3A6B4E for ; Tue, 15 Mar 2011 13:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.904 X-Spam-Level: X-Spam-Status: No, score=-10.904 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v80cS3j7WB9b for ; Tue, 15 Mar 2011 13:11:52 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 60A2C3A6A3B for ; Tue, 15 Mar 2011 13:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=706; q=dns/txt; s=iport; t=1300219998; x=1301429598; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ZxmqogV6LMBj0zpk8KIs49buxBUeUrZIjdqsZso+C4s=; b=DAD2pZzkASWPKOJU/TsNyCyZdZD8kgKr/JR3w8VzK6gX9RN9D2MYpcBQ RCS8my5HdsZqHciX+4Hrvm3s2pQcUMFZGRYYgCO8wWfGH3b9fkrJ9AE9u wUZT+Sim5TSo8+175zTzWqCrWuWUtezwkhxC5i8ZenYlQ52v1Iu9wvk2c 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAGdlf02tJXHA/2dsb2JhbACYTI0+d6UVnQSFYgSFMIsC X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="414691830" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-1.cisco.com with ESMTP; 15 Mar 2011 20:13:17 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2FKDH7V002687; Tue, 15 Mar 2011 20:13:17 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 15:13:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2011 15:13:16 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C301049957@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvjTGRHi2kCDEt1QmeYSEkYnWsZPwAAB2rA References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Mikael Abrahamsson" X-OriginalArrivalTime: 15 Mar 2011 20:13:17.0679 (UTC) FILETIME=[6C28C7F0:01CBE34D] Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:11:53 -0000 -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Tuesday, March 15, 2011 4:06 PM To: Hemant Singh (shemant) Cc: Joel Jaeggli; james woodyatt; IPv6 Ops WG Subject: RE: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >In this scenario an IGP is indeed needed. >So for a device to support this setup, IGP is a MUST. I do though see a >lot of trouble to get this kind of setup to work automatically, how do you=20 >get DNS to work for instance? How does DNS work today in an Enterprise across two routed domains with different subnet prefixes? One way is to have both domains go to one root DNS server for the domains. Hemant From swmike@swm.pp.se Tue Mar 15 13:19:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AAC93A6B49 for ; Tue, 15 Mar 2011 13:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT8o16VJVzmO for ; Tue, 15 Mar 2011 13:19:35 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 265863A6A8B for ; Tue, 15 Mar 2011 13:19:34 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2E9C49C; Tue, 15 Mar 2011 21:20:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2B4B29A; Tue, 15 Mar 2011 21:20:59 +0100 (CET) Date: Tue, 15 Mar 2011 21:20:59 +0100 (CET) From: Mikael Abrahamsson To: "Hemant Singh (shemant)" In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C301049957@XMB-RCD-109.cisco.com> Message-ID: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049957@XMB-RCD-109.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:19:36 -0000 On Tue, 15 Mar 2011, Hemant Singh (shemant) wrote: >> So for a device to support this setup, IGP is a MUST. I do though see a >> lot of trouble to get this kind of setup to work automatically, how do >> you get DNS to work for instance? > > How does DNS work today in an Enterprise across two routed domains with > different subnet prefixes? One way is to have both domains go to one > root DNS server for the domains. I guess I wasn't clear. Let me try to be more specific: How would the printer automatically be discovered in the home, or at least how would a DNS name pointing AAAA to the printers IPv6 address be entered into a domain name the user can enter, that would dynamically change as the PD prefixes change over time? -- Mikael Abrahamsson email: swmike@swm.pp.se From sthaug@nethelp.no Tue Mar 15 13:26:52 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D533A6E44 for ; Tue, 15 Mar 2011 13:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.27 X-Spam-Level: X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+uSgAIa2zpy for ; Tue, 15 Mar 2011 13:26:51 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by core3.amsl.com (Postfix) with SMTP id ED7AF3A6A8B for ; Tue, 15 Mar 2011 13:26:50 -0700 (PDT) Received: (qmail 69502 invoked from network); 15 Mar 2011 20:28:14 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Mar 2011 20:28:14 -0000 Date: Tue, 15 Mar 2011 21:28:14 +0100 (CET) Message-Id: <20110315.212814.74695734.sthaug@nethelp.no> To: brian.e.carpenter@gmail.com From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:26:52 -0000 > >> Bridging the LAN and WAN sides is a heresy, of course, and the sooner CPEs > >> stop doing it, the better. > > > > I don't see any reason for such a device to be handled in this draft, > > anyway. It's a cpe *router* draft, if it does L2 bridging between LAN and > > WAN then it's not a router, it's a media converter or a switch. > > And will not work properly for IPv6, which intrinsically requires a > router. I think > this should be stated somehow, in a few words. I don't see *why* IPv6 wouldn't work for instance behind a plain bridge type DSL modem. But if that is indeed the case, it needs to be explained. Agreed that such a device is not relevant for a CPE router document. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From ichiroumakino@gmail.com Tue Mar 15 13:28:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5285C3A6E7B for ; Tue, 15 Mar 2011 13:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSYKQ8CQBEdm for ; Tue, 15 Mar 2011 13:28:30 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 526E33A6E44 for ; Tue, 15 Mar 2011 13:28:30 -0700 (PDT) Received: by wyb42 with SMTP id 42so1049258wyb.31 for ; Tue, 15 Mar 2011 13:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=dJeHiArGHVShS54yTBgcHANxH1/Sa7hONm5W9Ta10lw=; b=DI2QpeUVNEuC2/xuERjizlo3ogS4jD6qmi+zLekCjhjEZZlpr+hh3NLQ3+nP4t6MOI xnMQD1eIc3wGCujhxP0SPIDilXq532yLep5eNEln07QzoPeVhToFoP8YQsoJYq4NZX8W p7VpCA5A2lDYGesllMi6LiVDveJZ3shZAvhxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=AHHC2H66wtK4o9i7z1B4/cS1drlQOboAxPsH6J4vAL5u/ImRNzBr74/veXc9JW0mXl I+EMEO/vw4KL5o9mUHOOhPvhB+gL63SczMF+qw+m2Pr9PMH2HaiZvYZfbtS+uzWN19ye 3jGv/D85TN3vCsrDD3naud1iWf9OBgIc2F77w= Received: by 10.227.136.204 with SMTP id s12mr12985390wbt.15.1300220995177; Tue, 15 Mar 2011 13:29:55 -0700 (PDT) Received: from gomlefisk.cisco.com (152.84-48-210.nextgentel.com [84.48.210.152]) by mx.google.com with ESMTPS id u9sm193152wbg.12.2011.03.15.13.29.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2011 13:29:54 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Tue, 15 Mar 2011 21:29:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0EDD6F66-D326-4656-B767-48C9B73989A3@employees.org> References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049957@XMB-RCD-109.cisco.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:28:31 -0000 Mikael, >>> So for a device to support this setup, IGP is a MUST. I do though = see a lot of trouble to get this kind of setup to work automatically, = how do you get DNS to work for instance? >>=20 >> How does DNS work today in an Enterprise across two routed domains = with >> different subnet prefixes? One way is to have both domains go to one >> root DNS server for the domains. >=20 > I guess I wasn't clear. Let me try to be more specific: >=20 > How would the printer automatically be discovered in the home, or at = least how would a DNS name pointing AAAA to the printers IPv6 address be = entered into a domain name the user can enter, that would dynamically = change as the PD prefixes change over time? Service Discovery has to be extended to work across a larger scope than = link-local. i.e. you also need automatically enabled multicast routing in these = networks too. see the failed homenet charter. cheers, Ole From jhw@apple.com Tue Mar 15 13:36:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97363A6E9B for ; Tue, 15 Mar 2011 13:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3h+6RpN6XNm for ; Tue, 15 Mar 2011 13:36:57 -0700 (PDT) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 088C23A6E6E for ; Tue, 15 Mar 2011 13:36:57 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 9955FD9330A1 for ; Tue, 15 Mar 2011 13:38:22 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-1b-4d7fce3e5f45 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay15.apple.com (Apple SCV relay) with SMTP id 8E.56.18996.E3ECF7D4; Tue, 15 Mar 2011 13:38:22 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.13.64] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI400CR79BYSH70@gertie.apple.com> for v6ops@ietf.org; Tue, 15 Mar 2011 13:38:22 -0700 (PDT) From: james woodyatt In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> Date: Tue, 15 Mar 2011 13:38:22 -0700 Message-id: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:36:58 -0000 On Mar 15, 2011, at 11:56 , Hemant Singh (shemant) wrote: > > The power grid folks already came to the Beijing IETF showing us their cpe router devices will force the home to be multihomed. Huh? Where is the draft that documents this? -- james woodyatt member of technical staff, core os networking From shemant@cisco.com Tue Mar 15 13:37:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70BA63A6E06 for ; Tue, 15 Mar 2011 13:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.889 X-Spam-Level: X-Spam-Status: No, score=-10.889 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc265+iVwJxe for ; Tue, 15 Mar 2011 13:37:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9F75B3A6975 for ; Tue, 15 Mar 2011 13:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=767; q=dns/txt; s=iport; t=1300221536; x=1301431136; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Aa5KlKvIHK9aDcyvJaoeWIgS3ZTu7g0UIiPb8uDGexU=; b=Fq4zkonKfZX6TwDRL5ZpN/r4mCwPMVQnjuW5aK9pEYG421iSE101LkPI LOttPy7g6/fSaX9EI0Lq4g7h+FKDhkn007WvaA4e+N14bTjoyucwDpMw8 jiAvwqhV6vGIkd6os1LCbc5/RawyF9kIbAvMXihH2YYfEDPXfu3hr/P4q c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAJhqf02tJV2Z/2dsb2JhbACYTI0+d6UJnQCFYgSFMIsCgx8 X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="320643779" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2011 20:38:56 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2FKct7u008605; Tue, 15 Mar 2011 20:38:55 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 15:38:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2011 15:38:54 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30104998F@XMB-RCD-109.cisco.com> In-Reply-To: <0EDD6F66-D326-4656-B767-48C9B73989A3@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvjT8MNH5ZCWP5PR4GFif8k4vv6yQAAErow References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049957@XMB-RCD-109.cisco.com> <0EDD6F66-D326-4656-B767-48C9B73989A3@employees.org> From: "Hemant Singh (shemant)" To: "Ole Troan" , "Mikael Abrahamsson" X-OriginalArrivalTime: 15 Mar 2011 20:38:55.0994 (UTC) FILETIME=[011105A0:01CBE351] Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:37:40 -0000 -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Tuesday, March 15, 2011 4:30 PM To: Mikael Abrahamsson Cc: Hemant Singh (shemant); IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >Service Discovery has to be extended to work across a larger scope than link-local. >i.e. you also need automatically enabled multicast routing in these networks too. >see the failed homenet charter. Thanks, Ole. Also, Mikael, if one uses the ULA addressing on the CE router and the printer, then the ULA is constant and easier for DNS to manage. Even when the SP link goes down and thus the global on the nodes is no longer usable, the ULA persists. =20 Hemant From shemant@cisco.com Tue Mar 15 13:46:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F43C3A6E4D for ; Tue, 15 Mar 2011 13:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V7EOhGCbcGg for ; Tue, 15 Mar 2011 13:46:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 64B453A6975 for ; Tue, 15 Mar 2011 13:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1293; q=dns/txt; s=iport; t=1300222078; x=1301431678; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=5ISIjeoehHY1vZWdsvsR7DmEDbJIJDIXOdx01YmmCJw=; b=ffynoa12TufIcehlX8/y/bE7jRouL+6UopW7PXxPEad0jPYcLLV2z6HM ZmLCezbIo8/Ey4W0yDnKNAQY6W6e0Q74qUKq3ThUwibUtllF+Y7uQHB7k Lhh+KPPnzzXZaWQxctzhA0q1LEK9oiPIuhQWlWLyL1NZnHdyCG29T6A15 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUBAOZsf02tJV2Z/2dsb2JhbACYTo0+d6UGnH6FYgSFMIsC X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="667461896" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 15 Mar 2011 20:47:57 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2FKlviJ016807; Tue, 15 Mar 2011 20:47:57 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 15:47:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2011 15:47:55 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3010499AA@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvjUPgF4bdZzDciQU6+FzmuDY0wHAAAE+2g References: <20110305184502.18531.25548.idtracker@localhost><76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com><4D7E685A.80202@bogus.com><5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "james woodyatt" , "IPv6 Ops WG" X-OriginalArrivalTime: 15 Mar 2011 20:47:57.0268 (UTC) FILETIME=[43B0E140:01CBE352] Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:46:33 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Tuesday, March 15, 2011 4:38 PM To: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >Huh? Where is the draft that documents this? http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 Snipped from the Abstract of the document above, is this text between squared brackets. [WiFi access points, cable boxes and other home devices with internet access could all be internetworked with smart metering devices by customers with no data networking expertise resulting in a complex multi-segment network with differing prefixes, routing support and service discovery needs.] I am sure there is other text in the document that points out two different routers in the home connected to two different SPs (one SP is the home's DSL or broadband SP and the other SP is the Power Grid company with their IPv6 CE router for the home) and thus one has a multihomed home. Anyway, you should look at Tom Herbst's prezo given to the v6ops at the IETF79 in Beijing that clearly shows a multihomed network. Note also that multihomed involves both a multihomed WAN and LAN for CE Router. Hemant From swmike@swm.pp.se Tue Mar 15 13:47:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E648A3A6EB1 for ; Tue, 15 Mar 2011 13:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8agu25Mq2TiO for ; Tue, 15 Mar 2011 13:47:31 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id D44DE3A691E for ; Tue, 15 Mar 2011 13:47:30 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AA9409C; Tue, 15 Mar 2011 21:48:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A75069A; Tue, 15 Mar 2011 21:48:55 +0100 (CET) Date: Tue, 15 Mar 2011 21:48:55 +0100 (CET) From: Mikael Abrahamsson To: "Hemant Singh (shemant)" In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30104998F@XMB-RCD-109.cisco.com> Message-ID: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049957@XMB-RCD-109.cisco.com> <0EDD6F66-D326-4656-B767-48C9B73989A3@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C30104998F@XMB-RCD-109.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:47:32 -0000 On Tue, 15 Mar 2011, Hemant Singh (shemant) wrote: > Thanks, Ole. Also, Mikael, if one uses the ULA addressing on the CE > router and the printer, then the ULA is constant and easier for DNS to > manage. Even when the SP link goes down and thus the global on the > nodes is no longer usable, the ULA persists. So the recommendation is that all home subnetworks should have ULA as well as one PD prefix from each SP? Is the ULA prefix PDed from the CPE router so all home routers gets multiple PDs? Or is this where the IGP comes in, that each router in the home should create a ULA for each LAN interface and announce this to its upstream interface (not to the SP, but to the CPE router) ? -- Mikael Abrahamsson email: swmike@swm.pp.se From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Mar 15 13:53:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E233A3A691E for ; Tue, 15 Mar 2011 13:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dA89xWUX1kuI for ; Tue, 15 Mar 2011 13:53:39 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id D0B003A6A2D for ; Tue, 15 Mar 2011 13:53:38 -0700 (PDT) Received: from 114-30-119-224.ip.adam.com.au ([114.30.119.224] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PzbGe-0000XL-8N; Wed, 16 Mar 2011 07:25:00 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id C9F555355B; Wed, 16 Mar 2011 07:24:59 +1030 (CST) Date: Wed, 16 Mar 2011 07:24:58 +1030 From: Mark Smith To: Gert Doering Message-ID: <20110316072458.1e5e1e0c@opy.nosense.org> In-Reply-To: <20110315114119.GM30227@Space.Net> References: <20110305184502.18531.25548.idtracker@localhost> <4D7D2BF5.9020400@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B78E@XMB-RCD-109.cisco.com> <4D7E79F8.7000602@gmail.com> <995A62E8-8766-4553-9B6C-13BA630623D5@gmail.com> <20110315214725.5fdb9f2b@opy.nosense.org> <20110315114119.GM30227@Space.Net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:53:41 -0000 Hi Gert, On Tue, 15 Mar 2011 12:41:19 +0100 Gert Doering wrote: > Hi, > > On Tue, Mar 15, 2011 at 09:47:25PM +1030, Mark Smith wrote: > > A possible advantage of a local resolver would be that if it received > > both A and AAAA RRs (over IPv4) and the WAN interface didn't support > > IPv6, it could avoid supplying the AAAAs to ULA IPv6 connected > > end-nodes on it's LAN interfaces. > > I don't like that idea. > > If I type "host www.foo.com" on my end system, I want to see what DNS has > to offer, not what $somerandomdevice in the DNS recursion path thinks I > might want to see. > It could be an option to switch this behaviour off in a CPE for people such as yourself. dnssec would probably stop this working, so that probably limits its usefulness lifetime. > If there is no IPv6 on the WAN side, and the client still does IPv6, send > back proper ICMP unreachables - and if the client cannot handle that, fix the > client. > I certainly think this is a better solution. However there are a few things that may influence is effectiveness - that generating unreachables is a SHOULD not a MUST, and they're rate limited, so there are still opportunities for the IPv6 unreachable timeouts. Regards, Mark. From d.sturek@att.net Tue Mar 15 13:54:32 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D033A6EA0 for ; Tue, 15 Mar 2011 13:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.049 X-Spam-Level: X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOySaajv00ow for ; Tue, 15 Mar 2011 13:54:31 -0700 (PDT) Received: from nm1-vm0.bullet.mail.ne1.yahoo.com (nm1-vm0.bullet.mail.ne1.yahoo.com [98.138.91.74]) by core3.amsl.com (Postfix) with SMTP id 2BD963A6E92 for ; Tue, 15 Mar 2011 13:54:31 -0700 (PDT) Received: from [98.138.90.55] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 15 Mar 2011 20:55:53 -0000 Received: from [98.138.89.251] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 15 Mar 2011 20:55:53 -0000 Received: from [127.0.0.1] by omp1043.mail.ne1.yahoo.com with NNFMP; 15 Mar 2011 20:55:53 -0000 X-Yahoo-Newman-Id: 922017.18618.bm@omp1043.mail.ne1.yahoo.com Received: (qmail 49130 invoked from network); 15 Mar 2011 20:55:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1300222553; bh=MP5Vrbi0XCVDcOoJueL9RDO5xl95hIAlAJYVY1GHlwg=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=A4aTNk7L1GArSzQiv9xqBrqhIP2QZa1Zz3fno+TeaimcGQ7i3jY1+z044kcXf3Z6JZC/Pa4ZH6nRhjlfz1FKAajWQmQpGdhKj3J2skull1s4k50VXaQUs0vfmdAUEMS/ibhMpcfe8h3fCxcUyScOA0wqB4ZDi63wN2rjiWzFNl0= Received: from Studio (d.sturek@174.78.56.227 with login) by smtp108.sbc.mail.gq1.yahoo.com with SMTP; 15 Mar 2011 13:55:53 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 9M6LMlIVM1kZErBqmYeqhSoDTvbkgTdmlqs5ykdqfQHute1 5kWs5NvPD9A293imUq7Z5.LJ9Hd.hRRvvUc6KJP_zAiOeB_p0UiwtFq5gWK_ Frywz2GXw873pojqccrlm8OO7D_bKO6ATBDELyyL7nlDPhhm.eMdSQctQJB6 Yc9.Z9QsES_jR3BpkT6bXsdxZOZakxnIv7zhHSb9mfQGRFRljMoL526YXj.. 17f0WlilNwY3lyF3X97UudwlIH2DKAJjS7udUO8TFNm_Lgea1YjXzLqyUe7i HoHgFo2NgI9Eh7c7GngNiZR_tGpM3enyvILWSgteC93RMW6WLVXz1VAU5azb b.yhV X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Hemant Singh \(shemant\)'" , "'james woodyatt'" , "'IPv6 Ops WG'" References: <20110305184502.18531.25548.idtracker@localhost><76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com><4D7E685A.80202@bogus.com><5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3010499AA@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3010499AA@XMB-RCD-109.cisco.com> Date: Tue, 15 Mar 2011 13:55:50 -0700 Message-ID: <000a01cbe353$5e325a20$1a970e60$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjUPgF4bdZzDciQU6+FzmuDY0wHAAAE+2gAABjBhA= Content-Language: en-us Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:54:32 -0000 Hi Hermant, Both Tom Herbst and myself (Don Sturek, representing Pacific Gas and Electric) will be in Prague and would like to discuss further the CPE Enhancements draft and the requirements around internetworked CPE within a home. As outlined in the http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 draft, activities are underway to deploy IPv6 enabled smart meters as well as support in WiFi and HomePlug to internetwork these smart meters with existing home networks connected to existing ISPs. The scenarios described in the draft are a little more than a year from large scale deployment (11 million smart meters installed to date) Don -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Tuesday, March 15, 2011 1:48 PM To: james woodyatt; IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Tuesday, March 15, 2011 4:38 PM To: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >Huh? Where is the draft that documents this? http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 Snipped from the Abstract of the document above, is this text between squared brackets. [WiFi access points, cable boxes and other home devices with internet access could all be internetworked with smart metering devices by customers with no data networking expertise resulting in a complex multi-segment network with differing prefixes, routing support and service discovery needs.] I am sure there is other text in the document that points out two different routers in the home connected to two different SPs (one SP is the home's DSL or broadband SP and the other SP is the Power Grid company with their IPv6 CE router for the home) and thus one has a multihomed home. Anyway, you should look at Tom Herbst's prezo given to the v6ops at the IETF79 in Beijing that clearly shows a multihomed network. Note also that multihomed involves both a multihomed WAN and LAN for CE Router. Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Tue Mar 15 13:56:52 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4EA3A6E92 for ; Tue, 15 Mar 2011 13:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.851 X-Spam-Level: X-Spam-Status: No, score=-10.851 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsWVMY5CXTev for ; Tue, 15 Mar 2011 13:56:51 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 503AB3A6B45 for ; Tue, 15 Mar 2011 13:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1411; q=dns/txt; s=iport; t=1300222697; x=1301432297; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=M00Gzv5FnrwSPJSqUVO5h6hUBPjRoBeHytose6scrCE=; b=Xgq90GiVT00XFNdj2/0V1wU1B6Vv8yrDs+gUeCiIwyI5GVcJJd9fBPz8 dn6V+NtB1CjFyytkbN624mG4oCIVfbSyX5Q8nsstIehGB0P15Z3rGQ8vC AKZh8Dap7kgRUwNin+mck/6mNYHrZpQ2HZbRJQiJmV+Sf43w+kqdFiPb9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUBALZvf02tJXG//2dsb2JhbACYT40+d6R9nH2FYgSFMIsC X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="347352276" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2011 20:58:15 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2FKwE8A018686; Tue, 15 Mar 2011 20:58:14 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 15:58:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2011 15:58:13 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3010499C3@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvjUnuH4CJm+WTNQ+WwJQ2EdOftYgAABV4Q References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049957@XMB-RCD-109.cisco.com> <0EDD6F66-D326-4656-B767-48C9B73989A3@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C30104998F@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Mikael Abrahamsson" X-OriginalArrivalTime: 15 Mar 2011 20:58:14.0513 (UTC) FILETIME=[B398FE10:01CBE353] Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:56:52 -0000 -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Tuesday, March 15, 2011 4:49 PM To: Hemant Singh (shemant) Cc: Ole Troan; IPv6 Ops WG Subject: RE: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >So the recommendation is that all home subnetworks should have ULA as well=20 >as one PD prefix from each SP? Is the ULA prefix PDed from the CPE router=20 >so all home routers gets multiple PDs? IPv6 from the womb supports multiple IPv6 addresses configured on a network interfaces. Yes, the hosts in the home are expected be served by multiple PD's - at least the ULA and one global IPv6 PD from the SP.=20 >Or is this where the IGP comes in, that each router in the home should=20 >create a ULA for each LAN interface and announce this to its upstream=20 >interface (not to the SP, but to the CPE router) ? Yes. However, if the routed topology of the home in a tree topology and the routers are thus using recursive prefix delegation, then no IGP is needed to propagate a downstream PD subnet prefix to the upstream router(s). The reason is because the upstream router snoops dhcpv6 messages during prefix delegation and thus the router knows what prefix subnet is assigned downstream. Soon as the home network is NOT a tree routed topology, an IGP is needed to propagate subnet prefix routes upstream.=20 Hemant From therbst@silverspringnet.com Tue Mar 15 13:59:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FEC3A691E for ; Tue, 15 Mar 2011 13:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnP1C0-42wRH for ; Tue, 15 Mar 2011 13:59:12 -0700 (PDT) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by core3.amsl.com (Postfix) with ESMTP id 2B1E03A6EBF for ; Tue, 15 Mar 2011 13:59:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAPNvf00KyAE+/2dsb2JhbACYT441wXyFYgSFMIsW X-IronPort-AV: E=Sophos;i="4.63,190,1299484800"; d="scan'208";a="3564089" Received: from unknown (HELO IT-EXCA-02.silverspringnet.com) ([10.200.1.62]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 15 Mar 2011 14:00:33 -0700 Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-02.silverspringnet.com ([::1]) with mapi; Tue, 15 Mar 2011 14:00:33 -0700 From: Thomas Herbst To: "Hemant Singh (shemant)" , james woodyatt , IPv6 Ops WG Date: Tue, 15 Mar 2011 14:00:31 -0700 Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvjVAZT9HxBhIK9REGhycMLEpaKIQ== Message-ID: In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3010499AA@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:59:13 -0000 Multihoming is not the primary requirement for an IGP from the herbst draft, though, it is different framing typed mac/phy's. The requirement for a IGP is that there is a need for intra-home routing between 802.3 framed networks and 802.15.4 in-home networks. There are two likely scenarios - 1) God box - Internet 802.3 (WAN) connection, 802.11 interior connection, 802.3 interior connection(s) and a 802.15.4 connection Or=20 2) multiple boxes - one from retail or SP with Internet 802.3 (WAN) connection, 802.11 interior connection, 802.3 interior connection(s) And a second with 802.3 and 802.15.4 With number 2, to enable Internet connectivity to the 802.15.4 network and general connectivity between the 802.11/802.3 networks and the 802.15.4 network, an IGP is required. tom On 3/15/11 1:47 PM, "Hemant Singh (shemant)" wrote: > > >-----Original Message----- >From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >Of james woodyatt >Sent: Tuesday, March 15, 2011 4:38 PM >To: IPv6 Ops WG >Subject: Re: [v6ops] I-D >Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > > >>Huh? Where is the draft that documents this? > >http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 > >Snipped from the Abstract of the document above, is this text between >squared brackets. > >[WiFi access points, cable boxes and other home devices with internet >access could all be internetworked with smart metering devices by >customers with no data networking expertise resulting in a complex >multi-segment network with differing prefixes, routing support and >service discovery needs.] > >I am sure there is other text in the document that points out two >different routers in the home connected to two different SPs (one SP is >the home's DSL or broadband SP and the other SP is the Power Grid >company with their IPv6 CE router for the home) and thus one has a >multihomed home. Anyway, you should look at Tom Herbst's prezo given to >the v6ops at the IETF79 in Beijing that clearly shows a multihomed >network. Note also that multihomed involves both a multihomed WAN and >LAN for CE Router. > >Hemant >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Tue Mar 15 13:59:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039923A6ECA for ; Tue, 15 Mar 2011 13:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPIxAumjDf4G for ; Tue, 15 Mar 2011 13:59:37 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id AD90F3A6B44 for ; Tue, 15 Mar 2011 13:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2826; q=dns/txt; s=iport; t=1300222863; x=1301432463; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=1TVkgCAJz7AHL4GvkKUqQv+4FC7u7o4OOsBEn0tq5y8=; b=goG5p3JssQ19ctHTcFcD1x43BVWQPjuIfCbIgWeBlaz6pVHVO862c1vF CBDN132W0duj/tuOWm6HKBtSTvCCNrjg4Yv826kHdv7Ay8vN6IhHPoOJY oRNw02nI2AR4bBswNIbHijYOgZD9cLo2+vXpB7akU+H9mefZNkJ6yGIah Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUBAPNvf02tJV2d/2dsb2JhbACYT40+d6R/nH2FYgSFMIsC X-IronPort-AV: E=Sophos;i="4.63,190,1299456000"; d="scan'208";a="225928108" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2011 21:01:02 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2FL12bH013000; Tue, 15 Mar 2011 21:01:02 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 16:01:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2011 16:01:01 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3010499C9@XMB-RCD-109.cisco.com> In-Reply-To: <000a01cbe353$5e325a20$1a970e60$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvjUPgF4bdZzDciQU6+FzmuDY0wHAAAE+2gAABjBhAAAEEHIA== References: <20110305184502.18531.25548.idtracker@localhost><76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com><4D7E685A.80202@bogus.com><5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3010499AA@XMB-RCD-109.cisco.com> <000a01cbe353$5e325a20$1a970e60$@sturek@att.net> From: "Hemant Singh (shemant)" To: , "james woodyatt" , "IPv6 Ops WG" X-OriginalArrivalTime: 15 Mar 2011 21:01:02.0930 (UTC) FILETIME=[17FB6320:01CBE354] Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 20:59:39 -0000 Don, Good to hear from you. I am also attending the IETF in Prague. I'd be happy to sit down with you guys again (like we did in Beijing) and work out the issues.=20 Hemant -----Original Message----- From: Don Sturek [mailto:d.sturek@att.net]=20 Sent: Tuesday, March 15, 2011 4:56 PM To: Hemant Singh (shemant); 'james woodyatt'; 'IPv6 Ops WG' Subject: RE: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Hi Hermant, Both Tom Herbst and myself (Don Sturek, representing Pacific Gas and Electric) will be in Prague and would like to discuss further the CPE Enhancements draft and the requirements around internetworked CPE within a home. As outlined in the http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 draft, activities are underway to deploy IPv6 enabled smart meters as well as support in WiFi and HomePlug to internetwork these smart meters with existing home networks connected to existing ISPs. The scenarios described in the draft are a little more than a year from large scale deployment (11 million smart meters installed to date) Don -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Tuesday, March 15, 2011 1:48 PM To: james woodyatt; IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Tuesday, March 15, 2011 4:38 PM To: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >Huh? Where is the draft that documents this? http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 Snipped from the Abstract of the document above, is this text between squared brackets. [WiFi access points, cable boxes and other home devices with internet access could all be internetworked with smart metering devices by customers with no data networking expertise resulting in a complex multi-segment network with differing prefixes, routing support and service discovery needs.] I am sure there is other text in the document that points out two different routers in the home connected to two different SPs (one SP is the home's DSL or broadband SP and the other SP is the Power Grid company with their IPv6 CE router for the home) and thus one has a multihomed home. Anyway, you should look at Tom Herbst's prezo given to the v6ops at the IETF79 in Beijing that clearly shows a multihomed network. Note also that multihomed involves both a multihomed WAN and LAN for CE Router. Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Tue Mar 15 14:07:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DB73A6808 for ; Tue, 15 Mar 2011 14:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Smi6A3FVgtxk for ; Tue, 15 Mar 2011 14:07:09 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id BBC803A6B58 for ; Tue, 15 Mar 2011 14:07:08 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 876AC9E; Tue, 15 Mar 2011 22:08:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 824319A; Tue, 15 Mar 2011 22:08:32 +0100 (CET) Date: Tue, 15 Mar 2011 22:08:32 +0100 (CET) From: Mikael Abrahamsson To: "Hemant Singh (shemant)" In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3010499C3@XMB-RCD-109.cisco.com> Message-ID: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049957@XMB-RCD-109.cisco.com> <0EDD6F66-D326-4656-B767-48C9B73989A3@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C30104998F@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3010499C3@XMB-RCD-109.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 21:07:11 -0000 On Tue, 15 Mar 2011, Hemant Singh (shemant) wrote: >> Or is this where the IGP comes in, that each router in the home should >> create a ULA for each LAN interface and announce this to its upstream >> interface (not to the SP, but to the CPE router) ? > > Yes. However, if the routed topology of the home in a tree topology and > the routers are thus using recursive prefix delegation, then no IGP is > needed to propagate a downstream PD subnet prefix to the upstream > router(s). The reason is because the upstream router snoops dhcpv6 > messages during prefix delegation and thus the router knows what prefix > subnet is assigned downstream. Soon as the home network is NOT a tree > routed topology, an IGP is needed to propagate subnet prefix routes > upstream. How does the CE router know what ULA the home IR has on it's LAN interface? Or is the intention do to PD both for the SP prefix and the ULA prefix from the CE, so any home IR always ask for multiple prefixes using PD, or can the CE PD multiple prefixes at once and the proposed design is that it should? -- Mikael Abrahamsson email: swmike@swm.pp.se From d.sturek@att.net Tue Mar 15 14:19:02 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C880F3A6B44 for ; Tue, 15 Mar 2011 14:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT+qRFUdjwTh for ; Tue, 15 Mar 2011 14:19:01 -0700 (PDT) Received: from nm2-vm0.bullet.mail.bf1.yahoo.com (nm2-vm0.bullet.mail.bf1.yahoo.com [98.139.213.127]) by core3.amsl.com (Postfix) with SMTP id 904413A6B1F for ; Tue, 15 Mar 2011 14:19:01 -0700 (PDT) Received: from [98.139.212.153] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 15 Mar 2011 21:20:24 -0000 Received: from [98.139.212.212] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 15 Mar 2011 21:20:24 -0000 Received: from [127.0.0.1] by omp1021.mail.bf1.yahoo.com with NNFMP; 15 Mar 2011 21:20:24 -0000 X-Yahoo-Newman-Id: 266306.55251.bm@omp1021.mail.bf1.yahoo.com Received: (qmail 30433 invoked from network); 15 Mar 2011 21:20:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1300224024; bh=HSW33NFT72QgO+QvduSHXRHW8ga/KCmrC99MZM9Pjk8=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=ImDE5SyJleDDkVNSPF27k2WzIgpL5br4sZEecNiihbi8UZf3pU4pefifwwZaifkl4DGd3riwGjHUoEZBrq+Q1nI+k4XDYaIVmp2AyzR56U3zuA8rGotjVJCHa5gsE2hCSgS1MJmHGPj0gFrg+8JatM6NYGEady0/uuctbQcov7o= Received: from Studio (d.sturek@174.78.56.227 with login) by smtp110.sbc.mail.bf1.yahoo.com with SMTP; 15 Mar 2011 14:20:23 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 9CO0a28VM1kwhFLv4fwB0_KoKczLAFtDzz25D3YrdrZTbE0 qHVBVK2myYtyCfMCodGSpjRsMINMKsJ8JX3I8MUeZaLSC4UAGXa0or58Rnnj HPL2v5w0tKBFegrZeB3Od3x1cnfnWL13u4phMGBroyj0NtRB1XJUekZMFd5d UYBPBa6oqSSPhI1vgYIEF9iVrzJPr8k.96.TQkO6NYnHP1kh6AWPg7469COy R5KRmi.pbYjO9mHg80HqBSFjNXxYx.j3v5aC8gRPF5Gutqu16gTTj7njO9e2 Gpd2gu5lDJ53Q1vfW X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Hemant Singh \(shemant\)'" , "'james woodyatt'" , "'IPv6 Ops WG'" References: <20110305184502.18531.25548.idtracker@localhost><76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com><4D7E685A.80202@bogus.com><5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3010499AA@XMB-RCD-109.cisco.com> <000a01cbe353$5e325a20$1a970e60$@sturek@att.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3010499C9@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3010499C9@XMB-RCD-109.cisco.com> Date: Tue, 15 Mar 2011 14:20:19 -0700 Message-ID: <002001cbe356$ca9e3690$5fdaa3b0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjUPgF4bdZzDciQU6+FzmuDY0wHAAAE+2gAABjBhAAAEEHIAAARHwA Content-Language: en-us Cc: "'Simpson, Robby \(GE Energy Services\)'" Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 21:19:02 -0000 Hi Hemant, Yes, let's find some time for sure. We have a draft proposal to discuss with Stuart Cheshire on extending m-DNS for site local multicasts (http://datatracker.ietf.org/doc/draft-lynn-dnsext-site-mdns/) plus we are working on a white paper covering the following topics (note the white paper is for discussion and portions may make sense for incorporation into the advanced CPE requirements draft): 1) White paper to address allocation of ULA prefixes, ULA address autoconfiguration and DAD, rules on limiting propagation of ULA prefixes beyond residence boundaries a. Define location where the ULA prefix is generated (default values if we can agree to them also) b. Define mechanism to distribute ULA prefixes c. Define mechanism to create unique ULA addresses from prefix (or more likely point to other drafts which do this like Autoconf) d. Define mechanism to stop propagation of ULA prefixes (which is probably the start of a much more complex problem) e. Propose either delegation (and realignment/DAD of updated ULA addresses) or a proxy and proxy agent to interconnect different ULA domains in a residence 3) White paper to define how an LBR (6LoWPAN border router) gets it global prefix to use (from the prefix space of the subscriber network). a. Probably use DHCP on the LBR to allocate the prefix from the subscriber network. As soon as our schedule is known, I will drop you a note and see if we can get together for 1-2 hours to discuss. Don -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, March 15, 2011 2:01 PM To: d.sturek@att.net; james woodyatt; IPv6 Ops WG Subject: RE: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Don, Good to hear from you. I am also attending the IETF in Prague. I'd be happy to sit down with you guys again (like we did in Beijing) and work out the issues. Hemant -----Original Message----- From: Don Sturek [mailto:d.sturek@att.net] Sent: Tuesday, March 15, 2011 4:56 PM To: Hemant Singh (shemant); 'james woodyatt'; 'IPv6 Ops WG' Subject: RE: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Hi Hermant, Both Tom Herbst and myself (Don Sturek, representing Pacific Gas and Electric) will be in Prague and would like to discuss further the CPE Enhancements draft and the requirements around internetworked CPE within a home. As outlined in the http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 draft, activities are underway to deploy IPv6 enabled smart meters as well as support in WiFi and HomePlug to internetwork these smart meters with existing home networks connected to existing ISPs. The scenarios described in the draft are a little more than a year from large scale deployment (11 million smart meters installed to date) Don -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Tuesday, March 15, 2011 1:48 PM To: james woodyatt; IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Tuesday, March 15, 2011 4:38 PM To: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >Huh? Where is the draft that documents this? http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 Snipped from the Abstract of the document above, is this text between squared brackets. [WiFi access points, cable boxes and other home devices with internet access could all be internetworked with smart metering devices by customers with no data networking expertise resulting in a complex multi-segment network with differing prefixes, routing support and service discovery needs.] I am sure there is other text in the document that points out two different routers in the home connected to two different SPs (one SP is the home's DSL or broadband SP and the other SP is the Power Grid company with their IPv6 CE router for the home) and thus one has a multihomed home. Anyway, you should look at Tom Herbst's prezo given to the v6ops at the IETF79 in Beijing that clearly shows a multihomed network. Note also that multihomed involves both a multihomed WAN and LAN for CE Router. Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Tue Mar 15 14:39:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7347C3A6EE0 for ; Tue, 15 Mar 2011 14:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnV1AVosFWhg for ; Tue, 15 Mar 2011 14:39:11 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 718403A6ED6 for ; Tue, 15 Mar 2011 14:39:10 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 58E9D9C; Tue, 15 Mar 2011 22:40:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4D8709A; Tue, 15 Mar 2011 22:40:35 +0100 (CET) Date: Tue, 15 Mar 2011 22:40:35 +0100 (CET) From: Mikael Abrahamsson To: "Hemant Singh (shemant)" In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3010499C3@XMB-RCD-109.cisco.com> Message-ID: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049957@XMB-RCD-109.cisco.com> <0EDD6F66-D326-4656-B767-48C9B73989A3@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C30104998F@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3010499C3@XMB-RCD-109.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 21:39:12 -0000 On Tue, 15 Mar 2011, Hemant Singh (shemant) wrote: > subnet is assigned downstream. Soon as the home network is NOT a tree > routed topology, an IGP is needed to propagate subnet prefix routes > upstream. Btw, since users will have to send out traffic to the respective SP only from the prefixes that SP has delegated, I guess we not only need an IGP, but some kind of policy routing (source based) so that packets going from hosts to the Internet end up on the correct SP? -- Mikael Abrahamsson email: swmike@swm.pp.se From dr@cluenet.de Tue Mar 15 14:52:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6F73A6E9A for ; Tue, 15 Mar 2011 14:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVsOLhfhQMSi for ; Tue, 15 Mar 2011 14:52:14 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by core3.amsl.com (Postfix) with ESMTP id 1F9A13A6BAC for ; Tue, 15 Mar 2011 14:52:14 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id D528510808C; Tue, 15 Mar 2011 22:53:38 +0100 (CET) Date: Tue, 15 Mar 2011 22:53:38 +0100 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110315215338.GA789@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <5B6B2B64C9FE2A489045EEEADDAFF2C3010499AA@XMB-RCD-109.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 21:52:16 -0000 On Tue, Mar 15, 2011 at 02:00:31PM -0700, Thomas Herbst wrote: > 2) multiple boxes - one from retail or SP with Internet 802.3 (WAN) > connection, 802.11 interior connection, 802.3 interior connection(s) > And a second with 802.3 and 802.15.4 > > With number 2, to enable Internet connectivity to the 802.15.4 network and > general connectivity between the 802.11/802.3 networks and the 802.15.4 > network, an IGP is required. I don't see that - as long as the 802.15.4 device acts as a router, requesting required IP space for the 802.15.4 domain via DHCPv6-PD from the home internet gateway router. Why is a full-blown dynamic IGP needed? How does the 802.15.4 gateway discover what address range it could advertise in IGP for own use? Do we really want IGP-enabled residential home LANs, where every device plugged in to can advertise arbitrary routes? As a home network "operator" and SP I seriously frown upon this scenario having random smart meter devices inject random routing information into my home network. What exactly is the scenario which requires non-hierarchical controlled routing that a DHCPv6-PD cascade would be able to provide? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From d.sturek@att.net Tue Mar 15 14:53:11 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4008B3A6E9A for ; Tue, 15 Mar 2011 14:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shy0PjBA4DQv for ; Tue, 15 Mar 2011 14:53:10 -0700 (PDT) Received: from nm1.bullet.mail.sp2.yahoo.com (nm1.bullet.mail.sp2.yahoo.com [98.139.91.71]) by core3.amsl.com (Postfix) with SMTP id 4D4533A6826 for ; Tue, 15 Mar 2011 14:53:10 -0700 (PDT) Received: from [98.139.91.66] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 15 Mar 2011 21:54:33 -0000 Received: from [98.139.91.49] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 15 Mar 2011 21:54:33 -0000 Received: from [127.0.0.1] by omp1049.mail.sp2.yahoo.com with NNFMP; 15 Mar 2011 21:54:33 -0000 X-Yahoo-Newman-Id: 492746.44431.bm@omp1049.mail.sp2.yahoo.com Received: (qmail 25946 invoked from network); 15 Mar 2011 21:54:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1300226072; bh=GURou1snlzzHBqLxFXkqylB+FzbjWIGIk2Qy71kThJ8=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=wgcIqHqYZFlm5dUWBVjUbhX2qeKQcWC685lmobIV8RlG6PVrQFc9N0sjEVW0JXkvN5/y36vZE6EUl+Ga5unhOcPJHTEmgGZvhwTdxSB9Ce7QVFSpQOw6ixqdS0m0+GrUgG4QLIcJg0JjSPPnijlyTffvcfqgwHMsFgy3qpJ91r8= Received: from Studio (d.sturek@174.78.56.227 with login) by smtp105.sbc.mail.gq1.yahoo.com with SMTP; 15 Mar 2011 14:54:32 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: vMHg76sVM1lfkrduXOnF0QZwWpgJLxr.dZXowqTrOz9q5lU Ml5xpfql_KwjA4cGkBEUpOIqAYF.X2hWZuTQMXG0T1zcB50gCSJL_MQNhdy0 lNjre8NU96x3iVD_4uQAPC1gOw.A0pVWUBicP5Ts8j9sg8ae6_X4GpOi4Wwl k7kUkljtcDgIo7xOFexkuZUXzFtUQpukhkCscY85NIUxW26AjukBmVtNllAa _RS9OMv.4rxo3v4vZd._DcddYIdPp8DFHQPdw5BvrQP45j0vcEiQfjvumjPR 0t5qWyosY4RiNtSPsiFo.AcA.lOxg2f3TtF6kcU8rVJ0IqyyAVrqbrQgQQ0p vDgcmpvs- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'George Michaelson'" References: <20110305184502.18531.25548.idtracker@localhost><76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com><4D7E685A.80202@bogus.com><5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3010499AA@XMB-RCD-109.cisco.com> <000a01cbe353$5e325a20$1a970e60$@sturek@att.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3010499C9@XMB-RCD-109.cisco.com> <002001cbe356$ca9e3690$5fdaa3b0$@sturek@att.net> <5B44B908-0652-4659-B841-F91A2EF97968@apnic.net> In-Reply-To: <5B44B908-0652-4659-B841-F91A2EF97968@apnic.net> Date: Tue, 15 Mar 2011 14:54:26 -0700 Message-ID: <004001cbe35b$8ff442f0$afdcc8d0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjWIuqdpOkYMMkQeuIs1hClsMySwAAsEJw Content-Language: en-us Cc: 'IPv6 Ops WG' , "'Simpson, Robby \(GE Energy Services\)'" Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 21:53:11 -0000 Hi George, We also meant to address the propagation of site local multicasts beyond residence boundaries as well. That said, I will be sure to attend your presentation as we don't really care how the problem is addressed (so long as our site local multicasts don't end up outside the residence!)....... Don -----Original Message----- From: George Michaelson [mailto:ggm@apnic.net] Sent: Tuesday, March 15, 2011 2:33 PM To: d.sturek@att.net Cc: Hemant Singh (shemant); james woodyatt; IPv6 Ops WG; Simpson, Robby (GE Energy Services); Geoff Huston Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt On 15/03/2011, at 2:20 PM, Don Sturek wrote: > > d. Define mechanism to stop propagation of ULA prefixes (which is > probably the start of a much more complex problem) As a point of information on this Don, Have a look at: http://tools.ietf.org/html/draft-michaelson-as112-ipv6-00 Which I will be presenting on in Prague/DNSOPS I hope. A *significant* daily volume of reverse-DNS is seen into ULA space. It far outweighs global unicast IPv6 requests on the ip6.arpa service. The query sources are widespread. This strongly suggests that a ULA deployment is out there in the wild, causing some kind of service to request 'who is that' into un-delegated reverse space. I understand you meant routing propagation, but I thought I'd point out there are other kinds of information leak about 'local' addresses Oh, and the multicast ranges are in there too. Link and Site scoped boundaries, the works. -George= From brian.e.carpenter@gmail.com Tue Mar 15 15:07:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651713A6E06 for ; Tue, 15 Mar 2011 15:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.451 X-Spam-Level: X-Spam-Status: No, score=-103.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xSAK6ka3Y9x for ; Tue, 15 Mar 2011 15:07:38 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 1924D3A6A40 for ; Tue, 15 Mar 2011 15:07:27 -0700 (PDT) Received: by fxm15 with SMTP id 15so1144813fxm.31 for ; Tue, 15 Mar 2011 15:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qG8WQFDDlYHqMOtCRml8l9mHAW9Yy+eTvcUdolEaErQ=; b=vOM+iPU72mYM/no/H2B8PJp0VIPwotANQdJCz5Q4fAAe6AMF3yvQnpeL15lfNcZLf9 qizQltRvPZCxcpfZK7r1Xeg2GP9Td047BFguROjBKWoLUx6dhYH0dkgNetLOfR2tCc4T 2IhBC99nKOdNA99QCFwUneaZSLe0DNGVw7DNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=e4laNqJBRJ7vYhQaXxguRhDr4pVoK67ULsmaOQUySOsqzJ/KWKdHRJbythWI1hzboq NJSkYq8wLrCDwucK1Po2Zt7SH7dW7ep4ImXwZLtjYoKiupp8bADU5jCohE0233cM+ra6 WMm2yc1TalrdWvCPxxZfZ1WAFV2wXdQduEQN8= Received: by 10.223.86.200 with SMTP id t8mr68629fal.26.1300226885110; Tue, 15 Mar 2011 15:08:05 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id n3sm156770faa.29.2011.03.15.15.08.01 (version=SSLv3 cipher=OTHER); Tue, 15 Mar 2011 15:08:04 -0700 (PDT) Message-ID: <4D7FE338.6040608@gmail.com> Date: Wed, 16 Mar 2011 11:07:52 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mikael Abrahamsson References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049957@XMB-RCD-109.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 22:07:39 -0000 On 2011-03-16 09:20, Mikael Abrahamsson wrote: > On Tue, 15 Mar 2011, Hemant Singh (shemant) wrote: > >>> So for a device to support this setup, IGP is a MUST. I do though see >>> a lot of trouble to get this kind of setup to work automatically, how >>> do you get DNS to work for instance? >> >> How does DNS work today in an Enterprise across two routed domains with >> different subnet prefixes? One way is to have both domains go to one >> root DNS server for the domains. > > I guess I wasn't clear. Let me try to be more specific: > > How would the printer automatically be discovered in the home, or at > least how would a DNS name pointing AAAA to the printers IPv6 address be > entered into a domain name the user can enter, that would dynamically > change as the PD prefixes change over time? Isn't that exactly what dynamic DNS update is for? As I said, we need to decide whether real DNS + dynamic update is recommended, or mDNS. If not, you do indeed need routed multicast for discovery. Do we really want to go there? Brian From brian.e.carpenter@gmail.com Tue Mar 15 15:09:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7733A6CAC for ; Tue, 15 Mar 2011 15:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.453 X-Spam-Level: X-Spam-Status: No, score=-103.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cbq0i-z1jp+t for ; Tue, 15 Mar 2011 15:09:15 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id A7D7F3A6B30 for ; Tue, 15 Mar 2011 15:09:14 -0700 (PDT) Received: by fxm15 with SMTP id 15so1146262fxm.31 for ; Tue, 15 Mar 2011 15:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=42mjRahLl+/HYKGjrvWDcFQ/QM0xRXIktjKWoKwaXfI=; b=au9QMUq5HfPro6thz4i0kLZFl0P4fHqbJfviS5vB5WhpI6wsowScyNIqwhbtJl3fu/ dzDKaqvuFjKyMH0Y6wHZI3e6w/2efpSXT8r8X2oQCgYBWGQVExvdDP9fLcSzFkDzw8uh cVJMfjvTZ1xFm1MFIi/KcS934WFDmJdkA9sRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=pZW2bUEvNqQublWAkp9OBF4XSUcyzqo4ZbwEdkWNLLI4aPgbhtBrqSb7G0A/pk4x9u 0xxBtpiD+XvOVkVGG9KpDQln2EMNucxSyJXERIuY0knlp9x6vBoyAbyRsznoqPbcvDXP pTI5S5I1+VN4eWMz958ljE5hB683IVHHv+/bc= Received: by 10.223.95.138 with SMTP id d10mr72641fan.21.1300227034469; Tue, 15 Mar 2011 15:10:34 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id j11sm154484faa.44.2011.03.15.15.10.31 (version=SSLv3 cipher=OTHER); Tue, 15 Mar 2011 15:10:33 -0700 (PDT) Message-ID: <4D7FE3D3.3010003@gmail.com> Date: Wed, 16 Mar 2011 11:10:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sthaug@nethelp.no References: <20110315.212814.74695734.sthaug@nethelp.no> In-Reply-To: <20110315.212814.74695734.sthaug@nethelp.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 22:09:15 -0000 On 2011-03-16 09:28, sthaug@nethelp.no wrote: >>>> Bridging the LAN and WAN sides is a heresy, of course, and the sooner CPEs >>>> stop doing it, the better. >>> I don't see any reason for such a device to be handled in this draft, >>> anyway. It's a cpe *router* draft, if it does L2 bridging between LAN and >>> WAN then it's not a router, it's a media converter or a switch. >> And will not work properly for IPv6, which intrinsically requires a >> router. I think >> this should be stated somehow, in a few words. > > I don't see *why* IPv6 wouldn't work for instance behind a plain bridge > type DSL modem. But if that is indeed the case, it needs to be explained. If you get a /56 you really need to be a router, surely. Brian > > Agreed that such a device is not relevant for a CPE router document. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > From brian.e.carpenter@gmail.com Tue Mar 15 15:10:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128FA3A6E06 for ; Tue, 15 Mar 2011 15:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.455 X-Spam-Level: X-Spam-Status: No, score=-103.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdKVkoxwn7E9 for ; Tue, 15 Mar 2011 15:10:35 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 21C763A6B30 for ; Tue, 15 Mar 2011 15:10:32 -0700 (PDT) Received: by wyb42 with SMTP id 42so1144683wyb.31 for ; Tue, 15 Mar 2011 15:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OAI9yh8pC/75FkYJa4BJQFyrc5i1EApF+DiF2lP/au8=; b=oUqhwABwKqQ5HLZNpwkCEUirQSs5nA5KA+7FHzjLkQAMKTqI9P0A9sRpi47y9fp/EE bjjmprtQmIkn3IHnCR78rJogEYoLd5YR5Rd0mn00csAXGUAoRNSz79z6pqad4blkwLTr /OH2IinYwb3UKFCmpp5d2pH9K1oOc4YhQAjSs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=vQPYxHlOQcZzv6t0789S8sPCK1ewyWar81MYnxobN9U0evDiuqP212TYcw3AHG+A5c H5jtHAmv7CP/GnAMbIAlT+RDtoJQ6AaPKWlIr1HEdX+Od3XaqCZ6I1ta72Ssif5SLeeO WYZR0CcdZwUhmbLYEDz4VMnxBqYDWYdR8/6Lk= Received: by 10.216.181.199 with SMTP id l49mr4051572wem.68.1300227118102; Tue, 15 Mar 2011 15:11:58 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id n4sm176807wee.28.2011.03.15.15.11.55 (version=SSLv3 cipher=OTHER); Tue, 15 Mar 2011 15:11:57 -0700 (PDT) Message-ID: <4D7FE427.7000201@gmail.com> Date: Wed, 16 Mar 2011 11:11:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 22:10:36 -0000 On 2011-03-16 08:59, Hemant Singh (shemant) wrote: > > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Tuesday, March 15, 2011 3:19 PM > To: Hemant Singh (shemant) > Cc: Joel Jaeggli; james woodyatt; IPv6 Ops WG > Subject: Re: [v6ops] I-D > Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > > >> Doesn't this work for multihoming as well, we can have multiple > prefixes >> on the same LAN and the Customer Interior Router can get multiple PDs > from >> the different spaces? > > How does my home computer addressed with the SP1 IPv6 global address > from PD1 print to the printer addresses with the SP2 IPv6 global address > from PD2 unless the PD2 subnet prefix is propagated by some means > between the two network domains? An IGP is needed or one could use MSR > (RFC 4191) in some cases of the home network. > >> Also when reading draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt I see no >> mention of multihoming, would this be done with two connections to one >> device, or two devices? > > You are correct. The current version does not support multihoming. > However multihoming is one feature that is under consideration to add to > the document. One use case we have in mind is a home served by two > different SP's using two different IPv6 CE routers with one WAN > interface on each device. Why does that change the requirements for an IPv6 router? It's 100% standard IPv6 deployment. Brian From jhw@apple.com Tue Mar 15 15:24:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B553A6A4B for ; Tue, 15 Mar 2011 15:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.256 X-Spam-Level: X-Spam-Status: No, score=-106.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aeVVE34qULz for ; Tue, 15 Mar 2011 15:24:52 -0700 (PDT) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 636853A6930 for ; Tue, 15 Mar 2011 15:24:52 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 11182D702D6B for ; Tue, 15 Mar 2011 15:26:18 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-0a-4d7fe78982e9 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay13.apple.com (Apple SCV relay) with SMTP id 05.E4.29082.987EF7D4; Tue, 15 Mar 2011 15:26:17 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.13.64] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI400KVFEBTC240@et.apple.com> for v6ops@ietf.org; Tue, 15 Mar 2011 15:26:17 -0700 (PDT) From: james woodyatt In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C3010499AA@XMB-RCD-109.cisco.com> Date: Tue, 15 Mar 2011 15:26:17 -0700 Message-id: <66E3C063-3C70-4B14-8417-9DD5CEFA6816@apple.com> References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3010499AA@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 22:24:53 -0000 On Mar 15, 2011, at 13:47 , Hemant Singh (shemant) wrote: > [I boggled at the claim:] >> On Mar 15, 2011, at 11:56 , Hemant Singh (shemant) wrote: >>> >>> The power grid folks already came to the Beijing IETF showing us their cpe router devices will force the home to be multihomed. >> >> Huh? Where is the draft that documents this? > > http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 I read that draft when it was first published. It documents no such thing. > I am sure there is other text in the document that points out two > different routers in the home connected to two different SPs (one SP is > the home's DSL or broadband SP and the other SP is the Power Grid > company with their IPv6 CE router for the home) and thus one has a > multihomed home. Anyway, you should look at Tom Herbst's prezo given to > the v6ops at the IETF79 in Beijing that clearly shows a multihomed > network. Note also that multihomed involves both a multihomed WAN and > LAN for CE Router. There is no language in the draft respecting site-multihoming of residential networks. There is the somewhat ambiguous section 2.3 "Intra-network routing with multiple internet connected CPEs" which says this: As network segments are interconnected, and CPE devices become border gateways for new bordering network segments, a routing protocol like RIPng needs to be supported. As noted for ULA delegation, the CPE needs to automatically detect the need in support for inter-segment routing and provide support automatically. Admittedly, this could be interpreted to mean multi-homing at residential sites. Maybe there was a presentation slide set in Beijing that explained clearly what this section is supposed to mean, but if so then I missed it. Was there such a presentation? My abiding and overarching question, which I have been asking for more than a year now without satisfactory answer, remains unanswered: what is forcing this to happen, and why are other obvious alternatives unsatisfactory? -- james woodyatt member of technical staff, core os networking From jhw@apple.com Tue Mar 15 15:34:39 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 826B03A6B44 for ; Tue, 15 Mar 2011 15:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkhRLFh7L5mc for ; Tue, 15 Mar 2011 15:34:38 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 953323A6A4B for ; Tue, 15 Mar 2011 15:34:38 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 77D63D703421 for ; Tue, 15 Mar 2011 15:36:04 -0700 (PDT) X-AuditID: 11807130-b7b5eae000005ccb-64-4d7fe9d4b260 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay11.apple.com (Apple SCV relay) with SMTP id 46.D7.23755.4D9EF7D4; Tue, 15 Mar 2011 15:36:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.13.64] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI400GXMES4QE20@gertie.apple.com> for v6ops@ietf.org; Tue, 15 Mar 2011 15:36:04 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 15 Mar 2011 15:36:03 -0700 Message-id: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> References: To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 22:34:39 -0000 On Mar 15, 2011, at 14:00 , Thomas Herbst wrote: > > The requirement for a IGP is that there is a need for intra-home routing > between 802.3 framed networks and 802.15.4 in-home networks. > > There are two likely scenarios - > 1) God box - Internet 802.3 (WAN) connection, 802.11 interior connection, > 802.3 interior connection(s) and a 802.15.4 connection > > Or > > 2) multiple boxes - one from retail or SP with Internet 802.3 (WAN) > connection, 802.11 interior connection, 802.3 interior connection(s) > And a second with 802.3 and 802.15.4 > > With number 2, to enable Internet connectivity to the 802.15.4 network and > general connectivity between the 802.11/802.3 networks and the 802.15.4 > network, an IGP is required. Would somebody please explain in clear technical detail why the obvious alternative, i.e. ND-proxy at the bastion between 802.1D and 802.15.4, is an unsatisfactory solution to the problem of not being able to bridge between 802.1D and 802.15.4? A related question is why an application proxy, which has the virtue of working when the residential Internet service provider is IPv4-only, is also an unsatisfactory solution to the Internet connectivity problems of the 802.15.4 engineering community? -- james woodyatt member of technical staff, core os networking From shemant@cisco.com Tue Mar 15 15:36:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CEB63A6B44 for ; Tue, 15 Mar 2011 15:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.819 X-Spam-Level: X-Spam-Status: No, score=-10.819 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHIv-TdIgzji for ; Tue, 15 Mar 2011 15:36:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 035D73A6A4B for ; Tue, 15 Mar 2011 15:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1008; q=dns/txt; s=iport; t=1300228652; x=1301438252; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=R2vjeSqf2gEZFU98QccCNYAS/B6KRDGwkwYCJLWEQD8=; b=DfOi1YF5JGCnEUWaK/kFl8q8iyGnN2hXBD7z017Cx/8ju/zPPHanLE5c FJYQTg/rKP6ewnBRRayvbePxJNaHpLSzrsHkQ74wkzB7tcdjkM+lK/fz1 tvvVkvtYINZZTLjeXx0pyx6fBzkn+DQwy0OS0LhOXe0KrUnC1DuKuKBT/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUBAK+Gf02tJV2Y/2dsb2JhbACYT40+d6RcnG6FYgSFMIsC X-IronPort-AV: E=Sophos;i="4.63,191,1299456000"; d="scan'208";a="320684172" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2011 22:37:32 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2FMbWdq032249; Tue, 15 Mar 2011 22:37:32 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Mar 2011 17:37:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2011 17:37:30 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C301049A8B@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvjVSlUrsdXyb2aTGGF+LuDAVI2nwABNs8A References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049957@XMB-RCD-109.cisco.com> <0EDD6F66-D326-4656-B767-48C9B73989A3@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C30104998F@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3010499C3@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Mikael Abrahamsson" X-OriginalArrivalTime: 15 Mar 2011 22:37:32.0597 (UTC) FILETIME=[92E47650:01CBE361] Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 22:36:08 -0000 -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Tuesday, March 15, 2011 5:09 PM To: Hemant Singh (shemant) Cc: Ole Troan; IPv6 Ops WG Subject: RE: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >How does the CE router know what ULA the home IR has on it's LAN=20 >interface? When the CE router is powered up the CE router will generate a ULA prefix. Thereafter an internal DHCPv6 server inside the CPE router delegates the ULA prefix to the LAN interfaces. >Or is the intention do to PD both for the SP prefix and the ULA prefix=20 >from the CE, so any home IR always ask for multiple prefixes using PD, or=20 >can the CE PD multiple prefixes at once and the proposed design is that it=20 >should? The Basic IPv6 CE router document that covers the topic of ULA does not go into such details and does not need to. The PD acquisition can happen in any order for the ULA or the GUA (Globally Unique Address). =20 Hemant From d.sturek@att.net Tue Mar 15 15:50:08 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2853A6EFB for ; Tue, 15 Mar 2011 15:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4E4ibshO+UA for ; Tue, 15 Mar 2011 15:50:07 -0700 (PDT) Received: from nm28.bullet.mail.ne1.yahoo.com (nm28.bullet.mail.ne1.yahoo.com [98.138.90.91]) by core3.amsl.com (Postfix) with SMTP id A54B03A6EE0 for ; Tue, 15 Mar 2011 15:50:07 -0700 (PDT) Received: from [98.138.90.48] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 15 Mar 2011 22:51:33 -0000 Received: from [98.138.87.11] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 15 Mar 2011 22:51:33 -0000 Received: from [127.0.0.1] by omp1011.mail.ne1.yahoo.com with NNFMP; 15 Mar 2011 22:51:33 -0000 X-Yahoo-Newman-Id: 277663.51142.bm@omp1011.mail.ne1.yahoo.com Received: (qmail 81252 invoked from network); 15 Mar 2011 22:51:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1300229493; bh=x33yzQ83ExBnZ9miOCremcYL3ic9dprmG47opE265G8=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=m2whTipHmLaKqja9BkedosAxWcud2uugb8B5vBomJatDJPa0uOX7ymYUfycikVXLvsMkhvchoUiiHd/VUUekotpvcbQOjOVNwjmOc6x68SCBW7ferH/JzyRopDP8ty1xP3FxetqhVFSrvBwYpLh7/XrEW//XRnzQiqPrBFU7SV0= Received: from Studio (d.sturek@174.78.56.227 with login) by smtp102.sbc.mail.ne1.yahoo.com with SMTP; 15 Mar 2011 15:51:32 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: QCTwcfUVM1kb2aGBOVe0QriuXmETU4IEFGJSXUjn643DAUt 4Bg5gOzmhn4PcgXac0roMMpPX5B69Je_l7cIolbHJPV.O7LsKp4JdMYouvcr JV4Cp61_IHkLnMmgi9vMKDU6ZqPL3EgBgErTLE_X0z1sPniHsagjMyWcsVVy mnxc.iZB7Hp_HO0XUeTIUT2A96z0g9Fz7FnlLj4FJpZ4_miaLetVRuc5LGo_ s7Y7CcpyNwyGCZPN4KqX0jvTWAkd0FomXLaL1Ek073SlF2IT6A0FpykCJNgO KLGTE_Cvs2mjhjCXo84KhYuIQ74Cci5TuZjtpR0fELD.1zU8evOCGERA- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'james woodyatt'" , "'IPv6 Ops WG'" References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> In-Reply-To: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> Date: Tue, 15 Mar 2011 15:51:29 -0700 Message-ID: <006e01cbe363$867875e0$936961a0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjYV9G0IboEeTqSCO0W+57AcD0igAASImw Content-Language: en-us Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 22:50:08 -0000 Hi James, >From your question below, could you provide a bulletized list of what an "application proxy" between an IEEE 802.15.4 subnet and a residential ISP subnet would do? Here are my questions: 1) You mentioned ND-proxy already 2) DNS proxy? 3) DAD? 4) ULA prefix proxy? 5) Multicast propagation (or is this assumed to be not supported for site locals since you assumed DNS proxy?) 6) Other services Just trying to understand what all this proxy would be doing........ Don -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Tuesday, March 15, 2011 3:36 PM To: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt On Mar 15, 2011, at 14:00 , Thomas Herbst wrote: > > The requirement for a IGP is that there is a need for intra-home routing > between 802.3 framed networks and 802.15.4 in-home networks. > > There are two likely scenarios - > 1) God box - Internet 802.3 (WAN) connection, 802.11 interior connection, > 802.3 interior connection(s) and a 802.15.4 connection > > Or > > 2) multiple boxes - one from retail or SP with Internet 802.3 (WAN) > connection, 802.11 interior connection, 802.3 interior connection(s) > And a second with 802.3 and 802.15.4 > > With number 2, to enable Internet connectivity to the 802.15.4 network and > general connectivity between the 802.11/802.3 networks and the 802.15.4 > network, an IGP is required. Would somebody please explain in clear technical detail why the obvious alternative, i.e. ND-proxy at the bastion between 802.1D and 802.15.4, is an unsatisfactory solution to the problem of not being able to bridge between 802.1D and 802.15.4? A related question is why an application proxy, which has the virtue of working when the residential Internet service provider is IPv4-only, is also an unsatisfactory solution to the Internet connectivity problems of the 802.15.4 engineering community? -- james woodyatt member of technical staff, core os networking _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Tue Mar 15 17:17:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18AA93A6A55 for ; Tue, 15 Mar 2011 17:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.549 X-Spam-Level: X-Spam-Status: No, score=-104.549 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-1m6co--T4B for ; Tue, 15 Mar 2011 17:17:02 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by core3.amsl.com (Postfix) with ESMTP id 450653A6A4E for ; Tue, 15 Mar 2011 17:17:02 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LI400DC8JI4G210@localhost.apple.com> for v6ops@ietf.org; Tue, 15 Mar 2011 17:18:28 -0700 (PDT) X-AuditID: 11807137-b7c3cae0000010f5-2f-4d8001d4e28f Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay16.apple.com (Apple SCV relay) with SMTP id EE.AE.04341.4D1008D4; Tue, 15 Mar 2011 17:18:28 -0700 (PDT) Received: from [17.193.15.152] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI400G2TJIRQE60@gertie.apple.com> for v6ops@ietf.org; Tue, 15 Mar 2011 17:18:27 -0700 (PDT) From: james woodyatt In-reply-to: <006e01cbe363$867875e0$936961a0$%sturek@att.net> Date: Tue, 15 Mar 2011 17:18:27 -0700 Message-id: <11624E0A-C5C7-4AB8-A6DB-5534E48AB528@apple.com> References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> <006e01cbe363$867875e0$936961a0$%sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 00:17:03 -0000 On Mar 15, 2011, at 3:51 PM, Don Sturek wrote: > > Just trying to understand what all this proxy would be doing........ You have some smart meter device on your 802.15.4 network. There are two ways an application proxy can help solve your connectivity problem. + To make the smart meter device reachable from the IPv6 Internet: via service through an application proxy running on a host on the 802.1D network with another interface to the 802.15.4 network. It would make any registrations in service directories required by the smart meter on its behalf. It would receive connections from remote peers and forward them in application layer to the real smart meter devices on the 802.15.4 network. + To make services on the IPv6 public Internet reachable from the smart meter device: via an application proxy running on a host on the 802.15.4 network with another interface to the 802.1D network where a global IPv6 prefix is advertised. It would advertise a ULA prefix to the 802.15.4 network and no global prefix. It would answer service directory queries from smart meter devices with its own ULA address and proxy the remote Internet services to hosts on the 802.15.4 network. Remote servers at IPv4 addresses would be proxied over the application layer on IPv6. -- james woodyatt member of technical staff, core os networking From d.sturek@att.net Tue Mar 15 17:30:33 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F573A6C03 for ; Tue, 15 Mar 2011 17:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.807 X-Spam-Level: X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTYjxMIiSeG9 for ; Tue, 15 Mar 2011 17:30:32 -0700 (PDT) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) by core3.amsl.com (Postfix) with SMTP id 6FE5C3A6BA4 for ; Tue, 15 Mar 2011 17:30:32 -0700 (PDT) Received: from [98.139.212.151] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 16 Mar 2011 00:31:54 -0000 Received: from [98.139.212.234] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 16 Mar 2011 00:31:54 -0000 Received: from [127.0.0.1] by omp1043.mail.bf1.yahoo.com with NNFMP; 16 Mar 2011 00:31:54 -0000 X-Yahoo-Newman-Id: 449775.18786.bm@omp1043.mail.bf1.yahoo.com Received: (qmail 22982 invoked from network); 16 Mar 2011 00:31:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1300235514; bh=Ia8mPQKSdOYv6qOWtbmmnr9ZRzSGezr8toklo6HNLwE=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=jA9Mvhw0/BrmLzWKulH6iFQEuyvf71Jdhu1xSC+EWm4VT7zk55gFemOY0sbdc2Zzhw9IFt09EPcKHSIXvlL7PT455X1VrGRajrgsPlyI9htm9HvcOUIQtvUWEislj7CKrc5ATJPE7zVbx4jkj7JFBQAaTUfXwNkFBw7Yh0ag58M= Received: from Studio (d.sturek@69.105.136.148 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 15 Mar 2011 17:31:53 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: ziLgEoIVM1lsS5i0dafMXfwAM.YENb7uLed8pqOJ5ch1bTM 9uOxQ9xIVf9vlVoIWjCRCxPMGti8KpKXuaZNfMZ17wEHfdMhyb67Ggjuat5D NWJXd1QAb.GLaEaRWy.ERPmd_63BUn9t9yxjtTM4b5p9z32sOEkBiOLDOHgi QT73jN5NhUs3SbvKxBoCPJGcA1vil58ZQg6R8rbvhDvmyR2OY9S4C8qEcK4q Gwtx0pNNxO0gCP26mz_TzaaMqDfppwii.iGCPSWTtS8oZ110hmawTkyy2EpU V_DNwJVSb5DFTpk8p1rrSSiajbW6IrDdQcynOlHfKBRR_OJKP6tAYehDbSRR 8LGtWdfxR2i9L X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'james woodyatt'" References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> <006e01cbe363$867875e0$936961a0$%sturek@att.net> <11624E0A-C5C7-4AB8-A6DB-5534E48AB528@apple.com> In-Reply-To: <11624E0A-C5C7-4AB8-A6DB-5534E48AB528@apple.com> Date: Tue, 15 Mar 2011 17:31:41 -0700 Message-ID: <004c01cbe371$8b8219c0$a2864d40$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvjb6wxXFqgvk9zQRGjSvIHstNpiwAAYUpg Content-Language: en-us Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 00:30:33 -0000 Hi James, I don't see how the suggestions below would work in an environment where the customer can bring in new devices, associate them to the network and expect access to their smart meter from WiFi, HomePlug or other medium not directly attached to the smart meter (but internetworked through CPE). Wouldn't your suggestion entail a lot of configuration if any new home network interface is introduced? I think we should focus on solving the problems in the home without having to configure an application gateway for every new interface. Don -----Original Message----- From: james woodyatt [mailto:jhw@apple.com] Sent: Tuesday, March 15, 2011 5:18 PM To: d.sturek@att.net Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt On Mar 15, 2011, at 3:51 PM, Don Sturek wrote: > > Just trying to understand what all this proxy would be doing........ You have some smart meter device on your 802.15.4 network. There are two ways an application proxy can help solve your connectivity problem. + To make the smart meter device reachable from the IPv6 Internet: via service through an application proxy running on a host on the 802.1D network with another interface to the 802.15.4 network. It would make any registrations in service directories required by the smart meter on its behalf. It would receive connections from remote peers and forward them in application layer to the real smart meter devices on the 802.15.4 network. + To make services on the IPv6 public Internet reachable from the smart meter device: via an application proxy running on a host on the 802.15.4 network with another interface to the 802.1D network where a global IPv6 prefix is advertised. It would advertise a ULA prefix to the 802.15.4 network and no global prefix. It would answer service directory queries from smart meter devices with its own ULA address and proxy the remote Internet services to hosts on the 802.15.4 network. Remote servers at IPv4 addresses would be proxied over the application layer on IPv6. -- james woodyatt member of technical staff, core os networking From jhw@apple.com Tue Mar 15 17:31:19 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7079B3A6D2D for ; Tue, 15 Mar 2011 17:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.471 X-Spam-Level: X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fYGbHw7FMru for ; Tue, 15 Mar 2011 17:31:18 -0700 (PDT) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id A3FF13A6BA4 for ; Tue, 15 Mar 2011 17:31:18 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 8E9F7D9405CA for ; Tue, 15 Mar 2011 17:32:44 -0700 (PDT) X-AuditID: 11807130-b7b5eae000005ccb-33-4d80052cbe85 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay11.apple.com (Apple SCV relay) with SMTP id 2E.E2.23755.C25008D4; Tue, 15 Mar 2011 17:32:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.15.152] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI400EJ1K6K1Q40@elliott.apple.com> for v6ops@ietf.org; Tue, 15 Mar 2011 17:32:44 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 15 Mar 2011 17:32:43 -0700 Message-id: <491F9309-238E-4B2C-BFEB-E9BE4EF00C86@apple.com> References: To: Thomas Herbst X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 00:31:19 -0000 On Mar 15, 2011, at 5:18 PM, Thomas Herbst wrote: > > Does every 802.15.4 application level gateway now need to be upgraded for the "lightbulb app"? I don't know. Presumably, someone with deeper knowledge of applications for 802.15.4 networking can speak authoritatively about what requirements might arise for application proxies in this scenario. Is there anyone with enough authority here to tell us? > The problem we are trying to solve is to connect subnets of different mac/phys together. The way to do that is to layer 3 forwarding. Maybe if I recite the link to RFC 4389, I'll get some traction: Just to be really thorough, I'll quote the abstract too. Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. Seriously, why doesn't neighbor discovery proxy offer the optimal solution here? I understand that layer-3 forwarding can be made to solve this problem. What I don't understand is why we are discounting the operational advantages of neighbor discovery proxy. -- james woodyatt member of technical staff, core os networking From d.sturek@att.net Tue Mar 15 17:41:14 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E393A6F25 for ; Tue, 15 Mar 2011 17:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+A2f3VL3dtb for ; Tue, 15 Mar 2011 17:41:13 -0700 (PDT) Received: from nm15-vm0.bullet.mail.ne1.yahoo.com (nm15-vm0.bullet.mail.ne1.yahoo.com [98.138.91.70]) by core3.amsl.com (Postfix) with SMTP id 22FB73A6F1F for ; Tue, 15 Mar 2011 17:41:13 -0700 (PDT) Received: from [98.138.90.54] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 16 Mar 2011 00:42:33 -0000 Received: from [98.138.89.166] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 16 Mar 2011 00:42:33 -0000 Received: from [127.0.0.1] by omp1022.mail.ne1.yahoo.com with NNFMP; 16 Mar 2011 00:42:33 -0000 X-Yahoo-Newman-Id: 498585.55977.bm@omp1022.mail.ne1.yahoo.com Received: (qmail 60017 invoked from network); 16 Mar 2011 00:42:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1300236153; bh=SU6Jo/AcGP87szTl/xkB8+QuyLH9lwBj8sD5PtSceCU=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=ZYzOOY7EEJs61pj+OuE6beCI9s3sqI3aZ3N1HhHtSDNh3hUasqg5XGjWsSO+Ohc3IwPs2Dn7McB2eWyIk0TaB66JkPoI4NldQ05Kgx/Ri4GHOTUhS5BhWbWTGtFbe4mk5OBhkIFPoqA7PnuB223VjznwQ0WDsJcwwo0+l/CHbSA= Received: from Studio (d.sturek@69.105.136.148 with login) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 15 Mar 2011 17:42:32 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: a6u6A9oVM1kCD0LFBqGdYeIFmx7HIGj8OoXeF48l9d6kF.O zc8jyADB1b1aUW813pgkNQxHWHTEViKEzodqqyRuFFK.vEPKOYAbJk7oE1Po 7IB0Gn0Q4smujaPbZKoKsZLUKRTU81crTHcmklxNSzMavuWoAJA4xfUqzdkD kyCfTYLJxA8AgdZVi3F_J11oVWL_3Eo1CACt0ESlioi6AD6NyQrjyKcREup4 pos0FliGoAInFqznaHNvb82rGNhB9ZNZpLbpWHfwva2tLuO7NlkqODrce17e p7BclKKFqyQd7a__7NCWB X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'james woodyatt'" , "'Thomas Herbst'" References: <491F9309-238E-4B2C-BFEB-E9BE4EF00C86@apple.com> In-Reply-To: <491F9309-238E-4B2C-BFEB-E9BE4EF00C86@apple.com> Date: Tue, 15 Mar 2011 17:42:26 -0700 Message-ID: <005601cbe373$0874d610$195e8230$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjcazLuM/tjF9pSeydi667OdCx5gAAOrqw Content-Language: en-us Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 00:41:14 -0000 Hi James, Sure, I am the chair for the core stack team responsible for the networking portion. My comments below marked with DON.... Don -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Tuesday, March 15, 2011 5:33 PM To: Thomas Herbst Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt On Mar 15, 2011, at 5:18 PM, Thomas Herbst wrote: > > Does every 802.15.4 application level gateway now need to be upgraded for the "lightbulb app"? I don't know. Presumably, someone with deeper knowledge of applications for 802.15.4 networking can speak authoritatively about what requirements might arise for application proxies in this scenario. Is there anyone with enough authority here to tell us? DON: If everytime anyone adds a new application we require an application proxy then your suggestion does not scale and won't work. That would be a shame for a current install base of 11 million devices we plan to switch onto IPv6 next year. > The problem we are trying to solve is to connect subnets of different mac/phys together. The way to do that is to layer 3 forwarding. Maybe if I recite the link to RFC 4389, I'll get some traction: Just to be really thorough, I'll quote the abstract too. Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. Seriously, why doesn't neighbor discovery proxy offer the optimal solution here? I understand that layer-3 forwarding can be made to solve this problem. What I don't understand is why we are discounting the operational advantages of neighbor discovery proxy. DON: So who configures the neighbor discovery proxy when a customer brings a new CPE home from the store? If this is somehow expected to happen automatically, I would rather solve the ULA and inter-residence routing problem than try to figure out how to configure an application proxy like you are suggesting. -- james woodyatt member of technical staff, core os networking _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From therbst@silverspringnet.com Tue Mar 15 17:45:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12B6A3A6BA1 for ; Tue, 15 Mar 2011 17:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdqU5NUKSOg8 for ; Tue, 15 Mar 2011 17:45:40 -0700 (PDT) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by core3.amsl.com (Postfix) with ESMTP id 46F0D3A6A19 for ; Tue, 15 Mar 2011 17:45:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANOef00KyAE+/2dsb2JhbACnBMFUhWIEhTCLFg X-IronPort-AV: E=Sophos;i="4.63,191,1299484800"; d="scan'208";a="3567205" Received: from unknown (HELO IT-EXCA-02.silverspringnet.com) ([10.200.1.62]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 15 Mar 2011 17:18:44 -0700 Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-02.silverspringnet.com ([::1]) with mapi; Tue, 15 Mar 2011 17:18:44 -0700 From: Thomas Herbst To: james woodyatt , IPv6 Ops WG Date: Tue, 15 Mar 2011 17:18:42 -0700 Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvjb7W2+rIx7LQwSDWNP4bYkUNmqw== Message-ID: In-Reply-To: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 00:45:41 -0000 James,=20 I can't say those solutions won't work. There are lots of ways to build a system. The applications we are developing on the 802.15.4 networks are IP based applications. We are doing that because we'd like to have the benefits of IP networking. While there are utility applications on the 802.15.4 network, it is the user's network and we should provide IP connectivity such that they can run what they want on it. I recently saw a startup demonstrate an IP networking enabled lightbulb. It is 802.15.4, but does not run the same applications we are putting on the utility meters. Does every 802.15.4 application level gateway now need to be upgraded for the "lightbulb app"? The problem we are trying to solve is to connect subnets of different mac/phys together. The way to do that is to layer 3 forwarding. An IGP (I don't care which one) is the obvious way to enable customers to interconnect their networks in arbitrary fashion, rather than hacking on a ND-proxy. One other problem mentioned on this thread was the issue of routes sent back to the provider. First, routing updates should not be sent to the provider, second, the provider should not be listening to routing updates from CPE. tom On 3/15/11 3:36 PM, "james woodyatt" wrote: >On Mar 15, 2011, at 14:00 , Thomas Herbst wrote: >>=20 >> The requirement for a IGP is that there is a need for intra-home routing >> between 802.3 framed networks and 802.15.4 in-home networks. >>=20 >> There are two likely scenarios - >> 1) God box - Internet 802.3 (WAN) connection, 802.11 interior >>connection, >> 802.3 interior connection(s) and a 802.15.4 connection >>=20 >> Or=20 >>=20 >> 2) multiple boxes - one from retail or SP with Internet 802.3 (WAN) >> connection, 802.11 interior connection, 802.3 interior connection(s) >> And a second with 802.3 and 802.15.4 >>=20 >> With number 2, to enable Internet connectivity to the 802.15.4 network >>and >> general connectivity between the 802.11/802.3 networks and the 802.15.4 >> network, an IGP is required. > >Would somebody please explain in clear technical detail why the obvious >alternative, i.e. ND-proxy at the bastion between 802.1D and 802.15.4, is >an unsatisfactory solution to the problem of not being able to bridge >between 802.1D and 802.15.4? > >A related question is why an application proxy, which has the virtue of >working when the residential Internet service provider is IPv4-only, is >also an unsatisfactory solution to the Internet connectivity problems of >the 802.15.4 engineering community? > > >-- >james woodyatt >member of technical staff, core os networking > > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Tue Mar 15 18:28:12 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0087B3A6A6F for ; Tue, 15 Mar 2011 18:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.48 X-Spam-Level: X-Spam-Status: No, score=-106.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwZlvLyyoT2E for ; Tue, 15 Mar 2011 18:28:11 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 340123A6A6B for ; Tue, 15 Mar 2011 18:28:11 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 416DCD70A29D for ; Tue, 15 Mar 2011 18:29:37 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-16-4d8012812260 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay15.apple.com (Apple SCV relay) with SMTP id 46.62.18996.182108D4; Tue, 15 Mar 2011 18:29:37 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.15.152] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI400G3CMTCQE80@gertie.apple.com> for v6ops@ietf.org; Tue, 15 Mar 2011 18:29:37 -0700 (PDT) From: james woodyatt In-reply-to: <005601cbe373$0874d610$195e8230$%sturek@att.net> Date: Tue, 15 Mar 2011 18:29:36 -0700 Message-id: <3BF10A81-18C9-42D1-85F5-91E6A5361DBE@apple.com> References: <491F9309-238E-4B2C-BFEB-E9BE4EF00C86@apple.com> <005601cbe373$0874d610$195e8230$%sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 01:28:12 -0000 On Mar 15, 2011, at 5:42 PM, Don Sturek wrote: > > DON: So who configures the neighbor discovery proxy when a customer brings > a new CPE home from the store? If this is somehow expected to happen > automatically, I would rather solve the ULA and inter-residence routing > problem than try to figure out how to configure an application proxy like > you are suggesting. I don't see how this problem can be any more complicated than configuring the router you plan to use as the border between the 802.1D and 802.15.4 segments behind a CPE gateway. It *should* be substantially less complicated. You tell the ND-proxy what 802.11 SSID to join or you plug a CAT-5 cable into its RJ-45 jack, then you tell it whatever parameters it needs to be a part of the 802.15.4 networks it will be bridging. You're done. Both 802.15.4 and 802.11 have simplified protected network setup methods, i.e. WPS in the case of 802.11 and I'm sure there's gotta be something like Bluetooth pairing for 802.15.4, right? Plugging CAT-5 into RJ-45 jacks is *really* easy. I feel certain that even nearly-fossilized electric utility companies can find technical writers who can handle the cognitive burden all this will place on ordinary consumers who buy cheap gear from their local $0.99 hardware stores. I'm extremely dubious, however, about that cognitive burden being manageable when the bastion between 802.15.4 and 802.1D is a router, which by the way has all the same configuration problems as a ND proxy box plus the fact that you have to configure... well, a *router*. Have you tried configuring one of those? I'm told there are companies that, for a nominal fee, will *certify* you as a competent technician skilled in configuring them. Some people make a living configuring and maintaining other people's routers. Hmmm. Maybe, just maybe, that's the whole point of this exercise? Nah, that couldn't be it. -- james woodyatt member of technical staff, core os networking From d.sturek@att.net Tue Mar 15 19:15:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5DD3A6B5B for ; Tue, 15 Mar 2011 19:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CajtXuZgD+Ir for ; Tue, 15 Mar 2011 19:15:02 -0700 (PDT) Received: from nm7-vm0.bullet.mail.ne1.yahoo.com (nm7-vm0.bullet.mail.ne1.yahoo.com [98.138.91.66]) by core3.amsl.com (Postfix) with SMTP id 5C3CA3A6A7E for ; Tue, 15 Mar 2011 19:15:02 -0700 (PDT) Received: from [98.138.90.49] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 16 Mar 2011 02:16:25 -0000 Received: from [98.138.89.197] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 16 Mar 2011 02:16:25 -0000 Received: from [127.0.0.1] by omp1055.mail.ne1.yahoo.com with NNFMP; 16 Mar 2011 02:16:25 -0000 X-Yahoo-Newman-Id: 327873.60407.bm@omp1055.mail.ne1.yahoo.com Received: (qmail 79536 invoked from network); 16 Mar 2011 02:16:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1300241776; bh=rN7AkxrHQ3oedrWArA5GTWwPkMKMg6pl6C+UrGz+rFQ=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=A2fWYo+3b/2B9s0N5PoTwQoPOLaRYFu4XMpuadDYgUElBIzSg4hu2hflUPN//fl/gFlAF8/URr0D9H/GhDI4W9coNHU12u6xEUJFmIXTSYCnPHKHnqhpCPcPTJQ1QkxW9dCoBLsxgn4t6f3ymkrLE3ZuV0RwiR6FxuZdPmMEiCg= Received: from Studio (d.sturek@69.105.136.148 with login) by smtp106.sbc.mail.gq1.yahoo.com with SMTP; 15 Mar 2011 19:16:14 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 1Um.rPUVM1l88dFG2ZF_wGEYXhNuEj0IwghRBZVicuW1tWO 5Kra_ppf7540mbz4ZBqF9_kpy1Q29I7cuW2cEjI6lA54193ixwNt.4jW5G9O RFJ9COtwny8ymOZATU6d41liK1DDvxBCzTJ2wJ8ez1B.Ti2cK0YLut4TLpaT StjP4JPFme1znAhxCcvZMTvr_aIRE3z6SjuM9xwJZUEweHT_GjNdbknjjUM1 L9gKDnSvEK.l5G19VNTCY0XvgzY51zi0wsepMwrSf.JGr1vLaix.DUBwGWOy iKTw3mdGTVKNat3yAJ.Wpxf5RC52_Twj2af7Up5DF790ygjINdeEYgrUBVD2 S3n5c X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'james woodyatt'" References: <491F9309-238E-4B2C-BFEB-E9BE4EF00C86@apple.com> <005601cbe373$0874d610$195e8230$%sturek@att.net> <3BF10A81-18C9-42D1-85F5-91E6A5361DBE@apple.com> In-Reply-To: <3BF10A81-18C9-42D1-85F5-91E6A5361DBE@apple.com> Date: Tue, 15 Mar 2011 19:16:10 -0700 Message-ID: <007101cbe380$1f2b1fb0$5d815f10$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjeZ3okhUoLr9CSLW9e7NyJdlwjwABlgmQ Content-Language: en-us Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 02:15:03 -0000 Hi James, You should get off of your soap box and get into the real world. Maybe we should find actual engineers in the v6ops group to look into the issue rather than folks interested in looking after their legacy deployments that actually don't work. Don -----Original Message----- From: james woodyatt [mailto:jhw@apple.com] Sent: Tuesday, March 15, 2011 6:30 PM To: d.sturek@att.net Cc: 'Thomas Herbst'; 'IPv6 Ops WG' Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt On Mar 15, 2011, at 5:42 PM, Don Sturek wrote: > > DON: So who configures the neighbor discovery proxy when a customer brings > a new CPE home from the store? If this is somehow expected to happen > automatically, I would rather solve the ULA and inter-residence routing > problem than try to figure out how to configure an application proxy like > you are suggesting. I don't see how this problem can be any more complicated than configuring the router you plan to use as the border between the 802.1D and 802.15.4 segments behind a CPE gateway. It *should* be substantially less complicated. You tell the ND-proxy what 802.11 SSID to join or you plug a CAT-5 cable into its RJ-45 jack, then you tell it whatever parameters it needs to be a part of the 802.15.4 networks it will be bridging. You're done. Both 802.15.4 and 802.11 have simplified protected network setup methods, i.e. WPS in the case of 802.11 and I'm sure there's gotta be something like Bluetooth pairing for 802.15.4, right? Plugging CAT-5 into RJ-45 jacks is *really* easy. I feel certain that even nearly-fossilized electric utility companies can find technical writers who can handle the cognitive burden all this will place on ordinary consumers who buy cheap gear from their local $0.99 hardware stores. I'm extremely dubious, however, about that cognitive burden being manageable when the bastion between 802.15.4 and 802.1D is a router, which by the way has all the same configuration problems as a ND proxy box plus the fact that you have to configure... well, a *router*. Have you tried configuring one of those? I'm told there are companies that, for a nominal fee, will *certify* you as a competent technician skilled in configuring them. Some people make a living configuring and maintaining other people's routers. Hmmm. Maybe, just maybe, that's the whole point of this exercise? Nah, that couldn't be it. -- james woodyatt member of technical staff, core os networking From swmike@swm.pp.se Tue Mar 15 22:00:27 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23C23A6774 for ; Tue, 15 Mar 2011 22:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOfTDekBP6LX for ; Tue, 15 Mar 2011 22:00:12 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id A8F073A6783 for ; Tue, 15 Mar 2011 22:00:05 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C34209C; Wed, 16 Mar 2011 06:01:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BEC0F9A; Wed, 16 Mar 2011 06:01:29 +0100 (CET) Date: Wed, 16 Mar 2011 06:01:29 +0100 (CET) From: Mikael Abrahamsson To: "Hemant Singh (shemant)" In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C301049A8B@XMB-RCD-109.cisco.com> Message-ID: References: <20110305184502.18531.25548.idtracker@localhost> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049957@XMB-RCD-109.cisco.com> <0EDD6F66-D326-4656-B767-48C9B73989A3@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C30104998F@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3010499C3@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049A8B@XMB-RCD-109.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 05:00:28 -0000 On Tue, 15 Mar 2011, Hemant Singh (shemant) wrote: >> Or is the intention do to PD both for the SP prefix and the ULA prefix >> from the CE, so any home IR always ask for multiple prefixes using PD, > or >> can the CE PD multiple prefixes at once and the proposed design is that > it >> should? > > The Basic IPv6 CE router document that covers the topic of ULA does not > go into such details and does not need to. The PD acquisition can > happen in any order for the ULA or the GUA (Globally Unique Address). I wasn't talking about the basic document, I was talking about the new one. Does the home IR aquire ULA *and* GUA using DHCPv6-PD from the CE, or does it create an ULA itself? How does the home IR what role it has, I would imagine it would be an identical device as the CE, so if this is to be plug and play, it needs to auto-discover this? -- Mikael Abrahamsson email: swmike@swm.pp.se From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Mar 16 01:43:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9F33A6892 for ; Wed, 16 Mar 2011 01:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCIopyif7+PA for ; Wed, 16 Mar 2011 01:43:56 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 3EC213A6860 for ; Wed, 16 Mar 2011 01:43:55 -0700 (PDT) Received: from 114-30-119-224.ip.adam.com.au ([114.30.119.224] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1PzmM3-00077Z-Rm; Wed, 16 Mar 2011 19:15:19 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 352F65355B; Wed, 16 Mar 2011 19:15:19 +1030 (CST) Date: Wed, 16 Mar 2011 19:15:18 +1030 From: Mark Smith To: james woodyatt Message-ID: <20110316191518.718e918a@opy.nosense.org> In-Reply-To: <491F9309-238E-4B2C-BFEB-E9BE4EF00C86@apple.com> References: <491F9309-238E-4B2C-BFEB-E9BE4EF00C86@apple.com> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 08:43:57 -0000 Hi James, On Tue, 15 Mar 2011 17:32:43 -0700 james woodyatt wrote: > On Mar 15, 2011, at 5:18 PM, Thomas Herbst wrote: > > > > Does every 802.15.4 application level gateway now need to be upgraded for the "lightbulb app"? > > I don't know. Presumably, someone with deeper knowledge of applications for 802.15.4 networking can speak authoritatively about what requirements might arise for application proxies in this scenario. > > Is there anyone with enough authority here to tell us? > > > The problem we are trying to solve is to connect subnets of different mac/phys together. The way to do that is to layer 3 forwarding. > > Maybe if I recite the link to RFC 4389, I'll get some traction: > > > > Just to be really thorough, I'll quote the abstract too. > > Bridging multiple links into a single entity has several operational > advantages. A single subnet prefix is sufficient to support multiple > physical links. There is no need to allocate subnet numbers to the > different networks, simplifying management. Bridging some types of > media requires network-layer support, however. This document > describes these cases and specifies the IP-layer support that enables > bridging under these circumstances. > > Seriously, why doesn't neighbor discovery proxy offer the optimal solution here? ULAs only for 802.16.4 devices, global + ULAs for other devices in the home. Possibility of multicast video, which would likely flatten the 802.16.4 devices' batteries in minutes if not seconds, and would have somewhat similar impacts on wifi connected laptop batteries. Segregation of networks for different security / Internet access policies and/or audit e.g. parent net verses children net. > I understand that layer-3 forwarding can be made to solve this > problem. What I don't understand is why we are discounting the > operational advantages of neighbor discovery proxy. > I think subnets provide a convenient tool to group devices together when they have common attributes or requirements - they're not necessarily useful just to overcome different link layer framing formats. If we can't use subnets to group devices together, then any decisions to perform actions based on these attributes or requirements needs to based on individual devices identities. For example, you could avoid the negative impacts of e.g. multicast video on a bridged or ND proxied segment of mixed 802.3 and 802.16.4 devices by moving to an NBMA/NHRP model for the segment. Unfortunately you'd lose the efficiency of link layer multicasts when you gain the ability to be more selective about what types of traffic is sent to specific end-nodes. Regards, Mark. From jav@sics.se Wed Mar 16 03:05:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C173A68E0 for ; Wed, 16 Mar 2011 03:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwwsOmMMESy8 for ; Wed, 16 Mar 2011 03:05:54 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 5EEE33A6917 for ; Wed, 16 Mar 2011 03:05:54 -0700 (PDT) Received: from [193.10.66.199] (dab.sics.se [193.10.66.199]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 976B7400F0; Wed, 16 Mar 2011 11:07:19 +0100 (CET) From: Javier Ubillos To: Andrew Yourtchenko In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-PvqolZZ9tli8eZs6Uipr" Date: Wed, 16 Mar 2011 11:07:19 +0100 Message-ID: <1300270039.2217.9.camel@dab> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: ayourtch@gmail.com, v6ops@ietf.org Subject: Re: [v6ops] HEX bar BoF in Prague poll X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 10:05:55 -0000 --=-PvqolZZ9tli8eZs6Uipr Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are we approaching any date decision? // Javier On Mon, 2011-02-28 at 19:47 +0100, Andrew Yourtchenko wrote: > Folks, >=20 > we've had a couple of offline discussions that it might be a good idea to= have a=20 > Bar BoF on happy eyeballs topics, and exchange the practical experiences. >=20 > So, Happy Eyeballs Xperi(ences|ments) bar bof: >=20 > http://doodle.com/arq27emxw45z92cd >=20 > In the spirit of the algorithm, there are two choices - 29th and 31th. >=20 > By adding some way to contact you back and ticking one or two of the tick= boxes=20 > onthe URL above you are increasing one or both of the "P" values. >=20 > The biggest value of P will win on the date. >=20 > The place will TBD depending on the # of folks. The default is that it wi= ll be a=20 > bar (since it's a bar bof). >=20 > The determination of the maximum of P will happen on 16th of March. >=20 > cheers, > andrew > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=-PvqolZZ9tli8eZs6Uipr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk2Ai9UACgkQGBo5FLRz4gqffACghu5d3J/HiEN0ybn6h8GM86dH IuEAni0exgWBNPnFQlS57Cc3H5RLHayw =DnT7 -----END PGP SIGNATURE----- --=-PvqolZZ9tli8eZs6Uipr-- From jav@sics.se Wed Mar 16 03:05:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39F03A68E0 for ; Wed, 16 Mar 2011 03:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgpYbPD+Z0ZF for ; Wed, 16 Mar 2011 03:05:55 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 5F0013A6918 for ; Wed, 16 Mar 2011 03:05:54 -0700 (PDT) Received: from [193.10.66.199] (dab.sics.se [193.10.66.199]) (Authenticated sender: jav@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 6FC90400D2; Wed, 16 Mar 2011 11:07:19 +0100 (CET) From: Javier Ubillos To: Andrew Yourtchenko In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-uasqg/26MCsJ1V1N0bpE" Date: Wed, 16 Mar 2011 11:07:17 +0100 Message-ID: <1300270037.2217.8.camel@dab> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Cc: ayourtch@gmail.com, v6ops@ietf.org Subject: Re: [v6ops] HEX bar BoF in Prague poll X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 10:05:55 -0000 --=-uasqg/26MCsJ1V1N0bpE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are we approaching any date decision? // Javier On Mon, 2011-02-28 at 19:47 +0100, Andrew Yourtchenko wrote: > Folks, >=20 > we've had a couple of offline discussions that it might be a good idea to= have a=20 > Bar BoF on happy eyeballs topics, and exchange the practical experiences. >=20 > So, Happy Eyeballs Xperi(ences|ments) bar bof: >=20 > http://doodle.com/arq27emxw45z92cd >=20 > In the spirit of the algorithm, there are two choices - 29th and 31th. >=20 > By adding some way to contact you back and ticking one or two of the tick= boxes=20 > onthe URL above you are increasing one or both of the "P" values. >=20 > The biggest value of P will win on the date. >=20 > The place will TBD depending on the # of folks. The default is that it wi= ll be a=20 > bar (since it's a bar bof). >=20 > The determination of the maximum of P will happen on 16th of March. >=20 > cheers, > andrew > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=-uasqg/26MCsJ1V1N0bpE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk2Ai88ACgkQGBo5FLRz4gpoNwCgm+L5IDF10cxGWYKE0Bd3Mdoa 2kwAn2W3IOftXPfyspJu2xmwGvr7IQlf =Rvdp -----END PGP SIGNATURE----- --=-uasqg/26MCsJ1V1N0bpE-- From ayourtch@cisco.com Wed Mar 16 04:46:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705A43A6972 for ; Wed, 16 Mar 2011 04:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38-9VmHh1WYS for ; Wed, 16 Mar 2011 04:45:59 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 2FE963A68BF for ; Wed, 16 Mar 2011 04:45:59 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2GBBlWl002355; Wed, 16 Mar 2011 12:11:47 +0100 (CET) Received: from sweet-brew-4.cisco.com (sweet-brew-4.cisco.com [144.254.10.205]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2GBBldP026576; Wed, 16 Mar 2011 12:11:47 +0100 (CET) Date: Wed, 16 Mar 2011 12:11:47 +0100 (CET) From: Andrew Yourtchenko To: Andrew Yourtchenko In-Reply-To: Message-ID: References: <1300270039.2217.9.camel@dab> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] HEX bar BoF in Prague poll X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 11:46:00 -0000 On Wed, 16 Mar 2011, Andrew Yourtchenko wrote: > Yes, yesterday night we had 10 people for Tuesday vs. 9 for Wednesday, s/Wednesday/Thursday/ - I need more coffee. Anyway, the date is Tuesday 29th March. cheers, andrew > so we will have to go with that. I'll check on the location and let > everyone know. > > cheers, > andrew > > On Wed, Mar 16, 2011 at 11:07 AM, Javier Ubillos wrote: >> Are we approaching any date decision? >> // Javier >> >> On Mon, 2011-02-28 at 19:47 +0100, Andrew Yourtchenko wrote: >>> Folks, >>> >>> we've had a couple of offline discussions that it might be a good idea to have a >>> Bar BoF on happy eyeballs topics, and exchange the practical experiences. >>> >>> So, Happy Eyeballs Xperi(ences|ments) bar bof: >>> >>> http://doodle.com/arq27emxw45z92cd >>> >>> In the spirit of the algorithm, there are two choices - 29th and 31th. >>> >>> By adding some way to contact you back and ticking one or two of the tickboxes >>> onthe URL above you are increasing one or both of the "P" values. >>> >>> The biggest value of P will win on the date. >>> >>> The place will TBD depending on the # of folks. The default is that it will be a >>> bar (since it's a bar bof). >>> >>> The determination of the maximum of P will happen on 16th of March. >>> >>> cheers, >>> andrew >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> > From fred@cisco.com Wed Mar 16 09:20:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DEEF3A6909 for ; Wed, 16 Mar 2011 09:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.158 X-Spam-Level: X-Spam-Status: No, score=-110.158 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jbnLx4mdNoT for ; Wed, 16 Mar 2011 09:20:22 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AB5A53A68EB for ; Wed, 16 Mar 2011 09:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2022; q=dns/txt; s=iport; t=1300292509; x=1301502109; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=sO9UWmmaFYWze4A+H32iS7vD175rCX1L4m5eSobmyu8=; b=Ulvn3XFqeIEeHjRc5RfVW0jb/E2E8ZmPsHiSAI3zAMQE0C+3jEZwEq+6 yR8XIFebrQzxw6hoZR255jWm/oTcR7q4nVC6rV7Y+VY70W3imhkbg4HCf ntlaxeCJx7961ZmhXOcB/VQQRo4om7pJ1auXyx1II1v762Hnqaz/+GPy7 s=; X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208";a="276630168" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-4.cisco.com with ESMTP; 16 Mar 2011 16:21:49 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2GGLhZN024711; Wed, 16 Mar 2011 16:21:48 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Wed, 16 Mar 2011 09:21:48 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Wed, 16 Mar 2011 09:21:48 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Wed, 16 Mar 2011 09:21:32 -0700 Message-Id: <7CDEDF38-9CBD-4F4D-B48A-B79266429382@cisco.com> References: <1300270039.2217.9.camel@dab> To: Andrew Yourtchenko X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] HEX bar BoF in Prague poll X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 16:20:24 -0000 On Mar 16, 2011, at 4:11 AM, Andrew Yourtchenko wrote: > On Wed, 16 Mar 2011, Andrew Yourtchenko wrote: >> Yes, yesterday night we had 10 people for Tuesday vs. 9 for = Wednesday, >=20 >=20 > s/Wednesday/Thursday/ - I need more coffee. >=20 > Anyway, the date is Tuesday 29th March. That's a great date. Most of us have a wee bit going on. Can I lean on = you to get a little more specific? Here: I'll help: http://www.doodle.com/ecuszwiftiarb9bd > cheers, > andrew >=20 >=20 >> so we will have to go with that. I'll check on the location and let >> everyone know. >>=20 >> cheers, >> andrew >>=20 >> On Wed, Mar 16, 2011 at 11:07 AM, Javier Ubillos wrote: >>> Are we approaching any date decision? >>> // Javier >>>=20 >>> On Mon, 2011-02-28 at 19:47 +0100, Andrew Yourtchenko wrote: >>>> Folks, >>>>=20 >>>> we've had a couple of offline discussions that it might be a good = idea to have a >>>> Bar BoF on happy eyeballs topics, and exchange the practical = experiences. >>>>=20 >>>> So, Happy Eyeballs Xperi(ences|ments) bar bof: >>>>=20 >>>> http://doodle.com/arq27emxw45z92cd >>>>=20 >>>> In the spirit of the algorithm, there are two choices - 29th and = 31th. >>>>=20 >>>> By adding some way to contact you back and ticking one or two of = the tickboxes >>>> onthe URL above you are increasing one or both of the "P" values. >>>>=20 >>>> The biggest value of P will win on the date. >>>>=20 >>>> The place will TBD depending on the # of folks. The default is that = it will be a >>>> bar (since it's a bar bof). >>>>=20 >>>> The determination of the maximum of P will happen on 16th of March. >>>>=20 >>>> cheers, >>>> andrew >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>=20 >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From simon.perreault@viagenie.ca Wed Mar 16 09:44:32 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB683A69D5 for ; Wed, 16 Mar 2011 09:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8PRXkZ6yZLt for ; Wed, 16 Mar 2011 09:44:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id F2E183A6929 for ; Wed, 16 Mar 2011 09:44:28 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5BE5421F1B; Wed, 16 Mar 2011 12:45:54 -0400 (EDT) Message-ID: <4D80E941.1080202@viagenie.ca> Date: Wed, 16 Mar 2011 12:45:53 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Fred Baker References: <1300270039.2217.9.camel@dab> <7CDEDF38-9CBD-4F4D-B48A-B79266429382@cisco.com> In-Reply-To: <7CDEDF38-9CBD-4F4D-B48A-B79266429382@cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] HEX bar BoF in Prague poll X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 16:44:32 -0000 On 2011-03-16 12:21, Fred Baker wrote: > That's a great date. Most of us have a wee bit going on. Can I lean on you to get a little more specific? > > Here: I'll help: http://www.doodle.com/ecuszwiftiarb9bd The initial doodle said: "The time will be evening (~20:00ish)." I would hope for "at the social". Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From fred@cisco.com Wed Mar 16 09:54:00 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59DC3A69DF for ; Wed, 16 Mar 2011 09:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.447 X-Spam-Level: X-Spam-Status: No, score=-110.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcH-EvxVdhH1 for ; Wed, 16 Mar 2011 09:53:59 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8863A3A69D5 for ; Wed, 16 Mar 2011 09:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=679; q=dns/txt; s=iport; t=1300294526; x=1301504126; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=ApJ6EtUG6w5iei7p+U7K285MBlvWVQs1zicxyQDfSsA=; b=NeZj5F6AjE9vnnnIkmttRUN+edMoaKM3XzqNE0BSOZ0iIu2yp0sTFNTY f9ywTzWPkIrw4OAccQwn//Lp7rySerp/NKSlKelLcdPoegtCTulIly9Mf QyI1u6SNA7aBtvz0p2C358S/W7XsRk+S8ef6l40zkIWYNJbYSHpmqcJsU 4=; X-IronPort-AV: E=Sophos;i="4.63,195,1299456000"; d="scan'208";a="667763187" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-6.cisco.com with ESMTP; 16 Mar 2011 16:55:26 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2GGsmHG001202; Wed, 16 Mar 2011 16:55:25 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Wed, 16 Mar 2011 09:55:25 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Wed, 16 Mar 2011 09:55:25 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D80E941.1080202@viagenie.ca> Date: Wed, 16 Mar 2011 09:55:24 -0700 Message-Id: <34820535-CB05-4EE3-90AC-56D9D262A5E1@cisco.com> References: <1300270039.2217.9.camel@dab> <7CDEDF38-9CBD-4F4D-B48A-B79266429382@cisco.com> <4D80E941.1080202@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] HEX bar BoF in Prague poll X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 16:54:00 -0000 OK, I missed that. Yes, I would hope it was "at the social". On Mar 16, 2011, at 9:45 AM, Simon Perreault wrote: > On 2011-03-16 12:21, Fred Baker wrote: >> That's a great date. Most of us have a wee bit going on. Can I lean = on you to get a little more specific? >>=20 >> Here: I'll help: http://www.doodle.com/ecuszwiftiarb9bd >=20 > The initial doodle said: "The time will be evening (~20:00ish)." >=20 > I would hope for "at the social". >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca From ayourtch@cisco.com Wed Mar 16 11:12:15 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B7B3A6A27 for ; Wed, 16 Mar 2011 11:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[AWL=0.839, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76K+wRV3yjyp for ; Wed, 16 Mar 2011 11:12:14 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 90DC53A6A31 for ; Wed, 16 Mar 2011 11:12:13 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2GI603l015049; Wed, 16 Mar 2011 19:06:00 +0100 (CET) Received: from sweet-brew-4.cisco.com (sweet-brew-4.cisco.com [144.254.10.205]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p2GI5x0i022586; Wed, 16 Mar 2011 19:05:59 +0100 (CET) Date: Wed, 16 Mar 2011 19:05:59 +0100 (CET) From: Andrew Yourtchenko To: Fred Baker In-Reply-To: <34820535-CB05-4EE3-90AC-56D9D262A5E1@cisco.com> Message-ID: References: <1300270039.2217.9.camel@dab> <7CDEDF38-9CBD-4F4D-B48A-B79266429382@cisco.com> <4D80E941.1080202@viagenie.ca> <34820535-CB05-4EE3-90AC-56D9D262A5E1@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] HEX bar BoF in Prague poll X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 18:12:15 -0000 On Wed, 16 Mar 2011, Fred Baker wrote: > OK, I missed that. Yes, I would hope it was "at the social". Yes, at the social it will be. cheers, andrew > > On Mar 16, 2011, at 9:45 AM, Simon Perreault wrote: > >> On 2011-03-16 12:21, Fred Baker wrote: >>> That's a great date. Most of us have a wee bit going on. Can I lean on you to get a little more specific? >>> >>> Here: I'll help: http://www.doodle.com/ecuszwiftiarb9bd >> >> The initial doodle said: "The time will be evening (~20:00ish)." >> >> I would hope for "at the social". >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca > > From scott.brim@gmail.com Wed Mar 16 11:14:48 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197F03A6A27 for ; Wed, 16 Mar 2011 11:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.276 X-Spam-Level: X-Spam-Status: No, score=-103.276 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfLTmMdMh3pQ for ; Wed, 16 Mar 2011 11:14:47 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D990E3A69DD for ; Wed, 16 Mar 2011 11:14:46 -0700 (PDT) Received: by gxk19 with SMTP id 19so933750gxk.31 for ; Wed, 16 Mar 2011 11:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=993FvVSqQxxE1JJrC0XS2qkmHTpKa9ibX7BBMDdjEuQ=; b=YPTpcPaFrTg2Qf2+Q43XxuBQ7S4yoDPPC26ZAbc6rJjjq140d5fWflWswuMW3nXFlH FebvfL6ytHWbmtNfJtLc04bBiAO0lvSI5YRwG0lp05cx9Dxof5dnLKgADvNf/ftnNuy+ NTy9v0aFL/kBsmjG/NcDfp6r2OhB4ltczZ+Ac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Lw70qbyXkZEykQesiaFy+ysvRtk2EL8Q7zqOspFLTHr3kz6jiFzXR1fjzS4zQQUaYn 002/BLTfS+bAPKQC9FMgQ+hUkrZk0WR4pbzy5JDaZnGLaga5KY+7Z7UFPXUO+JfehbUh JPaEWb3Ls4KcuojyL+xZ6D2Ic1qsAf3pTEXSs= Received: by 10.43.51.65 with SMTP id vh1mr411796icb.435.1300299373155; Wed, 16 Mar 2011 11:16:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.114.81 with HTTP; Wed, 16 Mar 2011 11:15:53 -0700 (PDT) In-Reply-To: References: <1300270039.2217.9.camel@dab> <7CDEDF38-9CBD-4F4D-B48A-B79266429382@cisco.com> <4D80E941.1080202@viagenie.ca> <34820535-CB05-4EE3-90AC-56D9D262A5E1@cisco.com> From: Scott Brim Date: Wed, 16 Mar 2011 14:15:53 -0400 Message-ID: To: Andrew Yourtchenko Content-Type: multipart/alternative; boundary=bcaec5299ad73d159f049e9d8a9d Cc: IPv6 Ops WG Subject: Re: [v6ops] HEX bar BoF in Prague poll X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 18:14:48 -0000 --bcaec5299ad73d159f049e9d8a9d Content-Type: text/plain; charset=ISO-8859-1 ok On Wed, Mar 16, 2011 at 14:05, Andrew Yourtchenko wrote: > > > On Wed, 16 Mar 2011, Fred Baker wrote: > > OK, I missed that. Yes, I would hope it was "at the social". >> > > Yes, at the social it will be. > > cheers, > andrew > > > >> On Mar 16, 2011, at 9:45 AM, Simon Perreault wrote: >> >> On 2011-03-16 12:21, Fred Baker wrote: >>> >>>> That's a great date. Most of us have a wee bit going on. Can I lean on >>>> you to get a little more specific? >>>> >>>> Here: I'll help: http://www.doodle.com/ecuszwiftiarb9bd >>>> >>> >>> The initial doodle said: "The time will be evening (~20:00ish)." >>> >>> I would hope for "at the social". >>> >>> Simon >>> -- >>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >>> STUN/TURN server --> http://numb.viagenie.ca >>> >> >> >> _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --bcaec5299ad73d159f049e9d8a9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ok

On Wed, Mar 16, 2011 at 14:05, Andrew = Yourtchenko <ayo= urtch@cisco.com> wrote:


On Wed, 16 Mar 2011, Fred Baker wrote:

OK, I missed that. Yes, I would hope it was "at the social".

Yes, at the social it will be.

cheers,
andrew



On Mar 16, 2011, at 9:45 AM, Simon Perreault wrote:

On 2011-03-16 12:21, Fred Baker wrote:
That's a great date. Most of us have a wee bit going on. Can I lean on = you to get a little more specific?

Here: I'll help: http://www.doodle.com/ecuszwiftiarb9bd

The initial doodle said: "The time will be evening (~20:00ish)."<= br>
I would hope for "at the social".

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--bcaec5299ad73d159f049e9d8a9d-- From shemant@cisco.com Wed Mar 16 18:36:41 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A1C3A69FD for ; Wed, 16 Mar 2011 18:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.811 X-Spam-Level: X-Spam-Status: No, score=-10.811 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yIIwjq+S7hC for ; Wed, 16 Mar 2011 18:36:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B89163A67EE for ; Wed, 16 Mar 2011 18:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1146; q=dns/txt; s=iport; t=1300325887; x=1301535487; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Bzj4JQPh581MYIJetJPbO1UTfz+rnMYSIRKcI/zFiBI=; b=Zj0CfZCCPwUCRTUOi9ocPYhDsitzznV7JL7b0tvJpn1pXVSWUtkdAbQ+ t7ZxWJVEhSz/ahvFMDdP2Y3Roh3SdAHysgK9Sjbh7rZ+PIB2Qie4dsFG4 FjGxuAlZs7qX73XKm+nSr2yIP92xwA7+DZ7r/CGnobpQgZQ8PKAUpwRRQ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjABABMDgU2tJV2Y/2dsb2JhbACEPpNdjFlcd6YPiyORMYEng0V3BIUviwKDIA X-IronPort-AV: E=Sophos;i="4.63,197,1299456000"; d="scan'208";a="278903459" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 17 Mar 2011 01:38:05 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2H1c57I028559; Thu, 17 Mar 2011 01:38:05 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 20:38:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 16 Mar 2011 20:38:04 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30104A0ED@XMB-RCD-109.cisco.com> In-Reply-To: <4D7FE427.7000201@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvjXgO1+lgBM2r4TMeZzR5pruno6QA5T7LQ References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> <4D7FE427.7000201@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" X-OriginalArrivalTime: 17 Mar 2011 01:38:06.0224 (UTC) FILETIME=[F6A68100:01CBE443] Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 01:36:41 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBb bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBNYXJj aCAxNSwgMjAxMSA2OjEyIFBNDQpUbzogSGVtYW50IFNpbmdoIChzaGVtYW50KQ0KQ2M6IE1pa2Fl bCBBYnJhaGFtc3NvbjsgSVB2NiBPcHMgV0cNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rp b246ZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LWNwZS1yb3V0ZXItYmlzLTAwLnR4dA0KDQo+V2h5IGRv ZXMgdGhhdCBjaGFuZ2UgdGhlIHJlcXVpcmVtZW50cyBmb3IgYW4gSVB2NiByb3V0ZXI/IEl0J3Mg MTAwJQ0KPnN0YW5kYXJkIElQdjYgZGVwbG95bWVudC4NCg0KQWdyZWVkLiAgSG93ZXZlciB0aGUg ZGVzaWduIHRlYW0gaXMgc3RlcHBpbmcgZ2luZ2VybHkuICAgV2UgZmlyc3QgZGlkIGEgc2luZ2xl IElQdjYgQ0Ugcm91dGVyIGluIHRoZSBob21lIGNhc2Ugd2hpY2ggaXMgdGhlIEJhc2ljIElQdjYg Q0UgUm91dGVyIGRvY3VtZW50IGluIHRoZSBSRkMgRWRpdG9yIFF1ZXVlLiAgVGhlIGJpcyBkb2N1 bWVudCBjb3ZlcnMgYSBzcGVjaWZpYyB0d28tcm91dGVyIGNhc2UuICAgSXQncyBvbmx5IHRoZSBm YWN0IHRoYXQgbWFraW5nIGFsbCBJUHY2IGZlYXR1cmVzIG9mIHRoZSBDRSBSb3V0ZXIgd29yayB3 aXRoIG11bHRpaG9taW5nIGlzIHRoZSBpc3N1ZS4gIEZvciBzb21lIGZlYXR1cmVzIHNvbHV0aW9u cyBkb24ndCBldmVuIGV4aXN0LiAgU28gd2hhdCBkb2VzIGEgZG9jdW1lbnQgbGlrZSBvdXJzIHBy b3Bvc2UgZm9yIHNvbHV0aW9uIHRvIHVzZT8gDQoNCkhlbWFudA0K From shemant@cisco.com Wed Mar 16 18:47:06 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2F03A69F8 for ; Wed, 16 Mar 2011 18:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.803 X-Spam-Level: X-Spam-Status: No, score=-10.803 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuUuYZTdANtE for ; Wed, 16 Mar 2011 18:47:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id C576E3A69EA for ; Wed, 16 Mar 2011 18:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1375; q=dns/txt; s=iport; t=1300326513; x=1301536113; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=gcm+2qMOP3vk083FBQC5mRr4imYDNqZYGyDg+af4CNw=; b=KIJrbkFXmc6EnUG0DUa1A+nmf3WqXwWVBbZOHVuCCqx8OVNlVF0n/Vg7 ZGvlOq/Jye9SoXMQIS1s9Xew8+16ScCZ1gHnN4d5t3MoWO63yweAo8Fg4 JVlCTML0KqzjVTQRcI4Wt1k+tSg3EnuUSKLWkpfjiqhY1Lx27NrjCWN/+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjABAC8FgU2tJXG//2dsb2JhbACYG401d6YXnFOFYwSFL4sC X-IronPort-AV: E=Sophos;i="4.63,197,1299456000"; d="scan'208";a="276859568" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-4.cisco.com with ESMTP; 17 Mar 2011 01:48:32 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2H1mWsT005890; Thu, 17 Mar 2011 01:48:32 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 20:48:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Mar 2011 20:48:30 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30104A0F4@XMB-RCD-109.cisco.com> In-Reply-To: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvjYWpt88yDX3YWRailCI6V5O1bfQA40+uA References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> From: "Hemant Singh (shemant)" To: "james woodyatt" , "IPv6 Ops WG" X-OriginalArrivalTime: 17 Mar 2011 01:48:32.0815 (UTC) FILETIME=[6C20B3F0:01CBE445] Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 01:47:06 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Tuesday, March 15, 2011 6:36 PM To: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >Would somebody please explain in clear technical detail why the obvious alternative, i.e. ND-proxy at the bastion between 802.1D and 802.15.4, is an unsatisfactory solution to the problem of not being >able to bridge between 802.1D and 802.15.4? Indeed when one has two disparate transports with different MAC layers, one cannot bridge data between the two transports. Thus ND Proxy is one alternative that jumps to mind. See this text in the bis document. [LNDP-1: If the CE Router has only one /64 prefix to be used across multiple LAN interfaces and the CE Router supports any two LAN interfaces that cannot bridge data between them because the two interfaces have disparate MAC layers, then the CE Router MUST support Proxying Neighbor Advertisements as specified in Section 7.2.8 of [RFC4861].]=20 However the bis document adds ND Proxy for only once specific case for legacy 3GPP networks where the operator could dole out only one /64 to the CE router. If a shorter than /64 prefix is assigned to the CE Router, one should use routing between the two transport layers. Hemant From fred@cisco.com Wed Mar 16 19:02:20 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03A193A69FC for ; Wed, 16 Mar 2011 19:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.209 X-Spam-Level: X-Spam-Status: No, score=-110.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrjWO+KrtAdL for ; Wed, 16 Mar 2011 19:02:18 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 259A03A69FA for ; Wed, 16 Mar 2011 19:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1956; q=dns/txt; s=iport; t=1300327425; x=1301537025; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=Q6u7zfjKdju1Lr0D65IYx7KX+Tk6klWnUClG8TgCHSs=; b=cDPuCdWLOeLZHBLv5jIkvSpanAXFaAlLut5zzHM4MqgtkNGz6pAL2USB Rf9RLiGXxopUP1Fd+cwheObnAD1eht2cYVFxK+ZZUGa//mbHA1zNxsduU D9Q6C/gBXnu3KR0+A7+Rd8Ng3XhkP+AAtqOwcs40sIyz6i9UDcI+hG8sc 4=; X-IronPort-AV: E=Sophos;i="4.63,197,1299456000"; d="scan'208";a="348008114" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-5.cisco.com with ESMTP; 17 Mar 2011 02:03:45 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2H23eTi012836; Thu, 17 Mar 2011 02:03:44 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Wed, 16 Mar 2011 19:03:44 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Wed, 16 Mar 2011 19:03:44 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30104A0F4@XMB-RCD-109.cisco.com> Date: Wed, 16 Mar 2011 19:03:29 -0700 Message-Id: <9376DC69-9818-469C-9D14-8B18CA323E4C@cisco.com> References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30104A0F4@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 02:02:20 -0000 On Mar 16, 2011, at 6:48 PM, Hemant Singh (shemant) wrote: >=20 >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of james woodyatt > Sent: Tuesday, March 15, 2011 6:36 PM > To: IPv6 Ops WG > Subject: Re: [v6ops] I-D > Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >=20 >=20 >> Would somebody please explain in clear technical detail why the = obvious > alternative, i.e. ND-proxy at the bastion between 802.1D and 802.15.4, > is an unsatisfactory solution to the problem of not being >able to > bridge between 802.1D and 802.15.4? Because you can't take a packet off an 802.3 LAN and drop it on an = 802.15.4 LAN... Compare http://en.wikipedia.org/wiki/Ethernet_frame#Structure with age = 45 of http://www.atmel.com/dyn/resources/prod_documents/doc5131.pdf And besides, 1518 octets doesn't fit very well in 127. > Indeed when one has two disparate transports with different MAC = layers, > one cannot bridge data between the two transports. Thus ND Proxy is = one > alternative that jumps to mind. See this text in the bis document. >=20 > [LNDP-1: If the CE Router has only one /64 prefix to be used across > multiple LAN interfaces and the CE Router supports any two LAN > interfaces that cannot bridge data between them because the two > interfaces have disparate MAC layers, then the CE Router MUST support > Proxying Neighbor Advertisements as specified in Section 7.2.8 of > [RFC4861].]=20 >=20 > However the bis document adds ND Proxy for only once specific case for > legacy 3GPP networks where the operator could dole out only one /64 to > the CE router. If a shorter than /64 prefix is assigned to the CE > Router, one should use routing between the two transport layers. >=20 > Hemant > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Wed Mar 16 20:00:24 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41DA13A6A1F for ; Wed, 16 Mar 2011 20:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.866 X-Spam-Level: X-Spam-Status: No, score=-104.866 tagged_above=-999 required=5 tests=[AWL=1.133, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykR2CKK24OzV for ; Wed, 16 Mar 2011 20:00:23 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 2871F3A6A13 for ; Wed, 16 Mar 2011 20:00:23 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 7880CD96A1BA for ; Wed, 16 Mar 2011 20:01:50 -0700 (PDT) X-AuditID: 11807137-b7c3cae0000010f5-27-4d81799eeaa9 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay16.apple.com (Apple SCV relay) with SMTP id 1C.40.04341.E99718D4; Wed, 16 Mar 2011 20:01:50 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.32.65.102] (166-205-137-019.mobile.mymmode.com [166.205.137.19]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI600AGXLQY3Z50@elliott.apple.com> for v6ops@ietf.org; Wed, 16 Mar 2011 20:01:50 -0700 (PDT) References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30104A0F4@XMB-RCD-109.cisco.com> <9376DC69-9818-469C-9D14-8B18CA323E4C@cisco.com> In-reply-to: <9376DC69-9818-469C-9D14-8B18CA323E4C@cisco.com> Message-id: <13B2D344-55C8-4AFA-B91A-22E42D0A8D29@apple.com> X-Mailer: iPhone Mail (8F190) From: james woodyatt Date: Wed, 16 Mar 2011 20:01:39 -0700 To: Fred Baker X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 03:00:24 -0000 Why don't all of these argument apply equally to both ND-proxy forwarding and layer-3 forwarding? I see no technical distinction. In both cases, you have to strip the sub-IP header to forward across interfaces. In both cases you have link-MTU trouble to manage. --jhw (sent from my phone) On Mar 16, 2011, at 19:03, Fred Baker wrote: > > On Mar 16, 2011, at 6:48 PM, Hemant Singh (shemant) wrote: > >> >> >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of james woodyatt >> Sent: Tuesday, March 15, 2011 6:36 PM >> To: IPv6 Ops WG >> Subject: Re: [v6ops] I-D >> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >> >> >>> Would somebody please explain in clear technical detail why the obvious >> alternative, i.e. ND-proxy at the bastion between 802.1D and 802.15.4, >> is an unsatisfactory solution to the problem of not being >able to >> bridge between 802.1D and 802.15.4? > > Because you can't take a packet off an 802.3 LAN and drop it on an 802.15.4 LAN... > > Compare http://en.wikipedia.org/wiki/Ethernet_frame#Structure with age 45 of http://www.atmel.com/dyn/resources/prod_documents/doc5131.pdf > > And besides, 1518 octets doesn't fit very well in 127. > >> Indeed when one has two disparate transports with different MAC layers, >> one cannot bridge data between the two transports. Thus ND Proxy is one >> alternative that jumps to mind. See this text in the bis document. >> >> [LNDP-1: If the CE Router has only one /64 prefix to be used across >> multiple LAN interfaces and the CE Router supports any two LAN >> interfaces that cannot bridge data between them because the two >> interfaces have disparate MAC layers, then the CE Router MUST support >> Proxying Neighbor Advertisements as specified in Section 7.2.8 of >> [RFC4861].] >> >> However the bis document adds ND Proxy for only once specific case for >> legacy 3GPP networks where the operator could dole out only one /64 to >> the CE router. If a shorter than /64 prefix is assigned to the CE >> Router, one should use routing between the two transport layers. >> >> Hemant >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Wed Mar 16 21:54:55 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC063A69EC for ; Wed, 16 Mar 2011 21:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.199 X-Spam-Level: X-Spam-Status: No, score=-110.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKnnxFGnnUeD for ; Wed, 16 Mar 2011 21:54:53 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 33ECA3A6919 for ; Wed, 16 Mar 2011 21:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2586; q=dns/txt; s=iport; t=1300337780; x=1301547380; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=fNu3hn7e5e7tsXAQm1MJqAfCtovTJIuLVRH+Sr1GTwI=; b=QFrwXMK0QIxu/yjmhjJeSDv8DZ/JszWxRJKpYFmFMXk0n1lxDt0uxdaK EnzSE29qaCSdOWO6yOFfO5Kbo1HSRXPPPNP9/fQJnU+YJiGPkFcaUNY9T b50EfmeaGE5jMJesmYx2kOdZE6N+4WtYKGdW4uqhL0G647YG7AbjSseA4 s=; X-IronPort-AV: E=Sophos;i="4.63,197,1299456000"; d="scan'208";a="276905102" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 17 Mar 2011 04:56:20 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2H4tCBX027319; Thu, 17 Mar 2011 04:56:19 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Wed, 16 Mar 2011 21:56:19 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Wed, 16 Mar 2011 21:56:19 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <13B2D344-55C8-4AFA-B91A-22E42D0A8D29@apple.com> Date: Wed, 16 Mar 2011 21:56:18 -0700 Message-Id: <1A6A14DB-5996-4624-A116-8B29F6B3D0B1@cisco.com> References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30104A0F4@XMB-RCD-109.cisco.com> <9376DC69-9818-469C-9D14-8B18CA323E4C@cisco.com> <13B2D344-55C8-4AFA-B91A-22E42D0A8D29@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 04:54:55 -0000 That is a great analysis if you're routing. On Mar 16, 2011, at 8:01 PM, james woodyatt wrote: > Why don't all of these argument apply equally to both ND-proxy = forwarding and layer-3 forwarding? I see no technical distinction. >=20 > In both cases, you have to strip the sub-IP header to forward across = interfaces. In both cases you have link-MTU trouble to manage. >=20 > --jhw (sent from my phone) >=20 > On Mar 16, 2011, at 19:03, Fred Baker wrote: >=20 >>=20 >> On Mar 16, 2011, at 6:48 PM, Hemant Singh (shemant) wrote: >>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >>> Of james woodyatt >>> Sent: Tuesday, March 15, 2011 6:36 PM >>> To: IPv6 Ops WG >>> Subject: Re: [v6ops] I-D >>> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >>>=20 >>>=20 >>>> Would somebody please explain in clear technical detail why the = obvious >>> alternative, i.e. ND-proxy at the bastion between 802.1D and = 802.15.4, >>> is an unsatisfactory solution to the problem of not being >able to >>> bridge between 802.1D and 802.15.4? >>=20 >> Because you can't take a packet off an 802.3 LAN and drop it on an = 802.15.4 LAN... >>=20 >> Compare http://en.wikipedia.org/wiki/Ethernet_frame#Structure with = age 45 of http://www.atmel.com/dyn/resources/prod_documents/doc5131.pdf >>=20 >> And besides, 1518 octets doesn't fit very well in 127. >>=20 >>> Indeed when one has two disparate transports with different MAC = layers, >>> one cannot bridge data between the two transports. Thus ND Proxy is = one >>> alternative that jumps to mind. See this text in the bis document. >>>=20 >>> [LNDP-1: If the CE Router has only one /64 prefix to be used across >>> multiple LAN interfaces and the CE Router supports any two LAN >>> interfaces that cannot bridge data between them because the two >>> interfaces have disparate MAC layers, then the CE Router MUST = support >>> Proxying Neighbor Advertisements as specified in Section 7.2.8 of >>> [RFC4861].]=20 >>>=20 >>> However the bis document adds ND Proxy for only once specific case = for >>> legacy 3GPP networks where the operator could dole out only one /64 = to >>> the CE router. If a shorter than /64 prefix is assigned to the CE >>> Router, one should use routing between the two transport layers. >>>=20 >>> Hemant >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From shemant@cisco.com Thu Mar 17 07:00:04 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51613A69DF for ; Thu, 17 Mar 2011 07:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.795 X-Spam-Level: X-Spam-Status: No, score=-10.795 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa7zU4QRFtS0 for ; Thu, 17 Mar 2011 07:00:03 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D7BFA3A695B for ; Thu, 17 Mar 2011 07:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1192; q=dns/txt; s=iport; t=1300370492; x=1301580092; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=DIu0kmORl+w3ijMvmx5ZcHXarc4KbU5IKpYfq4zyLVE=; b=dfaR5AGMmdpJ7FprPTFiYPSNfzpBP7uJDTW/j2/+BgN3IIEQqyOel2+A BRoGbawAkEWBy3uM6BA8dCg7PbvV+KnGSDypa0nPGYvAZgyPP6e31ziE5 AE8rl9ce4dcA65507uLE7Q8LlFUrsAZDbIGqbE1/LToHSFhtRm8Ws/5Jr A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjABAPuwgU2tJXHA/2dsb2JhbACYHY0xd6d+nDOFYwSFL4sC X-IronPort-AV: E=Sophos;i="4.63,199,1299456000"; d="scan'208";a="415384440" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-1.cisco.com with ESMTP; 17 Mar 2011 14:01:30 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2HE1Ud8014053; Thu, 17 Mar 2011 14:01:30 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 09:01:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Mar 2011 09:01:26 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30104A1E5@XMB-RCD-109.cisco.com> In-Reply-To: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: AcvjYWpt88yDX3YWRailCI6V5O1bfQBSStYA References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> From: "Hemant Singh (shemant)" To: "james woodyatt" , "IPv6 Ops WG" X-OriginalArrivalTime: 17 Mar 2011 14:01:30.0294 (UTC) FILETIME=[D0BF7560:01CBE4AB] Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 14:00:04 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Tuesday, March 15, 2011 6:36 PM To: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt >Would somebody please explain in clear technical detail why the obvious alternative, i.e. ND-proxy at the bastion between 802.1D and 802.15.4, is an unsatisfactory solution to the problem of not being >able to bridge between 802.1D and 802.15.4? ND Proxy has one pitfall that routing does not. When ND Proxy proxies a ND control packet such as a multicast NS from one segment to another, the packet will be multicast to the other segment and thus a multicast flood occurs. In contrast, when the two segments are routed, each segment is a separate ND link-local domain and no flooding of multicast occurs from one segment to another. Note also, one recommends ND Proxy strictly for the case when one has one subnet prefix to use across two network segments. For Tom's use case, we have each of the two routers using ULA and/or GUA that are shorter than /64, and thus routing is a better solution. =20 Hemant From ggm@apnic.net Tue Mar 15 14:31:31 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0273A6EE0 for ; Tue, 15 Mar 2011 14:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.065 X-Spam-Level: * X-Spam-Status: No, score=1.065 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QUADMgLskrE for ; Tue, 15 Mar 2011 14:31:30 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 1D7CF3A6C81 for ; Tue, 15 Mar 2011 14:31:29 -0700 (PDT) Received: from [203.119.76.129] (unknown [203.119.76.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id F0F5DB66C9; Wed, 16 Mar 2011 07:32:50 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: <002001cbe356$ca9e3690$5fdaa3b0$@sturek@att.net> Date: Tue, 15 Mar 2011 14:32:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5B44B908-0652-4659-B841-F91A2EF97968@apnic.net> References: <20110305184502.18531.25548.idtracker@localhost><76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com><4D7E685A.80202@bogus.com><5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3010499AA@XMB-RCD-109.cisco.com> <000a01cbe353$5e325a20$1a970e60$@sturek@att.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3010499C9@XMB-RCD-109.cisco.com> <002001cbe356$ca9e3690$5fdaa3b0$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Thu, 17 Mar 2011 08:54:33 -0700 Cc: IPv6 Ops WG , "Simpson, Robby \(GE Energy Services\)" Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 21:31:32 -0000 On 15/03/2011, at 2:20 PM, Don Sturek wrote: >=20 > d. Define mechanism to stop propagation of ULA prefixes (which is > probably the start of a much more complex problem) As a point of information on this Don, Have a look at: http://tools.ietf.org/html/draft-michaelson-as112-ipv6-00 Which I will be presenting on in Prague/DNSOPS I hope. A *significant* daily volume of reverse-DNS is seen into ULA space. It = far outweighs global unicast IPv6 requests on the ip6.arpa service. The = query sources are widespread. This strongly suggests that a ULA = deployment is out there in the wild, causing some kind of service to = request 'who is that' into un-delegated reverse space. I understand you meant routing propagation, but I thought I'd point out = there are other kinds of information leak about 'local' addresses Oh, and the multicast ranges are in there too. Link and Site scoped = boundaries, the works. -George= From ayourtch@gmail.com Wed Mar 16 03:36:53 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5012F3A690E for ; Wed, 16 Mar 2011 03:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv7LR8diSKCI for ; Wed, 16 Mar 2011 03:36:52 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 018DE3A6924 for ; Wed, 16 Mar 2011 03:36:51 -0700 (PDT) Received: by iwl42 with SMTP id 42so1828850iwl.31 for ; Wed, 16 Mar 2011 03:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qo/snd2sI6QBG0A0xMSG/og0hRQzIla2UQDKZmt691w=; b=lkCBihhQ+SwzezA6GDxNKnAc+ntVjZVuzSH/y7sGyHaymymWW3tdRLi4ONRMhIsJDx Wsjyz4VIss+SnMonEFQOPTD45q6jjOjf5HEWhCbCNYG368YrIjMZldghvRUmB4tm1bL5 IoL1yZSEAuMIkj7KjMTsy58OQXoSGyEbilLf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xh3/MYNTACkEaMT7wpBS3+oNFwsbECuBQEA0dd2ICFesmv0k/6DzAqYL+7ze5H7kkj kmsHTGjGIo/weYs2jJGDURyq/wOlWRA2hP+N14j8rx/qnuKjhTqcl6VjwiwuRD7tOqK3 BwlBIgEHFIAwDgmQnjZQtnZX8dPihZrC4xAho= MIME-Version: 1.0 Received: by 10.43.51.67 with SMTP id vh3mr709214icb.379.1300271606903; Wed, 16 Mar 2011 03:33:26 -0700 (PDT) Received: by 10.42.163.2 with HTTP; Wed, 16 Mar 2011 03:33:26 -0700 (PDT) In-Reply-To: <1300270039.2217.9.camel@dab> References: <1300270039.2217.9.camel@dab> Date: Wed, 16 Mar 2011 11:33:26 +0100 Message-ID: From: Andrew Yourtchenko To: Javier Ubillos Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 17 Mar 2011 08:54:33 -0700 Cc: v6ops@ietf.org Subject: Re: [v6ops] HEX bar BoF in Prague poll X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 10:36:53 -0000 Yes, yesterday night we had 10 people for Tuesday vs. 9 for Wednesday, so we will have to go with that. I'll check on the location and let everyone know. cheers, andrew On Wed, Mar 16, 2011 at 11:07 AM, Javier Ubillos wrote: > Are we approaching any date decision? > // Javier > > On Mon, 2011-02-28 at 19:47 +0100, Andrew Yourtchenko wrote: >> Folks, >> >> we've had a couple of offline discussions that it might be a good idea to have a >> Bar BoF on happy eyeballs topics, and exchange the practical experiences. >> >> So, Happy Eyeballs Xperi(ences|ments) bar bof: >> >> http://doodle.com/arq27emxw45z92cd >> >> In the spirit of the algorithm, there are two choices - 29th and 31th. >> >> By adding some way to contact you back and ticking one or two of the tickboxes >> onthe URL above you are increasing one or both of the "P" values. >> >> The biggest value of P will win on the date. >> >> The place will TBD depending on the # of folks. The default is that it will be a >> bar (since it's a bar bof). >> >> The determination of the maximum of P will happen on 16th of March. >> >> cheers, >> andrew >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From jhw@apple.com Thu Mar 17 09:25:54 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939213A69DB for ; Thu, 17 Mar 2011 09:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwOF+KMBUlAh for ; Thu, 17 Mar 2011 09:25:53 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by core3.amsl.com (Postfix) with ESMTP id B92D53A6A8B for ; Thu, 17 Mar 2011 09:25:52 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LI7000GKMZT2BW0@localhost.apple.com> for v6ops@ietf.org; Thu, 17 Mar 2011 09:27:21 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-1d-4d823668476e Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with SMTP id CB.14.29082.866328D4; Thu, 17 Mar 2011 09:27:21 -0700 (PDT) Received: from 67-218-105-161.cust.layer42.net ([67.218.105.161]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI7005CYN1CO030@gertie.apple.com> for v6ops@ietf.org; Thu, 17 Mar 2011 09:27:20 -0700 (PDT) From: james woodyatt In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C30104A1E5@XMB-RCD-109.cisco.com> Date: Thu, 17 Mar 2011 09:27:12 -0700 Message-id: References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30104A1E5@XMB-RCD-109.cisco.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 16:25:54 -0000 On Mar 17, 2011, at 7:01 AM, Hemant Singh (shemant) wrote: > > ND Proxy has one pitfall that routing does not. When ND Proxy proxies a > ND control packet such as a multicast NS from one segment to another, > the packet will be multicast to the other segment and thus a multicast > flood occurs. In contrast, when the two segments are routed, each > segment is a separate ND link-local domain and no flooding of multicast > occurs from one segment to another. Note also, one recommends ND Proxy > strictly for the case when one has one subnet prefix to use across two > network segments. For Tom's use case, we have each of the two routers > using ULA and/or GUA that are shorter than /64, and thus routing is a > better solution. You seriously mean to trade the additional operational complexity of provisioning, configuring and administering a routed home internet to save the cost of multicasting ICMPv6 messages? This does not sound like a sensible trade to me. -- james woodyatt member of technical staff, core os networking From ichiroumakino@gmail.com Thu Mar 17 09:30:26 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6443A6A91 for ; Thu, 17 Mar 2011 09:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJQrhMh3nVFj for ; Thu, 17 Mar 2011 09:30:25 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 1EDD43A6A88 for ; Thu, 17 Mar 2011 09:30:24 -0700 (PDT) Received: by wyb42 with SMTP id 42so3214941wyb.31 for ; Thu, 17 Mar 2011 09:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=yJStGgDUW+tq9h17VjB3VHhhtBwqHBRw3CEINNeRmq8=; b=gOuL7LMYEtXd3/WwpHc9t/0Fu8aMPMjKqurxGc4wf/5edKiHYsdAYJoUW0G4KyRgp8 caedtr8+LzhTZWjwbuNyrAvTTKJmxELVqbDlzXsNi8Dga0/DsRwbG2+tq/EetTvIOOd6 4a1ifb08ROw0a14AUAs3xERNxBuOJSQwz8gjo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=L5VLO5AqrsFI0hIHEXpwkVxqIe6rhZ4QnNqSfFeHc1b3iW+A+hGhzFB5xQUspFHYAf mNRzTc+iDrNb8CqvqDVsT9XAnWVW+AtZdXZmPvzG/JWLroYPkSG2IKi3D0AdQJv8yRFH CNAibTJ71pKojauyD6HYxvrPA7V8rhfLB03yo= Received: by 10.216.81.69 with SMTP id l47mr1067521wee.78.1300379512405; Thu, 17 Mar 2011 09:31:52 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-109.cisco.com (dhcp-osl-vl300-64-103-53-109.cisco.com [64.103.53.109]) by mx.google.com with ESMTPS id t11sm1175906wes.41.2011.03.17.09.31.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2011 09:31:50 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Thu, 17 Mar 2011 17:31:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <90A03A0C-F973-4C75-BC35-2CDE1ED79442@employees.org> References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30104A1E5@XMB-RCD-109.cisco.com> To: james woodyatt X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 16:30:26 -0000 James, >> ND Proxy has one pitfall that routing does not. When ND Proxy = proxies a >> ND control packet such as a multicast NS from one segment to another, >> the packet will be multicast to the other segment and thus a = multicast >> flood occurs. In contrast, when the two segments are routed, each >> segment is a separate ND link-local domain and no flooding of = multicast >> occurs from one segment to another. Note also, one recommends ND = Proxy >> strictly for the case when one has one subnet prefix to use across = two >> network segments. For Tom's use case, we have each of the two = routers >> using ULA and/or GUA that are shorter than /64, and thus routing is a >> better solution. =20 >=20 > You seriously mean to trade the additional operational complexity of = provisioning, configuring and administering a routed home internet to = save the cost of multicasting ICMPv6 messages? is there anything implied by routing that requires operational = complexity? there are multiple proposals for zero configuration routing. as far as I = see there is no reason why we couldn't design a self configuring network = at layer 3. > This does not sound like a sensible trade to me. ND proxies fail as soon as you have a loop in the network. cheers, Ole= From jhw@apple.com Thu Mar 17 10:09:45 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019C13A6AC9 for ; Thu, 17 Mar 2011 10:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.42 X-Spam-Level: X-Spam-Status: No, score=-104.42 tagged_above=-999 required=5 tests=[AWL=-1.821, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJXfCGJF+F9E for ; Thu, 17 Mar 2011 10:09:44 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by core3.amsl.com (Postfix) with ESMTP id 4F4323A6A25 for ; Thu, 17 Mar 2011 10:09:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LI7000G4P04G6K0@localhost.apple.com> for v6ops@ietf.org; Thu, 17 Mar 2011 10:11:12 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-89-4d8240b09032 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with SMTP id BA.D1.29082.0B0428D4; Thu, 17 Mar 2011 10:11:12 -0700 (PDT) Received: from [17.193.13.64] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI7005PLP2OO040@gertie.apple.com> for v6ops@ietf.org; Thu, 17 Mar 2011 10:11:12 -0700 (PDT) From: james woodyatt In-reply-to: <90A03A0C-F973-4C75-BC35-2CDE1ED79442@employees.org> Date: Thu, 17 Mar 2011 10:11:12 -0700 Message-id: References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30104A1E5@XMB-RCD-109.cisco.com> <90A03A0C-F973-4C75-BC35-2CDE1ED79442@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1208) X-Brightmail-Tracker: AAAAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 17:09:45 -0000 On Mar 17, 2011, at 09:31 , Ole Troan wrote: > > there are multiple proposals for zero configuration routing. as far as I see there is no reason why we couldn't design a self configuring network at layer 3. RIPng is not zero-configuration. Neither is OSPF. Searching the Internet draft archives, I find this abandoned draft from over ten years ago, which is an example of the sort of proposal I'm expecting to see: That draft was Informational and never updated. I can't find any other references to zero-configuration routing anywhere in the Internet draft archives or the RFC series. If there are "multiple" proposals for zero-configuration residential network routing protocols, then I'd like to see them now, please. -- james woodyatt member of technical staff, core os networking From joelja@bogus.com Thu Mar 17 11:02:01 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E722A3A6AE8 for ; Thu, 17 Mar 2011 11:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptIHxBo7f6PG for ; Thu, 17 Mar 2011 11:02:01 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 8ABA13A6AE4 for ; Thu, 17 Mar 2011 11:02:00 -0700 (PDT) Received: from 23173jjaeggli.local (m480536d0.tmodns.net [208.54.5.72]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p2HI3MnX096379 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 17 Mar 2011 18:03:23 GMT (envelope-from joelja@bogus.com) Message-ID: <4D824CE5.7030300@bogus.com> Date: Thu, 17 Mar 2011 11:03:17 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: james woodyatt References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30104A1E5@XMB-RCD-109.cisco.com> <90A03A0C-F973-4C75-BC35-2CDE1ED79442@employees.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Thu, 17 Mar 2011 18:03:25 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:02:02 -0000 On 3/17/11 10:11 AM, james woodyatt wrote: > That draft was Informational and never updated. I can't find any > other references to zero-configuration routing anywhere in the > Internet draft archives or the RFC series. If there are "multiple" > proposals for zero-configuration residential network routing > protocols, then I'd like to see them now, please. We've got practical demonstrations of real-world use of residential devices running routing protocols in ipv4, to the they're far from universal. It doesn't take much, or indeed a new protocol to make say ripng work in a resdential enviroment, just some generic assumptions of the parameters that a ripng speaker would use. I don't see the outcome as more dire than honoring router advertisements or dhcpv6 responses. > > -- james woodyatt member of technical staff, core os > networking > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From ichiroumakino@gmail.com Thu Mar 17 11:05:03 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C9B3A6ADF for ; Thu, 17 Mar 2011 11:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMoYPmDu+vtU for ; Thu, 17 Mar 2011 11:05:02 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 5A6713A6A1C for ; Thu, 17 Mar 2011 11:05:02 -0700 (PDT) Received: by wwa36 with SMTP id 36so2599549wwa.13 for ; Thu, 17 Mar 2011 11:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=FAe56Yqf2yu6Qb0barAzjou6FZQSAe859fwM0FJDZ2A=; b=ffPqBUBV9XHTbpIgDGJ+P+eJBoqZkVOgwwP7R3hK12TyVQswiES03SwSY9Ck9Ki+em vvT0pYQmvhm0D5VdFbl9R0xDRvxK++TES0MhnxWqRrx0jCUgmDgbHI6QYd5bnZn15eeQ viTVOu8SbvbHhsfkmji+HZc/NYthKXRhFxkQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=LfgNYYKLtnxPfVdVlhqad1Cv+At4MHeW8DNGeaxtF0FDsLtKcmwbVRqpapBJ72Mxya egajcY04iKXXHh+1EqyvpnX4Qb5Ub3GGok6usgyO5vSEPnANcjLzFVfLsCgKG6hU9wtT j5Q5aDazhDclX4e13kZ9YMgTiEE4WXsfkgKzs= Received: by 10.216.16.100 with SMTP id g78mr62182weg.55.1300384957209; Thu, 17 Mar 2011 11:02:37 -0700 (PDT) Received: from ams3-vpn-dhcp5852.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id f30sm1220600wef.7.2011.03.17.11.02.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2011 11:02:36 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Thu, 17 Mar 2011 19:02:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7BAAD776-5151-4CC9-A341-6903913937C3@employees.org> References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30104A1E5@XMB-RCD-109.cisco.com> <90A03A0C-F973-4C75-BC35-2CDE1ED79442@employees.org> To: james woodyatt X-Mailer: Apple Mail (2.1082) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:05:03 -0000 James, >> there are multiple proposals for zero configuration routing. as far = as I see there is no reason why we couldn't design a self configuring = network at layer 3. >=20 > RIPng is not zero-configuration. Neither is OSPF. Searching the = Internet draft archives, I find this abandoned draft from over ten years = ago, which is an example of the sort of proposal I'm expecting to see: what do you expect needs to be configured in RIP? apart from the router-id, in OSPF? what is your plan to handle loops in your ND proxies network? there is a = reason that is experimental after all. > >=20 > That draft was Informational and never updated. I can't find any = other references to zero-configuration routing anywhere in the Internet = draft archives or the RFC series. If there are "multiple" proposals for = zero-configuration residential network routing protocols, then I'd like = to see them now, please. = http://datatracker.ietf.org/doc/search/?name=3Dzerouter&rfcs=3Don&activeDr= afts=3Don&oldDrafts=3Don http://datatracker.ietf.org/doc/draft-dimitri-zospf/ cheers, Ole From fred@cisco.com Thu Mar 17 11:11:36 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DBF03A6A0F for ; Thu, 17 Mar 2011 11:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPkZDJdSE7KY for ; Thu, 17 Mar 2011 11:11:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4E4543A6A1C for ; Thu, 17 Mar 2011 11:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3884; q=dns/txt; s=iport; t=1300385583; x=1301595183; h=mime-version:subject:from:date:cc:message-id:references: to:content-transfer-encoding; bh=IzBGdY1uJs0XwD6vcK5TqHTEjLNhwfJd6jt2U9UYhNc=; b=YgpvOxNnhZD2GLApbJ1seAkm8WM5VB3wTiVVwfwYPCAbEA69Y2c1pucY yYPtrsgwMC4uPL0NSNZkV7nUf1bfNUKBHU92J+uG+cZYBkEKwtEl35NS9 jV+J5qrDeeC68q1QtIiaACo5QLN7b8GZI4EgXW698JNt0BlQKgkQNR+J1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJXrgU2tJXG9/2dsb2JhbAClTnenLZw5hWMEhS+HL4NN X-IronPort-AV: E=Sophos;i="4.63,200,1299456000"; d="scan'208";a="415497872" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-1.cisco.com with ESMTP; 17 Mar 2011 18:13:03 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2HICvPp008138; Thu, 17 Mar 2011 18:13:02 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Thu, 17 Mar 2011 11:13:02 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Thu, 17 Mar 2011 11:13:02 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker Date: Thu, 17 Mar 2011 11:12:46 -0700 Message-Id: <8E5030F1-872F-41FC-99EB-5E7621AA7983@cisco.com> References: <0971CB8A-267A-42AC-80A3-C3D37D2B4004@cisco.com> To: james woodyatt X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:11:36 -0000 The OSPF implementation I wrote at ACC in 1991-1993 required at most two = configuration events: it had to be turned on, and subnets had to be = given addresses. The same was true of RIP. And the same is true of each = of the long list of competitors of yours that I noted a couple of days = ago that consider placing a routing protocol in a CPE router a market = requirement. I submit that a zero-manual-configuration version can be built if the = configuration is automated. That would not be a process this working = group specifies, but as you note it is not rocket science. A competent = engineer can figure out how to do it if it is deemed necessary. In the = single subnet case, it simply means defaulting to a well-defined = configuration; in the multi-subnet case, it requires implementation of = DHCP or something like it to allocate /64s in the network. I really don't think this conversation is going anywhere. Permit me to = be uncharacteristically blunt while wearing my working group chair hat.=20= Apple has designed a model for the residential network that assumes one = /64 subnet in the home. This shows up in mDNS, which uses a link-scope = multicast address as opposed to a site-scope multicast address, in your = vehemence against incorporating a routing protocol in the CPE = requirements, and in other places. It is as close as I can imagine to an = Apple corporate position, something we try to avoid in the IETF.=20 Tom Herbst has pointed out a need to route between a residential HAN and = the remainder of the residential network due to differences between the = LAN technologies. I have pointed out, months ago, use cases in which it = is useful to have separate networks for security reasons (his and her = corporate offices with corporate-specified security requirements) and = separating the A/V bandwidth from other LAN usage in the home. I pointed = out the other day that the use of routing in the home is far from a = Cisco-corporate position - every residential CPE vendor I could quickly = verify, with two exceptions (yours and another device that described = itself as a "modem"), implements routing - at least RIP and in some = cases OSPF - in their devices. I will not rule that you're out of order here - if you can justify your = position, the working group is listening. But I will warn you that you = need to think about your passion a little more carefully.=20 What we can do, and perhaps should do, is RECOMMEND that "IF a vendor = chooses to implement a routing protocol in a CPE device, it SHOULD = implement RIPng as described in RFC 2080, and MAY implement other = protocols". But the preponderance of the evidence, in use cases, in = discussion brought to the working group, and in surveyed equipment in = the field, suggests that routing is done in the home in today's IPv4 = networks, and something we can provide useful guidance on in = residential/SOHO IPv6 networks.=20 On Mar 17, 2011, at 10:11 AM, james woodyatt wrote: > On Mar 17, 2011, at 09:31 , Ole Troan wrote: >>=20 >> there are multiple proposals for zero configuration routing. as far = as I see there is no reason why we couldn't design a self configuring = network at layer 3. >=20 > RIPng is not zero-configuration. Neither is OSPF. Searching the = Internet draft archives, I find this abandoned draft from over ten years = ago, which is an example of the sort of proposal I'm expecting to see: >=20 > >=20 > That draft was Informational and never updated. I can't find any = other references to zero-configuration routing anywhere in the Internet = draft archives or the RFC series. If there are "multiple" proposals for = zero-configuration residential network routing protocols, then I'd like = to see them now, please. From shemant@cisco.com Thu Mar 17 11:17:44 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC6D3A6A22 for ; Thu, 17 Mar 2011 11:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxmrQXZd-jaH for ; Thu, 17 Mar 2011 11:17:43 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0A9FE3A6A04 for ; Thu, 17 Mar 2011 11:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2529; q=dns/txt; s=iport; t=1300385951; x=1301595551; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=D7Y+oowKe89Y52DmnUSh409OL2HAbu2fvzVpz+SA+j8=; b=kZd7ffN6lVBXvX1WgnSAoLa7i7WSe5fYcHj98iT0JsDTDg64R/cfV9ET SQoA6RLm56FyOkWWRjifFcfHEOOHgA0tnjM2lz+g5+9KXZPFr8AGYaJXu Tsi8HVxN7cXORGBuspsqJIUFABO9/fA4jZSnSpjU6JY7b6YDyABRNgsAn M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjABADftgU2tJV2c/2dsb2JhbACYHY0xd6c7nDmFYwSFL4sC X-IronPort-AV: E=Sophos;i="4.63,200,1299456000"; d="scan'208";a="277231005" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-4.cisco.com with ESMTP; 17 Mar 2011 18:18:25 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2HIINBg026249; Thu, 17 Mar 2011 18:18:24 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 13:18:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Mar 2011 13:18:22 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30104A427@XMB-RCD-109.cisco.com> In-Reply-To: <7BAAD776-5151-4CC9-A341-6903913937C3@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt Thread-Index: Acvkzhkp9OCPLbDpS6KuVjL0xdXULgAAHo3w References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C30104A1E5@XMB-RCD-109.cisco.com><90A03A0C-F973-4C75-BC35-2CDE1ED79442@employees.org> <7BAAD776-5151-4CC9-A341-6903913937C3@employees.org> From: "Hemant Singh (shemant)" To: "Ole Troan" , "james woodyatt" X-OriginalArrivalTime: 17 Mar 2011 18:18:24.0423 (UTC) FILETIME=[B448E370:01CBE4CF] Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:17:44 -0000 James, I and Ole provided clear technical reasons for using routing over ND Proxy for Tom's use case of the HAN network internetworking with the home network. Then you said routing is not automatically or easily configurable. Here is an example of RIPng I configured on my Cisco IPv6 ubr10000 router. The network interface of GigabitEthernet4/0/0 on my IPv6 router is already up and running with an IPv6 global address configured. This is all I have to do on the router to configure RIPng and then have the GigabitEthernet4/0/0 join the RIPng network. As you can see, the configuration below is totally automatable.=20 shark(config)#ipv6 router rip labripng shark(config-rtr)#redistribute connected=20 shark(config-rtr)#redistribute static=20 shark(config-rtr)#int g4/0/0 shark(config-if)#ipv6 rip rip enable shark(config-if)#end shark# *Mar 16 21:51:55.235: %SYS-5-CONFIG_I: Configured from console by console shark# Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Ole Troan Sent: Thursday, March 17, 2011 2:03 PM To: james woodyatt Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt James, >> there are multiple proposals for zero configuration routing. as far as I see there is no reason why we couldn't design a self configuring network at layer 3. >=20 > RIPng is not zero-configuration. Neither is OSPF. Searching the Internet draft archives, I find this abandoned draft from over ten years ago, which is an example of the sort of proposal I'm expecting to see: what do you expect needs to be configured in RIP? apart from the router-id, in OSPF? what is your plan to handle loops in your ND proxies network? there is a reason that is experimental after all. > >=20 > That draft was Informational and never updated. I can't find any other references to zero-configuration routing anywhere in the Internet draft archives or the RFC series. If there are "multiple" proposals for zero-configuration residential network routing protocols, then I'd like to see them now, please. http://datatracker.ietf.org/doc/search/?name=3Dzerouter&rfcs=3Don&activeD= raf ts=3Don&oldDrafts=3Don http://datatracker.ietf.org/doc/draft-dimitri-zospf/ cheers, Ole _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Thu Mar 17 11:29:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A810F3A6A20 for ; Thu, 17 Mar 2011 11:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.359 X-Spam-Level: X-Spam-Status: No, score=-104.359 tagged_above=-999 required=5 tests=[AWL=-1.760, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyjtgcbpTAq9 for ; Thu, 17 Mar 2011 11:29:24 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by core3.amsl.com (Postfix) with ESMTP id E40D93A6A10 for ; Thu, 17 Mar 2011 11:29:24 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LI7000S8SR1G6S0@localhost.apple.com> for v6ops@ietf.org; Thu, 17 Mar 2011 11:30:53 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-29-4d82535d0df1 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay14.apple.com (Apple SCV relay) with SMTP id D7.9D.20744.D53528D4; Thu, 17 Mar 2011 11:30:53 -0700 (PDT) Received: from [17.193.15.152] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI7006BYSRGKY50@elliott.apple.com> for v6ops@ietf.org; Thu, 17 Mar 2011 11:30:53 -0700 (PDT) From: james woodyatt In-reply-to: <7BAAD776-5151-4CC9-A341-6903913937C3@employees.org> Date: Thu, 17 Mar 2011 11:30:52 -0700 Message-id: References: <8F3C4279-034D-41CE-830D-79D7D8D29432@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30104A1E5@XMB-RCD-109.cisco.com> <90A03A0C-F973-4C75-BC35-2CDE1ED79442@employees.org> <7BAAD776-5151-4CC9-A341-6903913937C3@employees.org> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:29:25 -0000 On Mar 17, 2011, at 11:02 AM, Ole Troan wrote: > > what is your plan to handle loops in your ND proxies network? there is a reason that is experimental after all. I imagine that loop avoidance with ND-proxy would probably require an extension to ICMPv6 that implements a spanning-tree protocol. > [I wrote:] >> >> >> >> That draft was Informational and never updated. I can't find any other references to zero-configuration routing anywhere in the Internet draft archives or the RFC series. If there are "multiple" proposals for zero-configuration residential network routing protocols, then I'd like to see them now, please. > > http://datatracker.ietf.org/doc/search/?name=zerouter&rfcs=on&activeDrafts=on&oldDrafts=on > http://datatracker.ietf.org/doc/draft-dimitri-zospf/ That draft is newer. From 2002. Still, its DISCLAIMER reads as follows: This draft is a work in progress. Its purpose is to sketch a potential solution to the problem of router self-configuration and highlight some of the trade-offs. The hope is to gauge interest within the IETF community for solving the problem, and soliciting feedback and suggestions from the designers, implementers, and users of the protocols referred to within. The purpose of this draft is not to attempt to set in stone a complete solution to the problem. Criticism and feedback are welcome. All references to OSPF imply OSPFv3, unless stated otherwise. It was never updated after that. I was rather hoping to see, at minimum, a Standards Track draft already taken up as a working group item somewhere in the Routing area. -- james woodyatt member of technical staff, core os networking From fred@cisco.com Thu Mar 17 11:34:25 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6D323A6AEB for ; Thu, 17 Mar 2011 11:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.503 X-Spam-Level: X-Spam-Status: No, score=-110.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2bnF4Zl56H7 for ; Thu, 17 Mar 2011 11:34:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C84043A6AE3 for ; Thu, 17 Mar 2011 11:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1315; q=dns/txt; s=iport; t=1300386953; x=1301596553; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=QbT+4wEWzlTyFMLrzZ2ON10ECtc3Ric9ugaOaS8KTHA=; b=EWIpubMrHuQU0Icn9rsoqTrIYSQR8cskpv9mW3c05ZmamqNKIWMEtnph vEbjf0ltBWaMiRu7iFLt+7ePoXqyLF8bBx8mxAijAp+iIbI/xqzPrnGUE oV+gsQdN6W6RE0TzTiubZvHLfLknTW1+M/ieXcmgeCsCIogeIPD/g1hVn E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPfwgU2tJXG8/2dsb2JhbAClTnenS5w4hWMEhS+HL4NN X-IronPort-AV: E=Sophos;i="4.63,200,1299456000"; d="scan'208";a="668215524" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-6.cisco.com with ESMTP; 17 Mar 2011 18:35:52 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2HIZkqX009676; Thu, 17 Mar 2011 18:35:51 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Thu, 17 Mar 2011 11:35:51 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Thu, 17 Mar 2011 11:35:51 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <8E5030F1-872F-41FC-99EB-5E7621AA7983@cisco.com> Date: Thu, 17 Mar 2011 11:35:34 -0700 Message-Id: References: <0971CB8A-267A-42AC-80A3-C3D37D2B4004@cisco.com> <8E5030F1-872F-41FC-99EB-5E7621AA7983@cisco.com> To: james woodyatt X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:34:26 -0000 On Mar 17, 2011, at 11:12 AM, Fred Baker wrote: > Apple has designed a model for the residential network that assumes = one /64 subnet in the home.=20 In my note, I should have also pointed out that this is contrary to both = RFC 3177 and its successor. The IETF has recommended to the operational = community that - due to the use cases I mentioned - edge networks SHOULD = be given prefixes that facilitate internal routing among an adequate = number of subnets.=20 In my home network, I could get away with a /63 - I have two subnets at = the moment, my office and "everything else". However, if one presumes = his and her offices, a separate A/V network from the main LAN (in my = home, the wired backbone has 802.11 APs on it; one could also argue for = routing between the wired and wireless networks), and routing into the = HAN, the fingers on one hand are quickly exhausted. This and a personal = preference for nibble boundaries is behind the suggestion I have made = for residential networks, which is a /60 prefix (16 potential subnets) = to the home. More generally, I would expect a provider to offer /60, = /56, /52, and /48 prefixes to its customers as part of a suite of = services at varying price points. The one that the IETF has uniformly = recommended against is /64.= From jhw@apple.com Thu Mar 17 11:49:40 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6FD3A6A33 for ; Thu, 17 Mar 2011 11:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.302 X-Spam-Level: X-Spam-Status: No, score=-106.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAdKIHcidX8P for ; Thu, 17 Mar 2011 11:49:39 -0700 (PDT) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 942AC3A6966 for ; Thu, 17 Mar 2011 11:49:39 -0700 (PDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id D78C5D74AC0E for ; Thu, 17 Mar 2011 11:51:07 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-92-4d82581b0149 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay14.apple.com (Apple SCV relay) with SMTP id 05.35.20744.B18528D4; Thu, 17 Mar 2011 11:51:07 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [17.193.15.152] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI7005VUTP7O070@gertie.apple.com> for v6ops@ietf.org; Thu, 17 Mar 2011 11:51:07 -0700 (PDT) From: james woodyatt In-reply-to: <8E5030F1-872F-41FC-99EB-5E7621AA7983@cisco.com> Date: Thu, 17 Mar 2011 11:51:07 -0700 Message-id: References: <0971CB8A-267A-42AC-80A3-C3D37D2B4004@cisco.com> <8E5030F1-872F-41FC-99EB-5E7621AA7983@cisco.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 18:49:40 -0000 On Mar 17, 2011, at 11:12 AM, Fred Baker wrote: > > I really don't think this conversation is going anywhere. I'm sure I've made my position clear, and I seem to have persuaded no one that, if a routing protocol is to be recommended by this draft, then it MUST be a zero-configuration routing protocol. I will now quit my campaign, and leave the discussion of this draft to proceed without further contribution from me. -- james woodyatt member of technical staff, core os networking From brian.e.carpenter@gmail.com Thu Mar 17 12:27:16 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9953A3A69A7 for ; Thu, 17 Mar 2011 12:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103 X-Spam-Level: X-Spam-Status: No, score=-103 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZWwU9M1hfg0 for ; Thu, 17 Mar 2011 12:27:11 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 55C5C3A694D for ; Thu, 17 Mar 2011 12:27:10 -0700 (PDT) Received: by vxg33 with SMTP id 33so3445065vxg.31 for ; Thu, 17 Mar 2011 12:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wec2ssuS4pmUYcxJt/VlECTmbJLVe9fn3zPaCqO9hDo=; b=BXGbVVrPwd8xz7gIng+NuYdqVfJOJAV6EzXCNJQ+dYddpNJYfAGBGb6RPGLpJ3ObvW rBazutB43mVmxrod3LwZcuwJM9y1qdDtYi2bjSiHZepszP67MXaEGDYtEJnIB0tJpky0 TpuaY1rFU4+JPv7+ZvwCp7nRDV+E7s2ZT5gOI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=uxOo9R0DA/MsdcDr+b2ot+ZoPhgjtP7GVXg+VvWIfB8YSZJG7sSpBw0ezbIYtSbtv4 Z0+Rb/hzOId88BErrtqMeLmNQbcrcQXF34eki5KzMY8NB9U0G2lWyH136lSxaW/4ML2k 2CVwVal158+VwWjr+m+z8LGCYpocT1iTAixuM= Received: by 10.52.100.99 with SMTP id ex3mr175164vdb.313.1300390118413; Thu, 17 Mar 2011 12:28:38 -0700 (PDT) Received: from [10.1.1.4] ([121.98.190.33]) by mx.google.com with ESMTPS id c16sm760710vdu.31.2011.03.17.12.28.35 (version=SSLv3 cipher=OTHER); Thu, 17 Mar 2011 12:28:37 -0700 (PDT) Message-ID: <4D8260E2.2080600@gmail.com> Date: Fri, 18 Mar 2011 08:28:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> <4D7FE427.7000201@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30104A0ED@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30104A0ED@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 19:27:16 -0000 On 2011-03-17 14:38, Hemant Singh (shemant) wrote: > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Tuesday, March 15, 2011 6:12 PM > To: Hemant Singh (shemant) > Cc: Mikael Abrahamsson; IPv6 Ops WG > Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt > >> Why does that change the requirements for an IPv6 router? It's 100% >> standard IPv6 deployment. > > Agreed. However the design team is stepping gingerly. We first did a single IPv6 CE router in the home case which is the Basic IPv6 CE Router document in the RFC Editor Queue. The bis document covers a specific two-router case. It's only the fact that making all IPv6 features of the CE Router work with multihoming is the issue. For some features solutions don't even exist. So what does a document like ours propose for solution to use? Nothing, I think. Until we have clarity on the issues in draft-v6ops-multihoming-without-nat66 I don't see what we can say, beyond MUST support multiple prefixes and MAY support multiple WAN interfaces. Brian From swmike@swm.pp.se Thu Mar 17 12:41:57 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0279E3A6B07 for ; Thu, 17 Mar 2011 12:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQx34dYsBiAM for ; Thu, 17 Mar 2011 12:41:56 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id DC0D53A6B09 for ; Thu, 17 Mar 2011 12:41:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A2A589C; Thu, 17 Mar 2011 20:43:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A082C9A for ; Thu, 17 Mar 2011 20:43:17 +0100 (CET) Date: Thu, 17 Mar 2011 20:43:17 +0100 (CET) From: Mikael Abrahamsson To: IPv6 Ops WG In-Reply-To: <4D8260E2.2080600@gmail.com> Message-ID: References: <20110305184502.18531.25548.idtracker@localhost> <76C43B2A-FEE5-4328-AB05-A10C38B23B2C@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com> <4D7E685A.80202@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com> <4D7FE427.7000201@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30104A0ED@XMB-RCD-109.cisco.com> <4D8260E2.2080600@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 19:41:57 -0000 On Fri, 18 Mar 2011, Brian E Carpenter wrote: > Nothing, I think. Until we have clarity on the issues in > draft-v6ops-multihoming-without-nat66 I don't see what we can say, > beyond MUST support multiple prefixes and MAY support multiple WAN > interfaces. A long time ago I did exactly this scenario, moved an enterprise from PA-subnet1 from ISP1 to PA-subnet2 at ISP2 over one month period, and both needed to work, and both ISPs did uRPF checking. I normally say that whatever process came up with the answer "policy routing" (routing based on source IP address) you made a serious mistake way before you came to that answer, but in this case I think it's actually a valid mechanism. In the draft I didn't see any mention of it, was it considered and rejected? If one CPE has two WAN links and it gets two different PD prefixes, then it can send traffic to each one based on source IP address. How this would be discovered in a two WAN CPE router scenario I don't have an answer for. Whatever is done, it would also cause suboptimal routing for one of the prefixes since traffic would be routed via whatever default gw the host chose. The major problem I see is how the two different CPEs would discover each others PD prefixes so they can do source based routing. ... or am I totally out in my thinking, perhaps this has been discussed and rejected before? -- Mikael Abrahamsson email: swmike@swm.pp.se From fred@cisco.com Thu Mar 17 12:46:05 2011 Return-Path: X-Original-To: v6ops@core3.amsl.com Delivered-To: v6ops@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90083A69CF for ; Thu, 17 Mar 2011 12:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.506 X-Spam-Level: X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnJsMPxm78mh for ; Thu, 17 Mar 2011 12:45:58 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 671013A69A7 for ; Thu, 17 Mar 2011 12:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3178; q=dns/txt; s=iport; t=1300391246; x=1301600846; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=ZVk1InjhEefOgX1iCPRCa+N1hNtsOnkqLzuvnHARPr8=; b=k6/czrAcPbt497pz5UrE1riELPt1snYHOboPdLXXMz74+SVRi5Uf/QvF 4lKqty4Zngan4EExRnM2IigCW2Zz4H++MIpXOXh5clppauxTk1Bwbjp2m 99ZL/y5uUg7glvqUV1JTyRrpExize5QBBZIcKZnHw8kULxipTw9Dd8vRZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF4Bgk2tJV2Y/2dsb2JhbAClUHenNJw3hWMEhS+HL4NN X-IronPort-AV: E=Sophos;i="4.63,201,1299456000"; d="scan'208";a="279274047" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-3.cisco.com with ESMTP; 17 Mar 2011 19:47:26 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2HJlLdH024999; Thu, 17 Mar 2011 19:47:25 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Thu, 17 Mar 2011 12:47:25 -0700 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Thu, 17 Mar 2011 12:47:25 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: Date: Thu, 17 Mar 2011 12:47:04 -0700 Message-Id: <4393F10E-BE2D-484E-A834-582474AFB33E@cisco.com> References: <0971CB8A-267A-42AC-80A3-C3D37D2B4004@cisco.com> <8E5030F1-872F-41FC-99EB-5E7621AA7983@cisco.com> To: james woodyatt X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 19:46:05 -0000 On Mar 17, 2011, at 11:51 AM, james woodyatt wrote: > On Mar 17, 2011, at 11:12 AM, Fred Baker wrote: >>=20 >> I really don't think this conversation is going anywhere. >=20 > I'm sure I've made my position clear, and I seem to have persuaded no = one that, if a routing protocol is to be recommended by this draft, then = it MUST be a zero-configuration routing protocol. I will now quit my = campaign, and leave the discussion of this draft to proceed without = further contribution from me. Ack, and in residential networks in which (to pick one example) RIPng is = in use and there is exactly one LAN, that shouldn't be a problem. What = it means is: - deriving the LAN Subnet prefix from the RFC 3633 IA_PD - using the timing specifications (30 second inter-update interval, 180 = second dead interval) from RFC 2080 - periodically announcing a default route (2000::/3, which would be my = thought, or ::/0). In a network in which multiple LANs are present, and therefore multiple = subnets, there must be a means to assign subnets from the IA_PD. One = obvious approach is manual configuration; another requires a DHCP = implementation that asks the ISP-facing router for a /64 for each of the = other subnets. There are probably other approaches as well. The = recommendation of an approach would be the province of another working = group; we can ask either 6man or rtgwg for help with that.