From tjc@ecs.soton.ac.uk Fri Feb 1 00:54:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B27C21F8797 for ; Fri, 1 Feb 2013 00:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtFqui-LPVvB for ; Fri, 1 Feb 2013 00:54:05 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 51FDB21F8792 for ; Fri, 1 Feb 2013 00:54:05 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r118rski017130 for ; Fri, 1 Feb 2013 08:53:54 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r118rski017130 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1359708834; bh=UgQ4RGIHwtm0vm48etJ0a+tU6/Q=; h=From:Subject:Date:To:Mime-Version:References; b=uFbiuLuPZYDZMvHKAuJ0SwfdECy53NoJiYgqoppf/YN+cMjcaqL8Tm996DHf+IaOF SlC/qop3ZWvRFZuRIJFOy0V0+yc5PNKfTYN6Dk7QDRGbOJHXKVP9kExpNjyxLkYMWr hCN5RP99tDv/06M9n6IinpMOrMQ2Hu1yvnv2l84o= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p108rs0430602849p5 ret-id none; Fri, 01 Feb 2013 08:53:54 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r118rTdC029153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 1 Feb 2013 08:53:30 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_185329BA-595B-4879-93C7-4E84E1E272CC" Message-ID: Date: Fri, 1 Feb 2013 08:53:29 +0000 To: "homenet@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p108rs043060284900; tid=p108rs0430602849p5; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <6EC5F424-80A3-417D-9E69-1B9C1986F28D@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r118rski017130 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [homenet] draft-ietf-homenet-arch X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 08:54:06 -0000 --Apple-Mail=_185329BA-595B-4879-93C7-4E84E1E272CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, A new -07 version of draft-ietf-homenet-arch will be published over the = weekend to incorporate comments made to date on the current version. =20 If you have any specific (especially new) comments to make on that = current version, now would be a good time to do so. For the current version see: = http://tools.ietf.org/html/draft-ietf-homenet-arch-06 Hopefully the -07 can move quickly to WGLC. Tim --Apple-Mail=_185329BA-595B-4879-93C7-4E84E1E272CC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi,

A new -07 version of draft-ietf-homenet-arch will be published over the weekend to incorporate comments made to date on the current version.  

If you have any specific (especially new) comments to make on that current version, now would be a good time to do so.


Hopefully the -07 can move quickly to WGLC.

Tim


--Apple-Mail=_185329BA-595B-4879-93C7-4E84E1E272CC-- From internet-drafts@ietf.org Sun Feb 10 10:42:12 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AA721F84F6; Sun, 10 Feb 2013 10:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq0n6n-huNkM; Sun, 10 Feb 2013 10:42:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D69B21F869E; Sun, 10 Feb 2013 10:42:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130210184211.18176.81674.idtracker@ietfa.amsl.com> Date: Sun, 10 Feb 2013 10:42:11 -0800 Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-07.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 18:42:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Home Networking Working Group of the IETF. Title : Home Networking Architecture for IPv6 Author(s) : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-07.txt Pages : 46 Date : 2013-02-10 Abstract: This text describes evolving networking technology within increasingly large residential home networks. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-arch-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tjc@ecs.soton.ac.uk Mon Feb 11 04:20:28 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61AB21F88B4 for ; Mon, 11 Feb 2013 04:20:28 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCPzmxVVLacx for ; Mon, 11 Feb 2013 04:20:27 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id E2D8921F88B0 for ; Mon, 11 Feb 2013 04:20:25 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r1BCKKuE021898 for ; Mon, 11 Feb 2013 12:20:20 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r1BCKKuE021898 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1360585220; bh=wHj8iItXfhSBIewtVvdt1tyjfbs=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=dGhxY2Hb3e4CY4mLvZUbPAUAQGdusC9bSXmhCXT+urkbrSpvB7JVOBN4msnuQoiEv lmVt6eYr97SE9NJBvoLrUtDoY/1TEvtDn0JwZKl3AFEHU7or/IMqBNkuD78t+/Ky53 YHI/8NmVrZVkG+2QmDasNmrn7HrsxdOF8lqpmn4c= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p1ACKK0430662969KS ret-id none; Mon, 11 Feb 2013 12:20:20 +0000 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r1BCKIRG015203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 11 Feb 2013 12:20:18 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <20130210184211.18176.81674.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2013 12:20:31 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20130210184211.18176.81674.idtracker@ietfa.amsl.com> <60284C1A-0A34-4C8E-A39C-9540CA6A2F7E@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p1ACKK043066296900; tid=p1ACKK0430662969KS; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r1BCKKuE021898 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-07.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 12:20:28 -0000 Hi, Just a note to highlight that this new version is available. I suspect = the chairs will want to push this to WGLC as soon as possible. All = comments very welcome. If you wish to suggest changes, please give = specific text if possible. As a small note, the .xml version of the -07 was run through ispell, but = the .txt not refreshed from that, so there's a small number of typos = that will be corrected. More substantive comment is required at this = stage... Thanks, Tim On 10 Feb 2013, at 18:42, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Home Networking Working Group of the = IETF. >=20 > Title : Home Networking Architecture for IPv6 > Author(s) : Tim Chown > Jari Arkko > Anders Brandt > Ole Troan > Jason Weil > Filename : draft-ietf-homenet-arch-07.txt > Pages : 46 > Date : 2013-02-10 >=20 > Abstract: > This text describes evolving networking technology within > increasingly large residential home networks. The goal of this > document is to define a general architecture for IPv6-based home > networking, describing the associated principles, considerations and > requirements. The text briefly highlights specific implications of > the introduction of IPv6 for home networking, discusses the elements > of the architecture, and suggests how standard IPv6 mechanisms and > addressing can be employed in home networking. The architecture > describes the need for specific protocol extensions for certain > additional functionality. It is assumed that the IPv6 home network > is not actively managed, and runs as an IPv6-only or dual-stack > network. There are no recommendations in this text for the IPv4 = part > of the network. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-homenet-arch >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-homenet-arch-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-07 From Ray.Bellis@nominet.org.uk Mon Feb 11 05:13:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06E421F8B25 for ; Mon, 11 Feb 2013 05:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIM87BNisO3T for ; Mon, 11 Feb 2013 05:13:05 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id B68E721F8A1C for ; Mon, 11 Feb 2013 05:13:03 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=VCNw6brq+Ya0aYk/bI1KXLoeijZl//qq9uje/sx7D2Q7ORo8ySU/uZ+x dni1qWebajrMsc7jSqRoQYdESv7FFvdt+FugsoJFNhCU9fO+E3d+aJN5w brjbufwcIVp7TIA; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1360588384; x=1392124384; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20I-D=20Action:=20draft-ietf- homenet-arch-07.txt|Date:=20Mon,=2011=20Feb=202013=2013:1 3:00=20+0000|Message-ID:=20<53F00E5CD8B2E34C81C0C89EB0B4F E73104E93D7@wds-exc1.okna.nominet.org.uk>|To:=20"homenet@ ietf.org=20Group"=20|CC:=20Tim=20Chown =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<43358AF98624154FB3F455777E36DF3B@okna.nom inet.org.uk>|In-Reply-To:=20|References:=20<2 0130210184211.18176.81674.idtracker@ietfa.amsl.com>=0D=0A =20<60284C1A-0A34-4C8E-A39C-9540CA6A2F7E@ecs.soton.ac.uk> =0D=0A=20; bh=u+j9WZ7qPHHOts2/G+RAJLMPbT2d1ldEWYpYMsYALZI=; b=Jq5nHarD0uFrwFLiReNqWBx9IVVLmFFW7Motppcr7MgSl4En05JGkKbU iLc37SfMRqI6udyWJg+ro5J2fk3PVItSGAzG64VdCBgV4NlThuw6aqj9b W45t/GRUOxySpL7; X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; d="scan'208";a="46369690" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 11 Feb 2013 13:13:02 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Mon, 11 Feb 2013 13:13:02 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: [homenet] I-D Action: draft-ietf-homenet-arch-07.txt Thread-Index: AQHOB75dzSLxPPpCmECW55JL9APAk5h0lOGAgAAOqgA= Date: Mon, 11 Feb 2013 13:13:00 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE73104E93D7@wds-exc1.okna.nominet.org.uk> References: <20130210184211.18176.81674.idtracker@ietfa.amsl.com> <60284C1A-0A34-4C8E-A39C-9540CA6A2F7E@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <43358AF98624154FB3F455777E36DF3B@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tim Chown Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-07.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 13:13:06 -0000 On 11 Feb 2013, at 12:20, Tim Chown wrote: > Just a note to highlight that this new version is available. I suspect th= e chairs will want to push this to WGLC as soon as possible. Our plan is to issue the WGLC tomorrow. > All comments very welcome. If you wish to suggest changes, please give sp= ecific text if possible. Mark and I would like to reiterate the importance of this. We'd like to ge= t this document off to the IESG and have the WG start working on subsequent= work items as soon as we can. Ray From mark@townsley.net Tue Feb 12 06:57:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E798A21F8C09 for ; Tue, 12 Feb 2013 06:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H05w+UqvIX2q for ; Tue, 12 Feb 2013 06:57:52 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id F250121F8BFD for ; Tue, 12 Feb 2013 06:57:51 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ez12so216927wid.6 for ; Tue, 12 Feb 2013 06:57:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=r+mtpyua6DFY9K6BVcDS+Wp9MbxyyzIomIbKA+vbfU8=; b=d4ksjFWpsqcK+GbmM3qnbRbwGihnZmVrrncw/DDOxGAQIq9eJb1ZEDz/h4fX6XY31a fNZCcUvgjEd7d99UG12b4hXr9A47uNaPr99a4y2SLIpU/3x6mRCZzRs+5druWdfOcRaU NICv7xDqxxbFtQcPleHRRdlxh6TBZw9FUGpf2/bJ5XDGtZK26YlCr7CspgXyjhvEoZnb zTJl47Biz0wfZjRlkdTnRNRcbIQdZU4NzGMv1HD42QoeflcW6FO9gb+HqKl3kC89/vxK k58XmujFxObjWHPrkDX1LAVRDfk8B4svIBSp8Jui37/5xwbAV3brb0MHBCHvIIQjhSZ2 oshg== X-Received: by 10.181.12.103 with SMTP id ep7mr3859923wid.12.1360681069870; Tue, 12 Feb 2013 06:57:49 -0800 (PST) Received: from marks-mac-mini.home (AMontsouris-159-1-45-11.w90-46.abo.wanadoo.fr. [90.46.252.11]) by mx.google.com with ESMTPS id e12sm40178584wiw.5.2013.02.12.06.57.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 06:57:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Mark Townsley In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE73104E93D7@wds-exc1.okna.nominet.org.uk> Date: Tue, 12 Feb 2013 15:57:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <64A60865-5DDD-494E-A22C-03B3887FB914@townsley.net> References: <20130210184211.18176.81674.idtracker@ietfa.amsl.com> <60284C1A-0A34-4C8E-A39C-9540CA6A2F7E@ecs.soton.ac.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE73104E93D7@wds-exc1.okna.nominet.org.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkhCBl1E0ladv5oyBls2LIKYbd7UYD25tp9xc/cw4OVC6d1ETWDHc3XnHJGe5n+mxZ6f0YS Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-07.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 14:57:53 -0000 On Feb 11, 2013, at 2:13 PM, Ray Bellis wrote: >=20 > On 11 Feb 2013, at 12:20, Tim Chown wrote: >=20 >> Just a note to highlight that this new version is available. I = suspect the chairs will want to push this to WGLC as soon as possible. >=20 > Our plan is to issue the WGLC tomorrow. Which Ray and I just did.=20 >=20 >> All comments very welcome. If you wish to suggest changes, please = give specific text if possible. >=20 > Mark and I would like to reiterate the importance of this. We'd like = to get this document off to the IESG and have the WG start working on = subsequent work items as soon as we can. Just to be clear, "subsequent work items" includes things like what we = use as a routing protocol in the home, etc. The architecture document is a very important guide to what we will be = doing. It needs review and buy-in, even if its not the most "fun" part = of the work in terms of protocol tweaking and implementation.=20 - Mark >=20 > Ray >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From Ray.Bellis@nominet.org.uk Tue Feb 12 07:00:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D95A21F8EC1 for ; Tue, 12 Feb 2013 07:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSa7tAd3M2s8 for ; Tue, 12 Feb 2013 07:00:19 -0800 (PST) Received: from mx3.nominet.org.uk (mail.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id D937821F8EBE for ; Tue, 12 Feb 2013 07:00:17 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version; b=ZusIfDXABJy9062k8Z68ellXaIM7wl2FJx0RUqlw/LWfn6pKLnzSgibq ovP/09hWtahkf43hUbGF5OxLQA4r3GBJbBQpC7/XZpCeIX2E+vWlR11df XPja17WhNx32ye5; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1360681219; x=1392217219; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Working=20Group=20Last=20Call=20for=20draft-i etf-homenet-arch-07|Date:=20Tue,=2012=20Feb=202013=2015:0 0:14=20+0000|Message-ID:=20<53F00E5CD8B2E34C81C0C89EB0B4F E73104F65F1@wds-exc1.okna.nominet.org.uk>|To:=20"homenet@ ietf.org=20Group"=20|MIME-Version:=201. 0|Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<8425AF7C0B25594DB02D75448AB12614@okna.nom inet.org.uk>; bh=Wcrf9SS7JQALMQD3Ym2MWgpm1dhB8uIwNoUOK7r5I4g=; b=6rI7GFMzdTMI/6xnvhWcBEEsrYbnQ+oEi4tTmFjki2g7p5wMOuZ8EWMX TWhdw5BMZbea2ys+d6h8ZnnYVSP9m6NedmFrF8V3xeFTjIsi+m4wlvuqj Qj80mzyigW0pz0F; X-IronPort-AV: E=Sophos;i="4.84,651,1355097600"; d="scan'208";a="46396732" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 12 Feb 2013 15:00:16 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Tue, 12 Feb 2013 15:00:15 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Working Group Last Call for draft-ietf-homenet-arch-07 Thread-Index: AQHOCTGp+xL3UhaWxkipUvpddH8FUA== Date: Tue, 12 Feb 2013 15:00:14 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE73104F65F1@wds-exc1.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <8425AF7C0B25594DB02D75448AB12614@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:00:20 -0000 This email marks the commencement of Working Group Last Call for draft-ietf= -homenet-arch-07. The WGLC will end on Monday March 4th. Ray and Mark. From Ray.Bellis@nominet.org.uk Wed Feb 13 06:28:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8137521F875C for ; Wed, 13 Feb 2013 06:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yae6Uy366NDD for ; Wed, 13 Feb 2013 06:28:28 -0800 (PST) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id A261D21F8759 for ; Wed, 13 Feb 2013 06:28:27 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version; b=mDk1Ybo25Dy6mgSM5DLqQ5BNtE49Gigi/GiX2MSyzAoVuqAoTBZ1kfTS PpABftglGyS19RiGiQL8q9z7dY1Va5JtebdpkZDoViwoQuSiCMgzSDLtp LUxj6qJeYuDTK/m; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1360765708; x=1392301708; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Call=20for=20agenda=20items|Date:=20Wed,=2013 =20Feb=202013=2014:28:24=20+0000|Message-ID:=20<53F00E5CD 8B2E34C81C0C89EB0B4FE73104FED11@wds-exc1.okna.nominet.org .uk>|To:=20"homenet@ietf.org=20Group"=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted -printable|Content-ID:=20; bh=/QIfbFVBgUFEPZESco8fZGdud9CQ3vnSvKEsjgCBkNM=; b=NUYRreJilhfw/dPmRLlYLCGwMXfRPq+yFseeMuM0LA/FPkIljXgSPS1E XoRxhM0FobjbLn2McX2PeWtzng0NJwDGNc7EKIJLpLve/FMDZjyUuDA7A GYMpj+EFcKEqOll; X-IronPort-AV: E=Sophos;i="4.84,657,1355097600"; d="scan'208";a="38380018" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 13 Feb 2013 14:28:26 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 14:28:26 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Call for agenda items Thread-Index: AQHOCfZil0O3cSkBW0i1WV7po6D+Vw== Date: Wed, 13 Feb 2013 14:28:24 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE73104FED11@wds-exc1.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] Call for agenda items X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:28:29 -0000 As some of you will no doubt have noticed, we've been allocated a 2.5 hour = session which is currently scheduled for 09:00 EDT on Thursday March 14th. Mark and I are planning not to have to dedicate much of that slot to the Ar= chitecture Document which is now in WGLC. Therefore, if you have new work that you wish to present to the working gro= up, please let the chairs now as soon as possible. You can reach both of u= s at once by emailing . Please note that the -00 submission deadline is next Monday 18th, and the d= eadline for updates is Monday 25th. In the event that we get too many requests for agenda time, priority will b= e given to drafts and/or ideas that have generated active discussion on the= list. thanks, Ray and Mark. From mbehring@cisco.com Wed Feb 13 06:55:28 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C2721F85DF for ; Wed, 13 Feb 2013 06:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DV7DRGFFptbB for ; Wed, 13 Feb 2013 06:55:27 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4B74321F85D2 for ; Wed, 13 Feb 2013 06:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=464; q=dns/txt; s=iport; t=1360767327; x=1361976927; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=ppOuVhHvQf1z1brMF5txRBS9Mi+8/WgwxvKCBju+PCs=; b=bsSUuBViIiYvMAVq3rdqYQoxooITgYbb4eys+cATvkEEjWAc66A5fyTI 5hn2P67J3nzpiNbzPEBBzjkDFwaqCbKPK92xIJSJPObvZk01Dn4/JxIAA gQFb+C/4XqdvZPO2h+ydz/11s8Qzjh97sTCQRH4u5G3Iw/aXrtJ+LkOsy M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABmoG1GtJXG9/2dsb2JhbABEwGcWc4IhAQQ6PxIBKhRCJgEEDg2ICr5YkSJhA6Z3gwaCJw X-IronPort-AV: E=Sophos;i="4.84,657,1355097600"; d="scan'208";a="176621847" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 13 Feb 2013 14:55:27 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1DEtQSB001627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 14:55:26 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 08:55:26 -0600 From: "Michael Behringer (mbehring)" To: "homenet@ietf.org" Thread-Topic: Next steps for draft-behringer-homenet-trust-bootstrap? Thread-Index: Ac4J+Pw0eYMPjXgJRAe/w/WICK0LAQ== Date: Wed, 13 Feb 2013 14:55:25 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F6D5EF0@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-behringer-homenet-trust-bootstrap@tools.ietf.org" Subject: [homenet] Next steps for draft-behringer-homenet-trust-bootstrap? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:55:28 -0000 Homenet WG,=20 In Atlanta we presented draft-behringer-homenet-trust-bootstrap-00, which e= xplains (high level) how trust could be bootstrapped in a homenet environme= nt.=20 The feedback we got during the meeting was mostly positive; we would like t= o understand the next steps for this draft? We believe this is a useful app= roach, and would like to have the document accepted as a WG doc at some poi= nt.=20 What is the next step?=20 Michael From mcr@sandelman.ca Wed Feb 13 16:26:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E81721E80A3 for ; Wed, 13 Feb 2013 16:26:29 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3u-RYpE5Ser3 for ; Wed, 13 Feb 2013 16:26:28 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id CF6CC21E809B for ; Wed, 13 Feb 2013 16:26:24 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4309E20168 for ; Wed, 13 Feb 2013 19:32:46 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 850436376A; Wed, 13 Feb 2013 19:25:18 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 74971636C5 for ; Wed, 13 Feb 2013 19:25:18 -0500 (EST) From: Michael Richardson To: homenet@ietf.org X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: [homenet] WGLC comments on ietf-homenet-arch-07 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 00:26:29 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I have read the document from top to bottom. It isn't ready. I find that it needs more detailed editing. It makes quite a number of non-normative references to documents which might never be published. I realize that this won't keep the document from moving forward, but I wonder how useful those references will be in the future. I do not find that there is really any substantive content in the architecture document which I disagree with, or which is, at this point, at all controversal. I think that actually it should be more definitive, and in a number of places, significantly less repetitive. I think that we need two further revisions of this document. One to tighten things up, and a second to include text on a more clearly prescriptive notion of what the architecture is. =3D=3D=3D I found this part weird: [RFC6204] defines basic requirements for customer edge routers (CERs). The scope of this text is the internal homenet, and thus specific features on the CER are out of scope for this text. I'm confused by this. If the architecture and requirements set out by homenet can not apply to the CER, then how does any of this work? Maybe it needs to say: [RFC6204] defines basic requirements for customer edge routers (CERs). The scope of this text is the internal homenet, and thus specific features on the **WAN side of** the CER are out of scope for this text. (again in paragraph 2 of section 3) section 2.4: s/hoemnet/homenet/ Please change: In the case where LLNs are being set up in a new home/deployment, individual LLNs may, at least initially, each use their own /48 ULA prefix. to; In the case where LLNs are being set up in a new home/deployment (as early as during construction of the home), LLNs will need to use their own /48 ULA prefix. Depending upon circumstances beyond the scope of homenet, it may be impossible to renumber the ULA used by the LLN so routing between ULA /48s may be required. I'd sure like to UPPERCASE all of: As such, neither IPv6 NAT or NPTv6 is recommended for use in the homenet architecture. add to: As noted later in this text, if appropriate filtering is in place on the CER(s) **(as mandated by RFC6024 requirement S-2)***, a ULA source address may be taken as an indication of locally sourced traffic. (while it is clear that BCP38 says that packets with a ULA in the source field should not be sent upstream, it is unclear to me if BCP38 is sufficiently clear that ULA packets arriving on the WAN interface with ULA source addresses should also not be passed into the LAN.) I wonder if section 2.6 point 1 really belongs. "Ensuring there is a way to access concent in the IPv4 Internet." There is no particular reason this belongs in homenet or has to be implemented in the home network itself. There are advantages to doing it "onsite" if at least one of the CERs has IPv4 connectivity, otherwise two ISPs implementing DNS64 could confuse the homenet. 3.2.2, "Number of CERs" probably needs a [PCP] reference. I wonder if the diagrams should have the "Service Provider Network" label extended to "invade" into the CER: +-------+-------+ +-------+-------+ \ | Service | | Service | \ | Provider A | | Provider B | | Service | Router | | Router | | Provider +------+--------+ +-------+-------+ | network | | | | Customer | | | Internet connections | / | | / +------+--------+ +-------+-------+ / | IPv6 | | IPv6 | _ _ | Customer Edge | | Customer Edge | \ | Router 1 | | Router 2 | / +------+--------+ +-------+-------+ / 3.2.3: add to: In some cases IPv4 home networks may feature cascaded NATs, which could include cases where NAT routers are included within VMs, or where Internet connection sharing services are used.=20 to say: In some cases IPv4 home networks may feature cascaded NATs. End users are frequently unaware that they have created such networks as "home routers" and "home switches" are frequently confused. In addition, there are cases where NAT routers are included within Virtual Machine Hypervisors=20 (VMware, HyperV, Xen, KVM, VirtualBox, etc...), or where Internet connection sharing services have been enabled. This document applies to the such hidden NAT "routers" equally. 3.2.4 para 4 s/archiecture/architecture/ 3.2.4 (page 18): An example of such a 'simpler' approach has been documented in [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. Alternatively a flooding/routing protocol could potentially be used to pass information through the homenet, such that internal routers and ultimately end hosts could learn per-prefix configuration information, allowing better address selection decisions to be made. However, this would imply probably host and certainly router changes. Or another avenue is to introduce support for source routing throughout the homenet; while greatly improving the 'intelligence' of routing decisions within the homenet, such an approach would require relatively significant router changes. it seems that we are sitting on the fence here. I think that we need to be a bit more prescriptive here? I think we need a definition of walled garden. I'm not really happy with the IAB one that I was pointed to when some said that the IAB said that walled gardens were bad. 3.4.1:=20 However, if only a /64 is offered by the ISP, the homenet may be severely constrained or even unable to function. I think that we need to say something different in the text that follows. "if only a single /64 is received by a CER, then the homenet prefix distribution protocol MUST contain a way for that CER to signal that failure case" I think that this replaces the text: For those reasons it is recommended that DHCP-PD or OSPFv3 capable routers have the ability to issue a warning upon receipt of a /64 if required to assign further prefixes within the home network. Though some consideration needs to be given to how that should be presented to a typical home user. 3.4.1: There may be cases where local law means some ISPs are required to change IPv6 prefixes (current IPv4 addresses) for privacy reasons for their customers. In such cases it may be possible to avoid an instant 'flash' renumbering and plan a non-flag day renumbering as per RFC 4192. Maybe if we are going to talk about this at all, we should reference=20 the specific law, and understand if the privacy law wouldn't also be=20 violated if my host talked to facebook using prefix1::001 and prefix2::001 at the same time, so in fact flash renumbering, is in fact required in order to satisfy the supposed law... 3.4.2 says: The use of ULAs should be restricted to the homenet scope through filtering at the border(s) of the homenet, as described in RFC 6092. I'm confused. 6092 doesn't mention ULAs at all? 3.4.2 last paragraph talks about multiple ULAs again and electing a master a second time. Might be best to just say this once. 3.4.3 para 3 says it again. 3.5 I think we have consensus that homenet is deploying a routing protocol. I think that 3.5 "Any routed solution" should be a seperate section. Either the requirements in 3.x should have more headings, or we should have explicit "REQ-XX" things itemized so that later documents can better refer to this. I think that perhaps much of section 3.7 could be removed, and replaced with a some statements from the mdnsext BOF slides. Simply stating that "homenet requires site wide service discovery as described in X" should be an abundant clue to the IESG that mdnsext in some form needs to be chartered, and identifying gaps is part of our charter. 3.8.1 - I don't think that DiffServ has any utility for a homenet. The issue is for QoS is getting an upstream ISP to prioritize the relevant traffic onto the downstream link(s). If it's really about traffic entirely internal to the homenet, then maybe some well known DSCP will do, sure... The right architecture, if there is going to be one is the IntServ/DiffEdge model. http://datatracker.ietf.org/doc/draft-bernet-diffedge/ I know that diffserv talked a lot about such things,=20 and I'm told win2k can even do this, but to my knowedge nothing went forward as a specification. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAURwu7oqHRg3pndX9AQJluAP8Cn+BNMS+PMv73Z6tZhEaVaf9jHaK7hTQ 5iburAB3ZtJLfd0Ekx4DkR9HjS2ZnM4ezCQH5GQWtE4dTivzzm6lGFgs6ZPEGDK2 wCvau9GbxzlAOE/tw8Ur06CRiZMyBa25ElK60ZghPKGG+zRBJ+Ninizy6qjJ8EbN SqCV6jZxQ3g= =/pMg -----END PGP SIGNATURE----- --=-=-=-- From otroan@employees.org Mon Feb 18 13:04:50 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B04B21F8C3E for ; Mon, 18 Feb 2013 13:04:50 -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=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Se1OEO7vXs0 for ; Mon, 18 Feb 2013 13:04:49 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 1565821F86CE for ; Mon, 18 Feb 2013 13:04:49 -0800 (PST) Received: from dhcp-10-61-111-81.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id A0BCD5E62 for ; Mon, 18 Feb 2013 13:04:47 -0800 (PST) From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Feb 2013 22:04:45 +0100 References: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> To: "homenet@ietf.org Group" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 21:04:50 -0000 Begin forwarded message: > From: > Subject: New Version Notification for draft-troan-homenet-sadr-00.txt > Date: February 18, 2013 22:01:47 GMT+01:00 > To: > Cc: > Received: from mail.cisco.com [173.36.12.72] by = otroan-mac.getinternet.no with POP3 (fetchmail-6.3.20) for = (single-drop); Mon, 18 Feb 2013 22:02:13 +0100 (CET) > Received: from rcdn-iport-6.cisco.com (173.37.86.77) by mail.cisco.com = (173.36.12.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 = Feb 2013 15:01:50 -0600 > Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by = rcdn-iport-6.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +0000 > Received: from rcdn-inbound-i.cisco.com (rcdn-inbound-i.cisco.com = [72.163.7.178]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id = r1IL1ixR029679 for ; Mon, 18 Feb 2013 21:01:49 GMT > Received: from mail.ietf.org ([64.170.98.30]) by = rcdn-inbound-i.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +0000 > Received: from localhost (localhost [127.0.0.1]) by = ietfa.amsl.com (Postfix) with ESMTP id CA4D221F8C03; Mon, 18 Feb 2013 = 13:01:48 -0800 (PST) > Received: from mail.ietf.org ([64.170.98.30]) by localhost = (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id = IlwPsnRC5mQw; Mon, 18 Feb 2013 13:01:48 -0800 (PST) > Received: from ietfa.amsl.com (localhost [127.0.0.1]) by = ietfa.amsl.com (Postfix) with ESMTP id EA73121F8C56; Mon, 18 Feb 2013 = 13:01:47 -0800 (PST) > Authentication-Results: rcdn-inbound-i.cisco.com; dkim=3Dneutral = (message not signed) header.i=3Dnone > X-From-Outside-Cisco: 64.170.98.30 > X-Ironport-Anti-Spam-Filtered: true > X-Ironport-Anti-Spam-Result: = Ak0BAE6WIlFAqmIemWdsb2JhbABEhkmoGgGRP4EFFg4BAQEBAQgLCwcUJ4JJVAI1AiYCSTKICQ= yuZJIogSONfxUdgheBEwOIZ41EAYEdkmM > X-Ironport-Av: E=3DSophos;i=3D"4.84,690,1355097600"; = d=3D"scan'208";a=3D"89740088" > X-Virus-Scanned: amavisd-new at amsl.com > Content-Type: text/plain; charset=3D"utf-8" > Content-Transfer-Encoding: quoted-printable > X-Test-Idtracker: no > X-Ietf-Idtracker: 4.40 > Message-Id: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> > Return-Path: internet-drafts@ietf.org > X-Ms-Exchange-Organization-Authsource: xhc-aln-x07.cisco.com > X-Ms-Exchange-Organization-Authas: Internal > X-Ms-Exchange-Organization-Authmechanism: 10 > Mime-Version: 1.0 >=20 >=20 > A new version of I-D, draft-troan-homenet-sadr-00.txt > has been successfully submitted by Ole Troan and posted to the > IETF repository. >=20 > Filename: draft-troan-homenet-sadr > Revision: 00 > Title: IPv6 Multihoming with Source Address Dependent = Routing (SADR) > Creation date: 2013-02-18 > Group: Individual Submission > Number of pages: 7 > URL: = http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt > Status: = http://datatracker.ietf.org/doc/draft-troan-homenet-sadr > Htmlized: = http://tools.ietf.org/html/draft-troan-homenet-sadr-00 >=20 >=20 > Abstract: > A multihomed network using provider aggregatable addresses must send > the packet out the right path to avoid violating the provider's > ingress filtering. This memo suggests a mechanism called Source > Address Dependent Routing to solve that problem. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From equinox@diac24.net Mon Feb 18 20:01:16 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8F721F8C2F for ; Mon, 18 Feb 2013 20:01:16 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crjn7YrlbJaz for ; Mon, 18 Feb 2013 20:01:15 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DE521F8B88 for ; Mon, 18 Feb 2013 20:01:15 -0800 (PST) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2::]) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U7eOF-0003Dg-0B; Tue, 19 Feb 2013 05:01:11 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80) (envelope-from ) id 1U7eO0-009JTG-Jl; Tue, 19 Feb 2013 05:01:00 +0100 Date: Tue, 19 Feb 2013 05:00:56 +0100 From: David Lamparter To: Ole Troan , Lorenzo Colitti Message-ID: <20130219040056.GM903228@jupiter.n2.diac24.net> References: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 04:01:16 -0000 Hi Ole, Hi Lorenzo, nice to see this moving forward! Comments below with section copy/paste. On Mon, Feb 18, 2013 at 10:04:45PM +0100, Ole Troan wrote: > > Subject: New Version Notification for draft-troan-homenet-sadr-00.txt [...] > > Filename: draft-troan-homenet-sadr > > Revision: 00 > > Title: IPv6 Multihoming with Source Address Dependent Routing (SADR) > > Creation date: 2013-02-18 > > Group: Individual Submission > > Number of pages: 7 > > URL: http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt > > Status: http://datatracker.ietf.org/doc/draft-troan-homenet-sadr > > Htmlized: http://tools.ietf.org/html/draft-troan-homenet-sadr-00 > 4. Using SADR for multihoming > > SADR is similar to policy based routing. This memo proposes a simple > extension to the destination based longest match algorithm to > constrain it to source address. > > In order to support ingress filtering by upstream networks, the > network MUST treat external routes specially. Ingress filtering MAY > also be used internally, by installing (S,D) routes for locally > assigned prefixes, where the source prefix would be the aggregatable > prefix. If no ingress filtering is performed inside the network, > then normal non-source constrained forwarding is used. The last sentence seems to imply that, unless we have ingress filtering on Internal Routers, they don't use SADR forwarding. This doesn't seem correct, shouldn't internal routers always use SADR to reach the correct border router? There is probably just a "for local networks" missing before the last full stop. > 6.2. Simplified SADR in home networks (In general, I'm not sure this simplified variant is a good idea... but I don't have an opinion yet at this point.) > In a home network using a dynamic prefix assignment mechanism such as > [I-D.arkko-homenet-prefix-assignment] it may be known that a > particular Border Router is announcing both an External Route and a > Usable Prefix (for example, if the same router ID is announcing > both). In this case, interior routers may assume that the Acceptable > Source Prefix of the External Route announced by that Border Router > is in fact the Usable Prefix announced by that Border Router. "the" sounds like a Border Router will only ever announce one such Usable Prefix. Thinking of DSL/Cable routers with an USB UMTS/LTE dongle, this isn't sufficient. > An internal router when receiving a AS-External LSA route will > install that in the routing table as normal. When the internal > router receives a usable prefix as part of prefix assignment, the > router shall add source constrained entries to all the AS-External > routes received from the same border router (matching router-ID). To address aforementioned issue, this should probably read: An internal router when receiving a AS-External LSA route will install that in the routing table as normal. When the internal router receives one or more usable prefixes as part of prefix assignment, the router shall add source constrained entries to all the AS-External routes received from the same border router (matching router-ID), for each of the usable prefixes. (Wording in arkko-homenet-prefix-assignment was changed from "usable prefix" to "aggregated prefix" by the way) > Routes that are not associated with a border router or are not AS- > External do not have source constrained paths. > > The routing protocol requirements for simplified SADR in the home > network are: > > 1. Routing protocol must flood all information to all routers in the > home network. (Single area). > > 2. Prefix assignment and unicast routing must be done in the same > protocol. > > 3. A router must be uniquely identified (router-id) so that router > advertisements and prefix assignment can be tied together 4. All routers on the homenet MUST support simplified SADR routing. If 4. is not given, this scenario will lead to a loop: All links assumed at equal cost, r2 does not support simplified SADR, R1,R3,R4 do. ISP_A, pfx_A ::/0 ISP_B, pfx_B, ::/0 | | R1 ------ r2 ------ R3 ------ R4 | Host Host now selects an address from pfx_B to reach some site on the internet. R1 forwards to r2 because the ::/0 from R4 is more specific on the source. r2 forwards back to R1 because it didn't consider source specific-ness and just went by lower cost... In particular, as long as R4 doesn't advertise "full" SADR LSAs, this will also break if r2 implements "full" SADR, but not the simplified variant. Cheers, David From otroan@employees.org Mon Feb 18 22:15:19 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BE821F8D12 for ; Mon, 18 Feb 2013 22:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.527 X-Spam-Level: X-Spam-Status: No, score=-10.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uRJybRDBiOr for ; Mon, 18 Feb 2013 22:15:17 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id BC57321F8B37 for ; Mon, 18 Feb 2013 22:15:16 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPsWI1GQ/khM/2dsb2JhbABEwDOBBRZzgh8BAQEDATo9AgULCw4JAS5PCAYciAMGDLE5kAKOezMHgl9hA5JthFyPO4MI X-IronPort-AV: E=Sophos;i="4.84,692,1355097600"; d="scan'208";a="11875369" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 19 Feb 2013 06:15:14 +0000 Received: from dhcp-10-61-111-162.cisco.com (dhcp-10-61-111-162.cisco.com [10.61.111.162]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1J6FEse011337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2013 06:15:14 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <20130219040056.GM903228@jupiter.n2.diac24.net> Date: Tue, 19 Feb 2013 07:15:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> <20130219040056.GM903228@jupiter.n2.diac24.net> To: David Lamparter X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 06:15:19 -0000 David, thanks for the thorough comments. > nice to see this moving forward! Comments below with section > copy/paste. >=20 > On Mon, Feb 18, 2013 at 10:04:45PM +0100, Ole Troan wrote: >>> Subject: New Version Notification for = draft-troan-homenet-sadr-00.txt > [...] >>> Filename: draft-troan-homenet-sadr >>> Revision: 00 >>> Title: IPv6 Multihoming with Source Address Dependent = Routing (SADR) >>> Creation date: 2013-02-18 >>> Group: Individual Submission >>> Number of pages: 7 >>> URL: = http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt >>> Status: = http://datatracker.ietf.org/doc/draft-troan-homenet-sadr >>> Htmlized: = http://tools.ietf.org/html/draft-troan-homenet-sadr-00 >=20 >> 4. Using SADR for multihoming >>=20 >> SADR is similar to policy based routing. This memo proposes a = simple >> extension to the destination based longest match algorithm to >> constrain it to source address. >>=20 >> In order to support ingress filtering by upstream networks, the >> network MUST treat external routes specially. Ingress filtering = MAY >> also be used internally, by installing (S,D) routes for locally >> assigned prefixes, where the source prefix would be the = aggregatable >> prefix. If no ingress filtering is performed inside the network, >> then normal non-source constrained forwarding is used. >=20 > The last sentence seems to imply that, unless we have ingress = filtering > on Internal Routers, they don't use SADR forwarding. This doesn't = seem > correct, shouldn't internal routers always use SADR to reach the > correct border router? There is probably just a "for local networks" > missing before the last full stop. yes, let me fix that. >> 6.2. Simplified SADR in home networks >=20 > (In general, I'm not sure this simplified variant is a good idea... = but > I don't have an opinion yet at this point.) yes, it is a hack. it would allows us to proceed while waiting for SADR = support in routing protocols though. >> In a home network using a dynamic prefix assignment mechanism such = as >> [I-D.arkko-homenet-prefix-assignment] it may be known that a >> particular Border Router is announcing both an External Route and a >> Usable Prefix (for example, if the same router ID is announcing >> both). In this case, interior routers may assume that the = Acceptable >> Source Prefix of the External Route announced by that Border Router >> is in fact the Usable Prefix announced by that Border Router. >=20 > "the" sounds like a Border Router will only ever announce one such = Usable > Prefix. Thinking of DSL/Cable routers with an USB UMTS/LTE dongle, = this > isn't sufficient. >=20 >> An internal router when receiving a AS-External LSA route will >> install that in the routing table as normal. When the internal >> router receives a usable prefix as part of prefix assignment, the >> router shall add source constrained entries to all the AS-External >> routes received from the same border router (matching router-ID). >=20 > To address aforementioned issue, this should probably read: >=20 > An internal router when receiving a AS-External LSA route will > install that in the routing table as normal. When the internal > router receives one or more usable prefixes as part of prefix > assignment, the router shall add source constrained entries to all > the AS-External routes received from the same border router > (matching router-ID), for each of the usable prefixes. yes. > (Wording in arkko-homenet-prefix-assignment was changed from "usable > prefix" to "aggregated prefix" by the way) >=20 >> Routes that are not associated with a border router or are not AS- >> External do not have source constrained paths. >>=20 >> The routing protocol requirements for simplified SADR in the home >> network are: >>=20 >> 1. Routing protocol must flood all information to all routers in = the >> home network. (Single area). >>=20 >> 2. Prefix assignment and unicast routing must be done in the same >> protocol. >>=20 >> 3. A router must be uniquely identified (router-id) so that router >> advertisements and prefix assignment can be tied together >=20 > 4. All routers on the homenet MUST support simplified SADR routing. I suppose that requirement applies generally, not only to the simplified = variant. > If 4. is not given, this scenario will lead to a loop: > All links assumed at equal cost, r2 does not support simplified SADR, > R1,R3,R4 do. >=20 > ISP_A, pfx_A ::/0 ISP_B, pfx_B, ::/0 > | | > R1 ------ r2 ------ R3 ------ R4 > | > Host >=20 > Host now selects an address from pfx_B to reach some site on the > internet. R1 forwards to r2 because the ::/0 from R4 is more specific > on the source. r2 forwards back to R1 because it didn't consider = source > specific-ness and just went by lower cost... >=20 > In particular, as long as R4 doesn't advertise "full" SADR LSAs, this > will also break if r2 implements "full" SADR, but not the simplified > variant. yes, absolutely. cheers, Ole= From v6ops@globis.net Tue Feb 19 23:52:13 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705F521F882D for ; Tue, 19 Feb 2013 23:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xfc3ucEHkt1n for ; Tue, 19 Feb 2013 23:52:12 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id ECD3E21F87CC for ; Tue, 19 Feb 2013 23:52:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id CF7C68700F2; Wed, 20 Feb 2013 08:46:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzhVDFlsJchQ; Wed, 20 Feb 2013 08:46:33 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 3C76287012A; Wed, 20 Feb 2013 08:46:33 +0100 (CET) Message-ID: <51247F52.9070000@globis.net> Date: Wed, 20 Feb 2013 08:46:26 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Ole Troan , lorenzo@google.com References: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 07:52:13 -0000 I have read this draft and find it useful. > A routing entry may have both (S, D) paths and (*, D) paths. The longest match wins Section 5 seems to suggest SADR is just a tie breaker applied to the subset of equal length D routes, but I think you probably should be more specific on the phrase "longest match" in this sentence, as there are 2 length comparisons (one on D and one on S) Section 6.2. During autoconfig, if the prefix is delegated to other Homenet routers on a hop by hop basis, the Homenet router receiving a new prefix could indeed install a default SADR route for (parent_prefix/x,0:/0) -> the upstream delegating router. So in this case your requirement 2 to strongly couple autoconfiguration and routing would not seem onerous. But alternatively, if the delegation of prefixes within Homenet occurs via a mechanism like DHCP PD, the receiving router could instead install a default SADR route (parent_prefix/x,0:/0) -> Homenet BR DHCP PD source address, and then recurse the standard unicast routing table to find the appropriate next hop toward the Homenet BR. This is a trick that works very well in BGP networks (with next BGP hop being a software/loopback interface of the AS egress router that is always up and stable, combined with an IGP containing just the loopback addresses of the BGP speaking AS egress routers) In which case there's no requirement for a hard link between the routing protocol and the prefix autoconfiguration mechanism, and thus no requirement to update the IGP to carry SADR routes, which I think is potentially a big win. regards, RayH Ole Troan wrote: > Begin forwarded message: > >> From: >> Subject: New Version Notification for draft-troan-homenet-sadr-00.txt >> Date: February 18, 2013 22:01:47 GMT+01:00 >> To: >> Cc: >> Received: from mail.cisco.com [173.36.12.72] by otroan-mac.getinternet.no with POP3 (fetchmail-6.3.20) for (single-drop); Mon, 18 Feb 2013 22:02:13 +0100 (CET) >> Received: from rcdn-iport-6.cisco.com (173.37.86.77) by mail.cisco.com (173.36.12.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 Feb 2013 15:01:50 -0600 >> Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +0000 >> Received: from rcdn-inbound-i.cisco.com (rcdn-inbound-i.cisco.com [72.163.7.178]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1IL1ixR029679 for ; Mon, 18 Feb 2013 21:01:49 GMT >> Received: from mail.ietf.org ([64.170.98.30]) by rcdn-inbound-i.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +0000 >> Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4D221F8C03; Mon, 18 Feb 2013 13:01:48 -0800 (PST) >> Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlwPsnRC5mQw; Mon, 18 Feb 2013 13:01:48 -0800 (PST) >> Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA73121F8C56; Mon, 18 Feb 2013 13:01:47 -0800 (PST) >> Authentication-Results: rcdn-inbound-i.cisco.com; dkim=utral (message not signed) header.i=none >> X-From-Outside-Cisco: 64.170.98.30 >> X-Ironport-Anti-Spam-Filtered: true >> X-Ironport-Anti-Spam-Result: Ak0BAE6WIlFAqmIemWdsb2JhbABEhkmoGgGRP4EFFg4BAQEBAQgLCwcUJ4JJVAI1AiYCSTKICQyuZJIogSONfxUdgheBEwOIZ41EAYEdkmM >> X-Ironport-Av: E=phos;i="4.84,690,1355097600"; d="scan'208";a="89740088" >> X-Virus-Scanned: amavisd-new at amsl.com >> Content-Type: text/plain; charset=tf-8" >> Content-Transfer-Encoding: quoted-printable >> X-Test-Idtracker: no >> X-Ietf-Idtracker: 4.40 >> Message-Id: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> >> Return-Path: internet-drafts@ietf.org >> X-Ms-Exchange-Organization-Authsource: xhc-aln-x07.cisco.com >> X-Ms-Exchange-Organization-Authas: Internal >> X-Ms-Exchange-Organization-Authmechanism: 10 >> Mime-Version: 1.0 >> >> >> A new version of I-D, draft-troan-homenet-sadr-00.txt >> has been successfully submitted by Ole Troan and posted to the >> IETF repository. >> >> Filename: draft-troan-homenet-sadr >> Revision: 00 >> Title: IPv6 Multihoming with Source Address Dependent Routing (SADR) >> Creation date: 2013-02-18 >> Group: Individual Submission >> Number of pages: 7 >> URL: http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt >> Status: http://datatracker.ietf.org/doc/draft-troan-homenet-sadr >> Htmlized: http://tools.ietf.org/html/draft-troan-homenet-sadr-00 >> >> >> Abstract: >> A multihomed network using provider aggregatable addresses must send >> the packet out the right path to avoid violating the provider's >> ingress filtering. This memo suggests a mechanism called Source >> Address Dependent Routing to solve that problem. >> >> >> >> >> The IETF Secretariat >> > > From otroan@employees.org Wed Feb 20 00:59:41 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485D521F8750 for ; Wed, 20 Feb 2013 00:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.529 X-Spam-Level: X-Spam-Status: No, score=-10.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofnwBONvY3+r for ; Wed, 20 Feb 2013 00:59:40 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7B11B21F873B for ; Wed, 20 Feb 2013 00:59:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH6PJFGQ/khR/2dsb2JhbAA7CsBUfxZzgh8BAQEDAScTPQIFCwsOOFcGMYduBr9pjUOBGDMHgl9hA6cDgwg X-IronPort-AV: E=Sophos;i="4.84,699,1355097600"; d="scan'208";a="80568335" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 20 Feb 2013 08:59:39 +0000 Received: from dhcp-lys02-vla252-10-147-116-40.cisco.com (dhcp-lys02-vla252-10-147-116-40.cisco.com [10.147.116.40]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1K8xc7r026022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 08:59:39 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <51247F52.9070000@globis.net> Date: Wed, 20 Feb 2013 09:59:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0BB080A0-2DAC-403C-B99D-627207F080E5@employees.org> References: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> <51247F52.9070000@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , lorenzo@google.com Subject: Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 08:59:41 -0000 Ray, > I have read this draft and find it useful. >=20 >> A routing entry may have both (S, D) paths and (*, D) paths. The > longest match wins >=20 > Section 5 seems to suggest SADR is just a tie breaker applied to the > subset of equal length D routes, but I think you probably should be = more > specific on the phrase "longest match" in this sentence, as there are = 2 > length comparisons (one on D and one on S) yes, right now we say: "First a longest match lookup is done in the routing table for the destination address, then for the resulting set a longest matching lookup is done for the source address." what if we also included some RIB entry examples? e.g. ::/0 (route) 2001:db8::/56 -> NH1 (path #1) 2001:db9::/56 -> NH2 (path #2) -> NH#3 (path #3) would that make it clearer? > Section 6.2. >=20 > During autoconfig, if the prefix is delegated to other Homenet routers > on a hop by hop basis, the Homenet router receiving a new prefix could > indeed install a default SADR route for (parent_prefix/x,0:/0) -> the > upstream delegating router. So in this case your requirement 2 to > strongly couple autoconfiguration and routing would not seem onerous. right, in that case the parent prefix wouldn't really be the aggregate = prefix though, and not identify the border exit. in a strict routed hierarchy then I guess you = wouldn't need SADR. > But alternatively, if the delegation of prefixes within Homenet occurs > via a mechanism like DHCP PD, the receiving router could instead = install > a default SADR route (parent_prefix/x,0:/0) -> Homenet BR DHCP PD = source > address, and then recurse the standard unicast routing table to find = the > appropriate next hop toward the Homenet BR. This is a trick that works > very well in BGP networks (with next BGP hop being a software/loopback > interface of the AS egress router that is always up and stable, = combined > with an IGP containing just the loopback addresses of the BGP speaking > AS egress routers) yes, now we tie the aggregate prefix and the advertising border router = using the router-id. if the border router had a global address, that was included in the = aggregate route advertisement as well as the external route advertisements, we could use that instead. it would certainly make the routing tables more clearer and more = explicit. > In which case there's no requirement for a hard link between the = routing > protocol and the prefix autoconfiguration mechanism, and thus no > requirement to update the IGP to carry SADR routes, which I think is > potentially a big win. that would be a big win, but I don't quite see how you avoid the hard = link? given that border routers may or may not advertise a default route, and = may also advertise more specifics...=20 cheers, Ole= From v6ops@globis.net Wed Feb 20 02:17:28 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C20721F873C for ; Wed, 20 Feb 2013 02:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.092 X-Spam-Level: X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFEMcxZ1HZZ3 for ; Wed, 20 Feb 2013 02:17:26 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6DF21F86EA for ; Wed, 20 Feb 2013 02:17:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3F37C8700F2; Wed, 20 Feb 2013 11:07:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyTbXe0r2Wi5; Wed, 20 Feb 2013 11:06:49 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 9DD278700EF; Wed, 20 Feb 2013 11:06:49 +0100 (CET) Message-ID: <5124A033.1030007@globis.net> Date: Wed, 20 Feb 2013 11:06:43 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Ole Troan References: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> <51247F52.9070000@globis.net> <0BB080A0-2DAC-403C-B99D-627207F080E5@employees.org> In-Reply-To: <0BB080A0-2DAC-403C-B99D-627207F080E5@employees.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , lorenzo@google.com Subject: Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 10:17:28 -0000 > Ole Troan > 20 February 2013 09:59 > Ray, > >> I have read this draft and find it useful. >> >>> A routing entry may have both (S, D) paths and (*, D) paths. The >> longest match wins >> >> Section 5 seems to suggest SADR is just a tie breaker applied to the >> subset of equal length D routes, but I think you probably should be more >> specific on the phrase "longest match" in this sentence, as there are 2 >> length comparisons (one on D and one on S) > > yes, right now we say: > > "First a longest match lookup is done in the routing table for the > destination address, then for the resulting set a longest matching > lookup is done for the source address." > > what if we also included some RIB entry examples? > e.g. > > ::/0 (route) > 2001:db8::/56 -> NH1 (path #1) > 2001:db9::/56 -> NH2 (path #2) > -> NH#3 (path #3) > > would that make it clearer? Yes I think so. It's just a readability thing. Suggest including various combinations e.g. (*,::/0) (2001:db8:1::/56,::/0) (*,2001:db8:2::/56) & (2001:db8:1::/56,2001:db8:2::/56) >> Section 6.2. >> >> During autoconfig, if the prefix is delegated to other Homenet routers >> on a hop by hop basis, the Homenet router receiving a new prefix could >> indeed install a default SADR route for (parent_prefix/x,0:/0) -> the >> upstream delegating router. So in this case your requirement 2 to >> strongly couple autoconfiguration and routing would not seem onerous. > > right, in that case the parent prefix wouldn't really be the aggregate prefix though, and not > identify the border exit. in a strict routed hierarchy then I guess you wouldn't need SADR. I don't see why it would not include this info. AFAIK we haven't yet settled on a prefix delegation mechanism, so the mechanism could carry both the aggregate prefix as well as the parent prefix at this point in the hierarchy, and even the border exit id/address. But then we're pretty much getting into a combined routing protocol and delegation mechanism exactly as you already indicated. >> But alternatively, if the delegation of prefixes within Homenet occurs >> via a mechanism like DHCP PD, the receiving router could instead install >> a default SADR route (parent_prefix/x,0:/0) -> Homenet BR DHCP PD source >> address, and then recurse the standard unicast routing table to find the >> appropriate next hop toward the Homenet BR. This is a trick that works >> very well in BGP networks (with next BGP hop being a software/loopback >> interface of the AS egress router that is always up and stable, combined >> with an IGP containing just the loopback addresses of the BGP speaking >> AS egress routers) > > yes, now we tie the aggregate prefix and the advertising border router using the router-id. > if the border router had a global address, that was included in the aggregate route advertisement > as well as the external route advertisements, we could use that instead. Right. Why wouldn't a border router have a global address if it is connected to the Internet? Am I missing something? > it would certainly make the routing tables more clearer and more explicit. And possibly converge faster too on local topology changes. >> In which case there's no requirement for a hard link between the routing >> protocol and the prefix autoconfiguration mechanism, and thus no >> requirement to update the IGP to carry SADR routes, which I think is >> potentially a big win. > > that would be a big win, but I don't quite see how you avoid the hard link? Thinking about this some more, it's specifically the requirement to select and modify a single IGP that is bothering me. That seems to make a big assumption about the autoconfiguration mechanism that we have yet to choose. Although that in the end modified OSPFv3 might be the best overall solution, it would seem to me easier and more correct to say that the prefix autoconfiguration mechanism should distribute the SADR information, as the Homenet BR anyway has to initiate the prefix delegation and provide the necessary Homenet BR egress information. The SADR specific information would to my mind be more tightly coupled to changes in prefix delegation from the upstream provider, or availability of the upstream provider link, and not directly with any local routing protocol or topology change. We're not planning on running OSPF to providers' PE routers... > given that border routers may or may not advertise a default route, and may also advertise > more specifics... True. My assumption is that the 99% use case will be a simple default route to "the Internet." That could be incorrect. What's the use case behind more specific routes (in the walled garden)? What would be so bad in the case of a walled garden if we always installed a default SADR route associated with the prefix learned specifically from the walled garden i.e. (walled_garden_derived_prefix/56,::/0) -> NH_walled_garden_homenet_BR? We've anyway still got to sort out correct source address selection even once we've got the basic packet routing in place. Source address selection could be the point where the real "routing" decision is made, whilst SADR would be used to select the correct Homenet BR and to avoid the ingress filters once the correct source address has been decided. regards, RayH > > cheers, > Ole > Ray Hunter > 20 February 2013 08:46 > I have read this draft and find it useful. > >> A routing entry may have both (S, D) paths and (*, D) paths. The > longest match wins > > Section 5 seems to suggest SADR is just a tie breaker applied to the > subset of equal length D routes, but I think you probably should be more > specific on the phrase "longest match" in this sentence, as there are 2 > length comparisons (one on D and one on S) > > Section 6.2. > > During autoconfig, if the prefix is delegated to other Homenet routers > on a hop by hop basis, the Homenet router receiving a new prefix could > indeed install a default SADR route for (parent_prefix/x,0:/0) -> the > upstream delegating router. So in this case your requirement 2 to > strongly couple autoconfiguration and routing would not seem onerous. > > But alternatively, if the delegation of prefixes within Homenet occurs > via a mechanism like DHCP PD, the receiving router could instead install > a default SADR route (parent_prefix/x,0:/0) -> Homenet BR DHCP PD source > address, and then recurse the standard unicast routing table to find the > appropriate next hop toward the Homenet BR. This is a trick that works > very well in BGP networks (with next BGP hop being a software/loopback > interface of the AS egress router that is always up and stable, combined > with an IGP containing just the loopback addresses of the BGP speaking > AS egress routers) > > In which case there's no requirement for a hard link between the routing > protocol and the prefix autoconfiguration mechanism, and thus no > requirement to update the IGP to carry SADR routes, which I think is > potentially a big win. > > regards, > RayH > > Ole Troan wrote: >> Begin forwarded message: >> >>> From: >>> Subject: New Version Notification for draft-troan-homenet-sadr-00.txt >>> Date: February 18, 2013 22:01:47 GMT+01:00 >>> To: >>> Cc: >>> Received: from mail.cisco.com [173.36.12.72] by otroan-mac.getinternet.no with POP3 (fetchmail-6.3.20) for (single-drop); Mon, 18 Feb 2013 22:02:13 +0100 (CET) >>> Received: from rcdn-iport-6.cisco.com (173.37.86.77) by mail.cisco.com (173.36.12.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 Feb 2013 15:01:50 -0600 >>> Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +0000 >>> Received: from rcdn-inbound-i.cisco.com (rcdn-inbound-i.cisco.com [72.163.7.178]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1IL1ixR029679 for ; Mon, 18 Feb 2013 21:01:49 GMT >>> Received: from mail.ietf.org ([64.170.98.30]) by rcdn-inbound-i.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +0000 >>> Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4D221F8C03; Mon, 18 Feb 2013 13:01:48 -0800 (PST) >>> Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlwPsnRC5mQw; Mon, 18 Feb 2013 13:01:48 -0800 (PST) >>> Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA73121F8C56; Mon, 18 Feb 2013 13:01:47 -0800 (PST) >>> Authentication-Results: rcdn-inbound-i.cisco.com; dkim=utral (message not signed) header.i=none >>> X-From-Outside-Cisco: 64.170.98.30 >>> X-Ironport-Anti-Spam-Filtered: true >>> X-Ironport-Anti-Spam-Result: Ak0BAE6WIlFAqmIemWdsb2JhbABEhkmoGgGRP4EFFg4BAQEBAQgLCwcUJ4JJVAI1AiYCSTKICQyuZJIogSONfxUdgheBEwOIZ41EAYEdkmM >>> X-Ironport-Av: E=phos;i="4.84,690,1355097600"; d="scan'208";a="89740088" >>> X-Virus-Scanned: amavisd-new at amsl.com >>> Content-Type: text/plain; charset=tf-8" >>> Content-Transfer-Encoding: quoted-printable >>> X-Test-Idtracker: no >>> X-Ietf-Idtracker: 4.40 >>> Message-Id: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> >>> Return-Path: internet-drafts@ietf.org >>> X-Ms-Exchange-Organization-Authsource: xhc-aln-x07.cisco.com >>> X-Ms-Exchange-Organization-Authas: Internal >>> X-Ms-Exchange-Organization-Authmechanism: 10 >>> Mime-Version: 1.0 >>> >>> >>> A new version of I-D, draft-troan-homenet-sadr-00.txt >>> has been successfully submitted by Ole Troan and posted to the >>> IETF repository. >>> >>> Filename: draft-troan-homenet-sadr >>> Revision: 00 >>> Title: IPv6 Multihoming with Source Address Dependent Routing (SADR) >>> Creation date: 2013-02-18 >>> Group: Individual Submission >>> Number of pages: 7 >>> URL: http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-troan-homenet-sadr >>> Htmlized: http://tools.ietf.org/html/draft-troan-homenet-sadr-00 >>> >>> >>> Abstract: >>> A multihomed network using provider aggregatable addresses must send >>> the packet out the right path to avoid violating the provider's >>> ingress filtering. This memo suggests a mechanism called Source >>> Address Dependent Routing to solve that problem. >>> >>> >>> >>> >>> The IETF Secretariat >>> > ------------------------------------------------------------------------ From otroan@employees.org Wed Feb 20 05:58:21 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3C221F85C0 for ; Wed, 20 Feb 2013 05:58:21 -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.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YC7lHn8I5L7N for ; Wed, 20 Feb 2013 05:58:21 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2245321F86BE for ; Wed, 20 Feb 2013 05:58:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG/VJFGQ/khR/2dsb2JhbABFwFd9FnOCIAEBBDo9AhALDjhXBoglwBqOWzMHgl9hA6cHgwg X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; d="scan'208";a="80574355" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 20 Feb 2013 13:58:19 +0000 Received: from dhcp-lys02-vla252-10-147-116-40.cisco.com (dhcp-lys02-vla252-10-147-116-40.cisco.com [10.147.116.40]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1KDwIaQ026659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 13:58:19 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <5124A033.1030007@globis.net> Date: Wed, 20 Feb 2013 14:58:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2B83C5D5-9E6A-4500-A551-85304F2101B7@employees.org> References: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> <51247F52.9070000@globis.net> <0BB080A0-2DAC-403C-B99D-627207F080E5@employees.org> <5124A033.1030007@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , lorenzo@google.com Subject: Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 13:58:22 -0000 Ray, thinking out loud. the border router includes in the advertisement of the aggregate prefix: - it's own global IPv6 address - list of external routes each internal router: - installs (S,D) routes for all of the external routes with the = border's global as next-hop. normal unicast routing is used to get to the border. yep, that should work too. and be completely independent of routing = protocol. but at the cost of being dependent on the prefix assignment = mechanism. leaving the question open I suppose, does SADR have a wider = applicability outside of the home network... cheers, Ole= From lorenzo@google.com Wed Feb 20 07:13:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF3B21F87ED for ; Wed, 20 Feb 2013 07:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.926 X-Spam-Level: X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-qrJ-3qIURu for ; Wed, 20 Feb 2013 07:13:04 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 79ACF21F87C4 for ; Wed, 20 Feb 2013 07:13:04 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id tb18so7848349obb.3 for ; Wed, 20 Feb 2013 07:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=FbRKObbhDKubSJPRXh5HVt0y+FpZiJVk6H8N4OHnmrY=; b=UO4xeVkhQhedSIAbKRNfFdnXTx+GznZXe3rCy/fq7hVsHpuxvPnbj59dvNvNgfu4z4 gWxniQYS5t5ACUW8TNl9iOa9xGi3RIFFWhNSMxLEkne924zQReIKGoa4Qn27mCq+A+8A PcLfb/G0LfSHBlIFcnV9wLQHwqWQPhY8oGMoToSM4sfZkJUac7BpGgBG7xNr5omDUjxI zgGhAx6/gQNfbR7o2MoqxU7oDJPmZluUnVgxr0HFrMNnRtQnrxUHn3ChyctyqXa5U2Du 51yIQ/2CBknxeFMU7YQM2BB7V62mJsrC0/OsI0NBX1pnjYJNioGq7z/qdn7PHxdFnWI1 Xtpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=FbRKObbhDKubSJPRXh5HVt0y+FpZiJVk6H8N4OHnmrY=; b=ffSVKwKgwncIWKR58i9GG5Kfs+0AjTvitzxTiziR2a+aHwlF6GajmWk92X+9ac8GKf IKWVRQ/nGLuIA0PTQKXsnDxO0zVYfcWhp8TpcC3Tq12SKM7N1LcHIkJnrFCuiSyV5KTZ r6kAflQFAd7zNF/sUxKcbFoKl27nbMJPv9IAGMbt+G4YHCh1EoD38/RS9HKmUvlnI6a4 qtATLgDoJB9W4uyiQH21YceW9031TIoh4CPKiItlhP4SVmWZk3qdai70Vy9vb99TI5/X RQjWAauApF5EeYK+2C6CLBIMKjX3TGza2g5JqpWsA3GFB8TsBrw+7qvoK8nrD2ZArWXa AwEw== X-Received: by 10.182.202.73 with SMTP id kg9mr9267857obc.95.1361373183981; Wed, 20 Feb 2013 07:13:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 20 Feb 2013 07:12:43 -0800 (PST) In-Reply-To: <2B83C5D5-9E6A-4500-A551-85304F2101B7@employees.org> References: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> <51247F52.9070000@globis.net> <0BB080A0-2DAC-403C-B99D-627207F080E5@employees.org> <5124A033.1030007@globis.net> <2B83C5D5-9E6A-4500-A551-85304F2101B7@employees.org> From: Lorenzo Colitti Date: Thu, 21 Feb 2013 00:12:43 +0900 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=e89a8f6436fc09b6eb04d6296596 X-Gm-Message-State: ALoCoQmy9q9LuCrieLVWiOP9sIs419bLYKLWU9/9q2Yj0cGorLn5WENIx0sQFrXpjMdg0GyTBVPACe+DbNTVe83F3sYZo+pc674sl9bIEI7GBoF86TJypwawAZfydJSqtlnBmPRLKSIbG3ofsokoEluroEgXl+5YQERlMvyyVqclS0ZC/hBnnSEVU389pt3Tdkh2Ngyzv5KK Cc: Ray Hunter , "homenet@ietf.org Group" Subject: Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:13:05 -0000 --e89a8f6436fc09b6eb04d6296596 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 20, 2013 at 10:58 PM, Ole Troan wrote: > thinking out loud. > > the border router includes in the advertisement of the aggregate prefix: > - it's own global IPv6 address > - list of external routes > > each internal router: > - installs (S,D) routes for all of the external routes with the border's > global as next-hop. > > normal unicast routing is used to get to the border. > This is what is done in network backbones with next-hop-self. That requires that you can do recursive loopbacks and that the border router's IP address is stable - i.e., if it's a loopback address. --e89a8f6436fc09b6eb04d6296596 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 20, 2013 at 10:58 PM, Ole Troan <otroan@em= ployees.org> wrote:
thinking out loud.

the border router includes in the advertisement of the aggregate prefix: =A0- it's own global IPv6 address
=A0- list of external routes

each internal router:
=A0- installs (S,D) routes for all of the external routes with the border&#= 39;s global as next-hop.

normal unicast routing is used to get to the border.
<= br>
This is what is done in network backbones with next-hop= -self. That requires that you can do recursive loopbacks and that the borde= r router's IP address is stable - i.e., if it's a loopback address.=
--e89a8f6436fc09b6eb04d6296596-- From mattia.rossi.mailinglists@gmail.com Wed Feb 20 08:49:44 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA6921F8931 for ; Wed, 20 Feb 2013 08:49:44 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFoet4-MWfED for ; Wed, 20 Feb 2013 08:49:44 -0800 (PST) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id C8DA721F88B0 for ; Wed, 20 Feb 2013 08:49:43 -0800 (PST) Received: by mail-ea0-f182.google.com with SMTP id a12so3631994eaa.13 for ; Wed, 20 Feb 2013 08:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KjkyrgxFtysumjSwzmC7llg/BfMkHK95Bspe9F4yCIY=; b=moeiLkKVDev2MGHN3b6wuo6/DhnpQGA1UZaGaCxHe+BsJkdLN7NUGfSRRfXbSQsLaH SyVXBjBQJNr1Sx0CjplpOQxttcmjrPorYsW/QlljNx1CZ15ousNptsRIRQRTL/Q4pIRP AJV/WfHtSmdfxcSGqxdM7Dyp3qzsUsPH8VIwCIZKe92AHrnkeS1OFki59uPKXXC1ezL1 xmLdK8HJ0CEk6563TWqs5cuMnQMnl/ZLsosR1/rB01p+O2RyWhhQvbZ1Jg8SuuqE8dcI QrbrjEEcR5ice8hPpiiWTg8AbDQ0/xaTov6s6IFRyRQp1fjIugKI8N5NwTrFU8IgpP8D FPXw== X-Received: by 10.14.193.134 with SMTP id k6mr70878829een.37.1361378982980; Wed, 20 Feb 2013 08:49:42 -0800 (PST) Received: from [192.168.0.101] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id d47sm51499604eem.9.2013.02.20.08.49.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 08:49:41 -0800 (PST) Message-ID: <5124FEA4.3080008@gmail.com> Date: Wed, 20 Feb 2013 17:49:40 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> <51247F52.9070000@globis.net> <0BB080A0-2DAC-403C-B99D-627207F080E5@employees.org> <5124A033.1030007@globis.net> In-Reply-To: <5124A033.1030007@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:49:44 -0000 Am 20.02.2013 11:06, schrieb Ray Hunter: > >> given that border routers may or may not advertise a default route, and may also advertise >> more specifics... > True. My assumption is that the 99% use case will be a simple default > route to "the Internet." That could be incorrect. > > What's the use case behind more specific routes (in the walled garden)? > > What would be so bad in the case of a walled garden if we always > installed a default SADR route associated with the prefix learned > specifically from the walled garden i.e. > (walled_garden_derived_prefix/56,::/0) -> NH_walled_garden_homenet_BR? True, generally it seems to me, that more specific routes are only needed in the case the Source Prefix in SADR is *. Otherwise the route is constrained by the source address anyway. The walled garden route is needed though, if the table looks like this: (*, ::/0) -> ISP_A # Default route to ISP A (*, ::/0) -> ISP_B # Default route to ISP B (*, 2001:db8::/64) -> R1 # Internal network, prefix from A (*, 2001:db8:1::/64) -> R2 # Internal network, prefix from A (*, 2001:db9::/64) -> R1 # Internal network, prefix from B (*, 2001:db9:1::/64) -> R2 # Internal network, prefix from B (*, fd00::/64) -> R3 # Internal network ULA (2001:db9::/56, 2001:420::/32) -> ISP_B # Walled garden route from ISP B Maybe that should be listed as an example as well. And maybe a line about how to behave if there's a tie with the multiple default route constellation: (*, ::/0) -> ISP_A # Default route to ISP A (*, ::/0) -> ISP_B # Default route to ISP B If we don't propose a solution , we should add a line which says that it's up to the implementation or load balancing mechanism or whatever to solve that, like: A router forwarding a packet does a longest match look-up on the destination address. If this is a (*, D) entry, it forwards the packet out the best next-hop as before (doing equal cost multi path load balancing etc). This applies also to multiple (*, ::/0) entries. > We've anyway still got to sort out correct source address selection even > once we've got the basic packet routing in place. Source address > selection could be the point where the real "routing" decision is > made, whilst SADR would be used to select the correct Homenet BR and to > avoid the ingress filters once the correct source address has been decided. > The hosts could perform NAT upon receipt of the ICMP code 5. Of course, if you have a low power device then you might have a problem... just a thought. I like the draft and find it very useful. From C.Grundemann@cablelabs.com Wed Feb 20 11:38:58 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442C721F8A08 for ; Wed, 20 Feb 2013 11:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUdjsnn1fM0b for ; Wed, 20 Feb 2013 11:38:57 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id BD6EE21F888B for ; Wed, 20 Feb 2013 11:38:57 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r1KJctvv005468; Wed, 20 Feb 2013 12:38:55 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 20 Feb 2013 12:38:55 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0328.009; Wed, 20 Feb 2013 12:38:56 -0700 From: Chris Grundemann To: "homenet@ietf.org" Thread-Topic: New Version Notification for draft-grundemann-homenet-hipnet-00.txt Thread-Index: AQHODFoiLVyBbAhOH0m+F6+nyCnoqZiDKyKA Date: Wed, 20 Feb 2013 19:38:55 +0000 Message-ID: <43238C9F8B23DA44B42A78D0129283E017FAE7BF@EXCHANGE.cablelabs.com> In-Reply-To: <20130216152728.22417.85041.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="utf-8" Content-ID: <4E94E859D1D00849A209D6E70822EA7A@cablelabs.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Approved: ondar Cc: "draft-grundemann-homenet-hipnet@tools.ietf.org" Subject: [homenet] FW: New Version Notification for draft-grundemann-homenet-hipnet-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:38:58 -0000 RGVhciBIb21lbmV0LA0KDQpDYWJsZUxhYnMsIGluIGNvb3BlcmF0aW9uIHdpdGggb3VyIG1lbWJl cnMgYW5kIHZlbmRvciBjb21wYW5pZXMsIGlzDQplbmhhbmNpbmcgb3VyIGVSb3V0ZXIgc3BlY2lm aWNhdGlvbiB0byBzdXBwb3J0IG11bHRpcm91dGVyIGhvbWUgbmV0d29ya3MuDQpBcyB3ZSBoYXZl IGluIHRoZSBwYXN0LCB3ZSBhcmUgcHJlc2VudGluZyBvdXIgZVJvdXRlciB1cGRhdGVzIHRvIHRo ZSBJRVRGDQppbiB0aGUgc3Bpcml0IG9mIHNoYXJpbmcuICBXZSBiZWxpZXZlIHRoYXQgdGhlc2Ug ZW5oYW5jZW1lbnRzIG1lZXQgdGhlDQpwcmluY2lwbGVzIG9mIHRoZSBob21lbmV0LWFyY2ggZG9j dW1lbnQsIHdoaWxlIG5vdCByZWx5aW5nIG9uIG5ldyBwcm90b2NvbA0KZGV2ZWxvcG1lbnQuDQoN CkluIGFkZGl0aW9uLCB3ZSBhcmUgcHJvdG90eXBpbmcgdGhlc2UgZW5oYW5jZW1lbnRzLCBhbmQg YXJlIHBsYW5uaW5nIHRvDQpkZW1vbnN0cmF0ZSB0aGVtIGluIE9ybGFuZG8uDQoNCkNoZWVycywN Cn5DaHJpcw0KDQoNCg0KT24gMi8xNi8xMyA4OjI3IEFNLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0Kd3JvdGU6DQoNCj4NCj5BIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtZ3J1bmRlbWFubi1ob21lbmV0LWhpcG5ldC0wMC50eHQNCj5oYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IENocmlzIERvbmxleSBhbmQgcG9zdGVkIHRv IHRoZQ0KPklFVEYgcmVwb3NpdG9yeS4NCj4NCj5GaWxlbmFtZToJIGRyYWZ0LWdydW5kZW1hbm4t aG9tZW5ldC1oaXBuZXQNCj5SZXZpc2lvbjoJIDAwDQo+VGl0bGU6CQkgQSBOZWFyIFRlcm0gU29s dXRpb24gZm9yIEhvbWUgSVAgTmV0d29ya2luZyAoSElQbmV0KQ0KPkNyZWF0aW9uIGRhdGU6CSAy MDEzLTAyLTE1DQo+R3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+TnVtYmVyIG9mIHBh Z2VzOiAyMg0KPlVSTDogICAgICAgICAgICAgDQo+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtZ3J1bmRlbWFubi1ob21lbmV0LWhpcG5ldC0wMC50eHQNCj5TdGF0dXM6 ICAgICAgICAgIA0KPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ3J1bmRl bWFubi1ob21lbmV0LWhpcG5ldA0KPkh0bWxpemVkOiAgICAgICAgDQo+aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZ3J1bmRlbWFubi1ob21lbmV0LWhpcG5ldC0wMA0KPg0KPg0KPkFi c3RyYWN0Og0KPiAgIEhvbWUgbmV0d29ya3MgYXJlIGJlY29taW5nIG1vcmUgY29tcGxleC4gIFdp dGggdGhlIGxhdW5jaCBvZiBuZXcNCj4gICBzZXJ2aWNlcyBzdWNoIGFzIGhvbWUgc2VjdXJpdHks IElQIHZpZGVvLCBTbWFydCBHcmlkLCBldGMuLCBtYW55DQo+ICAgU2VydmljZSBQcm92aWRlcnMg YXJlIHBsYWNpbmcgYWRkaXRpb25hbCBJUHY0L0lQdjYgcm91dGVycyBvbiB0aGUNCj4gICBzdWJz Y3JpYmVyIG5ldHdvcmsuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNlbGYtY29uZmlndXJp bmcgaG9tZQ0KPiAgIHJvdXRlciB0aGF0IGlzIGNhcGFibGUgb2Ygb3BlcmF0aW5nIGluIHN1Y2gg YW4gZW52aXJvbm1lbnQsIGFuZCB0aGF0DQo+ICAgcmVxdWlyZXMgbm8gdXNlciBpbnRlcmFjdGlv biB0byBjb25maWd1cmUgaXQuICBDb21wbGlhbnQgd2l0aA0KPiAgIGRyYWZ0LWlldGYtaG9tZW5l dC1hcmNoLCBpdCB1c2VzIGV4aXN0aW5nIHByb3RvY29scyBpbiBuZXcgd2F5cw0KPiAgIHdpdGhv dXQgdGhlIG5lZWQgZm9yIGEgcm91dGluZyBwcm90b2NvbC4NCj4NCj4NCj4gICAgICAgICAgICAg ICAgICANCj4gICAgICAgIA0KPg0KPg0KPlRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQoNCg== From john_brzozowski@cable.comcast.com Wed Feb 20 12:24:38 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CE521F889C for ; Wed, 20 Feb 2013 12:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoUajm8XOlz6 for ; Wed, 20 Feb 2013 12:24:37 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8336221F8806 for ; Wed, 20 Feb 2013 12:24:37 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57233313; Wed, 20 Feb 2013 12:54:18 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Wed, 20 Feb 2013 15:24:32 -0500 From: "Brzozowski, John" To: Mark Townsley , "homenet@ietf.org Group" Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHN+RIkUKHjmYjHJk2z+mbkmocqxw== Date: Wed, 20 Feb 2013 20:24:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:24:38 -0000 Folks, I expect to have a DOCSIS network available during IETF86 for Bits-n-Bytes if there is interest in having real broadband equipment in the HOMENET lab please let me know I will do my best to accommodate. After we got everything up an running I recall that some (or all) of the running code that was available during IETF85 had some issue interoperating with a live IPv6 enabled broadband network. The cable broadband network was functioning as it does today in production. I wanted to make sure everyone was aware that the environment would be available again in case there was an interest in testing (and/or fixing) their implementations. Regards, John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Mark Townsley Date: Monday, January 21, 2013 12:25 PM To: "homenet@ietf.org Group" Subject: [homenet] Running code in Orlando > >Group, > >Happy new year everyone. The next IETF will be upon us soon. > >Last IETF, we had two implementations based on >draft-arkko-homenet-prefix-assignment and >draft-ietf-ospf-ospfv3-autoconfig running about. Bugs in code as well as >bugs in specs were found. We had a number of people bringing along their >hosts and plugging them into the various router ports, and people >randomly changing the wiring to see if would keep working. Ironically, >uplinks to the outside world gave us some of the biggest headaches, and >with better planning we should be able to alleviate those problems if we >do this again. In any case, it was overall a positive experience, and >we're considering now whether or not to try and do it again. > >If you have an implementation of a protocol within the scope of the >homenet charter and homenet architecture (draft-ietf-homenet-arch-06) >based on an internet draft targeted to the homenet working group that you >would like to test with others, please send the list or chairs an email >so we can evaluate whether or not to schedule a place for you to get >together and work with others in person in Orlando. Note that this isn't >for "showcasing", but for working... so be expected to configure, >reconfigure, and change code on the fly accordingly. > >Please let us know ASAP, as March is coming soon! > >Thanks, > >- Mark & Ray=20 > > > > > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From v6ops@globis.net Wed Feb 20 12:38:56 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7318C21F871D for ; Wed, 20 Feb 2013 12:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.086 X-Spam-Level: X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abvuSxxNSHAQ for ; Wed, 20 Feb 2013 12:38:54 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6A02A21F8716 for ; Wed, 20 Feb 2013 12:38:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 71AA5870129; Wed, 20 Feb 2013 21:31:06 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCMFP-AlykEL; Wed, 20 Feb 2013 21:30:36 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id A4A50870123; Wed, 20 Feb 2013 21:30:36 +0100 (CET) Message-ID: <51253266.2080608@globis.net> Date: Wed, 20 Feb 2013 21:30:30 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Ole Troan References: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> <51247F52.9070000@globis.net> <0BB080A0-2DAC-403C-B99D-627207F080E5@employees.org> <5124A033.1030007@globis.net> <2B83C5D5-9E6A-4500-A551-85304F2101B7@employees.org> In-Reply-To: <2B83C5D5-9E6A-4500-A551-85304F2101B7@employees.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , lorenzo@google.com Subject: Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:38:56 -0000 > Ole Troan > 20 February 2013 14:58 > Ray, > > thinking out loud. > > the border router includes in the advertisement of the aggregate prefix: > - it's own global IPv6 address > - list of external routes > > each internal router: > - installs (S,D) routes for all of the external routes with the > border's global as next-hop. > > normal unicast routing is used to get to the border. > > yep, that should work too. and be completely independent of routing > protocol. Agreed. > but at the cost of being dependent on the prefix assignment mechanism. True. Which anyway has still to be solved for Homenet. > leaving the question open I suppose, does SADR have a wider > applicability outside of the home network... > Almost certainly, if you believe in stateful firewalls, and multiple alternate paths, but do not want to deploy either NAT66 or rfc6296 Network Prefix Translation (to guarantee a symmetric return path). You could consider an approach like the CIDR RFC, split into 3 topics: 1) Semantics of making a forwarding decision given a SADR table 2) Considerations for (routing) protocols that maintain the SADR table 3) Homenet specific solution (potentially tied to prefix autoconfiguration) > cheers, > Ole > Ray Hunter > 20 February 2013 11:06 >> Ole Troan >> 20 February 2013 09:59 >> Ray, >> >>> I have read this draft and find it useful. >>> >>>> A routing entry may have both (S, D) paths and (*, D) paths. The >>> longest match wins >>> >>> Section 5 seems to suggest SADR is just a tie breaker applied to the >>> subset of equal length D routes, but I think you probably should be more >>> specific on the phrase "longest match" in this sentence, as there are 2 >>> length comparisons (one on D and one on S) >> yes, right now we say: >> >> "First a longest match lookup is done in the routing table for the >> destination address, then for the resulting set a longest matching >> lookup is done for the source address." >> >> what if we also included some RIB entry examples? >> e.g. >> >> ::/0 (route) >> 2001:db8::/56 -> NH1 (path #1) >> 2001:db9::/56 -> NH2 (path #2) >> -> NH#3 (path #3) >> >> would that make it clearer? > Yes I think so. It's just a readability thing. > > Suggest including various combinations e.g. (*,::/0) > (2001:db8:1::/56,::/0) (*,2001:db8:2::/56) & > (2001:db8:1::/56,2001:db8:2::/56) >>> Section 6.2. >>> >>> During autoconfig, if the prefix is delegated to other Homenet routers >>> on a hop by hop basis, the Homenet router receiving a new prefix could >>> indeed install a default SADR route for (parent_prefix/x,0:/0) -> the >>> upstream delegating router. So in this case your requirement 2 to >>> strongly couple autoconfiguration and routing would not seem onerous. >> right, in that case the parent prefix wouldn't really be the aggregate prefix though, and not >> identify the border exit. in a strict routed hierarchy then I guess you wouldn't need SADR. > I don't see why it would not include this info. AFAIK we haven't yet > settled on a prefix delegation mechanism, so the mechanism could carry > both the aggregate prefix as well as the parent prefix at this point in > the hierarchy, and even the border exit id/address. But then we're > pretty much getting into a combined routing protocol and delegation > mechanism exactly as you already indicated. >>> But alternatively, if the delegation of prefixes within Homenet occurs >>> via a mechanism like DHCP PD, the receiving router could instead install >>> a default SADR route (parent_prefix/x,0:/0) -> Homenet BR DHCP PD source >>> address, and then recurse the standard unicast routing table to find the >>> appropriate next hop toward the Homenet BR. This is a trick that works >>> very well in BGP networks (with next BGP hop being a software/loopback >>> interface of the AS egress router that is always up and stable, combined >>> with an IGP containing just the loopback addresses of the BGP speaking >>> AS egress routers) >> yes, now we tie the aggregate prefix and the advertising border router using the router-id. >> if the border router had a global address, that was included in the aggregate route advertisement >> as well as the external route advertisements, we could use that instead. > Right. Why wouldn't a border router have a global address if it is > connected to the Internet? > Am I missing something? >> it would certainly make the routing tables more clearer and more explicit. > And possibly converge faster too on local topology changes. >>> In which case there's no requirement for a hard link between the routing >>> protocol and the prefix autoconfiguration mechanism, and thus no >>> requirement to update the IGP to carry SADR routes, which I think is >>> potentially a big win. >> that would be a big win, but I don't quite see how you avoid the hard link? > Thinking about this some more, it's specifically the requirement to > select and modify a single IGP that is bothering me. That seems to make > a big assumption about the autoconfiguration mechanism that we have yet > to choose. > > Although that in the end modified OSPFv3 might be the best overall > solution, it would seem to me easier and more correct to say that the > prefix autoconfiguration mechanism should distribute the SADR > information, as the Homenet BR anyway has to initiate the prefix > delegation and provide the necessary Homenet BR egress information. > > The SADR specific information would to my mind be more tightly coupled > to changes in prefix delegation from the upstream provider, or > availability of the upstream provider link, and not directly with any > local routing protocol or topology change. We're not planning on running > OSPF to providers' PE routers... >> given that border routers may or may not advertise a default route, and may also advertise >> more specifics... > True. My assumption is that the 99% use case will be a simple default > route to "the Internet." That could be incorrect. > > What's the use case behind more specific routes (in the walled garden)? > > What would be so bad in the case of a walled garden if we always > installed a default SADR route associated with the prefix learned > specifically from the walled garden i.e. > (walled_garden_derived_prefix/56,::/0) -> NH_walled_garden_homenet_BR? > > We've anyway still got to sort out correct source address selection even > once we've got the basic packet routing in place. Source address > selection could be the point where the real "routing" decision is > made, whilst SADR would be used to select the correct Homenet BR and to > avoid the ingress filters once the correct source address has been decided. > > regards, > RayH >> cheers, >> Ole >> Ray Hunter >> 20 February 2013 08:46 >> I have read this draft and find it useful. >> >>> A routing entry may have both (S, D) paths and (*, D) paths. The >> longest match wins >> >> Section 5 seems to suggest SADR is just a tie breaker applied to the >> subset of equal length D routes, but I think you probably should be more >> specific on the phrase "longest match" in this sentence, as there are 2 >> length comparisons (one on D and one on S) >> >> Section 6.2. >> >> During autoconfig, if the prefix is delegated to other Homenet routers >> on a hop by hop basis, the Homenet router receiving a new prefix could >> indeed install a default SADR route for (parent_prefix/x,0:/0) -> the >> upstream delegating router. So in this case your requirement 2 to >> strongly couple autoconfiguration and routing would not seem onerous. >> >> But alternatively, if the delegation of prefixes within Homenet occurs >> via a mechanism like DHCP PD, the receiving router could instead install >> a default SADR route (parent_prefix/x,0:/0) -> Homenet BR DHCP PD source >> address, and then recurse the standard unicast routing table to find the >> appropriate next hop toward the Homenet BR. This is a trick that works >> very well in BGP networks (with next BGP hop being a software/loopback >> interface of the AS egress router that is always up and stable, combined >> with an IGP containing just the loopback addresses of the BGP speaking >> AS egress routers) >> >> In which case there's no requirement for a hard link between the routing >> protocol and the prefix autoconfiguration mechanism, and thus no >> requirement to update the IGP to carry SADR routes, which I think is >> potentially a big win. >> >> regards, >> RayH >> >> Ole Troan wrote: >>> Begin forwarded message: >>> >>>> From: >>>> Subject: New Version Notification for draft-troan-homenet-sadr-00.txt >>>> Date: February 18, 2013 22:01:47 GMT+01:00 >>>> To: >>>> Cc: >>>> Received: from mail.cisco.com [173.36.12.72] by otroan-mac.getinternet.no with POP3 (fetchmail-6.3.20) for (single-drop); Mon, 18 Feb 2013 22:02:13 +0100 (CET) >>>> Received: from rcdn-iport-6.cisco.com (173.37.86.77) by mail.cisco.com (173.36.12.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 Feb 2013 15:01:50 -0600 >>>> Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +0000 >>>> Received: from rcdn-inbound-i.cisco.com (rcdn-inbound-i.cisco.com [72.163.7.178]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1IL1ixR029679 for ; Mon, 18 Feb 2013 21:01:49 GMT >>>> Received: from mail.ietf.org ([64.170.98.30]) by rcdn-inbound-i.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +0000 >>>> Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4D221F8C03; Mon, 18 Feb 2013 13:01:48 -0800 (PST) >>>> Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlwPsnRC5mQw; Mon, 18 Feb 2013 13:01:48 -0800 (PST) >>>> Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA73121F8C56; Mon, 18 Feb 2013 13:01:47 -0800 (PST) >>>> Authentication-Results: rcdn-inbound-i.cisco.com; dkim=utral (message not signed) header.i=none >>>> X-From-Outside-Cisco: 64.170.98.30 >>>> X-Ironport-Anti-Spam-Filtered: true >>>> X-Ironport-Anti-Spam-Result: Ak0BAE6WIlFAqmIemWdsb2JhbABEhkmoGgGRP4EFFg4BAQEBAQgLCwcUJ4JJVAI1AiYCSTKICQyuZJIogSONfxUdgheBEwOIZ41EAYEdkmM >>>> X-Ironport-Av: E=phos;i="4.84,690,1355097600"; d="scan'208";a="89740088" >>>> X-Virus-Scanned: amavisd-new at amsl.com >>>> Content-Type: text/plain; charset=tf-8" >>>> Content-Transfer-Encoding: quoted-printable >>>> X-Test-Idtracker: no >>>> X-Ietf-Idtracker: 4.40 >>>> Message-Id: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> >>>> Return-Path: internet-drafts@ietf.org >>>> X-Ms-Exchange-Organization-Authsource: xhc-aln-x07.cisco.com >>>> X-Ms-Exchange-Organization-Authas: Internal >>>> X-Ms-Exchange-Organization-Authmechanism: 10 >>>> Mime-Version: 1.0 >>>> >>>> >>>> A new version of I-D, draft-troan-homenet-sadr-00.txt >>>> has been successfully submitted by Ole Troan and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-troan-homenet-sadr >>>> Revision: 00 >>>> Title: IPv6 Multihoming with Source Address Dependent Routing (SADR) >>>> Creation date: 2013-02-18 >>>> Group: Individual Submission >>>> Number of pages: 7 >>>> URL: http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt >>>> Status: http://datatracker.ietf.org/doc/draft-troan-homenet-sadr >>>> Htmlized: http://tools.ietf.org/html/draft-troan-homenet-sadr-00 >>>> >>>> >>>> Abstract: >>>> A multihomed network using provider aggregatable addresses must send >>>> the packet out the right path to avoid violating the provider's >>>> ingress filtering. This memo suggests a mechanism called Source >>>> Address Dependent Routing to solve that problem. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >> ------------------------------------------------------------------------ > > Ole Troan > 20 February 2013 09:59 > Ray, > >> I have read this draft and find it useful. >> >>> A routing entry may have both (S, D) paths and (*, D) paths. The >> longest match wins >> >> Section 5 seems to suggest SADR is just a tie breaker applied to the >> subset of equal length D routes, but I think you probably should be more >> specific on the phrase "longest match" in this sentence, as there are 2 >> length comparisons (one on D and one on S) > > yes, right now we say: > > "First a longest match lookup is done in the routing table for the > destination address, then for the resulting set a longest matching > lookup is done for the source address." > > what if we also included some RIB entry examples? > e.g. > > ::/0 (route) > 2001:db8::/56 -> NH1 (path #1) > 2001:db9::/56 -> NH2 (path #2) > -> NH#3 (path #3) > > would that make it clearer? > >> Section 6.2. >> >> During autoconfig, if the prefix is delegated to other Homenet routers >> on a hop by hop basis, the Homenet router receiving a new prefix could >> indeed install a default SADR route for (parent_prefix/x,0:/0) -> the >> upstream delegating router. So in this case your requirement 2 to >> strongly couple autoconfiguration and routing would not seem onerous. > > right, in that case the parent prefix wouldn't really be the aggregate prefix though, and not > identify the border exit. in a strict routed hierarchy then I guess you wouldn't need SADR. > >> But alternatively, if the delegation of prefixes within Homenet occurs >> via a mechanism like DHCP PD, the receiving router could instead install >> a default SADR route (parent_prefix/x,0:/0) -> Homenet BR DHCP PD source >> address, and then recurse the standard unicast routing table to find the >> appropriate next hop toward the Homenet BR. This is a trick that works >> very well in BGP networks (with next BGP hop being a software/loopback >> interface of the AS egress router that is always up and stable, combined >> with an IGP containing just the loopback addresses of the BGP speaking >> AS egress routers) > > yes, now we tie the aggregate prefix and the advertising border router using the router-id. > if the border router had a global address, that was included in the aggregate route advertisement > as well as the external route advertisements, we could use that instead. > > it would certainly make the routing tables more clearer and more explicit. > >> In which case there's no requirement for a hard link between the routing >> protocol and the prefix autoconfiguration mechanism, and thus no >> requirement to update the IGP to carry SADR routes, which I think is >> potentially a big win. > > that would be a big win, but I don't quite see how you avoid the hard link? > given that border routers may or may not advertise a default route, and may also advertise > more specifics... > > cheers, > Ole > Ray Hunter > 20 February 2013 08:46 > I have read this draft and find it useful. > >> A routing entry may have both (S, D) paths and (*, D) paths. The > longest match wins > > Section 5 seems to suggest SADR is just a tie breaker applied to the > subset of equal length D routes, but I think you probably should be more > specific on the phrase "longest match" in this sentence, as there are 2 > length comparisons (one on D and one on S) > > Section 6.2. > > During autoconfig, if the prefix is delegated to other Homenet routers > on a hop by hop basis, the Homenet router receiving a new prefix could > indeed install a default SADR route for (parent_prefix/x,0:/0) -> the > upstream delegating router. So in this case your requirement 2 to > strongly couple autoconfiguration and routing would not seem onerous. > > But alternatively, if the delegation of prefixes within Homenet occurs > via a mechanism like DHCP PD, the receiving router could instead install > a default SADR route (parent_prefix/x,0:/0) -> Homenet BR DHCP PD source > address, and then recurse the standard unicast routing table to find the > appropriate next hop toward the Homenet BR. This is a trick that works > very well in BGP networks (with next BGP hop being a software/loopback > interface of the AS egress router that is always up and stable, combined > with an IGP containing just the loopback addresses of the BGP speaking > AS egress routers) > > In which case there's no requirement for a hard link between the routing > protocol and the prefix autoconfiguration mechanism, and thus no > requirement to update the IGP to carry SADR routes, which I think is > potentially a big win. > > regards, > RayH > > Ole Troan wrote: >> Begin forwarded message: >> >>> From: >>> Subject: New Version Notification for draft-troan-homenet-sadr-00.txt >>> Date: February 18, 2013 22:01:47 GMT+01:00 >>> To: >>> Cc: >>> Received: from mail.cisco.com [173.36.12.72] by otroan-mac.getinternet.no with POP3 (fetchmail-6.3.20) for (single-drop); Mon, 18 Feb 2013 22:02:13 +0100 (CET) >>> Received: from rcdn-iport-6.cisco.com (173.37.86.77) by mail.cisco.com (173.36.12.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 Feb 2013 15:01:50 -0600 >>> Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +0000 >>> Received: from rcdn-inbound-i.cisco.com (rcdn-inbound-i.cisco.com [72.163.7.178]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1IL1ixR029679 for ; Mon, 18 Feb 2013 21:01:49 GMT >>> Received: from mail.ietf.org ([64.170.98.30]) by rcdn-inbound-i.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +0000 >>> Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4D221F8C03; Mon, 18 Feb 2013 13:01:48 -0800 (PST) >>> Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlwPsnRC5mQw; Mon, 18 Feb 2013 13:01:48 -0800 (PST) >>> Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA73121F8C56; Mon, 18 Feb 2013 13:01:47 -0800 (PST) >>> Authentication-Results: rcdn-inbound-i.cisco.com; dkim=utral (message not signed) header.i=none >>> X-From-Outside-Cisco: 64.170.98.30 >>> X-Ironport-Anti-Spam-Filtered: true >>> X-Ironport-Anti-Spam-Result: Ak0BAE6WIlFAqmIemWdsb2JhbABEhkmoGgGRP4EFFg4BAQEBAQgLCwcUJ4JJVAI1AiYCSTKICQyuZJIogSONfxUdgheBEwOIZ41EAYEdkmM >>> X-Ironport-Av: E=phos;i="4.84,690,1355097600"; d="scan'208";a="89740088" >>> X-Virus-Scanned: amavisd-new at amsl.com >>> Content-Type: text/plain; charset=tf-8" >>> Content-Transfer-Encoding: quoted-printable >>> X-Test-Idtracker: no >>> X-Ietf-Idtracker: 4.40 >>> Message-Id: <20130218210147.7330.45442.idtracker@ietfa.amsl.com> >>> Return-Path: internet-drafts@ietf.org >>> X-Ms-Exchange-Organization-Authsource: xhc-aln-x07.cisco.com >>> X-Ms-Exchange-Organization-Authas: Internal >>> X-Ms-Exchange-Organization-Authmechanism: 10 >>> Mime-Version: 1.0 >>> >>> >>> A new version of I-D, draft-troan-homenet-sadr-00.txt >>> has been successfully submitted by Ole Troan and posted to the >>> IETF repository. >>> >>> Filename: draft-troan-homenet-sadr >>> Revision: 00 >>> Title: IPv6 Multihoming with Source Address Dependent Routing (SADR) >>> Creation date: 2013-02-18 >>> Group: Individual Submission >>> Number of pages: 7 >>> URL: http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-troan-homenet-sadr >>> Htmlized: http://tools.ietf.org/html/draft-troan-homenet-sadr-00 >>> >>> >>> Abstract: >>> A multihomed network using provider aggregatable addresses must send >>> the packet out the right path to avoid violating the provider's >>> ingress filtering. This memo suggests a mechanism called Source >>> Address Dependent Routing to solve that problem. >>> >>> >>> >>> >>> The IETF Secretariat >>> > ------------------------------------------------------------------------ From lorenzo@google.com Wed Feb 20 18:21:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F1F21F8D01 for ; Wed, 20 Feb 2013 18:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.933 X-Spam-Level: X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QU1c6sIknWe for ; Wed, 20 Feb 2013 18:21:55 -0800 (PST) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF3621F84F5 for ; Wed, 20 Feb 2013 18:21:55 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id l10so8758985oag.30 for ; Wed, 20 Feb 2013 18:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=gMlyxzf/TQ/UiH+X7nIRlqxfgrkNrnqsAT0xSHj2CyM=; b=ZVgRxG0oH88womd/ZEUkH1VwwIa6O2MGwQbsV/TLqPamtvRWRZyLbYUfnjSvn9IYOo sOr8J3/pv4hmq6UWzeUJBLrG0y0f7kIg45iD/Ow9n/pN/DMcrzrTb97m1V0cmqdquAFN ZVM/ai6d9yzKIKPQ7G7uW6bQPiuWkDnh5xZVd5TPCd7inkZbOjTz0UMsMMKr4gSOskWq Git05da/RB4t3EYN3/pf/QR186VqsEzgHRoAaZ0YCRHvAqjxlxV0sG07ocpqmNFCy3Te o/t6+7PJdWrRcuhRgsdPRQVE7+1P/6QbkIX4cHqyrFXZxZ7jKbRS2qEtMIlJsLPdUtNF 0p5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=gMlyxzf/TQ/UiH+X7nIRlqxfgrkNrnqsAT0xSHj2CyM=; b=eb5OLHoJMUqUIwqEA1VyabWEsSSNdDbDYTqslWDYt/UguqNz2kPtGSU1nRQFRGFXRR 9tEUcWR/0CiJ0fnoq0ybJ8ughje1VJOcUDu6mYZWh7o87g87rNWZxvTDdl9R6jnpTXyg 6jlr23HbMyDsxRRBKp6cFjanNt1HCKXPRhw/oWmcr9liDbNYKjmbKNl+azLDm0xCkDZ4 ZDgkKxeqkVYYvXNqAXZJpv0WLNgtKNIqZMprLIRNwnNlm/V8lFIlbir/8lZdnFesEhD5 pMTkJWLMp/AeFxNbWW1DMtvySfeZoxtbIw9pVOExJcoJBORoh5g9C58Rfm7FGeiq5Tm4 FxLw== X-Received: by 10.182.202.73 with SMTP id kg9mr10067644obc.95.1361413315028; Wed, 20 Feb 2013 18:21:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 20 Feb 2013 18:21:34 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Thu, 21 Feb 2013 11:21:34 +0900 Message-ID: To: "Brzozowski, John" , Jari Arkko Content-Type: multipart/alternative; boundary=e89a8f6436fc08e5bd04d632bdea X-Gm-Message-State: ALoCoQnAx+CPZ5S7GB2H9F5vHvVMf42G0zzEmz/QgYwjmm60l6DwS/DeOurDEW5EL+HXTsLLxvRFgXfbGk6x438u3vetjzkDsqPgDQG7w1iH6I8ESVsK5EHJCsk+kB5Nw4RuCOdLhHAxAlGy0AkNKJVl+ERJSrvFJcS0Tug7leFGo69/GeFrs9kQoAvoted7mCjvWzF3+xAX Cc: "homenet@ietf.org Group" , Mark Townsley Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 02:21:57 -0000 --e89a8f6436fc08e5bd04d632bdea Content-Type: text/plain; charset=ISO-8859-1 +1 for stuff that works in the real world. "Running code" isn't running code if it doesn't, well, run. :-) Mark, Jari, is it possible to revive the autoconfig/source-routing demo that we had in Atlanta? Even if it's only for a limited time, I think it's important to show that (or "whether", depending on your point of view) this stuff can work in the real world. John: assuming it's possible to revive the demo, then I think it would be enough to have two cable modems connected to a live network that hands out "something larger than /64" by default. If we don't have PD or if we don't have greater than /64 then there's not much point in attempting routing. :-) Does that sound possible? On Thu, Feb 21, 2013 at 5:24 AM, Brzozowski, John < John_Brzozowski@cable.comcast.com> wrote: > Folks, > > I expect to have a DOCSIS network available during IETF86 for Bits-n-Bytes > if there is interest in having real broadband equipment in the HOMENET lab > please let me know I will do my best to accommodate. After we got > everything up an running I recall that some (or all) of the running code > that was available during IETF85 had some issue interoperating with a live > IPv6 enabled broadband network. The cable broadband network was > functioning as it does today in production. > > I wanted to make sure everyone was aware that the environment would be > available again in case there was an interest in testing (and/or fixing) > their implementations. > > Regards, > > John > ========================================= > John Jason Brzozowski > Comcast Cable > m) +1-609-377-6594 > e) mailto:john_brzozowski@cable.comcast.com > o) +1-484-962-0060 > w) http://www.comcast6.net > ========================================= > > > > > > -----Original Message----- > From: Mark Townsley > Date: Monday, January 21, 2013 12:25 PM > To: "homenet@ietf.org Group" > Subject: [homenet] Running code in Orlando > > > > >Group, > > > >Happy new year everyone. The next IETF will be upon us soon. > > > >Last IETF, we had two implementations based on > >draft-arkko-homenet-prefix-assignment and > >draft-ietf-ospf-ospfv3-autoconfig running about. Bugs in code as well as > >bugs in specs were found. We had a number of people bringing along their > >hosts and plugging them into the various router ports, and people > >randomly changing the wiring to see if would keep working. Ironically, > >uplinks to the outside world gave us some of the biggest headaches, and > >with better planning we should be able to alleviate those problems if we > >do this again. In any case, it was overall a positive experience, and > >we're considering now whether or not to try and do it again. > > > >If you have an implementation of a protocol within the scope of the > >homenet charter and homenet architecture (draft-ietf-homenet-arch-06) > >based on an internet draft targeted to the homenet working group that you > >would like to test with others, please send the list or chairs an email > >so we can evaluate whether or not to schedule a place for you to get > >together and work with others in person in Orlando. Note that this isn't > >for "showcasing", but for working... so be expected to configure, > >reconfigure, and change code on the fly accordingly. > > > >Please let us know ASAP, as March is coming soon! > > > >Thanks, > > > >- Mark & Ray > > > > > > > > > > > >_______________________________________________ > >homenet mailing list > >homenet@ietf.org > >https://www.ietf.org/mailman/listinfo/homenet > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --e89a8f6436fc08e5bd04d632bdea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 for stuff that works in the real world. "Runn= ing code" isn't running code if it doesn't, well, run. :-)

Mark, Jari, is it possible to revive the autoco= nfig/source-routing demo that we had in Atlanta? Even if it's only for = a limited time, I think it's important to show that (or "whether&q= uot;, depending on your point of view) this stuff can work in the real worl= d.

John: assuming it's possible to revive = the demo, then I think it would be enough to have two cable modems connecte= d to a live network that hands out "something larger than /64" by= default. If we don't have PD or if we don't have greater than /64 = then there's not much point in attempting routing. :-)

Does that sound possible?


On Thu, Feb 21, 201= 3 at 5:24 AM, Brzozowski, John <John_Brzozowski@cable.comc= ast.com> wrote:
Folks,

I expect to have a DOCSIS network available during IETF86 for Bits-n-Bytes<= br> if there is interest in having real broadband equipment in the HOMENET lab<= br> please let me know I will do my best to accommodate. =A0After we got
everything up an running I recall that some (or all) of the running code that was available during IETF85 had some issue interoperating with a live<= br> IPv6 enabled broadband network. =A0The cable broadband network was
functioning as it does today in production.

I wanted to make sure everyone was aware that the environment would be
available again in case there was an interest in testing (and/or fixing) their implementations.

Regards,

John
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
m) +1-609-377-6594=
e) mailto:john_brzozow= ski@cable.comcast.com
o) +1-484-962-0060=
w) http://www.comcast= 6.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D





-----Original Message-----
From: Mark Townsley <mark@townsley.= net>
Date: Monday, January 21, 2013 12:25 PM
To: "homenet@ietf.org Group&qu= ot; <homenet@ietf.org>
Subject: [homenet] Running code in Orlando

>
>Group,
>
>Happy new year everyone. The next IETF will be upon us soon.
>
>Last IETF, we had two implementations based on
>draft-arkko-homenet-prefix-assignment and
>draft-ietf-ospf-ospfv3-autoconfig running about. Bugs in code as well a= s
>bugs in specs were found. We had a number of people bringing along thei= r
>hosts and plugging them into the various router ports, and people
>randomly changing the wiring to see if would keep working. Ironically,<= br> >uplinks to the outside world gave us some of the biggest headaches, and=
>with better planning we should be able to alleviate those problems if w= e
>do this again. In any case, it was overall a positive experience, and >we're considering now whether or not to try and do it again.
>
>If you have an implementation of a protocol within the scope of the
>homenet charter and homenet architecture (draft-ietf-homenet-arch-06) >based on an internet draft targeted to the homenet working group that y= ou
>would like to test with others, please send the list or chairs an email=
>so we can evaluate whether or not to schedule a place for you to get >together and work with others in person in Orlando. Note that this isn&= #39;t
>for "showcasing", but for working... so be expected to config= ure,
>reconfigure, and change code on the fly accordingly.
>
>Please let us know ASAP, as March is coming soon!
>
>Thanks,
>
>- Mark & Ray
>
>
>
>
>
>_______________________________________________
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet


_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--e89a8f6436fc08e5bd04d632bdea-- From mcr@sandelman.ca Wed Feb 20 19:17:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DB021E8086 for ; Wed, 20 Feb 2013 19:17:26 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ+nbXbR5H+u for ; Wed, 20 Feb 2013 19:17:25 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id F119F21E8055 for ; Wed, 20 Feb 2013 19:17:24 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E63920168; Wed, 20 Feb 2013 22:24:12 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 804326387F; Wed, 20 Feb 2013 22:16:16 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 41FBB6387D; Wed, 20 Feb 2013 22:16:16 -0500 (EST) From: Michael Richardson To: Lorenzo Colitti In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Mark Townsley , "homenet@ietf.org Group" , Jari Arkko , "Brzozowski, John" Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 03:17:26 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Lorenzo" =3D=3D Lorenzo Colitti writes: Lorenzo> +1 for stuff that works in the real world. "Running code" isn'= t running Lorenzo> code if it doesn't, well, run. :-) Lorenzo> Mark, Jari, is it possible to revive the autoconfig/source-rou= ting demo Lorenzo> that we had in Atlanta? Even if it's only for a limited time, = I think it's Lorenzo> important to show that (or "whether", depending on your point = of view) this Lorenzo> stuff can work in the real world. Lorenzo> John: assuming it's possible to revive the demo, then I think = it would be Lorenzo> enough to have two cable modems connected to a live network th= at hands out Lorenzo> "something larger than /64" by default. If we don't have PD or= if we don't Lorenzo> have greater than /64 then there's not much point in Lorenzo> attempting routing. :-) Would/could another foot of such a network be on the IETF network? =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUSWRf4qHRg3pndX9AQKuowP/QJf8K0c/Hm+N6HDlnAml6G6vY/3GTefU DewzFzIOzkl7X98Do/0Y1Uv5yt4fanMSHsI8MN7DBefAQfUlkGTsKvx61Vjlm5re WoX0MN8d5Nps9lxmec4g5QritVJfDjZPYC63zoTZN6t+1mxfS7GJtLspbXB4S7r9 YF2zWDr+ouw= =1bm2 -----END PGP SIGNATURE----- --=-=-=-- From lorenzo@google.com Wed Feb 20 19:40:50 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F00E21E808F for ; Wed, 20 Feb 2013 19:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBD7MNd2EhJN for ; Wed, 20 Feb 2013 19:40:49 -0800 (PST) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD5C21E8055 for ; Wed, 20 Feb 2013 19:40:49 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id un3so8325402obb.24 for ; Wed, 20 Feb 2013 19:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cdmrYnGqvlrCH+afM/y4OITV9FeH8JqgURvSfpt1tYE=; b=pX0Q64NQLhUj7++q9szkPpcyNB/rht9wktTh+f1FNa/S3gcu6bsGO08lw2L7PWLJMx Qjc7tLgJhlFOTevAyYMyGL5UJAnCBUE733krOogxfi/lorh/nin+9chhH4NS8XBUwfsu eBNh6v10BTOKXku6dDnU/oyMwKBlGvisHXepV0Y4J8lVj5lWqlia+NOT6+CyArk5anF7 rBOX+6+2ZnWPwcKHUcGHIXXTUVX6xfx+IIbeFwP8afos9aH6okkQcseqSSbCP4myda+N K6kLCth4udV8/yFPIN/wDHc+IvIQlMNBUP2SUm7ZKHOiI6tnU6IwEu/hPu/+BvCbouh2 nIWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=cdmrYnGqvlrCH+afM/y4OITV9FeH8JqgURvSfpt1tYE=; b=V7QFCnTG/H3QPZqKC51V7YsiUM4Tmjt2ZWNaJhkIzFky/zAyOPGF6kkdPCzNziOydS QnwxMWULWwP7YGWewpWKlqo5oAEcdP+atfJlxRy3CrOSi/x0Pl9fFBA2vtv6FTRTN64Q LyOHDpriwHZuPbnlpt1BAJeAzUpFMd5jNtZBX2+4SrlMTxXXecagLPTHohFz6B+xTVbp 7BCu3NLxkm2BecAUVnV7c7aOLqcp/58NmINFJX9WIRer1BeH+XtTPLiJSxU0Pxs5p+dS IFWpZ1alLYWxzMa6kkxaLkJYbEmGAjwtYuTRUxhUlrYFL5cPnMWyUpke0peRs/wEptt2 5rNQ== X-Received: by 10.60.169.178 with SMTP id af18mr10441133oec.133.1361418045498; Wed, 20 Feb 2013 19:40:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Wed, 20 Feb 2013 19:40:25 -0800 (PST) In-Reply-To: <22354.1361416575@sandelman.ca> References: <22354.1361416575@sandelman.ca> From: Lorenzo Colitti Date: Thu, 21 Feb 2013 12:40:25 +0900 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=bcaec54b45acfe268604d633d6fb X-Gm-Message-State: ALoCoQkGpfsifASCXE2sbAB2baG6BCzthzY/jXp6sqmeJ3lePT3/1/aOG7tJmnQAIUCysOhlNzE6nXe9LumQ2BLlOrvlLStvYDP/rAXxua3BUbeITtY+weIHAxwVMCQsEJ+6rBPwyzVEVCSHJsvdi+vhkflE7klafSAuHIlqpMgwxXb92RTkK8CYcmEEgaE9v627RqbPEpNN Cc: Mark Townsley , "homenet@ietf.org Group" , Jari Arkko , "Brzozowski, John" Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 03:40:50 -0000 --bcaec54b45acfe268604d633d6fb Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson wrote: > Would/could another foot of such a network be on the IETF network? > If the IETF network didn't respond to DHCPv6 PD requests, it wouldn't be much use. --bcaec54b45acfe268604d633d6fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
=
Would/could another foot of such a network b= e on the IETF network?

If the IET= F network didn't respond to DHCPv6 PD requests, it wouldn't be much= use.
--bcaec54b45acfe268604d633d6fb-- From equinox@diac24.net Wed Feb 20 19:49:59 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C64F21E8091 for ; Wed, 20 Feb 2013 19:49:59 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyGbVIEcczSw for ; Wed, 20 Feb 2013 19:49:58 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB34721E8055 for ; Wed, 20 Feb 2013 19:49:58 -0800 (PST) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2::]) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U8NAI-0007B1-Qt; Thu, 21 Feb 2013 04:49:46 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80) (envelope-from ) id 1U8NA6-00BpUo-1j; Thu, 21 Feb 2013 04:49:36 +0100 Date: Thu, 21 Feb 2013 04:49:34 +0100 From: David Lamparter To: Lorenzo Colitti Message-ID: <20130221034933.GC2799359@jupiter.n2.diac24.net> References: <22354.1361416575@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Michael Richardson , "homenet@ietf.org Group" , Jari Arkko , Mark Townsley , "Brzozowski, John" Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 03:49:59 -0000 On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote: > On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson > wrote: > > > Would/could another foot of such a network be on the IETF network? > > > > If the IETF network didn't respond to DHCPv6 PD requests, it wouldn't be > much use. Even without DHCPv6 PD on the remainder of the IETF network, it might be possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating part of the provider network. From john_brzozowski@cable.comcast.com Wed Feb 20 20:14:37 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A05421E8093 for ; Wed, 20 Feb 2013 20:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tCdy4kHxMRf for ; Wed, 20 Feb 2013 20:14:35 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 01C2C21E8091 for ; Wed, 20 Feb 2013 20:14:34 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57303551; Wed, 20 Feb 2013 20:44:18 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Wed, 20 Feb 2013 23:14:30 -0500 From: "Brzozowski, John" To: Lorenzo Colitti , Jari Arkko Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHN+RIkUKHjmYjHJk2z+mbkmocqx5iEFgMA//+qNIA= Date: Thu, 21 Feb 2013 04:14:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <5BD6FCC3D62286459D8F582081E541C8@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , Mark Townsley Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 04:14:37 -0000 We were delegating /56s last time. Definitely doable in Orlando. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Lorenzo Colitti Date: Wednesday, February 20, 2013 7:21 PM To: John Jason Brzozowski , Jari Arkko Cc: Mark Townsley , "homenet@ietf.org Group" Subject: Re: [homenet] Running code in Orlando >+1 for stuff that works in the real world. "Running code" isn't running >code if it doesn't, well, run. :-) > > >Mark, Jari, is it possible to revive the autoconfig/source-routing demo >that we had in Atlanta? Even if it's only for a limited time, I think >it's important to show that (or "whether", depending on your point of >view) this stuff can work in the > real world. > > >John: assuming it's possible to revive the demo, then I think it would be >enough to have two cable modems connected to a live network that hands >out "something larger than /64" by default. If we don't have PD or if we >don't have greater than /64 > then there's not much point in attempting routing. :-) > > >Does that sound possible? > > > >On Thu, Feb 21, 2013 at 5:24 AM, Brzozowski, John > wrote: > >Folks, > >I expect to have a DOCSIS network available during IETF86 for Bits-n-Bytes >if there is interest in having real broadband equipment in the HOMENET lab >please let me know I will do my best to accommodate. After we got >everything up an running I recall that some (or all) of the running code >that was available during IETF85 had some issue interoperating with a live >IPv6 enabled broadband network. The cable broadband network was >functioning as it does today in production. > >I wanted to make sure everyone was aware that the environment would be >available again in case there was an interest in testing (and/or fixing) >their implementations. > >Regards, > >John >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >John Jason Brzozowski >Comcast Cable >m) +1-609-377-6594 >e) mailto:john_brzozowski@cable.comcast.com >o) +1-484-962-0060 >w) http://www.comcast6.net >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > >-----Original Message----- >From: Mark Townsley >Date: Monday, January 21, 2013 12:25 PM >To: "homenet@ietf.org Group" >Subject: [homenet] Running code in Orlando > >> >>Group, >> >>Happy new year everyone. The next IETF will be upon us soon. >> >>Last IETF, we had two implementations based on >>draft-arkko-homenet-prefix-assignment and >>draft-ietf-ospf-ospfv3-autoconfig running about. Bugs in code as well as >>bugs in specs were found. We had a number of people bringing along their >>hosts and plugging them into the various router ports, and people >>randomly changing the wiring to see if would keep working. Ironically, >>uplinks to the outside world gave us some of the biggest headaches, and >>with better planning we should be able to alleviate those problems if we >>do this again. In any case, it was overall a positive experience, and >>we're considering now whether or not to try and do it again. >> >>If you have an implementation of a protocol within the scope of the >>homenet charter and homenet architecture (draft-ietf-homenet-arch-06) >>based on an internet draft targeted to the homenet working group that you >>would like to test with others, please send the list or chairs an email >>so we can evaluate whether or not to schedule a place for you to get >>together and work with others in person in Orlando. Note that this isn't >>for "showcasing", but for working... so be expected to configure, >>reconfigure, and change code on the fly accordingly. >> >>Please let us know ASAP, as March is coming soon! >> >>Thanks, >> >>- Mark & Ray >> >> >> >> >> >>_______________________________________________ >>homenet mailing list >>homenet@ietf.org >>https://www.ietf.org/mailman/listinfo/homenet > > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet > > > > > From john_brzozowski@cable.comcast.com Wed Feb 20 20:16:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0727B21E8090 for ; Wed, 20 Feb 2013 20:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWycZZo--0M4 for ; Wed, 20 Feb 2013 20:16:19 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 1C13321E8055 for ; Wed, 20 Feb 2013 20:16:19 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57303644; Wed, 20 Feb 2013 20:46:01 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Wed, 20 Feb 2013 23:16:14 -0500 From: "Brzozowski, John" To: Lorenzo Colitti , Michael Richardson Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHN+RIkUKHjmYjHJk2z+mbkmocqx5iEFgMAgAAPR4CAAAbBgP//lKYA Date: Thu, 21 Feb 2013 04:16:13 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <496FF729F231104980FC9D950654EF6C@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mark Townsley , "homenet@ietf.org Group" , Jari Arkko Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 04:16:20 -0000 Plus what media is being tested, ethernet? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Lorenzo Colitti Date: Wednesday, February 20, 2013 8:40 PM To: Michael Richardson Cc: John Jason Brzozowski , Jari Arkko , "homenet@ietf.org Group" , Mark Townsley Subject: Re: [homenet] Running code in Orlando >On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson > wrote: > >Would/could another foot of such a network be on the IETF network? > > > > >If the IETF network didn't respond to DHCPv6 PD requests, it wouldn't be >much use. > > > From john_brzozowski@cable.comcast.com Wed Feb 20 20:17:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66F721E8091 for ; Wed, 20 Feb 2013 20:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.064 X-Spam-Level: X-Spam-Status: No, score=-103.064 tagged_above=-999 required=5 tests=[AWL=-2.167, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+SthjVxvPmt for ; Wed, 20 Feb 2013 20:17:57 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 1343521E8055 for ; Wed, 20 Feb 2013 20:17:56 -0800 (PST) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.44143552; Wed, 20 Feb 2013 23:04:48 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Wed, 20 Feb 2013 23:17:07 -0500 From: "Brzozowski, John" To: David Lamparter , Lorenzo Colitti Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHN+RIkUKHjmYjHJk2z+mbkmocqx5iEFgMAgAAPR4CAAAbBgIAAAo4A//+SWQA= Date: Thu, 21 Feb 2013 04:17:06 +0000 Message-ID: In-Reply-To: <20130221034933.GC2799359@jupiter.n2.diac24.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , "homenet@ietf.org Group" , Jari Arkko , Mark Townsley Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 04:17:57 -0000 Why emulate it? Is the intention here to test the the code on an enterprise or corporate network? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: David Lamparter Date: Wednesday, February 20, 2013 8:49 PM To: Lorenzo Colitti Cc: Michael Richardson , Mark Townsley , "homenet@ietf.org Group" , Jari Arkko , John Jason Brzozowski Subject: Re: [homenet] Running code in Orlando >On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote: >> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson >> wrote: >>=20 >> > Would/could another foot of such a network be on the IETF network? >> > >>=20 >> If the IETF network didn't respond to DHCPv6 PD requests, it wouldn't be >> much use. > >Even without DHCPv6 PD on the remainder of the IETF network, it might be >possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating part >of the provider network. From equinox@diac24.net Wed Feb 20 20:41:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C1121E8090 for ; Wed, 20 Feb 2013 20:41:45 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wk2IZO2lcmo for ; Wed, 20 Feb 2013 20:41:45 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EDD21E808F for ; Wed, 20 Feb 2013 20:41:45 -0800 (PST) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2::]) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U8NyX-00045O-2r; Thu, 21 Feb 2013 05:41:41 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80) (envelope-from ) id 1U8NyK-00BsJ8-9R; Thu, 21 Feb 2013 05:41:30 +0100 Date: Thu, 21 Feb 2013 05:41:28 +0100 From: David Lamparter To: "Brzozowski, John" Message-ID: <20130221044128.GD2799359@jupiter.n2.diac24.net> References: <20130221034933.GC2799359@jupiter.n2.diac24.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Michael Richardson , Mark Townsley , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 04:41:45 -0000 On Thu, Feb 21, 2013 at 04:17:06AM +0000, Brzozowski, John wrote: > David Lamparter wrote: > >On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote: > >> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson > >> wrote: > >> > >> > Would/could another foot of such a network be on the IETF network? > >> > > >> > >> If the IETF network didn't respond to DHCPv6 PD requests, it wouldn't be > >> much use. > > > >Even without DHCPv6 PD on the remainder of the IETF network, it might be > >possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating part > >of the provider network. > > Why emulate it? Is the intention here to test the the code on an > enterprise or corporate network? The scope of the plugfest is the interior and border of the homenet. To get the border right, we need the service provider side of that border in some form. If the IETF network runs DHCPv6-PD, that is an usable approximation. My suggestion was for the case that the IETF network won't be running DHCPv6-PD. In that case, the easiest way to make the IETF network usable as one uplink for the homenet plugfest is to ask for a /52 to be made available for the plugfest in some static way and then provide DHCPv6-PD from that, running on some random PC box/laptop somewhere. Actually - controlling the DHCPv6-PD might be advantageous in order to allow tinkering with it to see how the testbed reacts. -David From mcr@sandelman.ca Wed Feb 20 20:54:37 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8849021E8091 for ; Wed, 20 Feb 2013 20:54:37 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6vwhsB8g6sG for ; Wed, 20 Feb 2013 20:54:37 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id CA5F021E808F for ; Wed, 20 Feb 2013 20:54:36 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1848820168; Thu, 21 Feb 2013 00:01:25 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 32DFF102F5; Wed, 20 Feb 2013 23:53:29 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 214EF20007; Wed, 20 Feb 2013 23:53:29 -0500 (EST) From: Michael Richardson To: "Brzozowski, John" In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Mark Townsley , "homenet@ietf.org Group" , Lorenzo Colitti , Jari Arkko , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 04:54:37 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Brzozowski," =3D=3D Brzozowski, John writes: Brzozowski> Why emulate it? Is the intention here to test the the code= on an Brzozowski> enterprise or corporate network? Walled Garden :-) =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUSWoSIqHRg3pndX9AQIamAP9ENrI2G6UznWWRjLzX1Qoh2NA8IqE1o3W xOb9voI30+BuBKq99mGGQUHlqSO08pZtPMd97NZ3jRUgZl2/sF2doZfmx8hc+VAM NPbGU9gynbRglya6YazKkHZ0ErnlOgOY3K4w59QPFR2DhI7R5b/z03b3Nm6Uunl1 0PPmwWDjYbk= =Cri3 -----END PGP SIGNATURE----- --=-=-=-- From joelja@bogus.com Wed Feb 20 22:41:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A2221F8DDF for ; Wed, 20 Feb 2013 22:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgD4rA6zIQST for ; Wed, 20 Feb 2013 22:41:00 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0CE21F8DDE for ; Wed, 20 Feb 2013 22:41:00 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1L6ewfH033628 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 21 Feb 2013 06:40:59 GMT (envelope-from joelja@bogus.com) Message-ID: <5125C175.90909@bogus.com> Date: Wed, 20 Feb 2013 22:40:53 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: David Lamparter , Lorenzo Colitti References: <22354.1361416575@sandelman.ca> <20130221034933.GC2799359@jupiter.n2.diac24.net> In-Reply-To: <20130221034933.GC2799359@jupiter.n2.diac24.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 21 Feb 2013 06:41:00 +0000 (UTC) Cc: Michael Richardson , "homenet@ietf.org Group" , Mark Townsley , Jari Arkko , "Brzozowski, John" Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 06:41:01 -0000 On 2/20/13 7:49 PM, David Lamparter wrote: > On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote: >> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson >> wrote: >> >>> Would/could another foot of such a network be on the IETF network? >>> >> If the IETF network didn't respond to DHCPv6 PD requests, it wouldn't be >> much use. > Even without DHCPv6 PD on the remainder of the IETF network, it might be > possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating part > of the provider network. that's a straight forward request to the noc, that said time is getting tight so if you want support for your experiment during the meeting I'd reach out expeditiously. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From mattia.rossi.mailinglists@gmail.com Thu Feb 21 00:46:44 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AFC21F8E03 for ; Thu, 21 Feb 2013 00:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=-1.469, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATIC=1.172] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JI7-76TeHIlP for ; Thu, 21 Feb 2013 00:46:43 -0800 (PST) Received: from mail-we0-x22a.google.com (we-in-x022a.1e100.net [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4163321F89AE for ; Thu, 21 Feb 2013 00:46:43 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id z53so7756902wey.1 for ; Thu, 21 Feb 2013 00:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DmXGnyU75Bh80XCXZbi9QIyppKjUD7CZiykd68CGF1M=; b=NFLZO7oMCCsWVs+9VzOMvEiZPWlTn3jL9mX0GL3vBiLUDg0arwjMu1mS2KvjVs9HMY axNjTdI7l9Vt3slq27MGuIvDRp6YjMx2vC1hMLD+tk3495kXREjzrSj9bezv6EP4bQqA 2vcgYKDCm1ALdk5YrwoBfq1j39ILRWglO32rO9AWCpCJh+cC7lTHZkk3PBKUs3++F6L2 eXKf3bkVSZH8HPw4zznaN//+cNuDFDOoPkwWbUO+VmgpdgihoUOIYu1FyhJSbfNsPVcG WVhRWaTX2jDzjfd5zfzeXpe+P6kV61O/FBwEEc6ek+z/i3q9VQaGCUSqEsC2ciTrhnIM Xc3Q== X-Received: by 10.194.108.229 with SMTP id hn5mr39586452wjb.8.1361436399392; Thu, 21 Feb 2013 00:46:39 -0800 (PST) Received: from [192.168.0.101] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id fx5sm38611915wib.11.2013.02.21.00.46.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 00:46:38 -0800 (PST) Message-ID: <5125DEED.2050806@gmail.com> Date: Thu, 21 Feb 2013 09:46:37 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <43238C9F8B23DA44B42A78D0129283E017FAE7BF@EXCHANGE.cablelabs.com> In-Reply-To: <43238C9F8B23DA44B42A78D0129283E017FAE7BF@EXCHANGE.cablelabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] FW: New Version Notification for draft-grundemann-homenet-hipnet-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 08:46:44 -0000 Hi Chris, reading the draft, it seems clear that it is bound to your specific CableLabs eRouter use case. I haven't understood if this is just an informational draft, or whether you want to pursue it further and adapt the draft to create a standard. In the latter case, some thoughts: It's not clear, that it would work with all the scenarios outliend in section 3.2.2 of the homenet architecture (http://tools.ietf.org/html/draft-ietf-homenet-arch-07). E.g. how does it cover Multihoming? If an internal router gets two addresses, one from each prefix, and assuming no CER_ID, how do you ensure that the /48 check works, and it doesn't pick the first address, comparing it to the second prefix, and thus declaring the router a CER which it is not? I believe that's a non-issue, as the /48 check is done on a per-interface basis, but that's not documented in the draft. A multihoming section where you explain this, would be beneficial I think. I also don't like the "/48 check" notation, as it implies that ISP's hand out a /48 (even if stated otherwise in the text). If you call it "ISP prefix check" or "Delegated prefix check" would be better, as the principle is, that the ISP hands out an address to the CER which is different from the delegated prefix, while the CER hands out addresses from that prefix. Cheers, Mat Am 20.02.2013 20:38, schrieb Chris Grundemann: > Dear Homenet, > > CableLabs, in cooperation with our members and vendor companies, is > enhancing our eRouter specification to support multirouter home networks. > As we have in the past, we are presenting our eRouter updates to the IETF > in the spirit of sharing. We believe that these enhancements meet the > principles of the homenet-arch document, while not relying on new protocol > development. > > In addition, we are prototyping these enhancements, and are planning to > demonstrate them in Orlando. > > Cheers, > ~Chris > > > > On 2/16/13 8:27 AM, "internet-drafts@ietf.org" > wrote: > >> A new version of I-D, draft-grundemann-homenet-hipnet-00.txt >> has been successfully submitted by Chris Donley and posted to the >> IETF repository. >> >> Filename: draft-grundemann-homenet-hipnet >> Revision: 00 >> Title: A Near Term Solution for Home IP Networking (HIPnet) >> Creation date: 2013-02-15 >> Group: Individual Submission >> Number of pages: 22 >> URL: >> http://www.ietf.org/internet-drafts/draft-grundemann-homenet-hipnet-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-grundemann-homenet-hipnet >> Htmlized: >> http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-00 >> >> >> Abstract: >> Home networks are becoming more complex. With the launch of new >> services such as home security, IP video, Smart Grid, etc., many >> Service Providers are placing additional IPv4/IPv6 routers on the >> subscriber network. This document describes a self-configuring home >> router that is capable of operating in such an environment, and that >> requires no user interaction to configure it. Compliant with >> draft-ietf-homenet-arch, it uses existing protocols in new ways >> without the need for a routing protocol. >> >> >> >> >> >> >> The IETF Secretariat >> > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From john_brzozowski@cable.comcast.com Thu Feb 21 08:15:01 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFEA21F8E99 for ; Thu, 21 Feb 2013 08:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=-1.625, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vOUutcv-AJt for ; Thu, 21 Feb 2013 08:15:00 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9FB21F8E54 for ; Thu, 21 Feb 2013 08:15:00 -0800 (PST) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.44188787; Thu, 21 Feb 2013 11:01:50 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Thu, 21 Feb 2013 11:14:10 -0500 From: "Brzozowski, John" To: Michael Richardson Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHOEE56UKHjmYjHJk2z+mbkmocqxw== Date: Thu, 21 Feb 2013 16:14:09 +0000 Message-ID: In-Reply-To: <21552.1361422409@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <63FE807E9E83AD43BB86043BA44B7D76@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mark Townsley , "homenet@ietf.org Group" , Lorenzo Colitti , Jari Arkko , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:15:01 -0000 Where the home has ethernet run to it? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Michael Richardson Date: Wednesday, February 20, 2013 9:53 PM To: John Jason Brzozowski Cc: David Lamparter , Lorenzo Colitti , "homenet@ietf.org Group" , Jari Arkko , Mark Townsley Subject: Re: [homenet] Running code in Orlando > >>>>>> "Brzozowski," =3D=3D Brzozowski, John >>>>>> writes: > Brzozowski> Why emulate it? Is the intention here to test the the >code on an > Brzozowski> enterprise or corporate network? > >Walled Garden :-) > > >--=20 >Michael Richardson , Sandelman Software Works > > From john_brzozowski@cable.comcast.com Thu Feb 21 08:15:08 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CDF21F8EE2 for ; Thu, 21 Feb 2013 08:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.364 X-Spam-Level: X-Spam-Status: No, score=-104.364 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zhpo7oNIGuV0 for ; Thu, 21 Feb 2013 08:15:07 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0E021F8E99 for ; Thu, 21 Feb 2013 08:15:07 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57379632; Thu, 21 Feb 2013 08:44:01 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Thu, 21 Feb 2013 11:14:10 -0500 From: "Brzozowski, John" To: David Lamparter Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHOEE56UKHjmYjHJk2z+mbkmocqxw== Date: Thu, 21 Feb 2013 16:14:08 +0000 Message-ID: In-Reply-To: <20130221044128.GD2799359@jupiter.n2.diac24.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <16DD4FE1A46F0C4BBDBB7346CA2A0851@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , "homenet@ietf.org Group" , Mark Townsley , Jari Arkko , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:15:08 -0000 Statically assigning prefixes may enable testing but is not how homes will be provisioned in reality. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: David Lamparter Date: Wednesday, February 20, 2013 9:41 PM To: John Jason Brzozowski Cc: David Lamparter , Lorenzo Colitti , Michael Richardson , "homenet@ietf.org Group" , Jari Arkko , Mark Townsley Subject: Re: [homenet] Running code in Orlando >On Thu, Feb 21, 2013 at 04:17:06AM +0000, Brzozowski, John wrote: >> David Lamparter wrote: >> >On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote: >> >> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson >> >> wrote: >> >>=20 >> >> > Would/could another foot of such a network be on the IETF network? >> >> > >> >>=20 >> >> If the IETF network didn't respond to DHCPv6 PD requests, it >>wouldn't be >> >> much use. >> > >> >Even without DHCPv6 PD on the remainder of the IETF network, it might >>be >> >possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating >>part >> >of the provider network. >>=20 >> Why emulate it? Is the intention here to test the the code on an >> enterprise or corporate network? > >The scope of the plugfest is the interior and border of the homenet. To >get the border right, we need the service provider side of that border >in some form. If the IETF network runs DHCPv6-PD, that is an usable >approximation. > >My suggestion was for the case that the IETF network won't be running >DHCPv6-PD. In that case, the easiest way to make the IETF network >usable as one uplink for the homenet plugfest is to ask for a /52 to be >made available for the plugfest in some static way and then provide >DHCPv6-PD from that, running on some random PC box/laptop somewhere. > >Actually - controlling the DHCPv6-PD might be advantageous in order to >allow tinkering with it to see how the testbed reacts. > > >-David From C.Donley@cablelabs.com Thu Feb 21 08:23:42 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA0E21F887F for ; Thu, 21 Feb 2013 08:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6GfBciiPtjs for ; Thu, 21 Feb 2013 08:23:42 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id CE45821F8433 for ; Thu, 21 Feb 2013 08:23:41 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r1LGNdI1008884; Thu, 21 Feb 2013 09:23:39 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 21 Feb 2013 09:23:39 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0328.009; Thu, 21 Feb 2013 09:23:39 -0700 From: Chris Donley To: Mattia Rossi , "homenet@ietf.org" Thread-Topic: [homenet] FW: New Version Notification for draft-grundemann-homenet-hipnet-00.txt Thread-Index: AQHOEE/OPY6/GtZor06vXLr/yPQBdg== Date: Thu, 21 Feb 2013 16:23:38 +0000 Message-ID: <8B09A8FA963FEF43835B9C215704654E17FD560A@EXCHANGE.cablelabs.com> In-Reply-To: <5125DEED.2050806@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [homenet] FW: New Version Notification for draft-grundemann-homenet-hipnet-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:23:42 -0000 On 2/21/13 1:46 AM, "Mattia Rossi" wrote: >Hi Chris, > >reading the draft, it seems clear that it is bound to your specific >CableLabs eRouter use case. Just as our eRouter specification was relevant to the wider community as a contribution to RFC 6204/bis, we believe that our updates to support multirouter topologies are also relevant beyond the cable ecosystem. >I haven't understood if this is just an informational draft, or whether >you want to pursue it further and adapt the draft to create a standard. This is informational. We are bringing our updates to the IETF, in case others can benefit from our work. We expect to be able to demonstrate this functionality in Orlando on OpenWRT routers - stop by and check it out. >=20 >In the latter case, some thoughts: > >It's not clear, that it would work with all the scenarios outliend in >section 3.2.2 of the homenet architecture >(http://tools.ietf.org/html/draft-ietf-homenet-arch-07). >E.g. how does it cover Multihoming? If an internal router gets two >addresses, one from each prefix, and assuming no CER_ID, how do you >ensure that the /48 check works, and it doesn't pick the first address, >comparing it to the second prefix, and thus declaring the router a CER >which it is not? >I believe that's a non-issue, as the /48 check is done on a >per-interface basis, but that's not documented in the draft. >A multihoming section where you explain this, would be beneficial I think. Multihoming is covered in Section 6 (Multiple ISPs). We believe that our approach will cover the scenarios in the homenet arch document, as well as some additional ones (e.g. 2 ISPs, 2 CERs, non-shared subnet e.g. For VPNs). To your point, we could clarify that the /48 check is per prefix per interface. > >I also don't like the "/48 check" notation, as it implies that ISP's >hand out a /48 (even if stated otherwise in the text). >If you call it "ISP prefix check" or "Delegated prefix check" would be >better, as the principle is, that the ISP hands out an address to the >CER which is different from the delegated prefix, while the CER hands >out addresses from that prefix. Thanks. We'll consider it for a future version. > >Cheers, > >Mat Chris --=20 Chris Donley CCIE, CISSP, SCiPM Director - Network Technologies CableLabs=AE 858 Coal Creek Circle Louisville, CO 80027 303-661-3480 (v) > >Am 20.02.2013 20:38, schrieb Chris Grundemann: >> Dear Homenet, >> >> CableLabs, in cooperation with our members and vendor companies, is >> enhancing our eRouter specification to support multirouter home >>networks. >> As we have in the past, we are presenting our eRouter updates to the >>IETF >> in the spirit of sharing. We believe that these enhancements meet the >> principles of the homenet-arch document, while not relying on new >>protocol >> development. >> >> In addition, we are prototyping these enhancements, and are planning to >> demonstrate them in Orlando. >> >> Cheers, >> ~Chris >> >> >> >> On 2/16/13 8:27 AM, "internet-drafts@ietf.org" >> >> wrote: >> >>> A new version of I-D, draft-grundemann-homenet-hipnet-00.txt >>> has been successfully submitted by Chris Donley and posted to the >>> IETF repository. >>> >>> Filename: draft-grundemann-homenet-hipnet >>> Revision: 00 >>> Title: A Near Term Solution for Home IP Networking (HIPnet) >>> Creation date: 2013-02-15 >>> Group: Individual Submission >>> Number of pages: 22 >>> URL: >>>=20 >>>http://www.ietf.org/internet-drafts/draft-grundemann-homenet-hipnet-00.t >>>xt >>> Status: >>> http://datatracker.ietf.org/doc/draft-grundemann-homenet-hipnet >>> Htmlized: >>> http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-00 >>> >>> >>> Abstract: >>> Home networks are becoming more complex. With the launch of new >>> services such as home security, IP video, Smart Grid, etc., many >>> Service Providers are placing additional IPv4/IPv6 routers on the >>> subscriber network. This document describes a self-configuring home >>> router that is capable of operating in such an environment, and that >>> requires no user interaction to configure it. Compliant with >>> draft-ietf-homenet-arch, it uses existing protocols in new ways >>> without the need for a routing protocol. >>> >>> >>> =20 >>> =20 >>> >>> >>> The IETF Secretariat >>> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From dave.taht@gmail.com Thu Feb 21 08:35:27 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B240521F8E82 for ; Thu, 21 Feb 2013 08:35: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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29dn+rU1CUE4 for ; Thu, 21 Feb 2013 08:35:18 -0800 (PST) Received: from mail-ie0-x22a.google.com (ie-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 687BF21F8E70 for ; Thu, 21 Feb 2013 08:35:18 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id c11so11564831ieb.1 for ; Thu, 21 Feb 2013 08:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0dzma0H7f4CJXKAjOEM3nFfDesd75GHhGSS6TAvQziA=; b=NwJISRsl0TzVU5D5GvVRTvPVenIQfSzBDvQCjnZe47yj69d+oiQqxsdUFDJC0yboar Ps42BInBII+sopn5oeUgp/XOB6umaw9g3xidMsTSx5I0yGByzRI2tVjzo9+PCkkUtNGH 1EdO80172xOFtXeFIQaxA3gGz0OYkVxFDlOP2aEQFo6MbkPdfamLDupEvft24ehlBkRt puYuROJlFeoPXC1ZRKPOL8eoXRJG7oTND/T98LLPOx+HQavpa6eXct35MlLdmhr9z7/X xTDU/fyVVcXMnjVBwp+lyAKdyV5EIwGBStJjrLe4dzbq0Kfhzhp/55xPhDstlzW3OBG3 kjtw== MIME-Version: 1.0 X-Received: by 10.50.56.139 with SMTP id a11mr12881507igq.86.1361464517983; Thu, 21 Feb 2013 08:35:17 -0800 (PST) Received: by 10.64.77.1 with HTTP; Thu, 21 Feb 2013 08:35:17 -0800 (PST) In-Reply-To: References: <20130221044128.GD2799359@jupiter.n2.diac24.net> Date: Thu, 21 Feb 2013 08:35:17 -0800 Message-ID: From: Dave Taht To: "Brzozowski, John" Content-Type: multipart/alternative; boundary=f46d0401f449f7fedf04d63ea826 Cc: Michael Richardson , Mark Townsley , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:35:27 -0000 --f46d0401f449f7fedf04d63ea826 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am primarily focused on demonstrating solutions to bufferbloat in my portion of bit's and bytes. But I note that the present CeroWrt build appears to have working dhcp-pd (I've successfully got /56 /60, /61/ /62 subnets from it), and assigning that to the 6+ internal interfaces, support for every other form of ipv6 tunneling, the latest dnsmasq which has some good ways of bonding dns names to ipv6 AAAAs, support for routing ipv4 and ipv6 subnetworks over the quagga babel protocol (the two routers I'm demoing are meshed together at 5ghz) We had to fix a few nasty instruction traps in the ipv6 stack last month, but after doing that, I'm pretty pleased with the over-all performance and reliability - it survived the "thc" ipv6 tests handily, for example. Could use some more exaustive real-world testing, so, get it (for the wndr3700v2 and 3800 series) http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.5-2/ We also have specialized builds for the ubiquity nanostation m5 and picostation m2hp products deployed in the campground testbed. We still haven't done anything with distributing prefixes inside the home beside ahcp, and I still find the dynamicism required by renting ipv6 addresses to so impact in so many aspects of the "sane usage of stuff like printers", and naming, and the security model as to *demand* ipv6 nat in the home... but I did not get around to implementing npt66 in this release!! (so those that would flame me for this opinion can hold off (pretty please!?) until perhaps I can go into the implementation details of all the many things that break today... with those that care. ) In terms of interop, besides dhcp-pd and bufferbloat fixes, I'd rather like to see if these release can be made to work with ospfv6 on other devices. What else will be shown? The original homenet code was far too large to be usable on such a small device, but perhaps at least the ospf layer could be tried. And all that said, I'm rather totally buried with tests for, processing a ton of data from the field, and testing nfq_codel/bufferbloat. I just finished giving talks on that at MIT and Stanford on that stuff What's wrong with wifi? http://www.youtube.com/watch?v=3DWksh2DPHCDI&feature=3Dyoutu.be Intro to codel and fq_codel: http://netseminar.stanford.edu/ On Thu, Feb 21, 2013 at 8:14 AM, Brzozowski, John < John_Brzozowski@cable.comcast.com> wrote: > Statically assigning prefixes may enable testing but is not how homes wil= l > be provisioned in reality. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Cable > m) 484-962-0060 > e) john_brzozowski@cable.comcast.com > o) 609-377-6594 > w) www.comcast6.net > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > -----Original Message----- > From: David Lamparter > Date: Wednesday, February 20, 2013 9:41 PM > To: John Jason Brzozowski > Cc: David Lamparter , Lorenzo Colitti > , Michael Richardson , > "homenet@ietf.org Group" , Jari Arkko > , Mark Townsley > Subject: Re: [homenet] Running code in Orlando > > >On Thu, Feb 21, 2013 at 04:17:06AM +0000, Brzozowski, John wrote: > >> David Lamparter wrote: > >> >On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote: > >> >> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson > >> >> wrote: > >> >> > >> >> > Would/could another foot of such a network be on the IETF network= ? > >> >> > > >> >> > >> >> If the IETF network didn't respond to DHCPv6 PD requests, it > >>wouldn't be > >> >> much use. > >> > > >> >Even without DHCPv6 PD on the remainder of the IETF network, it might > >>be > >> >possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating > >>part > >> >of the provider network. > >> > >> Why emulate it? Is the intention here to test the the code on an > >> enterprise or corporate network? > > > >The scope of the plugfest is the interior and border of the homenet. To > >get the border right, we need the service provider side of that border > >in some form. If the IETF network runs DHCPv6-PD, that is an usable > >approximation. > > > >My suggestion was for the case that the IETF network won't be running > >DHCPv6-PD. In that case, the easiest way to make the IETF network > >usable as one uplink for the homenet plugfest is to ask for a /52 to be > >made available for the plugfest in some static way and then provide > >DHCPv6-PD from that, running on some random PC box/laptop somewhere. > > > >Actually - controlling the DHCPv6-PD might be advantageous in order to > >allow tinkering with it to see how the testbed reacts. > > > > > >-David > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --f46d0401f449f7fedf04d63ea826 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am primarily focused on demonstrating solutions to bufferbloat in my port= ion of bit's and bytes.

But I note that the present CeroWrt buil= d appears to have working dhcp-pd (I've successfully got /56 /60, /61/ = /62 subnets from it), and assigning that to the 6+ internal interfaces, sup= port for every other form of ipv6 tunneling, the latest dnsmasq which has s= ome good ways of bonding dns names to ipv6 AAAAs, support for routing ipv4 = and ipv6 subnetworks over the quagga babel protocol (the two routers I'= m demoing are meshed together at 5ghz)

We had to fix a few nasty instruction traps in the ipv6 stack last mont= h, but after doing that, I'm pretty pleased with the over-all performan= ce and reliability - it survived the "thc" ipv6 tests handily, fo= r example. Could use some more exaustive real-world testing, so, get it (fo= r the wndr3700v2 and 3800 series)

http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr= /3.7.5-2/

We also have specialized=A0 builds for the ubiquity na= nostation m5 and picostation m2hp products deployed in the campground testb= ed.

We still haven't done anything with distributing prefixes inside th= e home beside ahcp, and I still find the dynamicism required by renting ipv= 6 addresses to so impact in so many aspects of the "sane usage of stuf= f like printers", and naming, and the security model as to *demand* ip= v6 nat in the home... but I did not get around to implementing npt66 in thi= s release!!

(so those that would flame me for this opinion can hold off (pretty ple= ase!?) until perhaps I can go into the implementation details of all the ma= ny things that break today... with those that care. )

In terms of in= terop, besides dhcp-pd and bufferbloat fixes, I'd rather like to see if= these release can be made to work with ospfv6 on other devices. What else = will be shown? The original homenet code was far too large to be usable on = such a small device, but perhaps at least the ospf layer could be tried.
And all that said, I'm rather totally buried with tests for, proces= sing a ton of data from the field, and testing nfq_codel/bufferbloat. I jus= t finished giving talks on that at MIT and Stanford on that stuff

What's wrong with wifi?

http://www.youtub= e.com/watch?v=3DWksh2DPHCDI&feature=3Dyoutu.be
=A0
Intro to codel and fq_codel:

http://netseminar.stanford.edu/


<= br>
On Thu, Feb 21, 2013 at 8:14 AM, Brzozowski, = John <John_Brzozowski@cable.comcast.com> wro= te:
Statically assigning prefixes may enable tes= ting but is not how homes will
be provisioned in reality.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
m) 48= 4-962-0060
e) j= ohn_brzozowski@cable.comcast.com
o) 60= 9-377-6594
w) www.comcast6.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D







-----Original Message-----
From: David Lamparter <equinox@diac24.net>
Date: Wednesday, February 20, 2013 9:41 PM
To: John Jason Brzozowski <john_brzozowski@cable.comcast.com>
Cc: David Lamparter <equinox@diac24.net>, Lorenzo Colitti
<lore= nzo@google.com>, Michael Richardson <mcr+ietf@sandelman.ca>,
"homenet@ietf.or= g Group" <homenet@ietf.org>, Jari Arkko
<jari.arkko@pi= uha.net>, Mark Townsley <mark@townsley.net>
Subject: Re: [homenet] Running code in Orlando

>On Thu, Feb 21, 2013 at 04:17:06AM +0000, Brzozowski, J= ohn wrote:
>> David Lamparter wrote:
>> >On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrot= e:
>> >> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson
>> >> <mcr+ietf@sandelman.ca>wrote:
>> >>
>> >> > Would/could another foot of such a network be on the= IETF network?
>> >> >
>> >>
>> >> If the IETF network didn't respond to DHCPv6 PD reque= sts, it
>>wouldn't be
>> >> much use.
>> >
>> >Even without DHCPv6 PD on the remainder of the IETF network, i= t might
>>be
>> >possible to get a /52../56 and run a DHCPv6 PD ourselves, emul= ating
>>part
>> >of the provider network.
>>
>> Why emulate it? =A0Is the intention here to test the the code on a= n
>> enterprise or corporate network?
>
>The scope of the plugfest is the interior and border of the homenet. = =A0To
>get the border right, we need the service provider side of that border<= br> >in some form. =A0If the IETF network runs DHCPv6-PD, that is an usable<= br> >approximation.
>
>My suggestion was for the case that the IETF network won't be runni= ng
>DHCPv6-PD. =A0In that case, the easiest way to make the IETF network >usable as one uplink for the homenet plugfest is to ask for a /52 to be=
>made available for the plugfest in some static way and then provide
>DHCPv6-PD from that, running on some random PC box/laptop somewhere. >
>Actually - controlling the DHCPv6-PD might be advantageous in order to<= br> >allow tinkering with it to see how the testbed reacts.
>
>
>-David

_______________________________________________
homenet mailing list
homenet@ietf.org<= br> https://www.ietf.org/mailman/listinfo/homenet



--
Dave T=E4ht=

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/= subscribe.html=20 --f46d0401f449f7fedf04d63ea826-- From john_brzozowski@cable.comcast.com Thu Feb 21 08:58:19 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F2F21F8EC3 for ; Thu, 21 Feb 2013 08:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuljXi1VmSMw for ; Thu, 21 Feb 2013 08:58:18 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5E821F8EC1 for ; Thu, 21 Feb 2013 08:58:18 -0800 (PST) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.44197248; Thu, 21 Feb 2013 11:45:07 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Thu, 21 Feb 2013 11:57:15 -0500 From: "Brzozowski, John" To: Dave Taht Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHOEE56UKHjmYjHJk2z+mbkmocqx5iE1hGA//+AAwA= Date: Thu, 21 Feb 2013 16:57:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , Mark Townsley , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:58:19 -0000 Since BnB is one night can we make provisions for the home net lab area to be open all week? Mark? Ray? Seems like it would be worth it. I am thinking all week would be ideal. ;) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Dave Taht Date: Thursday, February 21, 2013 9:35 AM To: John Jason Brzozowski Cc: David Lamparter , Michael Richardson , "homenet@ietf.org Group" , Mark Townsley , Jari Arkko , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando > > > >I am primarily focused on demonstrating solutions to bufferbloat in my >portion of bit's and bytes. > >But I note that the present CeroWrt build appears to have working dhcp-pd >(I've successfully got /56 /60, /61/ /62 subnets from it), and assigning >that to the 6+ internal interfaces, support for every other form of ipv6 >tunneling, the latest dnsmasq which has > some good ways of bonding dns names to ipv6 AAAAs, support for routing >ipv4 and ipv6 subnetworks over the quagga babel protocol (the two routers >I'm demoing are meshed together at 5ghz) > >We had to fix a few nasty instruction traps in the ipv6 stack last month, >but after doing that, I'm pretty pleased with the over-all performance >and reliability - it survived the "thc" ipv6 tests handily, for example. >Could use some more exaustive real-world > testing, so, get it (for the wndr3700v2 and 3800 series) > >http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.5-2/ > >We also have specialized builds for the ubiquity nanostation m5 and >picostation m2hp products deployed in the campground testbed. > >We still haven't done anything with distributing prefixes inside the home >beside ahcp, and I still find the dynamicism required by renting ipv6 >addresses to so impact in so many aspects of the "sane usage of stuff >like printers", and naming, and the security > model as to *demand* ipv6 nat in the home... but I did not get around to >implementing npt66 in this release!! > > >(so those that would flame me for this opinion can hold off (pretty >please!?) until perhaps I can go into the implementation details of all >the many things that break today... with those that care. ) > >In terms of interop, besides dhcp-pd and bufferbloat fixes, I'd rather >like to see if these release can be made to work with ospfv6 on other >devices. What else will be shown? The original homenet code was far too >large to be usable on such a small device, but > perhaps at least the ospf layer could be tried. > >And all that said, I'm rather totally buried with tests for, processing a >ton of data from the field, and testing nfq_codel/bufferbloat. I just >finished giving talks on that at MIT and Stanford on that stuff > >What's wrong with wifi? > >http://www.youtube.com/watch?v=3DWksh2DPHCDI&feature=3Dyoutu.be > =20 >Intro to codel and fq_codel: > >http://netseminar.stanford.edu/ > > > >On Thu, Feb 21, 2013 at 8:14 AM, Brzozowski, John > wrote: > >Statically assigning prefixes may enable testing but is not how homes will >be provisioned in reality. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >John Jason Brzozowski >Comcast Cable >m) 484-962-0060 >e) john_brzozowski@cable.comcast.com >o) 609-377-6594 >w) www.comcast6.net >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > >-----Original Message----- > >From: David Lamparter >Date: Wednesday, February 20, 2013 9:41 PM >To: John Jason Brzozowski >Cc: David Lamparter , Lorenzo Colitti > >, Michael Richardson >, >"homenet@ietf.org Group" , Jari Arkko >, Mark Townsley >Subject: Re: [homenet] Running code in Orlando > > >>On Thu, Feb 21, 2013 at 04:17:06AM +0000, Brzozowski, John wrote: >>> David Lamparter wrote: >>> >On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote: >>> >> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson >>> >> >wrote: >>> >> >>> >> > Would/could another foot of such a network be on the IETF network? >>> >> > >>> >> >>> >> If the IETF network didn't respond to DHCPv6 PD requests, it >>>wouldn't be >>> >> much use. >>> > >>> >Even without DHCPv6 PD on the remainder of the IETF network, it might >>>be >>> >possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating >>>part >>> >of the provider network. >>> >>> Why emulate it? Is the intention here to test the the code on an >>> enterprise or corporate network? >> >>The scope of the plugfest is the interior and border of the homenet. To >>get the border right, we need the service provider side of that border >>in some form. If the IETF network runs DHCPv6-PD, that is an usable >>approximation. >> >>My suggestion was for the case that the IETF network won't be running >>DHCPv6-PD. In that case, the easiest way to make the IETF network >>usable as one uplink for the homenet plugfest is to ask for a /52 to be >>made available for the plugfest in some static way and then provide >>DHCPv6-PD from that, running on some random PC box/laptop somewhere. >> >>Actually - controlling the DHCPv6-PD might be advantageous in order to >>allow tinkering with it to see how the testbed reacts. >> >> >>-David > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet > > > > > > > > >--=20 >Dave T=E4ht > >Fixing bufferbloat with cerowrt: >http://www.teklibre.com/cerowrt/subscribe.html > From fred@cisco.com Thu Feb 21 09:22:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6103A21F8CA7 for ; Thu, 21 Feb 2013 09:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.462 X-Spam-Level: X-Spam-Status: No, score=-110.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+on-uZTDUGn for ; Thu, 21 Feb 2013 09:22:24 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2D31721F8CAC for ; Thu, 21 Feb 2013 09:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2588; q=dns/txt; s=iport; t=1361467344; x=1362676944; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=VM7sgl2JAz/EpcOcIzJiSBcE8UN7yy/Zrq2WxguNS5U=; b=Bi4EH1l+PADYCPdcG7jrAyFwBFOCgwbkHgyEznby9f9UUVO0P1AGFKg5 sA587AMO6YK+InvBlXjn1EXoXOYDSeufBxKy/b3gq+qQBtfQs3eXe7ZUX 62t0jEpHx/X5314PR0yfusuViNwIeoA9ISOfUJSiWYTxrKOVh932A9Guk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMJWJlGtJXG+/2dsb2JhbABFwHyBBBZzgiEBBDo/EgEqFEInBA4NiAoMvxKNPQqBFjGCZmEDl1OPQYMHgWkJFx4 X-IronPort-AV: E=Sophos;i="4.84,710,1355097600"; d="scan'208";a="179710636" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 21 Feb 2013 17:22:23 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1LHMMqe010310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 17:22:22 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 11:22:22 -0600 From: "Fred Baker (fred)" To: "homenet@ietf.org Group" Thread-Topic: Egress Routing Discussion Thread-Index: AQHOEFgCGK9BIkojDUCI/aEwNxU6xw== Date: Thu, 21 Feb 2013 17:22:22 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B79DAEF@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.253] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" Subject: [homenet] Egress Routing Discussion X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 17:22:25 -0000 In Atlanta, Mark asked Lorenzo and I to put together a draft of an approach= to source/destination, and especially egress, routing. I pulled together a= plan of attack that I applied to both IPv4 and IPv6, and to both IS-IS and= OSPF and sought review from a limited list including Lorenzo; this include= s capabilities for at least one other use case I'm looking at. Mark asked m= e to cut that down to make things separately implementable (which they woul= d be anyway, but to make it apparent). So I have broken it into components. So we have several drafts in play at this IETF. Shu Yang documented his work in Quagga, in which he implemented source/dest= ination routing as a multi-topology routing model. http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu Yang, Jianping Wu, Dan Wang, 18-Feb-13 Ole Troan and Lorenzo Colitti documented their model, which is strictly egr= ess routing based on the OSPF AS-prefix-LSA and the assumption of automated= prefix allocation. This is not multi-topology; it in effect tags the defau= lt route advertised as a route from an alternate universe. http://tools.ietf.org/html/draft-troan-homenet-sadr "IPv6 Multihoming with Source Address Dependent Routing (SADR)", Ole Troan, Lorenzo Colitti, 18-Feb-13 I have documented my approach, which provides the generalized concept, is b= uilt into the routing protocols IS-IS and OSPF, and also addresses at least= one other "tagged routing" option, which is to look at flow labels. http://tools.ietf.org/html/draft-baker-ipv6-isis-automatic-prefix "Automated prefix allocation in IS-IS", Fred Baker, 18-Feb-13 http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing "Using IS-IS with Role-Based Access Control", Fred Baker, 17-Feb-13 http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 17-Feb-13 http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing "Using OSPFv3 with Role-Based Access Control", Fred Baker, 17-Feb-13 http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 17-Feb-13 http://tools.ietf.org/html/draft-baker-ipv6-ospf-extensible "Extensible OSPF LSAs", Fred Baker, 17-Feb-13 I'll say why I think mine is the correct approach in another email, as I im= agine my colleagues will for theirs. But the working group should consider = the question.= From mcr@sandelman.ca Thu Feb 21 10:31:50 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0905721F8F4C for ; Thu, 21 Feb 2013 10:31:50 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-2Lw4azcwNr for ; Thu, 21 Feb 2013 10:31:49 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 79A2B21F8F31 for ; Thu, 21 Feb 2013 10:31:49 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 51ACB2016D; Thu, 21 Feb 2013 13:38:39 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 20E0C6387F; Thu, 21 Feb 2013 13:30:41 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 109786387D; Thu, 21 Feb 2013 13:30:41 -0500 (EST) From: Michael Richardson To: "Fred Baker (fred)" In-Reply-To: <8C48B86A895913448548E6D15DA7553B79DAEF@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B79DAEF@xmb-rcd-x09.cisco.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Egress Routing Discussion X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 18:31:50 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "fred" =3D=3D fred > writes: fred> In Atlanta, Mark asked Lorenzo and I to put together a draft fred> of an approach to source/destination, and especially egress, fred> routing. I pulled together a plan of attack that I applied to fred> both IPv4 and IPv6, and to both IS-IS and OSPF and sought fred> review from a limited list including Lorenzo; this includes fred> capabilities for at least one other use case I'm looking fred> at. Mark asked me to cut that down to make things separately fred> implementable (which they would be anyway, but to make it fred> apparent). So I have broken it into components. wow, thank you for this reading list. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUSZn0IqHRg3pndX9AQKk0QQA3MMmsyTtMbN+Ai7o0iENRemWdczzUHCa EGvv7ms4+R+tJHQANGZfq7Miqb4f+UC02zEYp7N4Tujoppooe/2CcoS/NYQkOTJx 4fAuSn+2a2Ua0WJ4dOnISQWtEYNhwxgYN35to5s/CaJMEU8ZkOiWJ26bSvxjJLaG i+QnwiIyicE= =H3uO -----END PGP SIGNATURE----- --=-=-=-- From fred@cisco.com Thu Feb 21 11:23:11 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2573E21F8F64 for ; Thu, 21 Feb 2013 11:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.468 X-Spam-Level: X-Spam-Status: No, score=-110.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-6ylW91V-nU for ; Thu, 21 Feb 2013 11:23:09 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCCE21F8F65 for ; Thu, 21 Feb 2013 11:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11975; q=dns/txt; s=iport; t=1361474586; x=1362684186; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4nkGpZQN79GYkk5Ltg05K/R1xfAZW0WE5XFnkqHSUeo=; b=JI479jawzYV68Lh8mgdlHNwSag2cuZiOYK+4oN3143idPm56z84/Amuq SRCEUPBJ9AFmEFJDU3LYQDajOxZ26QDNIADEwEiX9EY1VmqoY3z0GKLUT +fSV7gSgrpy6awHpJ7mP38jVtHZ0CJKfL6Sprghb4EKDIDVqupNqRRGgB c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHlzJlGtJV2a/2dsb2JhbAA/BsELgQUWc4IfAQEBAwE6NgkFCwIBKhQQMiUCBAoEBQiIBAYMvy+NPQoSgQQxB4JfYQOXU49BgweBaQkXHg X-IronPort-AV: E=Sophos;i="4.84,711,1355097600"; d="scan'208";a="179790794" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 21 Feb 2013 19:23:05 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1LJN5mH006319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 19:23:05 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 13:23:03 -0600 From: "Fred Baker (fred)" To: "homenet@ietf.org Group" Thread-Topic: Egress Routing Discussion: Baker model Thread-Index: AQHOEGjePDmfY0YTWU22pYhqqdemMQ== Date: Thu, 21 Feb 2013 19:23:03 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> In-Reply-To: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.104] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" , "Abhay Roy \(akr\)" Subject: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:23:11 -0000 On Feb 22, 2013, at 6:22 AM, Fred Baker wrote: > In Atlanta, Mark asked Lorenzo and I to put together a draft of an approa= ch to source/destination, and especially egress, routing. I pulled together= a plan of attack that I applied to both IPv4 and IPv6, and to both IS-IS a= nd OSPF and sought review from a limited list including Lorenzo; this inclu= des capabilities for at least one other use case I'm looking at. Mark asked= me to cut that down to make things separately implementable (which they wo= uld be anyway, but to make it apparent). So I have broken it into component= s. >=20 > ...... >=20 > I have documented my approach, which provides the generalized concept, is= built into the routing protocols IS-IS and OSPF, and also addresses at lea= st one other "tagged routing" option, which is to look at flow labels. >=20 > http://tools.ietf.org/html/draft-baker-ipv6-isis-automatic-prefix > "Automated prefix allocation in IS-IS", Fred Baker, 18-Feb-13 >=20 > http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing > "Using IS-IS with Role-Based Access Control", Fred Baker, 17-Feb-13 >=20 > http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing > "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 17-Feb-13 >=20 > http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing > "Using OSPFv3 with Role-Based Access Control", Fred Baker, 17-Feb-13 >=20 > http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing > "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 17-Feb-13 >=20 > http://tools.ietf.org/html/draft-baker-ipv6-ospf-extensible > "Extensible OSPF LSAs", Fred Baker, 17-Feb-13 >=20 > I'll say why I think mine is the correct approach in another email, as I = imagine my colleagues will for theirs. But the working group should conside= r the question. This is that separate email. As I start, may I make the most direct possibl= e apology to my colleagues with other approaches. I'm going to say that I t= hink you're "wrong", and say why. That is in the spirit of open discussion = in which we have a technical disagreement. BTW, you should be aware that I = have a fair set of people who are telling me I'm wrong as well, hopefully i= n the same spirit. Some of them are pretty irritated with me, and I have go= tten irritated with them. Two parts of the question here relate to "what problem do we think we're so= lving" and "how do we model the network". A third will be "how do we implem= ent it in a router?" Homenet, I believe, thinks it's solving "how do I provide egress routing wi= th zero, or perhaps epsilon, configuration, using open source code in the c= heapest possible implementation." That's laudable; that said, I do believe = that egress routing is a requirement for any IPv6 network involving multipl= e provider-allocated prefixes, and that as a result this is something to be= built into the base protocol. In OSPF terminology, it is sufficient to bui= ld on an AS-external-LSA if that's the only source/destination route to be = considered (it is certainly a principal use case); for a general network, h= owever, we don't generally carry a lot of AS-external information around. S= o we need, I think, the ability to use native default routes as well as AS-= external default routes, which means that we also need to look at the intra= -area-prefix-LSA and the inter-area-prefix-LSA. The problem, I argue, is ho= w to tag a route with a set of attributes and apply a route policy to it. O= ne possible attribute is the source prefix that might be used by systems co= mmunicating with this destination, and there are other possible attributes.= The route policy is that traffic is forwarded to a stated destination if a= nd only if it also matches the other specified attributes. So, when we want= to source/destination route to a specified egress, the destination in ques= tion is a default route (::/0), the source is the relevant PA prefix, and w= e are asking the network to build routes in the way it natively does so for= traffic that has the specified set of attributes. As to "how we model it", there are at least two possible approaches. When J= on Moy was first building what we now call OSPF, one of the problems that t= he Internet was dealing with was congestive collapse. There were several ex= periments, one of which I was involved in with Neil Bierbaum of NASNET, in = which we wanted to send interactive traffic using paths that had relatively= low delay, and high volume file transfer traffic on other paths that had h= igh throughput. It was not unusual for those "high throughput" paths to als= o have long delay, such as through a geosynchronous satellite. The technolo= gy for doing this was originally documented, at least publicly, in RFCs 113= 1 and 1247, commented on in RFC 1812, and has evolved to RFC 4915's Multi-t= opology Routing; it was developed in parallel in IS-IS as well. The multi-t= opology model is based on the premise that routers and/or links differ from= each other in some important way, such as capacity, delay, or capability (= do they support IPv6? Do they have a stated diffserv configuration?), and t= hat it is useful to segregate them into sub-topologies and build routes wit= hin those topologies. The other possible model, which I am following, presu= mes that one is not routing "to a destination", although arriving at an int= ended destination is an important facet, or "through a specific topology"; = ultimately, one is routing a class of traffic, as I described in http://too= ls.ietf.org/html/draft-baker-fun-routing-class. That class of traffic (as s= een by a given router) consists of the datagrams that will pass through a s= tated router and have some set of attributes, which might include destinati= on address, source address, a flow label, a DSCP, or several other characte= ristics. For a DSCP, topology is important - I need to know whether the lin= ks have the attributes I am asking about. Those other attributes are not, i= n my view, topology-relevant - they simply help define the class of traffic= .=20 So I'm modeling the routing of a class of traffic identified by a set of at= tributes in what is otherwise a single topology. When you looked at my list of documents, you no doubt thought "the working = group is focused on OSPF as the routing protocol; why IS-IS?" I looked at I= S-IS first because it is the simplest to update in this way. The way IS-IS = works is that each router advertises an at-least-in-concept single Link Sta= te PDU (LSP) that contains information about itself and its neighborhood. T= he information is stored in type-length-value (TLV) objects, and the LSP is= in essence a list of them describing a single router. Each router starts w= ith its own LSP, determines how it will reach its neighbors, and then their= neighbors, and so on until it has figured out how to reach every router in= the network (including LANs, which are modeled as virtual routers called p= seudonodes). Along the way, it also discovers that routers advertise reacha= bility of various kinds: "if you have a route to me, I can deliver data to = <>", where <> might be an AppleTalk subnet, an IPv4 subnet (RFC 1195), an I= Pv6 subnet (RFC 5308), or any of a number of other things. RFC 5308 specifi= es such a TLV, which specifies an IPv6 prefix with some attributes like how= it got into the network. It also specifies the ability to have sub-TLVs, T= LVs that specify additional attributes for the larger TLV, although it does= n't define any. Those are for "future extension". Welcome to the future. So, from my perspective, in the routing protocol, we need to specify sub-TL= Vs for any additional attributes, such as source prefixes, that we want to = include, and IS-IS has given us that capability. What's necessary next is a= FIB that the routes can be stored into. I'll come to that later. Of course, IS-IS isn't going to be very useful in homenet without a way to = allocate prefixes to LANs. draft-baker-ipv6-isis-automatic-prefix is in ess= ence draft-ietf-ospf-ospfv3-autoconfig for IS-IS. Shoot me. But we wanted to do this in OSPF. Here, I have a problem. OSPF is designed = with fixed LSAs, not extensible LSAs, so adding an attribute to an LSA is d= ifficult without fundamentally changing the LSA. I started by defining a se= t of extensible LSAs in draft-baker-ipv6-ospf-extensible; they are direct c= ounterparts to RFC 5340's LSAs, and intended to be backward-compatible with= them. I'm not stuck on exactly that approach; I have since found that an e= xtensible LSA was considered and set aside by the working group in 2006/200= 7, in http://tools.ietf.org/html/draft-ietf-ospf-mt-ospfv3. Give me an appr= oach that gives me the ability to add a sub-TLV to an OSPF LSA such as I di= d for IS-IS, and I'm pleased as punch. draft-baker-ipv6-ospf-dst-src-routin= g is a direct counterpart to draft-baker-ipv6-isis-dst-src-routing, and dra= ft-baker-ipv6-ospf-dst-flowlabel-routing is a direct counterpart to draft-b= aker-ipv6-isis-dst-flowlabel-routing; they add attributes to an extensible = LSA. The theory is the same. Which brings us, I suppose, to the FIB. There are many ways a FIB can be de= signed, and I would expect every vendor to do it their own way; this is not= a matter for standardization. However, to have the discussion, it seems im= portant to at least mention some possible approaches. In appendices in the = drafts, I mention two. They are far from the only two; they are two. Mark felt it was important to specifically state how these might play with = the Waikato source address routing extensions in Linux, so I addressed that= . I generalized it a little bit; there is a trade-off, and I wanted to comm= ent on it. The premise in Waikato is that one identifies the source prefix = and uses that to select a destination FIB. In terms of writing code quickly= , that's a reasonable approach; the FIB itself is already designed, the que= stion is how to have more than one of them. My question is how many FIBs on= e might have, and what memory impacts that might imply. In a generalized mo= del, one could imagine having quite a number of FIBs. But now, what routes = do we expect to put into those FIBs? I expect that, at least in a small-to-= medium sized network, one has some number of PA prefixes and as many egress= default routes; most of the routes, whether few or many, are traditional d= estination routes within the domain. So, I can have a FIB per PA prefix, pu= t egress default routes only into the FIBs for their source prefixes, and p= ut every single destination route into each FIB. That results in a potentia= lly-large number of FIBs, each of which contains mostly-identical informati= on. If memory is a concern, I throw out a second option; I could have a des= tination-only FIB and a set of PA prefix-specific FIBs, which are usually r= elatively small, perhaps only a single route. When you do a route lookup, y= ou look in both the destination-only FIB, which will find local routes, and= the PA-relevant FIB, which will get you a default route, and use the one t= hat is most specific. That said, I think there is a much simpler approach, although it may take s= ome time to explain. A PATRICIA trie is a structure originally discussed in= 1968 for searching through ASCII text, and used in route tables. It allows= you to build a set of discontiguous bit strings, and do a radix search thr= ough the trie. For the details, I'll refer you to discussions of PATRICIA t= ries on the web and the appendix in the document.=20 So there are at least two possible FIB approaches; there are no doubt other= approaches, and they might be better. To each his or her own.= From mcr@sandelman.ca Thu Feb 21 12:36:55 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7D721F8F5A for ; Thu, 21 Feb 2013 12:36:55 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYuWMhlcU8L0 for ; Thu, 21 Feb 2013 12:36:54 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 21DC721F8EE6 for ; Thu, 21 Feb 2013 12:36:54 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7CE482016D for ; Thu, 21 Feb 2013 15:43:44 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E6C3F6387F; Thu, 21 Feb 2013 15:35:45 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D7F666387D for ; Thu, 21 Feb 2013 15:35:45 -0500 (EST) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 20:36:55 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Fred, I'm not sure that foo-chairs@ needs to be CC'ed on this discussion? Having not been through your documents yet... >This is that separate email. As I start, may I make the most direct possib= le >apology to my colleagues with other approaches. It would be helpful for me if you identified the different approaches. You have taken an approach that involves extending the LSA of ISIS (easy according to you) and of OSPF (harder, due to lack of sub-TLV). The fundamental approach is to flood the set of all link attributes and then: > The route policy is that traffic is forwarded to a stated > destination if and only if it also matches the other specified > attributes.=20=20 > Which brings us, I suppose, to the FIB. There are many ways a FIB can > be designed, and I would expect every vendor to do it their own way; > this is not a matter for standardization. However, to have the > discussion, it seems important to at least mention some possible > approaches. In appendices in the drafts, I mention two. They are far > from the only two; they are two.=20=20 this is completely akin to IPsec's RFC2401/4301's need to provide a set of functional requirements on the SPD, but not actually specify how to implement it.... thank you for bringing this up! > So, I can have a FIB per PA prefix, put egress default routes only > into the FIBs for their source prefixes, and put every single > destination route into each FIB. That results in a potentially-large > number of FIBs, each of which contains mostly-identical > information.=20 Worse perhaps is that the FIB's are mostly optimized to have large number of routes, and that optimization is mostly wasted here, because the homenet has perhaps nPA * nRouters subnets + default routes. Meanwhile, the source address selection process in Linux is mostly implemented as a linear search, although there is nothing requiring this. IPsec 2401/4301 has the same problem, and we would up ordering the SPD rather than specifying the order of evaluation for the various longest-prefix-match searches, port and protocol parts of the SPD. Fortuantely, most IPsec has had such lackluster uptake that outside of the contrived examples that I wrote as test cases, few ever run into a situation where two gateways pick different tunnels for traffic in two directions. I point to Appendix B of RFC4301 as a way to turn ordered entries into something that a PATRICIA trie/LPM engine can better deal with. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUSaFIYqHRg3pndX9AQIJtgP/ch28j2ezYlm+mpXw91haj7gl2XPBfoZn KoNUR8Eysql8wRDXlTFgH632NtrKR6NxIn5ksgkUzArhWgZjxrZZ/HUBRH+RULNG L0h+oFsLxLOQpxCK9Hvq/UHBn32tVrUlA7nmgu1MYX4k4EipzdQDbzj8iN4t58tA YOMBx4fW+2k= =m8aN -----END PGP SIGNATURE----- --=-=-=-- From lorenzo@google.com Thu Feb 21 16:42:04 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED06F21E8039 for ; Thu, 21 Feb 2013 16:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.946 X-Spam-Level: X-Spam-Status: No, score=-102.946 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0-HUghRhFNY for ; Thu, 21 Feb 2013 16:42:04 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id EC77C21E8034 for ; Thu, 21 Feb 2013 16:42:03 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id o17so119417oag.6 for ; Thu, 21 Feb 2013 16:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Vx/7QPgEGyyh7b3rqCViRxUmFpCHfn/qB2Qpx4ocOW4=; b=UX7SOVkE4F5XInAWfodXPkqgK5ngrrnkeMPFQVPBQ/jme/Q0oH0lb7OmJau5ec0zEN 3AbC9rIKb/+a60oe/T2f+VBQD1716PrcnIUHvHkxdfYVnHJU/0Sdzp3DOO7l5Gs/QpO7 SqeCwzPdZ+9DIXHC7vHLCCaRSX8HUyNUOXzNJrtg1UUId6Zhl6KrVfmkdOxEwxS3qa/C mZX7uPf5jmGK/CXCHFu8ZIuLYhJSatAyB7Eu2KyB7mCU/7AHgVxO6Ged6Xjsa7UuZEDM pQZkgDJSri1t0YloZVRNW2+Mr4n0d38stVVAw7nz4jRIEQhapcRALbEUYneeD/tFvR14 El/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Vx/7QPgEGyyh7b3rqCViRxUmFpCHfn/qB2Qpx4ocOW4=; b=Ytt2Vn7mpRsx+t75/g9qcylsO2NDAzyuzp/pvCFxvGk1UkAipfhZk0pWU/HOt4SBm6 9rrHQylxJWRC8wZGT5PCFpYZfcOWtpV/d2FMhMZfu0fyzvqsdZABN45HUfJRcp5J0y+s A9nSayojSOnnDmn3rUW2mnI0TdruV8gO3Gxbd5pzHXrwmNfMP5R2xAaaXz8j0NqvCGej 97DDmAKNN446j8polLycPqZ7TtEANPphE6mApkTnkhHIpu2NnfThuLgmAeDTWzb58WfX fzDvA8bxm1k7S4n1G/Go6lKes/jZJ2FoZEuMwhZBma9j7BAEjs2Z7CI2IhFmkqivKEY1 se9g== X-Received: by 10.60.169.178 with SMTP id af18mr11954418oec.133.1361493723328; Thu, 21 Feb 2013 16:42:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Thu, 21 Feb 2013 16:41:42 -0800 (PST) In-Reply-To: <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> From: Lorenzo Colitti Date: Fri, 22 Feb 2013 09:41:42 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=bcaec54b45acbe501604d64575ed X-Gm-Message-State: ALoCoQnAs3s6zYWHUAPlQtK4+bDjvnada5KL+cy+znGGFS+EY4IWh6D/Iv90DwqqQ16ABphtvJxUOTAt4+sEx+dB3hX90CxzvKGUDeCPInNm97/RO5i6+WxXPX9z18BuJVkxiG1U+mILRGz2YtRWBZwLVdjtfz5aS9m5YT4fWMqI2F87N0oKPo7p9AyYEI6gU9eL1XmlIjZg Cc: "homenet@ietf.org Group" , "Abhay Roy \(akr\)" , "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 00:42:05 -0000 --bcaec54b45acbe501604d64575ed Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 22, 2013 at 4:23 AM, Fred Baker (fred) wrote: > This is that separate email. As I start, may I make the most direct > possible apology to my colleagues with other approaches. I'm going to say > that I think you're "wrong", and say why. That is in the spirit of open > discussion in which we have a technical disagreement. BTW, you should be > aware that I have a fair set of people who are telling me I'm wrong as > well, hopefully in the same spirit. Some of them are pretty irritated with > me, and I have gotten irritated with them. > For what it's worth, as as a co-author of draft-troan-homenet-sadr-00, I don't think there is a disagreement. The draft cites your work, because we (or at least, I) think that the correct approach is in fact one where the routing protocol passes around source+destination routing pairs. The reason why the draft also proposes a simplified version of SADR that integrates with prefix assignment protocol is that it's possible to implement this without having to make substantial changes to OSPF. Extending the routing protocols will be a long and possibly hard road, and we feel that the group should at least consider the possibility of an approach with better time-to-market and lower barrier to implementation - especially since the alternatives being proposed are hierarchical DHCPv6 PD and NPT66. The risk is that we make the perfect the enemy of the good and we end up with NPT66, which means that we will have thrown away the chance for end-to-end IPv6 connectivity and will have to build apps in IPv6 just as we did in IPv4 - forever trying to guess what their addresses are, which magic packet incancation will work, and which third-party server is the best to relay packets through. On the OSPF vs. IS-IS choice... well, if we had an implementation of ISIS that could run on home networking devices, or if there was at least one on the horizon, things would be very different. --bcaec54b45acbe501604d64575ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 22, 2013 at 4:23 AM, Fred Baker (fred) <fred@cis= co.com> wrote:
This is that separate email. As I start, may I make the mo= st direct possible apology to my colleagues with other approaches. I'm = going to say that I think you're "wrong", and say why. That i= s in the spirit of open discussion in which we have a technical disagreemen= t. BTW, you should be aware that I have a fair set of people who are tellin= g me I'm wrong as well, hopefully in the same spirit. Some of them are = pretty irritated with me, and I have gotten irritated with them.

For what it's worth, as as a co-= author of draft-troan-homenet-sadr-00, I don't think there is a disagre= ement. The draft cites your work, because we (or at least, I) think that th= e correct approach is in fact one where the routing protocol passes around = source+destination routing pairs.

The reason why the draft also proposes a si= mplified version of SADR that integrates with prefix assignment protocol is= that it's possible to implement this without having to make substantia= l changes to OSPF. Extending the routing protocols will be a long and possi= bly hard road, and we feel that the group should at least consider the poss= ibility of an approach with better time-to-market and lower barrier to impl= ementation - especially since the alternatives being proposed are hierarchi= cal DHCPv6 PD and NPT66. The risk is that we make the perfect the enemy of = the good and we end up with NPT66, which means that we will have thrown awa= y the chance for end-to-end IPv6 connectivity and will have to build apps i= n IPv6 just as we did in IPv4 - forever trying to guess what their addresse= s are, which magic packet incancation will work, and which third-party serv= er is the best to relay packets through.

On the OSPF vs. IS-IS choice... well, if we= had an implementation of ISIS that could run on home networking devices, o= r if there was at least one on the horizon, things would be very different.=
--bcaec54b45acbe501604d64575ed-- From lorenzo@google.com Thu Feb 21 17:07:07 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F7C21F8740 for ; Thu, 21 Feb 2013 17:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKngkXItU2X2 for ; Thu, 21 Feb 2013 17:07:06 -0800 (PST) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id B02D621F873C for ; Thu, 21 Feb 2013 17:07:06 -0800 (PST) Received: by mail-oa0-f51.google.com with SMTP id h2so134749oag.10 for ; Thu, 21 Feb 2013 17:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/607MKXO/KgVgJMSnZN5cJ0CVtl7TqSrzoWlgGzxCsQ=; b=R+JFyOTCka6RsvODO7xdARzB7VrOpY2p7XOATxdXwPzO5wmkhkSLEuSuoQfm0AWvZk RL42xS5xXYel/iRBh0hdriQKRzbOGDa8KcS/0otv21QNrlpil3V8GRrDeqTdf47j3k3L L4uYK68AUZxA3AOrmGcmbnma1Zv6wzAAf5EWchYTFSmdrFLPS0LtSiebmWDSxkPXcbOI EcIjCLx8JifOH0+aXfp0bIYW1sth3eShN12syh6YNnm0ATF0h4hDROqYvZHhdIO2tGua J1XoTfKkqcSBcBVnztGlF7gqNR4aiLmnhbULa7vFrmuYunATi4jEI2PjiFpFjiCKkgKM 9LfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=/607MKXO/KgVgJMSnZN5cJ0CVtl7TqSrzoWlgGzxCsQ=; b=O8rZLtx4tGJyzBELSju+6GWMZ48qYdkIVtMe79H2l0avDKHC+j8zTuY3keXQJr3v0z +n6irmQntU60dbGUIkhZMxbzL4iDJo1bEO8pS9EaQh/EfzvHuYWXwsD79GKp8dOrdsuV vczw03JdjImpj+JUWlfeMFr+F24ne+zQxEsbkjKW5qfkWwTjibfOeYcDtpFmqm0GJJTD GUxyPpXQp+JNx1q3dmnzmtW2JGGxHLeKl/JwQ1Nacn42oZugiFpcbkbDxCMTqnWBpNI2 bXX9PLxe+Mo+E+ruVWQPkgH/RohA8rOw/Qdg2bhXn0zJxtAuv5hA4POpBrtl6tjG+hps d0tw== X-Received: by 10.60.170.140 with SMTP id am12mr21063oec.125.1361495225836; Thu, 21 Feb 2013 17:07:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Thu, 21 Feb 2013 17:06:45 -0800 (PST) In-Reply-To: References: <20130221044128.GD2799359@jupiter.n2.diac24.net> From: Lorenzo Colitti Date: Fri, 22 Feb 2013 10:06:45 +0900 Message-ID: To: Dave Taht Content-Type: multipart/alternative; boundary=bcaec54b48124d1a6a04d645cf49 X-Gm-Message-State: ALoCoQm8yMYpCg3+IWrZZCrnx2T+XAEPlXjbCXVPML/65f29gM5mCm2vQS4CHHW/FaC/kIOxp9P/2aGEl6PLmPfjw/lwSGKdXeBNw0krGtB+HAvwzz46agoL7YduFw4QYcOg/3uEGY+SrjzzPkIKYdBWngEdMqxR0YTzhCAPiqg0HUtpHCiP1SZAAP7biqhVdCGC54ivY02L Cc: Michael Richardson , Mark Townsley , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 01:07:07 -0000 --bcaec54b48124d1a6a04d645cf49 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 22, 2013 at 1:35 AM, Dave Taht wrote: > I still find the dynamicism required by renting ipv6 addresses to so > impact in so many aspects of the "sane usage of stuff like printers", and > naming, and the security model as to *demand* ipv6 nat in the home... Sigh. --bcaec54b48124d1a6a04d645cf49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 22, 2013 at 1:35 AM, Dave Taht <dave.taht@g= mail.com> wrote:
I still find the dynamicism required by rent= ing ipv6 addresses to so impact in so many aspects of the "sane usage = of stuff like printers", and naming, and the security model as to *dem= and* ipv6 nat in the home...

Sigh.=A0
--bcaec54b48124d1a6a04d645cf49-- From mcr@sandelman.ca Thu Feb 21 17:32:51 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3DD21F882F for ; Thu, 21 Feb 2013 17:32:51 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZLqQUgT+L+d for ; Thu, 21 Feb 2013 17:32:50 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id C7A4321F882E for ; Thu, 21 Feb 2013 17:32:50 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CC4402016D; Thu, 21 Feb 2013 20:39:33 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 3CE796387F; Thu, 21 Feb 2013 20:31:34 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 14B716387D; Thu, 21 Feb 2013 20:31:34 -0500 (EST) From: Michael Richardson To: fred@cisco.com, homenet@ietf.org X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 01:32:51 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable {possible resend} Fred, wrt: draft-baker-ipv6-isis-automatic-prefix-00 for a network where there is more than one ISP, is it acceptable for a CPE that has decided that it is PREFIX1:0123::/64 (and gone through the process of advertising it and backing things off...), to "randomly" decide to be PREFIX2:0123::/64 when it sees PREFIX2? I.e. the "0123" is identical for the two prefixes? This seems a desireable (but not required) property that all the prefixes on a LAN are similar. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUSbKdYqHRg3pndX9AQIbYQP/XaIBVRfXbu0U51y9LPgGpe0DduRAPheZ euBXLc1YHsZWcJY9W2VIYgdcCLEWshTTZZi0mzL/DA8nPGjBpIMgImfjAcZloRQm TNXIl7LNwGKhXsgExSKK1p+NCntK77KWMcEXFhQU4QTCnu0MlnltJj473pjZ2est eZfeQ0IyPd0= =esWP -----END PGP SIGNATURE----- --=-=-=-- From mike@mtcc.com Thu Feb 21 17:35:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E5621E803D for ; Thu, 21 Feb 2013 17:35:14 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+ufDBIFD8Pf for ; Thu, 21 Feb 2013 17:35:13 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id C7C6C21E803A for ; Thu, 21 Feb 2013 17:35:13 -0800 (PST) Received: from piolinux.mtcc.com (63-171-70-46.dsl.volcano.net [63.171.70.46] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1M1YOqm014408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 17:34:26 -0800 Message-ID: <5126CB1D.70705@mtcc.com> Date: Thu, 21 Feb 2013 17:34:21 -0800 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Lorenzo Colitti References: <20130221044128.GD2799359@jupiter.n2.diac24.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=949; t=1361496867; x=1362360867; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Running=20code=20in=20Orlan do |Sender:=20 |To:=20Lorenzo=20Colitti=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=pc1czCmh+i+BPuYHWrw2zo9cH0HKKCP4kbNXi8AtDiw=; b=VOFXR3evbm+pS3UrcCmCwNuDymVJfDS+AI8xGSpChKTyJ09OCxmd2P0LHX Ht9UJvfKwHqjJVWXE1HGOtMDCVANz31mtmTgu8yQL9Rb2ZJlKXzyU1WK/Lkr ynN7YCa5RlmFXa/syaYfvNTk8o5UVfwdUAxwpN18pyr8qm57QggLw=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 01:35:14 -0000 Lorenzo Colitti wrote: > On Fri, Feb 22, 2013 at 1:35 AM, Dave Taht > wrote: > > I still find the dynamicism required by renting ipv6 addresses to so > impact in so many aspects of the "sane usage of stuff like > printers", and naming, and the security model as to *demand* ipv6 > nat in the home... > > > Sigh. Sigh all you like, but I share Dave's skepticism that ISP's renumbering my prefix willy-nilly and it just sort of works with naming -- including addresses squirrelled away in places they ought not be -- is going to work any time soon. I don't like to think that NAT is inevitable but frankly the people in this working group don't get to vote on that. Speaking to the title of this thread: has anybody actually demonstrated such a thing end to end? It strikes me as Frankensteinian when you get all of the body parts bolted together. Mike From lorenzo@google.com Thu Feb 21 17:48:37 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C018D21F86B2 for ; Thu, 21 Feb 2013 17:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.951 X-Spam-Level: X-Spam-Status: No, score=-102.951 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHTH-BWrRLtx for ; Thu, 21 Feb 2013 17:48:36 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id A5E0D21F86AB for ; Thu, 21 Feb 2013 17:48:36 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id m1so154981oag.26 for ; Thu, 21 Feb 2013 17:48:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=p+Z3ollHG4geLHaMfU7U9z4Y4wcZl5HLwlYpuZD1kOU=; b=MgdT1ss7RcQ1SHBapYZMhAQEkuWp/Y/oGCQUGXoo/bh7DkYpztVX2hCDhhf5SYSqFJ wf2GIUMFrYCQ1l+dpZf16ggVj+L1reWDg1rqvB8ycuLQ4ipmev0AB98wF2wzyHY363PL Zy2Fy6nuEyIg6wQzB683H8F82NSOlZDjI+LyT7kHEmKTghuKFyCON1truH7O4G6dv/q4 8aAMg0CfYMnEgTiR9gY+iICkYraMIPGURtOZdM0cU9iElFW+6LesOMqYZ/7fG/vbgqb+ TL/el33F2Z7OH8oBj/3TZ+k4DaV81YNVIrggIIEBpxjpy9OvkxyCo1BXm9ueaXMU3aZ4 8zCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=p+Z3ollHG4geLHaMfU7U9z4Y4wcZl5HLwlYpuZD1kOU=; b=iDoMIoC6OI5PtskJjFBtzOXV79meOUW1cvvxiA5CV+HMTYqTFZoSR5WzBftS0SEExB H7SzAOTD+AMDR928aXE7gVV5+9HyOKx9AnXfMYI5k00kBQyUi90NjYz+NqdoRECY97k9 QmuaTmrndnkqK0cEVgVg5sduOhWI0d3Lt69RrFz7jlp/R8R1FE08BuKTzuNXvozG+0/y UvABoPRykRKR2p6H+p5LNhLM9lvvDyleqSiGGAMxOfXFroVEJZY1wE7htFRgUaIjEjMx JWV92QOuWtQwUTyc8Cc9bInHkHfF2HVRcDNt6roCh2RmzkoKLlSb1ujnh9JTccmfuv5K RT5g== X-Received: by 10.60.11.106 with SMTP id p10mr71496oeb.94.1361497716134; Thu, 21 Feb 2013 17:48:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Thu, 21 Feb 2013 17:48:16 -0800 (PST) In-Reply-To: <5126CB1D.70705@mtcc.com> References: <20130221044128.GD2799359@jupiter.n2.diac24.net> <5126CB1D.70705@mtcc.com> From: Lorenzo Colitti Date: Fri, 22 Feb 2013 10:48:16 +0900 Message-ID: To: Michael Thomas Content-Type: multipart/alternative; boundary=e89a8fb1eaf6bc5ed804d646637e X-Gm-Message-State: ALoCoQlWyaYMIBpPMXzaxmAFmjmehQIGpT2N78CtTfxRSRa1z+EaUKkMXPC6azaf0Fq8o35T50T0UEnChd3ZuvqPQEmHCf+q7/4ib9TJp4xPxxX8xFvXYtwKcWThJx8myS5TrDm8Lhd4+zpGdxk96bTCzy5B2w8jaiX5/7pOoSARRHPFKFo8jHTXFezMSrlxYnjm12ipxEnE Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 01:48:37 -0000 --e89a8fb1eaf6bc5ed804d646637e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 22, 2013 at 10:34 AM, Michael Thomas wrote: > Sigh. >> > > Sigh all you like, but I share Dave's skepticism that ISP's renumbering my > prefix willy-nilly and it just sort of works with naming -- including > addresses squirrelled away in places they ought not be -- is going to work > any time soon. That's why we have ULAs and multiple prefixes. I don't like to think that NAT is inevitable but frankly the people in this > working group don't get to vote on that. > Actually they do. They have the freedom to specify alternatives, and depending on how good a job they do, implementers may choose to use them. > Speaking to the title of this thread: has anybody actually demonstrated > such a thing end to end? It strikes me as Frankensteinian when you get all > of the body parts bolted together. > What thing exactly? Multiprefix multihoming? End-to-end connectivity in general? --e89a8fb1eaf6bc5ed804d646637e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 22, 2013 at 10:34 AM, Michael Thomas <mike@mtcc.c= om> wrote:
Sigh.

Sigh all you like, but I share Dave's skepticism that ISP's renumbe= ring my prefix=A0willy-nilly and it just sort of works with naming -- inclu= ding addresses squirrelled=A0away in places they ought not be -- is going t= o work any time soon.

That's why we have ULAs and multiple prefixes.=

I don't like to=A0think that NAT is inevitable but frankly the people i= n this working group don't get=A0to vote on that.
=
Actually they do. They have the freedom to specify alternati= ves, and depending on how good a job they do, implementers may choose to us= e them.
=A0
Speaking to the title of this thread: ha= s anybody actually demonstrated such a thing=A0end to end? It strikes me as= Frankensteinian when you get all of the body parts bolted=A0together.

What thing exactly? Multiprefix multihomin= g? End-to-end connectivity in general?
--e89a8fb1eaf6bc5ed804d646637e-- From mike@mtcc.com Thu Feb 21 17:57:58 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0FF21F8763 for ; Thu, 21 Feb 2013 17:57:58 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBICS0CfstiQ for ; Thu, 21 Feb 2013 17:57:57 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id B9AF121F873C for ; Thu, 21 Feb 2013 17:57:57 -0800 (PST) Received: from piolinux.mtcc.com (63-171-70-46.dsl.volcano.net [63.171.70.46] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1M1vC8R022656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 17:57:13 -0800 Message-ID: <5126D074.4090302@mtcc.com> Date: Thu, 21 Feb 2013 17:57:08 -0800 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Lorenzo Colitti References: <20130221044128.GD2799359@jupiter.n2.diac24.net> <5126CB1D.70705@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1711; t=1361498235; x=1362362235; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Running=20code=20in=20Orlan do |Sender:=20 |To:=20Lorenzo=20Colitti=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=nD1CJedls+DbO6DvhX01MVocErCctbuYgviatY+CjN8=; b=NgmVQlZSx+vLCGg8JBBYyKvEX7300mXbCC0yjyrIcVKoKG1mVeolTsd6c+ 8Wx1SJAhE8N9vpJ5V+WpJoLysELaCyQMiLiwFcl/UVJeAdz6osQ6iRE5LELr 7iaeUOI7G7jAKbYk0WKF4brhv5YX5rt/pLyaGxFtIi3DMgrr1weLw=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 01:57:58 -0000 Lorenzo Colitti wrote: > On Fri, Feb 22, 2013 at 10:34 AM, Michael Thomas > wrote: > > Sigh. > > > Sigh all you like, but I share Dave's skepticism that ISP's > renumbering my prefix willy-nilly and it just sort of works with > naming -- including addresses squirrelled away in places they ought > not be -- is going to work any time soon. > > > That's why we have ULAs and multiple prefixes. ULA's are of limited use. I still want to start my washing machine regardless of whether I'm at home or not. > I don't like to think that NAT is inevitable but frankly the people > in this working group don't get to vote on that. > > > Actually they do. They have the freedom to specify alternatives, and > depending on how good a job they do, implementers may choose to use them. Wishful thinking. NAT's didn't start with the blessing of IETF as I recall. They just happened. If the alternatives are too whacked out, history will repeat itself. > Speaking to the title of this thread: has anybody actually > demonstrated such a thing end to end? It strikes me as > Frankensteinian when you get all of the body parts bolted together. > > > What thing exactly? Multiprefix multihoming? End-to-end connectivity in > general? Yes, along with naming, security, prefix delegation across multiple routers, and isp's giving and withdrawing prefixes due to renumbering. I'm dubious that this has happened in real life with networks with people whose day job is to worry about such things, and I'd be astonished to hear such a thing has been shown to work on a home network. Mike From lorenzo@google.com Thu Feb 21 18:38:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAA521E803D for ; Thu, 21 Feb 2013 18:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXyqkYThZsp7 for ; Thu, 21 Feb 2013 18:38:14 -0800 (PST) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id 02DFB21E803C for ; Thu, 21 Feb 2013 18:38:13 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id dn14so178829obc.18 for ; Thu, 21 Feb 2013 18:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to:cc :content-type; bh=7oijvbiuGdHa1ai50F5TvVZ7l7MdYuBgj97KozD5Akg=; b=PsJPyDoObCKWxwS2TnhE+S+GqiN3E70SHxnMi/TaNU6HWMIRbFw/BDaitTulX0vTw/ 2hWXJ0mhcsIttQ25I1t534WCnE/a9+yDBCo7boVeFbe/tsWc/N0nGvvtv2lyFmee7VtZ 8BfOwMTnNlt1pAKUHMWpFDzFV+tV164URw+FPdBm39AvmpBWQSc+rwRR7vBdPTTq1AiM KZ2qni37UFFAqJ3UKe26Qu8D2ONSyFXa3BhKChthwxtS1VtNa93G4CcHdtBTBFfh7lJs +h9i9YHJ5HSEqlbAu2hUyoqTWXxCnCth++2Yq2VbBhDWPFG9/lsWxW1ikYfeu3UCduIU pdEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to:cc :content-type:x-gm-message-state; bh=7oijvbiuGdHa1ai50F5TvVZ7l7MdYuBgj97KozD5Akg=; b=pqrIa0UrLvgV6JAJz7DhOX6SUYeqfs/BCFUU/7dYUo+D8RLdpINntDhQEwX8y6YcDK STy/FzawluSjveq2GU+g1tgCghkhyusLXims2uq6OjfJgs2os/Cvu7+rggmewZN+ZjSC s5/NQr+Bw8P/W1Oy1LLYKNMuEODrpWntrsgyAcfxHxUdPNSE1An/6xKNQ0XQn2E9OlVa BN43LwBZJdfAb3B4DgcHM3cj0No/n5QayQMdMcEp1kGvFoXjMWL9ilzvfSvzSM9JtDF6 iI1u/jgzol+AuBmeJXfzunNkOJF3t02bLjnprX4gnMVFDkkzrXgPBGxMx4E73LcMdG0r GZSQ== X-Received: by 10.182.108.104 with SMTP id hj8mr129066obb.44.1361500693511; Thu, 21 Feb 2013 18:38:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Thu, 21 Feb 2013 18:37:53 -0800 (PST) From: Lorenzo Colitti Date: Fri, 22 Feb 2013 11:37:53 +0900 Message-ID: To: Michael Thomas Content-Type: multipart/alternative; boundary=f46d0447a1e933909604d6471507 X-Gm-Message-State: ALoCoQkGfehq44Ca/W41kDgw2LYP2Qa1Vz/vmLvzy7ZmSL1PDThfGxS9hk/WQzwjb2s01WM4MN2yKCn3lWfU7MFlfmu+7ocfPFd5LCiF84ofQ0esNYGkiLQHM44J+UZEP2cmusgvVxCzIOWY6ZyI0+cdBOzVDKl2V7OZGkZ69qp5hCsOdlLxE3sL/whhXE8OVhfdQMSweQM3 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter Subject: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 02:38:15 -0000 --f46d0447a1e933909604d6471507 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas wrote: > That's why we have ULAs and multiple prefixes. >> > > ULA's are of limited use. I still want to start my washing machine > regardless of whether I'm at home or not. And you'll know the current IPv6 address of that washing machine how? If you assume renumbering, then the inevitable conclusion is that the address at which you can reach the washing machine from outside your home will change. Therefore, something has to store that address somewhere that's accessible from outside the home, and it has to update it frequently enough that there are no significant outages. I don't see how this requirement is different whether you use NPTv6+ULA or dynamic global addresses. The only difference that I see is that in the case where the machine has a global address, it knows what that address is without having to ask a rendezvous server outside the network. In the case where it only has ULA, it doesn't know what its address is unless it asks a server. > I don't like to think that NAT is inevitable but frankly the people >> in this working group don't get to vote on that. >> >> >> Actually they do. They have the freedom to specify alternatives, and >> depending on how good a job they do, implementers may choose to use them. >> > > Wishful thinking. NAT's didn't start with the blessing of IETF as I > recall. They just > happened. If the alternatives are too whacked out, history will repeat > itself. Exactly. This group can specify alternatives, and if they're good enough, they'll get used. I think NAT became popular because users didn't want to pay ISPs twice to connect two devices. That was a pretty strong incentive. I think the incentives are much weaker with IPv6 now that residential ISPs provide at least a /64, and in most cases much more. > Speaking to the title of this thread: has anybody actually > >> demonstrated such a thing end to end? It strikes me as >> Frankensteinian when you get all of the body parts bolted together. >> >> >> What thing exactly? Multiprefix multihoming? End-to-end connectivity in >> general? >> > > Yes, along with naming, security, prefix delegation across multiple > routers, and isp's > giving and withdrawing prefixes due to renumbering. I'm dubious that this > has happened > in real life with networks with people whose day job is to worry about > such things, and > I'd be astonished to hear such a thing has been shown to work on a home > network. > I don't know about naming and security, but renumbering works using address deprecation (that's been in the spec since forever), and since it's covered by RFC6204 and there are conformance tests for it, devices with the appropriate logo will support it. Support for prefix delegation across multiple routers is spotty, and there's no way to make it work in arbitrary topologies, but for what it's worth, I run it at home and it does work (my operator-provided CPE supports DHCPv6 PD and all I needed to do was plug in an IPv6-capable CPE). source+destination based routing has been demonstrated to work. --f46d0447a1e933909604d6471507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas <mike@mtcc.c= om> wrote:
That's why we have ULAs and multiple= prefixes.

ULA's are of limited use. I still want to start my washing machine rega= rdless of=A0whether I'm at home or not.

And you'll know the current IPv6 address of that washing machine= how? If you assume renumbering, then the inevitable conclusion is =A0that = the address at which you can reach the washing machine from outside your ho= me will change. Therefore, something has to store that address somewhere th= at's accessible from outside the home, and it has to update it frequent= ly enough that there are no significant outages.

I don't see how this requirement is dif= ferent whether you use NPTv6+ULA or dynamic global addresses. The only diff= erence that I see is that in the case where the machine has a global addres= s, it knows what that address is without having to ask a rendezvous server = outside the network. In the case where it only has ULA, it doesn't know= what its address is unless it asks a server.
=A0
=A0 =A0 I don't like to think that NAT is inevitable but frankly the pe= ople
=A0 =A0 in this working group don't get to vote on that.


Actually they do. They have the freedom to specify alternatives, and depend= ing on how good a job they do, implementers may choose to use them.

Wishful thinking. NAT's didn't start with the blessing of IETF as I= recall. They just
happened. If the alternatives are too whacked out, history will repeat itse= lf.

Exactly. This group can specify a= lternatives, and if they're good enough, they'll get used.

I think NAT became popular because users di= dn't want to pay ISPs twice to connect two devices. That was a pretty s= trong incentive. I think the incentives are much weaker with IPv6 now that = residential ISPs provide at least a /64, and in most cases much more.
=A0
=A0 =A0 Speaking to the ti= tle of this thread: has anybody actually
=A0 =A0 demonstrated such a thing end to end? It strikes me as
=A0 =A0 Frankensteinian when you get all of the body parts bolted together.=


What thing exactly? Multiprefix multihoming? End-to-end connectivity in gen= eral?

Yes, along with naming, security, prefix delegation across multiple routers= , and isp's
giving and withdrawing prefixes due to renumbering. I'm dubious that th= is has happened
in real life with networks with people whose day job is to worry about such= things, and
I'd be astonished to hear such a thing has been shown to work on a home= network.

I don't know about = naming and security, but renumbering works using address deprecation (that&= #39;s been in the spec since forever), and since it's covered by RFC620= 4 and there are conformance tests for it, devices with the appropriate logo= will support it. Support for prefix delegation across multiple routers is = spotty, and there's no way to make it work in arbitrary topologies, but= for what it's worth, I run it at home and it does work (my operator-pr= ovided CPE supports DHCPv6 PD and all I needed to do was plug in an IPv6-ca= pable CPE). source+destination based routing has been demonstrated to work.=
--f46d0447a1e933909604d6471507-- From lorenzo@google.com Thu Feb 21 18:39:13 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31C821E8041 for ; Thu, 21 Feb 2013 18:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OncykCVcnB2d for ; Thu, 21 Feb 2013 18:39:13 -0800 (PST) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC3F21E803C for ; Thu, 21 Feb 2013 18:39:13 -0800 (PST) Received: by mail-oa0-f51.google.com with SMTP id h2so181897oag.24 for ; Thu, 21 Feb 2013 18:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=iSKrOa08YMsr0iyRi/RKmaEujQPddncbdHgV6fFxjW4=; b=lsw9RhfXT5HjZScb2eu5nQ+ZtZoc0wd6HDqzVLQfEb3Co/KxjxiecoKqAuzr27lCEC ULfccfEAxv8Ng7hyD/pLj8Rjcfrac9weQFdePEZptBUym6axCRhMQrRueN9xh4DIb1ba vvN+KitDtGQpXijAsAdoQqa07sXUcINKG7m1ehPVfIK7AIqCfEkJIwdu7wvTlhwXoc2C 7dh9X6uMWriV7vjRz8RQAVPWK27ZMAQBc9uglx8Ka45JZH8XyxyHN5YFX1j5sN8oH+sR FAHIOVgNgBU6EfMOaKbidlx48uAVaOfpvAaPbrZ2WNKLDqHVro6wRIIK0p7MHZmbE9dV XYAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=iSKrOa08YMsr0iyRi/RKmaEujQPddncbdHgV6fFxjW4=; b=bNdBBuoXQ6LApr4gFUIl9jCyvml6KlOR8Gg8V7FFQvz888WxYVr/ut5ujlK//WpGTx /4dD0yopkfOapnZIpFInBJJdjNWJJoE11RFIFFOAPs5q8HXFdALKQrtyk30GMiiZISga lczKGqj5SrEmsF2cRMi2MGYGoNttKIj6mpbfhYxuVzbLuJ12W9qtQDpJeXzOu9J+pv8I Kd0Hu4mQ14x6s3KUOV6g5B+lksVnjagngCdRsRhwFluN89+q8vsllQDv28PKRflTj7DR VJwmmPcV8VcjWznJxfD3QQfAlG7BDYPF0mUtGzwQim0Fh1lgZKqRONwYa5tuLLrjFJZB O2lQ== X-Received: by 10.60.6.199 with SMTP id d7mr97239oea.137.1361500752655; Thu, 21 Feb 2013 18:39:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Thu, 21 Feb 2013 18:38:52 -0800 (PST) In-Reply-To: <11123.1361496693@sandelman.ca> References: <11123.1361496693@sandelman.ca> From: Lorenzo Colitti Date: Fri, 22 Feb 2013 11:38:52 +0900 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=e89a8fb1fd74b9c61e04d6471813 X-Gm-Message-State: ALoCoQnipW8hRUHaaO2GYcd128AhlleYyXeYG63Sm67pysPRnAmWG16ErVDUcw0mCUp4kDf43SMs7hc1fkhS4dkjNTX9pbCIpuObHONyxm0G043TKfv+t79ham9yo4ELICNjleza6h22okHbE2rsGwhkoLaXXrjG/w8vJYHVMbSIQpEMF2Z38vm6VEpPaLuTdFHWKa/1tN3K Cc: "homenet@ietf.org" , Fred Baker Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 02:39:13 -0000 --e89a8fb1fd74b9c61e04d6471813 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 22, 2013 at 10:31 AM, Michael Richardson wrote: > I.e. the "0123" is identical for the two prefixes? > In the general case where the prefixes assigned by the operators are of different lengths, it cannot be. Right? --e89a8fb1fd74b9c61e04d6471813 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 22, 2013 at 10:31 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
=
I.e. the "0123" is identical for t= he two prefixes?

In the gen= eral case where the prefixes assigned by the operators are of different len= gths, it cannot be. Right?
--e89a8fb1fd74b9c61e04d6471813-- From mike@mtcc.com Thu Feb 21 19:05:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FA421E8053 for ; Thu, 21 Feb 2013 19:05:00 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkZtwXjMC0VT for ; Thu, 21 Feb 2013 19:04:59 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 2422C21E804B for ; Thu, 21 Feb 2013 19:04:59 -0800 (PST) Received: from piolinux.mtcc.com (63-171-70-46.dsl.volcano.net [63.171.70.46] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1M345oN011143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 19:04:05 -0800 Message-ID: <5126E021.6020103@mtcc.com> Date: Thu, 21 Feb 2013 19:04:01 -0800 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Lorenzo Colitti References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3706; t=1361502246; x=1362366246; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20NPTv6-only=20home=20network s |Sender:=20 |To:=20Lorenzo=20Colitti=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=t/ZOSVNlvNlafvTC9iydt26K4KFNOhYkcjdQ0/kW4ZI=; b=Mscqw7gy0fEe7/vihYXTXhSKt97pyj/OdN2vZjQhBuR82uVev2MjqNngoP HzzgZj2HpTHOcwA/x3nI7/CB3AmATQY8HRbGVMvFMQmAuFNESvAwWp3e/k9l wLT+gH/7D5dvOSjsqihX0oH0QMPJqXThuTdW5riXibe/e4aW/VbmU=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:05:00 -0000 Lorenzo Colitti wrote: > On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas > wrote: > > That's why we have ULAs and multiple prefixes. > > > ULA's are of limited use. I still want to start my washing machine > regardless of whether I'm at home or not. > > > And you'll know the current IPv6 address of that washing machine how? If > you assume renumbering, then the inevitable conclusion is that the > address at which you can reach the washing machine from outside your > home will change. Therefore, something has to store that address > somewhere that's accessible from outside the home, and it has to update > it frequently enough that there are no significant outages. Yes, that is the conclusion. The thing that I hold out some hope that we won't be sucked down the NAT septic tank this time around is that the need to globally address things on my home network won't be a geek-only oddity, but a real live requirement that needs to be solved unlike NATv4. Now do I have a lot of belief that this works well in real life? No, not really. Particularly about naming, and the things being tossed around here give me little hope that problem is even understood, let alone that solutions will be forthcoming. > I don't see how this requirement is different whether you use NPTv6+ULA > or dynamic global addresses. The only difference that I see is that in > the case where the machine has a global address, it knows what that > address is without having to ask a rendezvous server outside the > network. In the case where it only has ULA, it doesn't know what its > address is unless it asks a server. Yes, NPTv6 as I recall begs the question of split resolvers and all of the ickiness that brings with it. Fred can tell me I'm wrong if I'm wrong. > Exactly. This group can specify alternatives, and if they're good > enough, they'll get used. I don't think that it's controversial to say that any solution that takes into account the many things we want to accomplish is going to be complex. Far more complex than what the average home-router-with-nat does right now. Rube Goldberg is not our friend here. It scares me. > I think NAT became popular because users didn't want to pay ISPs twice > to connect two devices. That was a pretty strong incentive. I think the > incentives are much weaker with IPv6 now that residential ISPs provide > at least a /64, and in most cases much more. Yes, there were many reasons but the real point is that the IETF could scream foul, issue rfc's (i'm not really sure it ever did, but...) and generally try to stay relevant, but it didn't really matter. Utility fsvo "utility" 1, architecture 0. > I don't know about naming and security, but renumbering works using > address deprecation (that's been in the spec since forever), and since > it's covered by RFC6204 and there are conformance tests for it, devices > with the appropriate logo will support it. Support for prefix delegation > across multiple routers is spotty, and there's no way to make it work in > arbitrary topologies, but for what it's worth, I run it at home and it > does work (my operator-provided CPE supports DHCPv6 PD and all I needed > to do was plug in an IPv6-capable CPE). source+destination based routing > has been demonstrated to work. Naming is the one thing I'm almost certain is out in la-la land even in the big leagues. For home I'm pretty certain that handwaving would be a generous description of the current state of affairs. And then there's securing things which is always great for a good belly laugh. Mike From equinox@diac24.net Thu Feb 21 19:05:08 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D6D21E8051 for ; Thu, 21 Feb 2013 19:05:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DvaURTY5gv3 for ; Thu, 21 Feb 2013 19:05:07 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 088B321E804B for ; Thu, 21 Feb 2013 19:05:07 -0800 (PST) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2::]) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U8iwY-0005Xc-Q1; Fri, 22 Feb 2013 04:05:02 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80) (envelope-from ) id 1U8iwL-00D3S8-HF; Fri, 22 Feb 2013 04:04:52 +0100 Date: Fri, 22 Feb 2013 04:04:49 +0100 From: David Lamparter To: Lorenzo Colitti Message-ID: <20130222030449.GD2885509@jupiter.n2.diac24.net> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "homenet@ietf.org Group" , "ospf-chairs@tools.ietf.org" , "Fred Baker \(fred\)" , "isis-chairs@tools.ietf.org" , "Abhay Roy \(akr\)" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:05:08 -0000 On Fri, Feb 22, 2013 at 09:41:42AM +0900, Lorenzo Colitti wrote: > On Fri, Feb 22, 2013 at 4:23 AM, Fred Baker (fred) wrote: > > > This is that separate email. As I start, may I make the most direct > > possible apology to my colleagues with other approaches. I'm going to say > > that I think you're "wrong", and say why. That is in the spirit of open > > discussion in which we have a technical disagreement. BTW, you should be > > aware that I have a fair set of people who are telling me I'm wrong as > > well, hopefully in the same spirit. Some of them are pretty irritated with > > me, and I have gotten irritated with them. > > > > For what it's worth, as as a co-author of draft-troan-homenet-sadr-00, I > don't think there is a disagreement. The draft cites your work, because we > (or at least, I) think that the correct approach is in fact one where the > routing protocol passes around source+destination routing pairs. +1 > The reason why the draft also proposes a simplified version of SADR that > integrates with prefix assignment protocol is that it's possible to > implement this without having to make substantial changes to OSPF. > Extending the routing protocols will be a long and possibly hard road, and > we feel that the group should at least consider the possibility of an > approach with better time-to-market and lower barrier to implementation - > especially since the alternatives being proposed are hierarchical DHCPv6 PD > and NPT66. The risk is that we make the perfect the enemy of the good and > we end up with NPT66, which means that we will have thrown away the chance > for end-to-end IPv6 connectivity and will have to build apps in IPv6 just > as we did in IPv4 - forever trying to guess what their addresses are, which > magic packet incancation will work, and which third-party server is the > best to relay packets through. I have the fear that this will come around and do some ass-biting. This is a very subjective opinion of course, but I think it's reasonable to assume that if this ships, it will stick around for years to come. Lots of people never update their CPEs (which is obviously bad and leads to security problems, but we can't will that away...) So, even if we later go the "full-blown" way, we'll have to be interoperable with those will-be Simple SADR relicts. > On the OSPF vs. IS-IS choice... well, if we had an implementation of ISIS > that could run on home networking devices, or if there was at least one on > the horizon, things would be very different. There are in fact 2 implementations of IS-IS that may run on home networking devices, in different states. - BIRD seems to be interested in adding IS-IS due to interest from SPs. A branch exists, but not much progress has been made: [https://redmine.labs.nic.cz/projects/bird/repository?utf8=%E2%9C%93&rev=isis] - (Disclaimer: I'm the Quagga maintainer) Quagga has had bad IS-IS support for a long time. It has been overhauled and that overhaul was integrated in April 2012. I've had the pleasure of declaring it "beta" in the last release, although we're still squashing bugs here and there. [http://savannah.nongnu.org/forum/forum.php?forum_id=7501] Both BIRD and Quagga are readily available on OpenWRT derivatives and should run reasonably fine on limited-resources CPE devices. Both are released under the GNU GPL (v2+). -David From equinox@diac24.net Thu Feb 21 19:33:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E1021E8053 for ; Thu, 21 Feb 2013 19:33:14 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN2yQGxK1vhz for ; Thu, 21 Feb 2013 19:33:13 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A3621E803D for ; Thu, 21 Feb 2013 19:33:12 -0800 (PST) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2::]) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U8jNZ-0008KE-Eg; Fri, 22 Feb 2013 04:32:57 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80) (envelope-from ) id 1U8jNL-00D4yS-0W; Fri, 22 Feb 2013 04:32:46 +0100 Date: Fri, 22 Feb 2013 04:32:42 +0100 From: David Lamparter To: Michael Thomas Message-ID: <20130222033242.GE2885509@jupiter.n2.diac24.net> References: <5126E021.6020103@mtcc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5126E021.6020103@mtcc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:33:14 -0000 On Thu, Feb 21, 2013 at 07:04:01PM -0800, Michael Thomas wrote: > Lorenzo Colitti wrote: > > On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas > > wrote: > > > > That's why we have ULAs and multiple prefixes. > > > > > > ULA's are of limited use. I still want to start my washing machine > > regardless of whether I'm at home or not. > > > > > > And you'll know the current IPv6 address of that washing machine how? [...snip..] > Yes, NPTv6 as I recall begs the question of split resolvers and all of the > ickiness that brings with it. Fred can tell me I'm wrong if I'm wrong. > > > Exactly. This group can specify alternatives, and if they're good > > enough, they'll get used. > > I don't think that it's controversial to say that any solution that takes > into account the many things we want to accomplish is going to be complex. > Far more complex than what the average home-router-with-nat does right now. > Rube Goldberg is not our friend here. It scares me. Well, I wasn't able to find numbers on what percentage of CPEs is Linux-based these days, but, in all honesty, I think if there is a ready-made package for this, maybe even in OpenWRT, that will have a major impact on proliferation of pretty much anything in the CPE area. [...snip...] > > I don't know about naming and security, but renumbering works using > > address deprecation (that's been in the spec since forever), and since > > it's covered by RFC6204 and there are conformance tests for it, devices > > with the appropriate logo will support it. Support for prefix delegation > > across multiple routers is spotty, and there's no way to make it work in > > arbitrary topologies, but for what it's worth, I run it at home and it > > does work (my operator-provided CPE supports DHCPv6 PD and all I needed > > to do was plug in an IPv6-capable CPE). source+destination based routing > > has been demonstrated to work. > > Naming is the one thing I'm almost certain is out in la-la land even in the > big leagues. For home I'm pretty certain that handwaving would be a generous > description of the current state of affairs. And then there's securing things > which is always great for a good belly laugh. Indeed I have to agree on this one from practical experience. We've tried creating some kind of automatic IPv6 naming system at the local hackerspace - with 2 network software developers, no less - and failed. We're using SLAAC (which AFAIK is reasonable to expect in a homenet?) and a good percentage of our devices don't speak MDNS. We didn't even get as far as thinking about privacy addresses, we just failed to find any reasonable way to get names to start with... (Ok, well, maybe MDNS would've been the way to go... but, being targeted at local name resolution, this is nowhere near a turn-key solution for accessing a washing machine from the internet either.) -David From mellon@fugue.com Thu Feb 21 19:42:21 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB29421E803D for ; Thu, 21 Feb 2013 19:42:21 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzPQEBjfOsIl for ; Thu, 21 Feb 2013 19:42:20 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id C602121E803C for ; Thu, 21 Feb 2013 19:42:20 -0800 (PST) Received: from kali-8.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id D0546238053C; Thu, 21 Feb 2013 22:42:18 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <20130222033242.GE2885509@jupiter.n2.diac24.net> Date: Thu, 21 Feb 2013 22:42:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <78F112CE-68D4-4FB3-905D-FEE5F722547D@fugue.com> References: <5126E021.6020103@mtcc.com> <20130222033242.GE2885509@jupiter.n2.diac24.net> To: David Lamparter X-Mailer: Apple Mail (2.1499) Cc: Michael Richardson , Michael Thomas , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:42:21 -0000 On Feb 21, 2013, at 10:32 PM, David Lamparter = wrote: > We're using SLAAC (which AFAIK is reasonable to expect in a homenet?) > and a good percentage of our devices don't speak MDNS. We didn't even > get as far as thinking about privacy addresses, we just failed to find > any reasonable way to get names to start with... It's probably worth bearing in mind that the solution for your problem = hasn't been standardized yet, nor is there even rough consensus on what = the standard ought to look like, and so nobody's got it implemented in = devices. Basing our expectations on what the best we can do is on what we have = now is a recipe for failure. We should set our sights on doing it = right, and accept that it won't be done right in the very earliest IPv6 = homenets. From mike@mtcc.com Thu Feb 21 19:46:54 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C2321E803C for ; Thu, 21 Feb 2013 19:46:54 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoLXOtC2iIYU for ; Thu, 21 Feb 2013 19:46:51 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id E30B421E8037 for ; Thu, 21 Feb 2013 19:46:50 -0800 (PST) Received: from piolinux.mtcc.com (63-171-70-46.dsl.volcano.net [63.171.70.46] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1M3k4Z1024933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 19:46:05 -0800 Message-ID: <5126E9F7.4020906@mtcc.com> Date: Thu, 21 Feb 2013 19:45:59 -0800 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Ted Lemon References: <5126E021.6020103@mtcc.com> <20130222033242.GE2885509@jupiter.n2.diac24.net> <78F112CE-68D4-4FB3-905D-FEE5F722547D@fugue.com> In-Reply-To: <78F112CE-68D4-4FB3-905D-FEE5F722547D@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1114; t=1361504766; x=1362368766; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20NPTv6-only=20home=20network s |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=i9IZOqigvQI+v/+qUwXpr3c1Ot8on1u9D/3prfZWVwA=; b=raiW5jPcvWTnHYRLJXO0YJi0+18Bn27N0ue/Y2Oxvko3DJdNbwwaHAq0d2 90WgXDFyOfxyLPB6rGLX5EAo6JTwgc7zSdwUc0OIgKnPocJXXRdJFqcs1BS8 33AcC/khekKHh93rTOovQh53eRL2bLSHbIKboWL+aIqriq/J2N2Ws=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:46:54 -0000 Ted Lemon wrote: > On Feb 21, 2013, at 10:32 PM, David Lamparter wrote: >> We're using SLAAC (which AFAIK is reasonable to expect in a homenet?) >> and a good percentage of our devices don't speak MDNS. We didn't even >> get as far as thinking about privacy addresses, we just failed to find >> any reasonable way to get names to start with... > > It's probably worth bearing in mind that the solution for your problem hasn't been standardized yet, nor is there even rough consensus on what the standard ought to look like, and so nobody's got it implemented in devices. > > Basing our expectations on what the best we can do is on what we have now is a recipe for failure. We should set our sights on doing it right, and accept that it won't be done right in the very earliest IPv6 homenets. Well, if one of the requirements is that I be able to control my washing machine from across the continent, I'm not sure why we're even screwing with mdns in this wg. And if that's not a requirement for this working group, I have to ask which century it got chartered in. Mike From lorenzo@google.com Thu Feb 21 20:31:41 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FDE21F8E71 for ; Thu, 21 Feb 2013 20:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVDE1UY5MKYX for ; Thu, 21 Feb 2013 20:31:40 -0800 (PST) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id CC64321F8E70 for ; Thu, 21 Feb 2013 20:31:40 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id n12so233878oag.41 for ; Thu, 21 Feb 2013 20:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=gKi3JQ6qM2skyHNtfJ/Rs9lb3DpbUG3UmK8Qw/dFThs=; b=VlKL7ZeXPxtiPH9+Uwb0usOizNffjYjJ21EjNP0fW0xmqUxJvcElbx2U01IQoj17Yx 7GupYQ8HDBUAi3cJnBqp0UrRmHD4u7kwT91RZIEznzT6yaBGipvzuPigwn4SwYDntIsd BEPA83HUGW8ZoKqJSLhQnQlFfNrIw7vaW8ltuWM8ulH0h2kE3KFCYps0Krh/d7i7UR5r VwKhB4oGsXSF+GSk/1AgiTndv92itezlBykAbBCnDGlLPSidTlC2yBFeLOmln1x7Zvo8 pcXmQKQuTXetZhGfFqcAKfEV1werFBzpEcPd/JssMKwvx0mCNRFwHtDFMQR0dcN5JW0O BFGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=gKi3JQ6qM2skyHNtfJ/Rs9lb3DpbUG3UmK8Qw/dFThs=; b=WaoHarnolvXixtGCfPdJnTn+ThVtfLgu7wpwLSiSjIMC45sPK4tDWBgqYSs9RpKZSC TyvQXx4bezVRrCM/OOYNxpVl2DI3M7qHG0WRS3WXkJ3TivZa2+OycAZ92oPCXNE17O1Z 5BltIvkp25O9UmxeZOxNA6GZq/aIf68uiKngNMdOe6FXNjnzEWi188MhkECMrZ92dS8n SNz9iFLrjaO6W5s0JDFI+3g1Z77xGtlCyNF3B4I/lRENA8hzZbAZ7lTonsuZ38X2oeZk y/GR/uX2WfHfJW7tKYNlVF3kUWuTuRjdUARqac86ucz7z2xme57jzu189ibglgyYoARI 3CPQ== X-Received: by 10.60.11.106 with SMTP id p10mr210946oeb.94.1361507494968; Thu, 21 Feb 2013 20:31:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Thu, 21 Feb 2013 20:31:14 -0800 (PST) In-Reply-To: <5126E021.6020103@mtcc.com> References: <5126E021.6020103@mtcc.com> From: Lorenzo Colitti Date: Fri, 22 Feb 2013 13:31:14 +0900 Message-ID: To: Michael Thomas Content-Type: multipart/alternative; boundary=e89a8fb1eaf6993d5604d648aafa X-Gm-Message-State: ALoCoQlUUJMnAbWZiYcZTo+dlD9MKoraFGsfE8f27rPRwBhYvXgf9mHm1HE7iLPD0s0j0Vtf51bZUA677YUPWUo2hZEvz+lDkPpT1RduKvzhT7fyuNWXo56vmYX8AcyrmYVz7daAh9ndp7707L4tYGG9DQDAn9+lIsNiw/+6Qv5+9O8KZeuqEXOsUN1/kY3mGElKswV7YzgF Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 04:31:41 -0000 --e89a8fb1eaf6993d5604d648aafa Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 22, 2013 at 12:04 PM, Michael Thomas wrote: > I don't see how this requirement is different whether you use NPTv6+ULA or >> dynamic global addresses. The only difference that I see is that in the >> case where the machine has a global address, it knows what that address is >> without having to ask a rendezvous server outside the network. In the case >> where it only has ULA, it doesn't know what its address is unless it asks a >> server. >> > > Yes, NPTv6 as I recall begs the question of split resolvers and all of the > ickiness that brings with it. Fred can tell me I'm wrong if I'm wrong. My point was more that that NPTv6 doesn't make that any easier, more secure, or... anything, really. You still have to update the address somewhere; all that NPTv6 gives you is that now the washing machine doesn't know what its IPv6 address is. Right? --e89a8fb1eaf6993d5604d648aafa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 22, 2013 at 12:04 PM, Michael Thomas <mike@mtcc.c= om> wrote:
I don't see how this r= equirement is different whether you use NPTv6+ULA or dynamic global address= es. The only difference that I see is that in the case where the machine ha= s a global address, it knows what that address is without having to ask a r= endezvous server outside the network. In the case where it only has ULA, it= doesn't know what its address is unless it asks a server.

Yes, NPTv6 as I recall begs the question of split resolvers and all of the<= br> ickiness that brings with it. Fred can tell me I'm wrong if I'm wro= ng.

My point was more that that NPTv6= doesn't make that any easier, more secure, or... anything, really. You= still have to update the address somewhere; all that NPTv6 gives you is th= at now the washing machine doesn't know what its IPv6 address is. Right= ?
--e89a8fb1eaf6993d5604d648aafa-- From fred@cisco.com Thu Feb 21 20:50:24 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8482721F8EBC for ; Thu, 21 Feb 2013 20:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.475 X-Spam-Level: X-Spam-Status: No, score=-110.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GW3g0WaRPdb for ; Thu, 21 Feb 2013 20:50:23 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC1721F8EB4 for ; Thu, 21 Feb 2013 20:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=935; q=dns/txt; s=iport; t=1361508623; x=1362718223; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p0qJLVwHcpMkqt2xxVdL4vX/N3NsSKHFKCTs3vEcClE=; b=I+BSAfDYE+V1Gx/OmryraOv9uhorImURB3b7qHqn/0gq1NvHo2V+Zxeh T/LeiitL38LStYc8Zq8GAff3lJ8SQr1eyKrPdjGUSaRs8Cqdzt0C5fcZm msIndF5wOToHH/j7hOAcU1Ms8NCj/hdm3p2h6squXAYJfTCJOfrdgPFzD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAL/4JlGtJXG+/2dsb2JhbABFhge7EoEJFnOCHwEBAQMBeQULAgEIDhQkMiUCBA4FCIgEBr8+jVOBCAIxB4JfYQOIM55hgweBaj0 X-IronPort-AV: E=Sophos;i="4.84,713,1355097600"; d="scan'208";a="179897836" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 22 Feb 2013 04:50:05 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1M4o5bK015870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 04:50:05 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 22:50:04 -0600 From: "Fred Baker (fred)" To: Michael Richardson Thread-Topic: automatic prefix management (OSPF or ISIS version) Thread-Index: AQHOELgUX95OUhgPLE2zWlJ2R0KpxA== Date: Fri, 22 Feb 2013 04:50:05 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B79E503@xmb-rcd-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.155] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 04:50:24 -0000 On Feb 22, 2013, at 1:54 PM, Michael Richardson wrote: > For a network where there is more than one ISP, is it acceptable for a CP= E that has decided that it is PREFIX1:0123::/64, to "randomly" decide to be= PREFIX2:0123::/64? I don't see why not, at least in the home. There is a case, which homenet hasn't thought much about that I'm aware of,= which is renumbering a network. You'll notice in my draft that if the auto= config prefix is withdrawn, I expect prefixes dependent on it to be withdra= wn, and if stored in permanent storage, erased. The implication is that if = the same prefix is then readvertised, there's a good chance that all of the= subnet numbers will change. I know of at least one scenario where that wou= ld be considered a desirable characteristic. But I don't think that case is= , at least at this point, a general case or one I would specify beyond a "M= AY".= From fred@cisco.com Thu Feb 21 20:54:38 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285D221E8051 for ; Thu, 21 Feb 2013 20:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.114 X-Spam-Level: X-Spam-Status: No, score=-110.114 tagged_above=-999 required=5 tests=[AWL=-0.115, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNdznxfrTSCo for ; Thu, 21 Feb 2013 20:54:37 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 87E8721E804B for ; Thu, 21 Feb 2013 20:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=482; q=dns/txt; s=iport; t=1361508877; x=1362718477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UYuYxhzjYzJ9Y+t7++GPRfSqoreFzeeKdSUdeE/h57k=; b=FheGZTQVfJd4iLZggRMETw1M60eiprK88VmYKSi4VPNATlwQaI5HB0uY Hwrcr/TX0GOydtRkFrC0/XdhAlWMqrzOGD5M9CPIFOGD1OkYQuuDy1aRb bIDC1QvZ7XRG0TBLYXHpzDK/nOre2vbFvh1uZKEVJTUUUNjTNoOBvZPHo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAMD5JlGtJV2Y/2dsb2JhbABFhge7EoEJFnOCHwEBAQMBOj8FCwIBCCIUEDIlAgQOBQiIBAa/PY5bAjEHgl9hA6cUgweCJw X-IronPort-AV: E=Sophos;i="4.84,713,1355097600"; d="scan'208";a="176904868" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 22 Feb 2013 04:54:37 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1M4sbba014002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 04:54:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 22:54:36 -0600 From: "Fred Baker (fred)" To: Michael Richardson Thread-Topic: [homenet] Egress Routing Discussion: Baker model Thread-Index: AQHOELi20Cqqta4hK0iQ2Aq7Vju5cg== Date: Fri, 22 Feb 2013 04:54:36 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B79E560@xmb-rcd-x09.cisco.com> References: <20464.1361478945@sandelman.ca> In-Reply-To: <20464.1361478945@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.155] Content-Type: text/plain; charset="us-ascii" Content-ID: <48F28C174B1243469CBB8F8FFD425916@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 04:54:38 -0000 On Feb 22, 2013, at 9:35 AM, Michael Richardson wro= te: > Fred, I'm not sure that foo-chairs@ needs to be CC'ed on this > discussion? Having not been through your documents yet... I wanted them to see that the discussion was happening. They have each aske= d me to take some time with their working groups. In one case, that will be= amusing; I chair v6ops, and ospf and v6ops conflict. Yes, that's a great r= eason for having a co-chair.= From joelja@bogus.com Fri Feb 22 00:03:01 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF2621F8F5F for ; Fri, 22 Feb 2013 00:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9hLhghCwQly for ; Fri, 22 Feb 2013 00:03:01 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id ED2AE21F8F5D for ; Fri, 22 Feb 2013 00:03:00 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1M82D5V051796 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 22 Feb 2013 08:02:14 GMT (envelope-from joelja@bogus.com) Message-ID: <51272600.4080605@bogus.com> Date: Fri, 22 Feb 2013 00:02:08 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Michael Thomas , Lorenzo Colitti References: <5126E021.6020103@mtcc.com> In-Reply-To: <5126E021.6020103@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 22 Feb 2013 08:02:15 +0000 (UTC) Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 08:03:01 -0000 On 2/21/13 7:04 PM, Michael Thomas wrote: > Lorenzo Colitti wrote: >> On Fri, Feb 22, 2013 at 10:57 AM, Michael Thomas > > wrote: >> >> That's why we have ULAs and multiple prefixes. >> >> >> ULA's are of limited use. I still want to start my washing machine >> regardless of whether I'm at home or not. >> >> >> And you'll know the current IPv6 address of that washing machine how? >> If you assume renumbering, then the inevitable conclusion is that >> the address at which you can reach the washing machine from outside >> your home will change. Therefore, something has to store that address >> somewhere that's accessible from outside the home, and it has to >> update it frequently enough that there are no significant outages. > > Yes, that is the conclusion. The thing that I hold out some hope that > we won't > be sucked down the NAT septic tank this time around is that the need > to globally > address things on my home network won't be a geek-only oddity, but a > real live > requirement that needs to be solved unlike NATv4. So, I think what we can observe from the number of readily discoverable security cameras on the internet. was that the real-live requirement was at least partially solved thanks to upnp and dynamic dns registration, is not a geek-only-oddity, survives renumbering, and was for the most part done quite badly. hopefully it can be done better in the future. > > Now do I have a lot of belief that this works well in real life? No, > not really. > Particularly about naming, and the things being tossed around here > give me > little hope that problem is even understood, let alone that solutions > will be > forthcoming. > >> I don't see how this requirement is different whether you use >> NPTv6+ULA or dynamic global addresses. The only difference that I see >> is that in the case where the machine has a global address, it knows >> what that address is without having to ask a rendezvous server >> outside the network. In the case where it only has ULA, it doesn't >> know what its address is unless it asks a server. > > Yes, NPTv6 as I recall begs the question of split resolvers and all of > the > ickiness that brings with it. Fred can tell me I'm wrong if I'm wrong. > >> Exactly. This group can specify alternatives, and if they're good >> enough, they'll get used. > > I don't think that it's controversial to say that any solution that takes > into account the many things we want to accomplish is going to be > complex. > Far more complex than what the average home-router-with-nat does right > now. > Rube Goldberg is not our friend here. It scares me. > >> I think NAT became popular because users didn't want to pay ISPs >> twice to connect two devices. That was a pretty strong incentive. I >> think the incentives are much weaker with IPv6 now that residential >> ISPs provide at least a /64, and in most cases much more. > > Yes, there were many reasons but the real point is that the IETF could > scream > foul, issue rfc's (i'm not really sure it ever did, but...) and > generally try > to stay relevant, but it didn't really matter. Utility fsvo "utility" 1, > architecture 0. > > >> I don't know about naming and security, but renumbering works using >> address deprecation (that's been in the spec since forever), and >> since it's covered by RFC6204 and there are conformance tests for it, >> devices with the appropriate logo will support it. Support for prefix >> delegation across multiple routers is spotty, and there's no way to >> make it work in arbitrary topologies, but for what it's worth, I run >> it at home and it does work (my operator-provided CPE supports DHCPv6 >> PD and all I needed to do was plug in an IPv6-capable CPE). >> source+destination based routing has been demonstrated to work. > > Naming is the one thing I'm almost certain is out in la-la land even > in the > big leagues. For home I'm pretty certain that handwaving would be a > generous > description of the current state of affairs. And then there's securing > things > which is always great for a good belly laugh. > > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From brian.e.carpenter@gmail.com Fri Feb 22 00:22:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE5C21F8D0B for ; Fri, 22 Feb 2013 00:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.151 X-Spam-Level: X-Spam-Status: No, score=-101.151 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GG1KWhpQCMQk for ; Fri, 22 Feb 2013 00:22:26 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8224F21F8DF8 for ; Fri, 22 Feb 2013 00:22:25 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id hi18so389390wib.15 for ; Fri, 22 Feb 2013 00:22:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f2G2t+i43AcilTRzKnUGr3qh53IEpIrW4AQsaGJML6w=; b=VHZwD3gEFcrmY1zVlw+9TlHM3NSORgfsF2CaG3iodmjR3L4sFXiRz+LfUCdVqDeGKC 6bCzERv9SfjoaRe192Z+KcXHH5ZOzD2l91Mfd2SCFVqU8ZZ6JYnxrj1Tke4NiJSZVIOx oRgKpCVjUSuGnAxjtg9kgLeRU2XghlPBcB903uxMx+r/FjD93XxKwTa0gJ49DqAHWE9i TT4NjYqczgK1Fq01WJdTjVJzGGLUMChMkwLeuOQ26MCZoyANPhDhi1k7dvy1aZkwEHSy yQ5/VdgyPvFHa9DXnE1+dQNmFeDuFJSNPMtqqMEckxpkFDcLXwJLKP/dnHy2OyFGgJZ7 y1mQ== X-Received: by 10.194.172.197 with SMTP id be5mr1628793wjc.20.1361521342097; Fri, 22 Feb 2013 00:22:22 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-222.as13285.net. [2.102.217.222]) by mx.google.com with ESMTPS id bs6sm2042920wib.4.2013.02.22.00.22.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 00:22:21 -0800 (PST) Message-ID: <51272ACB.7040605@gmail.com> Date: Fri, 22 Feb 2013 08:22:35 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <8C48B86A895913448548E6D15DA7553B79E503@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B79E503@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 08:22:29 -0000 On 22/02/2013 04:50, Fred Baker (fred) wrote: > On Feb 22, 2013, at 1:54 PM, Michael Richardson > wrote: > >> For a network where there is more than one ISP, is it >> acceptable for a CPE that has decided that it is >> PREFIX1:0123::/64, to "randomly" decide to be >> PREFIX2:0123::/64? > > I don't see why not, at least in the home. > > There is a case, which homenet hasn't thought much about that > I'm aware of, which is renumbering a network. Surely, in a homenet, it's very much the case that (as Fred has hinted over in 6renum) the issue is "numbering" rather than renumbering. I may be too much of an energy conservation nut for most people, but my homenet is cold-started and numbered most mornings, because it is powered off at bedtime. However, I can see no harm in sticky subnet numbering, as long as the new prefix isn't long enough to overwrite the old subnet numbers. > You'll notice > in my draft that if the autoconfig prefix is withdrawn, I > expect prefixes dependent on it to be withdrawn, and if > stored in permanent storage, erased. The implication is that > if the same prefix is then readvertised, there's a good > chance that all of the subnet numbers will change. I know of > at least one scenario where that would be considered a > desirable characteristic. But I don't think that case is, at > least at this point, a general case or one I would specify > beyond a "MAY". Actually, do you even need a formal "MAY"? It's an implementer choice, isn't it? Brian From Ray.Bellis@nominet.org.uk Fri Feb 22 00:48:56 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D5121F8DC9 for ; Fri, 22 Feb 2013 00:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz+dh-1MlTGh for ; Fri, 22 Feb 2013 00:48:55 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2C57E21F8DBE for ; Fri, 22 Feb 2013 00:48:54 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=0ky5swvlS/DpcJSJ4R2tCRRAoHBwJ6M6Ab+8rAaZQ5k3N4nWRHSFOoPV J8iy9zrnQZNFTz8w+fTorbSZDoHzHxRsst1smr1KsPfbtZ/HzZwAs4znA WugQblYm0I9gmTf; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1361522935; x=1393058935; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20Egress=20Routing=20Discussi on:=20Baker=20model|Date:=20Fri,=2022=20Feb=202013=2008:4 8:52=20+0000|Message-ID:=20<53F00E5CD8B2E34C81C0C89EB0B4F E7310538CC6@wds-exc2.okna.nominet.org.uk>|To:=20"homenet@ ietf.org=20Group"=20|CC:=20"isis-chairs @tools.ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<055058C50F1C7B42B7C2246F836662FE @okna.nominet.org.uk>|In-Reply-To:=20<20130222030449.GD28 85509@jupiter.n2.diac24.net>|References:=20<472E7EB7-E262 -46CE-A17E-DE4C45C70566@cisco.com>=0D=0A=20<8C48B86A89591 3448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com>=0D=0A=20 =0D=0A=20<20130222030449.GD2885509@jupiter.n 2.diac24.net>; bh=0AZDzRFBWevK7BgLqCYX+tDGXIY1OfrK0VIq62ZPELY=; b=zBVUX+AiBTFR9aYN7HmOAlX5tUP0yDh3h6Kl4KDPaLN0At4iClNKsHQG DUvAJ8vTTQfFcKDbD3lIiGGNCigXTTfuIY2IlA2GZOEPjMhI0BIKSpTfj BUzBy0eQKB775vz; X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; d="scan'208";a="46624100" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx3.nominet.org.uk with ESMTP; 22 Feb 2013 08:48:53 +0000 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%17]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 08:48:52 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: [homenet] Egress Routing Discussion: Baker model Thread-Index: AQHOEGjePDmfY0YTWU22pYhqqdemMZiFCfIAgAAn/ICAAGAfgA== Date: Fri, 22 Feb 2013 08:48:52 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE7310538CC6@wds-exc2.okna.nominet.org.uk> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <20130222030449.GD2885509@jupiter.n2.diac24.net> In-Reply-To: <20130222030449.GD2885509@jupiter.n2.diac24.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <055058C50F1C7B42B7C2246F836662FE@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "isis-chairs@tools.ietf.org" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 08:48:56 -0000 On 22 Feb 2013, at 03:04, David Lamparter wrote: > - BIRD seems to be interested in adding IS-IS due to interest from SPs. > A branch exists, but not much progress has been made: > [https://redmine.labs.nic.cz/projects/bird/repository?utf8=3D%E2%9C%93&r= ev=3Disis] Ondrej Filip tells me that this is being worked on again, targeted for rele= ase in 2013Q2 Ray From brian.e.carpenter@gmail.com Fri Feb 22 00:48:50 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC32621F8CB3 for ; Fri, 22 Feb 2013 00:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.777 X-Spam-Level: X-Spam-Status: No, score=-99.777 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5R0BAVJDu+i for ; Fri, 22 Feb 2013 00:48:50 -0800 (PST) Received: from mail-we0-x22d.google.com (we-in-x022d.1e100.net [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3DE21F8C59 for ; Fri, 22 Feb 2013 00:48:50 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id r5so314937wey.4 for ; Fri, 22 Feb 2013 00:48:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lYxBEEqSS4HOYmc82lNcBBLPZ6UOV2sDGlDeBeyLygk=; b=PUTMSntOakYi7JDkT2ASnIXO27k32RKOPyXtq4JGV16cENiTLN4m0l9tqkbrucXQ1M f9EiBL04YJe/KpFQqfaa46AL5v8NeD3RdzG+SwRMv7pfgCuXis8XCMMUPJlTk3YZ2qVF DmhSJPxkLGH+eabd1UtSHIW/EyRnyBiUNJ42TKVfw8m8aH11j5rNG9jID86aNtyJ9sv4 y/69jpHcuc8DCJ+7myCES9jqwY9upGYqGGyW8pcLcJA8GCVGNDRo12IB2cmqd4O+Wtab mFx7NwUEHPjVvkcevzKZkzQucBAIKWo1YsZvw9YL1tdiDiNQYpVP93qN5tM/jAKuJPGG AOIQ== X-Received: by 10.180.87.98 with SMTP id w2mr1674294wiz.30.1361522929280; Fri, 22 Feb 2013 00:48:49 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-222.as13285.net. [2.102.217.222]) by mx.google.com with ESMTPS id du2sm2706123wib.0.2013.02.22.00.48.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 00:48:48 -0800 (PST) Message-ID: <512730FD.2030205@gmail.com> Date: Fri, 22 Feb 2013 08:49:01 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Thomas References: <5126E021.6020103@mtcc.com> <20130222033242.GE2885509@jupiter.n2.diac24.net> <78F112CE-68D4-4FB3-905D-FEE5F722547D@fugue.com> <5126E9F7.4020906@mtcc.com> In-Reply-To: <5126E9F7.4020906@mtcc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 22 Feb 2013 00:50:34 -0800 Cc: Michael Richardson , "Brzozowski, John" , Mark Townsley , Dave Taht , Jari Arkko , Ted Lemon , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 08:48:51 -0000 On 22/02/2013 03:45, Michael Thomas wrote: ... > Well, if one of the requirements is that I be able to control my washing > machine from across the continent, Actually we need to be clear about that requirement. There are at least three cases I can imagine: 1. I want to control my washing machine remotely (although I won't be doing that until I have a very reliable dhobi-robot to load and unload it). 2. The manufacturer wants to update my washing machine remotely. 3. A benevolent 3rd party wants to control it remotely. I think you'll find each of these cases has different discovery, naming and security requirements. Brian From brian.e.carpenter@gmail.com Fri Feb 22 00:56:03 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BCF21F8E70 for ; Fri, 22 Feb 2013 00:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.146 X-Spam-Level: X-Spam-Status: No, score=-101.146 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwgvqq9Z-ZUN for ; Fri, 22 Feb 2013 00:56:02 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7336621F8E64 for ; Fri, 22 Feb 2013 00:56:02 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id fg15so315033wgb.13 for ; Fri, 22 Feb 2013 00:56:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Vh/PDPX8NRp8vVl0u7JiSxqL4oonpByVlNl+UszBSpE=; b=TL/WkcjjTNIblIfCNtAncCo4JzxX8emB67BqTEzfyG1WnVyibqr/GwqktcNnCLxvtM cjZbayZOsnF+Oi7g7b7eewxbpSWPOdSGRCD3QZW/do/u7IM4VdTQ1rfC9JCDDeEUux07 5zesjzznt7nkEwxX1sJsvF7vPsvW2f5I7gflExcTZMUb8gjifQVgjF4r+tdvJ8Ji6UvZ 7mkHDPqC5Z+d8tpDvXrFZv9Vr4G8i8+8WvuDZsfhWQ7fqK/4yCG1UO6H2Q6SKTm8XM3R MgrB0ylPjCDOYNdL5PyeJ3HC3zvVy9BYKYfBtdnNEnOFv5cqaqRXPllJRFYECRk5x327 hi8A== X-Received: by 10.194.110.69 with SMTP id hy5mr1869091wjb.1.1361523361644; Fri, 22 Feb 2013 00:56:01 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-222.as13285.net. [2.102.217.222]) by mx.google.com with ESMTPS id fx5sm2167473wib.11.2013.02.22.00.55.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 00:56:00 -0800 (PST) Message-ID: <512732AD.3000003@gmail.com> Date: Fri, 22 Feb 2013 08:56:13 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , "Abhay Roy \(akr\)" , "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 08:56:03 -0000 On 21/02/2013 19:23, Fred Baker (fred) wrote: ... >> http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing >> "Using IS-IS with Role-Based Access Control", Fred Baker, 17-Feb-13 >> >> http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing >> "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 17-Feb-13 >> >> http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing >> "Using OSPFv3 with Role-Based Access Control", Fred Baker, 17-Feb-13 >> >> http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing >> "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 17-Feb-13 To get this on the record, I have serious doubts whether the use of the flow label suggested in these drafts is compatible with the current flow label standard (RFC6437). I think this is separable from the general approach, so I'd rather defer discussion until the general approach has been debated. Brian From v6ops@globis.net Fri Feb 22 02:01:11 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048CA21F8E2C for ; Fri, 22 Feb 2013 02:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGFstTVq0+eW for ; Fri, 22 Feb 2013 02:01:08 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 66A8121F8E20 for ; Fri, 22 Feb 2013 02:01:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 2A6B6870064; Fri, 22 Feb 2013 10:53:17 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRNdEVQS6ttO; Fri, 22 Feb 2013 10:52:47 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 66E45870061; Fri, 22 Feb 2013 10:52:47 +0100 (CET) Message-ID: <51273FE8.7050302@globis.net> Date: Fri, 22 Feb 2013 10:52:40 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" , "Abhay Roy \(akr\)" , "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 10:01:11 -0000 I have read all of your drafts, and those of the other authors, carefully, once. No doubt I'll have to re-read them. This response is limited to high level comments regarding the overall approach, and isprobably applicable to all 3 sets of authors : 1. Some drafts talk extensively about the need for an "extensible" routing protocol, and often mention the desirability of TLV (type-length-value) objects. I agree that a TLV structure potentially solves many issues of how to encode and transport new options between routing protocol speakers. But given that route determination is a distributed algorithm, and that Homenet devices will not always run the latest and greatest code, what action should nodes that are running older code take regarding any TLV options that they don't understand? Isn't there a danger that extensibility will lead to more routing loops, instability, and black holes? Is there a need for all speakers to first agree the (newest) commonly-understood subset of options that all speakers in a Homenet can/will honour before any extension options are transmitted? 2. Aren't we forgetting the first hop? Given a shared subnet/prefix/link with 2 CPE routers performing some fancy new form of forwarding (based on PBR or SADR or whatever) that is also shared by existing host implementations, how will the routers signal these new default route semantics to end hosts? Would we need a new prefix information option in ND? Would we need an extension to RFC 4191 Section 2.3 Route Information Option to include (source prefix,destination prefix) routes? Would we need a new ICMPv6 redirect message to extend RFC2461 Section 4.5 to include the possibility of (source,destination) redirects? 3. Limiting this discussion strictly to Homenet requirements: Aren't we forgetting the inter-provider management boundary? My view of the Homenet is a network that is potentially a member of multiple overlapping AS's simultaneously, without being an AS itself. That's highly unusual in routing protocol terms. I think that it is very unlikely that any operator will allow any dynamic routing between a CPE managed by a customer and a PE managed by the provider. I think there's also a potential issue of anyone making any assumptions about dynamic routing being available between a provider-managed CPE and a customer owned CPE. Software version control will not be trivial. The current most likely source of external routing information is DHCPv6-PD, used to locally autoconfigure a "floating static" default route on the Homenet BR, pointing out of the upstream interface to "the Internet". As such, how will any routing information beyond a simple default route (related to a single delegated prefix) be injected into the Homenet? Why are we importing the extra complexity (related to data centres and enterprises) into Homenet? 4. We're still planning on doing something about source address selection, aren't we? For all the suggested complexity of the packet routing solutions suggested so far, isn't the real "route" selection going to be performed in the host? 5. Flow label routing: hasn't rfc6437 scuppered any chance that the flow labels themselves will directly carry any meaning that could be realistically used to make deterministic forwarding decisions by low/mid-powered routers, because you're essentially going to have to reverse a 20 bit hash function to make a forwarding decision? Wouldn't the requirements in rfc6437 also suggest a routing table explosion, because each individual flow would have to be associated with an individual IS-IS route? Perhaps you could distribute some intermediate result to end hosts and routers via IS-IS,which is deterministic and related to policy based routing (such as including the tenant label in a TLV), but which after applying some hash transform and adding some entropy, would comply with the requirements of 6437? That'd potentially reduce the IS-IS routing table size dramatically. I've been waiting 15+ years for fully dynamic PBR and I fully expect to wait some time longer. In any case, with all due respect, I don't think it's relevant for Homene= t, 6. Other potentially simpler approaches that might be faster to market I have provided detailed feedback to Ole & Lorenzo, suggesting how Homenet could potentially work without modifying any routing protocols at all, with multi-homing, without resorting to NPT, and with BCP38 ingress/egress filters (albeit with a hard link to some yet-to-be-defined autoconfiguration protocol, and a limit that the prefixes of any walled-gardens must be disjoint from other AS's directly connected to this Homenet, and possibly some other limitations such as dumb hosts should not be connected to dual routers from competing providers). Do I need to write a draft on this, or is this already clear? Would someone be willing to help out/ collaborate? If I have other detailed comments on the individual drafts, I'll come back with those. regards, RayH Fred Baker (fred) wrote: > On Feb 22, 2013, at 6:22 AM, Fred Baker wrote: > >> In Atlanta, Mark asked Lorenzo and I to put together a draft of an app= roach to source/destination, and especially egress, routing. I pulled tog= ether a plan of attack that I applied to both IPv4 and IPv6, and to both = IS-IS and OSPF and sought review from a limited list including Lorenzo; t= his includes capabilities for at least one other use case I'm looking at.= Mark asked me to cut that down to make things separately implementable (= which they would be anyway, but to make it apparent). So I have broken it= into components. >> >> ...... >> >> I have documented my approach, which provides the generalized concept,= is built into the routing protocols IS-IS and OSPF, and also addresses a= t least one other "tagged routing" option, which is to look at flow label= s. >> >> http://tools.ietf.org/html/draft-baker-ipv6-isis-automatic-prefix >> "Automated prefix allocation in IS-IS", Fred Baker, 18-Feb-13 >> >> http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing= >> "Using IS-IS with Role-Based Access Control", Fred Baker, 17-Feb-13 >> >> http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing >> "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 17-Feb-13 >> >> http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing= >> "Using OSPFv3 with Role-Based Access Control", Fred Baker, 17-Feb-13 >> >> http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing >> "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 17-Feb-13= >> >> http://tools.ietf.org/html/draft-baker-ipv6-ospf-extensible >> "Extensible OSPF LSAs", Fred Baker, 17-Feb-13 >> >> I'll say why I think mine is the correct approach in another email, as= I imagine my colleagues will for theirs. But the working group should co= nsider the question. > > > This is that separate email. As I start, may I make the most direct pos= sible apology to my colleagues with other approaches. I'm going to say th= at I think you're "wrong", and say why. That is in the spirit of open dis= cussion in which we have a technical disagreement. BTW, you should be awa= re that I have a fair set of people who are telling me I'm wrong as well,= hopefully in the same spirit. Some of them are pretty irritated with me,= and I have gotten irritated with them. > > Two parts of the question here relate to "what problem do we think we'r= e solving" and "how do we model the network". A third will be "how do we = implement it in a router?" > > Homenet, I believe, thinks it's solving "how do I provide egress routin= g with zero, or perhaps epsilon, configuration, using open source code in= the cheapest possible implementation." That's laudable; that said, I do = believe that egress routing is a requirement for any IPv6 network involvi= ng multiple provider-allocated prefixes, and that as a result this is som= ething to be built into the base protocol. In OSPF terminology, it is suf= ficient to build on an AS-external-LSA if that's the only source/destinat= ion route to be considered (it is certainly a principal use case); for a = general network, however, we don't generally carry a lot of AS-external i= nformation around. So we need, I think, the ability to use native default= routes as well as AS-external default routes, which means that we also n= eed to look at the intra-area-prefix-LSA and the inter-area-prefix-LSA. T= he problem, I argue, is how to tag a route with a set of attributes and a= pply a route policy to it. One possible attribute is the source prefix th= at might be used by systems communicating with this destination, and ther= e are other possible attributes. The route policy is that traffic is forw= arded to a stated destination if and only if it also matches the other sp= ecified attributes. So, when we want to source/destination route to a spe= cified egress, the destination in question is a default route (::/0), the= source is the relevant PA prefix, and we are asking the network to build= routes in the way it natively does so for traffic that has the specified= set of attributes. > > As to "how we model it", there are at least two possible approaches. Wh= en Jon Moy was first building what we now call OSPF, one of the problems = that the Internet was dealing with was congestive collapse. There were se= veral experiments, one of which I was involved in with Neil Bierbaum of N= ASNET, in which we wanted to send interactive traffic using paths that ha= d relatively low delay, and high volume file transfer traffic on other pa= ths that had high throughput. It was not unusual for those "high throughp= ut" paths to also have long delay, such as through a geosynchronous satel= lite. The technology for doing this was originally documented, at least p= ublicly, in RFCs 1131 and 1247, commented on in RFC 1812, and has evolved= to RFC 4915's Multi-topology Routing; it was developed in parallel in IS= -IS as well. The multi-topology model is based on the premise that router= s and/or links differ from each other in some important way, such as capa= city, delay, or capability (do they support IPv6? Do they have a stated d= iffserv configuration?), and that it is useful to segregate them into sub= -topologies and build routes within those topologies. The other possible = model, which I am following, presumes that one is not routing "to a desti= nation", although arriving at an intended destination is an important fac= et, or "through a specific topology"; ultimately, one is routing a class = of traffic, as I described in http://tools.ietf.org/html/draft-baker-fun-= routing-class. That class of traffic (as seen by a given router) consists= of the datagrams that will pass through a stated router and have some se= t of attributes, which might include destination address, source address,= a flow label, a DSCP, or several other characteristics. For a DSCP, topo= logy is important - I need to know whether the links have the attributes = I am asking about. Those other attributes are not, in my view, topology-r= elevant - they simply help define the class of traffic.=20 > > So I'm modeling the routing of a class of traffic identified by a set o= f attributes in what is otherwise a single topology. > > When you looked at my list of documents, you no doubt thought "the work= ing group is focused on OSPF as the routing protocol; why IS-IS?" I looke= d at IS-IS first because it is the simplest to update in this way. The wa= y IS-IS works is that each router advertises an at-least-in-concept singl= e Link State PDU (LSP) that contains information about itself and its nei= ghborhood. The information is stored in type-length-value (TLV) objects, = and the LSP is in essence a list of them describing a single router. Each= router starts with its own LSP, determines how it will reach its neighbo= rs, and then their neighbors, and so on until it has figured out how to r= each every router in the network (including LANs, which are modeled as vi= rtual routers called pseudonodes). Along the way, it also discovers that = routers advertise reachability of various kinds: "if you have a route to = me, I can deliver data to <>", where <> might be an AppleTalk subnet, an = IPv4 subnet (RFC 1195), an IPv6 subnet (RFC 5308), or any of a number of = other things. RFC 5308 specifies such a TLV, which specifies an IPv6 pref= ix with some attributes like how it got into the network. It also specifi= es the ability to have sub-TLVs, TLVs that specify additional attributes = for the larger TLV, although it doesn't define any. Those are for "future= extension". Welcome to the future. > > So, from my perspective, in the routing protocol, we need to specify su= b-TLVs for any additional attributes, such as source prefixes, that we wa= nt to include, and IS-IS has given us that capability. What's necessary n= ext is a FIB that the routes can be stored into. I'll come to that later.= > > Of course, IS-IS isn't going to be very useful in homenet without a way= to allocate prefixes to LANs. draft-baker-ipv6-isis-automatic-prefix is = in essence draft-ietf-ospf-ospfv3-autoconfig for IS-IS. Shoot me. > > But we wanted to do this in OSPF. Here, I have a problem. OSPF is desig= ned with fixed LSAs, not extensible LSAs, so adding an attribute to an LS= A is difficult without fundamentally changing the LSA. I started by defin= ing a set of extensible LSAs in draft-baker-ipv6-ospf-extensible; they ar= e direct counterparts to RFC 5340's LSAs, and intended to be backward-com= patible with them. I'm not stuck on exactly that approach; I have since f= ound that an extensible LSA was considered and set aside by the working g= roup in 2006/2007, in http://tools.ietf.org/html/draft-ietf-ospf-mt-ospfv= 3. Give me an approach that gives me the ability to add a sub-TLV to an O= SPF LSA such as I did for IS-IS, and I'm pleased as punch. draft-baker-ip= v6-ospf-dst-src-routing is a direct counterpart to draft-baker-ipv6-isis-= dst-src-routing, and draft-baker-ipv6-ospf-dst-flowlabel-routing is a dir= ect counterpart to draft-baker-ipv6-isis-dst-flowlabel-routing; they add = attributes to an extensible LSA. The theory is the same. > > Which brings us, I suppose, to the FIB. There are many ways a FIB can b= e designed, and I would expect every vendor to do it their own way; this = is not a matter for standardization. However, to have the discussion, it = seems important to at least mention some possible approaches. In appendic= es in the drafts, I mention two. They are far from the only two; they are= two. > > Mark felt it was important to specifically state how these might play w= ith the Waikato source address routing extensions in Linux, so I addresse= d that. I generalized it a little bit; there is a trade-off, and I wanted= to comment on it. The premise in Waikato is that one identifies the sour= ce prefix and uses that to select a destination FIB. In terms of writing = code quickly, that's a reasonable approach; the FIB itself is already des= igned, the question is how to have more than one of them. My question is = how many FIBs one might have, and what memory impacts that might imply. I= n a generalized model, one could imagine having quite a number of FIBs. B= ut now, what routes do we expect to put into those FIBs? I expect that, a= t least in a small-to-medium sized network, one has some number of PA pre= fixes and as many egress default routes; most of the routes, whether few = or many, are traditional destination routes within the domain. So, I can = have a FIB per PA prefix, put egress default routes only into the FIBs fo= r their source prefixes, and put every single destination route into each= FIB. That results in a potentially-large number of FIBs, each of which c= ontains mostly-identical information. If memory is a concern, I throw out= a second option; I could have a destination-only FIB and a set of PA pre= fix-specific FIBs, which are usually relatively small, perhaps only a sin= gle route. When you do a route lookup, you look in both the destination-o= nly FIB, which will find local routes, and the PA-relevant FIB, which wil= l get you a default route, and use the one that is most specific. > > That said, I think there is a much simpler approach, although it may ta= ke some time to explain. A PATRICIA trie is a structure originally discus= sed in 1968 for searching through ASCII text, and used in route tables. I= t allows you to build a set of discontiguous bit strings, and do a radix = search through the trie. For the details, I'll refer you to discussions o= f PATRICIA tries on the web and the appendix in the document.=20 > > So there are at least two possible FIB approaches; there are no doubt o= ther approaches, and they might be better. To each his or her own. From lorenzo@google.com Fri Feb 22 02:17:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833CE21F8E74 for ; Fri, 22 Feb 2013 02:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgECSp9fIbLJ for ; Fri, 22 Feb 2013 02:17:25 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6649021F8E71 for ; Fri, 22 Feb 2013 02:17:25 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id l20so445231oag.9 for ; Fri, 22 Feb 2013 02:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=AyCgAzHljXmf2pvBwXu5R60+hY98FvZYDlsEwSEUmrU=; b=W4EDMkge6y+Vy53fi8eMDnRREdhVrNJuXCf2edH8nW1zmhXVgbb89VCAPCHZsv6mU/ 7t8SBM/+RYtVb2LcqbdQRed2CncPt2aGL8ercuXDHZTKlN4YpAu7lqa9gGAKfZg+Zn3U DcalB8h/3bkvMXo20y9ZDlfHqkjxRFrecFMjwXqZs3m7FW5lKXHJSy8xaY7aWNHtMUUd bZxfE7FYKW/2Wx5omYBHFrlAAOe8Vx43XAocibmZX1wDRnfnDadZ0lekzhg2ZcSDzjzD g/8wu6SSHoviWYhj615+JDfh8qBYUjsQxYkQDGRjIpmYNQ3FV6rAv6j2EcztnDsXqZSe 1Qzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=AyCgAzHljXmf2pvBwXu5R60+hY98FvZYDlsEwSEUmrU=; b=HpimUt+x0lSSCAHAOcTAfb6Lo2kjzmGkE3h3WDD/M+q+n5x8GnLHlbo4UUG1F4oGMm G+vk3wK96hTMM4MJzAws/0FbYsP6jEoT3T8604PoFQby1ECmedrQKmSYThO25ERDG3GH /UTNgfJ9cDh3K85sgxPFpF5UJo1aS/soI5copB1jP8JownpkYWqi3VdoFCl43Br+6ga8 vvg1JNZquhxS9aYFAmm2LI3Rq/Kr7GS+XOFaUAA7Max/QO3Sti4/a7qsfzOvfE0kpRYA mxRzkKoBDInUlpKUsw+CizO/h6B3B51vLs3sbAeJZ7Qvnfau7RpBjmwbgFO44iLdwKme s2Vg== X-Received: by 10.60.25.35 with SMTP id z3mr525053oef.98.1361528244557; Fri, 22 Feb 2013 02:17:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Fri, 22 Feb 2013 02:17:04 -0800 (PST) In-Reply-To: <51273FE8.7050302@globis.net> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> From: Lorenzo Colitti Date: Fri, 22 Feb 2013 19:17:04 +0900 Message-ID: To: Ray Hunter Content-Type: multipart/alternative; boundary=e89a8f923cfe60b3f604d64d7f27 X-Gm-Message-State: ALoCoQl2Ky/hYEuKED+kdsDhGlOIU3xEW2v1ozJHTK/V6NFvxfR2RD8lMx5//tpLlVCTBBg1mGhn/7hv8XI1LdZAlDRE/1IfN1au5pvBwTZG0Rs97Ka5RhzeKvE2hi2H4vhOsw6YHGahVswN9GtUNc0UqPclnhEu67YCcP6nAOXJxKoqP9FYuyf4V6DhHV9lYniXtP6eOjzH Cc: Ole Troan , "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , "Abhay Roy \(akr\)" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 10:17:26 -0000 --e89a8f923cfe60b3f604d64d7f27 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter wrote: > But given that route determination is a distributed algorithm, and that > Homenet devices will not always run the latest and greatest code, > what action should nodes that are running older code take regarding any > TLV options that they don't understand? > > Isn't there a danger that extensibility will lead to more routing loops, > instability, and black holes? > Yes. If intermediate devices don't understand SADR, you can get routing loops. We should document that clearly and find out how to avoid it. > 2. Aren't we forgetting the first hop? > > Given a shared subnet/prefix/link with 2 CPE routers performing some > fancy new form of forwarding (based on PBR or SADR or whatever) that is > also shared by existing host implementations, how will the routers > signal these new default route semantics to end hosts? > > Would we need a new prefix information option in ND? > > Would we need an extension to RFC 4191 Section 2.3 Route Information > Option to include (source prefix,destination prefix) routes? > > Would we need a new ICMPv6 redirect message to extend RFC2461 Section > 4.5 to include the possibility of (source,destination) redirects? > The beauty of this approach is that you don't need to signal anything to the hosts for things to work properly. The hosts pick whatever source address they choose and the network takes care of getting the packet to the right exit. If the right exit is down or gone, then the packet gets dropped, but as the SADR draft explains, you can fix this by telling the homenet routers to deprecate prefixes for which there is no exit. The hosts will then avoid those source addresses for new connections. (The authors of said draft do not agree amongst themselves whether this is the right thing to do or not; but no doubt the WG will have useful opinions here). If you want the hosts to do better load-balancing, then you do need to give them more information. We haven't looked at this. If you want to support walled garden prefixes that do not have complete reachability, then you need to tell the hosts not to use them. I believe DHCPv6 options exist to configure RFC 6724 policy on hosts, but I don't know if anyone supports them, and I haven't thought about the security issues or how to propagate that information through the homenet. 3. Limiting this discussion strictly to Homenet requirements: Aren't we > forgetting the inter-provider management boundary? > > My view of the Homenet is a network that is potentially a member of > multiple overlapping AS's simultaneously, without being an AS itself. > That's highly unusual in routing protocol terms. > > I think that it is very unlikely that any operator will allow any > dynamic routing between a CPE managed by a customer and a PE managed by > the provider. > > I think there's also a potential issue of anyone making any assumptions > about dynamic routing being available between a provider-managed CPE and > a customer owned CPE. Software version control will not be trivial. > > The current most likely source of external routing information is > DHCPv6-PD, used to locally autoconfigure a "floating static" default > route on the Homenet BR, pointing out of the upstream interface to "the > Internet". > > As such, how will any routing information beyond a simple default route > (related to a single delegated prefix) be injected into the Homenet? > > Why are we importing the extra complexity (related to data centres and > enterprises) into Homenet? > I thought the idea was that border routers would just do DHCPv6 PD and inject whatever routes they get into the homenet tagged with whatever source prefix they get. They wouldn't participate in any routing protocol with the ISP. We don't currently have any other mechanism for learning external routes, but when we do we can simply treat them in the same way. Does this not work for some reason? 6. Other potentially simpler approaches that might be faster to market > I have provided detailed feedback to Ole & Lorenzo, suggesting how > Homenet could potentially work without modifying any routing protocols > at all, with multi-homing, without resorting to NPT, and with BCP38 > ingress/egress filters (albeit with a hard link to some > yet-to-be-defined autoconfiguration protocol, and a limit that the > prefixes of any walled-gardens must be disjoint from other AS's directly > connected to this Homenet, and possibly some other limitations such as > dumb hosts should not be connected to dual routers from competing > providers). > Did I miss this? Where can I find it? Was it sent to the list? --e89a8f923cfe60b3f604d64d7f27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter <v6ops@globis.= net> wrote:
But given that route determination is a distributed algorithm, and that
Homenet devices will not always run the latest and greatest code,
what action should nodes that are running older code take regarding any
TLV options that they don't understand?

Isn't there a danger that extensibility will lead to more routing loops= ,
instability, and black holes?

Yes= . If intermediate devices don't understand SADR, you can get routing lo= ops. We should document that clearly and find out how to avoid it.
=A0
2. Aren't we forgetting th= e first hop?

Given a shared subnet/prefix/link with 2 CPE routers performing some
fancy new form of forwarding (based on PBR or SADR or whatever) that is
also shared by existing host implementations, how will the routers
signal these new default route semantics to end hosts?

Would we need a new prefix information option in ND?

Would we need an extension to RFC 4191 Section 2.3 Route Information
Option to include (source prefix,destination prefix) routes?

Would we need a new ICMPv6 redirect message to extend RFC2461 Section
4.5 to include the possibility of (source,destination) redirects?

The beauty of this approach is that you do= n't need to signal anything to the hosts for things to work properly. T= he hosts pick whatever source address they choose and the network takes car= e of getting the packet to the right exit.

If the right exit is down or gone, then the= packet gets dropped, but as the SADR draft explains, you can fix this by t= elling the homenet routers to deprecate prefixes for which there is no exit= . The hosts will then avoid those source addresses for new connections. (Th= e authors of said draft do not agree amongst themselves whether this is the= right thing to do or not; but no doubt the WG will have useful opinions he= re).

If you want the hosts to do better load-bal= ancing, then you do need to give them more information. We haven't look= ed at this.

If you want to support wal= led garden prefixes that do not have complete reachability, then you need t= o tell the hosts not to use them. I believe DHCPv6 options exist to configu= re RFC 6724 policy on hosts, but I don't know if anyone supports them, = and I haven't thought about the security issues or how to propagate tha= t information through the homenet.

3. Limiting this discussion s= trictly to Homenet requirements: =A0Aren't we
forgetting the inter-provider management boundary?

My view of the Homenet is a network that is potentially a member of
multiple overlapping AS's simultaneously, without being an AS itself. That's highly unusual in routing protocol terms.

I think that it is very unlikely that any operator will allow any
dynamic routing between a CPE managed by a customer and a PE managed by
the provider.

I think there's also a potential issue of anyone making any assumptions=
about dynamic routing being available between a provider-managed CPE and a customer owned CPE. Software version control will not be trivial.

The current most likely source of external routing information is
DHCPv6-PD, used to locally autoconfigure a "floating static" defa= ult
route on the Homenet BR, pointing out of the upstream interface to "th= e
Internet".

As such, how will any routing information beyond a simple default route
(related to a single delegated prefix) be injected into the Homenet?

Why are we importing the extra complexity (related to data centres and
enterprises) into Homenet?

I thou= ght the idea was that border routers would just do DHCPv6 PD and inject wha= tever routes they get into the homenet tagged with whatever source prefix t= hey get. They wouldn't participate in any routing protocol with the ISP= . We don't currently have any other mechanism for learning external rou= tes, but when we do we can simply treat them in the same way.

Does this not work for some reason?

6. Other potentially simpler approaches that might be faster to market
I have provided detailed feedback to Ole & Lorenzo, suggesting how
Homenet could potentially work without modifying any routing protocols
at all, with multi-homing, without resorting to NPT, and with BCP38
ingress/egress filters (albeit with a hard link to some
yet-to-be-defined autoconfiguration protocol, and a limit that the
prefixes of any walled-gardens must be disjoint from other AS's directl= y
connected to this Homenet, and possibly some other limitations such as
dumb hosts should not be connected to dual routers from competing
providers).

Did I miss this? Wher= e can I find it? Was it sent to the list?
--e89a8f923cfe60b3f604d64d7f27-- From ot@cisco.com Fri Feb 22 02:25:48 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F7121F8E19 for ; Fri, 22 Feb 2013 02:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.481 X-Spam-Level: X-Spam-Status: No, score=-10.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BNS7IHiLxu3 for ; Fri, 22 Feb 2013 02:25:48 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id C91E721F847C for ; Fri, 22 Feb 2013 02:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1369; q=dns/txt; s=iport; t=1361528747; x=1362738347; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=st25hpa8EUHqoYRxyMrZs/KchOvAchbf7B3Ir/3wyaQ=; b=kToQj9XJk9ottedjSXWfBZxvPPdurS8PBFxlZTSEmk9gYDDgLR0bZcj1 eNRoADHqg3bpY8GF0/RoUpAmFih6ZO3WmBGrB3aPnjho3On5X9qrsgNZb kAWDjOvgYlg+8QPe8ZCkin8Ry0J4D2ewsEjrYZIoygHsW7Gt5wnb21pLo c=; X-IronPort-AV: E=Sophos;i="4.84,714,1355097600"; d="scan'208";a="11981269" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 22 Feb 2013 10:25:47 +0000 Received: from dhcp-lys02-vla252-10-147-116-46.cisco.com (dhcp-lys02-vla252-10-147-116-46.cisco.com [10.147.116.46]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1MAPkX2015762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Feb 2013 10:25:46 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <8C48B86A895913448548E6D15DA7553B79DAEF@xmb-rcd-x09.cisco.com> Date: Fri, 22 Feb 2013 11:25:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <46EEC0B6-1D08-443A-A4C0-B91C7258B89A@cisco.com> References: <8C48B86A895913448548E6D15DA7553B79DAEF@xmb-rcd-x09.cisco.com> To: Fred Baker (fred) X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" , "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" Subject: Re: [homenet] Egress Routing Discussion X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 10:25:48 -0000 Fred, > Ole Troan and Lorenzo Colitti documented their model, which is = strictly egress routing based on the OSPF AS-prefix-LSA and the = assumption of automated prefix allocation. This is not multi-topology; = it in effect tags the default route advertised as a route from an = alternate universe. >=20 > http://tools.ietf.org/html/draft-troan-homenet-sadr > "IPv6 Multihoming with Source Address Dependent Routing (SADR)", Ole > Troan, Lorenzo Colitti, 18-Feb-13 to clarify, the SADR draft: - describes what source constrained / source address dependent routing = is - describes a conceptual forwarding model - gives two alternatives to how a routers forwarding table can be = populated. a) implicitly via other information learn from the prefix assignment = protocol b) explicitly via one of the Baker extensions to routing protocols. neither a nor b has any restriction to just the default route. more = specific routes are supported too. b allows flexibility to also advertise internal (S,D) routes, and S,D = routes not associated with border routers. I specifically chose single topology. just to make it clear, I think the correct solution is to add support = for (S,D) routes in the routing protocol, I just don't want to sit on the fence and wait until that support is = added and available. cheers, Ole= From equinox@diac24.net Fri Feb 22 03:48:50 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AB621F8E17; Fri, 22 Feb 2013 03:48:50 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcOnP1FiA1MG; Fri, 22 Feb 2013 03:48:49 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C1B21F8DA0; Fri, 22 Feb 2013 03:48:49 -0800 (PST) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2::]) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U8r7F-00080J-3I; Fri, 22 Feb 2013 12:48:37 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1U8r70-00DXpo-KY; Fri, 22 Feb 2013 12:48:26 +0100 Date: Fri, 22 Feb 2013 12:48:22 +0100 From: David Lamparter To: "Fred Baker (fred)" Message-ID: <20130222114822.GA3183407@jupiter.n2.diac24.net> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ole Troan , "isis-chairs@tools.ietf.org" , "ospf@ietf.org" , Ray Hunter , "homenet@ietf.org Group" , "Abhay Roy \(akr\)" , Lorenzo Colitti Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:48:50 -0000 On Fri, Feb 22, 2013 at 07:17:04PM +0900, Lorenzo Colitti wrote: > On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter wrote: > > > But given that route determination is a distributed algorithm, and that > > Homenet devices will not always run the latest and greatest code, > > what action should nodes that are running older code take regarding any > > TLV options that they don't understand? > > > > Isn't there a danger that extensibility will lead to more routing loops, > > instability, and black holes? > > Yes. If intermediate devices don't understand SADR, you can get routing > loops. We should document that clearly and find out how to avoid it. [quoting the earler loop sketch for convenience] | If 4. is not given, this scenario will lead to a loop: | All links assumed at equal cost, r2 does not support simplified SADR, | R1,R3,R4 do. | | ISP_A, pfx_A ::/0 ISP_B, pfx_B, ::/0 | | | | R1 ------ r2 ------ R3 ------ R4 | | | Host | | Host now selects an address from pfx_B to reach some site on the | internet. R1 forwards to r2 because the ::/0 from R4 is more specific | on the source. r2 forwards back to R1 because it didn't consider source | specific-ness and just went by lower cost... [/quote] Since I complained about this earlier, I feel obliged to throw possible approaches around. I'm excluding the prefix-assignment-integrated approach to distributing SADR routing information since that would supposedly by design require all participants to support SADR. For both "simple" and "full-blown" OSPFv3 the following loop/interop mechnisms come to my mind: 1. refusing adjacencies between SADR and non-SADR routers. Easily implemented with a Hello bit, this is the crowbar solution. Quite sufficient for homenet I guess, but probably less acceptable for anything else. 2. flagging SADR support in router LSAs/LSPs. Provides enough information to avoid loops. Three things can be done with this information: 2a. install null/reject routes for paths that cross non-SADR routers. Provides adequate failure semantics, instead of looping packets around we get an ICMP unreachable. Easy to implement. Downside: if there really is a non-SADR router, "not working" is now a state that is part of the result set of the dynamic route calculations. Users (and admins) probably do not expect this. 2b. calculate SPF around non-SADR routers Gets us a working network, but at a cost: there may now be 2 different paths to reach some faraway router, one for SADR-routed packets and a different one for non-SADR packets. Depending on how the router performs its SPF calculations, this can be hard to implement correctly - it's essentially a very narrowly and exactly specified case of multitopology routing. 2c. on encountering non-SADR routers, figure whether they'll do the right thing with the packet. ... complicated and of questionable use IMHO. Just listing this for completeness. 2a and 2b can be mixed with each other; packets will get passed along by 2a-type routers until they get discarded at a 2b-type router. My personal opinion at this point is that 2a and 2b should both be specified, with a requirement to indicate support level in the router documentation. We're unlikely to encounter normal OSPFv3 speakers in a plain "production/final" homenet, so they could take the easy way. If this gets implemented on routers for enterprise use, I'd expect 2b behaviour. (With the Baker OSPF/ISIS SADR specs quite independent from homenet as they are right now, I think getting homenet-only solutions in those is an unwise idea; homenet optimisation possibilities like allowing fallback to 2a on the other hand should be acceptable.) -David From mellon@fugue.com Fri Feb 22 04:27:35 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B952121F8ECF for ; Fri, 22 Feb 2013 04:27:35 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-BnmttxvSrd for ; Fri, 22 Feb 2013 04:27:33 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id EBB7621F8ECE for ; Fri, 22 Feb 2013 04:27:33 -0800 (PST) Received: from kali-8.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 43B86238033F; Fri, 22 Feb 2013 07:27:30 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <5126E9F7.4020906@mtcc.com> Date: Fri, 22 Feb 2013 07:27:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5126E021.6020103@mtcc.com> <20130222033242.GE2885509@jupiter.n2.diac24.net> <78F112CE-68D4-4FB3-905D-FEE5F722547D@fugue.com> <5126E9F7.4020906@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1499) Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 12:27:35 -0000 On Feb 21, 2013, at 10:45 PM, Michael Thomas wrote: > Well, if one of the requirements is that I be able to control my = washing machine from across the continent, > I'm not sure why we're even screwing with mdns in this wg. And if = that's not a requirement for this working > group, I have to ask which century it got chartered in. +1 From mellon@fugue.com Fri Feb 22 04:30:51 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A225021F8E53 for ; Fri, 22 Feb 2013 04:30:51 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2973jF5TDHLw for ; Fri, 22 Feb 2013 04:30:51 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB2B21F8E4E for ; Fri, 22 Feb 2013 04:30:51 -0800 (PST) Received: from kali-8.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 83CEF238033F; Fri, 22 Feb 2013 07:30:49 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: Date: Fri, 22 Feb 2013 07:30:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> References: <5126E021.6020103@mtcc.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1499) Cc: Michael Richardson , Michael Thomas , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 12:30:51 -0000 On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti = wrote: > My point was more that that NPTv6 doesn't make that any easier, more = secure, or... anything, really. You still have to update the address = somewhere; all that NPTv6 gives you is that now the washing machine = doesn't know what its IPv6 address is. Right? I think the issue that Michael imagines NPTv6 will address is the = transition period, when the washing machine has two IP addresses, and = the DNS may not have the new address, or may have both addresses, and = he's hoping the gateway will somehow bandage this up. However, the = gateway's ability to bandage this up is more imagined than real, and we = might as well just fix the underlying problem. From mellon@fugue.com Fri Feb 22 04:37:46 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A052A21F8E92 for ; Fri, 22 Feb 2013 04:37:46 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaLf2sN8dJFy for ; Fri, 22 Feb 2013 04:37:46 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4473321F8E58 for ; Fri, 22 Feb 2013 04:37:46 -0800 (PST) Received: from kali-8.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id D8450238033F; Fri, 22 Feb 2013 07:37:14 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: Date: Fri, 22 Feb 2013 07:37:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8C669A18-F9A3-44CF-A9B7-CF80884C0698@fugue.com> References: <5126E021.6020103@mtcc.com> <20130222033242.GE2885509@jupiter.n2.diac24.net> <78F112CE-68D4-4FB3-905D-FEE5F722547D@fugue.com> <5126E9F7.4020906@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1499) Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 12:37:46 -0000 On Feb 22, 2013, at 7:27 AM, Ted Lemon wrote: >> Well, if one of the requirements is that I be able to control my = washing machine from across the continent, >> I'm not sure why we're even screwing with mdns in this wg. And if = that's not a requirement for this working >> group, I have to ask which century it got chartered in. >=20 > +1 Er, that came out wrong. I'm agreeing with "want to be able to access = devices in the home from away," not "working group was chartered in the = last century." I am also skeptical about MDNS as a solution, though. From Ray.Bellis@nominet.org.uk Fri Feb 22 04:42:40 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9F321F8E95 for ; Fri, 22 Feb 2013 04:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gQlrHf6VcdA for ; Fri, 22 Feb 2013 04:42:38 -0800 (PST) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 531AD21F8EAA for ; Fri, 22 Feb 2013 04:42:38 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=CuaEKi76GhAmaTDh8PQexzJpQE/JynAMDwb2EiEb6VdwpEwL4W0zshBf uefYgVfdOoAiMhb4h1vQs8HEUra6idegReWsIiz09y3NvuynqIN7YrHiV 2cmiM1Stx8ZKALR; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1361536958; x=1393072958; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20NPTv6-only=20home=20network s|Date:=20Fri,=2022=20Feb=202013=2012:42:36=20+0000 |Message-ID:=20<53F00E5CD8B2E34C81C0C89EB0B4FE731053BAAF@ wds-exc2.okna.nominet.org.uk>|To:=20"homenet@ietf.org=20G roup"=20|CC:=20Michael=20Thomas=20|MIME-Version:=201.0|Content-Transfer-Encoding: =20quoted-printable|Content-ID:=20|In-Reply-To:=20<5126E9F7. 4020906@mtcc.com>|References:=20=0D=0A=20<5126 E021.6020103@mtcc.com>=20<20130222033242.GE2885509@jupite r.n2.diac24.net>=0D=0A=20<78F112CE-68D4-4FB3-905D-FEE5F72 2547D@fugue.com>=20<5126E9F7.4020906@mtcc.com>; bh=/XLNmH7nclBLw3o0DGXBZBIR3gg4cGvxdkPZC5EyCts=; b=JVeDnl3ftGGwgxy5baYP5WP0cYAEL+UcudT8FxlIPfj1SvnpJ/+n8ouN RFu+vrWutS9QDKvC5+zlJZPEu7KE7lejaP6mYdHxwPRCKGzSjUiCWxwhl 9ZlAezir1iWNier; X-IronPort-AV: E=Sophos;i="4.84,716,1355097600"; d="scan'208";a="38566671" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx4.nominet.org.uk with ESMTP; 22 Feb 2013 12:42:36 +0000 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%17]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 12:42:36 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: [homenet] NPTv6-only home networks Thread-Index: AQHOEKWv+JgGPqveS02imDGd8UEyzZiFMTuAgAAIBACAAAKqAIAAAQyAgACV7YA= Date: Fri, 22 Feb 2013 12:42:36 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE731053BAAF@wds-exc2.okna.nominet.org.uk> References: <5126E021.6020103@mtcc.com> <20130222033242.GE2885509@jupiter.n2.diac24.net> <78F112CE-68D4-4FB3-905D-FEE5F722547D@fugue.com> <5126E9F7.4020906@mtcc.com> In-Reply-To: <5126E9F7.4020906@mtcc.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Thomas Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 12:42:40 -0000 On 22 Feb 2013, at 03:45, Michael Thomas wrote: > Well, if one of the requirements is that I be able to control my washing = machine from across the continent, I'm not sure why we're even screwing wit= h mdns in this wg. And if that's not a requirement for this working group, = I have to ask which century it got chartered in. It's indirectly mentioned in the charter: "While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet." ... "End-to-end communication is both an opportunity and a concern as it enables new applications ..." and it's also explicitly called out in draft-ietf-homenet-arch (=A73.7) Ray From Ray.Bellis@nominet.org.uk Fri Feb 22 04:49:12 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B89521F8E95 for ; Fri, 22 Feb 2013 04:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juNtgQmXqbE7 for ; Fri, 22 Feb 2013 04:49:09 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 48DF421F8E70 for ; Fri, 22 Feb 2013 04:49:08 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=uufP3K4kGoHojJIHH0zrJ6fOdBDN8rci1d883DggLriAbTKprIwd/GJ9 531SYw2jo10LeH60owftOf8YTB8t1qdHN6T3lvwDil6922mztg72CaG6T HiarQIJGLPVZKiM; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1361537349; x=1393073349; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20NPTv6-only=20home=20network s|Date:=20Fri,=2022=20Feb=202013=2012:49:05=20+0000 |Message-ID:=20<53F00E5CD8B2E34C81C0C89EB0B4FE731053BB82@ wds-exc2.okna.nominet.org.uk>|To:=20Ted=20Lemon=20|CC:=20"homenet@ietf.org=20Group"=20|MIME-Version:=201.0|Content-Transfer-Encoding: =20quoted-printable|Content-ID:=20<7D18478376ADFF4496E287 CAD27AB822@okna.nominet.org.uk>|In-Reply-To:=20<8C669A18- F9A3-44CF-A9B7-CF80884C0698@fugue.com>|References:=20=0D=0A=20<5126E021.6020103@mtcc.com>=20<2013022203 3242.GE2885509@jupiter.n2.diac24.net>=0D=0A=20<78F112CE-6 8D4-4FB3-905D-FEE5F722547D@fugue.com>=20<5126E9F7.4020906 @mtcc.com>=0D=0A=20=0D=0A=20<8C669A18-F9A3-44CF-A9B7-CF80884C0698@ fugue.com>; bh=1XA0DLt/Ot6YVMUIyEXXPgxgJUJo03QJUUjP8D1aOl8=; b=uttYs5nnkJ9eM4VRPEIlz9fvjBbQDhAfJLDM0xjceysgeYGHFdQ0L84/ z9bVMHzzFXUguvmFuGjCSSmtN7kQDO42uoO2RixYwuotC9XB+s0Rb1Q8N nKgDJCSSpEz1HX6; X-IronPort-AV: E=Sophos;i="4.84,716,1355097600"; d="scan'208";a="38566713" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx4.nominet.org.uk with ESMTP; 22 Feb 2013 12:49:07 +0000 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%17]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 12:49:06 +0000 From: Ray Bellis To: Ted Lemon Thread-Topic: [homenet] NPTv6-only home networks Thread-Index: AQHOEKWv+JgGPqveS02imDGd8UEyzZiFMTuAgAAIBACAAAKqAIAAAQyAgACRtYCAAAK4gIAAA1GA Date: Fri, 22 Feb 2013 12:49:05 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE731053BB82@wds-exc2.okna.nominet.org.uk> References: <5126E021.6020103@mtcc.com> <20130222033242.GE2885509@jupiter.n2.diac24.net> <78F112CE-68D4-4FB3-905D-FEE5F722547D@fugue.com> <5126E9F7.4020906@mtcc.com> <8C669A18-F9A3-44CF-A9B7-CF80884C0698@fugue.com> In-Reply-To: <8C669A18-F9A3-44CF-A9B7-CF80884C0698@fugue.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <7D18478376ADFF4496E287CAD27AB822@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 12:49:12 -0000 On 22 Feb 2013, at 12:37, Ted Lemon wrote: > Er, that came out wrong. I'm agreeing with "want to be able to access d= evices in the home from away," not "working group was chartered in the last= century." :) > I am also skeptical about MDNS as a solution, though. Personally, I think there's still a good argument to be made for reserving = "normal unicast DNS" for access to globally addressable resources (be that = from the home to the outside, or from the outside into the home), whilst us= ing "some other protocol" for truly internal name resolution. I *really* don't like the idea of each individual Homenet having to create = some sort of randomised namespace for its internal DNS. Ray From john_brzozowski@cable.comcast.com Fri Feb 22 05:00:55 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE4621F8E7B for ; Fri, 22 Feb 2013 05:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.302 X-Spam-Level: X-Spam-Status: No, score=-104.302 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJv-ijRis2sM for ; Fri, 22 Feb 2013 05:00:54 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8881B21F8917 for ; Fri, 22 Feb 2013 05:00:54 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57537287; Fri, 22 Feb 2013 05:29:43 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Fri, 22 Feb 2013 08:00:00 -0500 From: "Brzozowski, John" To: Lorenzo Colitti , Dave Taht Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHOEPyFUKHjmYjHJk2z+mbkmocqxw== Date: Fri, 22 Feb 2013 12:59:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="Windows-1252" Content-ID: <70A3A54ADF26D74A919B898A32144779@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , "homenet@ietf.org Group" , Jari Arkko , Mark Townsley , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:00:55 -0000 Not sure I buy the security model angle, IPv4 NAT !=3D security. It would be great if we had a group working on service discovery=8Aoh wait!? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Lorenzo Colitti Date: Thursday, February 21, 2013 5:06 PM To: Dave Taht Cc: John Jason Brzozowski , David Lamparter , Michael Richardson , "homenet@ietf.org Group" , Mark Townsley , Jari Arkko Subject: Re: [homenet] Running code in Orlando >On Fri, Feb 22, 2013 at 1:35 AM, Dave Taht wrote: > >I still find the dynamicism required by renting ipv6 addresses to so >impact in so many aspects of the "sane usage of stuff like printers", and >naming, and the security model as to *demand* ipv6 nat in the home... > > > >Sigh.=20 > > > From john_brzozowski@cable.comcast.com Fri Feb 22 05:00:55 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE1321F8917 for ; Fri, 22 Feb 2013 05:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.418 X-Spam-Level: X-Spam-Status: No, score=-104.418 tagged_above=-999 required=5 tests=[AWL=0.813, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaB7ABv1GfyD for ; Fri, 22 Feb 2013 05:00:54 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id BD8DD21F8E70 for ; Fri, 22 Feb 2013 05:00:54 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57537311; Fri, 22 Feb 2013 05:29:45 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Fri, 22 Feb 2013 08:00:02 -0500 From: "Brzozowski, John" To: Michael Thomas , Lorenzo Colitti Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHOEE56UKHjmYjHJk2z+mbkmocqx5iFEUPtgABba4CAAGudgA== Date: Fri, 22 Feb 2013 13:00:01 +0000 Message-ID: In-Reply-To: <5126CB1D.70705@mtcc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <58DCD809FBDFFE4687B9F4CF7AE3368A@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:00:55 -0000 I second the sigh FWIW. And I do not share Dave's view on IPv6 NAT. What are you asking to be demonstrated? IPv6 NAT? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Michael Thomas Date: Thursday, February 21, 2013 5:34 PM To: Lorenzo Colitti Cc: Dave Taht , Michael Richardson , Mark Townsley , Jari Arkko , John Jason Brzozowski , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] Running code in Orlando >Lorenzo Colitti wrote: >> On Fri, Feb 22, 2013 at 1:35 AM, Dave Taht > > wrote: >>=20 >> I still find the dynamicism required by renting ipv6 addresses to so >> impact in so many aspects of the "sane usage of stuff like >> printers", and naming, and the security model as to *demand* ipv6 >> nat in the home... >>=20 >>=20 >> Sigh.=20 > >Sigh all you like, but I share Dave's skepticism that ISP's renumbering >my prefix >willy-nilly and it just sort of works with naming -- including addresses >squirrelled >away in places they ought not be -- is going to work any time soon. I >don't like to >think that NAT is inevitable but frankly the people in this working group >don't get >to vote on that. > >Speaking to the title of this thread: has anybody actually demonstrated >such a thing >end to end? It strikes me as Frankensteinian when you get all of the body >parts bolted >together. > >Mike From simon@thekelleys.org.uk Fri Feb 22 05:00:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEDD21F8EAC for ; Fri, 22 Feb 2013 05:00:57 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CE2eNoSgOSmd for ; Fri, 22 Feb 2013 05:00:56 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id C7B4F21F8E70 for ; Fri, 22 Feb 2013 05:00:56 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:60185 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U8sFD-00069T-W6 for homenet@ietf.org; Fri, 22 Feb 2013 13:00:56 +0000 Received: from guest-193-062-204-112.wtgc.org ([193.62.204.112]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1U8sFD-0003jA-FN for homenet@ietf.org; Fri, 22 Feb 2013 13:00:55 +0000 Message-ID: <51276C00.7060808@thekelleys.org.uk> Date: Fri, 22 Feb 2013 13:00:48 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> In-Reply-To: <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:00:57 -0000 On 22/02/13 12:30, Ted Lemon wrote: > On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti > wrote: > I think the issue that Michael imagines NPTv6 will address is the > transition period, when the washing machine has two IP addresses, and > the DNS may not have the new address, or may have both addresses, and > he's hoping the gateway will somehow bandage this up. However, the > gateway's ability to bandage this up is more imagined than real, and > we might as well just fix the underlying problem. The current development release of dnsmasq can act as an authoritative DNS server populated with all hosts on a homenet which it knows about from DHCP. Delegate your domain to it, and ensure that the TTL configured for DNS is smaller than the deprecated lifetime of addresses, and this problem should never arise. From v6ops@globis.net Fri Feb 22 05:01:44 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD4721F8ECA for ; Fri, 22 Feb 2013 05:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3YmI0Y46QV3 for ; Fri, 22 Feb 2013 05:01:43 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9C721F8917 for ; Fri, 22 Feb 2013 05:01:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9CF8D870061; Fri, 22 Feb 2013 13:53:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+ONNP01TxXm; Fri, 22 Feb 2013 13:53:26 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 3309F87005B; Fri, 22 Feb 2013 13:53:26 +0100 (CET) Message-ID: <51276A40.5020705@globis.net> Date: Fri, 22 Feb 2013 13:53:20 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Lorenzo Colitti References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ole Troan , "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , "Abhay Roy \(akr\)" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:01:44 -0000 > Lorenzo Colitti > 22 February 2013 11:17 > On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter > wrote: > > But given that route determination is a distributed algorithm, and > that > Homenet devices will not always run the latest and greatest code, > what action should nodes that are running older code take > regarding any > TLV options that they don't understand? > > Isn't there a danger that extensibility will lead to more routing > loops, > instability, and black holes? > > > Yes. If intermediate devices don't understand SADR, you can get > routing loops. We should document that clearly and find out how to > avoid it. > ACK. > > 2. Aren't we forgetting the first hop? > > Given a shared subnet/prefix/link with 2 CPE routers performing some > fancy new form of forwarding (based on PBR or SADR or whatever) > that is > also shared by existing host implementations, how will the routers > signal these new default route semantics to end hosts? > > Would we need a new prefix information option in ND? > > Would we need an extension to RFC 4191 Section 2.3 Route Information > Option to include (source prefix,destination prefix) routes? > > Would we need a new ICMPv6 redirect message to extend RFC2461 Section > 4.5 to include the possibility of (source,destination) redirects? > > > The beauty of this approach is that you don't need to signal anything > to the hosts for things to work properly. The hosts pick whatever > source address they choose and the network takes care of getting the > packet to the right exit. > Don't understand. Maybe I'm being really dumb. What about figure 2 of the Homenet Architecture? +-------+-------+ +-------+-------+ \ | Service | | Service | \ | Provider A | | Provider B | | Service | Router | | Router | | Provider +------+--------+ +-------+-------+ | network | | / | Customer | / | Internet connections | / | | +------+--------+ +-------+-------+ \ | IPv6 | | IPv6 | \ | Customer Edge | | Customer Edge | \ | Router 1 | | Router 2 | / +------+--------+ +-------+-------+ / | | / | | | End-User ---+---------+---+---------------+--+----------+--- | network(s) | | | | \ +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / | H1 | | H2 | | H3 | | H4 | / +----------+ +----------+ +----------+ +----------+ Figure 2 IPv6 Host H1 will receive RA messages from R1 and R2, and add them both to the default router list (RFC2461 6.3.6). IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with autoconfiguration and on-link flags set, and configure /64 prefixes from both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these as being on-link. But IMHO there's no further AS number/provider information/upstream topology information coupled to these /64 prefixes. There might be a router-router interconnect LAN between R1 and R2, or there might not be. How will the host H1 know to associate source address prefixes from provider2 with router2 for off link destinations e.g. to a Provider2/56 or Provider2/32? My expected host behavior would currently be that it'd just choose one of the known available default routers from the list. If correct fine. If not, then wait for an ICMPv6 redirect to be told to use the other router. But the ICMPv6 redirect doesn't have any facility to include source prefix specific info: only a redirect for a destination prefix to use another router (for all source prefixes), not for a source/destination pair. In the situation depicted in Homenet Arch figure 2, there will almost certainly be two valid routes to e.g. www.google.com, one via each provider, with the correct 1st hop router dependent purely on the source prefix. Even with RFC4191, the extension only provides routing information for a host to be able to select a default router based on the destination prefix, not an associated source prefix. Are we saying that H1 should tightly couple source address selection with RA PIO & default router selection? Thus H1 should never send packets with a source address derived from a PIO received in an RA from R2, to a potential default router R1 that sent an RA message but did not include a PIO for this particular source prefix? Where is this behavior defined in an RFC? I don't see it in http://www.ietf.org/rfc/rfc2461.txt Section 4.2 or http://tools.ietf.org/html/rfc4862#page-18 In fact section 6.3.6. on default router selection is quite explicit and doesn't mention associating potential default routers with prefix information options at all AFAIK. Are we saying that R1 should forward any packets it receives for (source_provider_prefix 2, ::/0) back over the same LAN to R2 without an ICMPv6 redirect? [Assuming R1 is managed by Provider 1 and R2 is managed by Provider 2] Won't the providers naturally want to apply their BCP38 ingress filter on the LAN interface of their CPE routers? as per draft-ietf-v6ops-6204bis-12 L-14 [LAN side requirements] The IPv6 CE router MUST send an ICMPv6 Destination Unreachable message, code 5 (Source address failed ingress/egress policy) for packets forwarded to it that use an address from a prefix that has been invalidated. > If the right exit is down or gone, then the packet gets dropped, but > as the SADR draft explains, you can fix this by telling the homenet > routers to deprecate prefixes for which there is no exit. The hosts > will then avoid those source addresses for new connections. (The > authors of said draft do not agree amongst themselves whether this is > the right thing to do or not; but no doubt the WG will have useful > opinions here). > Understand this. It's the first hop that bother me. Maybe Figure 2 in the Homenet Architecture is actually a fundamentally flawed topology, purely from a management perspective. > If you want the hosts to do better load-balancing, then you do need to > give them more information. We haven't looked at this. > > If you want to support walled garden prefixes that do not have > complete reachability, then you need to tell the hosts not to use > them. I believe DHCPv6 options exist to configure RFC 6724 policy on > hosts, but I don't know if anyone supports them, and I haven't thought > about the security issues or how to propagate that information through > the homenet. > > 3. Limiting this discussion strictly to Homenet requirements: > Aren't we > forgetting the inter-provider management boundary? > > My view of the Homenet is a network that is potentially a member of > multiple overlapping AS's simultaneously, without being an AS itself. > That's highly unusual in routing protocol terms. > > I think that it is very unlikely that any operator will allow any > dynamic routing between a CPE managed by a customer and a PE > managed by > the provider. > > I think there's also a potential issue of anyone making any > assumptions > about dynamic routing being available between a provider-managed > CPE and > a customer owned CPE. Software version control will not be trivial. > > The current most likely source of external routing information is > DHCPv6-PD, used to locally autoconfigure a "floating static" default > route on the Homenet BR, pointing out of the upstream interface to > "the > Internet". > > As such, how will any routing information beyond a simple default > route > (related to a single delegated prefix) be injected into the Homenet? > > Why are we importing the extra complexity (related to data centres and > enterprises) into Homenet? > > > I thought the idea was that border routers would just do DHCPv6 PD and > inject whatever routes they get into the homenet tagged with whatever > source prefix they get. Yes. > They wouldn't participate in any routing protocol with the ISP. We > don't currently have any other mechanism for learning external routes, > but when we do we can simply treat them in the same way. > > Does this not work for some reason? > No problem, but why worry about it now if it greatly increases the complexity? draft-ietf-v6ops-6204bis-12 effectively limits information in Homenet to simple default routes per provider only. W-3: Absent other routing information, the IPv6 CE router MUST use Router Discovery as specified in [RFC4861] to discover a default router(s) and install default route(s) in its routing table with the discovered router's address as the next hop. WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic routing protocol on its WAN interface. > > 6. Other potentially simpler approaches that might be faster to market > I have provided detailed feedback to Ole & Lorenzo, suggesting how > Homenet could potentially work without modifying any routing protocols > at all, with multi-homing, without resorting to NPT, and with BCP38 > ingress/egress filters (albeit with a hard link to some > yet-to-be-defined autoconfiguration protocol, and a limit that the > prefixes of any walled-gardens must be disjoint from other AS's > directly > connected to this Homenet, and possibly some other limitations such as > dumb hosts should not be connected to dual routers from competing > providers). > > > Did I miss this? Where can I find it? Was it sent to the list? Yes. http://www.ietf.org/mail-archive/web/homenet/current/msg02130.html > Ray Hunter > 22 February 2013 10:52 > I have read all of your drafts, and those of the other authors, > carefully, once. No doubt I'll have to re-read them. > > This response is limited to high level comments regarding the overall > approach, and isprobably applicable to all 3 sets of authors : > > 1. Some drafts talk extensively about the need for an "extensible" > routing protocol, and often mention the desirability of TLV > (type-length-value) objects. > > I agree that a TLV structure potentially solves many issues of how to > encode and transport new options between routing protocol speakers. > > But given that route determination is a distributed algorithm, and that > Homenet devices will not always run the latest and greatest code, > what action should nodes that are running older code take regarding any > TLV options that they don't understand? > > Isn't there a danger that extensibility will lead to more routing loops, > instability, and black holes? > > Is there a need for all speakers to first agree the (newest) > commonly-understood subset of options that all speakers in a Homenet > can/will honour before any extension options are transmitted? > > 2. Aren't we forgetting the first hop? > > Given a shared subnet/prefix/link with 2 CPE routers performing some > fancy new form of forwarding (based on PBR or SADR or whatever) that is > also shared by existing host implementations, how will the routers > signal these new default route semantics to end hosts? > > Would we need a new prefix information option in ND? > > Would we need an extension to RFC 4191 Section 2.3 Route Information > Option to include (source prefix,destination prefix) routes? > > Would we need a new ICMPv6 redirect message to extend RFC2461 Section > 4.5 to include the possibility of (source,destination) redirects? > > 3. Limiting this discussion strictly to Homenet requirements: Aren't we > forgetting the inter-provider management boundary? > > My view of the Homenet is a network that is potentially a member of > multiple overlapping AS's simultaneously, without being an AS itself. > That's highly unusual in routing protocol terms. > > I think that it is very unlikely that any operator will allow any > dynamic routing between a CPE managed by a customer and a PE managed by > the provider. > > I think there's also a potential issue of anyone making any assumptions > about dynamic routing being available between a provider-managed CPE and > a customer owned CPE. Software version control will not be trivial. > > The current most likely source of external routing information is > DHCPv6-PD, used to locally autoconfigure a "floating static" default > route on the Homenet BR, pointing out of the upstream interface to "the > Internet". > > As such, how will any routing information beyond a simple default route > (related to a single delegated prefix) be injected into the Homenet? > > Why are we importing the extra complexity (related to data centres and > enterprises) into Homenet? > > 4. We're still planning on doing something about source address > selection, aren't we? > For all the suggested complexity of the packet routing solutions > suggested so far, isn't the real "route" selection going to be performed > in the host? > > 5. Flow label routing: hasn't rfc6437 scuppered any chance that the flow > labels themselves will directly carry any meaning that could be > realistically used to make deterministic forwarding decisions by > low/mid-powered routers, because you're essentially going to have to > reverse a 20 bit hash function to make a forwarding decision? Wouldn't > the requirements in rfc6437 also suggest a routing table explosion, > because each individual flow would have to be associated with an > individual IS-IS route? Perhaps you could distribute some intermediate > result to end hosts and routers via IS-IS,which is deterministic and > related to policy based routing (such as including the tenant label in a > TLV), but which after applying some hash transform and adding some > entropy, would comply with the requirements of 6437? That'd potentially > reduce the IS-IS routing table size dramatically. I've been waiting 15+ > years for fully dynamic PBR and I fully expect to wait some time longer. > In any case, with all due respect, I don't think it's relevant for > Homenet, > > 6. Other potentially simpler approaches that might be faster to market > I have provided detailed feedback to Ole & Lorenzo, suggesting how > Homenet could potentially work without modifying any routing protocols > at all, with multi-homing, without resorting to NPT, and with BCP38 > ingress/egress filters (albeit with a hard link to some > yet-to-be-defined autoconfiguration protocol, and a limit that the > prefixes of any walled-gardens must be disjoint from other AS's directly > connected to this Homenet, and possibly some other limitations such as > dumb hosts should not be connected to dual routers from competing > providers). > > Do I need to write a draft on this, or is this already clear? > Would someone be willing to help out/ collaborate? > > If I have other detailed comments on the individual drafts, I'll come > back with those. > > regards, > RayH > > Fred Baker (fred) wrote: > > ------------------------------------------------------------------------ From john_brzozowski@cable.comcast.com Fri Feb 22 05:02:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB9521F8E7B for ; Fri, 22 Feb 2013 05:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.509 X-Spam-Level: X-Spam-Status: No, score=-104.509 tagged_above=-999 required=5 tests=[AWL=0.722, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ632eQUuXwy for ; Fri, 22 Feb 2013 05:02:25 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2DA21F8E70 for ; Fri, 22 Feb 2013 05:02:25 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57537633; Fri, 22 Feb 2013 05:31:16 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Fri, 22 Feb 2013 08:01:32 -0500 From: "Brzozowski, John" To: Lorenzo Colitti , Michael Thomas Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHOEE56UKHjmYjHJk2z+mbkmocqx5iFEUPtgABba4CAAAPjAIAAaEeA Date: Fri, 22 Feb 2013 13:01:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4D0F2FE4E6B89743A46CF55BD503D478@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:02:27 -0000 >Actually they do. They have the freedom to specify alternatives, and >depending on how good a job they do, implementers may choose to use them. =8Aand providing that these are specified by people who know what they doin= g and understand the problem that is being solved/addressed. :O From ot@cisco.com Fri Feb 22 05:06:47 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DB521F8F16 for ; Fri, 22 Feb 2013 05:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.485 X-Spam-Level: X-Spam-Status: No, score=-10.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mjrFZiLtu+f for ; Fri, 22 Feb 2013 05:06:45 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7974B21F8E3C for ; Fri, 22 Feb 2013 05:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16990; q=dns/txt; s=iport; t=1361538404; x=1362748004; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nzH0ymXLu12ECLgFUI/Vmzn5DJxs0+HaE5GgtdVDD5o=; b=dvEMFZ7YhKeu/6yb/jW/9GBodbAEubxGh7C9cBKklTabDDcc2Ax/JRuv iAYmHcad9zdm5SLtbe1r1O1GWFw6hmtaNm1EMu+mqGnjt8BgYyK2rcEZK LRrm+lvBY2MVuXJrOz+xvYJwXJPqSqSGp13/SJfSZswsIJlgc4LCNq32e 0=; X-IronPort-AV: E=Sophos;i="4.84,715,1355097600"; d="scan'208";a="80637701" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 22 Feb 2013 13:06:42 +0000 Received: from dhcp-lys02-vla252-10-147-116-46.cisco.com (dhcp-lys02-vla252-10-147-116-46.cisco.com [10.147.116.46]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1MD6grF008940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Feb 2013 13:06:42 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <51276A40.5020705@globis.net> Date: Fri, 22 Feb 2013 14:06:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3E23756C-A4E4-4D48-B534-EAB191F1AA48@cisco.com> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> <51276A40.5020705@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1499) Cc: "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , Lorenzo Colitti , "Abhay Roy \(akr\)" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:06:47 -0000 Ray, [...] >> 2. Aren't we forgetting the first hop? >>=20 >> Given a shared subnet/prefix/link with 2 CPE routers performing = some >> fancy new form of forwarding (based on PBR or SADR or whatever) >> that is >> also shared by existing host implementations, how will the routers >> signal these new default route semantics to end hosts? >>=20 >> Would we need a new prefix information option in ND? >>=20 >> Would we need an extension to RFC 4191 Section 2.3 Route = Information >> Option to include (source prefix,destination prefix) routes? >>=20 >> Would we need a new ICMPv6 redirect message to extend RFC2461 = Section >> 4.5 to include the possibility of (source,destination) redirects? >>=20 >>=20 >> The beauty of this approach is that you don't need to signal anything >> to the hosts for things to work properly. The hosts pick whatever >> source address they choose and the network takes care of getting the >> packet to the right exit. >>=20 > Don't understand. Maybe I'm being really dumb. >=20 > What about figure 2 of the Homenet Architecture? >=20 > +-------+-------+ +-------+-------+ \ > | Service | | Service | \ > | Provider A | | Provider B | | Service > | Router | | Router | | Provider > +------+--------+ +-------+-------+ | network > | | / > | Customer | / > | Internet connections | / > | | > +------+--------+ +-------+-------+ \ > | IPv6 | | IPv6 | \ > | Customer Edge | | Customer Edge | \ > | Router 1 | | Router 2 | / > +------+--------+ +-------+-------+ / > | | / > | | | End-User > ---+---------+---+---------------+--+----------+--- | network(s) > | | | | \ > +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ > |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / > | H1 | | H2 | | H3 | | H4 | / > +----------+ +----------+ +----------+ +----------+ >=20 > Figure 2 >=20 > >=20 > IPv6 Host H1 will receive RA messages from R1 and R2, and add them = both > to the default router list (RFC2461 6.3.6). >=20 > IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with > autoconfiguration and on-link flags set, and configure /64 prefixes = from > both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these > as being on-link. >=20 > But IMHO there's no further AS number/provider information/upstream > topology information coupled to these /64 prefixes. There might be a > router-router interconnect LAN between R1 and R2, or there might not = be. if there is no interconnect between R1 and R2, then the host has two interfaces connected to two separate connections. then I can't see how that can be solved in the network. my assumption is that all homenet = routers must be connected (I see I haven't stated that anywhere, but that should = be added). > How will the host H1 know to associate source address prefixes from > provider2 with router2 for off link destinations e.g. to a = Provider2/56 > or Provider2/32? in your case it will RFC6724, rule 5.5 > My expected host behavior would currently be that it'd just choose one > of the known available default routers from the list. If correct fine. > If not, then wait for an ICMPv6 redirect to be told to use the other = router. you would only get that if the routers were connected of course. whichever came first, you'd either get a unreachable code 5 (wrong = source) or ICMP redirect, or the router would just forward the packet to second = router. > But the ICMPv6 redirect doesn't have any facility to include source > prefix specific info: only a redirect for a destination prefix to use > another router (for all source prefixes), not for a source/destination > pair. In the situation depicted in Homenet Arch figure 2, there will > almost certainly be two valid routes to e.g. www.google.com, one via > each provider, with the correct 1st hop router dependent purely on the > source prefix. I agree, there is nothing useful the host learns from an ICMP redirect = here. > Even with RFC4191, the extension only provides routing information for = a > host to be able to select a default router based on the destination > prefix, not an associated source prefix. >=20 > Are we saying that H1 should tightly couple source address selection > with RA PIO & default router selection? for directly connected hosts, we have that already. note that only = applies when hosts are connected to the border router. > Thus H1 should never send packets with a source address derived from a > PIO received in an RA from R2, to a potential default router R1 that > sent an RA message but did not include a PIO for this particular = source > prefix? >=20 > Where is this behavior defined in an RFC? I don't see it in > http://www.ietf.org/rfc/rfc2461.txt Section 4.2 or > http://tools.ietf.org/html/rfc4862#page-18 > In fact section 6.3.6. on default router selection is quite explicit = and > doesn't mention associating potential default routers with prefix > information options at all AFAIK. again, that's rule 5.5 (which is somewhat weak) in 6724. > Are we saying that R1 should forward any packets it receives for > (source_provider_prefix 2, ::/0) back over the same LAN to R2 without = an > ICMPv6 redirect? [Assuming R1 is managed by Provider 1 and R2 is = managed > by Provider 2] yes, I think we probably would want to say that. > Won't the providers naturally want to apply their BCP38 ingress filter > on the LAN interface of their CPE routers?=20 > as per draft-ietf-v6ops-6204bis-12 L-14 [LAN side requirements] >=20 > The IPv6 CE router MUST send an ICMPv6 Destination Unreachable > message, code 5 (Source address failed ingress/egress policy) > for packets forwarded to it that use an address from a prefix > that has been invalidated. >=20 >=20 >> If the right exit is down or gone, then the packet gets dropped, but >> as the SADR draft explains, you can fix this by telling the homenet >> routers to deprecate prefixes for which there is no exit. The hosts >> will then avoid those source addresses for new connections. (The >> authors of said draft do not agree amongst themselves whether this is >> the right thing to do or not; but no doubt the WG will have useful >> opinions here). >>=20 > Understand this. It's the first hop that bother me. >=20 > Maybe Figure 2 in the Homenet Architecture is actually a fundamentally > flawed topology, purely from a management perspective. >> If you want the hosts to do better load-balancing, then you do need = to >> give them more information. We haven't looked at this. >>=20 >> If you want to support walled garden prefixes that do not have >> complete reachability, then you need to tell the hosts not to use >> them. I believe DHCPv6 options exist to configure RFC 6724 policy on >> hosts, but I don't know if anyone supports them, and I haven't = thought >> about the security issues or how to propagate that information = through >> the homenet. >>=20 >> 3. Limiting this discussion strictly to Homenet requirements: >> Aren't we >> forgetting the inter-provider management boundary? >>=20 >> My view of the Homenet is a network that is potentially a member = of >> multiple overlapping AS's simultaneously, without being an AS = itself. >> That's highly unusual in routing protocol terms. >>=20 >> I think that it is very unlikely that any operator will allow any >> dynamic routing between a CPE managed by a customer and a PE >> managed by >> the provider. >>=20 >> I think there's also a potential issue of anyone making any >> assumptions >> about dynamic routing being available between a provider-managed >> CPE and >> a customer owned CPE. Software version control will not be = trivial. >>=20 >> The current most likely source of external routing information is >> DHCPv6-PD, used to locally autoconfigure a "floating static" = default >> route on the Homenet BR, pointing out of the upstream interface to >> "the >> Internet". >>=20 >> As such, how will any routing information beyond a simple default >> route >> (related to a single delegated prefix) be injected into the = Homenet? >>=20 >> Why are we importing the extra complexity (related to data centres = and >> enterprises) into Homenet? >>=20 >>=20 >> I thought the idea was that border routers would just do DHCPv6 PD = and >> inject whatever routes they get into the homenet tagged with whatever >> source prefix they get. > Yes. >> They wouldn't participate in any routing protocol with the ISP. We >> don't currently have any other mechanism for learning external = routes, >> but when we do we can simply treat them in the same way. >>=20 >> Does this not work for some reason? >>=20 > No problem, but why worry about it now if it greatly increases the > complexity? >=20 > draft-ietf-v6ops-6204bis-12 effectively limits information in Homenet = to > simple default routes per provider only. >=20 > W-3: Absent other routing information, the IPv6 CE router MUST use > Router Discovery as specified in [RFC4861] to discover a > default router(s) and install default route(s) in its routing > table with the discovered router's address as the next hop. >=20 > WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic > routing protocol on its WAN interface. >>=20 but 6204 does support more specific routes in RAs (RFC4191?) >> 6. Other potentially simpler approaches that might be faster to = market >> I have provided detailed feedback to Ole & Lorenzo, suggesting how >> Homenet could potentially work without modifying any routing = protocols >> at all, with multi-homing, without resorting to NPT, and with = BCP38 >> ingress/egress filters (albeit with a hard link to some >> yet-to-be-defined autoconfiguration protocol, and a limit that the >> prefixes of any walled-gardens must be disjoint from other AS's >> directly >> connected to this Homenet, and possibly some other limitations = such as >> dumb hosts should not be connected to dual routers from competing >> providers). >>=20 >>=20 >> Did I miss this? Where can I find it? Was it sent to the list? > Yes. = http://www.ietf.org/mail-archive/web/homenet/current/msg02130.html >> Ray Hunter >> 22 February 2013 10:52 >> I have read all of your drafts, and those of the other authors, >> carefully, once. No doubt I'll have to re-read them. >>=20 >> This response is limited to high level comments regarding the overall >> approach, and isprobably applicable to all 3 sets of authors : >>=20 >> 1. Some drafts talk extensively about the need for an "extensible" >> routing protocol, and often mention the desirability of TLV >> (type-length-value) objects. >>=20 >> I agree that a TLV structure potentially solves many issues of how to >> encode and transport new options between routing protocol speakers. >>=20 >> But given that route determination is a distributed algorithm, and = that >> Homenet devices will not always run the latest and greatest code, >> what action should nodes that are running older code take regarding = any >> TLV options that they don't understand? >>=20 >> Isn't there a danger that extensibility will lead to more routing = loops, >> instability, and black holes? >>=20 >> Is there a need for all speakers to first agree the (newest) >> commonly-understood subset of options that all speakers in a Homenet >> can/will honour before any extension options are transmitted? >>=20 >> 2. Aren't we forgetting the first hop? >>=20 >> Given a shared subnet/prefix/link with 2 CPE routers performing some >> fancy new form of forwarding (based on PBR or SADR or whatever) that = is >> also shared by existing host implementations, how will the routers >> signal these new default route semantics to end hosts? >>=20 >> Would we need a new prefix information option in ND? >>=20 >> Would we need an extension to RFC 4191 Section 2.3 Route Information >> Option to include (source prefix,destination prefix) routes? >>=20 >> Would we need a new ICMPv6 redirect message to extend RFC2461 Section >> 4.5 to include the possibility of (source,destination) redirects? >>=20 >> 3. Limiting this discussion strictly to Homenet requirements: Aren't = we >> forgetting the inter-provider management boundary? >>=20 >> My view of the Homenet is a network that is potentially a member of >> multiple overlapping AS's simultaneously, without being an AS itself. >> That's highly unusual in routing protocol terms. >>=20 >> I think that it is very unlikely that any operator will allow any >> dynamic routing between a CPE managed by a customer and a PE managed = by >> the provider. >>=20 >> I think there's also a potential issue of anyone making any = assumptions >> about dynamic routing being available between a provider-managed CPE = and >> a customer owned CPE. Software version control will not be trivial. >>=20 >> The current most likely source of external routing information is >> DHCPv6-PD, used to locally autoconfigure a "floating static" default >> route on the Homenet BR, pointing out of the upstream interface to = "the >> Internet". >>=20 >> As such, how will any routing information beyond a simple default = route >> (related to a single delegated prefix) be injected into the Homenet? >>=20 >> Why are we importing the extra complexity (related to data centres = and >> enterprises) into Homenet? >>=20 >> 4. We're still planning on doing something about source address >> selection, aren't we? >> For all the suggested complexity of the packet routing solutions >> suggested so far, isn't the real "route" selection going to be = performed >> in the host? >>=20 >> 5. Flow label routing: hasn't rfc6437 scuppered any chance that the = flow >> labels themselves will directly carry any meaning that could be >> realistically used to make deterministic forwarding decisions by >> low/mid-powered routers, because you're essentially going to have to >> reverse a 20 bit hash function to make a forwarding decision? = Wouldn't >> the requirements in rfc6437 also suggest a routing table explosion, >> because each individual flow would have to be associated with an >> individual IS-IS route? Perhaps you could distribute some = intermediate >> result to end hosts and routers via IS-IS,which is deterministic and >> related to policy based routing (such as including the tenant label = in a >> TLV), but which after applying some hash transform and adding some >> entropy, would comply with the requirements of 6437? That'd = potentially >> reduce the IS-IS routing table size dramatically. I've been waiting = 15+ >> years for fully dynamic PBR and I fully expect to wait some time = longer. >> In any case, with all due respect, I don't think it's relevant for >> Homenet, >>=20 >> 6. Other potentially simpler approaches that might be faster to = market >> I have provided detailed feedback to Ole & Lorenzo, suggesting how >> Homenet could potentially work without modifying any routing = protocols >> at all, with multi-homing, without resorting to NPT, and with BCP38 >> ingress/egress filters (albeit with a hard link to some >> yet-to-be-defined autoconfiguration protocol, and a limit that the >> prefixes of any walled-gardens must be disjoint from other AS's = directly >> connected to this Homenet, and possibly some other limitations such = as >> dumb hosts should not be connected to dual routers from competing >> providers). >>=20 >> Do I need to write a draft on this, or is this already clear? >> Would someone be willing to help out/ collaborate? >>=20 >> If I have other detailed comments on the individual drafts, I'll come >> back with those. >>=20 >> regards, >> RayH >>=20 >> Fred Baker (fred) wrote: >>=20 >> = ------------------------------------------------------------------------ >=20 cheers, Ole From equinox@diac24.net Fri Feb 22 05:08:03 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9394321F8F30 for ; Fri, 22 Feb 2013 05:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1-fgt+dzHRC for ; Fri, 22 Feb 2013 05:08:03 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1558A21F8EE9 for ; Fri, 22 Feb 2013 05:08:03 -0800 (PST) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2::]) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U8sM5-0007cs-Ku; Fri, 22 Feb 2013 14:08:01 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1U8sLs-00Dc8w-Pg; Fri, 22 Feb 2013 14:07:51 +0100 Date: Fri, 22 Feb 2013 14:07:48 +0100 From: David Lamparter To: Simon Kelley Message-ID: <20130222130748.GC3183407@jupiter.n2.diac24.net> References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51276C00.7060808@thekelleys.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51276C00.7060808@thekelleys.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: homenet@ietf.org Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:08:03 -0000 On Fri, Feb 22, 2013 at 01:00:48PM +0000, Simon Kelley wrote: > On 22/02/13 12:30, Ted Lemon wrote: > > On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti > > wrote: > > > I think the issue that Michael imagines NPTv6 will address is the > > transition period, when the washing machine has two IP addresses, and > > the DNS may not have the new address, or may have both addresses, and > > he's hoping the gateway will somehow bandage this up. However, the > > gateway's ability to bandage this up is more imagined than real, and > > we might as well just fix the underlying problem. > > The current development release of dnsmasq can act as an authoritative > DNS server populated with all hosts on a homenet which it knows about > from DHCP. Delegate your domain to it, and ensure that the TTL > configured for DNS is smaller than the deprecated lifetime of addresses, > and this problem should never arise. This only works with stateful DHCPv6 though? -David From john_brzozowski@cable.comcast.com Fri Feb 22 05:09:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4373F21F87B1 for ; Fri, 22 Feb 2013 05:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.581 X-Spam-Level: X-Spam-Status: No, score=-104.581 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiOJMAGMJHdD for ; Fri, 22 Feb 2013 05:09:19 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 16F0021F87AA for ; Fri, 22 Feb 2013 05:09:19 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57538355; Fri, 22 Feb 2013 05:38:11 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Fri, 22 Feb 2013 08:08:28 -0500 From: "Brzozowski, John" To: Michael Thomas , Lorenzo Colitti Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHOEE56UKHjmYjHJk2z+mbkmocqx5iFEUPtgABba4CAAAPjAIAAAnsAgABntYA= Date: Fri, 22 Feb 2013 13:08:27 +0000 Message-ID: In-Reply-To: <5126D074.4090302@mtcc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:09:20 -0000 -----Original Message----- From: Michael Thomas Date: Thursday, February 21, 2013 5:57 PM To: Lorenzo Colitti Cc: Dave Taht , Michael Richardson , Mark Townsley , Jari Arkko , John Jason Brzozowski , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] Running code in Orlando >Lorenzo Colitti wrote: >> On Fri, Feb 22, 2013 at 10:34 AM, Michael Thomas > > wrote: >>=20 >> Sigh. >>=20 >>=20 >> Sigh all you like, but I share Dave's skepticism that ISP's >> renumbering my prefix willy-nilly and it just sort of works with >> naming -- including addresses squirrelled away in places they ought >> not be -- is going to work any time soon. >>=20 >>=20 >> That's why we have ULAs and multiple prefixes. > >ULA's are of limited use. I still want to start my washing machine >regardless of >whether I'm at home or not. [jjmb] maybe today, who knows about tomorrow. > > >> I don't like to think that NAT is inevitable but frankly the people >> in this working group don't get to vote on that. >>=20 >>=20 >> Actually they do. They have the freedom to specify alternatives, and >> depending on how good a job they do, implementers may choose to use >>them. > >Wishful thinking. NAT's didn't start with the blessing of IETF as I >recall. They just >happened. If the alternatives are too whacked out, history will repeat >itself. [jjmb] not sure I agree here, the conditions and parameters are different today specifically there are currently no issues with IPv6 resource availability. > > >> Speaking to the title of this thread: has anybody actually >> demonstrated such a thing end to end? It strikes me as >> Frankensteinian when you get all of the body parts bolted together. >>=20 >>=20 >> What thing exactly? Multiprefix multihoming? End-to-end connectivity in >> general? > >Yes, along with naming, security, prefix delegation across multiple >routers, and isp's >giving and withdrawing prefixes due to renumbering. I'm dubious that this >has happened >in real life with networks with people whose day job is to worry about >such things, and >I'd be astonished to hear such a thing has been shown to work on a home >network. [jjmb] hmmm we have quite a few real customers that are using IPv6 enabled on a daily basis mostly using technology that we specified ~8 years ago. Does this count? > >Mike From simon@thekelleys.org.uk Fri Feb 22 05:24:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AFC21F8F7F for ; Fri, 22 Feb 2013 05:24:57 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IGvIq+8vRck for ; Fri, 22 Feb 2013 05:24:57 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id E499721F8F82 for ; Fri, 22 Feb 2013 05:24:55 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:60225 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U8scP-0006FF-AE; Fri, 22 Feb 2013 13:24:53 +0000 Received: from guest-193-062-204-112.wtgc.org ([193.62.204.112]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1U8scO-0004SS-Qv; Fri, 22 Feb 2013 13:24:52 +0000 Message-ID: <5127719E.7020300@thekelleys.org.uk> Date: Fri, 22 Feb 2013 13:24:46 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: David Lamparter References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51276C00.7060808@thekelleys.org.uk> <20130222130748.GC3183407@jupiter.n2.diac24.net> In-Reply-To: <20130222130748.GC3183407@jupiter.n2.diac24.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:24:58 -0000 On 22/02/13 13:07, David Lamparter wrote: > On Fri, Feb 22, 2013 at 01:00:48PM +0000, Simon Kelley wrote: >> On 22/02/13 12:30, Ted Lemon wrote: >>> On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti >>> wrote: >> >>> I think the issue that Michael imagines NPTv6 will address is the >>> transition period, when the washing machine has two IP addresses, and >>> the DNS may not have the new address, or may have both addresses, and >>> he's hoping the gateway will somehow bandage this up. However, the >>> gateway's ability to bandage this up is more imagined than real, and >>> we might as well just fix the underlying problem. >> >> The current development release of dnsmasq can act as an authoritative >> DNS server populated with all hosts on a homenet which it knows about >> from DHCP. Delegate your domain to it, and ensure that the TTL >> configured for DNS is smaller than the deprecated lifetime of addresses, >> and this problem should never arise. > > This only works with stateful DHCPv6 though? It works as well for clients which do DHCPv4 and SLAAC. IPv6-only hosts would have to do stateful DHCPv6, but the DHCPv4 and SLAAC model covers an awful lot of currently-deployed clients. The IPv4 addresses can be RFC1918, the DHCPv4 lease is used to give dnsmasq the MAC address and name of a client. The authoritative DNS module is configurable to expose global IPv6 addresses and hide RFC1918 IPv4 addresses. Simon. From v6ops@globis.net Fri Feb 22 05:52:50 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C9C21F8E17 for ; Fri, 22 Feb 2013 05:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.394 X-Spam-Level: X-Spam-Status: No, score=-3.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VerUsBkUSlab for ; Fri, 22 Feb 2013 05:52:48 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7587E21F8EAF for ; Fri, 22 Feb 2013 05:52:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0C610870061; Fri, 22 Feb 2013 14:47:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVGMXx00QPAM; Fri, 22 Feb 2013 14:46:50 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E5E7887005F; Fri, 22 Feb 2013 14:46:49 +0100 (CET) Message-ID: <512776C3.4010106@globis.net> Date: Fri, 22 Feb 2013 14:46:43 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Ole Troan References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> <51276A40.5020705@globis.net> <3E23756C-A4E4-4D48-B534-EAB191F1AA48@cisco.com> In-Reply-To: <3E23756C-A4E4-4D48-B534-EAB191F1AA48@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , Lorenzo Colitti , "Abhay Roy \(akr\)" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:52:50 -0000 > Ole Troan > 22 February 2013 14:06 > Ray, > > [...] > >>> 2. Aren't we forgetting the first hop? >>> >>> Given a shared subnet/prefix/link with 2 CPE routers performing some >>> fancy new form of forwarding (based on PBR or SADR or whatever) >>> that is >>> also shared by existing host implementations, how will the routers >>> signal these new default route semantics to end hosts? >>> >>> Would we need a new prefix information option in ND? >>> >>> Would we need an extension to RFC 4191 Section 2.3 Route Information >>> Option to include (source prefix,destination prefix) routes? >>> >>> Would we need a new ICMPv6 redirect message to extend RFC2461 Section >>> 4.5 to include the possibility of (source,destination) redirects? >>> >>> >>> The beauty of this approach is that you don't need to signal anything >>> to the hosts for things to work properly. The hosts pick whatever >>> source address they choose and the network takes care of getting the >>> packet to the right exit. >>> >> Don't understand. Maybe I'm being really dumb. >> >> What about figure 2 of the Homenet Architecture? >> >> +-------+-------+ +-------+-------+ \ >> | Service | | Service | \ >> | Provider A | | Provider B | | Service >> | Router | | Router | | Provider >> +------+--------+ +-------+-------+ | network >> | | / >> | Customer | / >> | Internet connections | / >> | | >> +------+--------+ +-------+-------+ \ >> | IPv6 | | IPv6 | \ >> | Customer Edge | | Customer Edge | \ >> | Router 1 | | Router 2 | / >> +------+--------+ +-------+-------+ / >> | | / >> | | | End-User >> ---+---------+---+---------------+--+----------+--- | network(s) >> | | | | \ >> +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ >> |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / >> | H1 | | H2 | | H3 | | H4 | / >> +----------+ +----------+ +----------+ +----------+ >> >> Figure 2 >> >> >> >> IPv6 Host H1 will receive RA messages from R1 and R2, and add them both >> to the default router list (RFC2461 6.3.6). >> >> IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with >> autoconfiguration and on-link flags set, and configure /64 prefixes from >> both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these >> as being on-link. >> >> But IMHO there's no further AS number/provider information/upstream >> topology information coupled to these /64 prefixes. There might be a >> router-router interconnect LAN between R1 and R2, or there might not be. > > if there is no interconnect between R1 and R2, then the host has two > interfaces connected to two separate connections. then I can't see how > that can be solved in the network. my assumption is that all homenet routers > must be connected (I see I haven't stated that anywhere, but that should be added). > >> How will the host H1 know to associate source address prefixes from >> provider2 with router2 for off link destinations e.g. to a Provider2/56 >> or Provider2/32? > > in your case it will RFC6724, rule 5.5 Doh! Thanks. Agree it'll work, but possibly not for all current implementations. > >>> They wouldn't participate in any routing protocol with the ISP. We >>> don't currently have any other mechanism for learning external routes, >>> but when we do we can simply treat them in the same way. >>> >>> Does this not work for some reason? >>> >> No problem, but why worry about it now if it greatly increases the >> complexity? >> >> draft-ietf-v6ops-6204bis-12 effectively limits information in Homenet to >> simple default routes per provider only. >> >> W-3: Absent other routing information, the IPv6 CE router MUST use >> Router Discovery as specified in [RFC4861] to discover a >> default router(s) and install default route(s) in its routing >> table with the discovered router's address as the next hop. >> >> WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic >> routing protocol on its WAN interface. > > but 6204 does support more specific routes in RAs (RFC4191?) Yes, on the LAN interface in requirement L3, purely for advertising ULA and delegated prefixes. RFC4191 isn't excluded on the WAN for learning upstream prefixes (from a walled garden), but it's also not explicitly required either. Perhaps it should be. I'm not 100% convinced of the use case though. Currently only default route(s) are mentioned on the WAN interface. From mcr@sandelman.ca Fri Feb 22 06:17:36 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6828821F8E36 for ; Fri, 22 Feb 2013 06:17:36 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEzitjyktz4K for ; Fri, 22 Feb 2013 06:17:36 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 258F021F8E28 for ; Fri, 22 Feb 2013 06:17:30 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5595C2016D; Fri, 22 Feb 2013 09:24:23 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id DD5A26387F; Fri, 22 Feb 2013 09:16:21 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CE5D463765; Fri, 22 Feb 2013 09:16:21 -0500 (EST) From: Michael Richardson To: Lorenzo Colitti In-Reply-To: References: <11123.1361496693@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "homenet@ietf.org" , Fred Baker Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:17:37 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Lorenzo" =3D=3D Lorenzo Colitti writes: >> I.e. the "0123" is identical for the two prefixes? >>=20 Lorenzo> In the general case where the prefixes assigned by the Lorenzo> operators are of different lengths, it cannot be. Right? True. If the ISP with the longest prefix is alive first, then the routers=20 pick subnet-id parts that fit into that. If that ISP has provided enough subnets, then even when another ISP comes along, the "xx23" part might remain stable for a long time. I think this is a human friendly feature that none of our protocols should depend upon, but that nothing should forbid. Do you agree? =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUSd9tYqHRg3pndX9AQKv7gP/Rn4STy49dv0lyyhE5pQS/meJIi9cHnUM 3j8PNx82Vr6STAMbSQ0UvBmu0Ksz7fOfChXrpgMKSKVScZ+uGrzHpMf7UPf8VVDH ssUOvFEmiFj0B48iHB81plcV1BUF6sYERecY5De59rL7qDIYHOOGzgzb4Sc56oXM fr/JUxBKl38= =ZfMS -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Feb 22 06:19:41 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CB521F8E7B for ; Fri, 22 Feb 2013 06:19:41 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfidPEoqDOgP for ; Fri, 22 Feb 2013 06:19:40 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 7695921F8E71 for ; Fri, 22 Feb 2013 06:19:40 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 431832016D; Fri, 22 Feb 2013 09:26:33 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id BB73A6387F; Fri, 22 Feb 2013 09:18:31 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id AA8CC63765; Fri, 22 Feb 2013 09:18:31 -0500 (EST) From: Michael Richardson To: "Fred Baker (fred)" In-Reply-To: <8C48B86A895913448548E6D15DA7553B79E503@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B79E503@xmb-rcd-x09.cisco.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "homenet@ietf.org Group" Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:19:41 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "fred" =3D=3D fred > writes: fred> my draft that if the autoconfig prefix is withdrawn, I expect fred> prefixes dependent on it to be withdrawn, and if stored in fred> permanent storage, erased. The implication is that if the same fred> prefix is then readvertised, there's a good chance that all of fred> the subnet numbers will change. I know of at least one fred> scenario where that would be considered a desirable fred> characteristic. But I don't think that case is, at least at fred> this point, a general case or one I would specify beyond a fred> "MAY".=20 Assuming that the random "seed" is not erased, or that another prefix has been announced before the original withdrawn, then the seed might persist. (Remember that ULA prefix...) Can you elaborate the scenario where a subnet-id renumbering would be desireable, and would we want to actually signal this situation explicitely? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUSd+N4qHRg3pndX9AQJyMwQAu9PjKzNfzZHMQzWdI6ot4Rr3PpjlPxNA +ZV4ETYYNzPg0lIW7UtiqXEsAcv5O+iQmnAdq1lZnOeGUYjaO4EL29qWWpsAWZ8x n1LCxC2aGbEjdvCYxBIRm9V2f9iV7V87sid9fKdflJjrP9FUu7+9x5dRuBkHpMTv Pplim5unfUA= =qX4H -----END PGP SIGNATURE----- --=-=-=-- From mellon@fugue.com Fri Feb 22 06:48:38 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9202821F8658 for ; Fri, 22 Feb 2013 06:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPELabaEHSF2 for ; Fri, 22 Feb 2013 06:48:38 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0D19921F8441 for ; Fri, 22 Feb 2013 06:48:38 -0800 (PST) Received: from [10.255.24.180] (wsip-70-166-149-189.ri.ri.cox.net [70.166.149.189]) by toccata.fugue.com (Postfix) with ESMTPSA id 4CBE023805D9; Fri, 22 Feb 2013 09:48:07 -0500 (EST) References: <20130221044128.GD2799359@jupiter.n2.diac24.net> <5126CB1D.70705@mtcc.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5126CB1D.70705@mtcc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <85516831-01F4-41CA-93DF-2959DD65712F@fugue.com> X-Mailer: iPad Mail (10B141) From: Ted Lemon Date: Fri, 22 Feb 2013 09:48:05 -0500 To: Michael Thomas Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:48:38 -0000 On Feb 21, 2013, at 8:34 PM, Michael Thomas wrote: > Sigh all you like, but I share Dave's skepticism that ISP's renumbering my= prefix > willy-nilly and it just sort of works with naming -- including addresses s= quirrelled > away in places they ought not be -- is going to work any time soon. I don'= t like to > think that NAT is inevitable but frankly the people in this working group d= on't get > to vote on that. It's probably also worth mentioning that in general ISPs that do this on a r= egular basis are attacking their customer's network, and the resulting insta= bility is not the result of a failing on our part, but deliberate action on t= he part of the ISP. There are countries where ISPs are required by law to _offer_ a change of ad= dress every 24 hours for privacy purposes. At least in the cases I'm aware= of, ISPs don't _force_ this on their customers, but rather it's a configura= tion option paranoid customers can choose, which may default to on. This i= s an inconvenience to ISPs, because it causes address pool churn, and requir= es a lot of extra bits to be allocated to PE devices to accommodate all the d= eprecated addresses. Pretty much by definition, if you want to access your washing machine while a= way from home, you're throwing that particular sort of privacy right out the= window. It wasn't buying you much anyway--fuzzing the prefix by a few bit= s is very easy to reverse, and because of routing hierarchies, IPv6 prefixes= can't be assigned to the customer out of the ISP's entire address space--by= definition they will be restricted to localities. The other use case for frequent renumbering is an ISP who wants to prevent t= he customer from setting up servers. The washing machine is a server. Ei= ther the ISP succeeds, or fails, but in either case, they are acting directl= y against the customer's wishes. We can try to design a system that's rob= ust with respect to attacks like this, but in practice the best way to addre= ss this problem is to prevent it happening on a regular basis to people who w= ill care about it.= From mellon@fugue.com Fri Feb 22 06:50:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4F621F8F44 for ; Fri, 22 Feb 2013 06:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUoEdFtXEcgm for ; Fri, 22 Feb 2013 06:50:14 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 04CDB21F8F35 for ; Fri, 22 Feb 2013 06:50:14 -0800 (PST) Received: from [10.255.24.180] (wsip-70-166-149-189.ri.ri.cox.net [70.166.149.189]) by toccata.fugue.com (Postfix) with ESMTPSA id 9F42423805D9; Fri, 22 Feb 2013 09:49:43 -0500 (EST) References: <5126E021.6020103@mtcc.com> <20130222033242.GE2885509@jupiter.n2.diac24.net> <78F112CE-68D4-4FB3-905D-FEE5F722547D@fugue.com> <5126E9F7.4020906@mtcc.com> <8C669A18-F9A3-44CF-A9B7-CF80884C0698@fugue.com> <53F00E5CD8B2E34C81C0C89EB0B4FE731053BB82@wds-exc2.okna.nominet.org.uk> Mime-Version: 1.0 (1.0) In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE731053BB82@wds-exc2.okna.nominet.org.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B141) From: Ted Lemon Date: Fri, 22 Feb 2013 09:49:43 -0500 To: Ray Bellis Cc: "homenet@ietf.org Group" Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:50:14 -0000 On Feb 22, 2013, at 7:49 AM, Ray Bellis wrote: > I *really* don't like the idea of each individual Homenet having to create= some sort of randomised namespace for its internal DNS. I don't either, but that's not the only way to approach the problem.= From mellon@fugue.com Fri Feb 22 06:50:53 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089C421F86AB for ; Fri, 22 Feb 2013 06:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0tE7+IydDUC for ; Fri, 22 Feb 2013 06:50:52 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id CC7B721F8F67 for ; Fri, 22 Feb 2013 06:50:51 -0800 (PST) Received: from [10.255.24.180] (wsip-70-166-149-189.ri.ri.cox.net [70.166.149.189]) by toccata.fugue.com (Postfix) with ESMTPSA id D7BB723805D9; Fri, 22 Feb 2013 09:50:50 -0500 (EST) References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51276C00.7060808@thekelleys.org.uk> <20130222130748.GC3183407@jupiter.n2.diac24.net> <5127719E.7020300@thekelleys.org.uk> Mime-Version: 1.0 (1.0) In-Reply-To: <5127719E.7020300@thekelleys.org.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4D4C0DC5-705A-41EE-BCC4-A3BE30A170F9@fugue.com> X-Mailer: iPad Mail (10B141) From: Ted Lemon Date: Fri, 22 Feb 2013 09:50:50 -0500 To: Simon Kelley Cc: "homenet@ietf.org" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:50:53 -0000 On Feb 22, 2013, at 8:24 AM, Simon Kelley wrote: > It works as well for clients which do DHCPv4 and SLAAC. IPv6-only hosts > would have to do stateful DHCPv6, but the DHCPv4 and SLAAC model covers > an awful lot of currently-deployed clients. So dnsmasq is noticing that the IPv4 and IPv6 hosts are the same host using t= he MAC address or something, and then coordinating the DNS registration? From Carl.Wuyts@technicolor.com Fri Feb 22 06:55:15 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7D221F86AB for ; Fri, 22 Feb 2013 06:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nscCCd3By7Bh for ; Fri, 22 Feb 2013 06:55:14 -0800 (PST) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id 44D2F21F867D for ; Fri, 22 Feb 2013 06:54:25 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKUSeGnPStXdh4zmAMXulU6H/d2Lvd80xA@postini.com; Fri, 22 Feb 2013 06:55:12 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 22 Feb 2013 15:51:28 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.146]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Fri, 22 Feb 2013 15:51:43 +0100 From: Wuyts Carl To: Ted Lemon , Michael Thomas Date: Fri, 22 Feb 2013 15:51:42 +0100 Thread-Topic: [homenet] Running code in Orlando Thread-Index: Ac4RC7tl+oU4Msw5RbyNg4l7Lz9qMQAABnqQ Message-ID: <3135C2851EB6764BACEF35D8B495596806D80B2FBB@MOPESMBX01.eu.thmulti.com> References: <20130221044128.GD2799359@jupiter.n2.diac24.net> <5126CB1D.70705@mtcc.com> <85516831-01F4-41CA-93DF-2959DD65712F@fugue.com> In-Reply-To: <85516831-01F4-41CA-93DF-2959DD65712F@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 22 Feb 2013 07:00:05 -0800 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:55:15 -0000 Small add-on to the address-renew policy @ some ISPs Some ISPs do refresh the IP every XX hours for several reasons: * privacy * different contracts, i.e. you pay more for fixed IP over dynamic IP, i.e.= allows hosting on same IP The same will be applied for IPv6. Best regards Carl Wuyts Help preserve the color of our world - Think before you print. -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Ted Lemon Sent: vrijdag 22 februari 2013 15:48 To: Michael Thomas Cc: Michael Richardson; Mark Townsley; Dave Taht; Jari Arkko; Brzozowski, J= ohn; homenet@ietf.org Group; David Lamparter; Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando On Feb 21, 2013, at 8:34 PM, Michael Thomas wrote: > Sigh all you like, but I share Dave's skepticism that ISP's=20 > renumbering my prefix willy-nilly and it just sort of works with=20 > naming -- including addresses squirrelled away in places they ought=20 > not be -- is going to work any time soon. I don't like to think that=20 > NAT is inevitable but frankly the people in this working group don't get = to vote on that. It's probably also worth mentioning that in general ISPs that do this on a = regular basis are attacking their customer's network, and the resulting ins= tability is not the result of a failing on our part, but deliberate action = on the part of the ISP. There are countries where ISPs are required by law to _offer_ a change of a= ddress every 24 hours for privacy purposes. At least in the cases I'm awa= re of, ISPs don't _force_ this on their customers, but rather it's a config= uration option paranoid customers can choose, which may default to on. T= his is an inconvenience to ISPs, because it causes address pool churn, and = requires a lot of extra bits to be allocated to PE devices to accommodate a= ll the deprecated addresses. Pretty much by definition, if you want to access your washing machine while= away from home, you're throwing that particular sort of privacy right out = the window. It wasn't buying you much anyway--fuzzing the prefix by a few= bits is very easy to reverse, and because of routing hierarchies, IPv6 pre= fixes can't be assigned to the customer out of the ISP's entire address spa= ce--by definition they will be restricted to localities. The other use case for frequent renumbering is an ISP who wants to prevent = the customer from setting up servers. The washing machine is a server. = Either the ISP succeeds, or fails, but in either case, they are acting dire= ctly against the customer's wishes. We can try to design a system that's= robust with respect to attacks like this, but in practice the best way to = address this problem is to prevent it happening on a regular basis to peopl= e who will care about it. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From mike@mtcc.com Fri Feb 22 07:02:32 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD1D21F8DF2 for ; Fri, 22 Feb 2013 07:02:32 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0kq3AUJyrtU for ; Fri, 22 Feb 2013 07:02:31 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA4A21F8DE7 for ; Fri, 22 Feb 2013 07:02:31 -0800 (PST) Received: from piolinux.mtcc.com (63-171-70-46.dsl.volcano.net [63.171.70.46] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1MF1eMK016198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2013 07:01:41 -0800 Message-ID: <51278850.5080102@mtcc.com> Date: Fri, 22 Feb 2013 07:01:36 -0800 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Ted Lemon References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> In-Reply-To: <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1800; t=1361545302; x=1362409302; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20NPTv6-only=20home=20network s |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=0bg1x9R/8Tu7ZaV4bsDiufxKgumrEpQ8aIhC1hoc6Y0=; b=T2l/HWZJRfI06/Yfj/EbkAb/rGcIi9AuskmmIdWg2J57JCb41JFYNy/PR9 NsxbZnwttnDdir9WOxvOQiRUHKov6VzE3BNNAfzxO8rYA9e80KZoSMDCU1s/ +Ynv3rE3LhpkB/iDaz0/Jca36JFRQdguBgjWIyJ8Oh7XIc0PyNU5U=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:02:32 -0000 Ted Lemon wrote: > On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti wrote: >> My point was more that that NPTv6 doesn't make that any easier, more secure, or... anything, really. You still have to update the address somewhere; all that NPTv6 gives you is that now the washing machine doesn't know what its IPv6 address is. Right? > > I think the issue that Michael imagines NPTv6 will address is the transition period, when the washing machine has two IP addresses, and the DNS may not have the new address, or may have both addresses, and he's hoping the gateway will somehow bandage this up. However, the gateway's ability to bandage this up is more imagined than real, and we might as well just fix the underlying problem. Just to be perfectly clear, I'm not imagining NPTv6 working at all. (and how did this get turned into npt vs nat?) My fear is that the complexity of all of this will drive people and manufacturers to "simple" and brain dead solutions that do not meet the requirement that I be able to control my washing machine across the continent, for example. Renumbering is something that has gotten a lot of attention over the years in ietf, but its intersection with naming is still problematic as far as I can tell in the real world, and is likely to be even more problematic in with low-clue home networks. Right now, I don't think that sufficient energy is being given to just one obvious problem: how does real DNS interact with prefix delegation in the home (assuming that we don't want split horizon dns)? For that matter, let me be even more blunt: I don't think that real DNS is being given enough attention altogether in home settings, and until that happens we'll just inherit all of the awful hacks that are done with NATv4. Mike From brian.e.carpenter@gmail.com Fri Feb 22 07:15:12 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C839521F8E05 for ; Fri, 22 Feb 2013 07:15:12 -0800 (PST) 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.535, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erHWFCLpUU20 for ; Fri, 22 Feb 2013 07:15:12 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEC121F8602 for ; Fri, 22 Feb 2013 07:15:11 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so612215wge.10 for ; Fri, 22 Feb 2013 07:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aFZYg/H8iNG8ojKmruWwcP7/J2/swNIUIWbnStK54F8=; b=TQCrLbn7w5nFg6fUOSk/rnrObze6xU9VaMqr79HhvlzOJxeAYsbLlrDyDL0YTgnJI6 u6x2JOvBP9fjqyrJmjv9UYYoXUS3DlzgvJdZQk2/R1vtLU5gGz65ZyBD3/qFMBSchhyF 0QyIjBOGMrKSdKmSOloIAcUsaGUypFSMhnDYW5oyvQrEM48DWOTrUwpNNnkRxu1s5KQn xNAIkd449oWNBhfdi0gu6baIStS9lwQCbTlEyAG9BXEZDZpjHtQc58gacBFQXOzkh8xF 6WYwqOmRy8WnZLUVSVdkrtKEONXUsescC/o3M6t9S3HvfX4zlM1djpSw9A72gl48Sm1b GRGA== X-Received: by 10.180.80.35 with SMTP id o3mr50000420wix.9.1361546108822; Fri, 22 Feb 2013 07:15:08 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-222.as13285.net. [2.102.217.222]) by mx.google.com with ESMTPS id j4sm4497873wiz.10.2013.02.22.07.15.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 07:15:07 -0800 (PST) Message-ID: <51278B89.8000107@gmail.com> Date: Fri, 22 Feb 2013 15:15:21 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Bellis References: <53F00E5CD8B2E34C81C0C89EB0B4FE73104F65F1@wds-exc1.okna.nominet.org.uk> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE73104F65F1@wds-exc1.okna.nominet.org.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:15:12 -0000 I went through the draft, and noticed an instance of the word "hoemnet" in section 2.4. Otherwise I think this is now in good shape for publication. Regards Brian On 12/02/2013 15:00, Ray Bellis wrote: > This email marks the commencement of Working Group Last Call for draft-ietf-homenet-arch-07. > > The WGLC will end on Monday March 4th. > > Ray and Mark. > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From C.Donley@cablelabs.com Fri Feb 22 07:22:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE5621F8E45 for ; Fri, 22 Feb 2013 07:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgqBfBe89ISp for ; Fri, 22 Feb 2013 07:22:02 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3900021F8E3A for ; Fri, 22 Feb 2013 07:22:02 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r1MFLsW8021571; Fri, 22 Feb 2013 08:21:54 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Fri, 22 Feb 2013 08:21:54 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0328.009; Fri, 22 Feb 2013 08:21:54 -0700 From: Chris Donley To: Lorenzo Colitti , "Fred Baker (fred)" Thread-Topic: [homenet] Egress Routing Discussion: Baker model Thread-Index: AQHOEGjePDmfY0YTWU22pYhqqdemMZiFf0oAgACAkYA= Date: Fri, 22 Feb 2013 15:21:52 +0000 Message-ID: <8B09A8FA963FEF43835B9C215704654E17FD88B9@EXCHANGE.cablelabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_8B09A8FA963FEF43835B9C215704654E17FD88B9EXCHANGEcablela_" MIME-Version: 1.0 X-Approved: ondar Cc: "homenet@ietf.org Group" , "ospf-chairs@tools.ietf.org" , "isis-chairs@tools.ietf.org" , "Abhay Roy \(akr\)" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:22:05 -0000 --_000_8B09A8FA963FEF43835B9C215704654E17FD88B9EXCHANGEcablela_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Lorenzo Colitti > Date: Thursday, February 21, 2013 5:41 PM To: Fred Baker > Cc: "homenet@ietf.org Group" >, "Abhay Roy (akr)" >, "isis-chairs@tools.ietf.org" >, "ospf-chairs@to= ols.ietf.org" > Subject: Re: [homenet] Egress Routing Discussion: Baker model Extending the routing protocols will be a long and possibly hard road, and = we feel that the group should at least consider the possibility of an appro= ach with better time-to-market and lower barrier to implementation - especi= ally since the alternatives being proposed are hierarchical DHCPv6 PD and N= PT66. The risk is that we make the perfect the enemy of the good and we end= up with NPT66, [CD] There's another alternative we've added to eRouter (see draft-grundema= nn-homenet-hipnet) - hierarchical DHCPv6 without NPT66. For multihoming, y= ou can do source/dest routing at the CER(s), if necessary, not every router= . No routing protocol required, and no v6 NAT. --_000_8B09A8FA963FEF43835B9C215704654E17FD88B9EXCHANGEcablela_ Content-Type: text/html; charset="us-ascii" Content-ID: <305DBDF1FD0F9944BF7BB023CE3D21D1@cablelabs.com> Content-Transfer-Encoding: quoted-printable

From: Lorenzo Colitti <lorenzo@google.com>
Date: Thursday, February 21, 2013 5= :41 PM
To: Fred Baker <fred@cisco.com>
Cc: "homenet@ietf.org Group" <homenet@ietf.org>, "Abhay Roy (akr)" <akr@cisco.com>, "isis-chairs@tools.ietf.org" <isis-chairs@tools.ietf.o= rg>, "ospf-chairs= @tools.ietf.org" <ospf-chairs@tools.ietf.org>
Subject: Re: [homenet] Egress Routi= ng Discussion: Baker model

Extending the routing protocols will be a long and possibly hard road, and we feel t= hat the group should at least consider the possibility of an approach with = better time-to-market and lower barrier to implementation - especially sinc= e the alternatives being proposed are hierarchical DHCPv6 PD and NPT66. The risk is that we make the perfect= the enemy of the good and we end up with NPT66,

[CD]= There's another alternative we've added to eRouter (see draft-grundemann-h= omenet-hipnet) - hierarchical DHCPv6 without NPT66.  For multihoming, = you can do source/dest routing at the CER(s), if necessary, not every router.  No routing protocol required, and no= v6 NAT.  
--_000_8B09A8FA963FEF43835B9C215704654E17FD88B9EXCHANGEcablela_-- From Ray.Bellis@nominet.org.uk Fri Feb 22 07:22:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A752221F8E4E for ; Fri, 22 Feb 2013 07:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6co+3vOBzTa for ; Fri, 22 Feb 2013 07:22:52 -0800 (PST) Received: from mx3.nominet.org.uk (mail.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id C227C21F8E47 for ; Fri, 22 Feb 2013 07:22:51 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=S0bBbXfKxBI9HXoPVa7oGwFWfDWweLYKPcqBq8sUhLVfE9o/QLjCg2dJ r8B/xZ/Ys5BJquObwaIWBf52VXd4lFqO74ltmmiB/Bv5CxtQnPQt7JGNA WdEHj+TfHouNeTJ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1361546571; x=1393082571; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20Working=20Group=20Last=20Ca ll=20for=20draft-ietf-homenet-arch-07|Date:=20Fri,=2022 =20Feb=202013=2015:22:49=20+0000|Message-ID:=20<53F00E5CD 8B2E34C81C0C89EB0B4FE731053F75D@wds-exc2.okna.nominet.org .uk>|To:=20"homenet@ietf.org=20Group"=20|CC:=20Brian=20E=20Carpenter=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20quo ted-printable|Content-ID:=20<52EAC00E9CF6B54C9D04AC85A36D A025@okna.nominet.org.uk>|In-Reply-To:=20<51278B89.800010 7@gmail.com>|References:=20<53F00E5CD8B2E34C81C0C89EB0B4F E73104F65F1@wds-exc1.okna.nominet.org.uk>=0D=0A=20<51278B 89.8000107@gmail.com>; bh=5y6DuHEFoSivGhVD66+q35HDFxH0S3DW8Yf7k1vUi00=; b=BswiNqauXImp6IEt/L5rUpT06ZFvbxfuVMi9qwDXITBa8WAiakn85gvp IXUWeD58L5+h144C3rfWr6gOdOPtXJsYM2QzD/vcQANUuSIS8UmpZgyfK mjVtj/TfRVzjWVQ; X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208";a="46633353" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx3.nominet.org.uk with ESMTP; 22 Feb 2013 15:22:50 +0000 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%17]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 15:22:50 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07 Thread-Index: AQHOCTGp+xL3UhaWxkipUvpddH8FUJiGDHiAgAACFoA= Date: Fri, 22 Feb 2013 15:22:49 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE731053F75D@wds-exc2.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE73104F65F1@wds-exc1.okna.nominet.org.uk> <51278B89.8000107@gmail.com> In-Reply-To: <51278B89.8000107@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <52EAC00E9CF6B54C9D04AC85A36DA025@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:22:52 -0000 On 22 Feb 2013, at 15:15, Brian E Carpenter w= rote: > I went through the draft, and noticed an instance of the word "hoemnet" i= n section 2.4. >=20 > Otherwise I think this is now in good shape for publication. Brian - thanks for the review! Working Group participants: I know Tim has had some received some feedback directly, but so far on-list= I make it one "ready to go" and one "more work required". Please *do* review this version as thoroughly as possible before March 4th. thanks, Ray From mike@mtcc.com Fri Feb 22 07:25:19 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2603F21F8E47 for ; Fri, 22 Feb 2013 07:25:19 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1JuqYTODT33 for ; Fri, 22 Feb 2013 07:25:18 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 8868921F8E45 for ; Fri, 22 Feb 2013 07:25:18 -0800 (PST) Received: from piolinux.mtcc.com (63-171-70-46.dsl.volcano.net [63.171.70.46] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1MFOVLX023980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2013 07:24:32 -0800 Message-ID: <51278DAA.4000507@mtcc.com> Date: Fri, 22 Feb 2013 07:24:26 -0800 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: joel jaeggli References: <5126E021.6020103@mtcc.com> <51272600.4080605@bogus.com> In-Reply-To: <51272600.4080605@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=614; t=1361546673; x=1362410673; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20NPTv6-only=20home=20network s |Sender:=20 |To:=20joel=20jaeggli=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=0lMboSGWoVSVMShjAlhDz/hrN3RupiYDS9eU6nVPDoM=; b=BozNhHWJ2P3lFmoAX9Wgi7hPzU7cw/RAokCATw1Lx9C5pdcs8GA3zgyKTB 9rJ5vf490LmZFiAKqhe5o4W6efJZuNNhk6tdlLhUv/9knhO6vf4+tqAn6NCf zAzXkyrT0qfrE3rw2kCW5Wj2OFJcBrhj7BenNrmmJqw1KRXXRFeVA=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:25:19 -0000 joel jaeggli wrote: > On 2/21/13 7:04 PM, Michael Thomas wrote: > So, I think what we can observe from the number of readily discoverable > security cameras on the internet. was that the real-live requirement was > at least partially solved thanks to upnp and dynamic dns registration, > is not a geek-only-oddity, survives renumbering, and was for the most > part done quite badly. hopefully it can be done better in the future. I was under the impression that upnp is exactly what we should not be aspiring to, but that we'll get by default (like natv6) if nothing useful happens in ietf. Mike From tjc@ecs.soton.ac.uk Fri Feb 22 07:25:28 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4AB21F8E8B for ; Fri, 22 Feb 2013 07:25:28 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gomUbZwiRdAS for ; Fri, 22 Feb 2013 07:25:27 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 72B6D21F8E53 for ; Fri, 22 Feb 2013 07:25:27 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r1MFPNfV005778 for ; Fri, 22 Feb 2013 15:25:23 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r1MFPNfV005778 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1361546723; bh=crtvcBpHN6hSIvxjTj88CsC8eh4=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=ZcYCYK3zSkV5EZf32uLXsXXHTDV1RI8tmEfxS+oFrTK74og4EHLFxI60jeTAOivI5 f8EBGd7+cBwUL6nuwVBTGbxeL2NTcLcm3ogbDp+kUAX1beL2HsvqdewmF5G7l2LABV rrPcBeGK77YioxNpcp8oUgRdgKNinytT6UXggTxo= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p1LFPN04306189900I ret-id none; Fri, 22 Feb 2013 15:25:23 +0000 Received: from ip-163-003.eduroam.soton.ac.uk (ip-163-003.eduroam.soton.ac.uk [152.78.163.3]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r1MFPLOH002112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 22 Feb 2013 15:25:21 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <51278B89.8000107@gmail.com> Date: Fri, 22 Feb 2013 15:25:20 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE73104F65F1@wds-exc1.okna.nominet.org.uk> <51278B89.8000107@gmail.com> <6F38E3AB-267F-43AE-B23D-7A303133C416@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p1LFPN043061899000; tid=p1LFPN04306189900I; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r1MFPNfV005778 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:25:28 -0000 On 22 Feb 2013, at 15:15, Brian E Carpenter = wrote: > I went through the draft, and noticed an instance of the word = "hoemnet" in section 2.4. >=20 > Otherwise I think this is now in good shape for publication. Thanks Brian. The typos are there as I ran ispell on the .xml and forgot to re-run = xml2rfc before submitting. The .xml on the IETF server is OK :) I have two sets of comments to look through this weekend, from Michael = (to list) and a private response. =20 Further specific comments and suggestions for text would be welcome. = There's an amount of 'critique' in other threads on this list that isn't = easy to relate to specific items in the document, so targeted comments = at specific sections would help. Tim= From mike@mtcc.com Fri Feb 22 07:38:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F7C21F8ABC for ; Fri, 22 Feb 2013 07:38: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFgNRYv2KKk4 for ; Fri, 22 Feb 2013 07:38:44 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id D08CC21F87AA for ; Fri, 22 Feb 2013 07:38:44 -0800 (PST) Received: from piolinux.mtcc.com (63-171-70-46.dsl.volcano.net [63.171.70.46] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1MFbupZ028522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2013 07:37:57 -0800 Message-ID: <512790D0.8000006@mtcc.com> Date: Fri, 22 Feb 2013 07:37:52 -0800 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Ted Lemon References: <20130221044128.GD2799359@jupiter.n2.diac24.net> <5126CB1D.70705@mtcc.com> <85516831-01F4-41CA-93DF-2959DD65712F@fugue.com> In-Reply-To: <85516831-01F4-41CA-93DF-2959DD65712F@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2388; t=1361547480; x=1362411480; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Running=20code=20in=20Orlan do |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=MFD5Jv8Bdq5NNuYsAMRw11PciTUt1Wdpv2V/oty3faA=; b=q3oqi/nIM/VEBAIK2BtUkFNXEP00GmDKqzjx8PhNdDEhm+u352iEEy+sdc mWa/Brk/FhA3gsqbLFMDewpPYlbQHNWcmjtzNLXcb95My/aS9vtlEzlcSUye 5B9x1Zzvzx6c4PXgsagN3TlYX60kW8ZKRhA1raquU5R+bzxFK7Gr8=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:38:46 -0000 Ted Lemon wrote: > On Feb 21, 2013, at 8:34 PM, Michael Thomas wrote: >> Sigh all you like, but I share Dave's skepticism that ISP's renumbering my prefix >> willy-nilly and it just sort of works with naming -- including addresses squirrelled >> away in places they ought not be -- is going to work any time soon. I don't like to >> think that NAT is inevitable but frankly the people in this working group don't get >> to vote on that. > > It's probably also worth mentioning that in general ISPs that do this on a regular basis are attacking their customer's network, and the resulting instability is not the result of a failing on our part, but deliberate action on the part of the ISP. > > There are countries where ISPs are required by law to _offer_ a change of address every 24 hours for privacy purposes. At least in the cases I'm aware of, ISPs don't _force_ this on their customers, but rather it's a configuration option paranoid customers can choose, which may default to on. This is an inconvenience to ISPs, because it causes address pool churn, and requires a lot of extra bits to be allocated to PE devices to accommodate all the deprecated addresses. > > Pretty much by definition, if you want to access your washing machine while away from home, you're throwing that particular sort of privacy right out the window. It wasn't buying you much anyway--fuzzing the prefix by a few bits is very easy to reverse, and because of routing hierarchies, IPv6 prefixes can't be assigned to the customer out of the ISP's entire address space--by definition they will be restricted to localities. > > The other use case for frequent renumbering is an ISP who wants to prevent the customer from setting up servers. The washing machine is a server. Either the ISP succeeds, or fails, but in either case, they are acting directly against the customer's wishes. We can try to design a system that's robust with respect to attacks like this, but in practice the best way to address this problem is to prevent it happening on a regular basis to people who will care about it. Is there any way to convince the powers that be that v6 address privacy is a better/acceptable solution than prefix-based privacy? Is there really anything that needs to be done for v6 on that account other than just switching on the, oh say, laptop? Mike From mike@mtcc.com Fri Feb 22 07:46:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D0921F8D94 for ; Fri, 22 Feb 2013 07:46:20 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3tgxY+KAFUg for ; Fri, 22 Feb 2013 07:46:20 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id DC11D21F8A3D for ; Fri, 22 Feb 2013 07:46:19 -0800 (PST) Received: from piolinux.mtcc.com (63-171-70-46.dsl.volcano.net [63.171.70.46] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1MFjZCP031177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2013 07:45:36 -0800 Message-ID: <512791C3.20006@mtcc.com> Date: Fri, 22 Feb 2013 07:41:55 -0800 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: "Brzozowski, John" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1113; t=1361547937; x=1362411937; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Running=20code=20in=20Orlan do |Sender:=20 |To:=20=22Brzozowski,=20John=22=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=G5bZvjEfuolVO6fjr4SyXj15zaz4aqUd65YjgacYBng=; b=DB0MGheav8b/FMtQvbZCNypgD8xYCjse17RZXwnPFZ77Ht1COysHR7kKfH +QdeZj5jGEl8+vEynt9/TdUkx3+ooioOyHbUKQDjkQjaVfenWHKDySyXYKm4 zGfhNieUJSwHDB8c6wltXFO3TkvWW5Ok4xuIHmgqYSIcT+JTa4qh8=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:46:21 -0000 Brzozowski, John wrote: >>> general? >> Yes, along with naming, security, prefix delegation across multiple >> routers, and isp's >> giving and withdrawing prefixes due to renumbering. I'm dubious that this >> has happened >> in real life with networks with people whose day job is to worry about >> such things, and >> I'd be astonished to hear such a thing has been shown to work on a home >> network. > [jjmb] hmmm we have quite a few real customers that are using IPv6 enabled > on a daily basis mostly using technology that we specified ~8 years ago. > Does this count? Not really because my understanding is that these networks are giving a service that is pretty much the same as their v4 counterpart which is completely client centric. I seriously want globally accessible servers on my home network to be 1st class citizens and that implies naming and security/admission control. The future is now: a Raspberry Pi is $35. Tomorrow, we'll be getting gratuitous IP-enabled controllers on everything whether we want them or not just like when digital controls replaced analog. Mike From joelja@bogus.com Fri Feb 22 07:50:50 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934C721F8E2E for ; Fri, 22 Feb 2013 07:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJuQjvYr4bi9 for ; Fri, 22 Feb 2013 07:50:50 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1B04F21F8E04 for ; Fri, 22 Feb 2013 07:50:50 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1MFo4aE057133 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 22 Feb 2013 15:50:05 GMT (envelope-from joelja@bogus.com) Message-ID: <512793A6.1020804@bogus.com> Date: Fri, 22 Feb 2013 07:49:58 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Michael Thomas References: <5126E021.6020103@mtcc.com> <51272600.4080605@bogus.com> <51278DAA.4000507@mtcc.com> In-Reply-To: <51278DAA.4000507@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 22 Feb 2013 15:50:06 +0000 (UTC) Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:50:51 -0000 On 2/22/13 7:24 AM, Michael Thomas wrote: > joel jaeggli wrote: >> On 2/21/13 7:04 PM, Michael Thomas wrote: >> So, I think what we can observe from the number of readily >> discoverable security cameras on the internet. was that the real-live >> requirement was at least partially solved thanks to upnp and dynamic >> dns registration, is not a geek-only-oddity, survives renumbering, >> and was for the most part done quite badly. hopefully it can be done >> better in the future. > > I was under the impression that upnp is exactly what we should not be > aspiring to, > but that we'll get by default (like natv6) if nothing useful happens > in ietf. my point was not that upnp was worth aspiring too. it was that the existence proof for servers in the home is all over the place even in the the state of brokenness. > > Mike > From simon@thekelleys.org.uk Fri Feb 22 07:53:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9DC21F8E64 for ; Fri, 22 Feb 2013 07:53: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ogPREmMaITz for ; Fri, 22 Feb 2013 07:53:52 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id 4F22B21F8DF6 for ; Fri, 22 Feb 2013 07:53:52 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:60438 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U8uwT-0006yH-EG; Fri, 22 Feb 2013 15:53:45 +0000 Received: from guest-193-062-204-112.wtgc.org ([193.62.204.112]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1U8uwS-0000Pq-P2; Fri, 22 Feb 2013 15:53:44 +0000 Message-ID: <51279481.7080403@thekelleys.org.uk> Date: Fri, 22 Feb 2013 15:53:37 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ted Lemon References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51276C00.7060808@thekelleys.org.uk> <20130222130748.GC3183407@jupiter.n2.diac24.net> <5127719E.7020300@thekelleys.org.uk> <4D4C0DC5-705A-41EE-BCC4-A3BE30A170F9@fugue.com> In-Reply-To: <4D4C0DC5-705A-41EE-BCC4-A3BE30A170F9@fugue.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:53:52 -0000 On 22/02/13 14:50, Ted Lemon wrote: > On Feb 22, 2013, at 8:24 AM, Simon Kelley wrote: >> It works as well for clients which do DHCPv4 and SLAAC. IPv6-only hosts >> would have to do stateful DHCPv6, but the DHCPv4 and SLAAC model covers >> an awful lot of currently-deployed clients. > > So dnsmasq is noticing that the IPv4 and IPv6 hosts are the same host using the MAC address or something, and then coordinating the DNS registration? > > As the DHCPv4 state machine moves to "lease complete" it spits a (MAC address, hostname, broadcast domain) tuple over to the IPv6 side. The broadcast domain plus configuration yields a list of prefixes, and the MAC address gets turned into a SLAAC host-identifier. The two make a set of putative addresses. The state machine then sends an ICMP6 echo request to each putative address and if it responds then that address is added as an AAAA record with the hostname. There are some implementation details involving timeouts and retries and sending speculative router advertisements to ensure that a new-on-the-network host is ready to reply to the pings. The practice is that it always works, even a smartphone moving slowly into a dodgy Wifi network. If the client can get a DHPCv4 lease, the IPv6 SLAAC address gets a name too. Simon. From fred@cisco.com Fri Feb 22 08:54:15 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A3D21F8E68 for ; Fri, 22 Feb 2013 08:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.48 X-Spam-Level: X-Spam-Status: No, score=-110.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGYpcADKSCjc for ; Fri, 22 Feb 2013 08:54:13 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id F2A4421F8E45 for ; Fri, 22 Feb 2013 08:54:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3065; q=dns/txt; s=iport; t=1361552052; x=1362761652; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CckDFTNrZ6P5WK7RXqnrZ4nDxp8yhX4jmwDusda1O2Y=; b=JHAcOHUI8yC94sO8OBtgCK/rYWl2pCbjz19Fy1vSdHuNLeeO2OnFHLvg bSVZbrAAAjq745R+KDJYerPE/w+zo22sGLj1koXr9QipAJouR86OQMuq7 RSC7/q+DabbknowtndM/Rm6Wn3uy0ZxrUU42SS5QxoFxnyZWT16Rbo6PX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKOhJ1GtJXG//2dsb2JhbABEwSOBChZzgiABAQQ6PxACAQgiFBAyJQIEDgUIiAq/O41OgQ0CMQeCX2EDpx2DB4In X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208";a="179919531" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 22 Feb 2013 16:54:11 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1MGsB7S029392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 16:54:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 10:54:11 -0600 From: "Fred Baker (fred)" To: Michael Richardson Thread-Topic: [homenet] automatic prefix management (OSPF or ISIS version) Thread-Index: AQHOER08PySZi/9Ip02mqlUeLmH2jg== Date: Fri, 22 Feb 2013 16:54:10 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B79F270@xmb-rcd-x09.cisco.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> In-Reply-To: <23737.1361542581@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.89] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:54:15 -0000 On Feb 23, 2013, at 3:16 AM, Michael Richardson wrote: >=20 >>>>>> "Lorenzo" =3D=3D Lorenzo Colitti writes: >>> I.e. the "0123" is identical for the two prefixes? >>>=20 >=20 > Lorenzo> In the general case where the prefixes assigned by the > Lorenzo> operators are of different lengths, it cannot be. Right? >=20 > True. >=20 > If the ISP with the longest prefix is alive first, then the routers=20 > pick subnet-id parts that fit into that. If that ISP has provided > enough subnets, then even when another ISP comes along, the "xx23" > part might remain stable for a long time. >=20 > I think this is a human friendly feature that none of our protocols > should depend upon, but that nothing should forbid. Do you agree? >=20 > --=20 > Michael Richardson , Sandelman Software Works=20 I think we have violent agreement here. The text we're discussing is
Each router advertising a Reachability = TLV , including a pseudonode on a LAN, when it receives the Autoconfiguration TLV Advertisement, calculates and announces a mor= e specific prefix from the advertised autoconfiguration prefix in a Reachability TLV. This prefix is chosen at random, but may not coll= ide with any prefix currently advertised within the network and therefo= re in the LSP database. If you would like I can change This prefix is chosen at random, but may not collide with any prefix curren= tly advertised within the network and therefore in the LSP database. to read In the absence of other considerations, this prefix is chosen at random. It= MAY be derived from previous prefix allocation decisions, such as a prefix= stored in nonvolatile memory, the prefix used by a previous pseudonode on = the same LAN, or the subnet part of another prefix on the same interface. I= n any event, it MUST NOT collide with any prefix currently advertised withi= n the network and therefore in the LSP database. BTW, a side-note on the issue of non-volatile memory. The OSPF autoconfig d= raft says that an allocated prefix MUST be stored in non-volatile memory an= d as a result survive a reboot. Speaking for myself, I don't see the need f= or that; I'm not opposed to someone doing it, but they now have to think ab= out "what happens when" for various kinds of network changes. I think the p= rinciple might be one of "least surprise"; if a certain prefix is in use on= a LAN and the DIS changes (perhaps the old one fails), the new DIS should = use the same prefix as the old one, so that the hosts don't have to jump th= rough hoops. That said, I don't see the argument around a whole-building po= wer failure; unless there is a server being advertised in DNS, a randomly-s= elected new prefix will work just as well as the old one.= From mcr@sandelman.ca Fri Feb 22 09:10:10 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA1521F8B1C for ; Fri, 22 Feb 2013 09:10:10 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClPhY3nSNHBx for ; Fri, 22 Feb 2013 09:10:09 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2BA21F892D for ; Fri, 22 Feb 2013 09:09:56 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 884422016D; Fri, 22 Feb 2013 12:16:48 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8CC0F6387F; Fri, 22 Feb 2013 12:08:46 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 768146387D; Fri, 22 Feb 2013 12:08:46 -0500 (EST) From: Michael Richardson To: "Fred Baker (fred)" In-Reply-To: <8C48B86A895913448548E6D15DA7553B79F270@xmb-rcd-x09.cisco.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <8C48B86A895913448548E6D15DA7553B79F270@xmb-rcd-x09.cisco.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:10:10 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "fred" =3D=3D fred > writes: fred> If you would like I can change fred> This prefix is chosen at random, but may not collide with any fred> prefix currently advertised within the network and therefore fred> in the LSP database. fred> to read fred> In the absence of other considerations, this prefix is chosen fred> at random. It MAY be derived from previous prefix allocation fred> decisions, such as a prefix stored in nonvolatile memory, the fred> prefix used by a previous pseudonode on the same LAN, or the fred> subnet part of another prefix on the same interface. In any fred> event, it MUST NOT collide with any prefix currently fred> advertised within the network and therefore in the LSP fred> database. I like. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUSemHoqHRg3pndX9AQKQyAQAxNiQO/IEfzvHK+7UuxrlTL1e8z9szAb1 XiOiEQ0m/73IW9+LhOSfeJNaumSWLXUK8CgNFlJznwxQsDUXj5diy3mB9cafd9Wn 2qvnUwajeMnh2qGJ4d+lN5wMxxWDVnSSW9+stRFVn+fu7gPCPYgB6cXFCPCeO2/2 qC/bQ85M5dU= =Bakc -----END PGP SIGNATURE----- --=-=-=-- From fred@cisco.com Fri Feb 22 09:17:51 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4A721F8BE0 for ; Fri, 22 Feb 2013 09:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7mrlkDDJvk2 for ; Fri, 22 Feb 2013 09:17:50 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AAEEC21F8B6B for ; Fri, 22 Feb 2013 09:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1447; q=dns/txt; s=iport; t=1361553470; x=1362763070; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xyu5aTc6+EY1hVk/3vEAdZbMIqdiVoF2oFyeCwokL8I=; b=MNJ5KhmiCdWYIPF3CSM9qFIxZfccgdgMhsQ0XWnmZntTYcn49YYsLl5v Q30l3LmENlOJb3aLwFwSwer5SzPNSTeEVbvijzYM8dK52vv+UYuCyi0he 08DOtpCgmfz9z+ImKJDc4/BxaOJGLxlJYL4SNtjzjVeNOrYH/VsZqyfLX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIKnJ1GtJV2a/2dsb2JhbABEwSWBChZzgh8BAQEDATo/BQsCAQgiFBAyJQIEDgUIiAQGv0SOWwIxB4JfYQOnHYMHgic X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208";a="180120895" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 22 Feb 2013 17:17:50 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1MHHos2020612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 17:17:50 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 11:17:50 -0600 From: "Fred Baker (fred)" To: Michael Richardson Thread-Topic: [homenet] automatic prefix management (OSPF or ISIS version) Thread-Index: AQHOESCKPySZi/9Ip02mqlUeLmH2jg== Date: Fri, 22 Feb 2013 17:17:49 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B79F386@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B79E503@xmb-rcd-x09.cisco.com> <24143.1361542711@sandelman.ca> In-Reply-To: <24143.1361542711@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.89] Content-Type: text/plain; charset="us-ascii" Content-ID: <8F2DF126413F8E408BE54A3DBCDFD0E3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:17:51 -0000 On Feb 23, 2013, at 3:18 AM, Michael Richardson wrote: > Can you elaborate the scenario where a subnet-id renumbering would be des= ireable, and would we want to actually signal this situation explicitly? There is a BAA (a request for a research proposal) from the US Air Force fo= r a technology or methodology that would enable a network to "morph under a= ttack." A presumably-related question came to me a couple of years ago from= a researcher at Johns Hopkins APL; she wondered whether it would be possib= le for a network to blunt a DDOS attack without betraying the information t= hat the attack had been detected. One way that *could* work would be to have the network periodically renumbe= r. Imagine the network as a whole, or individual LANs from time to time, ad= ding a prefix, making the old one "not preferred", and then removing the ol= d one a few minutes later. The network endures the attack for a little whil= e and then - not because it has detected an attack, but because it would do= so anyway - side-steps it in routing. I'm imagining the operators in the room giggling to themselves at this poin= t, or tearing their hair before running screaming from the "room". One woul= d not want to have to debug anything in such a network. But that's what I'm referring to. I can imagine a network that, by policy, = actively wants the algorithm to choose a new number.= From mark@townsley.net Fri Feb 22 09:24:37 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F4421F8CB0 for ; Fri, 22 Feb 2013 09:24:37 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSFFLmCyG3qJ for ; Fri, 22 Feb 2013 09:24:36 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id C9C8721F8C6C for ; Fri, 22 Feb 2013 09:24:34 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hm6so1032993wib.8 for ; Fri, 22 Feb 2013 09:24:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=iTyFGvujgZp0FLcYHtFj7pJbx9W7Fo9cQdbMSaAkXIc=; b=iZq3PBKWjc8heGOKGiPoP8daZCt/aKgAh2KUkYxU4Z0RVfZD+pU3DdSfXQJIyxaTez 8baGD8m/1x6x/b/nxtXmYspNWi4LSKPRg4nuWidqZ/fL9vZc2+byOx9M3u099AZH+6id wNxr3aRLrd8Pzu7oDqt010e5fHz3DQ289OeROOqptzMKE7aQxLV/e4tKsENsM52yVbVL fm3BJE8omvGrVEybpwiWkHOtqNI7X400WkLsXVZkx5MqtLSgZV9GSZuXRtNFeltxZora 35TF8Qd9CWdpFUGt5lH0cErPLgjzd8gKAfzSXEF5VqDXhMwFKI1bHMn94MCfulz+dAP4 iUhg== X-Received: by 10.180.14.233 with SMTP id s9mr256103wic.25.1361553873904; Fri, 22 Feb 2013 09:24:33 -0800 (PST) Received: from ams-townsley-8913.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id o8sm5129300wix.7.2013.02.22.09.24.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 09:24:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: Date: Fri, 22 Feb 2013 18:24:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Brzozowski, John" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlN5Ahm+QDEG/CIkrPQTf/HRSuDsYbc11nM26bqNHqHKVa1LVl7XVabFG13YMcSQn+/xZy7 Cc: Michael Richardson , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:24:37 -0000 =20 On Feb 21, 2013, at 5:57 PM, Brzozowski, John wrote: > Since BnB is one night can we make provisions for the home net lab = area to > be open all week? Mark? Ray? Let's give it a shot! But... the chairs can only make the request. Allocating IETF space is = something only the ADs are authorized to do. In Atlanta, I asked for = space and was turned down (citing too short notice, specs not mature = enough, etc.). IPSO graciously gave us some squatting room, but we were = not able to get what we needed from the IETF NOC in that particular = location. So, while good work was done, it came with support headaches = (e.g., ISP uplinks were simulated via tunnels sourced from a router than = joined the IETF network like any other wireless host). > Seems like it would be worth it. I am thinking all week would be = ideal. > ;) I think that's a necessity. The request I sent in January to the list = included: "Note that this isn't for 'showcasing', but for working... so = be expected to configure, reconfigure, and change code on the fly = accordingly." I think that is very important, and in order for that to = happen, we need more than a couple of hours here or there. What I am hearing is that we currently have requests to provide = workspace for: 1. draft-grundemann-homenet-hipnet-00=20 2. perhaps CeroWRT? 3. perhaps draft-arkko-homenet-prefix-assignment and = draft-ietf-ospf-ospfv3-autoconfig again?=20 Last time, we were asked from the ADs things like: - How many implementations existed and how many would be present on site = to test.=20 - What drafts or RFCs would be tested - How much space, and for how long - Power and network requirements etc... John B, Dave T, are the two of you the right folks for us to work = offline with in order to try and put together the right ask? Thanks, - Mark >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Cable > m) 484-962-0060 > e) john_brzozowski@cable.comcast.com > o) 609-377-6594 > w) www.comcast6.net > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Dave Taht > Date: Thursday, February 21, 2013 9:35 AM > To: John Jason Brzozowski > Cc: David Lamparter , Michael Richardson > , "homenet@ietf.org Group" , = Mark > Townsley , Jari Arkko , = Lorenzo > Colitti > Subject: Re: [homenet] Running code in Orlando >=20 >>=20 >>=20 >>=20 >> I am primarily focused on demonstrating solutions to bufferbloat in = my >> portion of bit's and bytes. >>=20 >> But I note that the present CeroWrt build appears to have working = dhcp-pd >> (I've successfully got /56 /60, /61/ /62 subnets from it), and = assigning >> that to the 6+ internal interfaces, support for every other form of = ipv6 >> tunneling, the latest dnsmasq which has >> some good ways of bonding dns names to ipv6 AAAAs, support for = routing >> ipv4 and ipv6 subnetworks over the quagga babel protocol (the two = routers >> I'm demoing are meshed together at 5ghz) >>=20 >> We had to fix a few nasty instruction traps in the ipv6 stack last = month, >> but after doing that, I'm pretty pleased with the over-all = performance >> and reliability - it survived the "thc" ipv6 tests handily, for = example. >> Could use some more exaustive real-world >> testing, so, get it (for the wndr3700v2 and 3800 series) >>=20 >> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.5-2/ >>=20 >> We also have specialized builds for the ubiquity nanostation m5 and >> picostation m2hp products deployed in the campground testbed. >>=20 >> We still haven't done anything with distributing prefixes inside the = home >> beside ahcp, and I still find the dynamicism required by renting ipv6 >> addresses to so impact in so many aspects of the "sane usage of stuff >> like printers", and naming, and the security >> model as to *demand* ipv6 nat in the home... but I did not get around = to >> implementing npt66 in this release!! >>=20 >>=20 >> (so those that would flame me for this opinion can hold off (pretty >> please!?) until perhaps I can go into the implementation details of = all >> the many things that break today... with those that care. ) >>=20 >> In terms of interop, besides dhcp-pd and bufferbloat fixes, I'd = rather >> like to see if these release can be made to work with ospfv6 on other >> devices. What else will be shown? The original homenet code was far = too >> large to be usable on such a small device, but >> perhaps at least the ospf layer could be tried. >>=20 >> And all that said, I'm rather totally buried with tests for, = processing a >> ton of data from the field, and testing nfq_codel/bufferbloat. I just >> finished giving talks on that at MIT and Stanford on that stuff >>=20 >> What's wrong with wifi? >>=20 >> http://www.youtube.com/watch?v=3DWksh2DPHCDI&feature=3Dyoutu.be >>=20 >> Intro to codel and fq_codel: >>=20 >> http://netseminar.stanford.edu/ >>=20 >>=20 >>=20 >> On Thu, Feb 21, 2013 at 8:14 AM, Brzozowski, John >> wrote: >>=20 >> Statically assigning prefixes may enable testing but is not how homes = will >> be provisioned in reality. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> John Jason Brzozowski >> Comcast Cable >> m) 484-962-0060 >> e) john_brzozowski@cable.comcast.com >> o) 609-377-6594 >> w) www.comcast6.net >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >>=20 >> From: David Lamparter >> Date: Wednesday, February 20, 2013 9:41 PM >> To: John Jason Brzozowski >> Cc: David Lamparter , Lorenzo Colitti >>=20 >> , Michael Richardson > >, >> "homenet@ietf.org Group" , Jari Arkko >> , Mark Townsley >> Subject: Re: [homenet] Running code in Orlando >>=20 >>=20 >>> On Thu, Feb 21, 2013 at 04:17:06AM +0000, Brzozowski, John wrote: >>>> David Lamparter wrote: >>>>> On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote: >>>>>> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson >>>>>> >wrote: >>>>>>=20 >>>>>>> Would/could another foot of such a network be on the IETF = network? >>>>>>>=20 >>>>>>=20 >>>>>> If the IETF network didn't respond to DHCPv6 PD requests, it >>>> wouldn't be >>>>>> much use. >>>>>=20 >>>>> Even without DHCPv6 PD on the remainder of the IETF network, it = might >>>> be >>>>> possible to get a /52../56 and run a DHCPv6 PD ourselves, = emulating >>>> part >>>>> of the provider network. >>>>=20 >>>> Why emulate it? Is the intention here to test the the code on an >>>> enterprise or corporate network? >>>=20 >>> The scope of the plugfest is the interior and border of the homenet. = To >>> get the border right, we need the service provider side of that = border >>> in some form. If the IETF network runs DHCPv6-PD, that is an usable >>> approximation. >>>=20 >>> My suggestion was for the case that the IETF network won't be = running >>> DHCPv6-PD. In that case, the easiest way to make the IETF network >>> usable as one uplink for the homenet plugfest is to ask for a /52 to = be >>> made available for the plugfest in some static way and then provide >>> DHCPv6-PD from that, running on some random PC box/laptop somewhere. >>>=20 >>> Actually - controlling the DHCPv6-PD might be advantageous in order = to >>> allow tinkering with it to see how the testbed reacts. >>>=20 >>>=20 >>> -David >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> --=20 >> Dave T=E4ht >>=20 >> Fixing bufferbloat with cerowrt: >> http://www.teklibre.com/cerowrt/subscribe.html >> >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mark@townsley.net Fri Feb 22 09:24:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E148021F8D0B for ; Fri, 22 Feb 2013 09:24:45 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuvpWnrT5w70 for ; Fri, 22 Feb 2013 09:24:44 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE8621F8CFC for ; Fri, 22 Feb 2013 09:24:44 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so1221623wib.3 for ; Fri, 22 Feb 2013 09:24:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=8p6hQrhxdBNoV0s6ybISaiAuhnWYToRiTLA2Fd4Tm/I=; b=JYNU7cHFADzb2Eb70B/+sRablS64wydC+bC/vtrJAZP+aGXNL61mDeu6itA+Lw4n1m rMXOsutcussLqGVEvauYaU91Co1wUxLxlVh/8GctXoZd23jdP5/Csi9gDoblIvG7rvlb 23NEcfMwWNkys58Cd/QbCoj1Ydcha1eimjjNitb5OHIP7lyHexftDxuShW3M+DdXxjd+ ulDTKx443QBOBE7DqXqSK4Z38/Rt9eh1HNQERfX3DKGzEmaV51nCU0NP5WV7mAfEFdUc Io4DR+I/yVRc+5QFW/q9QiIEyVbNIP/PDu39Z+0Hio2EAKjHJ/19i0nwTuTFDwG31ksz CLNQ== X-Received: by 10.194.108.229 with SMTP id hn5mr5141918wjb.8.1361553883440; Fri, 22 Feb 2013 09:24:43 -0800 (PST) Received: from ams-townsley-8913.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id o8sm5129300wix.7.2013.02.22.09.24.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 09:24:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F6D5EF0@xmb-rcd-x14.cisco.com> Date: Fri, 22 Feb 2013 18:24:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F6D5EF0@xmb-rcd-x14.cisco.com> To: Michael Behringer (mbehring) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnwa1eQ6pOHQY8Y5btioapqmwdhzfc0PGIAkgnHT8WK7VrF5LT4cytWYOk+4T665xFKCO7l Cc: "homenet@ietf.org" , "draft-behringer-homenet-trust-bootstrap@tools.ietf.org" Subject: Re: [homenet] Next steps for draft-behringer-homenet-trust-bootstrap? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:24:46 -0000 On Feb 13, 2013, at 3:55 PM, Michael Behringer (mbehring) wrote: > Homenet WG,=20 >=20 > In Atlanta we presented draft-behringer-homenet-trust-bootstrap-00, = which explains (high level) how trust could be bootstrapped in a homenet = environment.=20 >=20 > The feedback we got during the meeting was mostly positive; we would = like to understand the next steps for this draft? We believe this is a = useful approach, and would like to have the document accepted as a WG = doc at some point.=20 >=20 > What is the next step?=20 Ray and I are open to more WG discussion on this given the positive = reception at the last meeting, but I'd rather see more discussion on the = list beforehand. Where do *you* see this model fitting in? - Mark > Michael > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From fred@cisco.com Fri Feb 22 09:41:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAE421F8E4B; Fri, 22 Feb 2013 09:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq18V+UgrOpG; Fri, 22 Feb 2013 09:41:44 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 60FF821F8E3A; Fri, 22 Feb 2013 09:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3318; q=dns/txt; s=iport; t=1361554904; x=1362764504; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QL6KVtFNkCc4WY3XW2BJZJglKP/cmZoNz3bV5182DZA=; b=Y30g1qO0KYxWiWx1ieQ0tdtcd48YV6XThtXIJSxtkPbI8IHziHgV+/Tr 2BzuPbBOYtCDSf+W1XrtfW/CyKQuhONgGfRZRZSnT7x4O6J+C5DfG+zsi LHKeaIXMFpbR3qBdimiMPvlYqd51Nxxd3wTQvAzErr9Xj0txyvaTc+zs3 E=; X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208";a="180156301" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 22 Feb 2013 17:41:44 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1MHfis7013029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 17:41:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 11:41:43 -0600 From: "Fred Baker (fred)" To: David Lamparter Thread-Topic: [homenet] Egress Routing Discussion: Baker model Thread-Index: AQHOESPgQtloSZFSukSmTv1pgutDzQ== Date: Fri, 22 Feb 2013 17:41:43 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B79F4E1@xmb-rcd-x09.cisco.com> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> <20130222114822.GA3183407@jupiter.n2.diac24.net> In-Reply-To: <20130222114822.GA3183407@jupiter.n2.diac24.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.89] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ole Troan , "isis-chairs@tools.ietf.org" , "ospf@ietf.org" , Ray Hunter , "homenet@ietf.org Group" , "Abhay Roy \(akr\)" , Lorenzo Colitti Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 17:41:45 -0000 inline=20 On Feb 23, 2013, at 12:48 AM, David Lamparter wrote: > For both "simple" and "full-blown" OSPFv3 the following loop/interop > mechnisms come to my mind: >=20 > 1. refusing adjacencies between SADR and non-SADR routers. > Easily implemented with a Hello bit, this is the crowbar solution. > Quite sufficient for homenet I guess, but probably less acceptable > for anything else. >=20 > 2. flagging SADR support in router LSAs/LSPs. > Provides enough information to avoid loops. Three things can be done > with this information: >=20 > 2a. install null/reject routes for paths that cross non-SADR routers. > Provides adequate failure semantics, instead of looping packets > around we get an ICMP unreachable. Easy to implement. > Downside: if there really is a non-SADR router, "not working" is > now a state that is part of the result set of the dynamic route > calculations. Users (and admins) probably do not expect this. >=20 > 2b. calculate SPF around non-SADR routers > Gets us a working network, but at a cost: there may now be 2 > different paths to reach some faraway router, one for SADR-routed > packets and a different one for non-SADR packets. Depending on how > the router performs its SPF calculations, this can be hard to > implement correctly - it's essentially a very narrowly and exactly > specified case of multitopology routing. >=20 > 2c. on encountering non-SADR routers, figure whether they'll do the > right thing with the packet. > ... complicated and of questionable use IMHO. Just listing this > for completeness. >=20 > 2a and 2b can be mixed with each other; packets will get passed along by > 2a-type routers until they get discarded at a 2b-type router. >=20 > My personal opinion at this point is that 2a and 2b should both be > specified, with a requirement to indicate support level in the router > documentation. We're unlikely to encounter normal OSPFv3 speakers in a > plain "production/final" homenet, so they could take the easy way. If > this gets implemented on routers for enterprise use, I'd expect 2b > behaviour. So you want the non-SADR routers to implement a null route, and the SADR ro= uters to route around the non-SADR routers. I'm scratching my head on how the un-updated routers would know to install = a null route if they don't understand the information.=20 I do think it would be straightforward to add a flag to the Hello indicatin= g that they understand such updates, and refusing to neighbor with a router= that doesn't. We have done that for other features. That does mean that ad= ding a router to an area that understands the updates forces an update to a= ll of the routers in an area, which could be a pain when upgrading.=20 Setting a flag in the Router LSA indicating willingness to handle these rou= tes is possible, but takes us in the direction of topological routing. My p= roblem with approaching it as a topology is the implied management overhead= ; we need to know whether to include any given router or link in a given to= pology, and where we might have advertised topology-specific metrics in RFC= 4915, we now want to infer that from a capability flag. ick.=20 From joelja@bogus.com Fri Feb 22 10:03:27 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92BA21F84BF for ; Fri, 22 Feb 2013 10:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+EA978+SdRt for ; Fri, 22 Feb 2013 10:03:27 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 70BF221F84E2 for ; Fri, 22 Feb 2013 10:03:27 -0800 (PST) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1MI2f1j058983 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 22 Feb 2013 18:02:41 GMT (envelope-from joelja@bogus.com) Message-ID: <5127B2BB.90604@bogus.com> Date: Fri, 22 Feb 2013 10:02:35 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Lorenzo Colitti , Dave Taht References: <20130221044128.GD2799359@jupiter.n2.diac24.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 22 Feb 2013 18:02:42 +0000 (UTC) Cc: Michael Richardson , Mark Townsley , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 18:03:28 -0000 On 2/21/13 5:06 PM, Lorenzo Colitti wrote: > On Fri, Feb 22, 2013 at 1:35 AM, Dave Taht > wrote: > > I still find the dynamicism required by renting ipv6 addresses to > so impact in so many aspects of the "sane usage of stuff like > printers", and naming, and the security model as to *demand* ipv6 > nat in the home... > Consumers don't statically assign ip addresses today I don't imagine they will do so the future. stability is provided by upper layer mechanisms be those dynamic dns updates, mdns,netbios upnp dlna and so on. From my vantage point renumbering in the case where very little is static is a lot like a drawn out mobility event. My laptop and my phone can locate each other whether they're on my office wifi network or my home wifi network. when I moved my printer from palo alto to moutain view (and between service providers) I didn't have to reconfigure it to find it, I just plugged it in. From mellon@fugue.com Fri Feb 22 11:44:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D76721F8956 for ; Fri, 22 Feb 2013 11:44:14 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJJ4-Mwuevrd for ; Fri, 22 Feb 2013 11:44:13 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B038121F8936 for ; Fri, 22 Feb 2013 11:44:13 -0800 (PST) Received: from [IPv6:2001:470:1f07:690:b967:c931:483c:bc24] (unknown [IPv6:2001:470:1f07:690:b967:c931:483c:bc24]) by toccata.fugue.com (Postfix) with ESMTPSA id D8C2A23805D9; Fri, 22 Feb 2013 14:44:10 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <51278850.5080102@mtcc.com> Date: Fri, 22 Feb 2013 14:44:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1499) Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:44:14 -0000 On Feb 22, 2013, at 10:01 AM, Michael Thomas wrote: > Right now, I don't think that sufficient energy is being given to just = one obvious problem: how does real DNS interact with > prefix delegation in the home (assuming that we don't want split = horizon dns)? For that matter, let me be even more blunt: > I don't think that real DNS is being given enough attention altogether = in home settings, and until that happens we'll > just inherit all of the awful hacks that are done with NATv4. Agreed. I'm delighted to hear that Simon has a hack in dnamasq that = addresses this problem in a dual-stack environment, but I want to have a = serious conversation somewhere about how to address the problem on the = v6-only homenet. Who's interested in sketching a DNS-based solution to the problem and = has time to work on it? From mellon@fugue.com Fri Feb 22 11:47:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1220821F8936 for ; Fri, 22 Feb 2013 11:47:57 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGmmRB9iuaEK for ; Fri, 22 Feb 2013 11:47:56 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0AB21F874A for ; Fri, 22 Feb 2013 11:47:56 -0800 (PST) Received: from [IPv6:2001:470:1f07:690:b967:c931:483c:bc24] (unknown [IPv6:2001:470:1f07:690:b967:c931:483c:bc24]) by toccata.fugue.com (Postfix) with ESMTPSA id 4F303238033F; Fri, 22 Feb 2013 14:47:25 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <512790D0.8000006@mtcc.com> Date: Fri, 22 Feb 2013 14:47:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <17269F15-7C52-40E5-B238-C4C52C76D599@fugue.com> References: <20130221044128.GD2799359@jupiter.n2.diac24.net> <5126CB1D.70705@mtcc.com> <85516831-01F4-41CA-93DF-2959DD65712F@fugue.com> <512790D0.8000006@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1499) Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:47:57 -0000 On Feb 22, 2013, at 10:37 AM, Michael Thomas wrote: > Is there any way to convince the powers that be that v6 address = privacy is a better/acceptable solution than > prefix-based privacy? Is there really anything that needs to be done = for v6 on that account other than just > switching on the, oh say, laptop? I don't think address-based privacy offers any privacy at all, since the = tracker can just track the prefix. The problem is that this is also = true of the customer prefix. I think the idea that you can get privacy = by changing the IP address or prefix is hopelessly naive. If you want = privacy, you probably need something like TOR, only commercial, but even = then what you get is privacy from everybody but your TOR provider. Ironically, the simplest version of this commercial TOR for IPv6 is an = NPTv6 router somewhere near the backbone. :} From mellon@fugue.com Fri Feb 22 11:49:30 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A47921F8956 for ; Fri, 22 Feb 2013 11:49:30 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCpUKDCxHTce for ; Fri, 22 Feb 2013 11:49:30 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 031C021F8936 for ; Fri, 22 Feb 2013 11:49:30 -0800 (PST) Received: from [IPv6:2001:470:1f07:690:b967:c931:483c:bc24] (unknown [IPv6:2001:470:1f07:690:b967:c931:483c:bc24]) by toccata.fugue.com (Postfix) with ESMTPSA id 4017423805D9; Fri, 22 Feb 2013 14:48:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <51279481.7080403@thekelleys.org.uk> Date: Fri, 22 Feb 2013 14:48:58 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51276C00.7060808@thekelleys.org.uk> <20130222130748.GC3183407@jupiter.n2.diac24.net> <5127719E.7020300@thekelleys.org.uk> <4D4C0DC5-705A-41EE-BCC4-A3BE30A170F9@fugue.com> <51279481.7080403@thekelleys.org.uk> To: Simon Kelley X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:49:30 -0000 On Feb 22, 2013, at 10:53 AM, Simon Kelley wrote: > The practice is that it always works, even a smartphone moving slowly > into a dodgy Wifi network. If the client can get a DHPCv4 lease, the > IPv6 SLAAC address gets a name too. That is _very_ cool. Nice work! From simon@thekelleys.org.uk Fri Feb 22 12:08:30 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A3721F86B7 for ; Fri, 22 Feb 2013 12:08:30 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBO+UKALMMyX for ; Fri, 22 Feb 2013 12:08:30 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id CBD6C21F8658 for ; Fri, 22 Feb 2013 12:08:22 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:60874 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U8yus-0008S3-0X; Fri, 22 Feb 2013 20:08:22 +0000 Received: from archie.thekelleys.org.uk ([192.168.1.167]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1U8yur-0008Hu-6O; Fri, 22 Feb 2013 20:08:21 +0000 Message-ID: <5127D03A.6040904@thekelleys.org.uk> Date: Fri, 22 Feb 2013 20:08:26 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ted Lemon References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51276C00.7060808@thekelleys.org.uk> <20130222130748.GC3183407@jupiter.n2.diac24.net> <5127719E.7020300@thekelleys.org.uk> <4D4C0DC5-705A-41EE-BCC4-A3BE30A170F9@fugue.com> <51279481.7080403@thekelleys.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:08:30 -0000 On 22/02/13 19:48, Ted Lemon wrote: > On Feb 22, 2013, at 10:53 AM, Simon Kelley wrote: >> The practice is that it always works, even a smartphone moving slowly >> into a dodgy Wifi network. If the client can get a DHPCv4 lease, the >> IPv6 SLAAC address gets a name too. > > That is _very_ cool. Nice work! > > I make no claims for the invention, only the implementation. I'm aware of it being independently invented at least twice, involving at least three different people. Simon. From jhw@apple.com Fri Feb 22 13:11:42 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE9621F8EBB for ; Fri, 22 Feb 2013 13:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.973 X-Spam-Level: X-Spam-Status: No, score=-100.973 tagged_above=-999 required=5 tests=[AWL=9.026, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xhd2jNo3Y-kp for ; Fri, 22 Feb 2013 13:11:41 -0800 (PST) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8F32E21F8EB5 for ; Fri, 22 Feb 2013 13:11:41 -0800 (PST) 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 mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MIN008ZV44QFPG1@mail-out.apple.com> for homenet@ietf.org; Fri, 22 Feb 2013 13:11:41 -0800 (PST) X-AuditID: 11807137-b7f156d000005a91-15-5127df0d6f8a Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id C8.75.23185.D0FD7215; Fri, 22 Feb 2013 13:11:41 -0800 (PST) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MIN00BOU47HL690@aniseed.apple.com> for homenet@ietf.org; Fri, 22 Feb 2013 13:11:41 -0800 (PST) From: james woodyatt In-reply-to: <23737.1361542581@sandelman.ca> Date: Fri, 22 Feb 2013 13:11:40 -0800 Message-id: <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> To: "homenet@ietf.org" X-Mailer: Apple Mail (2.1682) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUi2FAsrst7Xz3QoPuihMX7RYdYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8bd5AVvBHs6Kxg8HGRsYD7N3MXJySAiYSHT0n2eFsMUkLtxb z9bFyMUhJDCFSeLg3UksEM4sJokv664wg1QxC2hJrN95nAnE5hXQk5i5cglYt7CAp8Th5rVs IDabgIrEt8t3wWo4BXQkpm2bDhZnEVCVWNvxmBFijrbEk3cXWCHm2EisWz0VatkURonrxyAS IgKaEpdmH2WCOE9W4sOVNvYJjPyzkNwxC8kds5DMXcDIvIpRsCg1J7HS0EwvsaAgJ1UvOT93 EyM4zArNdzBu/yt3iFGAg1GJh5dxmnqgEGtiWXFl7iFGCQ5mJRHeiUlAId6UxMqq1KL8+KLS nNTiQ4zSHCxK4rx7zqgFCgmkJ5akZqemFqQWwWSZODilGhjta9at/6WSFxY587WSHnPQlnY9 1TOB7J9ffdCvXVnSrOJzjKfv56IlV3p+/zAO26Ba8Lx35cffyYccbi09sKlx8jE7cUePB7IS UgfCVQ+xGdcsyIu2CDoy1VfzEjcr92Z+7meT1jP0ajSUMkgtV2u/l9QoWqSnxbP2e6DApr8K 4osfOqW6rVViKc5INNRiLipOBABlx753LwIAAA== Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:11:42 -0000 On Feb 22, 2013, at 06:16 , Michael Richardson wrote: > > If the ISP with the longest prefix is alive first, then the routers > pick subnet-id parts that fit into that. If that ISP has provided > enough subnets, then even when another ISP comes along, the "xx23" > part might remain stable for a long time. This problem is precisely why I campaigned bitterly and vigorously against the adoption and V6OPS and later the publication of RFC 6177. When there was still a consensus that subscribers should always get a /48 prefix, it was reasonable to expect that a randomly chosen 16-bit subnet identifier would be unlikely to collide with another subnet in most automatically numbered routing domains. We were also in a position to expect that when a subscriber adds a new prefix from the same or a different provider, that all the subnet identifiers in use on one prefix could be mapped 1:1 into the new prefix. Now we have RFC 6177, which explodes all of that, for basically no sensible reason that I can see, and we are all the poorer for it. Well done, V6OPS, well done. -- james woodyatt core os networking From equinox@diac24.net Fri Feb 22 19:05:04 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079B921F8F1C; Fri, 22 Feb 2013 19:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvhKhiy-hfq8; Fri, 22 Feb 2013 19:05:03 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AC521F8F2A; Fri, 22 Feb 2013 19:04:58 -0800 (PST) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2::]) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U95Pr-0002bA-Qv; Sat, 23 Feb 2013 04:04:47 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1U95Pe-00EM1J-Ad; Sat, 23 Feb 2013 04:04:37 +0100 Date: Sat, 23 Feb 2013 04:04:34 +0100 From: David Lamparter To: "Fred Baker (fred)" Message-ID: <20130223030434.GD3183407@jupiter.n2.diac24.net> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> <20130222114822.GA3183407@jupiter.n2.diac24.net> <8C48B86A895913448548E6D15DA7553B79F4E1@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C48B86A895913448548E6D15DA7553B79F4E1@xmb-rcd-x09.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ole Troan , "isis-chairs@tools.ietf.org" , Ray Hunter , "ospf@ietf.org" , Lorenzo Colitti , "homenet@ietf.org Group" , "Abhay Roy \(akr\)" , David Lamparter Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 03:05:04 -0000 also inline On Fri, Feb 22, 2013 at 05:41:43PM +0000, Fred Baker (fred) wrote: > inline > > On Feb 23, 2013, at 12:48 AM, David Lamparter > wrote: > > For both "simple" and "full-blown" OSPFv3 the following loop/interop > > mechnisms come to my mind: > > > > 1. refusing adjacencies between SADR and non-SADR routers. > > Easily implemented with a Hello bit, this is the crowbar solution. > > Quite sufficient for homenet I guess, but probably less acceptable > > for anything else. > > > > 2. flagging SADR support in router LSAs/LSPs. > > Provides enough information to avoid loops. Three things can be done > > with this information: > > > > 2a. install null/reject routes for paths that cross non-SADR routers. > > Provides adequate failure semantics, instead of looping packets > > around we get an ICMP unreachable. Easy to implement. > > Downside: if there really is a non-SADR router, "not working" is > > now a state that is part of the result set of the dynamic route > > calculations. Users (and admins) probably do not expect this. > > > > 2b. calculate SPF around non-SADR routers > > Gets us a working network, but at a cost: there may now be 2 > > different paths to reach some faraway router, one for SADR-routed > > packets and a different one for non-SADR packets. Depending on how > > the router performs its SPF calculations, this can be hard to > > implement correctly - it's essentially a very narrowly and exactly > > specified case of multitopology routing. > > > > 2c. on encountering non-SADR routers, figure whether they'll do the > > right thing with the packet. > > ... complicated and of questionable use IMHO. Just listing this > > for completeness. > > > > 2a and 2b can be mixed with each other; packets will get passed along by > > 2a-type routers until they get discarded at a 2b-type router. > > > > My personal opinion at this point is that 2a and 2b should both be > > specified, with a requirement to indicate support level in the router > > documentation. We're unlikely to encounter normal OSPFv3 speakers in a > > plain "production/final" homenet, so they could take the easy way. If > > this gets implemented on routers for enterprise use, I'd expect 2b > > behaviour. > > > So you want the non-SADR routers to implement a null route, and the > SADR routers to route around the non-SADR routers. No - sorry for not wording this clearly enough. I want SADR routers to notice that they've hit a non-SADR router in their SPF calculation. And if they do, the SADR routers can either install a null route (and keep topological sanity, flagging the route under consideration down as "sorry no can do"), or go the alternate topology way. > I'm scratching my head on how the un-updated routers would know to > install a null route if they don't understand the information. They don't, indeed. > I do think it would be straightforward to add a flag to the Hello > indicating that they understand such updates, and refusing to neighbor > with a router that doesn't. We have done that for other features. That > does mean that adding a router to an area that understands the updates > forces an update to all of the routers in an area, which could be a > pain when upgrading. I think moving this flag to the router LSA is under all circumstances preferable over this. With the null route variant, it gives a painless upgrading path that keeps plain-old destination routing working; SADR can then be put into use when the relevant routers have the support. > Setting a flag in the Router LSA indicating willingness to handle > these routes is possible, but takes us in the direction of topological > routing. My problem with approaching it as a topology is the implied > management overhead; we need to know whether to include any given > router or link in a given topology, and where we might have advertised > topology-specific metrics in RFC 4915, we now want to infer that from > a capability flag. ick. This is exactly why the SADR routers can instead go install a null route, the only thing needed there is checking whether any router on the calculated path doesn't support SADR. FWIW, I think the double topology idea is not completely out of whack, though admittedly complicated and complex. The semantics are reasonably well-defined, it boils down to bifurcating into exactly two topologies, one normal and one SADR. I'm not particularly keen or tacked down on it though. -David P.S.: I can write this up in spec form if desired, I'm relatively new to IETF and have no idea how this works and all. Shall I put some text together for the null route variant and throw it in here? That would as a side effect make it easier to evaluate the idea, I think. From swmike@swm.pp.se Fri Feb 22 21:36:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0F721E803D for ; Fri, 22 Feb 2013 21:36:29 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+twOdC6gMwv for ; Fri, 22 Feb 2013 21:36:28 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C54BE21E8030 for ; Fri, 22 Feb 2013 21:36:26 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 70C669C; Sat, 23 Feb 2013 06:36:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 641729A; Sat, 23 Feb 2013 06:36:24 +0100 (CET) Date: Sat, 23 Feb 2013 06:36:24 +0100 (CET) From: Mikael Abrahamsson To: Ole Troan In-Reply-To: <3E23756C-A4E4-4D48-B534-EAB191F1AA48@cisco.com> Message-ID: References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> <51276A40.5020705@globis.net> <3E23756C-A4E4-4D48-B534-EAB191F1AA48@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: "homenet@ietf.org Group" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 05:36:29 -0000 On Fri, 22 Feb 2013, Ole Troan wrote: >> What about figure 2 of the Homenet Architecture? >> >> +-------+-------+ +-------+-------+ \ >> | Service | | Service | \ >> | Provider A | | Provider B | | Service >> | Router | | Router | | Provider >> +------+--------+ +-------+-------+ | network >> | | / >> | Customer | / >> | Internet connections | / >> | | >> +------+--------+ +-------+-------+ \ >> | IPv6 | | IPv6 | \ >> | Customer Edge | | Customer Edge | \ >> | Router 1 | | Router 2 | / >> +------+--------+ +-------+-------+ / >> | | / >> | | | End-User >> ---+---------+---+---------------+--+----------+--- | network(s) >> | | | | \ >> +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ >> |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / >> | H1 | | H2 | | H3 | | H4 | / >> +----------+ +----------+ +----------+ +----------+ >> >> Figure 2 >> >> >> > if there is no interconnect between R1 and R2, then the host has two > interfaces connected to two separate connections. then I can't see how > that can be solved in the network. my assumption is that all homenet routers > must be connected (I see I haven't stated that anywhere, but that should be added). But CE1 and CE2 share an interface in this case (the LAN). Shouldn't they be able to observe each others RA packets and from them discern what source addresses should go where? If CE1 receives packets from sources that is not from any address that CE1 has sent out RAs or DHCPv6-PD subdelegated from, then it's pretty obvious that these packets should not go out its default route because they're going to get dropped by ISP1 uRPF anyway. If it sees another router advertising those addresses on the LAN (or actually any addresses in case there are only two routers), then it should send the packets there. I know this doesn't solve other topologies, but in this perticular case it should be doable (but requires new functionality in the routers, but the hosts do not need any new functionality). -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Sat Feb 23 00:15:31 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D781D21F8F6A for ; Sat, 23 Feb 2013 00:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.85 X-Spam-Level: X-Spam-Status: No, score=-100.85 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNrdwl6Ion3I for ; Sat, 23 Feb 2013 00:15:31 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 35AA121F8DCB for ; Sat, 23 Feb 2013 00:15:31 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hm6so1548026wib.14 for ; Sat, 23 Feb 2013 00:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SpqLKUrifOfimGybj/NLXo4dMLPRI8Llq/jzZBeJdj4=; b=ROEd/xDrrMTWwMlVz1u36UwwhVYdsZTJRAJhhJ/nELYPTTpNuBCpGF/euEGZLlKJZY pgug+sMFcYe6SW3SrscC4jD0zgOcKMb7HayKjsF7jf+lQHymw3TBKrVDv/Ia1g84ojtO 8jth4DMwb8rdJZ30Z6Ql48SQuhsOsyCi8oBR9Y/ATCQO/5C5B9NmuU8+BZtNsadpV+Xn nyo2EEqFDLQ9w6DGCF6riXAbmYYdM8ioZF1QWs0fULqKYBDFMC+faISI5mItdy8FC6od ZROV3prX7tAienYuH2R3BVbUYT7rWLWlcfvQZDml8/H044kZe9cGxxFaJI8ULjkUc3UG JX7A== X-Received: by 10.194.58.202 with SMTP id t10mr8332614wjq.4.1361607330415; Sat, 23 Feb 2013 00:15:30 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-117.as13285.net. [2.102.216.117]) by mx.google.com with ESMTPS id n10sm2671084wia.0.2013.02.23.00.15.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Feb 2013 00:15:29 -0800 (PST) Message-ID: <51287AB1.7040700@gmail.com> Date: Sat, 23 Feb 2013 08:15:45 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> In-Reply-To: <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 08:15:32 -0000 On 22/02/2013 21:11, james woodyatt wrote: > This problem is precisely why I campaigned bitterly and vigorously against the adoption and V6OPS and later the publication of RFC 6177. > > When there was still a consensus that subscribers should always get a /48 prefix I think you must have missed the bit where operators and RIRs around the world abandoned the /48 recommendation wholesale. 6177 simply recognised reality. I agree it's a shame, but it was not the IETF's doing. Brian From brian.e.carpenter@gmail.com Sat Feb 23 00:20:19 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAE521F8DCB for ; Sat, 23 Feb 2013 00:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.769 X-Spam-Level: X-Spam-Status: No, score=-99.769 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o95G9MZjEPAr for ; Sat, 23 Feb 2013 00:20:19 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id A98A121F8B8F for ; Sat, 23 Feb 2013 00:20:18 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t11so1168693wey.14 for ; Sat, 23 Feb 2013 00:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=a1pZn0ITMfSgt1xqTZHN9u26DsBtBWcBiHIkT7y9oUk=; b=OVATml5G4pOGsv0SmuZrYpHqi6bpL7yQAbBpuC475hKwGAibVSEdEVR9wnRutJsnhs F9MDxskUvksCHSuw3cLDIsXW+qiIzbLq5jzCY0OgGRx4gB4aqiKymo89z9RqFRSvp7SQ gT9y78wg3wCmIWg+DA+eGJFGsdfU+rFFkwBj5Zc9YgeATugYUsp8fAN4rZlaHFPx9gAx Bv+aMiBPLE4vJbjOuJgibZhNdcpwGgL4MIJvGfMPacUCG/F3P/H+2KQXdvjW21uQbPVV nPkz+jpZfv4C+an03D7vBJuDgihSE3EOksLE6Sgh0bsX2oWjLM/rmdxScUbxJyi6kZzc xNMQ== X-Received: by 10.180.84.162 with SMTP id a2mr1718487wiz.14.1361607617869; Sat, 23 Feb 2013 00:20:17 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-117.as13285.net. [2.102.216.117]) by mx.google.com with ESMTPS id ej8sm2274866wib.9.2013.02.23.00.20.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Feb 2013 00:20:16 -0800 (PST) Message-ID: <51287BD1.1080608@gmail.com> Date: Sat, 23 Feb 2013 08:20:33 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <8C48B86A895913448548E6D15DA7553B79F270@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B79F270@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , "homenet@ietf.org Group" , Lorenzo Colitti Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 08:20:19 -0000 On 22/02/2013 16:54, Fred Baker (fred) wrote: ... > BTW, a side-note on the issue of non-volatile memory. The OSPF autoconfig draft says that an allocated prefix MUST be stored in non-volatile memory and as a result survive a reboot. Speaking for myself, I don't see the need for that; I'm not opposed to someone doing it, but they now have to think about "what happens when" for various kinds of network changes. I think the principle might be one of "least surprise"; if a certain prefix is in use on a LAN and the DIS changes (perhaps the old one fails), the new DIS should use the same prefix as the old one, so that the hosts don't have to jump through hoops. That said, I don't see the argument around a whole-building power failure; unless there is a server being advertised in DNS, a randomly-selected new prefix will work just as well as the old one. If Dynamic DNS Update is used, or some equivalent, even that issue would go away. But I think that to the extent that IPv6 addresses will ever appear on a user's screen, having stable values does have a small benefit. Also see the issues raised in draft-ietf-6renum-static-problem, some of which may apply in a homenet. Brian From equinox@diac24.net Sat Feb 23 01:19:42 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C1F21F8F41 for ; Sat, 23 Feb 2013 01:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWVMSB-iAvAp for ; Sat, 23 Feb 2013 01:19:39 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B70B21F8F42 for ; Sat, 23 Feb 2013 01:19:36 -0800 (PST) Received: from jupiter.n2.diac24.net ([2001:8d8:81:5c2::]) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U9BGV-0006fL-36; Sat, 23 Feb 2013 10:19:31 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1U9BGE-00EgQm-A3; Sat, 23 Feb 2013 10:19:20 +0100 Date: Sat, 23 Feb 2013 10:19:14 +0100 From: David Lamparter To: "Fred Baker (fred)" Message-ID: <20130223091914.GF3183407@jupiter.n2.diac24.net> References: <8C48B86A895913448548E6D15DA7553B79DAEF@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C48B86A895913448548E6D15DA7553B79DAEF@xmb-rcd-x09.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "homenet@ietf.org Group" , "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" Subject: Re: [homenet] Egress Routing Discussion X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 09:19:42 -0000 On Thu, Feb 21, 2013 at 05:22:22PM +0000, Fred Baker (fred) wrote: [...snip...] > I have documented my approach, which provides the generalized concept, is built into the routing protocols IS-IS and OSPF, and also addresses at least one other "tagged routing" option, which is to look at flow labels. > > http://tools.ietf.org/html/draft-baker-ipv6-isis-automatic-prefix > "Automated prefix allocation in IS-IS", Fred Baker, 18-Feb-13 > > http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing > "Using IS-IS with Role-Based Access Control", Fred Baker, 17-Feb-13 > > http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing > "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 17-Feb-13 > > http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing > "Using OSPFv3 with Role-Based Access Control", Fred Baker, 17-Feb-13 > > http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing > "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 17-Feb-13 > > http://tools.ietf.org/html/draft-baker-ipv6-ospf-extensible > "Extensible OSPF LSAs", Fred Baker, 17-Feb-13 While I did not exactly review or even thoroughly read the -ospf-extensible draft, I did just try to work with it in adding the null route idea to -ospf-dst-src-routing. I made these observations: - the two drafts share the "FIB Design" appendix. That shouldn't be in -extensible I presume? - the -extensible draft says absolutely nothing about how to handle unknown TLVs. I would suggest adding a bit to indicate mandatory / optional status, as done for example with BGP attributes. I'm not sure whether cutting down on possible TLV or length values is viable, so maybe a third TLV header byte needs to be added for this. - the -extensible draft references the source-prefix TLV. This seems OK in general, however in 3.1.1 IPv6 Destination Prefix TLV, "The IPv6 Destination Prefix TLV MAY be used with the IPv6 Source Prefix TLV, [...]" I believe it is somewhat weird to refer to a TLV that is not defined in that draft. Cheers, -David From rogerj@gmail.com Sat Feb 23 01:38:46 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F7C21F8F4D for ; Sat, 23 Feb 2013 01:38:46 -0800 (PST) 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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu7cz2WHpIkL for ; Sat, 23 Feb 2013 01:38:45 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 338C321F8F4E for ; Sat, 23 Feb 2013 01:38:44 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id k1so1351013oag.33 for ; Sat, 23 Feb 2013 01:38:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=eqc9xD2bgJ1aR2lNvULdN7ZfMDyfI4GaTVFtHvZ0fBM=; b=vsgHZbxcf2m7miRRrJ7FWHJXj7VnS4t2s+cWEV1V9CgTcQ65QQfX4Gu0gq2cVV9wyS YQfTisaxwbWopG1hSNIOgpQ5IvY98tU/pmKK+efeYa9NnxLiwS2hQ2WIzSQzZUt2uJk+ vNlGHUCPCFOiIixxqtyiKkKdYl0k7CkyWl2QQ1sPRLBnV0S0tqYvXeTeOY10maImkmeG ye847SveMyI29lJD+qpQbNVqShO/LEp7pE2Q4fQ5liFDosSfkJ3qMqEtnsI66/SKarZc VEG/dscXO59u8jKlOTnawm8gC/1pzmkDJzrev1ykk/42B18qSbeL+Zmu9Sy8z5o+IPd3 u6Dg== MIME-Version: 1.0 X-Received: by 10.60.5.165 with SMTP id t5mr1993886oet.117.1361612324456; Sat, 23 Feb 2013 01:38:44 -0800 (PST) Received: by 10.76.167.106 with HTTP; Sat, 23 Feb 2013 01:38:44 -0800 (PST) In-Reply-To: <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> Date: Sat, 23 Feb 2013 10:38:44 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: james woodyatt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org" Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 09:38:46 -0000 It might be a sidetrack on the discussion but I'll answer anyway On Fri, Feb 22, 2013 at 10:11 PM, james woodyatt wrote: > On Feb 22, 2013, at 06:16 , Michael Richardson wr= ote: >> >> If the ISP with the longest prefix is alive first, then the routers >> pick subnet-id parts that fit into that. If that ISP has provided >> enough subnets, then even when another ISP comes along, the "xx23" >> part might remain stable for a long time. > > This problem is precisely why I campaigned bitterly and vigorously agains= t the adoption and V6OPS and later the publication of RFC 6177. > > When there was still a consensus that subscribers should always get a /48= prefix, it was reasonable to expect that a randomly chosen 16-bit subnet i= dentifier would be unlikely to collide with another subnet in most automati= cally numbered routing domains. We were also in a position to expect that = when a subscriber adds a new prefix from the same or a different provider, = that all the subnet identifiers in use on one prefix could be mapped 1:1 in= to the new prefix. Now we have RFC 6177, which explodes all of that, for b= asically no sensible reason that I can see, and we are all the poorer for i= t. > > Well done, V6OPS, well done. As Brian said, it just reflect what RIR already has in place. I was one of those that suggested and argued for the possibility of using /56 for end-users, not only /48. However I still believe /48's are great and I use it for most end-SITES. For end-USERS a /48 is quite an overkill almost any way you consider it, except if you look at it from a very overall point of view like in the situation this mail-thread is about. 256 /64 is more than enough for almost all end-user cases I can dream up. If any end-user have a setup where 256 LAN segments ain't enough, well then it's so big that it should be consider a end-site and we are back to /48. The use case for homenet are those end-users, not end-sites. Or? --=20 Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From mcr@sandelman.ca Sat Feb 23 08:20:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B691D21F8FCF for ; Sat, 23 Feb 2013 08:20:52 -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.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KFg8Yj+5fUg for ; Sat, 23 Feb 2013 08:20:52 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id DCB0021F8FCE for ; Sat, 23 Feb 2013 08:20:50 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 732B72016E for ; Sat, 23 Feb 2013 11:27:47 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 115966387F; Sat, 23 Feb 2013 11:19:40 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DA0136387D for ; Sat, 23 Feb 2013 11:19:40 -0500 (EST) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 16:20:52 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Erik" =3D=3D Erik Kline writes: >> I don't know about naming and security, but renumbering works >> using address deprecation (that's been in the spec since >> forever), and since it's covered by RFC6204 and there are >> conformance tests for it, devices with the appropriate logo will >> support it. Erik> I wonder if we should ask the NOC about performing a Erik> renumbering during the next IETF meeting. v6 or v6 and v4? Given happy eyeballs, how will we measure the impact of a v6-only renumbering? =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUSjsHIqHRg3pndX9AQKOzQQAxC39iHMCPBPHoSMnZCoJ/ZFSVgbHgDPO 8BVI2iVTm7EpOptAjX0ryTwqnZbqi8vBt5+Pg/Nn+5Gn/lC/eDfPpBKkRhr47i1s Eg52Y1bzWhMz/+AlyIeUzAI+H1s03Y6mH5ukSlRrfsxcmsvH8WZi+mnSipOw30dt esseyP2bb6Q= =oABF -----END PGP SIGNATURE----- --=-=-=-- From tsavo.stds@gmail.com Sat Feb 23 09:56:37 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB4421F8F0B for ; Sat, 23 Feb 2013 09:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.274 X-Spam-Level: X-Spam-Status: No, score=0.274 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGaK9EKNCyk0 for ; Sat, 23 Feb 2013 09:56:30 -0800 (PST) Received: from mail-la0-x22a.google.com (la-in-x022a.1e100.net [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5C721F8F05 for ; Sat, 23 Feb 2013 09:56:29 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id fe20so1546186lab.29 for ; Sat, 23 Feb 2013 09:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:mime-version:to:cc:from:subject:date :content-type; bh=eJUbHC+t++XyQWl9pf1VXDfL6KEdTy85Et66JCWs9ag=; b=l6n1LtedyKzd+FYDt/yIFTXucrmmkNYqstgXHLICguH1762nU96paDKRSNu4oB0X5j nMIg4ggwB6pU/UInwf/Bv8G6wwA28phTKkMmI0XZa+9F2ZzQbAYJoCHuZZrjw8UO+/Rt 1S11P/+2uBDL/kNBSFqNhjhdxWRObOI+IAcrfjsz4O90HmJptd0K3hScRsXSmJVGsHI/ lbuOSMApJ8RJFQpCecVYuh4FdhY1y4uZWbL2t/ywe1p2s7ysYU1uR8LUhOR7phLkEb/Z pPtLgAmVocRhD++QVbZ9shzMyhJvH1IZ8UJxAKgEf7tDZvKQritaHB5pguJUax/OlY9T FoPw== X-Received: by 10.112.9.200 with SMTP id c8mr2156787lbb.122.1361642188761; Sat, 23 Feb 2013 09:56:28 -0800 (PST) Received: from [85.156.137.51] (85-156-137-51.elisa-mobile.fi. [85.156.137.51]) by mx.google.com with ESMTPS id c6sm2186182lbo.3.2013.02.23.09.56.26 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 23 Feb 2013 09:56:28 -0800 (PST) Message-ID: <512902cc.8632700a.0347.5c46@mx.google.com> MIME-Version: 1.0 To: Simon Kelley , Ted Lemon From: Teemu Savolainen Date: Sat, 23 Feb 2013 19:56:16 +0200 Content-Type: multipart/alternative; boundary="_98D7B163-8DFD-473F-8879-08A41E10D8E6_" Cc: "homenet@ietf.org" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 17:56:38 -0000 --_98D7B163-8DFD-473F-8879-08A41E10D8E6_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" And this works with hosts that use IPv6 privacy addresses and not have IIDs= derived from MAC? -----Original Message----- From: "Simon Kelley" Sent: =E2=80=8E22.=E2=80=8E2.=E2=80=8E2013 17:54 To: "Ted Lemon" Cc: "homenet@ietf.org" ; "David Lamparter" Subject: Re: [homenet] NPTv6-only home networks On 22/02/13 14:50, Ted Lemon wrote: > On Feb 22, 2013, at 8:24 AM, Simon Kelley wrote= : >> It works as well for clients which do DHCPv4 and SLAAC. IPv6-only hosts >> would have to do stateful DHCPv6, but the DHCPv4 and SLAAC model covers >> an awful lot of currently-deployed clients. >=20 > So dnsmasq is noticing that the IPv4 and IPv6 hosts are the same host usi= ng the MAC address or something, and then coordinating the DNS registration= ? >=20 >=20 As the DHCPv4 state machine moves to "lease complete" it spits a (MAC address, hostname, broadcast domain) tuple over to the IPv6 side. The broadcast domain plus configuration yields a list of prefixes, and the MAC address gets turned into a SLAAC host-identifier. The two make a set of putative addresses. The state machine then sends an ICMP6 echo request to each putative address and if it responds then that address is added as an AAAA record with the hostname. There are some implementation details involving timeouts and retries and sending speculative router advertisements to ensure that a new-on-the-network host is ready to reply to the pings. The practice is that it always works, even a smartphone moving slowly into a dodgy Wifi network. If the client can get a DHPCv4 lease, the IPv6 SLAAC address gets a name too. Simon. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet --_98D7B163-8DFD-473F-8879-08A41E10D8E6_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
And this wo= rks with hosts that use IPv6 privacy addresses and not have IIDs derived fr= om MAC?
From: Simon Kelley
Sent: =E2=80=8E22.=E2=80=8E2.=E2=80=8E2013 17:54
To: Ted Lemon
Cc: homenet@ietf.org; David Lamparter
Subject: Re: [ho= menet] NPTv6-only home networks

On 22/02/13 14:50, Ted = Lemon wrote:
> On Feb 22, 2013, at 8:24 AM, Simon Kelley <simon@th= ekelleys.org.uk> wrote:
>> It works as well for clients which d= o DHCPv4 and SLAAC. IPv6-only hosts
>> would have to do stateful D= HCPv6, but the DHCPv4 and SLAAC model covers
>> an awful lot of cu= rrently-deployed clients.
>
> So dnsmasq is noticing that the = IPv4 and IPv6 hosts are the same host using the MAC address or something, a= nd then coordinating the DNS registration?
>
>
As the DHCP= v4 state machine moves to "lease complete" it spits a (MAC
address, host= name, broadcast domain) tuple over to the IPv6 side.
The broadcast domai= n plus configuration yields a list of prefixes, and
the MAC address gets= turned into a SLAAC host-identifier. The two make a
set of putative add= resses. The state machine then sends an ICMP6 echo
request to each putat= ive address and if it responds then that address is
added as an AAAA rec= ord with the hostname.

There are some implementation details involvi= ng timeouts and retries and
sending speculative router advertisements to= ensure that a
new-on-the-network host is ready to reply to the pings.
The practice is that it always works, even a smartphone moving slowly=
into a dodgy Wifi network. If the client can get a DHPCv4 lease, theIPv6 SLAAC address gets a name too.

Simon.

_________________= ______________________________
homenet mailing list
homenet@ietf.org<= BR>https://www.ietf.org/mailman/listinfo/homenet
= --_98D7B163-8DFD-473F-8879-08A41E10D8E6_-- From simon@thekelleys.org.uk Sat Feb 23 10:02:16 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654FC21F8F63 for ; Sat, 23 Feb 2013 10:02:16 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaqXjZbzJer1 for ; Sat, 23 Feb 2013 10:02:12 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id 5562421F8F5B for ; Sat, 23 Feb 2013 10:02:12 -0800 (PST) Received: from cpc11-cmbg17-2-0-cust618.5-4.cable.virginmedia.com ([86.30.118.107]:36183 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U9JQI-0006CT-IK; Sat, 23 Feb 2013 18:02:10 +0000 Received: from host81-149-103-178.in-addr.btopenworld.com ([81.149.103.178] helo=[192.168.2.100]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1U9JQH-0003VZ-Sh; Sat, 23 Feb 2013 18:02:10 +0000 Message-ID: <5129041C.2090106@thekelleys.org.uk> Date: Sat, 23 Feb 2013 18:02:04 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Teemu Savolainen References: <512902cc.8632700a.0347.5c46@mx.google.com> In-Reply-To: <512902cc.8632700a.0347.5c46@mx.google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "homenet@ietf.org" , Ted Lemon , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 18:02:16 -0000 On 23/02/13 17:56, Teemu Savolainen wrote: > And this works with hosts that use IPv6 privacy addresses and not have > IIDs derived from MAC? If they have only privacy addresses, it doesn't work. If they have both a SLAAC address and a privacy address, and use the privacy address when initiating connections (for privacy), but accept connections to the SLAAC address, then it still works. Simon. > ------------------------------------------------------------------------ > From: Simon Kelley > Sent: ‎22.‎2.‎2013 17:54 > To: Ted Lemon > Cc: homenet@ietf.org ; David Lamparter > > Subject: Re: [homenet] NPTv6-only home networks > > On 22/02/13 14:50, Ted Lemon wrote: > > On Feb 22, 2013, at 8:24 AM, Simon Kelley > wrote: > >> It works as well for clients which do DHCPv4 and SLAAC. IPv6-only hosts > >> would have to do stateful DHCPv6, but the DHCPv4 and SLAAC model covers > >> an awful lot of currently-deployed clients. > > > > So dnsmasq is noticing that the IPv4 and IPv6 hosts are the same host > using the MAC address or something, and then coordinating the DNS > registration? > > > > > As the DHCPv4 state machine moves to "lease complete" it spits a (MAC > address, hostname, broadcast domain) tuple over to the IPv6 side. > The broadcast domain plus configuration yields a list of prefixes, and > the MAC address gets turned into a SLAAC host-identifier. The two make a > set of putative addresses. The state machine then sends an ICMP6 echo > request to each putative address and if it responds then that address is > added as an AAAA record with the hostname. > > There are some implementation details involving timeouts and retries and > sending speculative router advertisements to ensure that a > new-on-the-network host is ready to reply to the pings. > > The practice is that it always works, even a smartphone moving slowly > into a dodgy Wifi network. If the client can get a DHPCv4 lease, the > IPv6 SLAAC address gets a name too. > > Simon. > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From mellon@fugue.com Sat Feb 23 10:15:07 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF4E21F8780 for ; Sat, 23 Feb 2013 10:15:06 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujl3LeBH429r for ; Sat, 23 Feb 2013 10:15:05 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B8E9721F8EB5 for ; Sat, 23 Feb 2013 10:15:05 -0800 (PST) Received: from kali-9.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 4AE8723801AA; Sat, 23 Feb 2013 13:14:55 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <5129041C.2090106@thekelleys.org.uk> Date: Sat, 23 Feb 2013 13:14:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <512902cc.8632700a.0347.5c46@mx.google.com> <5129041C.2090106@thekelleys.org.uk> To: Simon Kelley X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org" , Teemu Savolainen , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 18:15:07 -0000 On Feb 23, 2013, at 1:02 PM, Simon Kelley = wrote: > If they have only privacy addresses, it doesn't work. If they have = both a SLAAC address and a privacy address, and use the privacy address = when initiating connections (for privacy), but accept connections to the = SLAAC address, then it still works. I would argue that if they have only privacy addresses, it _does_ work, = because privacy addresses ought not to be published in the DNS. From tsavo.stds@gmail.com Sat Feb 23 10:39:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927F521F8F0F for ; Sat, 23 Feb 2013 10:39:57 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS5P8LQDTUmJ for ; Sat, 23 Feb 2013 10:39:56 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 76B3521F8F0E for ; Sat, 23 Feb 2013 10:39:56 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so2072609wib.3 for ; Sat, 23 Feb 2013 10:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OeXtWNoy0SuiAovXRxC3HF3ctgZIbB1x7TKxn0uQNRk=; b=jxGm0gwQAIZpaYYr0JqrSHf/Fl2Cd2X4uQ3WIZcQX73nkaOrEGwtO1ZF6FldQ8ZOAO jYdqVpHdabR2ungJLicZCKxEk82pQmfHp0zGHkk1DG1vtmOTe0WV29HE8rnw9aB1M22A 4PnuBBXivOEVSQ5mDRSPLybz6wNWlYEdyODug0H/USuUhhK8n321sSzQpus2v0fzaQhD LQe+MiV9yrOdUZWSWkXTjxaIaY5v3oGOQL2atBYt6PQbJsAVA8Ic3aGTo6yAdQNCPte/ lVskAXVEBHvxKdO4DBN7aDqXDUDJlEbYybjkS0tOEgumW1vg9THkxiT+R+jt9Vcqk1XC 2R5w== MIME-Version: 1.0 X-Received: by 10.194.92.65 with SMTP id ck1mr10208857wjb.54.1361644795680; Sat, 23 Feb 2013 10:39:55 -0800 (PST) Received: by 10.194.152.71 with HTTP; Sat, 23 Feb 2013 10:39:55 -0800 (PST) Received: by 10.194.152.71 with HTTP; Sat, 23 Feb 2013 10:39:55 -0800 (PST) In-Reply-To: References: <512902cc.8632700a.0347.5c46@mx.google.com> <5129041C.2090106@thekelleys.org.uk> Date: Sat, 23 Feb 2013 20:39:55 +0200 Message-ID: From: Teemu Savolainen To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bd91f105b573504d668a259 Cc: Simon Kelley , "homenet@ietf.org" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 18:39:57 -0000 --047d7bd91f105b573504d668a259 Content-Type: text/plain; charset=ISO-8859-1 Good points, those clarify. Might be good idea to write I-D about:) Thank you. On Feb 23, 2013 8:14 PM, "Ted Lemon" wrote: > On Feb 23, 2013, at 1:02 PM, Simon Kelley wrote: > > If they have only privacy addresses, it doesn't work. If they have both > a SLAAC address and a privacy address, and use the privacy address when > initiating connections (for privacy), but accept connections to the SLAAC > address, then it still works. > > I would argue that if they have only privacy addresses, it _does_ work, > because privacy addresses ought not to be published in the DNS. > > --047d7bd91f105b573504d668a259 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Good points, those clarify. Might be good idea to write I-D = about:)

Thank you.

On Feb 23, 2013 8:14 PM, "Ted Lemon" &= lt;mellon@fugue.com> wrote:
On Feb 23, 2013, at 1:02 PM, Simon Kelley <simon@thekelleys.org.uk> wrote:
> If they have only privacy addresses, it doesn't work. If they have= both a SLAAC address and a privacy address, and use the privacy address wh= en initiating connections (for privacy), but accept connections to the SLAA= C address, then it still works.

I would argue that if they have only privacy addresses, it _does_ work, bec= ause privacy addresses ought not to be published in the DNS.

--047d7bd91f105b573504d668a259-- From mellon@fugue.com Sat Feb 23 10:46:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AABA21F8F22 for ; Sat, 23 Feb 2013 10:46:06 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyhhxKQBs5YX for ; Sat, 23 Feb 2013 10:46:05 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBE721F8F19 for ; Sat, 23 Feb 2013 10:46:05 -0800 (PST) Received: from kali-9.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 7D04C23801AA; Sat, 23 Feb 2013 13:46:04 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: Date: Sat, 23 Feb 2013 13:46:03 -0500 Content-Transfer-Encoding: 7bit Message-Id: <5F0C8E4D-3E54-42C6-BD86-43965CD49BC6@fugue.com> References: <512902cc.8632700a.0347.5c46@mx.google.com> <5129041C.2090106@thekelleys.org.uk> To: Teemu Savolainen X-Mailer: Apple Mail (2.1499) Cc: Simon Kelley , "homenet@ietf.org" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 18:46:06 -0000 On Feb 23, 2013, at 1:39 PM, Teemu Savolainen wrote: > Good points, those clarify. Might be good idea to write I-D about:) You offering? :) From v6ops@globis.net Sat Feb 23 10:48:33 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0446921F8759 for ; Sat, 23 Feb 2013 10:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.403 X-Spam-Level: X-Spam-Status: No, score=-3.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjC1H0s-xJL9 for ; Sat, 23 Feb 2013 10:48:31 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 523CE21F8911 for ; Sat, 23 Feb 2013 10:48:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id EB4CE87005B; Sat, 23 Feb 2013 19:40:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN-+suNWXKsU; Sat, 23 Feb 2013 19:40:10 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 7F8E3870049; Sat, 23 Feb 2013 19:40:10 +0100 (CET) Message-ID: <51290D04.5060001@globis.net> Date: Sat, 23 Feb 2013 19:40:04 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Ray Bellis , Tim Chown References: <53F00E5CD8B2E34C81C0C89EB0B4FE73104F65F1@wds-exc1.okna.nominet.org.uk> <51278B89.8000107@gmail.com> <53F00E5CD8B2E34C81C0C89EB0B4FE731053F75D@wds-exc2.okna.nominet.org.uk> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE731053F75D@wds-exc2.okna.nominet.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 18:48:33 -0000 As requested I have read draft-ietf-homenet-arch-07. Thanks everyone for the effort so far. IMHO I think the document is in very good shape, but that we're not quite there yet (which I guess means I'm obliged to supply comments on why I think that's the case). The main thrust of my comments below is an underlying feeling that we haven't yet fully got a handle on the boundary at the ISP/customer interface & the homenet/Internet interface, and that this will bite us later. I also think there's quite a bit of room to tighten up on nomenclature. e.g. home network v. homenet. ISP uplink v. Customer Internet connections. Border v. CER v. Border CER. Perhaps rather surprisingly, "homenet" is not defined anywhere. regards, RayH Detailed comments =============== Section 1 s/While at the time of writing some complex home network topologies exist, but most are/ While at the time of writing some complex home network topologies exist, most are / s/like to avoid such/like to avoid, such/ s/IPv6 with an eye/IPv6, with an eye/ s/can not be affected by new /cannot be modified by new / /[RFC6204] defines basic requirements for customer edge routers (CERs). The scope of this text is the internal homenet, and thus specific features on the CER are out of scope for this text./ I find this particular formulation confusing. Perhaps /[RFC6204] defined basic requirements for customer edge routers (CERs), which has recently been updated with the definition of requirements for specific transition tools on the CER in RFC 6204-bis [I-D.ietf-v6ops-6204bis] i.e. DS-Lite [RFC6333] and 6rd [RFC5969]. Such detailed specification of CER devices is considered out of scope of this architecture document, and we assume that any required update of the CER device specification as a result of adopting this architecture will be handled as separate and specific updates to these existing documents./ Section 1.1. /CER: Customer Edge Router. A border router at the edge of the homenet./ I regularly read "Homenet BR" or "Border Router" on this list used interchangeably with CER. Are they different? Equivalent? Or do we need to change our behaviour/definitions? This is my biggest worry. Do we have a good handle on the interface at the border? Does the set of "End-User network(s)" in Section 3 map 1:1 with a homenet? I don't think so: it includes the CER. What is a "Service Provider Network"? The rest of the Internet that isn't in the homenet? Wouldn't harm to copy some more definitions from 6204. Section 2.1 s/This is discussed later in the document./This is discussed in Section 3.7./ /border router(s)/ See comment on 1.1 Border Router v Customer Edge Router? /There will also be the need to discover which routers in the homenet are the border router(s) by an appropriate mechanism. Here, there are a number of choices. These include an appropriate service discovery protocol, or the use of a well-known name, resolved by some local name service. Both might have to deal with handling more than one router responding in multihomed environments./ Above paragraph does not make sense to me. Seems to be a context shift in the middle of the paragraph. How is a name service related to discovery of a border router? We're not suggesting all CER's have to be called a particular hostname? /2.2. Global addressability and elimination of NAT/ Strictly speaking, NAT won't be eliminated entirely. IPv4 will still use NAT. IPv6 never had NAT. How about just /2.2. Global addressability/ s/The end-to-end communication that is potentially enabled with IPv6/ The possibility for direct end-to-end communication on the Internet that will be restored by the introduction of IPv6/ The Internet architecture always was, and still is, direct end-to-end communication. We just temporarily lost the ability to do it due to lack of addresses. s/on the firewall/ on any firewall/ Section 2.3 s/Default Address Selection for IPv6[I-D.ietf-6man-rfc3484bis]/ Default Address Selection for Internet Protocol Version 6 (IPv6) [RFC6724]/ s/We discuss such challenges in multihoming later in this document./ We discuss such challenges of multihoming in Section 3.3.1./ Section 2.4 s/Despite this counter-argument, while setting a network up there may be a period with no connectivity/

Despite this counter-argument, there may be a period with no connectivity while setting up a network/ s/when the ULA destination lies within a /48 ULA prefix known to be used within the same homenet./ when the ULA source and destination addresses lie within a single /48 ULA prefix known to be used within the same homenet. However, it should be noted that even if it were known that multiple /48 ULA prefixes are in use within a single homenet (perhaps because multiple homenet routers each independently auto-generate a /48 ULA prefix and then share routing information), utilising a ULA source address and a ULA destination address from two disjoint /48 ULA prefixes is not preferred over using GUA by the default address selection rules [RFC6724]. In this case, special action may have to be taken at the individual host level if this was desired behaviour e.g. by modifying the address selection policy table./ Section 2.5 Security and Borders s/The filtering policy to/from the homenet is an important consideration, but the homenet/ISP border may not be the only border in a homenet. It is desirable that there are mechanisms to detect other types of borders, and then the means to apply different types of filtering policies at those borders, e.g. whether naming and service discovery should pass a given border. Any such policies should be able to be easily applied by typical home users, e.g. to give a visitor in a "guest" network access to media services in the home, or access to a printer in the residence. Simple mechanisms to apply policy changes, or associations between devices, will be required./ There are many potential borders related to the homenet. Some of these borders may be obvious by their nature and direct relationship to a physical interface e.g. the border between a high capacity network and a LLN, whilst others less so. The borders may also change over time, dependent on the deployment scenario e.g. a LLN for building control may be fitted during construction as a stand-alone network, and then only later connect to a homenet when the residents move in. The ISP/customer border is defined by ownership of equipment, and this can also change over time e.g. one ISP may supply CER routers, but a competitor ISP doesn't. The filtering policy to/from the homenet to ISP networks is an important consideration. This might include standard ingress and egress filtering [BCP38], as well as other default security policies designed to protect customer-owned resources and ISP-owned resources. It is desirable that there are mechanisms to automatically detect the borders, including those that may be less obvious e.g. a logical separation between a "guest" network and an "internal" network, and then the means to apply different types of filtering policies at those borders. Filtering should be considered in a wider context than just simple packet filters e.g. whether a naming and service discovery should pass a given border, the functions available to a user when connecting to a management interface froma certain network, or filtering of information learned by dynamic routing protocols. Any such policies should be able to be easily applied by typical home users e.g. to grant a "guest" user access to a printer on the "internal" network. Simple mechanisms to apply policy changes, or associations between devices, will be required./ /It is desirable to classify the external border of the home network as a unique logical interface separating the home network from service provider network/s. This border interface may be a single physical interface to a single service provider, multiple layer 2 sub-interfaces to a single service provider, or multiple connections to a single or multiple providers. This border makes it possible to describe edge operations and interface requirements across multiple functional areas including security, routing, service discovery, and router discovery./ I have a problem with the 2nd and 3rd sentences of this paragraph. It mixes organisational interfaces and technical network interfaces. When we start associating the external border with physical interfaces, I think we risk running into problems given the current document. In the current document, the customer may have two CER routers connected to two providers (Figure 2) One of these CER's could be provider managed CER1 and the other customer managed CER2. So the homenet extends to the WAN interface of each CER? That isn't explicitly shown anywhere. If the CER has to take part in autoconfiguration, that presumably means that to support the architecture of figure 2 CER1 will have to accept prefixes from ISP2. It'll also have to accept a default route to ISP2 if the WAN interface to ISP1 goes down. At what point does the ISP controlling CER1 truly have full management control if they can't even control the routing, and they have to accept neighbours and dynamic routing from a customer controlled device? Presumably they have to place their BCP38 filters on the WAN interface? They'll also have to be careful that any management traffic gets sent over the ISP1 interface from an ISP1 prefix, and not to ISP2 (via the default route just learned when the WAN interface goes down). Similarly, how is a customer going to be able to control CER1 sufficiently to be able to add shared secrets etc. required to pair with their devices, when it is controlled by ISP1? I'm not optimistic that this is a workable operational situation. The way we've traditionally handled this in the corporate world is to define an Network to Network Interface (NNI) with one router managed by each party connected back to back over a DMZ, and with no end user devices connected on this interconnection LAN. There would almost certainly need to be homenet specifications for both sides of the border. But that would also break the current autoconfiguration drafts, because they assume the device initiating autoconfiguration is the same device performing DHCPv6 PD. Section 3.3.1 /The alternative for a homenet would be to deploy NPTv6 [RFC6296] at the CER, with ULAs then typically used internally. NPTv6 has some architectural cost, due to the prefix translation used, but the internal part of the homenet (which is the scope of this text) sees only the one prefix in use./ I think this is controversial, and as has been pointed out recently on the WG list, is likely to break name resolution. Also see section 3.4.4 of the architecture /those addresses must not be altered in transit./ As such I think this sentence should be removed. s/[I-D.ietf-6man-rfc3484bis]/[RFC6724]/ Section 3.4.2 Here's 2 examples of the fuzzy external border. An IPv6-only homenet wouldn't have an IPv4 connection to the CER, because the CER is within the homenet. /functionality in the home gateway router, Such features are outside the scope of this document however, being CER functions./ Isn't CER within the homenet? Section 3.4.4 /In IPv4 NAT networks, the NAT provides an implicit firewall function./ Controversial and out of scope. Suggest delete this sentence. Incorrect quotes going further than the original RFC: s/ RFC 4864 implies an IPv6 "default deny" policy for inbound connections be used for similar functionality to IPv4 NAT. / RFC 4864 Section 4.2 states that "the use of firewalls and Intrusion Detection Systems (IDSs) is recommended for those that want boundary protection in addition to host defenses./ s/It should be noted that such a "default deny" approach would effectively replace the need for IPv4 NAT traversal protocols with a need to use a signalling protocol to request a firewall hole be opened./ It should be noted that applying a default deny rule for inbound traffic may require use a signalling protocol to request a firewall hole be opened./ Section 3.4.5 There were many comments on the list about potential negative aspects of ULA. s/ULAs should be used within the scope of a homenet to support routing between subnets regardless of whether a globally unique ISP-provided prefix is available./ULAs could potentially be used within the scope of a homenet to support routing between subnets regardless of whether a globally unique ISP-provided prefix is available, although it should be noted that ULA's may also have some limitations and downside./ Section 3.4.6 s/In general the routing protocol should support multiple ISP uplinks and delegated prefixes in concurrent use/ In general the routing protocol should support multiple customer internet connecions, and thus multiple delegated prefixes in concurrent use/ Section 3.4.7 Suggest adding a sentence or two on splitting and recombination s /The homenet will need to be aware of the extent of its own "site", as discussed in the previous section./ The homenet will need to be aware of the extent of its own "site", as discussed in the previous section. It may be assumed that the homenet is fully connected. If a homenet becomes segmented for whatever reason, this may result in multiple separate, but fully functional, homenets e.g. if the interlink between CER1 and CER2 in figure 2 were to break, this might end up as two disjoint and completely separate homenets, with all hosts still able to communicate with the Internet (using their existing prefixes) via their remaining ISP link. The converse is also true: when two or more homenet routers are (re)connected together (and they can determine that it is intended that they communicate), it is is expected that they will reconfigure to form a single contiguous homenet (with or without disruption to existing communications)./ /There may also be a prefix associated with NAT64, if in use in the homenet./ Suggest delete. Out of scope. /border CER/ What is a "border CER"? s/Where ULAs are used,/ If ULAs are used,/ s/The router should/ The elected router should/ s/should give each link a prefix/ should result in each link being assigned a stable prefix/ Section 3.4.9 What is a dual-stack residential gateway? Suggest s/The naming service should be able to resolve results for both IPv4 and IPv6 addresses, and with queries transported over either IPv4 or IPv6, where the homenet is running in dual stack operation/ ? Section 3.4.10. Proxy or Extend? Suggest moving the last two paragraphs of 3.4.9 into 3.4.10 and combine 3.4.10. Proxy or Extend? Current service discovery protocols are generally aimed at single subnets. There are two broad approaches for allowing services that would otherwise be link-local to work across a homenet site, and these may also need to be combined in practical implementations. In the example of service discovery, one approach is to take protocols like mDNS and have them run over site multicast within the homenet. Implementing Extended mDNS (xmDNS) [I-D.lynn-homenet-site-mdns], may require IPv6 multicast to be available across the scope of the whole homenet. This approach is fine if all hosts support the extension, and the scope within any internal borders is well-understood. But it's not backwards-compatible with existing link-local protocols. And it may have a negative impact on some hosts and media types. In some parts of the homenet, e.g. LLNs, devices may be sleeping, in which case a proxy for such nodes may be required, that can respond to multicast service discovery requests. Those same parts of the network may have less capacity for multicast traffic that may be flooded from other parts of the network. In general, message utilisation should be efficient considering the network technologies the service may need to operate over. The alternative approach is to proxy service discovery across each link, to propagate it. This is more complex, but is backwards-compatible. It would also need to work with IPv6, and dual-stack. The homenet architecture proposes that any existing protocols that are designed to only work within a subnet should be extended to work across subnets, rather than defining proxy capabilities for each of those functions. However, while it is desirable to extend protocols to site scope operation rather than providing proxy functions on subnet boundaries, the reality is that until all hosts can use site- scope discovery protocols, existing link-local protocols would need to be proxied anyway. Some protocols already have proxy functions defined and in use, e.g. DHCPv6 relays, in which case those protocols would be expected to continue to operate that way. Section 3.4.11 s/However, if only a /64 is offered by the ISP, the homenet may be severely constrained, or even unable to function./

BCP 157 [RFC6177] also states that " A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space." However, if insufficient address space is delegated by the ISP, the homenet may be severely constrained, or even unable to function./ /This implies the use of ULAs as supported in RFC 6204./ I think there's still some debate here. Suggest deleting this sentence. Section 3.5. This misses one of the great challenges thrown down by "how to avoid NAT' related to management boundaries. Suggest adding /IPv4/NAT/MAC address spoofing have been widely (ab)used to isolate customer managed portions of the network from network service provider managed portions. One of the expected challenges will be dealing with increased inter-dependencies between a customer and the ISP, given the new transparency of this interface, and the expected increased interaction. regards, RayH Ray Bellis wrote: > On 22 Feb 2013, at 15:15, Brian E Carpenter wrote: > >> I went through the draft, and noticed an instance of the word "hoemnet" in section 2.4. >> >> Otherwise I think this is now in good shape for publication. > > Brian - thanks for the review! > > Working Group participants: > > I know Tim has had some received some feedback directly, but so far on-list I make it one "ready to go" and one "more work required". > > Please *do* review this version as thoroughly as possible before March 4th. > > thanks, > > Ray > > From tsavo.stds@gmail.com Sat Feb 23 12:12:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1122C21F84F9 for ; Sat, 23 Feb 2013 12:12:57 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yz7ohVBZzQB for ; Sat, 23 Feb 2013 12:12:56 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF7221F84D9 for ; Sat, 23 Feb 2013 12:12:56 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id o1so1922710wic.5 for ; Sat, 23 Feb 2013 12:12:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1uOjOqKF4q7gzX/69RaprHS3Zpj1lLXd088QNsKQVjc=; b=tS9kRfbUhuYUmO788UGfmqy11bal5b0kRxr/s2+uusnSmFVJdI8K9jA8eFCPmeVms8 9JdRytzoopj+oK1kMWw5fXW8eejUlKRkeiM4k0cox2s8ngXRvYg7haFtmx9iW+3k03ms JoUeNHcLxjQ3Y7xhaaGzS/d0T9eBYeTL4gF16hEdShlxTJzl3nP3LEWGFuz7ZqG411CN BdhgruWKqDluhFGCs3VTt9174m1otfoMa6Ke/smdaO19nQlk7q462Z8P5zOhTsoE+uPQ OtEBIBs0HeBh8XjxcJnRtOz8YSdxBB5wLk2Rannw08FRyswEYgVJzXEDyxMARO2TWqgw PxsQ== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr10533650wjb.24.1361650375609; Sat, 23 Feb 2013 12:12:55 -0800 (PST) Received: by 10.194.152.71 with HTTP; Sat, 23 Feb 2013 12:12:55 -0800 (PST) Received: by 10.194.152.71 with HTTP; Sat, 23 Feb 2013 12:12:55 -0800 (PST) In-Reply-To: <5F0C8E4D-3E54-42C6-BD86-43965CD49BC6@fugue.com> References: <512902cc.8632700a.0347.5c46@mx.google.com> <5129041C.2090106@thekelleys.org.uk> <5F0C8E4D-3E54-42C6-BD86-43965CD49BC6@fugue.com> Date: Sat, 23 Feb 2013 22:12:55 +0200 Message-ID: From: Teemu Savolainen To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8f642c14f24d2f04d669eed3 Cc: Simon Kelley , homenet@ietf.org, David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 20:12:57 -0000 --e89a8f642c14f24d2f04d669eed3 Content-Type: text/plain; charset=ISO-8859-1 I'll leave it for those whose idea this was:-) (And it lacks the IPv6-only aspect) On Feb 23, 2013 8:46 PM, "Ted Lemon" wrote: > On Feb 23, 2013, at 1:39 PM, Teemu Savolainen > wrote: > > Good points, those clarify. Might be good idea to write I-D about:) > > You offering? :) > > > --e89a8f642c14f24d2f04d669eed3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I'll leave it for those whose idea this was:-)

(And it lacks the IPv6-only aspect)

On Feb 23, 2013 8:46 PM, "Ted Lemon" &= lt;mellon@fugue.com> wrote:
On Feb 23, 2013, at 1:39 PM, Teemu Savolainen <tsavo.stds@gmail.com> wrote:
> Good points, those clarify. Might be good idea to write I-D about:)
You offering? =A0 :)


--e89a8f642c14f24d2f04d669eed3-- From fred@cisco.com Sat Feb 23 14:24:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B044721F8AB6 for ; Sat, 23 Feb 2013 14:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.107 X-Spam-Level: X-Spam-Status: No, score=-110.107 tagged_above=-999 required=5 tests=[AWL=-0.108, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbw1XNsnoHcu for ; Sat, 23 Feb 2013 14:24:25 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F28C621F89A3 for ; Sat, 23 Feb 2013 14:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2217; q=dns/txt; s=iport; t=1361658265; x=1362867865; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mLmDx7l6ki+hlcgHaBOqWUnSvFM6ChsEF0fOCJ9F+Zs=; b=Rs8HWnfzdxKiup8qd1A5tIoIUyWAb72c61n8VwU+DS8ST9NrAdpE4VoX oNo8O2r2YbKgQk0g1/pV0VrEKlCcA7+oesDCIRJg70J7rtE5Gne2Yn8Lw aMjrTzqBErdkn3Ha7NfpicReGr3eHwZF0b34H7OupiNPmvaQFJr+hdqpS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADlBKVGtJV2Y/2dsb2JhbABFwVGBCRZzgh8BAQEDATo/BQsCAQgYChQQMiUCBA4FCAyHeQa/CI5bAjEHgl9hA5wDix+DB4In X-IronPort-AV: E=Sophos;i="4.84,724,1355097600"; d="scan'208";a="180436495" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 23 Feb 2013 22:24:24 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1NMOOCL030456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Feb 2013 22:24:24 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Sat, 23 Feb 2013 16:24:24 -0600 From: "Fred Baker (fred)" To: james woodyatt Thread-Topic: [homenet] automatic prefix management (OSPF or ISIS version) Thread-Index: AQHOEhSH30J56WOVp0yJhNejzw7Pcw== Date: Sat, 23 Feb 2013 22:24:23 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> In-Reply-To: <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 22:24:25 -0000 On Feb 22, 2013, at 1:11 PM, james woodyatt wrote: > On Feb 22, 2013, at 06:16 , Michael Richardson wr= ote: >>=20 >> If the ISP with the longest prefix is alive first, then the routers=20 >> pick subnet-id parts that fit into that. If that ISP has provided >> enough subnets, then even when another ISP comes along, the "xx23" >> part might remain stable for a long time. >=20 > This problem is precisely why I campaigned bitterly and vigorously agains= t the adoption and V6OPS and later the publication of RFC 6177. >=20 > When there was still a consensus that subscribers should always get a /48= prefix, it was reasonable to expect that a randomly chosen 16-bit subnet i= dentifier would be unlikely to collide with another subnet in most automati= cally numbered routing domains. We were also in a position to expect that = when a subscriber adds a new prefix from the same or a different provider, = that all the subnet identifiers in use on one prefix could be mapped 1:1 in= to the new prefix. Now we have RFC 6177, which explodes all of that, for b= asically no sensible reason that I can see, and we are all the poorer for i= t. >=20 > Well done, V6OPS, well done. Two thoughts. One: the v6ops result reflects the operational result in the ARIN community= : operators there would like to be able to allocate /56 prefixes to smaller= customers and /48s to larger ones. If you want castigate someone, castigat= e them. Two: If randomization within the home is the issue, I'm not sure the differ= ence between a /48 and a /56 is all that significant. We're discussing the = ability to pick a half dozen at best out of a much larger field, and arguin= g against operators that can't see a reason for anything shorter than a /64= . You've heard me argue before that prefix length should be an attribute of= the service one purchases, much as capacity is: in the home, I suspect tha= t a /60 would suffice for the vast majority of purposes, and I can imagine = companies that would not be happy with a /56 but might be happy with a /52.= I don't see a technical argument that everyone has to have precisely a /48= .= From mellon@fugue.com Sat Feb 23 15:26:44 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DA721F8713 for ; Sat, 23 Feb 2013 15:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hz0x4s19Uq+C for ; Sat, 23 Feb 2013 15:26:44 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 19AFE21F86BC for ; Sat, 23 Feb 2013 15:26:44 -0800 (PST) Received: from [10.0.1.24] (unknown [64.215.212.135]) by toccata.fugue.com (Postfix) with ESMTPSA id 3A0B123801AA; Sat, 23 Feb 2013 18:26:43 -0500 (EST) References: <512902cc.8632700a.0347.5c46@mx.google.com> <5129041C.2090106@thekelleys.org.uk> <5F0C8E4D-3E54-42C6-BD86-43965CD49BC6@fugue.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <357A947D-9032-4255-87FB-77DC34BAF8DE@fugue.com> X-Mailer: iPad Mail (10B141) From: Ted Lemon Date: Sat, 23 Feb 2013 18:26:41 -0500 To: Teemu Savolainen Cc: Simon Kelley , "homenet@ietf.org" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 23:26:44 -0000 On Feb 23, 2013, at 3:12 PM, Teemu Savolainen wrote: > I'll leave it for those whose idea this was:-) If you insist. However, that assumes that they will write a document, whic= h isn't always a safe assumption. From dave.taht@gmail.com Sat Feb 23 15:39:03 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DDC21F8498 for ; Sat, 23 Feb 2013 15:39:03 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDw1CICtAdc2 for ; Sat, 23 Feb 2013 15:38:56 -0800 (PST) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D20ED21F848A for ; Sat, 23 Feb 2013 15:38:56 -0800 (PST) Received: by mail-ia0-f171.google.com with SMTP id z13so1549699iaz.16 for ; Sat, 23 Feb 2013 15:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MBypvvZeagTVBCN4fg++yiPy4mUZxZTvI575et3U4r4=; b=xnnGSs1YD+FSqQCnFy6wY9tqotTKa0yJAsVAjLn0L6K9UhMWQVS0YkI2bxFMqdLd8M 74UzUy3rMj2ugOVrWcIjIg1Ka9DWxwceCiC5FXzSplXLQVDqZQtC3DwAioLuhieTvnnk q2vzjYO+Sl1SkOoz9AZTOOLZ0Y7oROTbrAdvlHQRiOvMWUBYsUvq8kZObtUbomYVIDiZ 9csR09MT7SZBQADyEhzlTYnDE2zUnkL6QXRULtQTnuVFhm6MpUyadAa7x/HB8NeyYy+Z kUQmb6PcQ+q5mNaidkqmsgeia3sgGvCWOSST+IwR9XjiiFcm466IFx7pQ46EuEeRQgHH jEkg== MIME-Version: 1.0 X-Received: by 10.50.236.100 with SMTP id ut4mr1311677igc.86.1361662736466; Sat, 23 Feb 2013 15:38:56 -0800 (PST) Received: by 10.64.77.1 with HTTP; Sat, 23 Feb 2013 15:38:56 -0800 (PST) In-Reply-To: <357A947D-9032-4255-87FB-77DC34BAF8DE@fugue.com> References: <512902cc.8632700a.0347.5c46@mx.google.com> <5129041C.2090106@thekelleys.org.uk> <5F0C8E4D-3E54-42C6-BD86-43965CD49BC6@fugue.com> <357A947D-9032-4255-87FB-77DC34BAF8DE@fugue.com> Date: Sat, 23 Feb 2013 15:38:56 -0800 Message-ID: From: Dave Taht To: Ted Lemon Content-Type: multipart/alternative; boundary=14dae9399de3b6096004d66ccf07 Cc: Evan Hunt , Simon Kelley , "homenet@ietf.org" , Teemu Savolainen , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 23:39:03 -0000 --14dae9399de3b6096004d66ccf07 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Feb 23, 2013 at 3:26 PM, Ted Lemon wrote: > On Feb 23, 2013, at 3:12 PM, Teemu Savolainen > wrote: > > I'll leave it for those whose idea this was:-) > > If you insist. However, that assumes that they will write a document, > which isn't always a safe assumption. > I am a big believer in running code and rough consensus. We seem to have both at the moment... As one of the inventors of the dhcpv4 to SLAAC naming technique (with evan hunt), I'm glad to hear this. However, someone else had come up with it independently and published it a few months prior to us, and we'd have to track that person down in order to write an ID. Simon Kelly took what we had in cerowrt, and improved it substantially, however there is still some stuff that is less than desirable, notably, the DNS TTL is presently set to 0 in the dnsmasq implementation, and I tend to think it should reflect the available lease time, or some larger number than 0, in order to do more effective caching. dnsmasq is now a full fledged replacement for radvd, and as it as insight into the lease time now, coming up with either a suggested minimum TTL or one based on the least seems like a good idea. Suggestions? Secondly, what ietf group would shepard the document? --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --14dae9399de3b6096004d66ccf07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 23, 2013 at 3:26 PM, Ted Lem= on <mellon@fugue.com> wrote:
On Feb 23, 2013, at 3:12 PM, Teemu Savolainen <tsavo.stds@gmail.com> wrote:
> I'll leave it for those whose idea this was:-)

If you insist. =A0 However, that assumes that they will write a docum= ent, which isn't always a safe assumption.

I a= m a big believer in running code and rough consensus.

We seem to hav= e both at the moment...

As one of the inventors of the dhcpv4 to SLAAC naming technique (with e= van hunt), I'm glad to hear this.

However, someone else had come= up with it independently and published it a few months prior to us, and we= 'd have to track that person down in order to write an ID.

Simon Kelly took what we had in cerowrt, and improved it substantially,= however there is still some stuff that is less than desirable, notably, th= e DNS TTL is presently set to 0 in the dnsmasq implementation, and I tend t= o think it should reflect the available lease time, or some larger number t= han 0, in order to do more effective caching.

dnsmasq is now a full fledged replacement for radvd, and as it as insig= ht into the lease time now, coming up with either a suggested minimum TTL o= r one based on the least seems like a good idea. Suggestions?

Second= ly, what ietf group would shepard the document?

--
Dave T=E4ht

Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html=20 --14dae9399de3b6096004d66ccf07-- From dave.taht@gmail.com Sat Feb 23 15:41:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793F521F8EAD for ; Sat, 23 Feb 2013 15:41:20 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlJKu-Po1dIq for ; Sat, 23 Feb 2013 15:41:14 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4A76621F84AF for ; Sat, 23 Feb 2013 15:41:14 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id bn7so2048092ieb.11 for ; Sat, 23 Feb 2013 15:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+C615VU+dI0KI3f71PeASltT1wwWIiVpgNA7tpYKOZc=; b=mMdUMHCzS9nIdCc/bku54Ls6Iso3IKPMuGwMHbP3DcRHqfIj038MH4Yb96VYdvWszk tI+UqH+mwIwTT7Aba/OBuA4pQ5C9dZQBcEpF3ZeMjrwCLT29xjjzFw8jWtRTtkGSr/rq 4yLU7SuwwvrkANbOmQTRDznu0FLYVs0SC/YUUDNrsszI1BQ+P53BCsd3LKpC5GsVdULg 0MtsrtkvGO5SjuXJ5LhxvGxeZyJZk5ulic7/0pVegqmfWE00BLIyRQSIDA5oilfSP8tp V0aOWoLYwpGVMd9sb6IF6vBBtmr4aUdCr/0EomJiliAiwEKhT23VVBhkdd+SowTTjXoo VIcQ== MIME-Version: 1.0 X-Received: by 10.50.106.199 with SMTP id gw7mr1380612igb.27.1361662873906; Sat, 23 Feb 2013 15:41:13 -0800 (PST) Received: by 10.64.77.1 with HTTP; Sat, 23 Feb 2013 15:41:13 -0800 (PST) In-Reply-To: References: <512902cc.8632700a.0347.5c46@mx.google.com> <5129041C.2090106@thekelleys.org.uk> <5F0C8E4D-3E54-42C6-BD86-43965CD49BC6@fugue.com> <357A947D-9032-4255-87FB-77DC34BAF8DE@fugue.com> Date: Sat, 23 Feb 2013 15:41:13 -0800 Message-ID: From: Dave Taht To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8f234d6de766db04d66cd7a2 Cc: Evan Hunt , Simon Kelley , "homenet@ietf.org" , Teemu Savolainen , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 23:41:20 -0000 --e89a8f234d6de766db04d66cd7a2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Feb 23, 2013 at 3:38 PM, Dave Taht wrote: > > dnsmasq is now a full fledged replacement for radvd, and as it as insight > into the lease time now, coming up with either a suggested minimum TTL or > one based on the least seems like a good idea. Suggestions? > Grumble. Remind me not to try to write important stuff on my phone. dnsmasq is now a full fledged replacement for radvd, and as it nas insight into the lease time now, coming up with either a suggested minimum TTL or one based on the current value of the lease seems like a good idea. Suggestions? > > Secondly, what ietf group would shepard the document? > > -- > Dave T=E4ht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --e89a8f234d6de766db04d66cd7a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 23, 2013 at 3:38 PM, Dave Ta= ht <dave.taht@gmail.com> wrote:

dnsmasq is now a full fledged replaceme= nt for radvd, and as it as insight into the lease time now, coming up with = either a suggested minimum TTL or one based on the least seems like a good = idea. Suggestions?

Grumble. Remind me not to try to write im= portant stuff on my phone.

dnsmasq is now a full fledged replacement for radvd, and as it nas insight into=20 the lease time now, coming up with either a suggested minimum TTL or one based on the current value of the lease seems like a good idea. Suggestion= s?


=A0

Secondly, what ietf group would shepard the document?

--
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.t= eklibre.com/cerowrt/subscribe.html=20



--
Dave T=E4= ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowr= t/subscribe.html=20 --e89a8f234d6de766db04d66cd7a2-- From john_brzozowski@cable.comcast.com Sat Feb 23 15:55:24 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5A521F8DDC for ; Sat, 23 Feb 2013 15:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.579 X-Spam-Level: X-Spam-Status: No, score=-104.579 tagged_above=-999 required=5 tests=[AWL=0.652, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fxor52h0Azg7 for ; Sat, 23 Feb 2013 15:55:24 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0E021F8BA6 for ; Sat, 23 Feb 2013 15:55:24 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57752461; Sat, 23 Feb 2013 16:24:06 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Sat, 23 Feb 2013 18:54:27 -0500 From: "Brzozowski, John" To: Ted Lemon , Michael Thomas Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHOEE56UKHjmYjHJk2z+mbkmocqx5iF9qyZgAIq7QA= Date: Sat, 23 Feb 2013 23:54:26 +0000 Message-ID: In-Reply-To: <85516831-01F4-41CA-93DF-2959DD65712F@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <3FC1C931E05057458113CD91490AA059@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 23:55:24 -0000 -----Original Message----- From: Ted Lemon Date: Friday, February 22, 2013 6:48 AM To: Michael Thomas Cc: Lorenzo Colitti , Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , John Jason Brzozowski , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] Running code in Orlando >On Feb 21, 2013, at 8:34 PM, Michael Thomas wrote: >> Sigh all you like, but I share Dave's skepticism that ISP's renumbering >>my prefix >> willy-nilly and it just sort of works with naming -- including >>addresses squirrelled >> away in places they ought not be -- is going to work any time soon. I >>don't like to >> think that NAT is inevitable but frankly the people in this working >>group don't get >> to vote on that. > >It's probably also worth mentioning that in general ISPs that do this on >a regular basis are attacking their customer's network, and the resulting >instability is not the result of a failing on our part, but deliberate >action on the part of the ISP. [jjmb] not sure I would say renumbering is attacking, it may be referred to as running a network. FWIW this happens today with IPv4. > >There are countries where ISPs are required by law to _offer_ a change of >address every 24 hours for privacy purposes. At least in the cases I'm >aware of, ISPs don't _force_ this on their customers, but rather it's a >configuration option paranoid customers can choose, which may default to >on. This is an inconvenience to ISPs, because it causes address pool >churn, and requires a lot of extra bits to be allocated to PE devices to >accommodate all the deprecated addresses. [jjmb] first I have heard of this, interesting. > >Pretty much by definition, if you want to access your washing machine >while away from home, you're throwing that particular sort of privacy >right out the window. It wasn't buying you much anyway--fuzzing the >prefix by a few bits is very easy to reverse, and because of routing >hierarchies, IPv6 prefixes can't be assigned to the customer out of the >ISP's entire address space--by definition they will be restricted to >localities. > >The other use case for frequent renumbering is an ISP who wants to >prevent the customer from setting up servers. The washing machine is a >server. Either the ISP succeeds, or fails, but in either case, they are >acting directly against the customer's wishes. [jjmb] are a customer is violating their usage agreement with the ISP. >We can try to design a system that's robust with respect to attacks like >this, but in practice the best way to address this problem is to prevent >it happening on a regular basis to people who will care about it. From john_brzozowski@cable.comcast.com Sat Feb 23 15:59:21 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31D621F8E50 for ; Sat, 23 Feb 2013 15:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.528 X-Spam-Level: X-Spam-Status: No, score=-104.528 tagged_above=-999 required=5 tests=[AWL=0.703, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSx+60xVnjjT for ; Sat, 23 Feb 2013 15:59:21 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2006621F874A for ; Sat, 23 Feb 2013 15:59:21 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57752692; Sat, 23 Feb 2013 16:28:07 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Sat, 23 Feb 2013 18:58:29 -0500 From: "Brzozowski, John" To: Michael Thomas , Ted Lemon Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHOEE56UKHjmYjHJk2z+mbkmocqx5iF9qyZgABhrwCAAcpeAA== Date: Sat, 23 Feb 2013 23:58:27 +0000 Message-ID: In-Reply-To: <512790D0.8000006@mtcc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 23:59:21 -0000 I do not think the issue here is privacy or lack of interest in the same. It is ensuring capacity is managed appropriately. Further, allocating static blocks to everyone has an entirely different set of impacts that go much deeper in the network beyond the home. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Michael Thomas Date: Friday, February 22, 2013 7:37 AM To: Ted Lemon Cc: Lorenzo Colitti , Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , John Jason Brzozowski , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] Running code in Orlando >Ted Lemon wrote: >> On Feb 21, 2013, at 8:34 PM, Michael Thomas wrote: >>> Sigh all you like, but I share Dave's skepticism that ISP's >>>renumbering my prefix >>> willy-nilly and it just sort of works with naming -- including >>>addresses squirrelled >>> away in places they ought not be -- is going to work any time soon. I >>>don't like to >>> think that NAT is inevitable but frankly the people in this working >>>group don't get >>> to vote on that. >>=20 >> It's probably also worth mentioning that in general ISPs that do this >>on a regular basis are attacking their customer's network, and the >>resulting instability is not the result of a failing on our part, but >>deliberate action on the part of the ISP. >>=20 >> There are countries where ISPs are required by law to _offer_ a change >>of address every 24 hours for privacy purposes. At least in the cases >>I'm aware of, ISPs don't _force_ this on their customers, but rather >>it's a configuration option paranoid customers can choose, which may >>default to on. This is an inconvenience to ISPs, because it causes >>address pool churn, and requires a lot of extra bits to be allocated to >>PE devices to accommodate all the deprecated addresses. >>=20 >> Pretty much by definition, if you want to access your washing machine >>while away from home, you're throwing that particular sort of privacy >>right out the window. It wasn't buying you much anyway--fuzzing the >>prefix by a few bits is very easy to reverse, and because of routing >>hierarchies, IPv6 prefixes can't be assigned to the customer out of the >>ISP's entire address space--by definition they will be restricted to >>localities. >>=20 >> The other use case for frequent renumbering is an ISP who wants to >>prevent the customer from setting up servers. The washing machine is a >>server. Either the ISP succeeds, or fails, but in either case, they >>are acting directly against the customer's wishes. We can try to >>design a system that's robust with respect to attacks like this, but in >>practice the best way to address this problem is to prevent it happening >>on a regular basis to people who will care about it. > >Is there any way to convince the powers that be that v6 address privacy >is a better/acceptable solution than >prefix-based privacy? Is there really anything that needs to be done for >v6 on that account other than just >switching on the, oh say, laptop? > >Mike From mike@mtcc.com Sat Feb 23 16:04:19 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6581C21F8E50 for ; Sat, 23 Feb 2013 16:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeHhQDQmeDfu for ; Sat, 23 Feb 2013 16:04:18 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9C021F8BA6 for ; Sat, 23 Feb 2013 16:04:18 -0800 (PST) Received: from piolinux.mtcc.com (63-171-70-46.dsl.volcano.net [63.171.70.46] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1O03RLk002815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Feb 2013 16:03:28 -0800 Message-ID: <512958CB.8000603@mtcc.com> Date: Sat, 23 Feb 2013 16:03:23 -0800 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: "Brzozowski, John" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=754; t=1361664210; x=1362528210; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Servers=20in=20the=20home=20are=20not=20a=20cri me |Sender:=20 |To:=20=22Brzozowski,=20John=22=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=IWTM+V9QDPgDEGe+DDbtlUz2jlTI2sEjcee74xIamBM=; b=AVv1nSMmlZ7iFSC+r2HIQ205uZATUtVP++Ty1/lLM5T0Qkb5V2kbX31DqE Uy4CyUI5O/vgznyLJCG+8Fn8iWKsWi+C3Cf1FLKLteNsSIboy+3mRPuXsY3u kOnKLXJXMqvKf1d8ysHNesvv6NMSwxOZVHsSB6nZtu9ymE6oxh1V8=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , Ted Lemon , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: [homenet] Servers in the home are not a crime X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 00:04:19 -0000 Brzozowski, John wrote: >> The other use case for frequent renumbering is an ISP who wants to >> prevent the customer from setting up servers. The washing machine is a >> server. Either the ISP succeeds, or fails, but in either case, they are >> acting directly against the customer's wishes. > [jjmb] are a customer is violating their usage agreement with the ISP. Is there any way this working group can make a statement that my washing machine, home cameras, DVR, hot tub, thermostat, and light sockets, etc, etc, etc are not TOS-worth scofflaws, and that ISP should come up with some 21st century way of describing abusive behaviour for their customers rather than relying on detection of the heinous crime of listen(2)? Mike From john_brzozowski@cable.comcast.com Sat Feb 23 16:04:41 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AE021F8EDA for ; Sat, 23 Feb 2013 16:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.567 X-Spam-Level: X-Spam-Status: No, score=-104.567 tagged_above=-999 required=5 tests=[AWL=0.664, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zculMBUUjsjt for ; Sat, 23 Feb 2013 16:04:41 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDAC21F8ED5 for ; Sat, 23 Feb 2013 16:04:41 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57753008; Sat, 23 Feb 2013 16:33:20 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Sat, 23 Feb 2013 19:03:43 -0500 From: "Brzozowski, John" To: Michael Thomas Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHOEE56UKHjmYjHJk2z+mbkmocqx5iFEUPtgABba4CAAAPjAIAAAnsAgABntYCAAH68gIAByrUA Date: Sun, 24 Feb 2013 00:03:42 +0000 Message-ID: In-Reply-To: <512791C3.20006@mtcc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <8EC29E4C1A6F7F458C1BC2C4F4EFA021@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 00:04:42 -0000 -----Original Message----- From: Michael Thomas Date: Friday, February 22, 2013 7:41 AM To: John Jason Brzozowski Cc: Lorenzo Colitti , Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] Running code in Orlando >Brzozowski, John wrote: >>>> general? >>> Yes, along with naming, security, prefix delegation across multiple >>> routers, and isp's >>> giving and withdrawing prefixes due to renumbering. I'm dubious that >>>this >>> has happened >>> in real life with networks with people whose day job is to worry about >>> such things, and >>> I'd be astonished to hear such a thing has been shown to work on a home >>> network. >> [jjmb] hmmm we have quite a few real customers that are using IPv6 >>enabled >> on a daily basis mostly using technology that we specified ~8 years ago. >> Does this count? > >Not really because my understanding is that these networks are giving a >service >that is pretty much the same as their v4 counterpart which is completely >client >centric.=20 [jjmb] I disagree it counts, sorry. When you say client centric you mean clients accessing the Internet not accessing the home from the Internet? >I seriously want globally accessible servers on my home network to be >1st class citizens and that implies naming and security/admission control. >The future is now: a Raspberry Pi is $35. Tomorrow, we'll be getting >gratuitous IP-enabled >controllers on everything whether we want them or not just like when >digital controls >replaced analog. > >Mike From john_brzozowski@cable.comcast.com Sat Feb 23 16:07:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042D021F8EDA for ; Sat, 23 Feb 2013 16:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.602 X-Spam-Level: X-Spam-Status: No, score=-104.602 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNy3mHBaUu6w for ; Sat, 23 Feb 2013 16:07:01 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 0415021F8EAD for ; Sat, 23 Feb 2013 16:07:00 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57753099; Sat, 23 Feb 2013 16:35:47 -0700 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by PACDCEXHUB02.cable.comcast.com (24.40.56.115) with Microsoft SMTP Server (TLS) id 14.2.318.1; Sat, 23 Feb 2013 19:06:08 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Sat, 23 Feb 2013 19:06:08 -0500 From: "Brzozowski, John" To: Mark Townsley Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHOEE56UKHjmYjHJk2z+mbkmocqx5iE1hGA//+AAwCAAiAOgIABrruA Date: Sun, 24 Feb 2013 00:06:07 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <088B4A2755C1524C814D01EC40496F68@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 00:07:05 -0000 Mark you can always reach out to me. I can help make sure the correct technical requirements are outlined. I also have been working closely on BnB so there may be some overlap we can help avoid. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Mark Townsley Date: Friday, February 22, 2013 9:24 AM To: John Jason Brzozowski Cc: Dave Taht , Michael Richardson , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando >=20 >On Feb 21, 2013, at 5:57 PM, Brzozowski, John wrote: > >> Since BnB is one night can we make provisions for the home net lab area >>to >> be open all week? Mark? Ray? > >Let's give it a shot! > >But... the chairs can only make the request. Allocating IETF space is >something only the ADs are authorized to do. In Atlanta, I asked for >space and was turned down (citing too short notice, specs not mature >enough, etc.). IPSO graciously gave us some squatting room, but we were >not able to get what we needed from the IETF NOC in that particular >location. So, while good work was done, it came with support headaches >(e.g., ISP uplinks were simulated via tunnels sourced from a router than >joined the IETF network like any other wireless host). > >> Seems like it would be worth it. I am thinking all week would be ideal. >> ;) > >I think that's a necessity. The request I sent in January to the list >included: "Note that this isn't for 'showcasing', but for working... so >be expected to configure, reconfigure, and change code on the fly >accordingly." I think that is very important, and in order for that to >happen, we need more than a couple of hours here or there. > >What I am hearing is that we currently have requests to provide workspace >for: > >1. draft-grundemann-homenet-hipnet-00 >2. perhaps CeroWRT? >3. perhaps draft-arkko-homenet-prefix-assignment and >draft-ietf-ospf-ospfv3-autoconfig again? > >Last time, we were asked from the ADs things like: > >- How many implementations existed and how many would be present on site >to test.=20 >- What drafts or RFCs would be tested >- How much space, and for how long >- Power and network requirements >etc... > >John B, Dave T, are the two of you the right folks for us to work offline >with in order to try and put together the right ask? > >Thanks, > >- Mark > > >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> John Jason Brzozowski >> Comcast Cable >> m) 484-962-0060 >> e) john_brzozowski@cable.comcast.com >> o) 609-377-6594 >> w) www.comcast6.net >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Dave Taht >> Date: Thursday, February 21, 2013 9:35 AM >> To: John Jason Brzozowski >> Cc: David Lamparter , Michael Richardson >> , "homenet@ietf.org Group" , >>Mark >> Townsley , Jari Arkko , Lorenzo >> Colitti >> Subject: Re: [homenet] Running code in Orlando >>=20 >>>=20 >>>=20 >>>=20 >>> I am primarily focused on demonstrating solutions to bufferbloat in my >>> portion of bit's and bytes. >>>=20 >>> But I note that the present CeroWrt build appears to have working >>>dhcp-pd >>> (I've successfully got /56 /60, /61/ /62 subnets from it), and >>>assigning >>> that to the 6+ internal interfaces, support for every other form of >>>ipv6 >>> tunneling, the latest dnsmasq which has >>> some good ways of bonding dns names to ipv6 AAAAs, support for routing >>> ipv4 and ipv6 subnetworks over the quagga babel protocol (the two >>>routers >>> I'm demoing are meshed together at 5ghz) >>>=20 >>> We had to fix a few nasty instruction traps in the ipv6 stack last >>>month, >>> but after doing that, I'm pretty pleased with the over-all performance >>> and reliability - it survived the "thc" ipv6 tests handily, for >>>example. >>> Could use some more exaustive real-world >>> testing, so, get it (for the wndr3700v2 and 3800 series) >>>=20 >>> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.5-2/ >>>=20 >>> We also have specialized builds for the ubiquity nanostation m5 and >>> picostation m2hp products deployed in the campground testbed. >>>=20 >>> We still haven't done anything with distributing prefixes inside the >>>home >>> beside ahcp, and I still find the dynamicism required by renting ipv6 >>> addresses to so impact in so many aspects of the "sane usage of stuff >>> like printers", and naming, and the security >>> model as to *demand* ipv6 nat in the home... but I did not get around >>>to >>> implementing npt66 in this release!! >>>=20 >>>=20 >>> (so those that would flame me for this opinion can hold off (pretty >>> please!?) until perhaps I can go into the implementation details of all >>> the many things that break today... with those that care. ) >>>=20 >>> In terms of interop, besides dhcp-pd and bufferbloat fixes, I'd rather >>> like to see if these release can be made to work with ospfv6 on other >>> devices. What else will be shown? The original homenet code was far too >>> large to be usable on such a small device, but >>> perhaps at least the ospf layer could be tried. >>>=20 >>> And all that said, I'm rather totally buried with tests for, >>>processing a >>> ton of data from the field, and testing nfq_codel/bufferbloat. I just >>> finished giving talks on that at MIT and Stanford on that stuff >>>=20 >>> What's wrong with wifi? >>>=20 >>> http://www.youtube.com/watch?v=3DWksh2DPHCDI&feature=3Dyoutu.be >>>=20 >>> Intro to codel and fq_codel: >>>=20 >>> http://netseminar.stanford.edu/ >>>=20 >>>=20 >>>=20 >>> On Thu, Feb 21, 2013 at 8:14 AM, Brzozowski, John >>> wrote: >>>=20 >>> Statically assigning prefixes may enable testing but is not how homes >>>will >>> be provisioned in reality. >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> John Jason Brzozowski >>> Comcast Cable >>> m) 484-962-0060 >>> e) john_brzozowski@cable.comcast.com >>> o) 609-377-6594 >>> w) www.comcast6.net >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>>=20 >>> From: David Lamparter >>> Date: Wednesday, February 20, 2013 9:41 PM >>> To: John Jason Brzozowski >>> Cc: David Lamparter , Lorenzo Colitti >>>=20 >>> , Michael Richardson >> >, >>> "homenet@ietf.org Group" , Jari Arkko >>> , Mark Townsley >>> Subject: Re: [homenet] Running code in Orlando >>>=20 >>>=20 >>>> On Thu, Feb 21, 2013 at 04:17:06AM +0000, Brzozowski, John wrote: >>>>> David Lamparter wrote: >>>>>> On Thu, Feb 21, 2013 at 12:40:25PM +0900, Lorenzo Colitti wrote: >>>>>>> On Thu, Feb 21, 2013 at 12:16 PM, Michael Richardson >>>>>>> >wrote: >>>>>>>=20 >>>>>>>> Would/could another foot of such a network be on the IETF network? >>>>>>>>=20 >>>>>>>=20 >>>>>>> If the IETF network didn't respond to DHCPv6 PD requests, it >>>>> wouldn't be >>>>>>> much use. >>>>>>=20 >>>>>> Even without DHCPv6 PD on the remainder of the IETF network, it >>>>>>might >>>>> be >>>>>> possible to get a /52../56 and run a DHCPv6 PD ourselves, emulating >>>>> part >>>>>> of the provider network. >>>>>=20 >>>>> Why emulate it? Is the intention here to test the the code on an >>>>> enterprise or corporate network? >>>>=20 >>>> The scope of the plugfest is the interior and border of the homenet. >>>>To >>>> get the border right, we need the service provider side of that border >>>> in some form. If the IETF network runs DHCPv6-PD, that is an usable >>>> approximation. >>>>=20 >>>> My suggestion was for the case that the IETF network won't be running >>>> DHCPv6-PD. In that case, the easiest way to make the IETF network >>>> usable as one uplink for the homenet plugfest is to ask for a /52 to >>>>be >>>> made available for the plugfest in some static way and then provide >>>> DHCPv6-PD from that, running on some random PC box/laptop somewhere. >>>>=20 >>>> Actually - controlling the DHCPv6-PD might be advantageous in order to >>>> allow tinkering with it to see how the testbed reacts. >>>>=20 >>>>=20 >>>> -David >>>=20 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Dave T=E4ht >>>=20 >>> Fixing bufferbloat with cerowrt: >>> http://www.teklibre.com/cerowrt/subscribe.html >>> >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > From mellon@fugue.com Sat Feb 23 16:18:04 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBA021F84BD for ; Sat, 23 Feb 2013 16:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwcWkS408mgm for ; Sat, 23 Feb 2013 16:18:03 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A1F5021F84B3 for ; Sat, 23 Feb 2013 16:18:03 -0800 (PST) Received: from [10.0.1.24] (unknown [64.215.212.135]) by toccata.fugue.com (Postfix) with ESMTPSA id C880E23801AA; Sat, 23 Feb 2013 19:18:02 -0500 (EST) References: <512902cc.8632700a.0347.5c46@mx.google.com> <5129041C.2090106@thekelleys.org.uk> <5F0C8E4D-3E54-42C6-BD86-43965CD49BC6@fugue.com> <357A947D-9032-4255-87FB-77DC34BAF8DE@fugue.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4FD57AD4-AAAE-40F9-8C07-DD91319E3FDE@fugue.com> X-Mailer: iPad Mail (10B141) From: Ted Lemon Date: Sat, 23 Feb 2013 19:18:01 -0500 To: Dave Taht Cc: Evan Hunt , Simon Kelley , "homenet@ietf.org" , Teemu Savolainen , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 00:18:04 -0000 On Feb 23, 2013, at 6:41 PM, Dave Taht wrote: > dnsmasq is now a full fledged replacement for radvd, and as it nas insight= into the lease time now, coming up with either a suggested minimum TTL or o= ne based on the current value of the lease seems like a good idea. Suggestio= ns? The lease time is something configured on the gateway. It's not really rel= ated to the TTL, since the expectation is that the device will renew over an= d over, even if the lease time is short. And if the device moves to a diff= erent location, it probably won't be able to register the same name, so a st= ale record won't be a major problem. Personally I'd use a value of 3600; it doesn't give you a ton of caching, bu= t that doesn't matter for a name that is almost never looked up by anyone. = Caching google.com is really important. Caching washing-machine.brattlegr= ad.fugue.com, not so much. As for the document, if it's worth documenting, it's worth someone writing t= he document. If you want the person who first suggested it to you to get c= redit, mention them in the acknowledges and wax poetic about the greatness o= f their contribution. If you want to make sure that the work gets document= ed, write the document if they won't.= From mellon@fugue.com Sat Feb 23 17:31:44 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D889E21F8F5B for ; Sat, 23 Feb 2013 17:31:44 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rey6HyDB5m0s for ; Sat, 23 Feb 2013 17:31:44 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0C21F8F4A for ; Sat, 23 Feb 2013 17:31:44 -0800 (PST) Received: from kali-9.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id 58D1823801AA; Sat, 23 Feb 2013 20:31:42 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: Date: Sat, 23 Feb 2013 20:31:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Brzozowski, John" X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 01:31:45 -0000 On Feb 23, 2013, at 6:58 PM, "Brzozowski, John" = wrote: > I do not think the issue here is privacy or lack of interest in the = same. > It is ensuring capacity is managed appropriately. Further, allocating > static blocks to everyone has an entirely different set of impacts = that go > much deeper in the network beyond the home. To be clear, what I was talking about is a policy of deliberately = renumbering the customer in the absence of any operational need to do = so, other than a misguided attempt to enforce a contract clause that = some might describe as unconscionable. I happen to know that your = company doesn't do any such thing, because I'm a customer, but I have = heard of small ISPs doing this sort of thing with IPv4. I think the IPv6 architecture is quite robust in the face of such = behavior, certainly in comparison to IPv4. But the point is that if = this sort of behavior on the part of the ISP introduces some hiccups in = the performance of the homenet, this is par for the course. From simon@thekelleys.org.uk Sun Feb 24 01:48:34 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED30521F9002 for ; Sun, 24 Feb 2013 01:48:33 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SBjggsnGl36 for ; Sun, 24 Feb 2013 01:48:33 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABA221F9001 for ; Sun, 24 Feb 2013 01:48:33 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:34567 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U9YC8-0003zE-8X for homenet@ietf.org; Sun, 24 Feb 2013 09:48:32 +0000 Received: from host81-149-103-178.in-addr.btopenworld.com ([81.149.103.178] helo=[192.168.2.100]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1U9YC7-0005u2-FF for homenet@ietf.org; Sun, 24 Feb 2013 09:48:31 +0000 Message-ID: <5129E1E8.7040903@thekelleys.org.uk> Date: Sun, 24 Feb 2013 09:48:24 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <512902cc.8632700a.0347.5c46@mx.google.com> <5129041C.2090106@thekelleys.org.uk> <5F0C8E4D-3E54-42C6-BD86-43965CD49BC6@fugue.com> <357A947D-9032-4255-87FB-77DC34BAF8DE@fugue.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 09:48:34 -0000 On 23/02/13 23:38, Dave Taht wrote: > Simon Kelly took what we had in cerowrt, and improved it substantially, > however there is still some stuff that is less than desirable, notably, > the DNS TTL is presently set to 0 in the dnsmasq implementation This isn't quite accurate. Replies with cached data from forwarded queries of course get the TTL from upstream, reduced by the time the data has been cached. Replies with 0 TTL are answers to queries from internal hosts (ie from hosts on the local net) where the data in also local (ie stuff from /etc/hosts, other configuration or DHCP leases). The rationale is that re-doing the query is very cheap for these hosts, and there is no other good value for TTL. DHCP lease time is not a good value. My laptop can have a DHCP lease with days left to run on my wireless subnet: if I plug in the wired network port, the name will be transfered to the new lease on the wired subnet, and I don't want to wait for days for all the hosts on the net to catch up with the new address. For queries _not_ from the internal hosts (i.e. the new auth functionality) the TTL in the replies currently defaults to 600, and is configurable. These replies are only ever local data, dnsmasq will never forward-upstream queries from the wider net, to avoid DNS amplification attacks. Simon. From Ray.Bellis@nominet.org.uk Sun Feb 24 04:24:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BDB21F8FCA for ; Sun, 24 Feb 2013 04:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klCmI-W4Mjpr for ; Sun, 24 Feb 2013 04:23:59 -0800 (PST) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 34A9821F8F6C for ; Sun, 24 Feb 2013 04:23:57 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: x-originating-ip:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version; b=rE/JIvk5uYpGpErY/5qovXZBt0EZl+GAka5n7F/+utP/KAN5KExypryp 1Ga8GADpZZRsoPmwVF8Bf15i37cKgEpKHepmDixO9pDqh5qkdBt2IZyHj FC3bG63pPSr+Lzb; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1361708639; x=1393244639; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20List=20administrivia|Date:=20Sun,=2024=20Feb =202013=2012:23:55=20+0000|Message-ID:=20<53F00E5CD8B2E34 C81C0C89EB0B4FE731055F30B@wds-exc1.okna.nominet.org.uk> |To:=20"homenet@ietf.org=20Group"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Content-ID:=20<908C3FE664731E409479E3D54ABC6D63 @okna.nominet.org.uk>; bh=gfjpd8hLWp00Xpo8gWE04WyTSpLTVuKteKZcaxGFcMc=; b=vPTWgHx/FRHQN3R5eI/0tyPA8yf+RRIW6OTpI1nhP1eq+kIoaXWfxWHI yLHtv9GJTbj316UX55NN4WimYvkqjWHwYNaUWYJERVM9gnnlxUyEJ9AtA Sly0hqyYCd3KAjf; X-IronPort-AV: E=Sophos;i="4.84,729,1355097600"; d="scan'208";a="38597492" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 24 Feb 2013 12:23:56 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Sun, 24 Feb 2013 12:23:56 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: List administrivia Thread-Index: AQHOEonQ3CrE4NgSDE+8c+BWwI0dhA== Date: Sun, 24 Feb 2013 12:23:55 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE731055F30B@wds-exc1.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <908C3FE664731E409479E3D54ABC6D63@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] List administrivia X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 12:24:00 -0000 Would WG participants _please_ trim the list of recipients when sending to = the list. I have a modest stack of messages that have been held by the list software = because they have too many recipients, and which I will now release. I shall not release any more after that. Ray From ek@google.com Fri Feb 22 21:53:22 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE4C21F8ABC for ; Fri, 22 Feb 2013 21:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad15+ArWPPqe for ; Fri, 22 Feb 2013 21:53:22 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id CC97021F89B9 for ; Fri, 22 Feb 2013 21:53:21 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id j6so1245417oag.22 for ; Fri, 22 Feb 2013 21:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=w8G3UlZ1WOExZJGgGoxBhHU6I1buO9lHCUxnAV0BghA=; b=jzsZbREB61tOmkU5h9MsQm8HTI7v/3gKzcYtLmw6vgZDPUg+q+9PT25WK4ghfV0o+D gGz4iv+ONmRyChIAlFCgQ079OBvreUG5ZWh1lgsMeJzgnD7Zgj0UP94KP+gvL8gADmZH XD6XKhWRghElUhqzbbEAP6MW59X8I45yv+wyyt5M3QviNGT9hidcUEXpcRNk6E2JW1mp DnenFsHO7BN1+wvkkAGcrJrQQAyMhECFHhTMtwMhP467ehGzOS+3PTNreUn8EDlUNuT4 mR+uWeX6dwmnPnn1RyFX+Nzp1e422VZPes/lgh7R83Rxcv5tdbt8C+PxkUe/WgAy5GiD L1Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=w8G3UlZ1WOExZJGgGoxBhHU6I1buO9lHCUxnAV0BghA=; b=J1OZ3HKjMqSfG3KTch6J1wIW1hpLOB9+HNrd4+3LdT9Jdmo9MgRzMv+FhVdzvUAAcP coNdiGUSBXadZm3hMg02Q1k0DNhviU/4FJAGJblkBRS8e02pmGgaiaFCCWeyWkC1mIt+ XohrjR2ZLnApza7CWx3Mux95wbcrGB5ontdthxCyV8F61R0jrcfvqjLzQBWKD2IVjFX2 ry67gT8D7c8npsX3lMxyIfcevK0LhloEtA9aav0TcPK2iuWdvMKqdJXHnuPP6QG/2Wrs 3Tzt5hSbhy1aApgIAIqwd3rsW5SwaQIS+dR1mDG75pJDsypcmwyxqSnKeDYCo5y8Jc+I qAdQ== X-Received: by 10.60.9.1 with SMTP id v1mr1733843oea.130.1361598800476; Fri, 22 Feb 2013 21:53:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.50.227 with HTTP; Fri, 22 Feb 2013 21:53:00 -0800 (PST) In-Reply-To: References: From: Erik Kline Date: Sat, 23 Feb 2013 14:53:00 +0900 Message-ID: To: Lorenzo Colitti , joel jaeggli , Brian E Carpenter Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlo6jw5U2rBwAY/v8rhiJaPZfK/R67KdpU3/9hXLmxkOuppoOjZ4O0p5IeNPbrK6s9aUaOasOiUkH+E/8HFoLv5G8X//WAW0/wkZBTQ1TgbamwgNIKDWiIR7wfxg9TFupd//BSEp4B5hfi7hsMK+zT3AqJj0rboT8kA2ArNyiDxGJbCNWubKHoigcFZblEwEpb+VZg+ X-Mailman-Approved-At: Sun, 24 Feb 2013 04:24:31 -0800 Cc: Michael Richardson , Michael Thomas , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 05:53:22 -0000 > I don't know about naming and security, but renumbering works using address > deprecation (that's been in the spec since forever), and since it's covered > by RFC6204 and there are conformance tests for it, devices with the > appropriate logo will support it. I wonder if we should ask the NOC about performing a renumbering during the next IETF meeting. Ideally, we should be able to perform one or two (or three) renumberings in a week, glean the relevant operational experience, and send a draft to v6ops shortly thereafter. Ideally... From brian.e.carpenter@gmail.com Sat Feb 23 00:27:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1689E21F8F4B for ; Sat, 23 Feb 2013 00:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.455 X-Spam-Level: X-Spam-Status: No, score=-99.455 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvLqbXYTU1V2 for ; Sat, 23 Feb 2013 00:27:25 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0266921F8F33 for ; Sat, 23 Feb 2013 00:27:24 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hm11so2963063wib.1 for ; Sat, 23 Feb 2013 00:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2ZoLGH/BadwL080ktQDzB2ZL6b/lOuDIMa7WSKiNTDA=; b=FpxZjwzkI/YLCzyHCaRv80pzqFbhFos1tuM+sq/1j+dpcO2exzgPCbVozz2muRW7U1 DDgkFEA0vldH94hRXY+3OCT/TdlxEJXJC7/tDq3RcBvsLJsDzwwZpRKz5LV5O7XqxUFB R+rFajMVvUoD6whgEXG6Oj2+Rbg41Xg6zlWMIf2skdwfS/NaNzmBagAM6DNdgWVyMVlk amYAPFqNkI2l59+tNNbJEFza3ofJRowWPeTOrEoKDEKKma6Rdq5k1BTyB07Cxto8hTyS fzukrvUT0CjN8V5jhtzoYWNGT1OT3dnoUqFzCuvs8DNGTHxmZfDP8tq0/zlFe4s7F+Md bY2Q== X-Received: by 10.180.82.231 with SMTP id l7mr1591943wiy.15.1361608044180; Sat, 23 Feb 2013 00:27:24 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-117.as13285.net. [2.102.216.117]) by mx.google.com with ESMTPS id bs6sm2695030wib.4.2013.02.23.00.27.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Feb 2013 00:27:23 -0800 (PST) Message-ID: <51287D7A.60300@gmail.com> Date: Sat, 23 Feb 2013 08:27:38 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Erik Kline References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 24 Feb 2013 04:24:32 -0800 Cc: Michael Richardson , Michael Thomas , Mark Townsley , Dave Taht , joel jaeggli , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: [homenet] renumbering the IETF X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 08:27:26 -0000 On 23/02/2013 05:53, Erik Kline wrote: .. > I wonder if we should ask the NOC about performing a renumbering > during the next IETF meeting. > > Ideally, we should be able to perform one or two (or three) > renumberings in a week, glean the relevant operational experience, and > send a draft to v6ops shortly thereafter. Great idea. I won't be in Orlando, but I am fairly sure there is nothing I would do there that cares about address persistency, apart from having to reconnect to jabber maybe. Conducting an RFC 4192 procedure on Tuesday night and a flash IPv6 renumbering during Thursday morning would be very interesting! At least Skype will not be a problem during IPv6 renumbering. Brian From mike@mtcc.com Sat Feb 23 05:42:43 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B19721F8489 for ; Sat, 23 Feb 2013 05:42:43 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHJs+jUZby-J for ; Sat, 23 Feb 2013 05:42:42 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 9230D21F8468 for ; Sat, 23 Feb 2013 05:42:42 -0800 (PST) Received: from piolinux.mtcc.com (63-171-70-46.dsl.volcano.net [63.171.70.46] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1NDfhSQ007966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Feb 2013 05:41:44 -0800 Message-ID: <5128C712.3020201@mtcc.com> Date: Sat, 23 Feb 2013 05:41:38 -0800 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Erik Kline References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=907; t=1361626906; x=1362490906; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20NPTv6-only=20home=20network s |Sender:=20 |To:=20Erik=20Kline=20 |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20forma t=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=yIBZhpsvnJrnpch3UeQBl7+xmvtnis/zU6tKtCLzEB8=; b=nq6al6E4tlOlhr3DphTKbfCPcMMieRqcd/w89lH9Rw407F6V0vV/MU8S+s O1HNjaB+3M029tGZXInNuqwKnIaPvz4tY6Hyc8fWssFmaYGazuIIPj97hZVc +6kQpYYmpgNGcymIV6AHhni0VLMfy5jJ/2aROkjj7njX+LNCgcO+M=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com X-Mailman-Approved-At: Sun, 24 Feb 2013 04:24:32 -0800 Cc: Michael Richardson , Mark Townsley , Dave Taht , joel jaeggli , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 13:42:43 -0000 Erik Kline wrote: >> I don't know about naming and security, but renumbering works using address >> deprecation (that's been in the spec since forever), and since it's covered >> by RFC6204 and there are conformance tests for it, devices with the >> appropriate logo will support it. > > I wonder if we should ask the NOC about performing a renumbering > during the next IETF meeting. > > Ideally, we should be able to perform one or two (or three) > renumberings in a week, glean the relevant operational experience, and > send a draft to v6ops shortly thereafter. > > Ideally... The only way that this would have relevance that is specific to the emerging v6 homenet is if there were servers being renumbered too, and how that affects global connectivity. If we're not planning for this, then we're ignoring one of the most important things that v6 homenets will provide. Mike From brian.e.carpenter@gmail.com Sat Feb 23 11:37:01 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15BC21F8F29 for ; Sat, 23 Feb 2013 11:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.825 X-Spam-Level: X-Spam-Status: No, score=-100.825 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naLzObqSFcMc for ; Sat, 23 Feb 2013 11:37:01 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id EFDB121F865D for ; Sat, 23 Feb 2013 11:37:00 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fm10so1439973wgb.9 for ; Sat, 23 Feb 2013 11:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/9uZVb439XQB/zAhpTO6QAAqJqbBnJEnMT4f3qrftTw=; b=ZOQLrKx8e5/kjxh+ukrIZchiJZbXvPNfAMEbVT25MEu9wPN9vE0MHQ6FYC0e5vSXOE PsSYtBRywMKLpGZZkCAZaCzm1u2jLkleOkBIgAunRRPLgb5GgTOFARVI8L0SxggyzES7 PjsGrlO1Ic5q4xI5vrhGsMoRrSRlOIhGfTRFLogTm3fULxcMCqny9gZ+Dzzake/Yhjny 9Llc5xdZmEpjn119DIJYufJ9sYUhQ6zW6Ulr5f9J10G8jhS8lCgpeT+wvN+Y+Qmeq782 73XkQkOGudttqtB1JzLXeIFSwq7g2waOFIZTJxT9H0aaAv0FPcP88GCBhnbGi6QXbMij J/aQ== X-Received: by 10.194.19.97 with SMTP id d1mr10342176wje.52.1361648220165; Sat, 23 Feb 2013 11:37:00 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-117.as13285.net. [2.102.216.117]) by mx.google.com with ESMTPS id bj9sm5273450wib.4.2013.02.23.11.36.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Feb 2013 11:36:58 -0800 (PST) Message-ID: <51291A69.8040407@gmail.com> Date: Sat, 23 Feb 2013 19:37:13 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian E Carpenter References: <51287D7A.60300@gmail.com> In-Reply-To: <51287D7A.60300@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 24 Feb 2013 04:24:32 -0800 Cc: Michael Richardson , Michael Thomas , Mark Townsley , Dave Taht , joel jaeggli , Jari Arkko , "Brzozowski, John" , Erik Kline , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] renumbering the IETF X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 19:37:01 -0000 Michael asked: > Given happy eyeballs, how will we measure the impact of a v6-only > renumbering? By a reduction in IPv6 traffic after the event? In any case, to some extent it's a pass/fail test (where "pass" = "no complaints"). Regards Brian On 23/02/2013 08:27, Brian E Carpenter wrote: > On 23/02/2013 05:53, Erik Kline wrote: > .. >> I wonder if we should ask the NOC about performing a renumbering >> during the next IETF meeting. >> >> Ideally, we should be able to perform one or two (or three) >> renumberings in a week, glean the relevant operational experience, and >> send a draft to v6ops shortly thereafter. > > Great idea. I won't be in Orlando, but I am fairly sure there is nothing > I would do there that cares about address persistency, apart from > having to reconnect to jabber maybe. Conducting an RFC 4192 procedure > on Tuesday night and a flash IPv6 renumbering during Thursday morning > would be very interesting! > > At least Skype will not be a problem during IPv6 renumbering. > > Brian > From john_brzozowski@cable.comcast.com Sat Feb 23 15:57:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BDE21F8E3A for ; Sat, 23 Feb 2013 15:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=-1.556, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XPGCkmfu-KU for ; Sat, 23 Feb 2013 15:57:04 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4D921F8DDC for ; Sat, 23 Feb 2013 15:57:04 -0800 (PST) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.44422430; Sat, 23 Feb 2013 18:43:44 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Sat, 23 Feb 2013 18:56:10 -0500 From: "Brzozowski, John" Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHOEE56UKHjmYjHJk2z+mbkmocqx5iF9qyZgABUyQCAAdaYgA== Date: Sat, 23 Feb 2013 23:56:08 +0000 Message-ID: In-Reply-To: <3135C2851EB6764BACEF35D8B495596806D80B2FBB@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <69C2F8DD2FA20A44A0D036296C39AF35@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Wuyts Carl , Ted Lemon , Michael Thomas X-Mailman-Approved-At: Sun, 24 Feb 2013 04:24:32 -0800 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 23:57:05 -0000 Also for ISP that have this "problem" called growth activities of this type (renumbering) may be required to ensure capacity is properly managed which in turn is essential to a proper customer experience. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Wuyts Carl Date: Friday, February 22, 2013 6:51 AM To: Ted Lemon , Michael Thomas Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , John Jason Brzozowski , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: RE: [homenet] Running code in Orlando >Small add-on to the address-renew policy @ some ISPs > >Some ISPs do refresh the IP every XX hours for several reasons: >* privacy >* different contracts, i.e. you pay more for fixed IP over dynamic IP, >i.e. allows hosting on same IP > >The same will be applied for IPv6. > >Best regards >Carl Wuyts >Help preserve the color of our world - Think before you print. > > > > >-----Original Message----- >From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On >Behalf Of Ted Lemon >Sent: vrijdag 22 februari 2013 15:48 >To: Michael Thomas >Cc: Michael Richardson; Mark Townsley; Dave Taht; Jari Arkko; Brzozowski, >John; homenet@ietf.org Group; David Lamparter; Lorenzo Colitti >Subject: Re: [homenet] Running code in Orlando > >On Feb 21, 2013, at 8:34 PM, Michael Thomas wrote: >> Sigh all you like, but I share Dave's skepticism that ISP's >> renumbering my prefix willy-nilly and it just sort of works with >> naming -- including addresses squirrelled away in places they ought >> not be -- is going to work any time soon. I don't like to think that >> NAT is inevitable but frankly the people in this working group don't >>get to vote on that. > >It's probably also worth mentioning that in general ISPs that do this on >a regular basis are attacking their customer's network, and the resulting >instability is not the result of a failing on our part, but deliberate >action on the part of the ISP. > >There are countries where ISPs are required by law to _offer_ a change of >address every 24 hours for privacy purposes. At least in the cases I'm >aware of, ISPs don't _force_ this on their customers, but rather it's a >configuration option paranoid customers can choose, which may default to >on. This is an inconvenience to ISPs, because it causes address pool >churn, and requires a lot of extra bits to be allocated to PE devices to >accommodate all the deprecated addresses. > >Pretty much by definition, if you want to access your washing machine >while away from home, you're throwing that particular sort of privacy >right out the window. It wasn't buying you much anyway--fuzzing the >prefix by a few bits is very easy to reverse, and because of routing >hierarchies, IPv6 prefixes can't be assigned to the customer out of the >ISP's entire address space--by definition they will be restricted to >localities. > >The other use case for frequent renumbering is an ISP who wants to >prevent the customer from setting up servers. The washing machine is a >server. Either the ISP succeeds, or fails, but in either case, they are >acting directly against the customer's wishes. We can try to design a >system that's robust with respect to attacks like this, but in practice >the best way to address this problem is to prevent it happening on a >regular basis to people who will care about it. >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From john_brzozowski@cable.comcast.com Sun Feb 24 06:20:42 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B4621F8FF4 for ; Sun, 24 Feb 2013 06:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=-1.570, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bkNrFgxXXyA for ; Sun, 24 Feb 2013 06:20:42 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2B31521F8FEB for ; Sun, 24 Feb 2013 06:20:42 -0800 (PST) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.44442067; Sun, 24 Feb 2013 09:08:09 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Sun, 24 Feb 2013 09:20:35 -0500 From: "Brzozowski, John" To: Ted Lemon Thread-Topic: [homenet] Running code in Orlando Thread-Index: AQHOEE56UKHjmYjHJk2z+mbkmocqx5iF9qyZgABhrwCAAcpeAIAAbd8AgACDAYA= Date: Sun, 24 Feb 2013 14:20:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 14:20:43 -0000 Thanks for the clarification Ted. I recall this being looked at as a standard practice ~10 years ago even for larger providers, however, the challenges associated with the same out weighed any perceived benefits. I do not hear much about this sort of thing these days. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Ted Lemon Date: Saturday, February 23, 2013 5:31 PM To: John Jason Brzozowski Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Running code in Orlando >On Feb 23, 2013, at 6:58 PM, "Brzozowski, John" > wrote: >> I do not think the issue here is privacy or lack of interest in the >>same. >> It is ensuring capacity is managed appropriately. Further, allocating >> static blocks to everyone has an entirely different set of impacts that >>go >> much deeper in the network beyond the home. > >To be clear, what I was talking about is a policy of deliberately >renumbering the customer in the absence of any operational need to do so, >other than a misguided attempt to enforce a contract clause that some >might describe as unconscionable. I happen to know that your company >doesn't do any such thing, because I'm a customer, but I have heard of >small ISPs doing this sort of thing with IPv4. > >I think the IPv6 architecture is quite robust in the face of such >behavior, certainly in comparison to IPv4. But the point is that if >this sort of behavior on the part of the ISP introduces some hiccups in >the performance of the homenet, this is par for the course. > From victor.kuarsingh@gmail.com Sun Feb 24 06:43:59 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CA521F8FE7 for ; Sun, 24 Feb 2013 06:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.365 X-Spam-Level: X-Spam-Status: No, score=-0.365 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-MMnh78YBsN for ; Sun, 24 Feb 2013 06:43:59 -0800 (PST) Received: from mail-ia0-x236.google.com (ia-in-x0236.1e100.net [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 37F6221F8F95 for ; Sun, 24 Feb 2013 06:43:58 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id k38so1811401iah.27 for ; Sun, 24 Feb 2013 06:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=Hk2/XnlMDBK0qPMYzQ2n5Yzky3PTx1FWsEpd3d7PEqw=; b=L/Bk783dLhBrU5fHS8GdW+klLIGPoD0GLZxgYdg5WE3i4SeIZ0E2mWBcXzsF5ApWCy bgP4JaQDwjseraRcV4rlOBQaSnnGVYB5LotXDOaY51K+RsxFHM1IupwTaIy/3WiKH8JJ pL5sJhP9Gxj54quq/D1/qQjix9VJbPHn+05YWA0t/gV3fIJmuhxEovNaUuiItysZjdu8 SPWq0TAPf5i4BtgN7Wy0BTqQ1QzEwzBe8EUKC0NBvWb+JZymVDDrWgRLJT5s6SsCl5cc NZSINjDnXCzQ0ypatnkuvGHfWeBOA5Md8yfS1pdmevf1B0rz/TfuzuIiKgtsr5EfewHQ bt8g== X-Received: by 10.50.150.228 with SMTP id ul4mr2119770igb.9.1361717038561; Sun, 24 Feb 2013 06:43:58 -0800 (PST) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPS id uq1sm2738801igc.5.2013.02.24.06.43.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 24 Feb 2013 06:43:57 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sun, 24 Feb 2013 09:43:48 -0500 From: Victor Kuarsingh To: "Brzozowski, John" , Ted Lemon Message-ID: Thread-Topic: [homenet] Running code in Orlando In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Running code in Orlando X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 14:43:59 -0000 On 2013-02-24 9:20 AM, "Brzozowski, John" wrote: >Thanks for the clarification Ted. I recall this being looked at as a >standard practice ~10 years ago even for larger providers, however, the >challenges associated with the same out weighed any perceived benefits. I >do not hear much about this sort of thing these days. Agreed. Renumbering for large deployments like the one I am familiar with are related to the necessity to manage the network, growth and other access network related dynamics. This is an expensive exercise, and I would venture to say most operators would only do it based on necessity. Although we don't like it, some amount of renumbering will occur (hard to same how much just yet given there are some differences with IPv6 vs. IPv4 related to addressing). Regards, Victor K >-----Original Message----- >From: Ted Lemon >Date: Saturday, February 23, 2013 5:31 PM >To: John Jason Brzozowski >Cc: "homenet@ietf.org Group" >Subject: Re: [homenet] Running code in Orlando > >>On Feb 23, 2013, at 6:58 PM, "Brzozowski, John" >> wrote: >>> I do not think the issue here is privacy or lack of interest in the >>>same. >>> It is ensuring capacity is managed appropriately. Further, allocating >>> static blocks to everyone has an entirely different set of impacts that >>>go >>> much deeper in the network beyond the home. >> >>To be clear, what I was talking about is a policy of deliberately >>renumbering the customer in the absence of any operational need to do so, >>other than a misguided attempt to enforce a contract clause that some >>might describe as unconscionable. I happen to know that your company >>doesn't do any such thing, because I'm a customer, but I have heard of >>small ISPs doing this sort of thing with IPv4. >> >>I think the IPv6 architecture is quite robust in the face of such >>behavior, certainly in comparison to IPv4. But the point is that if >>this sort of behavior on the part of the ISP introduces some hiccups in >>the performance of the homenet, this is par for the course. >> > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From sm@resistor.net Sun Feb 24 09:15:15 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B8921F9070 for ; Sun, 24 Feb 2013 09:15:15 -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.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrnF5xCoEgcp for ; Sun, 24 Feb 2013 09:15:13 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C85421F906E for ; Sun, 24 Feb 2013 09:15:08 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1OHEspk011123; Sun, 24 Feb 2013 09:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361726104; bh=jfP1v9ASoxtlLQY6y1lBGpp02US+ryu8qK03Wm6wO0M=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GwDXUff+SyDDtxytwcZuPNcKJtYwWlLMBwqo8OGYFz5EzoT9E/e1NjrHVd33QmWiB +aD39fK9D2RlbJ4xnboyFYgeILv4d+TaUrdqDa0WebH06WsDoTlkzFDuPKsNZ2sCxa qpcN6BuzfKm3SUt7Ke856t3MXBzeo/BhxVf+9MN8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1361726104; i=@resistor.net; bh=jfP1v9ASoxtlLQY6y1lBGpp02US+ryu8qK03Wm6wO0M=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Y56pDdw5sQbe+/lxIPPrVkVJxytK8JSiYcFTtkU15GJ+5h5+8nSpVQg18G0dEZR5e C+isLVHF7Jow7C1kLgFBFeASCCnqC1QKSIc7Yw8YdDeERTJy1uS95Zz6JxeuV4uykL zFTB8vmYhB0KLAb6ztSuunKoRm3l/n4T8LFsZcqE= Message-Id: <6.2.5.6.2.20130224085009.0afd0810@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 24 Feb 2013 08:54:46 -0800 To: james woodyatt From: SM In-Reply-To: <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: homenet@ietf.org Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 17:15:15 -0000 Hi James, At 13:11 22-02-2013, james woodyatt wrote: >When there was still a consensus that subscribers should always get >a /48 prefix, it was reasonable to expect that a randomly chosen >16-bit subnet identifier would be unlikely to collide with another >subnet in most automatically numbered routing domains. We were also Architecture and politics do not go well together. Some decisions tend to create complexity down the line. Regards, -sm From john_brzozowski@cable.comcast.com Sun Feb 24 09:29:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B5721F9068 for ; Sun, 24 Feb 2013 09:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.406 X-Spam-Level: X-Spam-Status: No, score=-104.406 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfisTUqnzSlF for ; Sun, 24 Feb 2013 09:29:56 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id A6A7B21F9067 for ; Sun, 24 Feb 2013 09:29:56 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57789214; Sun, 24 Feb 2013 09:58:37 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Sun, 24 Feb 2013 12:29:01 -0500 From: "Brzozowski, John" To: Lorenzo Colitti , Michael Thomas Thread-Topic: [homenet] NPTv6-only home networks Thread-Index: AQHOEKWseJqgpe0N7kSCQ5ntBRDfFpiFhQ2AgAAYXgCAA6olgA== Date: Sun, 24 Feb 2013 17:29:00 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 17:29:57 -0000 > >My point was more that that NPTv6 doesn't make that any easier, more >secure, or... anything, really. You still have to update the address >somewhere; all that NPTv6 gives you is that now the washing machine >doesn't know what its IPv6 address is. Right? [jjmb] yes and I agree with your points. From john_brzozowski@cable.comcast.com Sun Feb 24 09:32:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B8021F906B for ; Sun, 24 Feb 2013 09:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.438 X-Spam-Level: X-Spam-Status: No, score=-104.438 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSgAA9TmGOxE for ; Sun, 24 Feb 2013 09:32:05 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1AE21F9067 for ; Sun, 24 Feb 2013 09:32:05 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57789333; Sun, 24 Feb 2013 10:00:47 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Sun, 24 Feb 2013 12:31:11 -0500 From: "Brzozowski, John" To: Ted Lemon , Michael Thomas Thread-Topic: [homenet] NPTv6-only home networks Thread-Index: AQHOEKWseJqgpe0N7kSCQ5ntBRDfFpiFhQ2AgAAIBACAAAKpAIAAAQ2AgACRtICAAyWugA== Date: Sun, 24 Feb 2013 17:31:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <7D9D21B6BF1B2948980DEEE8BB1BACB3@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 17:32:06 -0000 I thought mdnsext was supposed to handle this now? Still agree it should be covered some where. -----Original Message----- From: Ted Lemon Date: Friday, February 22, 2013 4:27 AM To: Michael Thomas Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , John Jason Brzozowski , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] NPTv6-only home networks >On Feb 21, 2013, at 10:45 PM, Michael Thomas wrote: >> Well, if one of the requirements is that I be able to control my >>washing machine from across the continent, >> I'm not sure why we're even screwing with mdns in this wg. And if >>that's not a requirement for this working >> group, I have to ask which century it got chartered in. > >+1 > From john_brzozowski@cable.comcast.com Sun Feb 24 09:34:35 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDE121F9078 for ; Sun, 24 Feb 2013 09:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.468 X-Spam-Level: X-Spam-Status: No, score=-104.468 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83MYBu-2qf2D for ; Sun, 24 Feb 2013 09:34:34 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5417221F906B for ; Sun, 24 Feb 2013 09:34:34 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57789443; Sun, 24 Feb 2013 10:04:06 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Sun, 24 Feb 2013 12:34:30 -0500 From: "Brzozowski, John" To: Simon Kelley , "homenet@ietf.org" Thread-Topic: [homenet] NPTv6-only home networks Thread-Index: AQHOEKWseJqgpe0N7kSCQ5ntBRDfFpiFhQ2AgAAYXgCAAIX+AIAACGEAgAMdTYA= Date: Sun, 24 Feb 2013 17:34:29 +0000 Message-ID: In-Reply-To: <51276C00.7060808@thekelleys.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 17:34:35 -0000 Do you populate A-DNS with hosts learned from mDNS and advertise hosts in A-DNS via mDNS? :O =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Simon Kelley Date: Friday, February 22, 2013 5:00 AM To: "homenet@ietf.org" Subject: Re: [homenet] NPTv6-only home networks >On 22/02/13 12:30, Ted Lemon wrote: >> On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti >> wrote: > >> I think the issue that Michael imagines NPTv6 will address is the >> transition period, when the washing machine has two IP addresses, and >> the DNS may not have the new address, or may have both addresses, and >> he's hoping the gateway will somehow bandage this up. However, the >> gateway's ability to bandage this up is more imagined than real, and >> we might as well just fix the underlying problem. > >The current development release of dnsmasq can act as an authoritative >DNS server populated with all hosts on a homenet which it knows about >from DHCP. Delegate your domain to it, and ensure that the TTL >configured for DNS is smaller than the deprecated lifetime of addresses, >and this problem should never arise. > > > > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From john_brzozowski@cable.comcast.com Sun Feb 24 09:42:40 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBEF21F8454 for ; Sun, 24 Feb 2013 09:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5wllqWSTd+X for ; Sun, 24 Feb 2013 09:42:39 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 7672C21F908F for ; Sun, 24 Feb 2013 09:42:39 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57789727; Sun, 24 Feb 2013 10:11:13 -0700 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.2.318.1; Sun, 24 Feb 2013 12:41:37 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Sun, 24 Feb 2013 12:41:36 -0500 From: "Brzozowski, John" To: Michael Thomas , joel jaeggli Thread-Topic: [homenet] NPTv6-only home networks Thread-Index: AQHOEKWseJqgpe0N7kSCQ5ntBRDfFpiFhQ2AgABTSwCAAHuUAIAC9yeA Date: Sun, 24 Feb 2013 17:41:35 +0000 Message-ID: In-Reply-To: <51278DAA.4000507@mtcc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <8FD75FD92D426548B76B9B6B3C9833C4@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 17:42:40 -0000 DLNA seems to have some challenges seeing how IPv6 is relevant for them in the future, I think UPnP has done some work however upper layer protocols/applications must still require the use of the same. -----Original Message----- From: Michael Thomas Date: Friday, February 22, 2013 7:24 AM To: Joel Jaeggli Cc: Lorenzo Colitti , Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , John Jason Brzozowski , "homenet@ietf.org Group" , David Lamparter Subject: Re: [homenet] NPTv6-only home networks >joel jaeggli wrote: >> On 2/21/13 7:04 PM, Michael Thomas wrote: >> So, I think what we can observe from the number of readily discoverable >> security cameras on the internet. was that the real-live requirement >>was=20 >> at least partially solved thanks to upnp and dynamic dns registration, >> is not a geek-only-oddity, survives renumbering, and was for the most >> part done quite badly. hopefully it can be done better in the future. > >I was under the impression that upnp is exactly what we should not be >aspiring to, >but that we'll get by default (like natv6) if nothing useful happens in >ietf. > >Mike From john_brzozowski@cable.comcast.com Sun Feb 24 09:44:37 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A1221F908B for ; Sun, 24 Feb 2013 09:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.353 X-Spam-Level: X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=-1.456, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP7Wr2iE3BEC for ; Sun, 24 Feb 2013 09:44:37 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB2E21F848D for ; Sun, 24 Feb 2013 09:44:37 -0800 (PST) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.44448449; Sun, 24 Feb 2013 12:31:14 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Sun, 24 Feb 2013 12:43:41 -0500 From: "Brzozowski, John" To: Ted Lemon , Michael Thomas Thread-Topic: [homenet] NPTv6-only home networks Thread-Index: AQHOEKWseJqgpe0N7kSCQ5ntBRDfFpiFhQ2AgAAYXgCAAIX+AIAAKiIAgABO8YCAAq8tgA== Date: Sun, 24 Feb 2013 17:43:40 +0000 Message-ID: In-Reply-To: <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <46189F5849C0214CA4E1DF17C4326010@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 17:44:37 -0000 I have to agree kudos to Simon for trying to move something forward and the something pertains to real problems that we must solve. While I recognize that is not in the HOMENET charter I do not agree that this should be IPv6 only. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Ted Lemon Date: Friday, February 22, 2013 11:44 AM To: Michael Thomas Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , John Jason Brzozowski , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks >On Feb 22, 2013, at 10:01 AM, Michael Thomas wrote: >> Right now, I don't think that sufficient energy is being given to just >>one obvious problem: how does real DNS interact with >> prefix delegation in the home (assuming that we don't want split >>horizon dns)? For that matter, let me be even more blunt: >> I don't think that real DNS is being given enough attention altogether >>in home settings, and until that happens we'll >> just inherit all of the awful hacks that are done with NATv4. > >Agreed. I'm delighted to hear that Simon has a hack in dnamasq that >addresses this problem in a dual-stack environment, but I want to have a >serious conversation somewhere about how to address the problem on the >v6-only homenet. > >Who's interested in sketching a DNS-based solution to the problem and has >time to work on it? > From mellon@fugue.com Sun Feb 24 10:12:48 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5133821F8438 for ; Sun, 24 Feb 2013 10:12:48 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1OeaQJYh6Rs for ; Sun, 24 Feb 2013 10:12:47 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 00C9021F8F58 for ; Sun, 24 Feb 2013 10:12:22 -0800 (PST) Received: from kali-10.home.lan (c-174-62-144-132.hsd1.nh.comcast.net [174.62.144.132]) by toccata.fugue.com (Postfix) with ESMTPSA id CB0622380534; Sun, 24 Feb 2013 13:12:19 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: Date: Sun, 24 Feb 2013 13:12:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Brzozowski, John" X-Mailer: Apple Mail (2.1499) Cc: Michael Richardson , Michael Thomas , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 18:12:48 -0000 On Feb 24, 2013, at 12:31 PM, "Brzozowski, John" = wrote: > I thought mdnsext was supposed to handle this now? Still agree it = should > be covered some where. The question is whether this working group should just decide, = sight-unseen, that an mdnsext solution will be good, or whether there = are other solutions worth exploring. From joelja@bogus.com Sun Feb 24 10:28:09 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C503521F903E for ; Sun, 24 Feb 2013 10:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz-W-sXQ3TZP for ; Sun, 24 Feb 2013 10:28:09 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E749521F84BD for ; Sun, 24 Feb 2013 10:28:08 -0800 (PST) Received: from joels-MacBook-Air.local (68.sub-70-199-85.myvzw.com [70.199.85.68]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r1OIRNbX087340 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 24 Feb 2013 18:27:24 GMT (envelope-from joelja@bogus.com) Message-ID: <512A5B88.8000005@bogus.com> Date: Sun, 24 Feb 2013 10:27:20 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: "Brzozowski, John" , Michael Thomas References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 24 Feb 2013 18:27:25 +0000 (UTC) Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 18:28:09 -0000 On 2/24/13 9:41 AM, Brzozowski, John wrote: > DLNA seems to have some challenges seeing how IPv6 is relevant for them in > the future, I think UPnP has done some work however upper layer > protocols/applications must still require the use of the same. Practically speaking, iirc they have to some challenges to make their toolchain work across more than one subnet. > > > -----Original Message----- > From: Michael Thomas > Date: Friday, February 22, 2013 7:24 AM > To: Joel Jaeggli > Cc: Lorenzo Colitti , Michael Richardson > , Mark Townsley , Dave Taht > , Jari Arkko , John Jason > Brzozowski , "homenet@ietf.org Group" > , David Lamparter > Subject: Re: [homenet] NPTv6-only home networks > >> joel jaeggli wrote: >>> On 2/21/13 7:04 PM, Michael Thomas wrote: >>> So, I think what we can observe from the number of readily discoverable >>> security cameras on the internet. was that the real-live requirement >>> was >>> at least partially solved thanks to upnp and dynamic dns registration, >>> is not a geek-only-oddity, survives renumbering, and was for the most >>> part done quite badly. hopefully it can be done better in the future. >> I was under the impression that upnp is exactly what we should not be >> aspiring to, >> but that we'll get by default (like natv6) if nothing useful happens in >> ietf. >> >> Mike > From marka@isc.org Sun Feb 24 12:22:01 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B3821F90FB for ; Sun, 24 Feb 2013 12:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05gMPN2UHu4P for ; Sun, 24 Feb 2013 12:22:00 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 77AE921F90F9 for ; Sun, 24 Feb 2013 12:22:00 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B2D3CC95B9; Sun, 24 Feb 2013 20:21:52 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361737320; bh=5ckNPXzP7/5DZK7fMdiZpqFbGmI56r22jUISAujZ2oY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=bhPF/mhL1VAHUN9fhIbkcuVY27NMJFiH4UTmo83aakEA3TOrERAyove/JuNLyU4A6 AveKpzgDnurGW2wyErW72c6eauzXSUkkvbRqytqN2V5Tk87/rW7+BkjAUnvA6NOE/l HnXZN3EVAXcd3et82PnOs6YVMFLKelN0krCPySRs= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Sun, 24 Feb 2013 20:21:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 74E3E216C47; Sun, 24 Feb 2013 20:21:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C80B730035E0; Mon, 25 Feb 2013 07:21:50 +1100 (EST) To: Michael Thomas From: Mark Andrews References: <512958CB.8000603@mtcc.com> In-reply-to: Your message of "Sat, 23 Feb 2013 16:03:23 -0800." <512958CB.8000603@mtcc.com> Date: Mon, 25 Feb 2013 07:21:50 +1100 Message-Id: <20130224202150.C80B730035E0@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Michael Richardson , Ted Lemon , Dave Taht , Mark Townsley , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] Servers in the home are not a crime X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 20:22:01 -0000 In message <512958CB.8000603@mtcc.com>, Michael Thomas writes: > Brzozowski, John wrote: > >> The other use case for frequent renumbering is an ISP who wants to > >> prevent the customer from setting up servers. The washing machine is a > >> server. Either the ISP succeeds, or fails, but in either case, they are > >> acting directly against the customer's wishes. > > > [jjmb] are a customer is violating their usage agreement with the ISP. > > > Is there any way this working group can make a statement that my washing mach > ine, > home cameras, DVR, hot tub, thermostat, and light sockets, etc, etc, etc are > not TOS-worth scofflaws, and that ISP should come up with some 21st century w > ay of > describing abusive behaviour for their customers rather than relying on detec > tion of > the heinous crime of listen(2)? Actually ISP's that renumber their customers regularly are performing a DoS on their customers which actually may be illegal rather than just a contract violation as they are deliberately breaking existing connections. I've seen software updates take longer than a hour to download. They also can't in good faith be said to be delivering the Internet. They generally have to break protocol default behaviors and write specialised servers to get this broken behaviour. There is a expectation that when you renew a lease that you will get the same address unless it is a exceptional circumstance. > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From john_brzozowski@cable.comcast.com Sun Feb 24 15:29:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E178421F9125 for ; Sun, 24 Feb 2013 15:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.472 X-Spam-Level: X-Spam-Status: No, score=-104.472 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wE+jCqvLfeK6 for ; Sun, 24 Feb 2013 15:29:19 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id CF87721F9124 for ; Sun, 24 Feb 2013 15:29:19 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57806034; Sun, 24 Feb 2013 15:58:46 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Sun, 24 Feb 2013 18:29:13 -0500 From: "Brzozowski, John" To: Mark Andrews Thread-Topic: [homenet] Servers in the home are not a crime Thread-Index: AQHOEsycoZzdlq45KkOH7SHFa/ijhZiJp+UA Date: Sun, 24 Feb 2013 23:29:12 +0000 Message-ID: In-Reply-To: <20130224202150.C80B730035E0@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <03FD901AA731914D98F35441A806FB57@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Servers in the home are not a crime X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 23:29:21 -0000 Misguided. -----Original Message----- From: Mark Andrews Date: Sunday, February 24, 2013 12:21 PM To: Michael Thomas Cc: John Jason Brzozowski , Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , Ted Lemon , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] Servers in the home are not a crime > >In message <512958CB.8000603@mtcc.com>, Michael Thomas writes: >> Brzozowski, John wrote: >> >> The other use case for frequent renumbering is an ISP who wants to >> >> prevent the customer from setting up servers. The washing machine >>is a >> >> server. Either the ISP succeeds, or fails, but in either case, >>they are >> >> acting directly against the customer's wishes. >>=20 >> > [jjmb] are a customer is violating their usage agreement with the ISP. >>=20 >>=20 >> Is there any way this working group can make a statement that my >>washing mach >> ine, >> home cameras, DVR, hot tub, thermostat, and light sockets, etc, etc, >>etc are >> not TOS-worth scofflaws, and that ISP should come up with some 21st >>century w >> ay of >> describing abusive behaviour for their customers rather than relying on >>detec >> tion of >> the heinous crime of listen(2)? > >Actually ISP's that renumber their customers regularly are performing >a DoS on their customers which actually may be illegal rather than >just a contract violation as they are deliberately breaking existing >connections. I've seen software updates take longer than a hour >to download. They also can't in good faith be said to be delivering >the Internet. They generally have to break protocol default behaviors >and write specialised servers to get this broken behaviour. There >is a expectation that when you renew a lease that you will get the >same address unless it is a exceptional circumstance. > >> Mike >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >--=20 >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From john_brzozowski@cable.comcast.com Sun Feb 24 15:46:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDCF21F9109 for ; Sun, 24 Feb 2013 15:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.496 X-Spam-Level: X-Spam-Status: No, score=-104.496 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do1k4dPIM1Jx for ; Sun, 24 Feb 2013 15:46:25 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id EFA7A21F8E43 for ; Sun, 24 Feb 2013 15:46:24 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.57806693; Sun, 24 Feb 2013 16:14:50 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Sun, 24 Feb 2013 18:45:14 -0500 From: "Brzozowski, John" To: joel jaeggli , Michael Thomas Thread-Topic: [homenet] NPTv6-only home networks Thread-Index: AQHOEKWseJqgpe0N7kSCQ5ntBRDfFpiFhQ2AgABTSwCAAHuUAIAC9yeAgABgnACAAAUAgA== Date: Sun, 24 Feb 2013 23:45:13 +0000 Message-ID: In-Reply-To: <512A5B88.8000005@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <30D78E9786A36D4CAE70CCC4AFEF4ADB@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 23:46:26 -0000 I believe this is accurate. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Joel Jaeggli Date: Sunday, February 24, 2013 10:27 AM To: John Jason Brzozowski , Michael Thomas Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks >On 2/24/13 9:41 AM, Brzozowski, John wrote: >> DLNA seems to have some challenges seeing how IPv6 is relevant for them >>in >> the future, I think UPnP has done some work however upper layer >> protocols/applications must still require the use of the same. >Practically speaking, iirc they have to some challenges to make their >toolchain work across more than one subnet. >> >> >> -----Original Message----- >> From: Michael Thomas >> Date: Friday, February 22, 2013 7:24 AM >> To: Joel Jaeggli >> Cc: Lorenzo Colitti , Michael Richardson >> , Mark Townsley , Dave Taht >> , Jari Arkko , John Jason >> Brzozowski , "homenet@ietf.org Group" >> , David Lamparter >> Subject: Re: [homenet] NPTv6-only home networks >> >>> joel jaeggli wrote: >>>> On 2/21/13 7:04 PM, Michael Thomas wrote: >>>> So, I think what we can observe from the number of readily >>>>discoverable >>>> security cameras on the internet. was that the real-live requirement >>>> was >>>> at least partially solved thanks to upnp and dynamic dns registration, >>>> is not a geek-only-oddity, survives renumbering, and was for the most >>>> part done quite badly. hopefully it can be done better in the future. >>> I was under the impression that upnp is exactly what we should not be >>> aspiring to, >>> but that we'll get by default (like natv6) if nothing useful happens in >>> ietf. >>> >>> Mike >> > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From lorenzo@google.com Sun Feb 24 16:51:13 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9605221F9162 for ; Sun, 24 Feb 2013 16:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.958 X-Spam-Level: X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5G7b-z4KsDa for ; Sun, 24 Feb 2013 16:51:11 -0800 (PST) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id ADF3B21F9144 for ; Sun, 24 Feb 2013 16:51:11 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id i10so2398442oag.0 for ; Sun, 24 Feb 2013 16:51:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=qpZ24EDjdObudyTa5MvWrpk0sKIapCWjgEoX1LTkJQA=; b=fArVHsWO26DV0assmQVIXIJwLFWEA7FnmH5blFDyvhS6CAoFBHNbOvgdUdrf6zsjsX BNf70bh/64S6oSp2dBpm4PrDLM5VFzFWP3GEDSRQZIdE7Wqac+Zw4UFc4h/MqQt1qOab hLHSJ/0H3oxwzQKYMCjAl01ILZrksgBpSqG6GPMt1VMsqjb2gmM7P77I2zWrVxrAhPxJ ZTiG7jMp50jXm83nV8MTZQ9dvuI5kLOG6M8TwoBuE10a+UDlRk+Dedivh71ciBrcS2SW GIu9FwL0hlGxQC5PeVq056DLoKe3/BxJGn5xGSpj9BmYLwZ4RGja0oumeWof3fPNXdoX ZKeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=qpZ24EDjdObudyTa5MvWrpk0sKIapCWjgEoX1LTkJQA=; b=oY/SqW32yaGGHimylddnfo+437fQG2SXUl3gbqUCF2rwz4I2yg5ePRncYbPFGUWoms AtL1k5H5993FFbiNTvWjCBD1UoQiJVVbBCfyZBW8gT5mBhZLd1GBMxigRMW5v3Lb9Nng raMrGIO2hEcLVeg6ayJIzuBinEi9Zi0LFCB3hbOPcAfDGY49YLgZRJJRv396q3BVbgCb f6ajAR4/NMvBFAnqiBkLjfno4eaNjQlXQT6kUze8YCyky29k2fRDbRLLWfXUTTEr8Z9g hS5/y1EUlrqAfDSZhs8Otg0nzoupQCHiL9WYXSNHG1vpPNFotjwHqLRz5MHnbjLgr98B 3mNA== X-Received: by 10.182.42.35 with SMTP id k3mr299004obl.67.1361753471001; Sun, 24 Feb 2013 16:51:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Sun, 24 Feb 2013 16:50:50 -0800 (PST) In-Reply-To: <3E23756C-A4E4-4D48-B534-EAB191F1AA48@cisco.com> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> <51276A40.5020705@globis.net> <3E23756C-A4E4-4D48-B534-EAB191F1AA48@cisco.com> From: Lorenzo Colitti Date: Mon, 25 Feb 2013 09:50:50 +0900 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=f46d04463184e94c5604d681ef52 X-Gm-Message-State: ALoCoQlpA2NwZH5P7YlmD8GuogaXYtofgmOpH4XEj2M1luYiLImArohEP6evy6eHFim5+bifPRn9p8vzDycPxZwY39R8wk27Y3kX0fZUf61LoSQ+hQcOOWcs3gN/V6//VQGJBBAaCHC1gohPKMD5ZFjfPFuS77/S2ZDH8ZUPQA2JlnHUiujyig2adFmTET3WNy3ThynZ485P Cc: "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" , Ray Hunter , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , "Abhay Roy \(akr\)" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 00:51:14 -0000 --f46d04463184e94c5604d681ef52 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 22, 2013 at 10:06 PM, Ole Troan wrote: > > IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with > > autoconfiguration and on-link flags set, and configure /64 prefixes from > > both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these > > as being on-link. > > > > But IMHO there's no further AS number/provider information/upstream > > topology information coupled to these /64 prefixes. There might be a > > router-router interconnect LAN between R1 and R2, or there might not be. > > if there is no interconnect between R1 and R2, then the host has two > interfaces connected to two separate connections. then I can't see how > that can be solved in the network. my assumption is that all homenet > routers must be connected (I see I haven't stated that anywhere, but that > should be added). > Do we really need this? When I originally put together the strawman it seemed to me that there are only two cases: either the two border routers have a path to each other, or they don't. If they do not have a path to each other, then the host cannot be connected to both routers using the same interface - because if it is, it's a broadcast interface and those two routers are also connected to each other. Should we write this in the draft? > > How will the host H1 know to associate source address prefixes from > > provider2 with router2 for off link destinations e.g. to a Provider2/56 > > or Provider2/32? > > in your case it will RFC6724, rule 5.5 > You don't need to invoke RFC 6724 for this. RFC 3484 (prefer outgoing interface) is enough. We should put this in the draft though. > My expected host behavior would currently be that it'd just choose one > > of the known available default routers from the list. If correct fine. > > If not, then wait for an ICMPv6 redirect to be told to use the other > router. > > you would only get that if the routers were connected of course. > whichever came first, you'd either get a unreachable code 5 (wrong source) > or ICMP redirect, or the router would just forward the packet to second > router. > Please let's not design something that requires ICMP redirects to work. It will be slow and unreliable. > > Thus H1 should never send packets with a source address derived from a > > PIO received in an RA from R2, to a potential default router R1 that > > sent an RA message but did not include a PIO for this particular source > > prefix? > > > > Where is this behavior defined in an RFC? I don't see it in > > http://www.ietf.org/rfc/rfc2461.txt Section 4.2 or > > http://tools.ietf.org/html/rfc4862#page-18 > > In fact section 6.3.6. on default router selection is quite explicit and > > doesn't mention associating potential default routers with prefix > > information options at all AFAIK. > > again, that's rule 5.5 (which is somewhat weak) in 6724. > 3484 rule 5 too, right? Or not? --f46d04463184e94c5604d681ef52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 22, 2013 at 10:06 PM, Ole Troan <ot@cisco.com&= gt; wrote:
=
> IPv6 Host H1 will receive two PIO's, one ea= ch from R1 and R2, with
> autoconfiguration and on-link flags set, and configure /64 prefixes fr= om
> both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these=
> as being on-link.
>
> But IMHO there's no further AS number/provider information/upstrea= m
> topology information coupled to these /64 prefixes. There might be a > router-router interconnect LAN between R1 and R2, or there might not b= e.

if there is no interconnect between R1 and R2, then the host ha= s two
interfaces connected to two separate connections. then I can't see how<= br> that can be solved in the network. my assumption is that all homenet router= s=A0must be connected (I see I haven't stated that anywhere, but that s= hould be added).

Do we really nee= d this?

When I originally put together the strawman= it seemed to me that there are only two cases: either the two border route= rs have a path to each other, or they don't. If they do not have a path= to each other, then the host cannot be connected to both routers using the= same interface - because if it is, it's a broadcast interface and thos= e two routers are also connected to each other.

Should we write this in the draft?
=A0
> How will the host H1 know to associate source addres= s prefixes from
> provider2 with router2 for off link destinations e.g. to a Provider2/5= 6
> or Provider2/32?

in your case it will RFC6724, rule 5.5

You don't need to invoke RFC 6724 for this. RFC 3484 (prefe= r outgoing interface) is enough. We should put this in the draft though.

> My expected host behavior would currently be that it= 'd just choose one
> of the known available default routers from the list. If correct fine.=
> If not, then wait for an ICMPv6 redirect to be told to use the other r= outer.

you would only get that if the routers were connected of course.
whichever came first, you'd either get a unreachable code 5 (wrong sour= ce)
or ICMP redirect, or the router would just forward the packet to second rou= ter.

Please let's not design = something that requires ICMP redirects to work. It will be slow and unrelia= ble.
=A0
> Thus H1 should never send packets with a source addr= ess derived from a
> PIO received in an RA from R2, to a potential default router R1 that > sent an RA message but did not include a PIO for this particular sourc= e
> prefix?
>
> Where is this behavior defined in an RFC? I don't see it in
> http= ://www.ietf.org/rfc/rfc2461.txt Section 4.2 or
> http://tools.ietf.org/html/rfc4862#page-18
> In fact section 6.3.6. on default router selection is quite explicit a= nd
> doesn't mention associating potential default routers with prefix<= br> > information options at all AFAIK.

again, that's rule 5.5 (which is somewhat weak) in 6724.

3484 rule 5 too, right? Or not?
--f46d04463184e94c5604d681ef52-- From mcr@sandelman.ca Sun Feb 24 20:01:33 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE14321F91BE for ; Sun, 24 Feb 2013 20:01:33 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9lJS8J1EDMd for ; Sun, 24 Feb 2013 20:01:33 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id E693C21F91BA for ; Sun, 24 Feb 2013 20:01:28 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DD43D2016E; Sun, 24 Feb 2013 23:08:30 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 0CA656387F; Sun, 24 Feb 2013 23:00:18 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EF24C63765; Sun, 24 Feb 2013 23:00:18 -0500 (EST) From: Michael Richardson To: Ted Lemon In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Michael Thomas , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 04:01:33 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ted" =3D=3D Ted Lemon writes: >> I thought mdnsext was supposed to handle this now? Still agree >> it should be covered some where. Ted> The question is whether this working group should just decide, Ted> sight-unseen, that an mdnsext solution will be good, or whether Ted> there are other solutions worth exploring. I believe that this group should write its' requirements down clearly and depend/trust upon the IESG to enforce them on an mDNSext group.=20=20 Of course, it isn't like that group is being chartered to meet on mars or some other inaccessible place. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUSrh0oqHRg3pndX9AQKgwAQAhXW9dpFYy3VhtF29KrajiFd+WXMx2Ahs yIWL+eet++T61PxsrHVx5eBisb5Xsd79+eyMfmdPWBfhlkaxOIyVqJrvBy1XXWIO KZkBeVKMK7h2Ix3fkU7dHKAcP5+F3cTWvGwP9p/zvjoNCMY2DMDnFDE2wg8gbhnl AemYdVZx3R8= =il9g -----END PGP SIGNATURE----- --=-=-=-- From v6ops@globis.net Mon Feb 25 00:34:02 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F66321F9084 for ; Mon, 25 Feb 2013 00:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDD0JhD8XlH2 for ; Mon, 25 Feb 2013 00:33:59 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACD721F9071 for ; Mon, 25 Feb 2013 00:33:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 282358700CD; Mon, 25 Feb 2013 09:26:11 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBIkNrTuQ+ip; Mon, 25 Feb 2013 09:25:49 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E1AF6870085; Mon, 25 Feb 2013 09:25:48 +0100 (CET) Message-ID: <512B2006.7070903@globis.net> Date: Mon, 25 Feb 2013 09:25:42 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Lorenzo Colitti References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> <51276A40.5020705@globis.net> <3E23756C-A4E4-4D48-B534-EAB191F1AA48@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ole Troan , "isis-chairs@tools.ietf.org" , "ospf-chairs@tools.ietf.org" , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , "Abhay Roy \(akr\)" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:34:02 -0000 > Lorenzo Colitti > 25 February 2013 01:50 > On Fri, Feb 22, 2013 at 10:06 PM, Ole Troan > wrote: > > > IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with > > autoconfiguration and on-link flags set, and configure /64 > prefixes from > > both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know > these > > as being on-link. > > > > But IMHO there's no further AS number/provider information/upstream > > topology information coupled to these /64 prefixes. There might be a > > router-router interconnect LAN between R1 and R2, or there might > not be. > > if there is no interconnect between R1 and R2, then the host has two > interfaces connected to two separate connections. then I can't see how > that can be solved in the network. my assumption is that all > homenet routers must be connected (I see I haven't stated that > anywhere, but that should be added). > > > Do we really need this? > Actually I meant a connection between 2 routers higher up the topology i.e. not one where the only common connection between CER1 and CER2 is also shared with (local) end hosts on the same LAN. But the discussion has gone the right way anyway. > When I originally put together the strawman it seemed to me that there > are only two cases: either the two border routers have a path to each > other, or they don't. If they do not have a path to each other, then > the host cannot be connected to both routers using the same interface > - because if it is, it's a broadcast interface and those two routers > are also connected to each other. > > Should we write this in the draft? > Figure 2 of the architecture is the problematic one, where there are end hosts that share the only connection between 2 CERs (from competing ISPs). The end hosts do not share the same information as the 2 routers (the end hosts ignore routing, and the PIO sent by the 2 CERs are non-overlapping, as they are configured by 2 independent ASs). > > > How will the host H1 know to associate source address prefixes from > > provider2 with router2 for off link destinations e.g. to a > Provider2/56 > > or Provider2/32? > > in your case it will RFC6724, rule 5.5 > > > You don't need to invoke RFC 6724 for this. RFC 3484 (prefer outgoing > interface) is enough. We should put this in the draft though. > No. From the hosts perspective, SA & SB are on the same interface. > > > My expected host behavior would currently be that it'd just > choose one > > of the known available default routers from the list. If correct > fine. > > If not, then wait for an ICMPv6 redirect to be told to use the > other router. > > you would only get that if the routers were connected of course. > whichever came first, you'd either get a unreachable code 5 (wrong > source) > or ICMP redirect, or the router would just forward the packet to > second router. > > > Please let's not design something that requires ICMP redirects to > work. It will be slow and unreliable. > Agreed. > > > Thus H1 should never send packets with a source address derived > from a > > PIO received in an RA from R2, to a potential default router R1 that > > sent an RA message but did not include a PIO for this particular > source > > prefix? > > > > Where is this behavior defined in an RFC? I don't see it in > > http://www.ietf.org/rfc/rfc2461.txt Section 4.2 or > > http://tools.ietf.org/html/rfc4862#page-18 > > In fact section 6.3.6. on default router selection is quite > explicit and > > doesn't mention associating potential default routers with prefix > > information options at all AFAIK. > > again, that's rule 5.5 (which is somewhat weak) in 6724. > > > 3484 rule 5 too, right? Or not? Nope. You'd need the updated version of address selection (RFC6724) rule 5.5. which binds SA to next hop, rather than outbound physical interface. So this might be an issue with existing implementations, and those which do not track which prefix assignment was learned from which next hop. An alternative would be that CER1 learns prefixes from CER2, and configures up addresses from the competitor ISP on its own router, (potentially accepting a candidate default route too if its own WAN link goes down), which might be problematic from a management and operations perspective e.g. if CER1 is also providing ISP1 specific services like TV or telephony. Which is why I've raised concerns about the definition of the Homenet border in the architecture document. This never came into play in 6204 (single router, single AS) > Ole Troan > 22 February 2013 14:06 > Ray, > > [...] > >>> 2. Aren't we forgetting the first hop? >>> >>> Given a shared subnet/prefix/link with 2 CPE routers performing some >>> fancy new form of forwarding (based on PBR or SADR or whatever) >>> that is >>> also shared by existing host implementations, how will the routers >>> signal these new default route semantics to end hosts? >>> >>> Would we need a new prefix information option in ND? >>> >>> Would we need an extension to RFC 4191 Section 2.3 Route Information >>> Option to include (source prefix,destination prefix) routes? >>> >>> Would we need a new ICMPv6 redirect message to extend RFC2461 Section >>> 4.5 to include the possibility of (source,destination) redirects? >>> >>> >>> The beauty of this approach is that you don't need to signal anything >>> to the hosts for things to work properly. The hosts pick whatever >>> source address they choose and the network takes care of getting the >>> packet to the right exit. >>> >> Don't understand. Maybe I'm being really dumb. >> >> What about figure 2 of the Homenet Architecture? >> >> +-------+-------+ +-------+-------+ \ >> | Service | | Service | \ >> | Provider A | | Provider B | | Service >> | Router | | Router | | Provider >> +------+--------+ +-------+-------+ | network >> | | / >> | Customer | / >> | Internet connections | / >> | | >> +------+--------+ +-------+-------+ \ >> | IPv6 | | IPv6 | \ >> | Customer Edge | | Customer Edge | \ >> | Router 1 | | Router 2 | / >> +------+--------+ +-------+-------+ / >> | | / >> | | | End-User >> ---+---------+---+---------------+--+----------+--- | network(s) >> | | | | \ >> +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ >> |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / >> | H1 | | H2 | | H3 | | H4 | / >> +----------+ +----------+ +----------+ +----------+ >> >> Figure 2 >> >> >> >> IPv6 Host H1 will receive RA messages from R1 and R2, and add them both >> to the default router list (RFC2461 6.3.6). >> >> IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with >> autoconfiguration and on-link flags set, and configure /64 prefixes from >> both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these >> as being on-link. >> >> But IMHO there's no further AS number/provider information/upstream >> topology information coupled to these /64 prefixes. There might be a >> router-router interconnect LAN between R1 and R2, or there might not be. > > if there is no interconnect between R1 and R2, then the host has two > interfaces connected to two separate connections. then I can't see how > that can be solved in the network. my assumption is that all homenet routers > must be connected (I see I haven't stated that anywhere, but that should be added). > >> How will the host H1 know to associate source address prefixes from >> provider2 with router2 for off link destinations e.g. to a Provider2/56 >> or Provider2/32? > > in your case it will RFC6724, rule 5.5 > >> My expected host behavior would currently be that it'd just choose one >> of the known available default routers from the list. If correct fine. >> If not, then wait for an ICMPv6 redirect to be told to use the other router. > > you would only get that if the routers were connected of course. > whichever came first, you'd either get a unreachable code 5 (wrong source) > or ICMP redirect, or the router would just forward the packet to second router. > >> But the ICMPv6 redirect doesn't have any facility to include source >> prefix specific info: only a redirect for a destination prefix to use >> another router (for all source prefixes), not for a source/destination >> pair. In the situation depicted in Homenet Arch figure 2, there will >> almost certainly be two valid routes to e.g. www.google.com, one via >> each provider, with the correct 1st hop router dependent purely on the >> source prefix. > > I agree, there is nothing useful the host learns from an ICMP redirect here. > >> Even with RFC4191, the extension only provides routing information for a >> host to be able to select a default router based on the destination >> prefix, not an associated source prefix. >> >> Are we saying that H1 should tightly couple source address selection >> with RA PIO & default router selection? > > for directly connected hosts, we have that already. note that only applies when > hosts are connected to the border router. > >> Thus H1 should never send packets with a source address derived from a >> PIO received in an RA from R2, to a potential default router R1 that >> sent an RA message but did not include a PIO for this particular source >> prefix? >> >> Where is this behavior defined in an RFC? I don't see it in >> http://www.ietf.org/rfc/rfc2461.txt Section 4.2 or >> http://tools.ietf.org/html/rfc4862#page-18 >> In fact section 6.3.6. on default router selection is quite explicit and >> doesn't mention associating potential default routers with prefix >> information options at all AFAIK. > > again, that's rule 5.5 (which is somewhat weak) in 6724. > >> Are we saying that R1 should forward any packets it receives for >> (source_provider_prefix 2, ::/0) back over the same LAN to R2 without an >> ICMPv6 redirect? [Assuming R1 is managed by Provider 1 and R2 is managed >> by Provider 2] > > yes, I think we probably would want to say that. > >> Won't the providers naturally want to apply their BCP38 ingress filter >> on the LAN interface of their CPE routers? >> as per draft-ietf-v6ops-6204bis-12 L-14 [LAN side requirements] >> >> The IPv6 CE router MUST send an ICMPv6 Destination Unreachable >> message, code 5 (Source address failed ingress/egress policy) >> for packets forwarded to it that use an address from a prefix >> that has been invalidated. >> >> >>> If the right exit is down or gone, then the packet gets dropped, but >>> as the SADR draft explains, you can fix this by telling the homenet >>> routers to deprecate prefixes for which there is no exit. The hosts >>> will then avoid those source addresses for new connections. (The >>> authors of said draft do not agree amongst themselves whether this is >>> the right thing to do or not; but no doubt the WG will have useful >>> opinions here). >>> >> Understand this. It's the first hop that bother me. >> >> Maybe Figure 2 in the Homenet Architecture is actually a fundamentally >> flawed topology, purely from a management perspective. >>> If you want the hosts to do better load-balancing, then you do need to >>> give them more information. We haven't looked at this. >>> >>> If you want to support walled garden prefixes that do not have >>> complete reachability, then you need to tell the hosts not to use >>> them. I believe DHCPv6 options exist to configure RFC 6724 policy on >>> hosts, but I don't know if anyone supports them, and I haven't thought >>> about the security issues or how to propagate that information through >>> the homenet. >>> >>> 3. Limiting this discussion strictly to Homenet requirements: >>> Aren't we >>> forgetting the inter-provider management boundary? >>> >>> My view of the Homenet is a network that is potentially a member of >>> multiple overlapping AS's simultaneously, without being an AS itself. >>> That's highly unusual in routing protocol terms. >>> >>> I think that it is very unlikely that any operator will allow any >>> dynamic routing between a CPE managed by a customer and a PE >>> managed by >>> the provider. >>> >>> I think there's also a potential issue of anyone making any >>> assumptions >>> about dynamic routing being available between a provider-managed >>> CPE and >>> a customer owned CPE. Software version control will not be trivial. >>> >>> The current most likely source of external routing information is >>> DHCPv6-PD, used to locally autoconfigure a "floating static" default >>> route on the Homenet BR, pointing out of the upstream interface to >>> "the >>> Internet". >>> >>> As such, how will any routing information beyond a simple default >>> route >>> (related to a single delegated prefix) be injected into the Homenet? >>> >>> Why are we importing the extra complexity (related to data centres and >>> enterprises) into Homenet? >>> >>> >>> I thought the idea was that border routers would just do DHCPv6 PD and >>> inject whatever routes they get into the homenet tagged with whatever >>> source prefix they get. >> Yes. >>> They wouldn't participate in any routing protocol with the ISP. We >>> don't currently have any other mechanism for learning external routes, >>> but when we do we can simply treat them in the same way. >>> >>> Does this not work for some reason? >>> >> No problem, but why worry about it now if it greatly increases the >> complexity? >> >> draft-ietf-v6ops-6204bis-12 effectively limits information in Homenet to >> simple default routes per provider only. >> >> W-3: Absent other routing information, the IPv6 CE router MUST use >> Router Discovery as specified in [RFC4861] to discover a >> default router(s) and install default route(s) in its routing >> table with the discovered router's address as the next hop. >> >> WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic >> routing protocol on its WAN interface. > > but 6204 does support more specific routes in RAs (RFC4191?) > >>> 6. Other potentially simpler approaches that might be faster to market >>> I have provided detailed feedback to Ole & Lorenzo, suggesting how >>> Homenet could potentially work without modifying any routing protocols >>> at all, with multi-homing, without resorting to NPT, and with BCP38 >>> ingress/egress filters (albeit with a hard link to some >>> yet-to-be-defined autoconfiguration protocol, and a limit that the >>> prefixes of any walled-gardens must be disjoint from other AS's >>> directly >>> connected to this Homenet, and possibly some other limitations such as >>> dumb hosts should not be connected to dual routers from competing >>> providers). >>> >>> >>> Did I miss this? Where can I find it? Was it sent to the list? >> Yes. http://www.ietf.org/mail-archive/web/homenet/current/msg02130.html >>> Ray Hunter >>> 22 February 2013 10:52 >>> I have read all of your drafts, and those of the other authors, >>> carefully, once. No doubt I'll have to re-read them. >>> >>> This response is limited to high level comments regarding the overall >>> approach, and isprobably applicable to all 3 sets of authors : >>> >>> 1. Some drafts talk extensively about the need for an "extensible" >>> routing protocol, and often mention the desirability of TLV >>> (type-length-value) objects. >>> >>> I agree that a TLV structure potentially solves many issues of how to >>> encode and transport new options between routing protocol speakers. >>> >>> But given that route determination is a distributed algorithm, and that >>> Homenet devices will not always run the latest and greatest code, >>> what action should nodes that are running older code take regarding any >>> TLV options that they don't understand? >>> >>> Isn't there a danger that extensibility will lead to more routing loops, >>> instability, and black holes? >>> >>> Is there a need for all speakers to first agree the (newest) >>> commonly-understood subset of options that all speakers in a Homenet >>> can/will honour before any extension options are transmitted? >>> >>> 2. Aren't we forgetting the first hop? >>> >>> Given a shared subnet/prefix/link with 2 CPE routers performing some >>> fancy new form of forwarding (based on PBR or SADR or whatever) that is >>> also shared by existing host implementations, how will the routers >>> signal these new default route semantics to end hosts? >>> >>> Would we need a new prefix information option in ND? >>> >>> Would we need an extension to RFC 4191 Section 2.3 Route Information >>> Option to include (source prefix,destination prefix) routes? >>> >>> Would we need a new ICMPv6 redirect message to extend RFC2461 Section >>> 4.5 to include the possibility of (source,destination) redirects? >>> >>> 3. Limiting this discussion strictly to Homenet requirements: Aren't we >>> forgetting the inter-provider management boundary? >>> >>> My view of the Homenet is a network that is potentially a member of >>> multiple overlapping AS's simultaneously, without being an AS itself. >>> That's highly unusual in routing protocol terms. >>> >>> I think that it is very unlikely that any operator will allow any >>> dynamic routing between a CPE managed by a customer and a PE managed by >>> the provider. >>> >>> I think there's also a potential issue of anyone making any assumptions >>> about dynamic routing being available between a provider-managed CPE and >>> a customer owned CPE. Software version control will not be trivial. >>> >>> The current most likely source of external routing information is >>> DHCPv6-PD, used to locally autoconfigure a "floating static" default >>> route on the Homenet BR, pointing out of the upstream interface to "the >>> Internet". >>> >>> As such, how will any routing information beyond a simple default route >>> (related to a single delegated prefix) be injected into the Homenet? >>> >>> Why are we importing the extra complexity (related to data centres and >>> enterprises) into Homenet? >>> >>> 4. We're still planning on doing something about source address >>> selection, aren't we? >>> For all the suggested complexity of the packet routing solutions >>> suggested so far, isn't the real "route" selection going to be performed >>> in the host? >>> >>> 5. Flow label routing: hasn't rfc6437 scuppered any chance that the flow >>> labels themselves will directly carry any meaning that could be >>> realistically used to make deterministic forwarding decisions by >>> low/mid-powered routers, because you're essentially going to have to >>> reverse a 20 bit hash function to make a forwarding decision? Wouldn't >>> the requirements in rfc6437 also suggest a routing table explosion, >>> because each individual flow would have to be associated with an >>> individual IS-IS route? Perhaps you could distribute some intermediate >>> result to end hosts and routers via IS-IS,which is deterministic and >>> related to policy based routing (such as including the tenant label in a >>> TLV), but which after applying some hash transform and adding some >>> entropy, would comply with the requirements of 6437? That'd potentially >>> reduce the IS-IS routing table size dramatically. I've been waiting 15+ >>> years for fully dynamic PBR and I fully expect to wait some time longer. >>> In any case, with all due respect, I don't think it's relevant for >>> Homenet, >>> >>> 6. Other potentially simpler approaches that might be faster to market >>> I have provided detailed feedback to Ole & Lorenzo, suggesting how >>> Homenet could potentially work without modifying any routing protocols >>> at all, with multi-homing, without resorting to NPT, and with BCP38 >>> ingress/egress filters (albeit with a hard link to some >>> yet-to-be-defined autoconfiguration protocol, and a limit that the >>> prefixes of any walled-gardens must be disjoint from other AS's directly >>> connected to this Homenet, and possibly some other limitations such as >>> dumb hosts should not be connected to dual routers from competing >>> providers). >>> >>> Do I need to write a draft on this, or is this already clear? >>> Would someone be willing to help out/ collaborate? >>> >>> If I have other detailed comments on the individual drafts, I'll come >>> back with those. >>> >>> regards, >>> RayH >>> >>> Fred Baker (fred) wrote: >>> >>> ------------------------------------------------------------------------ > > > cheers, > Ole > > Ray Hunter > 22 February 2013 13:53 >> Lorenzo Colitti >> 22 February 2013 11:17 >> On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter > > wrote: >> >> But given that route determination is a distributed algorithm, and >> that >> Homenet devices will not always run the latest and greatest code, >> what action should nodes that are running older code take >> regarding any >> TLV options that they don't understand? >> >> Isn't there a danger that extensibility will lead to more routing >> loops, >> instability, and black holes? >> >> >> Yes. If intermediate devices don't understand SADR, you can get >> routing loops. We should document that clearly and find out how to >> avoid it. >> > ACK. >> 2. Aren't we forgetting the first hop? >> >> Given a shared subnet/prefix/link with 2 CPE routers performing some >> fancy new form of forwarding (based on PBR or SADR or whatever) >> that is >> also shared by existing host implementations, how will the routers >> signal these new default route semantics to end hosts? >> >> Would we need a new prefix information option in ND? >> >> Would we need an extension to RFC 4191 Section 2.3 Route Information >> Option to include (source prefix,destination prefix) routes? >> >> Would we need a new ICMPv6 redirect message to extend RFC2461 Section >> 4.5 to include the possibility of (source,destination) redirects? >> >> >> The beauty of this approach is that you don't need to signal anything >> to the hosts for things to work properly. The hosts pick whatever >> source address they choose and the network takes care of getting the >> packet to the right exit. >> > Don't understand. Maybe I'm being really dumb. > > What about figure 2 of the Homenet Architecture? > > +-------+-------+ +-------+-------+ \ > | Service | | Service | \ > | Provider A | | Provider B | | Service > | Router | | Router | | Provider > +------+--------+ +-------+-------+ | network > | | / > | Customer | / > | Internet connections | / > | | > +------+--------+ +-------+-------+ \ > | IPv6 | | IPv6 | \ > | Customer Edge | | Customer Edge | \ > | Router 1 | | Router 2 | / > +------+--------+ +-------+-------+ / > | | / > | | | End-User > ---+---------+---+---------------+--+----------+--- | network(s) > | | | | \ > +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ > |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / > | H1 | | H2 | | H3 | | H4 | / > +----------+ +----------+ +----------+ +----------+ > > Figure 2 > > > > IPv6 Host H1 will receive RA messages from R1 and R2, and add them both > to the default router list (RFC2461 6.3.6). > > IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with > autoconfiguration and on-link flags set, and configure /64 prefixes from > both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these > as being on-link. > > But IMHO there's no further AS number/provider information/upstream > topology information coupled to these /64 prefixes. There might be a > router-router interconnect LAN between R1 and R2, or there might not be. > > How will the host H1 know to associate source address prefixes from > provider2 with router2 for off link destinations e.g. to a Provider2/56 > or Provider2/32? > > My expected host behavior would currently be that it'd just choose one > of the known available default routers from the list. If correct fine. > If not, then wait for an ICMPv6 redirect to be told to use the other router. > > But the ICMPv6 redirect doesn't have any facility to include source > prefix specific info: only a redirect for a destination prefix to use > another router (for all source prefixes), not for a source/destination > pair. In the situation depicted in Homenet Arch figure 2, there will > almost certainly be two valid routes to e.g. www.google.com, one via > each provider, with the correct 1st hop router dependent purely on the > source prefix. > > Even with RFC4191, the extension only provides routing information for a > host to be able to select a default router based on the destination > prefix, not an associated source prefix. > > Are we saying that H1 should tightly couple source address selection > with RA PIO & default router selection? > > Thus H1 should never send packets with a source address derived from a > PIO received in an RA from R2, to a potential default router R1 that > sent an RA message but did not include a PIO for this particular source > prefix? > > Where is this behavior defined in an RFC? I don't see it in > http://www.ietf.org/rfc/rfc2461.txt Section 4.2 or > http://tools.ietf.org/html/rfc4862#page-18 > In fact section 6.3.6. on default router selection is quite explicit and > doesn't mention associating potential default routers with prefix > information options at all AFAIK. > > Are we saying that R1 should forward any packets it receives for > (source_provider_prefix 2, ::/0) back over the same LAN to R2 without an > ICMPv6 redirect? [Assuming R1 is managed by Provider 1 and R2 is managed > by Provider 2] > > Won't the providers naturally want to apply their BCP38 ingress filter > on the LAN interface of their CPE routers? > as per draft-ietf-v6ops-6204bis-12 L-14 [LAN side requirements] > > The IPv6 CE router MUST send an ICMPv6 Destination Unreachable > message, code 5 (Source address failed ingress/egress policy) > for packets forwarded to it that use an address from a prefix > that has been invalidated. > > >> If the right exit is down or gone, then the packet gets dropped, but >> as the SADR draft explains, you can fix this by telling the homenet >> routers to deprecate prefixes for which there is no exit. The hosts >> will then avoid those source addresses for new connections. (The >> authors of said draft do not agree amongst themselves whether this is >> the right thing to do or not; but no doubt the WG will have useful >> opinions here). >> > Understand this. It's the first hop that bother me. > > Maybe Figure 2 in the Homenet Architecture is actually a fundamentally > flawed topology, purely from a management perspective. >> If you want the hosts to do better load-balancing, then you do need to >> give them more information. We haven't looked at this. >> >> If you want to support walled garden prefixes that do not have >> complete reachability, then you need to tell the hosts not to use >> them. I believe DHCPv6 options exist to configure RFC 6724 policy on >> hosts, but I don't know if anyone supports them, and I haven't thought >> about the security issues or how to propagate that information through >> the homenet. >> >> 3. Limiting this discussion strictly to Homenet requirements: >> Aren't we >> forgetting the inter-provider management boundary? >> >> My view of the Homenet is a network that is potentially a member of >> multiple overlapping AS's simultaneously, without being an AS itself. >> That's highly unusual in routing protocol terms. >> >> I think that it is very unlikely that any operator will allow any >> dynamic routing between a CPE managed by a customer and a PE >> managed by >> the provider. >> >> I think there's also a potential issue of anyone making any >> assumptions >> about dynamic routing being available between a provider-managed >> CPE and >> a customer owned CPE. Software version control will not be trivial. >> >> The current most likely source of external routing information is >> DHCPv6-PD, used to locally autoconfigure a "floating static" default >> route on the Homenet BR, pointing out of the upstream interface to >> "the >> Internet". >> >> As such, how will any routing information beyond a simple default >> route >> (related to a single delegated prefix) be injected into the Homenet? >> >> Why are we importing the extra complexity (related to data centres and >> enterprises) into Homenet? >> >> >> I thought the idea was that border routers would just do DHCPv6 PD and >> inject whatever routes they get into the homenet tagged with whatever >> source prefix they get. > Yes. >> They wouldn't participate in any routing protocol with the ISP. We >> don't currently have any other mechanism for learning external routes, >> but when we do we can simply treat them in the same way. >> >> Does this not work for some reason? >> > No problem, but why worry about it now if it greatly increases the > complexity? > > draft-ietf-v6ops-6204bis-12 effectively limits information in Homenet to > simple default routes per provider only. > > W-3: Absent other routing information, the IPv6 CE router MUST use > Router Discovery as specified in [RFC4861] to discover a > default router(s) and install default route(s) in its routing > table with the discovered router's address as the next hop. > > WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic > routing protocol on its WAN interface. >> 6. Other potentially simpler approaches that might be faster to market >> I have provided detailed feedback to Ole & Lorenzo, suggesting how >> Homenet could potentially work without modifying any routing protocols >> at all, with multi-homing, without resorting to NPT, and with BCP38 >> ingress/egress filters (albeit with a hard link to some >> yet-to-be-defined autoconfiguration protocol, and a limit that the >> prefixes of any walled-gardens must be disjoint from other AS's >> directly >> connected to this Homenet, and possibly some other limitations such as >> dumb hosts should not be connected to dual routers from competing >> providers). >> >> >> Did I miss this? Where can I find it? Was it sent to the list? > Yes. http://www.ietf.org/mail-archive/web/homenet/current/msg02130.html >> Ray Hunter >> 22 February 2013 10:52 >> I have read all of your drafts, and those of the other authors, >> carefully, once. No doubt I'll have to re-read them. >> >> This response is limited to high level comments regarding the overall >> approach, and isprobably applicable to all 3 sets of authors : >> >> 1. Some drafts talk extensively about the need for an "extensible" >> routing protocol, and often mention the desirability of TLV >> (type-length-value) objects. >> >> I agree that a TLV structure potentially solves many issues of how to >> encode and transport new options between routing protocol speakers. >> >> But given that route determination is a distributed algorithm, and that >> Homenet devices will not always run the latest and greatest code, >> what action should nodes that are running older code take regarding any >> TLV options that they don't understand? >> >> Isn't there a danger that extensibility will lead to more routing loops, >> instability, and black holes? >> >> Is there a need for all speakers to first agree the (newest) >> commonly-understood subset of options that all speakers in a Homenet >> can/will honour before any extension options are transmitted? >> >> 2. Aren't we forgetting the first hop? >> >> Given a shared subnet/prefix/link with 2 CPE routers performing some >> fancy new form of forwarding (based on PBR or SADR or whatever) that is >> also shared by existing host implementations, how will the routers >> signal these new default route semantics to end hosts? >> >> Would we need a new prefix information option in ND? >> >> Would we need an extension to RFC 4191 Section 2.3 Route Information >> Option to include (source prefix,destination prefix) routes? >> >> Would we need a new ICMPv6 redirect message to extend RFC2461 Section >> 4.5 to include the possibility of (source,destination) redirects? >> >> 3. Limiting this discussion strictly to Homenet requirements: Aren't we >> forgetting the inter-provider management boundary? >> >> My view of the Homenet is a network that is potentially a member of >> multiple overlapping AS's simultaneously, without being an AS itself. >> That's highly unusual in routing protocol terms. >> >> I think that it is very unlikely that any operator will allow any >> dynamic routing between a CPE managed by a customer and a PE managed by >> the provider. >> >> I think there's also a potential issue of anyone making any assumptions >> about dynamic routing being available between a provider-managed CPE and >> a customer owned CPE. Software version control will not be trivial. >> >> The current most likely source of external routing information is >> DHCPv6-PD, used to locally autoconfigure a "floating static" default >> route on the Homenet BR, pointing out of the upstream interface to "the >> Internet". >> >> As such, how will any routing information beyond a simple default route >> (related to a single delegated prefix) be injected into the Homenet? >> >> Why are we importing the extra complexity (related to data centres and >> enterprises) into Homenet? >> >> 4. We're still planning on doing something about source address >> selection, aren't we? >> For all the suggested complexity of the packet routing solutions >> suggested so far, isn't the real "route" selection going to be performed >> in the host? >> >> 5. Flow label routing: hasn't rfc6437 scuppered any chance that the flow >> labels themselves will directly carry any meaning that could be >> realistically used to make deterministic forwarding decisions by >> low/mid-powered routers, because you're essentially going to have to >> reverse a 20 bit hash function to make a forwarding decision? Wouldn't >> the requirements in rfc6437 also suggest a routing table explosion, >> because each individual flow would have to be associated with an >> individual IS-IS route? Perhaps you could distribute some intermediate >> result to end hosts and routers via IS-IS,which is deterministic and >> related to policy based routing (such as including the tenant label in a >> TLV), but which after applying some hash transform and adding some >> entropy, would comply with the requirements of 6437? That'd potentially >> reduce the IS-IS routing table size dramatically. I've been waiting 15+ >> years for fully dynamic PBR and I fully expect to wait some time longer. >> In any case, with all due respect, I don't think it's relevant for >> Homenet, >> >> 6. Other potentially simpler approaches that might be faster to market >> I have provided detailed feedback to Ole & Lorenzo, suggesting how >> Homenet could potentially work without modifying any routing protocols >> at all, with multi-homing, without resorting to NPT, and with BCP38 >> ingress/egress filters (albeit with a hard link to some >> yet-to-be-defined autoconfiguration protocol, and a limit that the >> prefixes of any walled-gardens must be disjoint from other AS's directly >> connected to this Homenet, and possibly some other limitations such as >> dumb hosts should not be connected to dual routers from competing >> providers). >> >> Do I need to write a draft on this, or is this already clear? >> Would someone be willing to help out/ collaborate? >> >> If I have other detailed comments on the individual drafts, I'll come >> back with those. >> >> regards, >> RayH >> >> Fred Baker (fred) wrote: >> >> ------------------------------------------------------------------------ > > Lorenzo Colitti > 22 February 2013 11:17 > On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter > wrote: > > But given that route determination is a distributed algorithm, and > that > Homenet devices will not always run the latest and greatest code, > what action should nodes that are running older code take > regarding any > TLV options that they don't understand? > > Isn't there a danger that extensibility will lead to more routing > loops, > instability, and black holes? > > > Yes. If intermediate devices don't understand SADR, you can get > routing loops. We should document that clearly and find out how to > avoid it. > > > 2. Aren't we forgetting the first hop? > > Given a shared subnet/prefix/link with 2 CPE routers performing some > fancy new form of forwarding (based on PBR or SADR or whatever) > that is > also shared by existing host implementations, how will the routers > signal these new default route semantics to end hosts? > > Would we need a new prefix information option in ND? > > Would we need an extension to RFC 4191 Section 2.3 Route Information > Option to include (source prefix,destination prefix) routes? > > Would we need a new ICMPv6 redirect message to extend RFC2461 Section > 4.5 to include the possibility of (source,destination) redirects? > > > The beauty of this approach is that you don't need to signal anything > to the hosts for things to work properly. The hosts pick whatever > source address they choose and the network takes care of getting the > packet to the right exit. > > If the right exit is down or gone, then the packet gets dropped, but > as the SADR draft explains, you can fix this by telling the homenet > routers to deprecate prefixes for which there is no exit. The hosts > will then avoid those source addresses for new connections. (The > authors of said draft do not agree amongst themselves whether this is > the right thing to do or not; but no doubt the WG will have useful > opinions here). > > If you want the hosts to do better load-balancing, then you do need to > give them more information. We haven't looked at this. > > If you want to support walled garden prefixes that do not have > complete reachability, then you need to tell the hosts not to use > them. I believe DHCPv6 options exist to configure RFC 6724 policy on > hosts, but I don't know if anyone supports them, and I haven't thought > about the security issues or how to propagate that information through > the homenet. > > 3. Limiting this discussion strictly to Homenet requirements: > Aren't we > forgetting the inter-provider management boundary? > > My view of the Homenet is a network that is potentially a member of > multiple overlapping AS's simultaneously, without being an AS itself. > That's highly unusual in routing protocol terms. > > I think that it is very unlikely that any operator will allow any > dynamic routing between a CPE managed by a customer and a PE > managed by > the provider. > > I think there's also a potential issue of anyone making any > assumptions > about dynamic routing being available between a provider-managed > CPE and > a customer owned CPE. Software version control will not be trivial. > > The current most likely source of external routing information is > DHCPv6-PD, used to locally autoconfigure a "floating static" default > route on the Homenet BR, pointing out of the upstream interface to > "the > Internet". > > As such, how will any routing information beyond a simple default > route > (related to a single delegated prefix) be injected into the Homenet? > > Why are we importing the extra complexity (related to data centres and > enterprises) into Homenet? > > > I thought the idea was that border routers would just do DHCPv6 PD and > inject whatever routes they get into the homenet tagged with whatever > source prefix they get. They wouldn't participate in any routing > protocol with the ISP. We don't currently have any other mechanism for > learning external routes, but when we do we can simply treat them in > the same way. > > Does this not work for some reason? > > 6. Other potentially simpler approaches that might be faster to market > I have provided detailed feedback to Ole & Lorenzo, suggesting how > Homenet could potentially work without modifying any routing protocols > at all, with multi-homing, without resorting to NPT, and with BCP38 > ingress/egress filters (albeit with a hard link to some > yet-to-be-defined autoconfiguration protocol, and a limit that the > prefixes of any walled-gardens must be disjoint from other AS's > directly > connected to this Homenet, and possibly some other limitations such as > dumb hosts should not be connected to dual routers from competing > providers). > > > Did I miss this? Where can I find it? Was it sent to the list? > Ray Hunter > 22 February 2013 10:52 > I have read all of your drafts, and those of the other authors, > carefully, once. No doubt I'll have to re-read them. > > This response is limited to high level comments regarding the overall > approach, and isprobably applicable to all 3 sets of authors : > > 1. Some drafts talk extensively about the need for an "extensible" > routing protocol, and often mention the desirability of TLV > (type-length-value) objects. > > I agree that a TLV structure potentially solves many issues of how to > encode and transport new options between routing protocol speakers. > > But given that route determination is a distributed algorithm, and that > Homenet devices will not always run the latest and greatest code, > what action should nodes that are running older code take regarding any > TLV options that they don't understand? > > Isn't there a danger that extensibility will lead to more routing loops, > instability, and black holes? > > Is there a need for all speakers to first agree the (newest) > commonly-understood subset of options that all speakers in a Homenet > can/will honour before any extension options are transmitted? > > 2. Aren't we forgetting the first hop? > > Given a shared subnet/prefix/link with 2 CPE routers performing some > fancy new form of forwarding (based on PBR or SADR or whatever) that is > also shared by existing host implementations, how will the routers > signal these new default route semantics to end hosts? > > Would we need a new prefix information option in ND? > > Would we need an extension to RFC 4191 Section 2.3 Route Information > Option to include (source prefix,destination prefix) routes? > > Would we need a new ICMPv6 redirect message to extend RFC2461 Section > 4.5 to include the possibility of (source,destination) redirects? > > 3. Limiting this discussion strictly to Homenet requirements: Aren't we > forgetting the inter-provider management boundary? > > My view of the Homenet is a network that is potentially a member of > multiple overlapping AS's simultaneously, without being an AS itself. > That's highly unusual in routing protocol terms. > > I think that it is very unlikely that any operator will allow any > dynamic routing between a CPE managed by a customer and a PE managed by > the provider. > > I think there's also a potential issue of anyone making any assumptions > about dynamic routing being available between a provider-managed CPE and > a customer owned CPE. Software version control will not be trivial. > > The current most likely source of external routing information is > DHCPv6-PD, used to locally autoconfigure a "floating static" default > route on the Homenet BR, pointing out of the upstream interface to "the > Internet". > > As such, how will any routing information beyond a simple default route > (related to a single delegated prefix) be injected into the Homenet? > > Why are we importing the extra complexity (related to data centres and > enterprises) into Homenet? > > 4. We're still planning on doing something about source address > selection, aren't we? > For all the suggested complexity of the packet routing solutions > suggested so far, isn't the real "route" selection going to be performed > in the host? > > 5. Flow label routing: hasn't rfc6437 scuppered any chance that the flow > labels themselves will directly carry any meaning that could be > realistically used to make deterministic forwarding decisions by > low/mid-powered routers, because you're essentially going to have to > reverse a 20 bit hash function to make a forwarding decision? Wouldn't > the requirements in rfc6437 also suggest a routing table explosion, > because each individual flow would have to be associated with an > individual IS-IS route? Perhaps you could distribute some intermediate > result to end hosts and routers via IS-IS,which is deterministic and > related to policy based routing (such as including the tenant label in a > TLV), but which after applying some hash transform and adding some > entropy, would comply with the requirements of 6437? That'd potentially > reduce the IS-IS routing table size dramatically. I've been waiting 15+ > years for fully dynamic PBR and I fully expect to wait some time longer. > In any case, with all due respect, I don't think it's relevant for > Homenet, > > 6. Other potentially simpler approaches that might be faster to market > I have provided detailed feedback to Ole & Lorenzo, suggesting how > Homenet could potentially work without modifying any routing protocols > at all, with multi-homing, without resorting to NPT, and with BCP38 > ingress/egress filters (albeit with a hard link to some > yet-to-be-defined autoconfiguration protocol, and a limit that the > prefixes of any walled-gardens must be disjoint from other AS's directly > connected to this Homenet, and possibly some other limitations such as > dumb hosts should not be connected to dual routers from competing > providers). > > Do I need to write a draft on this, or is this already clear? > Would someone be willing to help out/ collaborate? > > If I have other detailed comments on the individual drafts, I'll come > back with those. > > regards, > RayH > > Fred Baker (fred) wrote: > > ------------------------------------------------------------------------ From lorenzo@google.com Mon Feb 25 00:48:19 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB5121F91BA for ; Mon, 25 Feb 2013 00:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.959 X-Spam-Level: X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVhellgHoWCb for ; Mon, 25 Feb 2013 00:48:18 -0800 (PST) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id ACA1321F91B0 for ; Mon, 25 Feb 2013 00:48:18 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id o6so2668990oag.18 for ; Mon, 25 Feb 2013 00:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=uwWCXfzPlnwJHSBDbv5brtSYHUB2+mSPrAGw+0q3z2A=; b=IiebZhwIHNYhkCTAy7Z1+p83+Uem/MetnPnt35X5R7w5cIHki4zwT7Xb/eHKwqcIuD KU/CINv+mcK9jl7iZvu4IwGEKVVCPdjFmWybPOSfBJw4Aspu/kUR3eWmGabRWi8VBZC2 lY7wrIBsDoksEAguGioYoM+SO0uOPjWLKelwNjyDTF+7A/9Ku1/SrOM7cWtkpQCMztZb jWSOU5W+gW49JJRexMQ0d6JXd98fOVe27mv47qfVSeeyS1UkDNVaNCh3PEg3tem3VFFl RO+YC2f3azb0ITb8a2/KQvJAAZhFRIKUvE9bntFq12eQBJf7aSrWd5tmaeLh5ARl6d7D VNrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=uwWCXfzPlnwJHSBDbv5brtSYHUB2+mSPrAGw+0q3z2A=; b=Lpgq1kd9RG/an5N2SLjLcAHGrwQvOyQ3Ik3s7qL56DhcJHGsD2KSEoIMY4frmSN7Bk SdLTkejXRdI3cjIqkONCPQC+5iHMPBCLStR+oaT2lHK2KzmCtk/SqfcHqJPu+FTsMyRT zh0oY3Z56X0EGi0Nuyp57tMfZU41ezzc+cmHQoAF/Fad762zx6qxosSP/qHgf7dlHs7I k+XN6sdHXV8eb9Voii7VBTDs+6SITWM+xeTwEAVQGXQ/q/7WRy7rigKuOLWKXmqNdwXD z5fLfIV/An9ndtmu0oCCzCYZ1oHlEKMmr5PZD1GtaJi8ADALmGRAC4CQA3sYMoZoCj4u EjAQ== X-Received: by 10.60.20.193 with SMTP id p1mr123oee.133.1361782097925; Mon, 25 Feb 2013 00:48:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Mon, 25 Feb 2013 00:47:57 -0800 (PST) In-Reply-To: <512B2006.7070903@globis.net> References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> <51276A40.5020705@globis.net> <3E23756C-A4E4-4D48-B534-EAB191F1AA48@cisco.com> <512B2006.7070903@globis.net> From: Lorenzo Colitti Date: Mon, 25 Feb 2013 17:47:57 +0900 Message-ID: To: Ray Hunter Content-Type: multipart/alternative; boundary=e89a8ff1c2d8359d9704d6889a39 X-Gm-Message-State: ALoCoQmrhni27KxD2/+mvz+vDtMFQFlFOuDfF0+LS+hkLNtkDyBWkon3DM+9KNwVqw07mKaNv+2cyHZLgQBR5uEeUF+wYLmLjRk/L01uEqYnvrnnHNcWOFKAMLvH+Y6Fo8BXZCN1YovJRYmyQjqUIFzYxI+qPGzExiFWzAXAu/uG2W1Xy/1JcKWVO1e5HVdfCoFy9gJINPBl Cc: "isis-chairs@tools.ietf.org" , "homenet@ietf.org Group" , "ospf-chairs@tools.ietf.org" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:48:19 -0000 --e89a8ff1c2d8359d9704d6889a39 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 25, 2013 at 5:25 PM, Ray Hunter wrote: > Figure 2 of the architecture is the problematic one, where there are end > hosts that share the only connection between 2 CERs (from competing ISPs). > > The end hosts do not share the same information as the 2 routers > (the end hosts ignore routing, and the PIO sent by the 2 CERs are > non-overlapping, as they are configured by 2 independent ASs). > Maybe I don't understand the problem. You're talking about the figure in http://tools.ietf.org/html/draft-ietf-homenet-arch-07#section-3.2.2.2 , right? And your concern is: "what happens if H1 sends a packet with source address SA (assigned from ISP A) to CER2"? The answer is that at CER2, the packet will not match the default route to ISP B because the source address doesn't match. However, it matches the default route to ISP A announced by CER1. So CER2 forwards the packet to CER1, and CER1 sends it out to ISP A. Yes, it's an extra IP hop, but the packet gets to where it needs to go. No? --e89a8ff1c2d8359d9704d6889a39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 25, 2013 at 5:25 PM, Ray Hunter <v6ops@globis.= net> wrote:
Figure 2 of the architecture is the problematic one, where there are end hosts that share the only connection between 2 CERs (from competing ISPs).<= br>
The end hosts do not share the same information as the 2 routers
(the end hosts ignore routing, and the PIO sent by the 2 CERs are
non-overlapping, as they are configured by 2 independent ASs).

Maybe I don't understand the problem.=A0
<= div>
You're talking about the figure in http://tools.ietf.org/html/draft-ietf-homenet-arch-07#section-3.2.2= .2 , right? And your concern is: "what happens if H1 sends a packe= t with source address SA (assigned from ISP A) to CER2"?

The answer is that at CER2, the packet will not match t= he default route to ISP B because the source address doesn't match. How= ever, it matches the default route to ISP A announced by CER1. So CER2 forw= ards the packet to CER1, and CER1 sends it out to ISP A. Yes, it's an e= xtra IP hop, but the packet gets to where it needs to go. No?
--e89a8ff1c2d8359d9704d6889a39-- From v6ops@globis.net Mon Feb 25 01:55:48 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF21821F9277 for ; Mon, 25 Feb 2013 01:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBFg645xD9JQ for ; Mon, 25 Feb 2013 01:55:48 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id D1A1A21F9275 for ; Mon, 25 Feb 2013 01:55:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 00721870115; Mon, 25 Feb 2013 10:50:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IadoUkc2lR-P; Mon, 25 Feb 2013 10:50:03 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 1A3C5870060; Mon, 25 Feb 2013 10:50:03 +0100 (CET) Message-ID: <512B33C4.9030106@globis.net> Date: Mon, 25 Feb 2013 10:49:56 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Lorenzo Colitti References: <472E7EB7-E262-46CE-A17E-DE4C45C70566@cisco.com> <8C48B86A895913448548E6D15DA7553B79DCE3@xmb-rcd-x09.cisco.com> <51273FE8.7050302@globis.net> <51276A40.5020705@globis.net> <3E23756C-A4E4-4D48-B534-EAB191F1AA48@cisco.com> <512B2006.7070903@globis.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "isis-chairs@tools.ietf.org" , "homenet@ietf.org Group" , "ospf-chairs@tools.ietf.org" Subject: Re: [homenet] Egress Routing Discussion: Baker model X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 09:55:48 -0000 > Lorenzo Colitti > 25 February 2013 09:47 > On Mon, Feb 25, 2013 at 5:25 PM, Ray Hunter > wrote: > > Figure 2 of the architecture is the problematic one, where there > are end > hosts that share the only connection between 2 CERs (from > competing ISPs). > > The end hosts do not share the same information as the 2 routers > (the end hosts ignore routing, and the PIO sent by the 2 CERs are > non-overlapping, as they are configured by 2 independent ASs). > > > Maybe I don't understand the problem. > > You're talking about the figure in > http://tools.ietf.org/html/draft-ietf-homenet-arch-07#section-3.2.2.2 > , right? And your concern is: "what happens if H1 sends a packet with > source address SA (assigned from ISP A) to CER2"? yes. Bigger concern is that the borders of Homenet seem fuzzy, but I've expressed that elsewhere. > > The answer is that at CER2, the packet will not match the default > route to ISP B because the source address doesn't match. However, it > matches the default route to ISP A announced by CER1. So CER2 forwards > the packet to CER1, and CER1 sends it out to ISP A. Yes, it's an extra > IP hop, but the packet gets to where it needs to go. No? Thanks. That'd work (provided your draft updates/clarifies RFC2461 Section 8.2 to cover SADR so an ICMP redirect is not sent in this case, and provided BCP38 filters of RFC6204 requirement S-2 have been applied to the WAN interface, not the LAN). It would also seem to suggest that if CER1 and CER2 LAN interfaces are within the homenet boundary, that if the WAN link to CER2 failed, then CER2 would also learn a default route from CER1 (and vice versa), and any telephony traffic or management traffic generated by CER2 would also be sent to CER1 and ISP1 if it had a source address of ISP1? Suggesting ISP specific services and applications should only bind to source addresses native to their own ISP? From jhw@apple.com Mon Feb 25 11:23:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC4A21F91AC for ; Mon, 25 Feb 2013 11:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=7.521, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2g6l2E+PJ52 for ; Mon, 25 Feb 2013 11:23:44 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3591021F8E8F for ; Mon, 25 Feb 2013 11:23:44 -0800 (PST) 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 mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MIS006U9J6ZC8M2@mail-out.apple.com> for homenet@ietf.org; Mon, 25 Feb 2013 11:23:34 -0800 (PST) X-AuditID: 1180711d-b7f236d000005e0f-da-512bb9bbe8ea Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 6A.35.24079.BB9BB215; Mon, 25 Feb 2013 11:21:31 -0800 (PST) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MIS00KFSJ3UNG40@aniseed.apple.com> for homenet@ietf.org; Mon, 25 Feb 2013 11:21:31 -0800 (PST) From: james woodyatt In-reply-to: <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> Date: Mon, 25 Feb 2013 11:21:30 -0800 Message-id: <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> To: "homenet@ietf.org" X-Mailer: Apple Mail (2.1682) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUi2FAsrmu6SzvQYNYxC4v3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoEr42b/W9aC2yIVyxZuZ2xgPCvQxcjJISFgInHtRDcbhC0mceHe eiCbi0NIYAqTRO+j+0wQziwmiVm7poJVMQtoSazfeZwJxOYV0JOYuXIJK4gtLOApcbh5LVgN m4CKxLfLd8FqOAW8JRZOewNWwyKgKnFz5lpWiDnaEk/eXWCFmGMj8W/hORaIZR1MEm/nnwRr FhHQlLg0+ygTxHmyEh+utLFPYOSfheSOWUjumIVk7gJG5lWMgkWpOYmVhsZ6iQUFOal6yfm5 mxjBYVYou4Nx/0/+Q4wCHIxKPLwXW7UDhVgTy4orcw8xSnAwK4nwcmYAhXhTEiurUovy44tK c1KLDzFKc7AoifO+XKMZKCSQnliSmp2aWpBaBJNl4uCUamDceNhS4xTrYrY6Obn6DwzSUd42 5+9dOX3uiL0iG5/23rc2cwW/1Nh0S7EUHKytnXCjvnDDquT/fxtesXg0X3jw40dbSJ9Wzx/t xqk7MgNkp999cix01wIr1s55kqE7sp9Wu5ev29P2NzrmRNz6/Fij9kzOm7PLX1bfZb60wci/ cUVove2yP6eVWIozEg21mIuKEwFmjr6uLwIAAA== Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:23:45 -0000 On Feb 23, 2013, at 14:24 , Fred Baker (fred) wrote: > > One: the v6ops result reflects the operational result in the ARIN community: operators there would like to be able to allocate /56 prefixes to smaller customers and /48s to larger ones. If you want castigate someone, castigate them. I'm unable to participate in ARIN or other RIR discussions, otherwise they would have heard a bellyful from me about it. I'd castigate *them* here too, but that would be off topic. > Two: If randomization within the home is the issue, I'm not sure the difference between a /48 and a /56 is all that significant. The point I wished to make is that we don't have a reasonable expectation that the size of a HOMENET subnet identifier will ever be constant over time and across renumbering events, much less across transfers between providers. We're not even confident that a HOMENET will even be offered *any* space for a subnet identifier. As a result, it means that Automatic Prefix Management here is basically unable to do it statelessly, i.e. by randomly generating subnet numbers from an identifier space of conventional size and testing for collision before using them. Any HOMENET autoprefix system will depend on the proper configuration of a central subnet identifier registry integrated or tightly coupled with the border gateway. When new link routers arrive, they have to ask the central registry for the next available subnet identifier and take out a lease on it, just like an IPv4 host that has to maintain a lease to use its interface addresses with DHCP. When link routers leave, they have to release their lease or the network must wait for it to timeout. And what happens when a HOMENET has four link routers in it, and the ISP renumbers the delegated prefix from a /60 to a /63? Obviously, something in the network has to kick two of the routers out of the HOMENET, but which two? Does the subscriber even get to choose? Basically, we've given up on stateless router autoconfiguration in HOMENET, and we're forced into a stateful solution. There are no good choices here, and the worst case outcome is that we will force the widespread adoption of NAT66 at HOMNET borders, precisely because it may turn out that subscribers want stable subnet identifiers, and more of them than their service providers are willing to provide at reasonable price. This all happened before, and we're not showing any signs of making sure it doesn't happen again. -- james woodyatt core os networking From fred@cisco.com Mon Feb 25 13:26:08 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABC921E80DB for ; Mon, 25 Feb 2013 13:26:08 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvEnKTbr1XMH for ; Mon, 25 Feb 2013 13:26:08 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 702EE21E809D for ; Mon, 25 Feb 2013 13:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2199; q=dns/txt; s=iport; t=1361827567; x=1363037167; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Tldk/+jz+N3fSm9S01lOY4DC4pBVZHpodYRy6qtPeWA=; b=FHQqZw++59LWS+v34di9FOM2UvebGu/fbruqbXw40Zfs4NIbdFRckmLf rtVZDYAOjuKoRgm1r+80lfm6ar45bOz6QsVKYUlktW2FwpjVui+qX3DKX NmBpFXlFBT+D/rfTnMhn/U5jBV1g+L+tVF/TBHelPvREZBcW+gAHP7RPe g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFLWK1GtJV2a/2dsb2JhbAA/BsFZgQYWc4IfAQEBAwE6PwULAgEIIhQQMiUCBA4FCBOHcgbABY1ZgQICMQeCX2EDpyKDB4In X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; d="scan'208";a="180982086" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 25 Feb 2013 21:26:07 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1PLQ7et014312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 21:26:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 15:26:06 -0600 From: "Fred Baker (fred)" To: james woodyatt Thread-Topic: [homenet] automatic prefix management (OSPF or ISIS version) Thread-Index: AQHOE564zoD0Jxn6c0KGGI5oHEQgRg== Date: Mon, 25 Feb 2013 21:26:05 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7A83B6@xmb-rcd-x09.cisco.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> In-Reply-To: <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 21:26:08 -0000 On Feb 25, 2013, at 11:21 AM, james woodyatt wrote: > Basically, we've given up on stateless router autoconfiguration in HOMENE= T, and we're forced into a stateful solution. There are no good choices he= re, and the worst case outcome is that we will force the widespread adoptio= n of NAT66 at HOMNET borders, precisely because it may turn out that subscr= ibers want stable subnet identifiers, and more of them than their service p= roviders are willing to provide at reasonable price. This all happened bef= ore, and we're not showing any signs of making sure it doesn't happen again= . Here I'm a little confused. Who is "we"? To my knowledge, homenet hasn't gi= ven up on automated subnet allocation. If homenet has, no problem, let the = draft expire. If the ISP wants to allocate specific /64s to a customer, that's actually O= K. It requires some thought, however. We are going to have to send a DHCP-P= D request from each router in the network to the ISP's DHCP-PD server, whic= h will allocate some number of /64s to the requesting router. I don't know = about your world; in my world, it's not unusual for routers to have more th= an two interfaces; in a home using wireless and wifi, one could imagine eac= h router asking for two downstream subnets just for that in addition to an = upstream interface. The router in my home, a Cisco 881W, could conceivably = have five subnets on as many interfaces in addition to whatever is on the I= SP-facing interface. I could imagine this requiring some jiggling of the DHCP-PD spec. As I reca= ll, it (RFC 3633 section 10) allocates a prefix with a length, and allocate= s from that prefix to a variety of its own interfaces and potentially other= s. A router asking for 5 /64s will in fact ask for, and receive, one /61. I= f we want it to literally ask for a list of /64s, I think we have to play w= ith it a bit. I suppose the IA_PD could contain multiple of those options; = maybe that's the work-around. What would actually be topical and helpful would be specific comments on th= e draft in question. What that it says do you object to, and what do you wi= sh it would say?= From mark@townsley.net Mon Feb 25 14:18:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2527321E8123 for ; Mon, 25 Feb 2013 14:18:00 -0800 (PST) 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_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6jF6WZgsqEW for ; Mon, 25 Feb 2013 14:17:59 -0800 (PST) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8840D21F90CE for ; Mon, 25 Feb 2013 14:17:57 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id b57so1800750eek.32 for ; Mon, 25 Feb 2013 14:17:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ve8C3v6MPesK5Yg/X6h3KjT49mvrAIh9AGRSYdMGZvM=; b=EK62TKbo7G4WJo5+WCDqiw0nj3FKuQTHmYgmdWWpDckQ2f37iohB2XvKnsVETi1Dp2 hhMj03fharpoog3HTcA2qu4na8PGJIS9Vv2EEoVXqbcn/R4AgM9VQ23CN63aWrMVKJPJ LdB6q1dxyE/xTO0FOPLsv8UdUWOkFW3ENNhjdDcv4u6vNZgEQyp76THmacasMKoU+Mo8 IIMbRF3A4NB7wiUFmaRrU4lm9PnBWA8PXkZlSRm5YitJZvXNP0QVV76pXewtjwMsiF9N mIcpKKvdIeZlkBeYXc/iCJimyeKw1/l0w1YsjRTyQ1v7WkN2Dj6T8KjBNDf+laXheqkg HavQ== X-Received: by 10.14.207.73 with SMTP id m49mr43408342eeo.24.1361830676682; Mon, 25 Feb 2013 14:17:56 -0800 (PST) Received: from ?IPv6:2001:420:c0c1:8:5d9f:6665:5c42:8998? ([2001:420:c0c1:8:5d9f:6665:5c42:8998]) by mx.google.com with ESMTPS id q42sm20493227eem.14.2013.02.25.14.17.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 14:17:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <51287D7A.60300@gmail.com> Date: Mon, 25 Feb 2013 23:17:51 +0100 Content-Transfer-Encoding: 7bit Message-Id: <364CAA7D-4988-462D-B2AA-8729F228884C@townsley.net> References: <51287D7A.60300@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQk6ickXg1rdnacg+v6A1g0OUHi/6P1bH/lR5OB/BJV3K77pke799tQ6glsjnJdJBUPJ0AV+ Cc: "homenet@ietf.org Group" Subject: Re: [homenet] renumbering the IETF X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:18:00 -0000 On Feb 23, 2013, at 9:27 AM, Brian E Carpenter wrote: > On 23/02/2013 05:53, Erik Kline wrote: > .. >> I wonder if we should ask the NOC about performing a renumbering >> during the next IETF meeting. >> >> Ideally, we should be able to perform one or two (or three) >> renumberings in a week, glean the relevant operational experience, and >> send a draft to v6ops shortly thereafter. > > Great idea. I won't be in Orlando, but I am fairly sure there is nothing > I would do there that cares about address persistency, apart from > having to reconnect to jabber maybe. Conducting an RFC 4192 procedure > on Tuesday night and a flash IPv6 renumbering during Thursday morning > would be very interesting! We might as well toss in some ULAs as well. - Mark > > At least Skype will not be a problem during IPv6 renumbering. > > Brian From tjc@ecs.soton.ac.uk Mon Feb 25 14:54:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4DC21E80F6 for ; Mon, 25 Feb 2013 14:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZdw77nXev0x for ; Mon, 25 Feb 2013 14:54:28 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC7621F9211 for ; Mon, 25 Feb 2013 14:54:27 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r1PMsQD3010334 for ; Mon, 25 Feb 2013 22:54:26 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r1PMsQD3010334 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1361832866; bh=vSv1xnEBpDMMjTr1zfF8E7lTDMo=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=vkUyhYoi3+TcvOtC4AuXR62TmNRW3m+1NMnoiSISD5sSUl4OWkEtpyK8FYH4/JzDQ 5L2urcERv2PSSLzDpHfNnPAep96Ez2cpxIm+2Lg1sY0hmOMYGipp6wKGm3+rjlN8ZM tnnT1hk+xtTqcTBNoNAg9En62qJqjumcFhRWzXtE= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p1OMsQ0430654491Ls ret-id none; Mon, 25 Feb 2013 22:54:26 +0000 Received: from [192.168.1.103] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r1PMrwRK007560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 25 Feb 2013 22:53:59 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <364CAA7D-4988-462D-B2AA-8729F228884C@townsley.net> Date: Mon, 25 Feb 2013 22:53:57 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <51287D7A.60300@gmail.com> <364CAA7D-4988-462D-B2AA-8729F228884C@townsley.net> <08AE2EFA-D7DB-4B52-B8F7-3ABB5CFD6658@ecs.soton.ac.uk> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p1OMsQ043065449100; tid=p1OMsQ0430654491Ls; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r1PMsQD3010334 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] renumbering the IETF X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:54:29 -0000 On 25 Feb 2013, at 22:17, Mark Townsley wrote >=20 > On Feb 23, 2013, at 9:27 AM, Brian E Carpenter wrote: >=20 >> On 23/02/2013 05:53, Erik Kline wrote: >> .. >>> I wonder if we should ask the NOC about performing a renumbering >>> during the next IETF meeting. >>>=20 >>> Ideally, we should be able to perform one or two (or three) >>> renumberings in a week, glean the relevant operational experience, = and >>> send a draft to v6ops shortly thereafter. >>=20 >> Great idea. I won't be in Orlando, but I am fairly sure there is = nothing >> I would do there that cares about address persistency, apart from >> having to reconnect to jabber maybe. Conducting an RFC 4192 procedure >> on Tuesday night and a flash IPv6 renumbering during Thursday morning >> would be very interesting! >=20 > We might as well toss in some ULAs as well.=20 That would be very useful.=20 Renumbering tests have been run ten years ago, with good results for the = network elements given there's no 'flag day', but not with ULAs in the = mix. So 'flash' renumbering with ULAs in place would be interesting. Tim= From lorenzo@google.com Mon Feb 25 16:28:36 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7551C21E818F for ; Mon, 25 Feb 2013 16:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.96 X-Spam-Level: X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1v3EIy+1awy for ; Mon, 25 Feb 2013 16:28:35 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id C338021E8165 for ; Mon, 25 Feb 2013 16:28:34 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id o17so4256641oag.34 for ; Mon, 25 Feb 2013 16:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0RQTkjybHyDgBkYohz9csIfdSDVP7vBOB3qIlxYxt4o=; b=VV2Xo7LaoqakjQdyv6iFywC2ShAiI6HeXTOI6J6G7IQEx6p/v6VjD/mzudQbtigQXE Zf8KGxxSMbhFJgeOvlCD40sVHkJqEc3ETobCDAzbptyKVzOuiYjLubu3SCC07/MLf7ps 7m34vy0zXtmbYNQZOoTz4J/PoAAEayREwV+u8dTkCnjSutR6dtiw2NVXYwV/zWkrtJZz 1CADznjFOmThFy1MyquNrBfQOSel94D9lSjRJKROsgU9ZSpKdrfDHty1ZbJ5NXKlRBgX 5dKWfd9APgFVxnOEGJ3W5D4x8CWDzSNTpUV22bq9/L2utlK/3fBqEdssIwvSRz7DdBM1 IMGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=0RQTkjybHyDgBkYohz9csIfdSDVP7vBOB3qIlxYxt4o=; b=i4KY+wDJFkpOoGa9iOBiQZ473Hy6BRA1rgYvUCt1UrWungz+R/ymA81wkrXFOUksQO 0WWXHxm7GLpHjNk22ITg9zFGIkuZZf2TjunDC/3/7nAU17+2t6Zzu24CiFuKCQTwR50V hyTH3M7OqjQ/iXuPg8YZ1ibgp8iexejABnQu8PtzYWNwjxFSuZwcDLVrk279vsTyvVyb +R5uGrxd27YtkgIvL31c7irVDOev3qg5bsb/2QZpFOUjCkfms3V6veMNZA6OwmvnqBVV QAHYlzKyTNfAVIWcnNZgwse05xLaN8zM007suXLyA2oQxXy2GpF+63zJQp6AMsqsJd14 akCg== X-Received: by 10.182.108.104 with SMTP id hj8mr9760664obb.44.1361838514260; Mon, 25 Feb 2013 16:28:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.70 with HTTP; Mon, 25 Feb 2013 16:28:14 -0800 (PST) In-Reply-To: <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> From: Lorenzo Colitti Date: Tue, 26 Feb 2013 09:28:14 +0900 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=f46d0447a1e9e26daa04d695bcb0 X-Gm-Message-State: ALoCoQkVEwez4MTKgpiYotsiWomlhaSZBb/vj4h6q9x1cfMh5piA6lI6S2yxTh3SnH+ZuilFlRGjp0TCOrQgtrIG1JxcMMUiZAwog0vHX9lf5Fx1NEG9dGIYEGHbIly4p/68dXvqd0NzhmAMjrkTjo411lX3Gqf6k8TnP0+QV1CKVTLT1G0UvKKZd7GvL2gj3rRq4JKrqmxv Cc: "homenet@ietf.org" Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:28:36 -0000 --f46d0447a1e9e26daa04d695bcb0 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 26, 2013 at 4:21 AM, james woodyatt wrote: > As a result, it means that Automatic Prefix Management here is basically > unable to do it statelessly, i.e. by randomly generating subnet numbers > from an identifier space of conventional size and testing for collision > before using them. > Why do you say this? Assuming the ISP(s) providing service to the home assign enough space to number all the links (e.g., /60, /56, or /48), then what's the problem? --f46d0447a1e9e26daa04d695bcb0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 26, 2013 at 4:21 AM, james woodyatt <jhw@apple.c= om> wrote:
As a result, it means= that Automatic Prefix Management here is basically unable to do it statele= ssly, i.e. by randomly generating subnet numbers from an identifier space o= f conventional size and testing for collision before using them.

Why do you say this? Assuming the IS= P(s) providing service to the home assign enough space to number all the li= nks (e.g., /60, /56, or /48), then what's the problem?
--f46d0447a1e9e26daa04d695bcb0-- From jhw@apple.com Mon Feb 25 18:22:52 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C1B21E8147 for ; Mon, 25 Feb 2013 18:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.852 X-Spam-Level: X-Spam-Status: No, score=-103.852 tagged_above=-999 required=5 tests=[AWL=6.747, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdHM2nCCgFgL for ; Mon, 25 Feb 2013 18:22:52 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2552121E812C for ; Mon, 25 Feb 2013 18:22:52 -0800 (PST) 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 mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MIT008MM2LYLOA0@mail-out.apple.com> for homenet@ietf.org; Mon, 25 Feb 2013 18:22:51 -0800 (PST) X-AuditID: 1180711d-b7f236d000005e0f-4e-512c1c7a162b Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id A9.8E.24079.A7C1C215; Mon, 25 Feb 2013 18:22:50 -0800 (PST) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MIT005T22M2VB50@aniseed.apple.com> for homenet@ietf.org; Mon, 25 Feb 2013 18:22:50 -0800 (PST) From: james woodyatt In-reply-to: Date: Mon, 25 Feb 2013 18:22:50 -0800 Message-id: <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> To: "homenet@ietf.org" X-Mailer: Apple Mail (2.1682) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUi2FAsrlsloxNo8PuEtcX7RYdYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8WLtMbaC/UIVLR9msDcwvufrYuTkkBAwkXg3uZ8JwhaTuHBv PVsXIxeHkMAUJokJC3qZIZxZTBJr7p9mBKliFtCR6P3+jRnE5hXQk5i5cgkriC0s4ClxuHkt G4jNJqAi8e3yXaCpHBycAsESrz7bgYRZBFQllv/oYoEYoy3x5N0FVogxNhLPtv8EO0JIoIlZ 4ltXEYgtIqApcWn2UajjZCU+XGljn8DIPwvJFbOQXDELydgFjMyrGAWLUnMSKw2N9RILCnJS 9ZLzczcxgkOsUHYH4/6f/IcYBTgYlXh4L7ZqBwqxJpYVV+YeYpTgYFYS4eXMAArxpiRWVqUW 5ccXleakFh9ilOZgURLnZX4ClBJITyxJzU5NLUgtgskycXBKNTAarZleeI9L52xg8Ect/4Rn WTN4r9tPv6WZt/fp9yXWzQ7vzx10qzzqaeDVVfqz4v+x5iidGRIZ6WxLFC0tDFh2XxHIy7mX JJ/m+0+MJcRH7P4LfeXXMmXswvMmTZc87H8mR6IlvLR9xTJv490T+t6/eHzy+1E5tUdTQ4+Z SjRYHwy5NOmp2UMlluKMREMt5qLiRADCgtEiLQIAAA== Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 02:22:52 -0000 On Feb 25, 2013, at 16:28 , Lorenzo Colitti wrote: > On Tue, Feb 26, 2013 at 4:21 AM, james woodyatt wrote: >> As a result, it means that Automatic Prefix Management here is basically unable to do it statelessly, i.e. by randomly generating subnet numbers from an identifier space of conventional size and testing for collision before using them. > > Why do you say this? Assuming the ISP(s) providing service to the home assign enough space to number all the links (e.g., /60, /56, or /48), then what's the problem? p1. I don't believe it's reasonable to assume that service providers will always provide a short enough prefix to number all the links in a subscriber's network, or that those that currently do will continue to do so into the foreseeable future, or that they will even give notice prior to reducing the space delegated to a subscriber. p2. In a decent sized subscriber network, with several subnets in place, a /56 delegation means a small but significant changes that a randomly selected subnet identifier will collide with an existing one, whenever a router joins the network. With a /60, the odds climb quite a bit, and in some networks it will be 15/16. (Do not make the mistake of assuming that router joins and leaves will be infrequent events. Plan for them happening several times per second, or you will be sorry later.) p3. All this pain can be traded away for the reasonably well-understood pain of NAT66 and a single ULA prefix with a constant 16-bit subnet identifier space, where collisions will be rare and stateless prefix autoconfiguration will settle quickly basically every time. I personally don't think that's a good trade, but if routed home networks are ever to become the normal setup, then I'm very skeptical that my opinion will turn out to be the majority one. I think if we want to avoid the temptation of subscribers to deploy NAT66 to preserve the stability of their 16-bit subnet identifier space in the face of service providers "enhancing their choices" with a variety of plans with varying policies for prefix delegation, then we have to do it with a stateful subnet manager in the network, near the border gateways. -- james woodyatt core os networking From asaeda@nict.go.jp Mon Feb 25 18:44:13 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7428621E80F4 for ; Mon, 25 Feb 2013 18:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYQN6IPVEAZe for ; Mon, 25 Feb 2013 18:44:12 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D1721E80B3 for ; Mon, 25 Feb 2013 18:44:12 -0800 (PST) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id r1Q2iBHV013373 for ; Tue, 26 Feb 2013 11:44:11 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id r1Q2iAZY022586 for ; Tue, 26 Feb 2013 11:44:10 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id r1Q2iAaV022582 for ; Tue, 26 Feb 2013 11:44:10 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 9DA37163FF for ; Tue, 26 Feb 2013 11:44:10 +0900 (JST) Received: from localhost (5gou2f-dhcp44.nict.go.jp [133.243.146.204]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 8BAD1163DD for ; Tue, 26 Feb 2013 11:44:10 +0900 (JST) Date: Tue, 26 Feb 2013 11:43:18 +0900 (JST) Message-Id: <20130226.114318.153371974.asaeda@nict.go.jp> To: homenet@ietf.org From: Hitoshi Asaeda X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [homenet] multiple upstreams for igmp/mld proxy X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 02:44:13 -0000 Hi, I've been working in PIM WG and submitted a draft describing multiple upstream interface support for IGMP/MLD proxy. http://tools.ietf.org/html/draft-asaeda-pim-mldproxy-multif-01 The abstract is as follows; This document describes the way of supporting multiple upstream interfaces for an IGMP/MLD proxy device. The proposed extension enables that an IGMP/MLD proxy device receives multicast packets through multiple upstream interfaces. The upstream interface is selected with manually configured supported address prefixes and interface priority value. A take-over operation switching from an inactive upstream interface to an active upstream interface is also considered. In the last PIM WG meeting, I got a comment that Homenet WG may be interested in this feature. If someone in this group would be interested in this feature, please kindly take a look at this draft and give us comments. (It'd be better to post your comments for this draft to PIM ML, but if you don't subscribe PIM ML, please directly mail me your comments. I can then reply and copy to PIM ML if needed.) Thank you. Regards, -- Hitoshi Asaeda From marka@isc.org Mon Feb 25 18:56:41 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089EC21E8143 for ; Mon, 25 Feb 2013 18:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8oEcvjLEyUM for ; Mon, 25 Feb 2013 18:56:40 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3B60521E80B3 for ; Mon, 25 Feb 2013 18:56:40 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id C6B86C94B6; Tue, 26 Feb 2013 02:56:34 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361847400; bh=Q3aH6gzyJkJd1D3EGFjCQG5AohBc9efZOU2v3EXLGdw=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=gfIZ9cvw/qd5YGz5A9UbjX438B2B7U/1lm0aPKBOMFiYdBf5KcVNNKP8Tb666bkq+ tt4HZU6nziwktbbb35tzci3Rv0VkKS9+B7aZlXKcqizqqUK+jK/CBJ318QmqNw8p8g YTW6yRJk19RU1WidRt6egT/bqvIRLEsDRcZ5RmS4= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Tue, 26 Feb 2013 02:56:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4952:ac91:78ad:bca0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 72FA8216C40; Tue, 26 Feb 2013 02:56:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5CAD9301035F; Tue, 26 Feb 2013 13:56:31 +1100 (EST) To: james woodyatt From: Mark Andrews References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> In-reply-to: Your message of "Mon, 25 Feb 2013 18:22:50 -0800." <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> Date: Tue, 26 Feb 2013 13:56:31 +1100 Message-Id: <20130226025631.5CAD9301035F@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "homenet@ietf.org" Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 02:56:41 -0000 In message <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com>, james woodyatt wri tes: > p3. All this pain can be traded away for the reasonably well-understood pain > of NAT66 and a single ULA prefix with a constant 16-bit subnet identifier spa > ce, where collisions will be rare and stateless prefix autoconfiguration will > settle quickly basically every time. I personally don't think that's a good > trade, but if routed home networks are ever to become the normal setup, then > I'm very skeptical that my opinion will turn out to be the majority one. NAT66 assumes a /48 or else you don't have enough bits to fix the checksums. > I think if we want to avoid the temptation of subscribers to deploy NAT66 to > preserve the stability of their 16-bit subnet identifier space in the face of > service providers "enhancing their choices" with a variety of plans with var > ying policies for prefix delegation, then we have to do it with a stateful su > bnet manager in the network, near the border gateways. > > > -- > james woodyatt > core os networking > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ek@google.com Mon Feb 25 19:08:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF34921F95A4 for ; Mon, 25 Feb 2013 19:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gNVF5aGa7b1 for ; Mon, 25 Feb 2013 19:08:29 -0800 (PST) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6ED21F95A3 for ; Mon, 25 Feb 2013 19:08:29 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id k38so3076455iah.13 for ; Mon, 25 Feb 2013 19:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=RfxyVvBJpeg8wDY9WGoK3W+vLm0McodFwrPviNTwsDY=; b=k2sNyISWwkLIC9T5hV5DBktHVNf5o8ZOA/5D265lUj6iUtrH/lUS7sKuncY09a/JoL hLzY9t/vglZcXt+rh16lMTmn0JHZ/2QUdtSd3d8OMAAevwrsnWCivgdERUL+dXVcY5hx fSbnqjLvINErALgMK0XHoBU3swX6NBUIn+kNC18qRGGzez4gE55ld32eWuqVO0TIEj8r 8gC96tze+RkqZUwKe54iEF3WHBV1GzDIOK/RwWe+BIHjC87JAkIoDF0Y1Sg6WAqshnTr qX1j7cP/dvktgskZxn80nwZnwszl2fFN7frXHbmO1LgqQfcLok6x6Zaj7CciN9ZKm2sd jZrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=RfxyVvBJpeg8wDY9WGoK3W+vLm0McodFwrPviNTwsDY=; b=egkIBQli64tdHe6mGKeTTstZ7dgzZAvOfbBf2yZ34PiMiQrhnYNEieF5Tp9Yp4KD64 /bjeOzLR+pbJ5E0OnCeo086SWexunsKTKh6dWQG4I6cmo7dpuN2M2EyIJF2gPPi33tK+ Fm+p40PHyyHcq/sYxz7/JLmZXszksHrj+Oae0jx8WrxcengfIES6xFq2wqJ/BQAEkArA NkQ+IFBkA7CPto8SruXKdH9LLau69v6uigALMfOI8i1DED1jp0iYBrFADxoo+lGZ92gl jTpUEZEqtxIQJCC/zgipdk1tNAqJKL+KPPTAdw2hBFuV64DoTmLv6jhvwwiG/E19qTvQ SZEA== X-Received: by 10.50.140.101 with SMTP id rf5mr4583841igb.41.1361848108790; Mon, 25 Feb 2013 19:08:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.229.202 with HTTP; Mon, 25 Feb 2013 19:08:08 -0800 (PST) In-Reply-To: <43238C9F8B23DA44B42A78D0129283E017FAE7BF@EXCHANGE.cablelabs.com> References: <20130216152728.22417.85041.idtracker@ietfa.amsl.com> <43238C9F8B23DA44B42A78D0129283E017FAE7BF@EXCHANGE.cablelabs.com> From: Erik Kline Date: Tue, 26 Feb 2013 12:08:08 +0900 Message-ID: To: Chris Grundemann Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnM1iDoC1PCu08R58+oq/qXfMiKEt2BPv15NLGfro/uLqqwILlS2J+A2bHkh0ONoc7TAE5zN66GdKPDSc7GWNWI7zWsobr+feuQ5VZIzp6AktRhF6x6FpaA91y8bWEM27D+WAIzx8psKcEpsPoG4NtsYweXVoki/fdDP/h3qTRnmHGzRui8vxOtV6hLJRKmhcS2jYxm Cc: "homenet@ietf.org" , "draft-grundemann-homenet-hipnet@tools.ietf.org" Subject: Re: [homenet] FW: New Version Notification for draft-grundemann-homenet-hipnet-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 03:08:29 -0000 WRT to Section 4.1, I think the "/48 check" may not be a good idea. It may work for /your/ deployment models, but it doesn't necessarily work for all. Furthermore, if this were widely adopted it would effectively enforce that deployment model all providers, needlessly I think. Consider a deployment model that I believe I first heard from Lorenzo: a customer is allocated a prefix AND the "zero-numbered" /64 from that prefix is advertised in the RA toward the customers home gateway. (Really any <64 customer prefix and any single /64 would work, like the "all ones" /64--it doesn't particularly matter.) I'm not aware of anything that technically precludes this nor do I think we should move to preclude it now. (Note: there may be some home gateways that are not be smart enough to recognize that one of the prefixes delegated to it is in use already on one of its interfaces (e.g. WAN), but homenet can require such intelligence.) So, your text could try to recognize that IF there is only one allocated prefix in the home && IF an interface is not number from that prefix THEN it must be an edge. That's fine. But being numbered from within the allocated prefix does not necessarily mean that it's an interior router. From lorenzo@google.com Mon Feb 25 19:35:59 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA4A21E8166 for ; Mon, 25 Feb 2013 19:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.377 X-Spam-Level: X-Spam-Status: No, score=-101.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLyAPBC+QhVg for ; Mon, 25 Feb 2013 19:35:58 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id ADDC321E80B3 for ; Mon, 25 Feb 2013 19:35:52 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c10so4027583ieb.31 for ; Mon, 25 Feb 2013 19:35:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=jAjoObNqa1eyyyQE1xI0iJ2S7JaZOyIkm2BGHFo25rw=; b=lUthZvOHlbu8gzuyWY64WySvasZtlNnqVIzt8qOKUK/gK7z6WDxkFVcOUjBKl6EGXI pR7A8WF+J0l6vJ6swRUs3cHmS9UXguQY4w/wAR6xsdl6MOfiWkjsmRDxoLY7lvhJq2QS fmHc9bivVodjE0aCEiQdtl5+sdxPHvpE2J4UQpBzyyW/6iPA1rXghYZOjePNfWZ9M08d TfuWICIbPGwoDoKgyUVllvtR4LGntPShoeICv7uJhK+e3a1XsbGSj9qDe38MwXKNM7d3 3kHY+Vb8ZXeYsVFrkQ1cAS1fTIyBAHS4qigF46LhLYpSPShxxv/ohFsBxLeIoLwHTdpu qaGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=jAjoObNqa1eyyyQE1xI0iJ2S7JaZOyIkm2BGHFo25rw=; b=O4s5ltiJplkb+3ZZUk49/7SkjullD4Wd979Q9pECQe87AmIoiu/SaK/0PlmABBJ6yR 8Q3uDhtOfGj1mMAImK+ZINgkzJQITsCGFhl4i3NvAzYtsT2qBOhrQBUGqE2i3u4zqQ5s iI20wgk5GXLHuzy+tmGjM5VAV2XMFT4dv1Nr7DhsLbniWIFBa+j5t2+UTV3bGCyFQsNQ a4le08z+bLio+J+XryUVMi5vWTidIHrSTYrTiu2jbB2NLcTcCbptmirwkmZMLniZ+24v ux415jSyTJwrvZrHG8qLQ5oG1H+0BVM5of/SyKw9xW3QP+uHSWm2w0Ip9+foBxOzyiBU c6jQ== X-Received: by 10.42.92.72 with SMTP id s8mr5531696icm.0.1361849752165; Mon, 25 Feb 2013 19:35:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.158.73 with HTTP; Mon, 25 Feb 2013 19:35:32 -0800 (PST) In-Reply-To: <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> From: Lorenzo Colitti Date: Tue, 26 Feb 2013 12:35:32 +0900 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=90e6ba5bba1db83f1e04d6985ae3 X-Gm-Message-State: ALoCoQkyE2DFIrpBa7/NPTl0dIWozH2ublCsTcEQs8AayOHdr+AWO8h6TjFxcw8qvfm1GDiUANSY8RQEQ3z4/+R6O3NaYMffndZXjOKLASrRT4MEc7o0jHBQGYFpcjQ6ijmicYLln92ZBM+8/Bm670DqMYOYwjvAl2u05pvvPNnKimW2LhIGh0XbyKPfC7YtvPj5k9+3dYUH Cc: "homenet@ietf.org" Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 03:35:59 -0000 --90e6ba5bba1db83f1e04d6985ae3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 26, 2013 at 11:22 AM, james woodyatt wrote: > p1. I don't believe it's reasonable to assume that service providers will > always provide a short enough prefix to number all the links in a > subscriber's network, or that those that currently do will continue to do > so into the foreseeable future, or that they will even give notice prior to > reducing the space delegated to a subscriber. > Ok, but in that case the only options available to us are a) give up, or b) make routing work with smaller-than-/64 prefixes. I believe our current plan is to give up and tell the ISPs that if they want to run a routed home, then they need to assign it more than a /64. The alternative is basically a vicious circle: if ISPs ignore the IETF's advice and assign a /64 because they see additional address space as an upsell opportunity, then someone will figure out how to share the /64 by using ugly hacks like routing /128s assigned from DHCPv6. Goodbye privacy addresses, goodbye robust routing, but still, things will work most of the time. If the ISPs start to assign smaller than /64, things still work until they assign fewer /128s than the number of devices you have. At that point, someone will implement NAPTv6 and we're back where we started in IPv4. > p2. In a decent sized subscriber network, with several subnets in place, a > /56 delegation means a small but significant changes that a randomly > selected subnet identifier will collide with an existing one, whenever a > router joins the network. With a /60, the odds climb quite a bit, and in > some networks it will be 15/16. (Do not make the mistake of assuming that > router joins and leaves will be infrequent events. Plan for them happening > several times per second, or you will be sorry later.) > Ok, but isn't that why the prefix autoconfiguration drafts assume that collisions are a regular part of prefix assignment? Are there issues with those drafts? Will their approach not work? > p3. All this pain can be traded away for the reasonably well-understood > pain of NAT66 and a single ULA prefix with a constant 16-bit subnet > identifier space, where collisions will be rare and stateless prefix > autoconfiguration will settle quickly basically every time. > How is using a single ULA better for this? Perhaps you don't have to deal with changes in flight (well, assuming that a backup router becomes available to act as ULA anchor when the designated ULA anchor is unplugged/crashes), so maybe that's a simplification. However, the moment you try to use more /64s internally than you have externally, stateless NPTv6 doesn't work any more, right? For example, suppose you use fc00::/48 in the home, and you have two links, which you number fc00:0:0:1::/64 and fc00:0:0:2::/64. You have one host on each link, and for some reason they both pick the same interface ID, so host A is fc00:0:0:1::dead:beef host B is fc00:0:0:2::dead:beef. Everything works fine so far. Now suppose that externally you have only one /64, 2001:db8::/64. I can't see how that can work: if you get a packet to 2001:db8::dead:beef, you don't know what to do with it. I think if we want to avoid the temptation of subscribers to deploy NAT66 > to preserve the stability of their 16-bit subnet identifier space in the > face of service providers "enhancing their choices" with a variety of plans > with varying policies for prefix delegation, then we have to do it with a > stateful subnet manager in the network, near the border gateways. If you don't have enough external space for all your hosts, then a stateful subnet manager isn't enough. You need a stateful host+port manager. i.e., you need an IPv4-style NAPT. --90e6ba5bba1db83f1e04d6985ae3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 26, 2013 at 11:22 AM, james woodyatt <jhw@apple.c= om> wrote:
p1. I= don't believe it's reasonable to assume that service providers wil= l always provide a short enough prefix to number all the links in a subscri= ber's network, or that those that currently do will continue to do so i= nto the foreseeable future, or that they will even give notice prior to red= ucing the space delegated to a subscriber.

Ok, but in that case the only = options available to us are a) give up, or b) make routing work with smalle= r-than-/64 prefixes. I believe our current plan is to give up and tell the = ISPs that if they want to run a routed home, then they need to assign it mo= re than a /64.

The alternative is basically a vicious circ= le: if ISPs ignore the IETF's advice and assign a /64 because they see = additional address space as an upsell opportunity, then someone will figure= out how to share the /64 by using ugly hacks like routing /128s assigned f= rom DHCPv6. Goodbye privacy addresses, goodbye robust routing, but still, t= hings will work most of the time. If the ISPs start to assign smaller than = /64, things still work until they assign fewer /128s than the number of dev= ices you have. At that point, someone will implement NAPTv6 and we're b= ack where we started in IPv4.
=A0
p2. In a decent sized subscriber network, with se= veral subnets in place, a /56 delegation means a small but significant chan= ges that a randomly selected subnet identifier will collide with an existin= g one, whenever a router joins the network. =A0With a /60, the odds climb q= uite a bit, and in some networks it will be 15/16. (Do not make the mistake= of assuming that router joins and leaves will be infrequent events. Plan f= or them happening several times per second, or you will be sorry later.)

Ok, but isn't that why the= prefix autoconfiguration drafts assume that collisions are a regular part = of prefix assignment? Are there issues with those drafts? Will their approa= ch not work?
=A0
p3. All this pain can be traded away for the reas= onably well-understood pain of NAT66 and a single ULA prefix with a constan= t 16-bit subnet identifier space, where collisions will be rare and statele= ss prefix autoconfiguration will settle quickly basically every time.

How is using a single ULA bett= er for this? Perhaps you don't have to deal with changes in flight (wel= l, assuming that a backup router becomes available to act as ULA anchor whe= n the designated ULA anchor is unplugged/crashes), so maybe that's a si= mplification. However, the moment you try to use more /64s internally than = you have externally, stateless NPTv6 doesn't work any more, right?

For example, suppose you use fc00::/48 in t= he home, and you have two links, which you number fc00:0:0:1::/64 and fc00:= 0:0:2::/64. You have one host on each link, and for some reason they both p= ick the same interface ID, so host A is fc00:0:0:1::dead:beef host B is fc0= 0:0:0:2::dead:beef. Everything works fine so far. Now suppose that external= ly you have only one /64, 2001:db8::/64. I can't see how that can work:= if you get a packet to=A02001:db8::dead:beef, you don't know what to d= o with it.

I think if we want to avoid the tempt= ation of subscribers to deploy NAT66 to preserve the stability of their 16-= bit subnet identifier space in the face of service providers "enhancin= g their choices" with a variety of plans with varying policies for pre= fix delegation, then we have to do it with a stateful subnet manager in the= network, near the border gateways.

If you don't have enough external space for a= ll your hosts, then a stateful subnet manager isn't enough. You need a = stateful host+port manager. i.e., you need an IPv4-style NAPT.
--90e6ba5bba1db83f1e04d6985ae3-- From mellon@fugue.com Mon Feb 25 19:46:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619D721E816D for ; Mon, 25 Feb 2013 19:46:20 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysoYe9QYud7A for ; Mon, 25 Feb 2013 19:46:19 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9D27221E80B3 for ; Mon, 25 Feb 2013 19:46:19 -0800 (PST) Received: from [10.0.1.12] (user-387gmsm.cable.mindspring.com [208.120.91.150]) by toccata.fugue.com (Postfix) with ESMTPSA id A7905238033D; Mon, 25 Feb 2013 22:46:16 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: Date: Mon, 25 Feb 2013 22:46:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <48F0F7E1-B0C1-455F-A0EA-FD82BAD2EF7A@fugue.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org" , james woodyatt Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 03:46:20 -0000 On Feb 25, 2013, at 10:35 PM, Lorenzo Colitti = wrote: > The alternative is basically a vicious circle: if ISPs ignore the = IETF's advice and assign a /64 because they see additional address space = as an upsell opportunity, then someone will figure out how to share the = /64 by using ugly hacks like routing /128s assigned from DHCPv6. That might be what you imagine someone will do, but what they almost = certainly will actually do is just bridge. Math is hard. From lorenzo@google.com Mon Feb 25 19:53:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2592E21E8171 for ; Mon, 25 Feb 2013 19:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUSFVQ-8v8Xj for ; Mon, 25 Feb 2013 19:53:44 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9512521E816D for ; Mon, 25 Feb 2013 19:53:41 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c10so3937543ieb.17 for ; Mon, 25 Feb 2013 19:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=SezSFKR+M9EqXL9nxoMVSUuVPJahDDUhjywi/A9LL6I=; b=CmCSvn7zH7lc4PlxW0u7YVRMqDHVo7gGJcM9qDCx4rO1lLy9twE68Re6179AqvfdnJ UIqo82UAtcfc/BeLS2GCIqE8aTIzPGFiajUL9YnKQhVBiWrfJAcgL3PAZqoop0VCeyjp hlp9LdhDYaOJVOMk5tfgMDDzopPSNrEM5OJuNyRAW6EX5Sd3pc/VPZxh0KloYIWvWrx8 7ES+10NKqbc5lNAhj1tuo5ufHjwE9t5KjhaPK5G1rePAuOspEEGAAz+EOX6PsBCQ3RpK UT61YPylncVGkdviUK6bEN3SaPBUrTnZPL8cuEqHcdiMGgoDbcgLI8yKaRf7rCiGELzX DICQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=SezSFKR+M9EqXL9nxoMVSUuVPJahDDUhjywi/A9LL6I=; b=i4voufvt7BUUxzUC9HPnsNvGPCjtk4sj99f8F4Nn+NQcEFeoPmbct7BAAv/1OmdrFE +sBFPgTIin5tMw+JOgI7prBKYc4n/NfofR1B/mb63QxLGaevFClNJ12ioaj1QAuwXe3v vQ8JtBDP+s320g1HDitb4IMqhguCHXOnjvc3NDein2Ef8U/FzPNM9Yxk8X8oZyfCgG/g sED+SORFSOBuy97kZvk0iHl1Eex3cX+Di4uZrQCDhdbYEcd8RRepexigx5dxvuRicgyC QCe8OaS8z55HKy3SNbc5Fn8dtkozs3MdEqBpPd+zcnsoVBYWG1cpHY/iGAoDGRSuSWwE ovjw== X-Received: by 10.50.157.163 with SMTP id wn3mr4695031igb.89.1361850821023; Mon, 25 Feb 2013 19:53:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.158.73 with HTTP; Mon, 25 Feb 2013 19:53:20 -0800 (PST) In-Reply-To: <48F0F7E1-B0C1-455F-A0EA-FD82BAD2EF7A@fugue.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> <48F0F7E1-B0C1-455F-A0EA-FD82BAD2EF7A@fugue.com> From: Lorenzo Colitti Date: Tue, 26 Feb 2013 12:53:20 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8f2344d76cbb1504d6989a5b X-Gm-Message-State: ALoCoQl4wbsyDeK94qbNFXSz/W9bu/B5lR03KqzSdcGSwPVJ16UtPwusl02kWBj+h/IYNW1tUUVEWff2fixL3LUGWqpXSdtF/gVtvPi8YYmMPumVzhkJTj5Z2JqFN+4nuNv2e/pJ19dOow9bUpjOd4vjgpgT5lYfGGz2UbxiqX+QN4fDqnGcQi97UDNd5MdyKEXg1/YzB1ay Cc: "homenet@ietf.org" , james woodyatt Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 03:53:45 -0000 --e89a8f2344d76cbb1504d6989a5b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 26, 2013 at 12:46 PM, Ted Lemon wrote: > > The alternative is basically a vicious circle: if ISPs ignore the IETF's > advice and assign a /64 because they see additional address space as an > upsell opportunity, then someone will figure out how to share the /64 by > using ugly hacks like routing /128s assigned from DHCPv6. > > That might be what you imagine someone will do, but what they almost > certainly will actually do is just bridge. Math is hard. > Yes, bridging will work because if everything is on one link, DAD will avoid collisions. My point was that there is no way to do routing, even with NPTv6, unless enough address space is assigned to the network. --e89a8f2344d76cbb1504d6989a5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 26, 2013 at 12:46 PM, Ted Lemon <mellon@fugue.= com> wrote:
> The alternative is basically a vicious circle: if ISPs ignore the= IETF's advice and assign a /64 because they see additional address spa= ce as an upsell opportunity, then someone will figure out how to share the = /64 by using ugly hacks like routing /128s assigned from DHCPv6.

That might be what you imagine someone will do, but what they almost = certainly will actually do is just bridge. =A0 Math is hard.

Yes, bridging will work because if everything is on o= ne link, DAD will avoid collisions. My point was that there is no way to do= routing, even with NPTv6, unless enough address space is assigned to the n= etwork.
--e89a8f2344d76cbb1504d6989a5b-- From lorenzo@google.com Mon Feb 25 20:06:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC0421E8173 for ; Mon, 25 Feb 2013 20:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.827 X-Spam-Level: X-Spam-Status: No, score=-101.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyNLzgBnCvrI for ; Mon, 25 Feb 2013 20:06:57 -0800 (PST) Received: from mail-ie0-x234.google.com (unknown [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id EC17021E816D for ; Mon, 25 Feb 2013 20:06:56 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id bn7so3930334ieb.39 for ; Mon, 25 Feb 2013 20:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=PuUK7SXJlsTS5I1YB/ZKgKWOINOLAqUM3EiZQnPUTBk=; b=gr21vWLqPCK++K8Ni88E4Egtj1Tjiq2+ptVqi2niKmAV1qNasmq3JsjsWv1fymf7ef c2dkfP1MqLpF4U3xJSP6BDKQ4qj7CN7AGOnRF0OqG6USUXCfKt6aCrftDrWe9fJwqC2w X2zKQJzmpN7xJklQ4bWNIdCldjXH2UNM6BfAacZwQ47pEXjVmG8Vx96Bi0+9nE2eTaW2 5dJq8d3uGTwRnH1CtkYMndM+zax3CKGpUHZ8c1vDgCsaYbYKaV4awt439AjNBvCtuLH0 WgxiwoNBIYR/mG1zA/rN02Fmop7kF9jQ/WFsaVjIReLJnu3NXVlH1IAemu6g96WXd+IP 0n2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=PuUK7SXJlsTS5I1YB/ZKgKWOINOLAqUM3EiZQnPUTBk=; b=hW6CUmhFUpx7FQSrW9RilgE7uVCWDyz7SG+ghMYENQTJBx59C7LebxE7XAgobASNBx 8UOUDBV37rwgAeERB/jP+8a4lzgkfDjVgQrg1LqUryAIyTkdsqjcHAPDv+yI5UlmUmWh nO3qpMWJduOVriB0ShQ78ZNau6Ne1ekcpwsHlbYXjqcR9SwIrs51cPY2QBrODjmdQQm5 jO3t2uZVb/I9gJ0on0ME7Q9TTdYaM21m61jhYI54SP8g4V7Bpe3EPjxVhswrcUy21XBx PhDSBVd34GXMYKfk88N1iIk48K9Osp1pVCXldOadHJcknY0so4aN0Tr+KgDFAPOYitQ3 9BEA== X-Received: by 10.50.149.195 with SMTP id uc3mr4566516igb.4.1361851616529; Mon, 25 Feb 2013 20:06:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.158.73 with HTTP; Mon, 25 Feb 2013 20:06:36 -0800 (PST) In-Reply-To: <364CAA7D-4988-462D-B2AA-8729F228884C@townsley.net> References: <51287D7A.60300@gmail.com> <364CAA7D-4988-462D-B2AA-8729F228884C@townsley.net> From: Lorenzo Colitti Date: Tue, 26 Feb 2013 13:06:36 +0900 Message-ID: To: Mark Townsley Content-Type: multipart/alternative; boundary=e89a8f3ba31bd737c204d698c902 X-Gm-Message-State: ALoCoQmwl52XJJaF20AGW6g3FuRpi25ZaFGhEOsBwa2KCCgwdW5yXDZHZCPWUaMFxc6Hh1w228TTpkXIbXlWnaoPVtKWsl6g5a+OaYD/kuDJnEGuHgYelpewTgqHo2TL0NgbfVT4Yb6hkAYeTYuNhmGuW5FB2wB8HHFExCAQL2muCYklSbFZ6ZJt1WFnnihWDZK+8yebtgcU Cc: "homenet@ietf.org Group" Subject: Re: [homenet] renumbering the IETF X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 04:06:57 -0000 --e89a8f3ba31bd737c204d698c902 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 26, 2013 at 7:17 AM, Mark Townsley wrote: > > Great idea. I won't be in Orlando, but I am fairly sure there is nothing > > I would do there that cares about address persistency, apart from > > having to reconnect to jabber maybe. Conducting an RFC 4192 procedure > > on Tuesday night and a flash IPv6 renumbering during Thursday morning > > would be very interesting! > > We might as well toss in some ULAs as well. > Hmm. Do we know for sure that all clients properly depref ULAs below global addresses (either because they follow RFC6724 instead of RFC3484, or because they implement the longest prefix matching rule?) If not, some clients might break. --e89a8f3ba31bd737c204d698c902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 26, 2013 at 7:17 AM, Mark Townsley <mark@to= wnsley.net> wrote:
> Great idea. I won'= ;t be in Orlando, but I am fairly sure there is nothing
> I would do there that cares about address persistency, apart from
> having to reconnect to jabber maybe. Conducting an RFC 4192 procedure<= br> > on Tuesday night and a flash IPv6 renumbering during Thursday morning<= br> > would be very interesting!

We might as well toss in some ULAs as well.

=
Hmm. Do we know for sure that all clients properly depref = ULAs below global addresses (either because they follow RFC6724 instead of = RFC3484, or because they implement the longest prefix matching rule?) If no= t, some clients might break.
--e89a8f3ba31bd737c204d698c902-- From marka@isc.org Mon Feb 25 20:13:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D77121F90E7 for ; Mon, 25 Feb 2013 20:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMM5FQAzzibT for ; Mon, 25 Feb 2013 20:13:45 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id CBDA721F9032 for ; Mon, 25 Feb 2013 20:13:44 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1F4895F985D; Tue, 26 Feb 2013 04:13:36 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361852024; bh=j86DV9AtmYuIOrGTnu3a/00KVwmCemPRQQKwt0TqnmY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=fsyIJCYz5igp04aspvlbpaJOGiGVsVxdFHT0A3EeEgDc5gIQXDjjsUBF1cTQrxJGi D/CW14tl/uLSo0fmVP3cWYgN11jSfrqpo4b+Bs+ZeBU+vahAfQWlpyt1U7bPoKO8Ob 5ZaD/M9QPWCU76LLz2+FCPIoMkpWjODdFIQHjEik= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4952:ac91:78ad:bca0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 37D7A216C3B; Tue, 26 Feb 2013 04:13:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5EFAF30117D1; Tue, 26 Feb 2013 15:13:29 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <51287D7A.60300@gmail.com> <364CAA7D-4988-462D-B2AA-8729F228884C@townsley.net> In-reply-to: Your message of "Tue, 26 Feb 2013 13:06:36 +0900." Date: Tue, 26 Feb 2013 15:13:29 +1100 Message-Id: <20130226041329.5EFAF30117D1@drugs.dv.isc.org> Cc: "homenet@ietf.org Group" , Mark Townsley Subject: Re: [homenet] renumbering the IETF X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 04:13:45 -0000 In message , Lorenzo Colitti writes: > > On Tue, Feb 26, 2013 at 7:17 AM, Mark Townsley wrote: > > > > Great idea. I won't be in Orlando, but I am fairly sure there is nothing > > > I would do there that cares about address persistency, apart from > > > having to reconnect to jabber maybe. Conducting an RFC 4192 procedure > > > on Tuesday night and a flash IPv6 renumbering during Thursday morning > > > would be very interesting! > > > > We might as well toss in some ULAs as well. > > > > Hmm. Do we know for sure that all clients properly depref ULAs below global > addresses (either because they follow RFC6724 instead of RFC3484, or > because they implement the longest prefix matching rule?) If not, some > clients might break. Longest match works well enough 2001/2002 have 14 bits in common. fc00 has no bits in common with 2001 or 2002. I've been using ULA PA addresses together at home for years without issue. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lorenzo@google.com Mon Feb 25 20:40:12 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04D621F95C7 for ; Mon, 25 Feb 2013 20:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.877 X-Spam-Level: X-Spam-Status: No, score=-101.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E37mpBJsiVHq for ; Mon, 25 Feb 2013 20:40:12 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2F04C21F95C6 for ; Mon, 25 Feb 2013 20:40:11 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id k14so3983689iea.41 for ; Mon, 25 Feb 2013 20:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Q4+FsjtKL5ghFQ+NZh5iQ5cvaOwN77aWsMFSQ0iA98Q=; b=TsVxai3uE0FwYUb1LiX+hgFQL52m2lMW91dl6tw+kdRtV02ngjP43aB6Rgyv4VLchE HhYtahZ1pyCB69Q7/Pg6uZpt5KkH2t8/j16bLk6iYrT2+WEjQo3O02mpCHdZoTL8LAud T3BuJO3JriEmeyGDckXD7ALz0WVQZ3CGOLobkTuPkZQnEJR1GWSW38fxhS65iBBao+qJ NN3qwQ0Qe8Hfc6gpI1Wd0QdiZWjuzd+7L4PMjGGmfzMBrNQGu7UdeltGEMnQVD1ced3l 6eKX8uYDWaIYCTew7bmwYCz+/OH42qcMcc9BQF5DVS7YT+k7b89dhns4IYGTZ5ktoABm m2wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Q4+FsjtKL5ghFQ+NZh5iQ5cvaOwN77aWsMFSQ0iA98Q=; b=UzpFrX6Ww49SKmamnrUfez4Y62tffwATJk8wXkDyovPEXX7iCBKoE9m0X1Bsr2QdBE wIPwxqjW57HBPh6gUYLVXt2REuP7CM/gFrNqdM9oLiLeAQ+OOHvj5hpFSTUpAJ1eDbwT YkUOd9uyMBPnperXYQ16aeBAI/HeHU8G/KyIwyuGbSI5bWLM+l8wvngbizLlfWk6gnhD JJM7HuTJZiYSmCwS82amiIVy/XWzNR15Ck0pHT4um6VAM/cTacDI5W50ksYqBzE26NHQ ybkxa6ctVJRMTdnb6eF1deC49+VEER4LojqH+EQ98CuJBVVgYM3vRVcQp2ykoWrrvO4i CTSg== X-Received: by 10.43.118.2 with SMTP id fo2mr1265222icc.41.1361853611551; Mon, 25 Feb 2013 20:40:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.158.73 with HTTP; Mon, 25 Feb 2013 20:39:51 -0800 (PST) In-Reply-To: <20130226041329.5EFAF30117D1@drugs.dv.isc.org> References: <51287D7A.60300@gmail.com> <364CAA7D-4988-462D-B2AA-8729F228884C@townsley.net> <20130226041329.5EFAF30117D1@drugs.dv.isc.org> From: Lorenzo Colitti Date: Tue, 26 Feb 2013 13:39:51 +0900 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=bcaec517c8acc0de7304d699406d X-Gm-Message-State: ALoCoQl9YHSa1NUwdkMVF1mHMRygi6s5X08nvlpnvjM5MU8v1ojlc8H1F6hE3uKSlh+FDTii9MeWN3cLkMeFClLsQrd8pBDf5WPaadxCtfcDdaR3oFmBfoCkhGOBxLkJ8vhllijgYEObigGBy/D2BB8U1Pw04QRnIvn4NDiYWOFnucy8UZNUl/DVomM+HpJv41wvUEUo+gkB Cc: "homenet@ietf.org Group" , Mark Townsley Subject: Re: [homenet] renumbering the IETF X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 04:40:12 -0000 --bcaec517c8acc0de7304d699406d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 26, 2013 at 1:13 PM, Mark Andrews wrote: > > Hmm. Do we know for sure that all clients properly depref ULAs below > global > > addresses (either because they follow RFC6724 instead of RFC3484, or > > because they implement the longest prefix matching rule?) If not, some > > clients might break. > > Longest match works well enough 2001/2002 have 14 bits in common. > fc00 has no bits in common with 2001 or 2002. I've been using ULA > PA addresses together at home for years without issue. > Which is why I asked whether we know for sure that all clients implement it. Do we? --bcaec517c8acc0de7304d699406d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
--bcaec517c8acc0de7304d699406d-- From marka@isc.org Mon Feb 25 21:40:11 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C532F21E816D for ; Mon, 25 Feb 2013 21:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiTBiJc1Hzkl for ; Mon, 25 Feb 2013 21:39:43 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 44D8121E8168 for ; Mon, 25 Feb 2013 21:39:43 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 53DB8C951D; Tue, 26 Feb 2013 05:39:40 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361857182; bh=ZYb7dO6YiaUEJngfN711PxfGXtFU8opNLPIjCRiJ9YA=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=iceCQhqUhOXAQYo9mlN5T2RiyQhraVrpMv+M0UC8QEQMf0OzH02clcSbIinXzlyHi kpV4NsqnVasC0ewpHUpZUXEaErRohBcyPWmwPvn0P9YE/5ql0IFUI2YgPTdFo2Oku/ BlHcCoGlfg1UUaUrhq2ABrMQqoFcSvx+Psr+Wx0U= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Tue, 26 Feb 2013 05:39:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4952:ac91:78ad:bca0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 8E0D8216C43; Tue, 26 Feb 2013 05:39:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 08B1F3012931; Tue, 26 Feb 2013 16:39:33 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <51287D7A.60300@gmail.com> <364CAA7D-4988-462D-B2AA-8729F228884C@townsley.net> <20130226041329.5EFAF30117D1@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 26 Feb 2013 13:39:51 +0900." Date: Tue, 26 Feb 2013 16:39:33 +1100 Message-Id: <20130226053934.08B1F3012931@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "homenet@ietf.org Group" , Mark Townsley Subject: Re: [homenet] renumbering the IETF X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 05:40:11 -0000 In message , Lorenzo Colitti writes: > > On Tue, Feb 26, 2013 at 1:13 PM, Mark Andrews wrote: > > > > Hmm. Do we know for sure that all clients properly depref ULAs below > > global > > > addresses (either because they follow RFC6724 instead of RFC3484, or > > > because they implement the longest prefix matching rule?) If not, some > > > clients might break. > > > > Longest match works well enough 2001/2002 have 14 bits in common. > > fc00 has no bits in common with 2001 or 2002. I've been using ULA > > PA addresses together at home for years without issue. > > > > Which is why I asked whether we know for sure that all clients implement > it. Do we? Does it matter? There will presumably be a ssid without all the experimentation going to fallback to. The only question is this a opt-in or opt-out experiment? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From cb.list6@gmail.com Mon Feb 25 21:54:40 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC77621F956D for ; Mon, 25 Feb 2013 21:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjrK6GYTlsUJ for ; Mon, 25 Feb 2013 21:54:40 -0800 (PST) Received: from mail-gg0-x22d.google.com (mail-gg0-x22d.google.com [IPv6:2607:f8b0:4002:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3099721F956C for ; Mon, 25 Feb 2013 21:54:40 -0800 (PST) Received: by mail-gg0-f173.google.com with SMTP id b6so635404ggm.32 for ; Mon, 25 Feb 2013 21:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2FFyorZYiBXgH6X01PunjEu9e8CLaI2sVnD17LeF7C0=; b=vl32Kaf8GTDclzVuVYXz0og6HeXoOXuMmDlrCAnnt9ZoQkHbw05gZ5hTnkAZ60Zham MLIpgXE2tqXrpLbz2BxmBdiaFhLe6r35CK+KLyxqQ9S03gi7vyRbHs3fMYIGPR3dxpET RyRYjkzXbCL4PzZZmb0k9WHiZp3L7MO4nF195lqvZv6ymZ2qGeU0Fx2NumWQtNqInNJE C0lPznO57lNujQnazq9lzD2fsg5ZIERzNNS5Aw3go2nWnPw4Bb65ekfWzE96QOo/07XA Y8g8DfNxHf+CNshB0MA+M41Sp2fpuKn37T0VUFgnVP82YRaSBhs0s8UADfmqZUG5iWMR e84Q== MIME-Version: 1.0 X-Received: by 10.236.172.164 with SMTP id t24mr23067200yhl.1.1361858079660; Mon, 25 Feb 2013 21:54:39 -0800 (PST) Received: by 10.236.172.233 with HTTP; Mon, 25 Feb 2013 21:54:39 -0800 (PST) Received: by 10.236.172.233 with HTTP; Mon, 25 Feb 2013 21:54:39 -0800 (PST) In-Reply-To: References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> <48F0F7E1-B0C1-455F-A0EA-FD82BAD2EF7A@fugue.com> Date: Mon, 25 Feb 2013 21:54:39 -0800 Message-ID: From: Cameron Byrne To: lorenzo@google.com Content-Type: multipart/alternative; boundary=20cf301d449812a40604d69a4b61 Cc: "homenet@ietf.org" , Ted Lemon , james woodyatt Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 05:54:40 -0000 --20cf301d449812a40604d69a4b61 Content-Type: text/plain; charset=ISO-8859-1 Sent from ipv6-only Android On Feb 26, 2013 11:53 AM, "Lorenzo Colitti" wrote: > > On Tue, Feb 26, 2013 at 12:46 PM, Ted Lemon wrote: >> >> > The alternative is basically a vicious circle: if ISPs ignore the IETF's advice and assign a /64 because they see additional address space as an upsell opportunity, then someone will figure out how to share the /64 by using ugly hacks like routing /128s assigned from DHCPv6. >> >> That might be what you imagine someone will do, but what they almost certainly will actually do is just bridge. Math is hard. > > > Yes, bridging will work because if everything is on one link, DAD will avoid collisions. My point was that there is no way to do routing, even with NPTv6, unless enough address space is assigned to the network. > > Sorry for silly question. But ...is there a pointer to why routing is desired in the home ? Did homenet document usecases for this ? Cb _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --20cf301d449812a40604d69a4b61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Feb 26, 2013 11:53 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Tue, Feb 26, 2013 at 12:46 PM, Ted Lemon <mellon@fugue.com> wrote:
>>
>> > The alternative is basically a vicious circle: if ISPs ignore= the IETF's advice and assign a /64 because they see additional address= space as an upsell opportunity, then someone will figure out how to share = the /64 by using ugly hacks like routing /128s assigned from DHCPv6.
>>
>> That might be what you imagine someone will do, but what they almo= st certainly will actually do is just bridge. =A0 Math is hard.
>
>
> Yes, bridging will work because if everything is on one link, DAD will= avoid collisions. My point was that there is no way to do routing, even wi= th NPTv6, unless enough address space is assigned to the network.
>
>

Sorry for silly question. But ...is there a pointer to why r= outing is desired in the home ?=A0 Did homenet document usecases for this ?=

Cb _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.= ietf.org/mailman/listinfo/homenet
>

--20cf301d449812a40604d69a4b61-- From cb.list6@gmail.com Mon Feb 25 22:01:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E4B21F95E2 for ; Mon, 25 Feb 2013 22:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MikFxwZW9uCy for ; Mon, 25 Feb 2013 22:01:19 -0800 (PST) Received: from mail-gg0-x231.google.com (mail-gg0-x231.google.com [IPv6:2607:f8b0:4002:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 53EF121F95E1 for ; Mon, 25 Feb 2013 22:01:19 -0800 (PST) Received: by mail-gg0-f177.google.com with SMTP id q1so626691gge.8 for ; Mon, 25 Feb 2013 22:01:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lv9pudgbLOqDmRlQ1oLWJEMJjeztyPpGZ9v1vv37bJE=; b=ENBoLGsQbcSeiLda43cbAt0ah1/q+7adrF6el+yl3Nc/RP+7Geua3qNct3Xucc+Z1c YOXpHSL21s1yw3k+T0zUspiDZRgsX2d1djNltUFXIp56cvR/o4meYFxmbBuNifVqdNb8 y2V2Trdhk1EmOhRk4i+FbdlGUfFNdL+wrHDGPpI+V8eZ7ScTeTKDyw7v+wA/3sx7TP3W 3ykiBIZYwOk6X+LjpQQbRdS0MZFmF8D4YoMAgq/asyav8f1EC131rHvU/pYEuEMrKBEW SaTX5GMcA+cehgExQk5otHr7pfW2cTT7LvByCtdpynR383CbziEgcvwHSAcCSxXB4X6E M0sQ== MIME-Version: 1.0 X-Received: by 10.236.69.67 with SMTP id m43mr22994728yhd.40.1361858469385; Mon, 25 Feb 2013 22:01:09 -0800 (PST) Received: by 10.236.172.233 with HTTP; Mon, 25 Feb 2013 22:01:08 -0800 (PST) Received: by 10.236.172.233 with HTTP; Mon, 25 Feb 2013 22:01:08 -0800 (PST) In-Reply-To: References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> <48F0F7E1-B0C1-455F-A0EA-FD82BAD2EF7A@fugue.com> Date: Mon, 25 Feb 2013 22:01:08 -0800 Message-ID: From: Cameron Byrne To: lorenzo@google.com Content-Type: multipart/alternative; boundary=bcaec50b505c4d605404d69a62b7 Cc: "homenet@ietf.org" , Ted Lemon , james woodyatt Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 06:01:20 -0000 --bcaec50b505c4d605404d69a62b7 Content-Type: text/plain; charset=ISO-8859-1 Sent from ipv6-only Android On Feb 26, 2013 1:54 PM, "Cameron Byrne" wrote: > > Sent from ipv6-only Android > > On Feb 26, 2013 11:53 AM, "Lorenzo Colitti" wrote: > > > > On Tue, Feb 26, 2013 at 12:46 PM, Ted Lemon wrote: > >> > >> > The alternative is basically a vicious circle: if ISPs ignore the IETF's advice and assign a /64 because they see additional address space as an upsell opportunity, then someone will figure out how to share the /64 by using ugly hacks like routing /128s assigned from DHCPv6. > >> > >> That might be what you imagine someone will do, but what they almost certainly will actually do is just bridge. Math is hard. > > > > > > Yes, bridging will work because if everything is on one link, DAD will avoid collisions. My point was that there is no way to do routing, even with NPTv6, unless enough address space is assigned to the network. > > > > > > Sorry for silly question. But ...is there a pointer to why routing is desired in the home ? Did homenet document usecases for this ? > Ok. I see it in the charter. I dont find it particularly appealing or worth a great trade off for the level of complexity involved. Especially if the tradeoffs require nat66 or something similarly complex CB > Cb _______________________________________________ > > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > --bcaec50b505c4d605404d69a62b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Feb 26, 2013 1:54 PM, "Cameron Byrne" <cb.list6@gmail.com> wrote:
>
> Sent from ipv6-only Android
>
> On Feb 26, 2013 11:53 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
> >
> > On Tue, Feb 26, 2013 at 12:46 PM, Ted Lemon <mellon@fugue.com> wrote:
> >>
> >> > The alternative is basically a vicious circle: if ISPs i= gnore the IETF's advice and assign a /64 because they see additional ad= dress space as an upsell opportunity, then someone will figure out how to s= hare the /64 by using ugly hacks like routing /128s assigned from DHCPv6. > >>
> >> That might be what you imagine someone will do, but what they= almost certainly will actually do is just bridge. =A0 Math is hard.
> >
> >
> > Yes, bridging will work because if everything is on one link, DAD= will avoid collisions. My point was that there is no way to do routing, ev= en with NPTv6, unless enough address space is assigned to the network.
> >
> >
>
> Sorry for silly question. But ...is there a pointer to why routing is = desired in the home ?=A0 Did homenet document usecases for this ?
>

Ok. I see it in the charter. I dont find it particularly app= ealing or worth a great trade off for the level of complexity involved. Esp= ecially if the tradeoffs require nat66 or something similarly complex

CB
> Cb _______________________________________________
>
> > homenet mailing list
> > homenet@ietf.org
> > https:/= /www.ietf.org/mailman/listinfo/homenet
> >

--bcaec50b505c4d605404d69a62b7-- From fernando@gont.com.ar Mon Feb 25 22:15:40 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E571D21F9665 for ; Mon, 25 Feb 2013 22:15:39 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwJ8wp+H9bvy for ; Mon, 25 Feb 2013 22:15:38 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2B521F9662 for ; Mon, 25 Feb 2013 22:15:38 -0800 (PST) Received: from [186.137.77.228] (helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UADod-0003QJ-9z; Tue, 26 Feb 2013 07:15:11 +0100 Message-ID: <512C52DB.9040406@gont.com.ar> Date: Tue, 26 Feb 2013 03:14:51 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Simon Kelley References: <512902cc.8632700a.0347.5c46@mx.google.com> <5129041C.2090106@thekelleys.org.uk> In-Reply-To: <5129041C.2090106@thekelleys.org.uk> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ted Lemon , "homenet@ietf.org" , Teemu Savolainen , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 06:15:40 -0000 Hi, Simon, On 02/23/2013 03:02 PM, Simon Kelley wrote: > On 23/02/13 17:56, Teemu Savolainen wrote: >> And this works with hosts that use IPv6 privacy addresses and not have >> IIDs derived from MAC? > > If they have only privacy addresses, it doesn't work. If they have both > a SLAAC address and a privacy address, and use the privacy address when > initiating connections (for privacy), but accept connections to the > SLAAC address, then it still works. But.. if you're learning the IPv6 addresses based on the assumption that they are the traditional SLAAC addresses (that embed IEEE identifiers), you'd be missing IPv6 addresses of Windows nodes (which do not generate IIDs according to traditional SLAAC), any nodes using CGAs, etc. Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fgont@si6networks.com Mon Feb 25 22:40:43 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F21021F91CB for ; Mon, 25 Feb 2013 22:40:43 -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_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqGNdPAYrzaT for ; Mon, 25 Feb 2013 22:40:42 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0C08A21F90E6 for ; Mon, 25 Feb 2013 22:40:42 -0800 (PST) Received: from [186.137.77.228] (helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UAECO-000415-J0; Tue, 26 Feb 2013 07:39:38 +0100 Message-ID: <512C589E.9040104@si6networks.com> Date: Tue, 26 Feb 2013 03:39:26 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ted Lemon References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> In-Reply-To: <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , Michael Thomas , Mark Townsley , Dave Taht , Jari Arkko , "Brzozowski, John" , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 06:40:43 -0000 Hi, Ted, On 02/22/2013 04:44 PM, Ted Lemon wrote: > On Feb 22, 2013, at 10:01 AM, Michael Thomas wrote: >> Right now, I don't think that sufficient energy is being given to >> just one obvious problem: how does real DNS interact with prefix >> delegation in the home (assuming that we don't want split horizon >> dns)? For that matter, let me be even more blunt: I don't think >> that real DNS is being given enough attention altogether in home >> settings, and until that happens we'll just inherit all of the >> awful hacks that are done with NATv4. > > Agreed. I'm delighted to hear that Simon has a hack in dnamasq that > addresses this problem in a dual-stack environment, but I want to > have a serious conversation somewhere about how to address the > problem on the v6-only homenet. > > Who's interested in sketching a DNS-based solution to the problem and > has time to work on it? I've been lurking for the most time, so.. double-checking: essentially, what you want is that you always keep DNS for nodes in the internal network, and those entries remain up-to-date e.g. in the presence of renumbering? (I guess dynamic updates by each client is not acceptable, so there should be some kind of "proxy" doing the job for the local net, right?) If I got your problem statement right, I'd argue that there are, essentially, two problems here: 1) Learning the IPv6 addresses in use 2) Updating the DNS accordingly "1" is already solved by . "2" could be an add-on to ipv6mon, that would do the DNS updates according to the address changes. If the above sounds sensible, I voulteer to: 1) Write the code that does what I've described above 2) Write an I-D that describes what I've done with the code. :-) Thoughts? Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From simon@thekelleys.org.uk Mon Feb 25 23:43:23 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BCB21F85C0 for ; Mon, 25 Feb 2013 23:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqZRyc5t89cx for ; Mon, 25 Feb 2013 23:43:23 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF2221F8203 for ; Mon, 25 Feb 2013 23:43:23 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:37690 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UAFC6-0000iS-31 for homenet@ietf.org; Tue, 26 Feb 2013 07:43:22 +0000 Received: from archie.thekelleys.org.uk ([192.168.1.167]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1UAFC5-00025C-HU for homenet@ietf.org; Tue, 26 Feb 2013 07:43:21 +0000 Message-ID: <512C67A2.1060607@thekelleys.org.uk> Date: Tue, 26 Feb 2013 07:43:30 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <512902cc.8632700a.0347.5c46@mx.google.com> <5129041C.2090106@thekelleys.org.uk> <512C52DB.9040406@gont.com.ar> In-Reply-To: <512C52DB.9040406@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 07:43:23 -0000 On 26/02/13 06:14, Fernando Gont wrote: > Hi, Simon, > > On 02/23/2013 03:02 PM, Simon Kelley wrote: >> On 23/02/13 17:56, Teemu Savolainen wrote: >>> And this works with hosts that use IPv6 privacy addresses and not have >>> IIDs derived from MAC? >> >> If they have only privacy addresses, it doesn't work. If they have both >> a SLAAC address and a privacy address, and use the privacy address when >> initiating connections (for privacy), but accept connections to the >> SLAAC address, then it still works. > > But.. if you're learning the IPv6 addresses based on the assumption that > they are the traditional SLAAC addresses (that embed IEEE identifiers), > you'd be missing IPv6 addresses of Windows nodes (which do not generate > IIDs according to traditional SLAAC), any nodes using CGAs, etc. On my network, the Windows nodes use stateful DHCPv6. I don't see this technique as a universal panacea or something to necessarily rely on going forward, but it does make naming work _for_existing_deployed_systems. It works, for instance, with hundreds of millions of existing Android phones and tablets, 99.99% of which will never be upgraded. Simon. > > Cheers, > From simon@thekelleys.org.uk Mon Feb 25 23:52:54 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBD221F868E for ; Mon, 25 Feb 2013 23:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHrYYp3aWu7g for ; Mon, 25 Feb 2013 23:52:44 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0A221F8697 for ; Mon, 25 Feb 2013 23:52:42 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:37709 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UAFL7-0000kL-Ki for homenet@ietf.org; Tue, 26 Feb 2013 07:52:41 +0000 Received: from archie.thekelleys.org.uk ([192.168.1.167]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1UAFL7-0002MJ-37 for homenet@ietf.org; Tue, 26 Feb 2013 07:52:41 +0000 Message-ID: <512C69D2.9050105@thekelleys.org.uk> Date: Tue, 26 Feb 2013 07:52:50 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> In-Reply-To: <512C589E.9040104@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 07:52:54 -0000 On 26/02/13 06:39, Fernando Gont wrote: > Hi, Ted, > > On 02/22/2013 04:44 PM, Ted Lemon wrote: >> On Feb 22, 2013, at 10:01 AM, Michael Thomas wrote: >>> Right now, I don't think that sufficient energy is being given to >>> just one obvious problem: how does real DNS interact with prefix >>> delegation in the home (assuming that we don't want split horizon >>> dns)? For that matter, let me be even more blunt: I don't think >>> that real DNS is being given enough attention altogether in home >>> settings, and until that happens we'll just inherit all of the >>> awful hacks that are done with NATv4. >> >> Agreed. I'm delighted to hear that Simon has a hack in dnamasq that >> addresses this problem in a dual-stack environment, but I want to >> have a serious conversation somewhere about how to address the >> problem on the v6-only homenet. >> >> Who's interested in sketching a DNS-based solution to the problem and >> has time to work on it? > > I've been lurking for the most time, so.. double-checking: essentially, > what you want is that you always keep DNS for nodes in the internal > network, and those entries remain up-to-date e.g. in the presence of > renumbering? (I guess dynamic updates by each client is not acceptable, > so there should be some kind of "proxy" doing the job for the local net, > right?) Dnsmasq handles this already in the "guess slaac-addresses" case. When a new prefix is added to the network, dnsmasq advertises it and goes through the existing DHCPv4 leases and pings the new putative addresses, adding any that respond as AAAA records. I'm not sure that hosts using stateful DHCPv6 fare so well, not least because I don't really understand what is meant to happen in the DHCP protocol in such circumstances. > > If I got your problem statement right, I'd argue that there are, > essentially, two problems here: > 1) Learning the IPv6 addresses in use > 2) Updating the DNS accordingly Dnsmasq does both of these for internal DNS, it's just an extension of what it has always done in IPv4 land. There's a new test release that does the same for external DNS, by acting as the authoritative server for a zone, and/or providing zone transfer to other authoritative servers. > > "1" is already solved by . > "2" could be an add-on to ipv6mon, that would do the DNS updates > according to the address changes. > > If the above sounds sensible, I voulteer to: > 1) Write the code that does what I've described above > 2) Write an I-D that describes what I've done with the code. :-) Simon. From fgont@si6networks.com Tue Feb 26 00:03:23 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3366D21F88A1 for ; Tue, 26 Feb 2013 00:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.341 X-Spam-Level: X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BXRLUko9JIJ for ; Tue, 26 Feb 2013 00:03:22 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8D65521F889D for ; Tue, 26 Feb 2013 00:03:22 -0800 (PST) Received: from [186.137.77.228] (helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UAFVO-0005ys-FY; Tue, 26 Feb 2013 09:03:18 +0100 Message-ID: <512C6C40.8010406@si6networks.com> Date: Tue, 26 Feb 2013 05:03:12 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Simon Kelley References: <512902cc.8632700a.0347.5c46@mx.google.com> <5129041C.2090106@thekelleys.org.uk> <512C52DB.9040406@gont.com.ar> <512C67A2.1060607@thekelleys.org.uk> In-Reply-To: <512C67A2.1060607@thekelleys.org.uk> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 08:03:23 -0000 On 02/26/2013 04:43 AM, Simon Kelley wrote: >> But.. if you're learning the IPv6 addresses based on the assumption that >> they are the traditional SLAAC addresses (that embed IEEE identifiers), >> you'd be missing IPv6 addresses of Windows nodes (which do not generate >> IIDs according to traditional SLAAC), any nodes using CGAs, etc. > > On my network, the Windows nodes use stateful DHCPv6. I don't see this > technique as a universal panacea or something to necessarily rely on > going forward, but it does make naming work > _for_existing_deployed_systems. It works, for instance, with hundreds of > millions of existing Android phones and tablets, 99.99% of which will > never be upgraded. Agreed. I was mostly thinking about the IPv6-only case, and also about a more general technique that would still work with SLAAC when hte IIDs do not include MAC addresses. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Feb 26 00:06:01 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A4121F88B1 for ; Tue, 26 Feb 2013 00:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpyDvHYp91Iv for ; Tue, 26 Feb 2013 00:06:00 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5B021F88B0 for ; Tue, 26 Feb 2013 00:06:00 -0800 (PST) Received: from [186.137.77.228] (helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UAFXw-00066l-8I; Tue, 26 Feb 2013 09:05:56 +0100 Message-ID: <512C6CDF.9030807@si6networks.com> Date: Tue, 26 Feb 2013 05:05:51 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Simon Kelley References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C69D2.9050105@thekelleys.org.uk> In-Reply-To: <512C69D2.9050105@thekelleys.org.uk> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 08:06:01 -0000 On 02/26/2013 04:52 AM, Simon Kelley wrote: >> I've been lurking for the most time, so.. double-checking: essentially, >> what you want is that you always keep DNS for nodes in the internal >> network, and those entries remain up-to-date e.g. in the presence of >> renumbering? (I guess dynamic updates by each client is not acceptable, >> so there should be some kind of "proxy" doing the job for the local net, >> right?) > > Dnsmasq handles this already in the "guess slaac-addresses" case. When a > new prefix is added to the network, dnsmasq advertises it and goes > through the existing DHCPv4 leases and pings the new putative addresses, > adding any that respond as AAAA records. > > I'm not sure that hosts using stateful DHCPv6 fare so well, not least > because I don't really understand what is meant to happen in the DHCP > protocol in such circumstances. You mean in the circumstance of renumbering, or what? >> If I got your problem statement right, I'd argue that there are, >> essentially, two problems here: >> 1) Learning the IPv6 addresses in use >> 2) Updating the DNS accordingly > > Dnsmasq does both of these for internal DNS, it's just an extension of > what it has always done in IPv4 land. There's a new test release that > does the same for external DNS, by acting as the authoritative server > for a zone, and/or providing zone transfer to other authoritative servers. As noted in my previous email, I was trying to address the v6-only case, and also tryng to come up with a general technique that would handle the case of SLAAC with IIDs that do not embed MAC addresses. Cheers -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Tue Feb 26 02:50:50 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855D121F8A53 for ; Tue, 26 Feb 2013 02:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.773 X-Spam-Level: X-Spam-Status: No, score=-101.773 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq+NDXqC8GmK for ; Tue, 26 Feb 2013 02:50:49 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 74CF721F8812 for ; Tue, 26 Feb 2013 02:50:49 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id t44so3381506wey.40 for ; Tue, 26 Feb 2013 02:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gkRAGW84urxfa84Ja2sfk4ni2M5KihmXOHcniJzgaKw=; b=QwIe0tdGSukV738C7Wc4U3qoGXeZFHTmfG8Ny84cz6Q5IyH4UFL7FR1YPNm182lELq 0kzx68eMWvdEITly0qxTDO3XWD8XzKqFMvK45X5Zs5T0c8YpKGZK7JJCtajLGReRrv0D cfc4GiZ8ifu4Yw2ZfOHLp4acmC5GGEp+evTh0cOzRPtwqDrqgPewCkv2R3CAP5H4PuFq WLjTshTRmthZXsNufKmm1SnINZnCTxIHyypdQL9kjt7By4Zo6FR4XLOaFCxGWQipJMj6 xXzTxK+JuejqAXgRUTf5Vb6N+3+dWB/h2k+xjz2dzqPePHnIubw5QbriUovRtx5L6VHT BAgg== X-Received: by 10.194.122.131 with SMTP id ls3mr25430990wjb.55.1361875848627; Tue, 26 Feb 2013 02:50:48 -0800 (PST) Received: from [128.232.110.102] (c102.al.cl.cam.ac.uk. [128.232.110.102]) by mx.google.com with ESMTPS id n2sm20287646wiy.6.2013.02.26.02.50.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 02:50:47 -0800 (PST) Message-ID: <512C938C.4080702@gmail.com> Date: Tue, 26 Feb 2013 10:50:52 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> In-Reply-To: <512C589E.9040104@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Brzozowski, John" , Michael Richardson , Michael Thomas , Mark Townsley , Dave Taht , Jari Arkko , Ted Lemon , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 10:50:50 -0000 On 26/02/2013 06:39, Fernando Gont wrote: ... > I've been lurking for the most time, so.. double-checking: essentially, > what you want is that you always keep DNS for nodes in the internal > network, and those entries remain up-to-date e.g. in the presence of > renumbering? (I guess dynamic updates by each client is not acceptable, Why not? That's what Secure DDNS Update is intended for, isn't it? Brian From fgont@si6networks.com Tue Feb 26 03:06:41 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BBC21F8A53 for ; Tue, 26 Feb 2013 03:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uS6QaqGt5Dl for ; Tue, 26 Feb 2013 03:06:40 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id A5E2821F8A51 for ; Tue, 26 Feb 2013 03:06:40 -0800 (PST) Received: from [186.137.77.228] (helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UAILB-0001n6-8l; Tue, 26 Feb 2013 12:04:57 +0100 Message-ID: <512C96CF.5090906@si6networks.com> Date: Tue, 26 Feb 2013 08:04:47 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> In-Reply-To: <512C938C.4080702@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ted Lemon , Michael Richardson , Michael Thomas , Mark Townsley , Dave Taht , Jari Arkko , "BrzoBecausezowski, John" , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 11:06:41 -0000 On 02/26/2013 07:50 AM, Brian E Carpenter wrote: > On 26/02/2013 06:39, Fernando Gont wrote: > ... >> I've been lurking for the most time, so.. double-checking: essentially, >> what you want is that you always keep DNS for nodes in the internal >> network, and those entries remain up-to-date e.g. in the presence of >> renumbering? (I guess dynamic updates by each client is not acceptable, > > Why not? Because if it's acceptable, there's no problem to worry about? :-) -- I guess the thing with dynamic updates is that it doesn't work with "zero configuration" (unless one assumes that updates on a local network could be allowed to be unauthenticated?) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From mellon@fugue.com Tue Feb 26 04:10:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC8021F8A45 for ; Tue, 26 Feb 2013 04:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75OjuyZ0obYN for ; Tue, 26 Feb 2013 04:10:57 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE1E21F8901 for ; Tue, 26 Feb 2013 04:10:44 -0800 (PST) Received: from [10.0.1.14] (user-387gmsm.cable.mindspring.com [208.120.91.150]) by toccata.fugue.com (Postfix) with ESMTPSA id 99B23238033D; Tue, 26 Feb 2013 07:10:42 -0500 (EST) References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> <48F0F7E1-B0C1-455F-A0EA-FD82BAD2EF7A@fugue.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Ted Lemon Date: Tue, 26 Feb 2013 07:10:42 -0500 To: Cameron Byrne Cc: "homenet@ietf.org" , james woodyatt , "lorenzo@google.com" Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:10:57 -0000 On Feb 26, 2013, at 1:01 AM, Cameron Byrne wrote: > Ok. I see it in the charter. I dont find it particularly appealing or wort= h a great trade off for the level of complexity involved. Especially if the t= radeoffs require nat66 or something similarly complex Touch=A8=A6. Seriously, though, the point of routing in the home is that you really don't= want to bridge disparate media, and you want routers plugged together by pe= ople who don't know about routing to create a happy, functioning network, no= t a dysfunctional network that sort of works but is never satisfactory. I'm sure Mark would give you a different sales pitch, but that's why I'm int= erested in it. From ot@cisco.com Tue Feb 26 04:19:10 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E81821F8A89 for ; Tue, 26 Feb 2013 04:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYVPXpcUrH55 for ; Tue, 26 Feb 2013 04:19:09 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6C77A21F86D5 for ; Tue, 26 Feb 2013 04:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1003; q=dns/txt; s=iport; t=1361881149; x=1363090749; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UoDz89wmMIOLeB47iGLFbUb9Uf/G/WEV2jl9ylFYK44=; b=O8KnzwJvN9NJ3djrAvcwx5604FbJCGhtNJwXm2GXOlY7IWIyKIiFqMy0 8pk00yULuunwtfv/3x2OrUezsswUfJM/LU7ic3V6zt7biCOePYiDaTg/u oc4YxvtxorH/5VQaZFq38kD37092iVKVymENbG8UpFKki+ee1tlU+R3b1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMSmLFGQ/khR/2dsb2JhbABFhk+7EX4Wc4IfAQEBAwF5EAsODigCVwaIIAaRbpp9CII+j1yBH404MweCKTZhA4g4jgWQZ4MI X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; d="scan'208";a="12064485" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 26 Feb 2013 12:19:08 +0000 Received: from dhcp-lys01-vla250-10-147-112-164.cisco.com (dhcp-lys01-vla250-10-147-112-164.cisco.com [10.147.112.164]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1QCJ7an031635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Feb 2013 12:19:08 GMT Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: Date: Tue, 26 Feb 2013 13:19:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5322F4D7-8A16-4821-A63E-29DFBC556614@cisco.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> <48F0F7E1-B0C1-455F-A0EA-FD82BAD2EF7A@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) Cc: Cameron Byrne , "lorenzo@google.com" , "homenet@ietf.org" , james woodyatt Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:19:10 -0000 >> Ok. I see it in the charter. I dont find it particularly appealing or = worth a great trade off for the level of complexity involved. Especially = if the tradeoffs require nat66 or something similarly complex >=20 > Touch=A8=A6. >=20 > Seriously, though, the point of routing in the home is that you really = don't want to bridge disparate media, and you want routers plugged = together by people who don't know about routing to create a happy, = functioning network, not a dysfunctional network that sort of works but = is never satisfactory. exactly. the arguments I've heard are: - people just plug in whatever they bought, it must work regardless of = being a router or a bridge - not all link-layers can be bridged together e.g. 802.15.4 - problems with bridging links with very different speed = characteristics e.g. 802.11 and 1G wired - isolation between networks with different policy, e.g. guest = networks, internal home automation, public wifi cheers, Ole From mellon@fugue.com Tue Feb 26 04:19:58 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93FD21F86D5 for ; Tue, 26 Feb 2013 04:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Yn142cxSejV for ; Tue, 26 Feb 2013 04:19:58 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8E921F86CB for ; Tue, 26 Feb 2013 04:19:58 -0800 (PST) Received: from [10.0.1.14] (user-387gmsm.cable.mindspring.com [208.120.91.150]) by toccata.fugue.com (Postfix) with ESMTPSA id 06A82238033D; Tue, 26 Feb 2013 07:19:57 -0500 (EST) References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> Mime-Version: 1.0 (1.0) In-Reply-To: <512C96CF.5090906@si6networks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B146) From: Ted Lemon Date: Tue, 26 Feb 2013 07:19:58 -0500 To: Fernando Gont Cc: Michael Richardson , Michael Thomas , Mark Townsley , Dave Taht , Jari Arkko , "BrzoBecausezowski, John" , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:19:59 -0000 On Feb 26, 2013, at 6:04 AM, Fernando Gont wrote: > -- I guess the thing with dynamic updates is that it doesn't work with > "zero configuration" (unless one assumes that updates on a local network > could be allowed to be unauthenticated?) There are lots of ways to make dynamic update work on a local network that w= ouldn't be acceptable on an enterprise network. For instance, you could ju= st say "if someone sends an update from an IP address, and that update insta= lls an AAAA record pointing to that IP address, allow it." Or you could us= e the CGA-TSIG draft. Or you could use stateful DHCPv6. Or you could use= stateless DHCPv6. Homenets aren't zeroconf--there has to be a way, at a minimum, to communicat= e a prefix and a DNS server address. This can be done with RA, or with RA+= stateless DHCPv6, or with stateful DHCPv6. So in a homenet we can expect t= hat there _will_ be a mechanism that _could_ be made to work for setting up D= NS; the questions are: (1) Which ways do we support, if any? (2) How do we resolve the question of who is the local DNS server? As far as I can tell, this whole notion has been punted in favor of multi-su= bnet mDNS; my concern is that we are going to wind up with a new protocol th= at's a weird amalgam of mDNS and DNS but shares little code with existing im= plementations of either protocol/= From fgont@si6networks.com Tue Feb 26 06:23:27 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACDA21F8867 for ; Tue, 26 Feb 2013 06:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ksaEtoDtWHe for ; Tue, 26 Feb 2013 06:23:26 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 45BED21F8745 for ; Tue, 26 Feb 2013 06:23:24 -0800 (PST) Received: from [186.137.77.228] (helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UALPq-0006Yf-KY; Tue, 26 Feb 2013 15:21:58 +0100 Message-ID: <512CC4FD.2020804@si6networks.com> Date: Tue, 26 Feb 2013 11:21:49 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ted Lemon References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , Michael Thomas , Mark Townsley , Dave Taht , Jari Arkko , "BrzoBecausezowski, John" , Fernando Gont , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:23:27 -0000 On 02/26/2013 09:19 AM, Ted Lemon wrote: > Homenets aren't zeroconf--there has to be a way, at a minimum, to > communicate a prefix and a DNS server address. This can be done > with RA, or with RA+stateless DHCPv6, or with stateful DHCPv6. So > in a homenet we can expect that there _will_ be a mechanism that > _could_ be made to work for setting up DNS; the questions are: > > (1) Which ways do we support, if any? Stupid question: Can we enforce requirements on host implementations as a result of homenet? (e.g., among all the nice pieces of DDNS, how many of them are widely implemented? and if not widely implemented, can we push changes in this area?) If we cannot do that, but can spec functionality in, say, home routers, then something along the lines of what I sketched in my previous email might make more sense. > (2) How do we resolve the question of who is the local DNS server? You mean the authoritative DNS server for nodes in the local network? > As far as I can tell, this whole notion has been punted in favor of > multi-subnet mDNS; my concern is that we are going to wind up with a > new protocol that's a weird amalgam of mDNS and DNS but shares little > code with existing implementations of either protocol/ Since I was not involved in such discussions, just double-checking: I guess the whole argument for DNS had to do with * No need for authoritative servers? * Availability of "local" zones, as opposed to global zones? * Something (technical :-) ) else? I think that it shouldn't be hard to come up with something to make DNS work with local zones, without relying on multicast (and thus avoiding the need to do mDNS). If there's interest in exploring this path, I could give this some thought -- just checking the mDNS thing is not casted into stone, such that I avoid wasting time unnecessarily... Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Ray.Bellis@nominet.org.uk Tue Feb 26 06:26:31 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEC921F8A0D for ; Tue, 26 Feb 2013 06:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N1lDjEBJMT6 for ; Tue, 26 Feb 2013 06:26:28 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8F15121F8883 for ; Tue, 26 Feb 2013 06:26:28 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=W+yDtwOY2ZLYQBngbVouMsJMHI6ztL36Ubx5m4CuBT428PR2DFqQ1Qib y9z251fv48AMdGJoDVjOuN7SIueCVdJj20BQMB3c0KXDbhg0sUAKSHeaQ /trz9QSB5J1r4HJ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1361888788; x=1393424788; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20NPTv6-only=20home=20network s|Date:=20Tue,=2026=20Feb=202013=2014:26:26=20+0000 |Message-ID:=20<53F00E5CD8B2E34C81C0C89EB0B4FE7310575C86@ wds-exc1.okna.nominet.org.uk>|To:=20Fernando=20Gont=20|CC:=20"homenet@ietf.org=20Group"=20< homenet@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20|In-Reply-To:=20<512CC4FD.2020804@si6networks .com>|References:=20=0D=0A=20<5126E021.6020103 @mtcc.com>=0D=0A=20=0D=0A=20<81675C1D-FFA8-452 D-B8BD-147533074F13@fugue.com>=20<51278850.5080102@mtcc.c om>=0D=0A=20<7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.c om>=0D=0A=20<512C589E.9040104@si6networks.com>=20<512C938 C.4080702@gmail.com>=0D=0A=20<512C96CF.5090906@si6network s.com>=0D=0A=20=0D=0A=20<512CC4FD.2020804@si6networks.com>; bh=8+pOw+bKLRHKc/HTqVY637hNwKdOZKfCkapG80zbbDs=; b=l3mfaSnl8QidPb2QXieMm3QFzUWsrXt8oL509vxeIQI6rSAEpXqrZciA h7FgvvNRJEVwmlH37N/ttkofk4R9jBwnWx6KEHr6RAPj2Tp/1KHgFXLXL t9NQIVBhB7/Tc9O; X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="38640275" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 26 Feb 2013 14:26:27 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 14:26:27 +0000 From: Ray Bellis To: Fernando Gont Thread-Topic: [homenet] NPTv6-only home networks Thread-Index: AQHOEKWv+JgGPqveS02imDGd8UEyzZiFMTuAgAAYXwCAAIX9AIAAKiIAgABO8YCABW4UAIAARkAAgAAD5ICAABUBAIAAIgyAgAABSgA= Date: Tue, 26 Feb 2013 14:26:26 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE7310575C86@wds-exc1.okna.nominet.org.uk> References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> <512CC4FD.2020804@si6networks.com> In-Reply-To: <512CC4FD.2020804@si6networks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:26:31 -0000 On 26 Feb 2013, at 14:21, Fernando Gont wrote: > Stupid question: > Can we enforce requirements on host implementations as a result of > homenet? We should avoid it wherever possible. Ray From ot@cisco.com Tue Feb 26 06:29:08 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0E021F88B9 for ; Tue, 26 Feb 2013 06:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2dPMGPIm7oM for ; Tue, 26 Feb 2013 06:29:07 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DEBFA21F8432 for ; Tue, 26 Feb 2013 06:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=223; q=dns/txt; s=iport; t=1361888947; x=1363098547; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8bPR3065hAJhAnh7aBmik9akySqaYqW3awz7GorjzFs=; b=E67mBxF3g7RDpfTAICmpHQ3g1VSWmSN9UG3G+iZyxZRpUcco4w6PEHV2 mwZBfmCJaUVbfcW7Ml6bxqYfazVEamcDHd3ssLV89rxoQUsDpVsLIiPou qJlM6lYhG630T1X5P4Zx8CBtf+xZgo2hcqgW6GYN649f9JdYRty/9S/Qf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAErGLFGQ/khR/2dsb2JhbABFwWl9FnOCHwEBAQMBOj8QC0ZXBoggBq9pj12PFAeCX2EDlkCQaIMJ X-IronPort-AV: E=Sophos;i="4.84,740,1355097600"; d="scan'208";a="150946889" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 26 Feb 2013 14:29:02 +0000 Received: from dhcp-lys01-vla250-10-147-112-164.cisco.com (dhcp-lys01-vla250-10-147-112-164.cisco.com [10.147.112.164]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1QET2u0026464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Feb 2013 14:29:02 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE7310575C86@wds-exc1.okna.nominet.org.uk> Date: Tue, 26 Feb 2013 15:29:01 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> <512CC4FD.2020804@si6networks.com> <53F00E5CD8B2E34C81C0C89EB0B4FE7310575C86@wds-exc1.okna.nominet.org.uk> To: Ray Bellis X-Mailer: Apple Mail (2.1499) Cc: Fernando Gont , "homenet@ietf.org Group" Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:29:08 -0000 >> Stupid question: >> Can we enforce requirements on host implementations as a result of >> homenet? > > We should avoid it wherever possible. for service discovery that's pretty much unavoidable. cheers, Ole From Ray.Bellis@nominet.org.uk Tue Feb 26 06:43:31 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D67F21F8A8E for ; Tue, 26 Feb 2013 06:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMyyvGryMssu for ; Tue, 26 Feb 2013 06:43:30 -0800 (PST) Received: from mx3.nominet.org.uk (mail.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id EFF1D21F8995 for ; Tue, 26 Feb 2013 06:43:28 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=c33VnhuPYvJCNMICgpAi5uhq43BipqziggK33H33AHiL0niWRpnKroOg /vDV1CvD+uHU7n82iDwJIrbEb+TIqfy/Z3NLpVuKabqilqdtBYjg7t7iy Ma74o+s4zpHmgmb; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1361889809; x=1393425809; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20NPTv6-only=20home=20network s|Date:=20Tue,=2026=20Feb=202013=2014:43:26=20+0000 |Message-ID:=20<53F00E5CD8B2E34C81C0C89EB0B4FE7310576DB5@ wds-exc1.okna.nominet.org.uk>|To:=20Ole=20Troan=20|CC:=20"homenet@ietf.org=20Group"=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20quo ted-printable|Content-ID:=20|In-Reply-To:=20|References:=20=0D=0A=20<5126E021.6020103@mtcc.com>=0D=0A=20 =0D=0A=20<81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> =20<51278850.5080102@mtcc.com>=0D=0A=20<7C9831DB-E0DC-43E 1-AEDC-BA2DA1D8A6A4@fugue.com>=0D=0A=20<512C589E.9040104@ si6networks.com>=20<512C938C.4080702@gmail.com>=0D=0A=20< 512C96CF.5090906@si6networks.com>=0D=0A=20=0D=0A=20<512CC4FD.20208 04@si6networks.com>=0D=0A=20<53F00E5CD8B2E34C81C0C89EB0B4 FE7310575C86@wds-exc1.okna.nominet.org.uk>=0D=0A=20; bh=DKgq2bfWUpnsdbH1HHPsjzXqDlp/XZXK/d6dXCHaHdg=; b=MgCPrEKWOioYrM4K7rOvB5k2ksMNm93FJEP5Rpg4n1Bi78/wzSaTVqJF ZUrpxis1Yerh0S/spr6UlkawRw25iVdQgLqTiIKd3PiOpg0vbHu+j+2Hr vBrMKtctiKG1187; X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="46741766" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 26 Feb 2013 14:43:27 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 14:43:27 +0000 From: Ray Bellis To: Ole Troan Thread-Topic: [homenet] NPTv6-only home networks Thread-Index: AQHOEKWv+JgGPqveS02imDGd8UEyzZiFMTuAgAAYXwCAAIX9AIAAKiIAgABO8YCABW4UAIAARkAAgAAD5ICAABUBAIAAIgyAgAABSgCAAAC5gIAABAcA Date: Tue, 26 Feb 2013 14:43:26 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE7310576DB5@wds-exc1.okna.nominet.org.uk> References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> <512CC4FD.2020804@si6networks.com> <53F00E5CD8B2E34C81C0C89EB0B4FE7310575C86@wds-exc1.okna.nominet.org.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:43:31 -0000 On 26 Feb 2013, at 14:29, Ole Troan wrote: > for service discovery that's pretty much unavoidable. That's true. The charter does in fact acknowledge this: "Prefix configuration, routing, and security related work shall not cause a= ny changes that are not backwards compatible to existing IPv6 hosts. There = may be host visible changes in the work on naming and discovery protocols, = ..." Ray From mike@mtcc.com Tue Feb 26 06:48:53 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BD921F8999 for ; Tue, 26 Feb 2013 06:48:53 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id en9-xqo7RQ5H for ; Tue, 26 Feb 2013 06:48:52 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id C68A421F8883 for ; Tue, 26 Feb 2013 06:48:52 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1QEmiXE013294 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Feb 2013 06:48:46 -0800 Message-ID: <512CCB4C.5060507@mtcc.com> Date: Tue, 26 Feb 2013 06:48:44 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ted Lemon References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1555; t=1361890126; x=1362754126; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20NPTv6-only=20home=20network s |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=b+WskWbznvpj6dOrBAANWcUXpRoY33RaxpRJXgtRBoQ=; b=Z/Ff8mSNpZHuO4MAcbS2yf/764gI5UdYzSJgzw6XQ41YXaXC4gKYsL47v6 HFSMIGS5YcSuuEAM0PM3ozqOkXAydgaF+a1Mcezyf/0Tn86voloGLeVgZuzJ qLvJgCbQJlzGaw8Sw2hLNdQT+7DdfS11R9QoddHEzzFFX417wdbjk=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Michael Richardson , Mark Townsley , Dave Taht , Jari Arkko , "BrzoBecausezowski, John" , "homenet@ietf.org Group" Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:48:54 -0000 On 02/26/2013 04:19 AM, Ted Lemon wrote: > On Feb 26, 2013, at 6:04 AM, Fernando Gont wrote: >> -- I guess the thing with dynamic updates is that it doesn't work with >> "zero configuration" (unless one assumes that updates on a local network >> could be allowed to be unauthenticated?) > There are lots of ways to make dynamic update work on a local network that wouldn't be acceptable on an enterprise network. For instance, you could just say "if someone sends an update from an IP address, and that update installs an AAAA record pointing to that IP address, allow it." Or you could use the CGA-TSIG draft. Or you could use stateful DHCPv6. Or you could use stateless DHCPv6. What I've been rolling through my head is a host being able to claim a a name in a namespace when it attaches to a network provable by possession of an asymmetric key it generates. The host could update that name binding at any time (eg, change the AAAA) just by signing the update with that key. The DNS could age those name bindings to get rid of transient names (eg, phones that come and go on your homenet). The "trust model" here is the ability to get onto my homenet at all, I think. That is, I have the password to an SSID. Maybe different SSID's have different DNS subdomains like XXX.guest.myhomedomain.org. How this lines up with other work, or whether it meets the myriad of other requirements, I do not know. But it at least seems plausible to me for a littleconf kind of deployment like a homenet. Mike From fgont@si6networks.com Tue Feb 26 07:05:33 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8EF21F8995 for ; Tue, 26 Feb 2013 07:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfdM+qjf7uk9 for ; Tue, 26 Feb 2013 07:05:32 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC7521F8A89 for ; Tue, 26 Feb 2013 07:05:32 -0800 (PST) Received: from [186.137.77.228] (helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UAM5y-0007hM-9C; Tue, 26 Feb 2013 16:05:30 +0100 Message-ID: <512CCF34.9010705@si6networks.com> Date: Tue, 26 Feb 2013 12:05:24 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "homenet@ietf.org" X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:05:33 -0000 Folks, Just to kick some discussion: Regarding naming and service discovery, it seems that there are folks that are in the camp of "let's make mDNS work on multiple segments", while others seem to be in the camp of "this should be done with DNS". May I introduce a third option? mDNS for the local net, DNS to glue the multiple segments. That way, there's no additional code needed on the clients, no extensions needed for DNS, and just some software on the boxes linking the different network segments. I could draft something along these lines, if there's interest. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From mike@mtcc.com Tue Feb 26 07:07:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F9A21F8880 for ; Tue, 26 Feb 2013 07:07:25 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsvE2RiEeYMm for ; Tue, 26 Feb 2013 07:07:25 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id F16ED21F887D for ; Tue, 26 Feb 2013 07:07:24 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1QF7N9u019525 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Feb 2013 07:07:24 -0800 Message-ID: <512CCFAB.60802@mtcc.com> Date: Tue, 26 Feb 2013 07:07:23 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Simon Kelley References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C69D2.9050105@thekelleys.org.uk> In-Reply-To: <512C69D2.9050105@thekelleys.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=933; t=1361891244; x=1362755244; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20NPTv6-only=20home=20network s |Sender:=20 |To:=20Simon=20Kelley=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=u4922hKjkoAqBPDP0awXtsJ/QWAkwYjGEpAQwERCTqU=; b=Ph4zaTo2rQwZpOOFrTnN9aEd8NrVHqzYIw8wNThhPEvaCMSoaPr6+5ALAL iS2NZKb0cyXqgMGqlRQriIKdwXV9miXcvB+KLbnXCkOFwiAnfgi3cVUsOCoQ CxqqCYpGv/4vNJveNUnTf88CcJ/VYTH0phlNY59FpEa0VavKPTxhI=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:07:26 -0000 On 02/25/2013 11:52 PM, Simon Kelley wrote: > >> If I got your problem statement right, I'd argue that there are, >> essentially, two problems here: >> 1) Learning the IPv6 addresses in use >> 2) Updating the DNS accordingly > > > Dnsmasq does both of these for internal DNS, it's just an extension of what it has always done in IPv4 land. There's a new test release that does the same for external DNS, by acting as the authoritative server for a zone, and/or providing zone transfer to other authoritative servers. I'm not understanding: what is the name that it associates with the address? A synthesized one like ISP's often do with forward map addresses in their dynamic pool? What I've been wondering is whether a "reverse mdns" might be handy in these kinds of situations. Ie, "here's an address, what do you want your name to be?" There at least you might get a name that is a little less opaque. Mike From john_brzozowski@cable.comcast.com Tue Feb 26 07:30:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44BA21F8640 for ; Tue, 26 Feb 2013 07:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.198 X-Spam-Level: X-Spam-Status: No, score=-102.198 tagged_above=-999 required=5 tests=[AWL=-1.301, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebDkjvJRe2ZF for ; Tue, 26 Feb 2013 07:30:57 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 041B321F863F for ; Tue, 26 Feb 2013 07:30:56 -0800 (PST) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.44628557; Tue, 26 Feb 2013 10:18:20 -0500 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 26 Feb 2013 10:30:48 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Tue, 26 Feb 2013 10:30:47 -0500 From: "Brzozowski, John" To: Fernando Gont , "homenet@ietf.org" Thread-Topic: [homenet] Naming and Service Discovery Thread-Index: AQHOFDK+UAtIt1/u90yVqk/MPdq/spiMRBWA Date: Tue, 26 Feb 2013 15:30:46 +0000 Message-ID: In-Reply-To: <512CCF34.9010705@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <4BDA0A49CBFFF14F96489C74F1852F54@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:30:57 -0000 So far the problem I have seen with authoritative DNS is one still needs to know what to ask for, the benefit of service discovery is what is available is being announced. Unless I missed something I do not beleive the latter has been part of the discussions specific to authoritative DNS. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozowski@cable.comcast.com o) 609-377-6594 w) www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Fernando Gont Date: Tuesday, February 26, 2013 7:05 AM To: "homenet@ietf.org" Subject: [homenet] Naming and Service Discovery >Folks, > >Just to kick some discussion: > >Regarding naming and service discovery, it seems that there are folks >that are in the camp of "let's make mDNS work on multiple segments", >while others seem to be in the camp of "this should be done with DNS". > >May I introduce a third option? mDNS for the local net, DNS to glue the >multiple segments. That way, there's no additional code needed on the >clients, no extensions needed for DNS, and just some software on the >boxes linking the different network segments. > >I could draft something along these lines, if there's interest. > >Thanks, >--=20 >Fernando Gont >SI6 Networks >e-mail: fgont@si6networks.com >PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From fgont@si6networks.com Tue Feb 26 07:41:56 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383E521F87E7 for ; Tue, 26 Feb 2013 07:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSwuBYwQBPI7 for ; Tue, 26 Feb 2013 07:41:55 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 90FBA21F8845 for ; Tue, 26 Feb 2013 07:41:55 -0800 (PST) Received: from [186.137.77.228] (helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UAMf9-000071-0L; Tue, 26 Feb 2013 16:41:51 +0100 Message-ID: <512CD7B9.90701@si6networks.com> Date: Tue, 26 Feb 2013 12:41:45 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Brzozowski, John" References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:41:56 -0000 On 02/26/2013 12:30 PM, Brzozowski, John wrote: > So far the problem I have seen with authoritative DNS is one still needs > to know what to ask for, the benefit of service discovery is what is > available is being announced. You could have some kind of magic name that identifies services, and has PTR records with host names in it. If that's not enough, you could have a magic "all current services" magic name, which would contain PTR records (or something similar to data) pointing to the previous records I mentioned. -- After all, you typically want the list of services/services when you want to do something (browse the net, play some music, etc.). That is, that of having to ask shouldn't be a problem -- and, actually, may probably scale easier/better than broadcasting stuff. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From C.Grundemann@cablelabs.com Tue Feb 26 07:46:04 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200FB21F8786 for ; Tue, 26 Feb 2013 07:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHL261w8cMb0 for ; Tue, 26 Feb 2013 07:46:03 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 99BA821F8767 for ; Tue, 26 Feb 2013 07:46:03 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r1QFk2SE002835 for ; Tue, 26 Feb 2013 08:46:02 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 26 Feb 2013 08:46:02 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0328.009; Tue, 26 Feb 2013 08:46:02 -0700 From: Chris Grundemann To: "homenet@ietf.org Group" Thread-Topic: New Version Notification for draft-grundemann-homenet-hipnet-01.txt Thread-Index: AQHOE632tguMrEFIo02b/Z+r0qz0MJiMSWYA Date: Tue, 26 Feb 2013 15:46:01 +0000 Message-ID: <43238C9F8B23DA44B42A78D0129283E017FC9051@EXCHANGE.cablelabs.com> In-Reply-To: <20130225231509.5387.62666.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Approved: ondar Subject: [homenet] FW: New Version Notification for draft-grundemann-homenet-hipnet-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:46:04 -0000 SGFpbCBIb21lbmV0LA0KDQpGWUkgLSBXZSBoYXZlIHVwZGF0ZWQgb3VyICJISVBuZXQiIGRyYWZ0 LiBUaGlzIC0wMSBpcyBhIG1pbm9yIHVwZGF0ZSwNCndoaWNoIGluY2x1ZGVzIGFsbW9zdCBleGNs dXNpdmVseSBlZGl0b3JpYWwgZml4ZXMuIFdlIGhhdmUgdGFrZW4gbm90ZSBvZg0KYWxsIGZlZWRi YWNrIHJlY2VpdmVkIHRodXMgZmFyLCBib3RoIG9uIGFuZCBvZmYgbGlzdCwgYW5kIHdpbGwgd29y ayB0bw0KaW5jb3Jwb3JhdGUgdGhhdCBmZWVkYmFjayBpbiBmdXJ0aGVyIHJldmlzaW9ucyBhcyBp dCBtYWtlcyBzZW5zZS4NCg0KVGhhbmtzLA0KfkNocmlzDQoNCg0KT24gMi8yNS8xMyA0OjE1IFBN LCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0K d3JvdGU6DQoNCj4NCj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZ3J1bmRlbWFubi1ob21l bmV0LWhpcG5ldC0wMS50eHQNCj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IENo cmlzIEdydW5kZW1hbm4gYW5kIHBvc3RlZCB0byB0aGUNCj5JRVRGIHJlcG9zaXRvcnkuDQo+DQo+ RmlsZW5hbWU6CSBkcmFmdC1ncnVuZGVtYW5uLWhvbWVuZXQtaGlwbmV0DQo+UmV2aXNpb246CSAw MQ0KPlRpdGxlOgkJIEEgTmVhciBUZXJtIFNvbHV0aW9uIGZvciBIb21lIElQIE5ldHdvcmtpbmcg KEhJUG5ldCkNCj5DcmVhdGlvbiBkYXRlOgkgMjAxMy0wMi0yNQ0KPkdyb3VwOgkJIEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KPk51bWJlciBvZiBwYWdlczogMjINCj5VUkw6ICAgICAgICAgICAgIA0K Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdydW5kZW1hbm4taG9t ZW5ldC1oaXBuZXQtMDEudHh0DQo+U3RhdHVzOiAgICAgICAgICANCj5odHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdydW5kZW1hbm4taG9tZW5ldC1oaXBuZXQNCj5IdG1saXpl ZDogICAgICAgIA0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdydW5kZW1hbm4t aG9tZW5ldC1oaXBuZXQtMDENCj5EaWZmOiAgICAgICAgICAgIA0KPmh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWdydW5kZW1hbm4taG9tZW5ldC1oaXBuZXQtMDENCj4NCj5B YnN0cmFjdDoNCj4gICBIb21lIG5ldHdvcmtzIGFyZSBiZWNvbWluZyBtb3JlIGNvbXBsZXguICBX aXRoIHRoZSBsYXVuY2ggb2YgbmV3DQo+ICAgc2VydmljZXMgc3VjaCBhcyBob21lIHNlY3VyaXR5 LCBJUCB2aWRlbywgU21hcnQgR3JpZCwgZXRjLiwgbWFueQ0KPiAgIFNlcnZpY2UgUHJvdmlkZXJz IGFyZSBwbGFjaW5nIGFkZGl0aW9uYWwgSVB2NC9JUHY2IHJvdXRlcnMgb24gdGhlDQo+ICAgc3Vi c2NyaWJlciBuZXR3b3JrLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzZWxmLWNvbmZpZ3Vy aW5nIGhvbWUNCj4gICByb3V0ZXIgdGhhdCBpcyBjYXBhYmxlIG9mIG9wZXJhdGluZyBpbiBzdWNo IGFuIGVudmlyb25tZW50LCBhbmQgdGhhdA0KPiAgIHJlcXVpcmVzIG5vIHVzZXIgaW50ZXJhY3Rp b24gdG8gY29uZmlndXJlIGl0LiAgQ29tcGxpYW50IHdpdGgNCj4gICBkcmFmdC1pZXRmLWhvbWVu ZXQtYXJjaCwgaXQgdXNlcyBleGlzdGluZyBwcm90b2NvbHMgaW4gbmV3IHdheXMNCj4gICB3aXRo b3V0IHRoZSBuZWVkIGZvciBhIHJvdXRpbmcgcHJvdG9jb2wuDQo+DQo+DQo+ICAgICAgICAgICAg ICAgICAgDQo+ICAgICAgICANCj4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KPg0KDQo= From mellon@fugue.com Tue Feb 26 08:24:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976AF21F886A for ; Tue, 26 Feb 2013 08:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trjb1SJoZGBo for ; Tue, 26 Feb 2013 08:24:23 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B864C21F87EA for ; Tue, 26 Feb 2013 08:24:23 -0800 (PST) Received: from [10.0.1.12] (user-387gmsm.cable.mindspring.com [208.120.91.150]) by toccata.fugue.com (Postfix) with ESMTPSA id 4EDB7238033D; Tue, 26 Feb 2013 11:24:19 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <512CC4FD.2020804@si6networks.com> Date: Tue, 26 Feb 2013 11:24:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8AB7DF5E-8CB6-44D7-A04F-757D9E1528D8@fugue.com> References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> <512CC4FD.2020804@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:24:25 -0000 On Feb 26, 2013, at 9:21 AM, Fernando Gont = wrote: > If we cannot do that, but can spec functionality in, say, home = routers, > then something along the lines of what I sketched in my previous email > might make more sense. I dont think it cuts that way. If we specify a system for doing this, = and it gets general support in home gateways, particularly if it's = supported by at least some operating systems, then we will probably see = more implementations follow the spec. So we should choose the solution = we want, not settle for something. I don't mean to suggest that what you've proposed isn't a good solution; = simply that we should prefer it because it's a better solution, if it = is, not because it's more likely to see widespread deployment. At this = stage in the life of IPv4, SunOS didn't even have a built-in DNS = resolver, and had determined that Yellow Pages was the way to do naming. = (NIS, for those of us still old enough to remember SunOS, but not old = enough to remember YP.) As for "not needing authoritative DNS in the homenet," I think we've = generally agreed that we at least need it so we can publish names = externally; the real question is how we arrange for that to happen. I = think if we need it at all, we might as well just use it, and not = develop a new protocol suite to do homenet naming. From mellon@fugue.com Tue Feb 26 08:26:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6196D21F888C for ; Tue, 26 Feb 2013 08:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xH73z4uK-+3 for ; Tue, 26 Feb 2013 08:26:43 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 31F9721F85DB for ; Tue, 26 Feb 2013 08:26:41 -0800 (PST) Received: from [10.0.1.12] (user-387gmsm.cable.mindspring.com [208.120.91.150]) by toccata.fugue.com (Postfix) with ESMTPSA id 584F4238033D; Tue, 26 Feb 2013 11:26:38 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <512CCB4C.5060507@mtcc.com> Date: Tue, 26 Feb 2013 11:26:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> <512CCB4C.5060507@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:26:45 -0000 On Feb 26, 2013, at 9:48 AM, Michael Thomas wrote: > What I've been rolling through my head is a host being able to claim a > a name in a namespace when it attaches to a network provable by = possession > of an asymmetric key it generates. The host could update that name = binding > at any time (eg, change the AAAA) just by signing the update with that = key. > The DNS could age those name bindings to get rid of transient names = (eg, > phones that come and go on your homenet). Yup. > The "trust model" here is the ability to get onto my homenet at all, I = think. > That is, I have the password to an SSID. Maybe different SSID's have = different > DNS subdomains like XXX.guest.myhomedomain.org. I think you could just say that the guest domain isn't published = externally. > How this lines up with other work, or whether it meets the myriad of = other > requirements, I do not know. But it at least seems plausible to me for = a > littleconf kind of deployment like a homenet. Yes. The complexity comes in if we support multihoming, which is part = of homenet's scope. It seems obvious that the edge router should be = the authoritative name server, but what if there are two edge routers? From mellon@fugue.com Tue Feb 26 08:29:58 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02D621F8846 for ; Tue, 26 Feb 2013 08:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1omeU5MqThyX for ; Tue, 26 Feb 2013 08:29:58 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 43E6D21F8749 for ; Tue, 26 Feb 2013 08:29:58 -0800 (PST) Received: from [10.0.1.12] (user-387gmsm.cable.mindspring.com [208.120.91.150]) by toccata.fugue.com (Postfix) with ESMTPSA id 6C3A0238033D; Tue, 26 Feb 2013 11:29:57 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <512CCF34.9010705@si6networks.com> Date: Tue, 26 Feb 2013 11:29:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <512CCF34.9010705@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org" Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:29:59 -0000 On Feb 26, 2013, at 10:05 AM, Fernando Gont = wrote: > May I introduce a third option? mDNS for the local net, DNS to glue = the > multiple segments. That way, there's no additional code needed on the > clients, no extensions needed for DNS, and just some software on the > boxes linking the different network segments. I think that's what the mdns guys are talking about doing. I think = it's a bad idea. It doesn't solve the multihoming problem; it's hard = to figure out what problem it _does_ solve that can't be solved better = using existing technology. From mike@mtcc.com Tue Feb 26 08:43:22 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDE721F8702 for ; Tue, 26 Feb 2013 08:43: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0op84BTp56vy for ; Tue, 26 Feb 2013 08:43:21 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 226A621F8758 for ; Tue, 26 Feb 2013 08:43:19 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1QGhH5d020545 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Feb 2013 08:43:17 -0800 Message-ID: <512CE625.2010303@mtcc.com> Date: Tue, 26 Feb 2013 08:43:17 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ted Lemon References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> <512CCB4C.5060507@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1210; t=1361896998; x=1362760998; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20NPTv6-only=20home=20network s |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=cwDsV1ncHNwnTvRagAm4n9H93xbbdYFT7G6RZKUA04c=; b=gGJB/URAR3rD+Gj+mU7h61zf2m2OWhqrggITW5FUflCutfXcBO78IBJyPg 0tt0VDVu+r0706Q7YmdEUubvgEPDL0q+77Pvbs9M4dEna4rDo0cD0o1TOxom dQjDyoeD91RyaTZaT8P7+Ah+Qrb1iAh2nyTN7Q5G9lXG7gvdSKT1w=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:43:22 -0000 On 02/26/2013 08:26 AM, Ted Lemon wrote: > >> How this lines up with other work, or whether it meets the myriad of other >> requirements, I do not know. But it at least seems plausible to me for a >> littleconf kind of deployment like a homenet. > Yes. The complexity comes in if we support multihoming, which is part of homenet's scope. It seems obvious that the edge router should be the authoritative name server, but what if there are two edge routers? > I think we should probably steer clear of "convenient place to host the repository" from its actual routing function. That is, I don't think that it really matters whether it's an edge router or not even though it's a likely place to put that functionality since it's always on, etc, etc. Maybe what we really want is to replicate the name database onto *all* capable devices and then elect an authoritative one? Ideally, I should be able to toss one of my routers into the trash and install another one and not have naming die until I configure something again. Not sure how you'd deal with the glue records to do that though... i doubt you'd want to be changing that in the root zones. Maybe a clever use of anycast? Mike From mike@mtcc.com Tue Feb 26 08:55:22 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDA021F87EA for ; Tue, 26 Feb 2013 08:55: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJvhMpGEx0kS for ; Tue, 26 Feb 2013 08:55:22 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id B145021F89E1 for ; Tue, 26 Feb 2013 08:55:17 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1QGtFIa024721 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Feb 2013 08:55:16 -0800 Message-ID: <512CE8F3.4070303@mtcc.com> Date: Tue, 26 Feb 2013 08:55:15 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ted Lemon References: <512CCF34.9010705@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=912; t=1361897716; x=1362761716; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Naming=20and=20Service=20Di scovery |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=dSb6QytAfHTV+tjmUFs/bcSaqH5THPkjf4eQ9xnuuDg=; b=sMiuRDcydDjszLxhM8CXYHjkO7F3by9TBoLuYmUxuyNsGvQ8OafupiYZo0 9QEDVgVj3eGXPFYPrA3apCNBRwChVgdKmpEQIM3I2QudjeteV+mZQBVd1CwX 3Ccl6COQdM8kx/Ol4mGLPJISpAZyFzo3Hz0MA7rqfppYzKVoqfRGg=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Fernando Gont , "homenet@ietf.org" Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:55:22 -0000 On 02/26/2013 08:29 AM, Ted Lemon wrote: > On Feb 26, 2013, at 10:05 AM, Fernando Gont wrote: >> May I introduce a third option? mDNS for the local net, DNS to glue the >> multiple segments. That way, there's no additional code needed on the >> clients, no extensions needed for DNS, and just some software on the >> boxes linking the different network segments. > I think that's what the mdns guys are talking about doing. I think it's a bad idea. It doesn't solve the multihoming problem; it's hard to figure out what problem it _does_ solve that can't be solved better using existing technology. > Anything that keeps with the absurdity of "refrigerator.local" being ambiguous because I'm halfway between mine and my neighbor's house connecting back and forth on our wifi's is a bad situation. We should stop the care and feeding that bad solution right now. Mike From fgont@si6networks.com Tue Feb 26 08:56:17 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6C721F89E1 for ; Tue, 26 Feb 2013 08:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5DIna10ZSVW for ; Tue, 26 Feb 2013 08:56:14 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6E32F21F87CC for ; Tue, 26 Feb 2013 08:55:54 -0800 (PST) Received: from [186.137.77.228] (helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UANok-0001yj-G4; Tue, 26 Feb 2013 17:55:50 +0100 Message-ID: <512CE911.6070003@si6networks.com> Date: Tue, 26 Feb 2013 13:55:45 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ted Lemon References: <512CCF34.9010705@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 16:56:17 -0000 On 02/26/2013 01:29 PM, Ted Lemon wrote: > >> May I introduce a third option? mDNS for the local net, DNS to glue >> the multiple segments. That way, there's no additional code needed >> on the clients, no extensions needed for DNS, and just some >> software on the boxes linking the different network segments. > > I think that's what the mdns guys are talking about doing. My understanding was that they were going to extend mDNS to work on multiple segments, rather than gluing mDNS "islands" with DNS... but I have not really followed the discussions in the mdnsext. > I think > it's a bad idea. It doesn't solve the multihoming problem; it's > hard to figure out what problem it _does_ solve that can't be solved > better using existing technology. Is there a requirements list for what naming/service discovery should achive? i.e., are those requirements documented? -- because that would be step #1 here. (yes, there are general requirements in the homenet charter, but was wondering if something had been written for naming and service discovery). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Tue Feb 26 09:09:36 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CA621F8845 for ; Tue, 26 Feb 2013 09:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.934 X-Spam-Level: X-Spam-Status: No, score=-100.934 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdtl5ZiZCKDN for ; Tue, 26 Feb 2013 09:09:36 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 125A921F86FA for ; Tue, 26 Feb 2013 09:09:35 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hn17so5170467wib.16 for ; Tue, 26 Feb 2013 09:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Lp21E+++25YfMaKA/FXBgDX3jXJ3Vu+G4yvHABsX4zM=; b=pjIetVAl2pEQ7hs8JPANOJ4idYrSsJXa16VacLWjhvFVuSjdSPiRN/HhBWgNiliwie xfk+ymA8EIV1n3s6KwIoY1e8yuIiEhYebeZRK007u3Z3F5lUqhN3+rci/uvyckUo3K5s e3PbEwJf+Tx3+3iSWFzI0fG1lyYp0M3WLkRReYUFiaSGhQX/jvIM1vw9IRYiNX85KyEv nFKzUW3kw3R2Nq2kYM6e1SmJsU+O8qehfPa18hjfyTTVTfD4M8LuD/rVjuyEKgPHFn3k +GlXRIniF4nJ9/I1S3u2adywXxIAVF2aSwGLrYrkq2R96Z6PQ4U030ZVAecvmjmHx08w zwtA== X-Received: by 10.180.83.137 with SMTP id q9mr20863176wiy.4.1361898575180; Tue, 26 Feb 2013 09:09:35 -0800 (PST) Received: from [192.168.1.65] (host-2-101-189-195.as13285.net. [2.101.189.195]) by mx.google.com with ESMTPS id fg6sm3188233wib.10.2013.02.26.09.09.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 09:09:33 -0800 (PST) Message-ID: <512CEC52.1060508@gmail.com> Date: Tue, 26 Feb 2013 17:09:38 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Thomas References: <512CCF34.9010705@si6networks.com> <512CE8F3.4070303@mtcc.com> In-Reply-To: <512CE8F3.4070303@mtcc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "homenet@ietf.org" , Ted Lemon Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 17:09:36 -0000 On 26/02/2013 16:55, Michael Thomas wrote: > On 02/26/2013 08:29 AM, Ted Lemon wrote: >> On Feb 26, 2013, at 10:05 AM, Fernando Gont >> wrote: >>> May I introduce a third option? mDNS for the local net, DNS to glue the >>> multiple segments. That way, there's no additional code needed on the >>> clients, no extensions needed for DNS, and just some software on the >>> boxes linking the different network segments. >> I think that's what the mdns guys are talking about doing. I think >> it's a bad idea. It doesn't solve the multihoming problem; it's hard >> to figure out what problem it _does_ solve that can't be solved better >> using existing technology. >> > > Anything that keeps with the absurdity of "refrigerator.local" being > ambiguous because I'm halfway between mine and my neighbor's > house connecting back and forth on our wifi's is a bad situation. We > should stop the care and feeding that bad solution right now. Yes. It beats me why we don't just do a gap analysis for making real DNS work in the home. Brian From v6ops@globis.net Tue Feb 26 09:16:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C7921F8A08 for ; Tue, 26 Feb 2013 09:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBVc7PzhdGx6 for ; Tue, 26 Feb 2013 09:16:25 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 13B0021F8A04 for ; Tue, 26 Feb 2013 09:16:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6D01C8700E2; Tue, 26 Feb 2013 18:11:08 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+rHQ1taZzPL; Tue, 26 Feb 2013 18:10:39 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 71D9B87005F; Tue, 26 Feb 2013 18:10:39 +0100 (CET) Message-ID: <512CEC89.6030706@globis.net> Date: Tue, 26 Feb 2013 18:10:33 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Ted Lemon References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> <512CCB4C.5060507@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , Michael Thomas Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 17:16:26 -0000 Ted Lemon wrote: > On Feb 26, 2013, at 9:48 AM, Michael Thomas wrote: >> What I've been rolling through my head is a host being able to claim a >> a name in a namespace when it attaches to a network provable by possession >> of an asymmetric key it generates. The host could update that name binding >> at any time (eg, change the AAAA) just by signing the update with that key. >> The DNS could age those name bindings to get rid of transient names (eg, >> phones that come and go on your homenet). > > Yup. Yes. >> The "trust model" here is the ability to get onto my homenet at all, I think. >> That is, I have the password to an SSID. Maybe different SSID's have different >> DNS subdomains like XXX.guest.myhomedomain.org. > > I think you could just say that the guest domain isn't published externally. Yes. >> How this lines up with other work, or whether it meets the myriad of other >> requirements, I do not know. But it at least seems plausible to me for a >> littleconf kind of deployment like a homenet. > > Yes. The complexity comes in if we support multihoming, which is part of homenet's scope. It seems obvious that the edge router should be the authoritative name server Agreed, for on-homenet resolution (to keep service when one Internet connection is down). > , but what if there are two edge routers? > Elect one to be authoritative: which needs a new protocol, plus some really complex take-over mechanism on failure. Or just update all CER's independently. Plus any off-homenet hosted personal domain if you're fortunate enough have one. Why not? What's fundamentally wrong with having n AAAA records for the same machine name resolved in n different zones in n authoritative DNS servers? From john_brzozowski@cable.comcast.com Tue Feb 26 09:22:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E9521F8857 for ; Tue, 26 Feb 2013 09:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.333 X-Spam-Level: X-Spam-Status: No, score=-104.333 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV8XfLNsQ886 for ; Tue, 26 Feb 2013 09:22:48 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 237C521F8883 for ; Tue, 26 Feb 2013 09:22:48 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.58114640; Tue, 26 Feb 2013 09:52:11 -0700 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 26 Feb 2013 12:22:42 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Tue, 26 Feb 2013 12:22:42 -0500 From: "Brzozowski, John" To: Fernando Gont , Ted Lemon Thread-Topic: [homenet] Naming and Service Discovery Thread-Index: AQHOFD6CUAtIt1/u90yVqk/MPdq/spiMr5GA//+zsQA= Date: Tue, 26 Feb 2013 17:22:41 +0000 Message-ID: In-Reply-To: <512CE911.6070003@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 17:22:57 -0000 -----Original Message----- From: Fernando Gont Date: Tuesday, February 26, 2013 8:55 AM To: Ted Lemon Cc: "homenet@ietf.org" Subject: Re: [homenet] Naming and Service Discovery >On 02/26/2013 01:29 PM, Ted Lemon wrote: >> >>> May I introduce a third option? mDNS for the local net, DNS to glue >>> the multiple segments. That way, there's no additional code needed >>> on the clients, no extensions needed for DNS, and just some >>> software on the boxes linking the different network segments. >>=20 >> I think that's what the mdns guys are talking about doing. > >My understanding was that they were going to extend mDNS to work on >multiple segments, rather than gluing mDNS "islands" with DNS... but I >have not really followed the discussions in the mdnsext. [jjmb] I thought this was one of the goals as well. > > >> I think >> it's a bad idea. It doesn't solve the multihoming problem; it's >> hard to figure out what problem it _does_ solve that can't be solved >> better using existing technology. > >Is there a requirements list for what naming/service discovery should >achive? i.e., are those requirements documented? -- because that would >be step #1 here. (yes, there are general requirements in the homenet >charter, but was wondering if something had been written for naming and >service discovery). [jjmb] there may be words, hard to say of if they are accurate. I confess I have not read them closely lately. > >Thanks, >--=20 >Fernando Gont >SI6 Networks >e-mail: fgont@si6networks.com >PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From john_brzozowski@cable.comcast.com Tue Feb 26 09:27:58 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189A621F89DA for ; Tue, 26 Feb 2013 09:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.355 X-Spam-Level: X-Spam-Status: No, score=-104.355 tagged_above=-999 required=5 tests=[AWL=0.876, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-jxT4+Pg5AL for ; Tue, 26 Feb 2013 09:27:57 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id DC8C721F89D2 for ; Tue, 26 Feb 2013 09:27:52 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.58116095; Tue, 26 Feb 2013 09:57:17 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Tue, 26 Feb 2013 12:27:47 -0500 From: "Brzozowski, John" To: Ted Lemon , Fernando Gont Thread-Topic: [homenet] NPTv6-only home networks Thread-Index: AQHOFD20eJqgpe0N7kSCQ5ntBRDfFpiMZK+A Date: Tue, 26 Feb 2013 17:27:46 +0000 Message-ID: In-Reply-To: <8AB7DF5E-8CB6-44D7-A04F-757D9E1528D8@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: <162BC6136D75A54A9F980F72A3E7DA63@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 17:27:58 -0000 -----Original Message----- From: Ted Lemon Date: Tuesday, February 26, 2013 8:24 AM To: Fernando Gont Cc: "homenet@ietf.org Group" Subject: Re: [homenet] NPTv6-only home networks >On Feb 26, 2013, at 9:21 AM, Fernando Gont wrote: >> If we cannot do that, but can spec functionality in, say, home routers, >> then something along the lines of what I sketched in my previous email >> might make more sense. > >I dont think it cuts that way. If we specify a system for doing this, >and it gets general support in home gateways, particularly if it's >supported by at least some operating systems, then we will probably see >more implementations follow the spec. So we should choose the solution >we want, not settle for something. [jjmb] the train will depart regardless, now would be a good time to ensure we have focused achievable goals and requirements. > >I don't mean to suggest that what you've proposed isn't a good solution; >simply that we should prefer it because it's a better solution, if it is, >not because it's more likely to see widespread deployment. At this >stage in the life of IPv4, SunOS didn't even have a built-in DNS >resolver, and had determined that Yellow Pages was the way to do naming. > (NIS, for those of us still old enough to remember SunOS, but not old >enough to remember YP.) [jjmb] we also need to consider that we may not arrive at something that works for everyone. > >As for "not needing authoritative DNS in the homenet," I think we've >generally agreed that we at least need it so we can publish names >externally; the real question is how we arrange for that to happen. I >think if we need it at all, we might as well just use it, and not develop >a new protocol suite to do homenet naming. [jjmb] I thought there was some other working going on where this data could be extracted from the CPE router? > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From simon@thekelleys.org.uk Tue Feb 26 10:15:37 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C9F21F88BC for ; Tue, 26 Feb 2013 10:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YaOU8WIwbG6 for ; Tue, 26 Feb 2013 10:15:37 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id D74EF21F8889 for ; Tue, 26 Feb 2013 10:15:36 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:38569 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UAP3u-0003f0-Ce for homenet@ietf.org; Tue, 26 Feb 2013 18:15:34 +0000 Received: from archie.thekelleys.org.uk ([192.168.1.167]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1UAP3t-0004MO-Ob for homenet@ietf.org; Tue, 26 Feb 2013 18:15:33 +0000 Message-ID: <512CFBCE.4020800@thekelleys.org.uk> Date: Tue, 26 Feb 2013 18:15:42 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C69D2.9050105@thekelleys.org.uk> <512CCFAB.60802@mtcc.com> In-Reply-To: <512CCFAB.60802@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:15:37 -0000 On 26/02/13 15:07, Michael Thomas wrote: > On 02/25/2013 11:52 PM, Simon Kelley wrote: >> >>> If I got your problem statement right, I'd argue that there are, >>> essentially, two problems here: >>> 1) Learning the IPv6 addresses in use >>> 2) Updating the DNS accordingly >> >> >> Dnsmasq does both of these for internal DNS, it's just an extension of >> what it has always done in IPv4 land. There's a new test release that >> does the same for external DNS, by acting as the authoritative server >> for a zone, and/or providing zone transfer to other authoritative >> servers. > > I'm not understanding: what is the name that it associates with the > address? > A synthesized one like ISP's often do with forward map addresses in their > dynamic pool? Either the name that the host provides in a DHCP hostname or FQDN option, or a name associated with the host in the dnsmasq configuration. Most DHCP clients provide the hostname in their DHCP requests these days. Dnsmasq configuration allows associating a name with a MAC address or client-id. Simon. From mike@mtcc.com Tue Feb 26 10:21:56 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5F421F88A6 for ; Tue, 26 Feb 2013 10:21: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXIkwPSYvT9J for ; Tue, 26 Feb 2013 10:21:56 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 977E621F8869 for ; Tue, 26 Feb 2013 10:21:55 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1QILsT1022890 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Feb 2013 10:21:55 -0800 Message-ID: <512CFD42.2010209@mtcc.com> Date: Tue, 26 Feb 2013 10:21:54 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Simon Kelley References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C69D2.9050105@thekelleys.org.uk> <512CCFAB.60802@mtcc.com> <512CFBCE.4020800@thekelleys.org.uk> In-Reply-To: <512CFBCE.4020800@thekelleys.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1281; t=1361902915; x=1362766915; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20NPTv6-only=20home=20network s |Sender:=20 |To:=20Simon=20Kelley=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=n+iG0H/J7YgFlqnAH6hCOoaP/Af3DvNPTbfFaDnW7jc=; b=orky5POvR+qUwVqRhbBpsJ9EjSrHyE1fABktiTLaNCOQts7f2Gf+wFOT9a d+srQKI/SFyaJC7iHBvDi7HkHcYs3OZiSPJ6p4slt+bLg9N5j+czlQi4SyKa +RsDVpcSAZE1XBjZcTQviGR65fQiCbieCPDoh4tLjkvermKNNZqZs=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:21:56 -0000 On 02/26/2013 10:15 AM, Simon Kelley wrote: > On 26/02/13 15:07, Michael Thomas wrote: >> On 02/25/2013 11:52 PM, Simon Kelley wrote: >>> >>>> If I got your problem statement right, I'd argue that there are, >>>> essentially, two problems here: >>>> 1) Learning the IPv6 addresses in use >>>> 2) Updating the DNS accordingly >>> >>> >>> Dnsmasq does both of these for internal DNS, it's just an extension of >>> what it has always done in IPv4 land. There's a new test release that >>> does the same for external DNS, by acting as the authoritative server >>> for a zone, and/or providing zone transfer to other authoritative >>> servers. >> >> I'm not understanding: what is the name that it associates with the >> address? >> A synthesized one like ISP's often do with forward map addresses in their >> dynamic pool? > > Either the name that the host provides in a DHCP hostname or FQDN option, or a name associated with the host in the dnsmasq configuration. Most DHCP clients provide the hostname in their DHCP requests these days. Dnsmasq configuration allows associating a name with a MAC address or client-id. Ah, ok. But that wouldn't work in a SLAAC environment unless it did a DHCP INFORM, right? Hosts don't do that generally, right? Mike From mellon@fugue.com Tue Feb 26 10:30:27 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1B321F882E for ; Tue, 26 Feb 2013 10:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CWqkOXe-ZAj for ; Tue, 26 Feb 2013 10:30:22 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B8F2121F8765 for ; Tue, 26 Feb 2013 10:30:22 -0800 (PST) Received: from [10.0.1.12] (user-387gmsm.cable.mindspring.com [208.120.91.150]) by toccata.fugue.com (Postfix) with ESMTPSA id 4AC112380907; Tue, 26 Feb 2013 13:30:21 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <512CE625.2010303@mtcc.com> Date: Tue, 26 Feb 2013 13:30:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9C2F9A35-94B0-424D-9FF8-E9AC944A4BBE@fugue.com> References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> <512CCB4C.5060507@mtcc.com> <512CE625.2010303@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:30:28 -0000 On Feb 26, 2013, at 11:43 AM, Michael Thomas wrote: > I think we should probably steer clear of "convenient place to host = the repository" > from its actual routing function. That is, I don't think that it = really matters whether it's an edge router or not even though it's a = likely place to put that functionality since it's always on, etc, etc. = Maybe what we really want is to replicate the name database onto *all* = capable devices and then elect an authoritative one? Ideally, I should = be able to toss one of my routers into the trash and install another one = and not have naming die until I configure something again. The reason I suggest using the edge device is that it's easy for a = device to tell that it's the edge device, and you don't want to have a = bazillion different devices doing it because it's hairy and complicated, = and almost certainly won't be gotten right in a lot of implementations. = There is a value to following expedience here, and not trying to be = overly clever. What you're describing is basically mDNS, except mDNS = doesn't use elections=97it just uses assertions. If that's the right = answer, then we don't need to talk about a DNS primary in the homenet at = all. But you do bring up a good point, which is that keeping this database = alive across physical reconfiguration events is worthwhile. But maybe = you want to primary the zone at your ISP or some other external service, = and secondary it on your edge devices. > Not sure how you'd deal with the glue records to do that though... i = doubt you'd > want to be changing that in the root zones. Maybe a clever use of = anycast? The glue records for the PTR zone need to be at your ISP, so that's = really easy. The glue records for the AAAA zone need to be updatable = and the TTL quite short (there won't be many queries, so this is ok). = Either way, if you have a publicly visible forward zone it's going to be = either a name server you set up on a server off your homenet, or it's = going to be on a name server you're buying service from (like = dyndns.org), or you have some kind of promise from your ISP that they = won't renumber you without notice, and your domain is in a registry. = Or maybe the primary is on your homenet, but isn't one of the published = nameservers for the zone, and the ones that are published are off-net at = your ISP or at someplace like dyndns.org. From fred@cisco.com Tue Feb 26 10:30:45 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22EF21F8921 for ; Tue, 26 Feb 2013 10:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.412 X-Spam-Level: X-Spam-Status: No, score=-110.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Yol8QqPiVpq for ; Tue, 26 Feb 2013 10:30:45 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E2EA721F891D for ; Tue, 26 Feb 2013 10:30:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1906; q=dns/txt; s=iport; t=1361903445; x=1363113045; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RvIKy1yUY5vFvlOlEYYNxFcF5WJqdGBLehPj3ZOQenA=; b=V07JTZGzpl2pbPYtkQuA5uLZKnLSc84LZNebozS0/kWPtql5Ck7dGxov sCyRJ874sbX97hohGpP2zNRQuSH2kWFhNpaM66cXWViyQ2LdsQaGiFq9b 3XpcAPUPv4XFyUzux0NWgpHLSTF5rmFGP76VEWk74aq97gDqrs6G30iMl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPf+LFGtJV2a/2dsb2JhbABFwWh/FnOCHwEBAQMBOj8FCQICAQgiFBAbFyUCBA4FCIgFBgyvc5ACBASNSYEUAjEHgl9hA6cogwiBaT4 X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="181417684" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 26 Feb 2013 18:30:44 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1QIUi5Q009360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Feb 2013 18:30:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 12:30:44 -0600 From: "Fred Baker (fred)" To: Mark Andrews Thread-Topic: [homenet] automatic prefix management (OSPF or ISIS version) Thread-Index: AQHOFE9jEmAeLD6tz0Wx/6IsdeQQ1w== Date: Tue, 26 Feb 2013 18:30:44 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7AD9BF@xmb-rcd-x09.cisco.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> <20130226025631.5CAD9301035F@drugs.dv.isc.org> In-Reply-To: <20130226025631.5CAD9301035F@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:30:45 -0000 On Feb 25, 2013, at 6:56 PM, Mark Andrews wrote: >=20 > In message <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com>, james woodya= tt wri > tes: >> p3. All this pain can be traded away for the reasonably well-understood = pain=20 >> of NAT66 and a single ULA prefix with a constant 16-bit subnet identifie= r spa >> ce, where collisions will be rare and stateless prefix autoconfiguration= will >> settle quickly basically every time. I personally don't think that's a = good >> trade, but if routed home networks are ever to become the normal setup, = then >> I'm very skeptical that my opinion will turn out to be the majority one. >=20 > NAT66 assumes a /48 or else you don't have enough bits to fix the checksu= ms. You really need to re-read the document. https://tools.ietf.org/html/rfc629= 6 First, the term "NAT66" refers to stateful Network *Address* Translation, w= hich doesn't update checksums in the prefix at all - it is what we have don= e in IPv4/IPv4 NAT but done in IPv6/IPv6 junction points, which means repla= cing the address entirely. If you're talking about stateless prefix transla= tion, which can update the checksum in the prefix, it's Network Prefix Tran= slation, NPT66.=20 The reason we changed the name was that we couldn't get people to distingui= sh between those two notions; one blocks traffic while the other does not, = and there are other ramifications. We obviously still have not succeeded. NPT66 is not limited to /48s. It can update the checksum in the EID if the = prefix is longer. And then there's ILNP, which doesn't update the checksum in the translator = because it changed the end to end checksum algorithm (the definition of the= pseudo-header). > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mellon@fugue.com Tue Feb 26 10:32:51 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6D121F891D for ; Tue, 26 Feb 2013 10:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSSN5PCk29Xh for ; Tue, 26 Feb 2013 10:32:51 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6944721F88EF for ; Tue, 26 Feb 2013 10:32:50 -0800 (PST) Received: from [10.0.1.12] (user-387gmsm.cable.mindspring.com [208.120.91.150]) by toccata.fugue.com (Postfix) with ESMTPSA id B91112380907; Tue, 26 Feb 2013 13:32:49 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <512CE911.6070003@si6networks.com> Date: Tue, 26 Feb 2013 13:32:48 -0500 Content-Transfer-Encoding: 7bit Message-Id: <09DCCC42-9789-4809-B92F-282559DCBF1B@fugue.com> References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org" Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:32:51 -0000 On Feb 26, 2013, at 11:55 AM, Fernando Gont wrote: > Is there a requirements list for what naming/service discovery should > achive? http://tools.ietf.org/html/draft-ietf-homenet-arch-07#section-3.7 From simon@thekelleys.org.uk Tue Feb 26 10:33:19 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04E421F8734 for ; Tue, 26 Feb 2013 10:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 502acxUg3waO for ; Tue, 26 Feb 2013 10:33:19 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id 9060F21F86B3 for ; Tue, 26 Feb 2013 10:33:10 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:38606 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UAPKv-0003kK-Us for homenet@ietf.org; Tue, 26 Feb 2013 18:33:10 +0000 Received: from archie.thekelleys.org.uk ([192.168.1.167]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1UAPKv-0004tr-5I for homenet@ietf.org; Tue, 26 Feb 2013 18:33:09 +0000 Message-ID: <512CFFE8.5020201@thekelleys.org.uk> Date: Tue, 26 Feb 2013 18:33:12 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C69D2.9050105@thekelleys.org.uk> <512CCFAB.60802@mtcc.com> <512CFBCE.4020800@thekelleys.org.uk> <512CFD42.2010209@mtcc.com> In-Reply-To: <512CFD42.2010209@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 18:33:19 -0000 On 26/02/13 18:21, Michael Thomas wrote: > On 02/26/2013 10:15 AM, Simon Kelley wrote: >> On 26/02/13 15:07, Michael Thomas wrote: >>> On 02/25/2013 11:52 PM, Simon Kelley wrote: >>>> >>>>> If I got your problem statement right, I'd argue that there are, >>>>> essentially, two problems here: >>>>> 1) Learning the IPv6 addresses in use >>>>> 2) Updating the DNS accordingly >>>> >>>> >>>> Dnsmasq does both of these for internal DNS, it's just an extension of >>>> what it has always done in IPv4 land. There's a new test release that >>>> does the same for external DNS, by acting as the authoritative server >>>> for a zone, and/or providing zone transfer to other authoritative >>>> servers. >>> >>> I'm not understanding: what is the name that it associates with the >>> address? >>> A synthesized one like ISP's often do with forward map addresses in >>> their >>> dynamic pool? >> >> Either the name that the host provides in a DHCP hostname or FQDN >> option, or a name associated with the host in the dnsmasq >> configuration. Most DHCP clients provide the hostname in their DHCP >> requests these days. Dnsmasq configuration allows associating a name >> with a MAC address or client-id. > > Ah, ok. But that wouldn't work in a SLAAC environment unless it did a DHCP > INFORM, right? Hosts don't do that generally, right? It works in a SLAAC environment where the host _also_ does DHCPv4, which is where we came in....... Simon. From mike@mtcc.com Tue Feb 26 11:28:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610A721F8890 for ; Tue, 26 Feb 2013 11:28:04 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ncJQk7umGi4 for ; Tue, 26 Feb 2013 11:28:03 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id CB8FB21F8887 for ; Tue, 26 Feb 2013 11:28:01 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1QHRNcX003660 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Feb 2013 09:27:23 -0800 Message-ID: <512CF07B.6020105@mtcc.com> Date: Tue, 26 Feb 2013 09:27:23 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ray Hunter References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> <512CCB4C.5060507@mtcc.com> <512CEC89.6030706@globis.net> In-Reply-To: <512CEC89.6030706@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=421; t=1361899644; x=1362763644; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20NPTv6-only=20home=20network s |Sender:=20 |To:=20Ray=20Hunter=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=nNiUBez+RrKwdomCN/fZFpX63TjLjo1J55zheS5vsZw=; b=GUMZSKcBMf54/eAx8qf9tFcSFtkqabP6m9L0XldfFUuU8woYKLapa76x/O SV2LJY4+I445WxGVhjTjk9hwfZ1N4mznyMulVtvI9FNg12M3KEztZhoGJevM d7abPZkMa676lByec0HVKwEsV6wr+tOl4Q7B9ZdDBzxhbdQPI+GdU=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 19:28:05 -0000 X-List-Received-Date: Tue, 26 Feb 2013 19:28:05 -0000 On 02/26/2013 09:10 AM, Ray Hunter wrote: > > , but what if there are two edge routers? > > Elect one to be authoritative: which needs a new protocol, plus some > really complex take-over mechanism on failure. Pardon my ignorance, but how does this happen in real life, and in particular with anycast? Aren't all of the anycast reachable servers authoritative as far as the outside world is concerned? Mike From jhw@apple.com Tue Feb 26 11:28:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691FA21F8884 for ; Tue, 26 Feb 2013 11:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.696 X-Spam-Level: X-Spam-Status: No, score=-104.696 tagged_above=-999 required=5 tests=[AWL=5.904, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1eQzvJR-UXs for ; Tue, 26 Feb 2013 11:28:04 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4211021F8889 for ; Tue, 26 Feb 2013 11:28:04 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MIU0028DE2IGRG0@mail-out.apple.com> for homenet@ietf.org; Tue, 26 Feb 2013 11:27:54 -0800 (PST) X-AuditID: 11807153-b7f8a6d0000064e7-7a-512d0cbaa307 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 0D.20.25831.ABC0D215; Tue, 26 Feb 2013 11:27:54 -0800 (PST) Received: from kallisti.apple.com ([17.193.13.64]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MIU00L9EE2IE320@aniseed.apple.com> for homenet@ietf.org; Tue, 26 Feb 2013 11:27:54 -0800 (PST) From: james woodyatt In-reply-to: Date: Tue, 26 Feb 2013 11:27:54 -0800 Message-id: References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> To: "homenet@ietf.org" X-Mailer: Apple Mail (2.1682) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUi2FAsrruLRzfQYPF5M4v3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoErY8nL2awFC7kqTj3Zw9rA2MPRxcjJISFgItHycjY7hC0mceHe erYuRi4OIYF+JomWLStZIJxZTBJ3W64xg1QxC+hI9H7/BmbzCuhJzFy5hBXEFhbwlDjcvJYN xGYTUJH4dvkuE4jNKRAsse73FLAaFgFViZfnvjFCzNGWePLuAlCcA2iOjcSul/oQu/4wSyxu msgCUiMioClxafZRJojrZCU+XGljn8DIPwvJGbOQnDELydgFjMyrGAWKUnMSK431EgsKclL1 kvNzNzGCQ6wweAfjn2VWhxgFOBiVeHgXXNIJFGJNLCuuzD3EKMHBrCTC+/EAUIg3JbGyKrUo P76oNCe1+BCjNAeLkjhvym+glEB6YklqdmpqQWoRTJaJg1OqgTHCfe2BK9OdTZ59SZbgKHR4 tUTyqbOdlEnujdzGgh+up18evdN9TTf/nrbHnd35m5uMj5X1WtxqVVbgCObvavyT82ZK8rFj +zZ4hswKZZstsuCh2SuurwvvHDv48VTytlXhr6fNavqdEHVhb/qHkLQak5cCat6tDzfVqk2c bl+6vyEw9W/oyVQlluKMREMt5qLiRADvXCBvLQIAAA== Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 19:28:06 -0000 On Feb 25, 2013, at 19:35 , Lorenzo Colitti wrote: > > However, the moment you try to use more /64s internally than you have externally, stateless NPTv6 doesn't work any more, right? Correct. But remember: I *never* write NAT66 when what I mean is NPTv6. I really did mean NAT66 and not NPTv6. In this scenario, we would number HOMENET domains with 16 bits of ULA subnet identifier and 64 bits of interface identifier for hosts on each subnet. Then we would NAT66 the ULA /48 prefix into whatever addresses are in the pool of longer prefixes the service provider gives us because they won't give us a /48 at an acceptable price. We would not use NPTv6, as that doesn't work. We would then use the PCP protocol to control NAT66 mappings just the same as we do today with NAT44 mappings, but the good news is that PCP explicitly supports that form of IPv6/NAT so it's all good. Thank you PCP working group. Yes, this breaks referral in IPv6 even more than it's already broken, but I'm thinking service providers will be happy with that overall. If I were building an IPv6 home gateway to support routed home networks today, this is how I would feel compelled to do it. -- james woodyatt core os networking From mcr@sandelman.ca Tue Feb 26 11:37:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9937821F86CD for ; Tue, 26 Feb 2013 11:37:00 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj41BxGXX-QD for ; Tue, 26 Feb 2013 11:36:54 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF6821F86C1 for ; Tue, 26 Feb 2013 11:36:54 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AED1320168; Tue, 26 Feb 2013 14:44:02 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 4E09763A5C; Tue, 26 Feb 2013 14:35:44 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3BE2563769; Tue, 26 Feb 2013 14:35:44 -0500 (EST) From: Michael Richardson To: Fernando Gont In-Reply-To: <512CCF34.9010705@si6networks.com> References: <512CCF34.9010705@si6networks.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "homenet@ietf.org" Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 19:37:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Fernando" =3D=3D Fernando Gont writes: Fernando> Regarding naming and service discovery, it seems that Fernando> there are folks that are in the camp of "let's make mDNS Fernando> work on multiple segments", while others seem to be in the Fernando> camp of "this should be done with DNS". Fernando> May I introduce a third option? mDNS for the local net, Fernando> DNS to glue the multiple segments. That way, there's no Fernando> additional code needed on the clients, no extensions Fernando> needed for DNS, and just some software on the boxes Fernando> linking the different network segments. You are saying that we would reduce the problem of getting something like dynamic DNS update working on every printer and TV appliance, into the problem of getting dynamic DNS working on at least one router that listens on every subnet on which mDNS is enabled. I think that this would please the campus people well, as it would give them the control that I think that they need, while not risking flooding mDNS in places unseen. I think that this will also please the router and switch vendors, because on many campuses (campii?) LANs are defined by VLAN-type technology, and having more smarts in switches sells more switches :-) I think that this will please the home user because mostly nothing changes.=20 I think that this will please homenet because we have already much discussion about the desire for stable forward DNS names, and the need for ISPs to delegate things, and this works very well into that architecture. It might also please the IESG, because it makes mdnsext likely unnecessary: your proposed document is a BCP, no new protocols required. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUS0OkIqHRg3pndX9AQKRpwQApHPW41sVG30mLgrOWVv6Of0TvLKgIJyl 7r4FtkGxqsi0coi51kwft8yu+eEof4VYwvYTTEUjQN9VK/6TJ6eA8oFFo1qbz1/e jo93ztbbWgGJGrx9FB1OlN00TT7dx5DmApT38iPV5rBM3FnTfvi1vKZay9Hgi+62 alubApVpPUI= =xXPy -----END PGP SIGNATURE----- --=-=-=-- From mellon@fugue.com Tue Feb 26 11:47:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B8921F8883 for ; Tue, 26 Feb 2013 11:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1HCrWg4SX3x for ; Tue, 26 Feb 2013 11:47:03 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6E00321F8942 for ; Tue, 26 Feb 2013 11:47:03 -0800 (PST) Received: from [10.0.1.12] (user-387gmsm.cable.mindspring.com [208.120.91.150]) by toccata.fugue.com (Postfix) with ESMTPSA id E96682380907; Tue, 26 Feb 2013 14:47:00 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <27626.1361907344@sandelman.ca> Date: Tue, 26 Feb 2013 14:46:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <070E0E14-538D-42DF-8B5F-B149122A5C1F@fugue.com> References: <512CCF34.9010705@si6networks.com> <27626.1361907344@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1499) Cc: Fernando Gont , "homenet@ietf.org" Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 19:47:06 -0000 On Feb 26, 2013, at 2:35 PM, Michael Richardson = wrote: > Fernando> May I introduce a third option? mDNS for the local net, > Fernando> DNS to glue the multiple segments. That way, there's no > Fernando> additional code needed on the clients, no extensions > Fernando> needed for DNS, and just some software on the boxes > Fernando> linking the different network segments. >=20 > You are saying that we would reduce the problem of getting something > like dynamic DNS update working on every printer and TV appliance, = into > the problem of getting dynamic DNS working on at least one router that > listens on every subnet on which mDNS is enabled. Ah, I read this wrong. This does actually make a certain amount of = sense. Beware though that it is not as simple a problem as you might = first imagine, because mDNS deals poorly with name clashes, and name = clashes when switching subnets are par for the course, because the name = in the old location persists for longer than the time it takes to switch = networks. From ot@cisco.com Tue Feb 26 12:16:19 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC6621F88C8 for ; Tue, 26 Feb 2013 12:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.467 X-Spam-Level: X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2E9Pm2humk1 for ; Tue, 26 Feb 2013 12:16:17 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id E047921F87D2 for ; Tue, 26 Feb 2013 12:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=290; q=dns/txt; s=iport; t=1361909777; x=1363119377; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=7yUTi9WbaJMVCliEPv9T7A7ZrFQlyoFwlMQq8oqHv7E=; b=kCaaq8qqN60fjwLiSPVKYikaZNpipnOiQTArAmEFV4DPaXqpsb5hTYZh 3YxvnwpSNU3IoTAbH306CdTjiX7BCzw6YU+P50Z0shjY86j1DREurmQ/+ us8pkzDcTwNtpFv1TTrKhL2CRB4nemNq46x8nGnN7e1OVkxPdg5WP1YQP I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUFAMgWLVGQ/khR/2dsb2JhbABFhgi7bX8Wc4IfAQEBAwE6PwULCw44VwaIIAYMsAWQEI8UB4JfYQOWQIEej0qDCQ X-IronPort-AV: E=Sophos;i="4.84,742,1355097600"; d="scan'208";a="12075132" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 26 Feb 2013 20:16:15 +0000 Received: from dhcp-10-61-96-64.cisco.com (dhcp-10-61-96-64.cisco.com [10.61.96.64]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1QKGFOb000781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Feb 2013 20:16:15 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <512CE911.6070003@si6networks.com> Date: Tue, 26 Feb 2013 21:16:15 +0100 Content-Transfer-Encoding: 7bit Message-Id: <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org" , Ted Lemon Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:16:19 -0000 > My understanding was that they were going to extend mDNS to work on > multiple segments, rather than gluing mDNS "islands" with DNS... but I > have not really followed the discussions in the mdnsext. see: http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01 cheers, Ole From v6ops@globis.net Tue Feb 26 12:30:11 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32A521F8700 for ; Tue, 26 Feb 2013 12:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD5tNIuc8y1X for ; Tue, 26 Feb 2013 12:30:11 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id EF43621F860A for ; Tue, 26 Feb 2013 12:30:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 820E2870124; Tue, 26 Feb 2013 21:24:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSEuG+pCE2pm; Tue, 26 Feb 2013 21:24:25 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 8B5DE870123; Tue, 26 Feb 2013 21:24:25 +0100 (CET) Message-ID: <512D19F3.8030407@globis.net> Date: Tue, 26 Feb 2013 21:24:19 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Michael Thomas References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> <512CCB4C.5060507@mtcc.com> <512CEC89.6030706@globis.net> <512CF07B.6020105@mtcc.com> In-Reply-To: <512CF07B.6020105@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:30:11 -0000 Michael Thomas wrote: > On 02/26/2013 09:10 AM, Ray Hunter wrote: >> >> , but what if there are two edge routers? >> >> Elect one to be authoritative: which needs a new protocol, plus some >> really complex take-over mechanism on failure. > > Pardon my ignorance, but how does this happen in real life, and in > particular with anycast? Aren't all of the anycast reachable servers > authoritative as far as the outside world is concerned? > > Mike > As far as I can see, there are no existing off-the-shelf solutions available that cover all homenet naming requirements. Therefore to answer your question: it doesn't happen in real life today. We're talking theoretical auto-config of DNS servers by some process. Which would be new and require some sort of election protocol to see which CER would become "the anointed one." That server would then have to work out which zone(s) to serve, given multiple parent ISPs. Also if it failed we'd have to start all over again. Hence the alternative suggestion that all CERs could always become authoritative DNS servers, each providing a zone delegated from their respective parent ISP (or other DNS name service provider). We'd probably then either have to suggest the end nodes update all the servers present in the homenet actively with name->AAAA information via registration every time they moved. Or perhaps more practically, get the host to update a random CER somehow, and then work out some way of mirroring the latest info between zones in the background between the CERs, without needing a static master-slave relationship. That'd probably also require some new stuff. But I'd still rather look at the gap analysis to make DNS work (with new autoconfig/mirroring stuff), than try to proxy mDNS over multiple subnets in an arbitrary topology (messy), or extend mDNS to be multi-subnet aware (completely new, and reliant on site-wide multicast), or extend a stateless protocol like mDNS to update DNS for off-homenet resolution. From cb.list6@gmail.com Tue Feb 26 13:33:51 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB8321F85A4 for ; Tue, 26 Feb 2013 13:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yU3Gz7GgGu0 for ; Tue, 26 Feb 2013 13:33:51 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 88F5121F85BD for ; Tue, 26 Feb 2013 13:33:50 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id z53so3882279wey.15 for ; Tue, 26 Feb 2013 13:33:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/rGgouOMhNtMyVT6C2yGKKz4gNl5q7f+H5BzZA2IjsM=; b=MFd254va1LtyI00Erc7i7ooP+gaYneT55HEcV9d/MnbthMjR7LHHgp5FD7qVtNB37x Fo14fpbjZj6e/kVb9hMZk55FCYI48C15J5YzXYk436044FmsZVtwfTWe98rqIBRl1XUo YM7sKsszBPK9SylfeVPfm0UqZyl0D/9c+GF098JekqBZgDVhbrX4uGhJWwOEm3t+2Jpr NrlaaB1R29D6G7MuQVu3Ox6FWbEFv3YcQ6USOw+TSW4TzyQXjLAY7dGNZGEo4X54jrTw vx6y4YfX+S3QWhSkvsvqu8EHpXEAZQLVcHe4diPHZ45l6zCKqwY1hDKF3vjL0r2JfO5m anEA== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr12714435wjc.35.1361914429605; Tue, 26 Feb 2013 13:33:49 -0800 (PST) Received: by 10.194.20.35 with HTTP; Tue, 26 Feb 2013 13:33:49 -0800 (PST) Received: by 10.194.20.35 with HTTP; Tue, 26 Feb 2013 13:33:49 -0800 (PST) In-Reply-To: <5322F4D7-8A16-4821-A63E-29DFBC556614@cisco.com> References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> <48F0F7E1-B0C1-455F-A0EA-FD82BAD2EF7A@fugue.com> <5322F4D7-8A16-4821-A63E-29DFBC556614@cisco.com> Date: Tue, 26 Feb 2013 13:33:49 -0800 Message-ID: From: Cameron Byrne To: Ole Troan Content-Type: multipart/alternative; boundary=089e013d1da8ca905704d6a769b0 Cc: "homenet@ietf.org" , Ted Lemon , james woodyatt , lorenzo@google.com Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 21:33:51 -0000 --089e013d1da8ca905704d6a769b0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sent from ipv6-only Android On Feb 26, 2013 8:19 PM, "Ole Troan" wrote: > > >> Ok. I see it in the charter. I dont find it particularly appealing or worth a great trade off for the level of complexity involved. Especially if the tradeoffs require nat66 or something similarly complex > > > > Touch=E9. > > > > Seriously, though, the point of routing in the home is that you really don't want to bridge disparate media, and you want routers plugged together by people who don't know about routing to create a happy, functioning network, not a dysfunctional network that sort of works but is never satisfactory. > > exactly. > > the arguments I've heard are: > - people just plug in whatever they bought, it must work regardless of being a router or a bridge How does routing make this better for a homenet ? Ethernet supports arbitrary topologies. > - not all link-layers can be bridged together e.g. 802.15.4 Whos requirement is that? Is it a primary use case or can be a stub L3 link > - problems with bridging links with very different speed characteristics e.g. 802.11 and 1G wired Routing is better? > - isolation between networks with different policy, e.g. guest networks, internal home automation, public wifi > Seems like homenet is trying to devine the special sauce that makes Frankenstein come alive. Warning ... my home network includes exactly 1 802.11g AP that cost $50 6 years ago and effectively is Zero configuration. CB > cheers, > Ole > --089e013d1da8ca905704d6a769b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Feb 26, 2013 8:19 PM, "Ole Troan" <ot@cisco.com> wrote:
>
> >> Ok. I see it in the charter. I dont find it particularly appe= aling or worth a great trade off for the level of complexity involved. Espe= cially if the tradeoffs require nat66 or something similarly complex
> >
> > Touch=E9.
> >
> > Seriously, though, the point of routing in the home is that you r= eally don't want to bridge disparate media, and you want routers plugge= d together by people who don't know about routing to create a happy, fu= nctioning network, not a dysfunctional network that sort of works but is ne= ver satisfactory.
>
> exactly.
>
> the arguments I've heard are:
> =A0- people just plug in whatever they bought, it must work regardless= of being a router or a bridge

How does routing make this better for a homenet ? Ethernet= =A0 supports arbitrary topologies.

> =A0- not all link-layers can be bridged together e.g. 8= 02.15.4

Whos requirement is that? Is it a primary use case or can be= a stub L3 link

> =A0- problems with bridging links with very different s= peed characteristics e.g. 802.11 and 1G wired

Routing is better?

> =A0- isolation between networks with different policy, = e.g. guest networks, internal home automation, public wifi
>

Seems like homenet is trying to devine the special sauce tha= t makes Frankenstein come alive.

Warning ... my home network includes exactly 1 802.11g AP th= at cost $50 6 years ago and effectively is Zero configuration.

CB

> cheers,
> Ole
>

--089e013d1da8ca905704d6a769b0-- From marka@isc.org Tue Feb 26 14:36:38 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAEB21F86EA for ; Tue, 26 Feb 2013 14:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, J_CHICKENPOX_29=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WU-Jbx0NTkc for ; Tue, 26 Feb 2013 14:36:37 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 0380F21F8780 for ; Tue, 26 Feb 2013 14:36:37 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 240A05F985D; Tue, 26 Feb 2013 22:36:16 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361918190; bh=GO7Rbh6nhA62q3A4RsHOLTbAJFZYHxyZHp8BoI07LxQ=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=No+qddchGdFvvqv3MbQsQ9Ff6RmvPulKTNFETDQE287k0rAF4bTTbptirIIBkUK1D 7+l5MHtIYWgF+73cv0vO7iM21pmvrGlPfLBkpgvM0hyvlhXHCDC+dU3kvxpd9ziM0V 3UHkbiZZpxS0fgLnGVsOnc0Mxg6TE7nHjLuxMOW4= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:f5b5:34f:65a7:a779]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DAC26216C3B; Tue, 26 Feb 2013 22:36:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 40B74301ABF7; Wed, 27 Feb 2013 09:36:12 +1100 (EST) To: Fernando Gont From: Mark Andrews References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> <512CC4FD.2020804@si6networks.com> In-reply-to: Your message of "Tue, 26 Feb 2013 11:21:49 -0300." <512CC4FD.2020804@si6networks.com> Date: Wed, 27 Feb 2013 09:36:12 +1100 Message-Id: <20130226223612.40B74301ABF7@drugs.dv.isc.org> Cc: "BrzoBecausezowski, John" , Michael Richardson , Michael Thomas , Mark Townsley , Dave Taht , Jari Arkko , Ted Lemon , "homenet@ietf.org Group" , Lorenzo Colitti , David Lamparter Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 22:36:38 -0000 In message <512CC4FD.2020804@si6networks.com>, Fernando Gont writes: > On 02/26/2013 09:19 AM, Ted Lemon wrote: > > Homenets aren't zeroconf--there has to be a way, at a minimum, to > > communicate a prefix and a DNS server address. This can be done > > with RA, or with RA+stateless DHCPv6, or with stateful DHCPv6. So > > in a homenet we can expect that there _will_ be a mechanism that > > _could_ be made to work for setting up DNS; the questions are: > > > > (1) Which ways do we support, if any? > > Stupid question: > Can we enforce requirements on host implementations as a result of > homenet? (e.g., among all the nice pieces of DDNS, how many of them are > widely implemented? and if not widely implemented, can we push changes > in this area?) Windows and MacOS both support DDNS. You have to turn the latter on. Thats well over half of homenet boxes. > If we cannot do that, but can spec functionality in, say, home routers, > then something along the lines of what I sketched in my previous email > might make more sense. > > > > (2) How do we resolve the question of who is the local DNS server? > > You mean the authoritative DNS server for nodes in the local network? You make a SOA query for the name you want to add. You remove labels until you get a SOA response (there are optimisations that can be applied to make this quicker). You lookup the NS RRset now that you have the containing zone. If the master server (see the SOA record) is in the NS RRset you send to it otherwise you try all the NS's until you get SUCCESS or REFUSED. If you get NOTIMP you move onto the next server. When you have exhausted all the servers you stop. NOTIMP indicates that update / update forwarding is not supported/enabled. REFUSED means you hit a acl. SUCCESS means you update was accepted. This is bog standard update processing. It works with split namespaces. If you are updating PTR records you look for CNAME records with the initial SOA query in case RFC 2317 delegations are present and you update the owner name of the PTR to match the target of the CNAME. You then restart the process. > > As far as I can tell, this whole notion has been punted in favor of > > multi-subnet mDNS; my concern is that we are going to wind up with a > > new protocol that's a weird amalgam of mDNS and DNS but shares little > > code with existing implementations of either protocol/ > > Since I was not involved in such discussions, just double-checking: I > guess the whole argument for DNS had to do with > * No need for authoritative servers? > * Availability of "local" zones, as opposed to global zones? > * Something (technical :-) ) else? > > I think that it shouldn't be hard to come up with something to make DNS > work with local zones, without relying on multicast (and thus avoiding > the need to do mDNS). If there's interest in exploring this path, I > could give this some thought -- just checking the mDNS thing is not > casted into stone, such that I avoid wasting time unnecessarily... > > Thanks! > > Best regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Tue Feb 26 14:45:38 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5EB21F86C5 for ; Tue, 26 Feb 2013 14:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-FgndINDoqo for ; Tue, 26 Feb 2013 14:45:37 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id EA06421F84DC for ; Tue, 26 Feb 2013 14:45:36 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 4BE765F9919; Tue, 26 Feb 2013 22:45:15 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361918725; bh=SxcWGuX3ZZKjMIIJC0QBb6nYflWqga4YY+7m5qKJbTY=; h=Cc:From:References:Subject:In-reply-to:Date; b=iQtnI/idK8wO8GnH6J5xnLItF27xJHHsWyU788lebM86tLy0QrSy1Oh6cizk27wA1 buv+BC8/4EKrZNOS2tuBAI3HvqHkABXXrHXlDT2PQ8Mh57Vd3nN8QWzewOWoP3tikA igtCrSlqIqc3WilaqVM2BkZydh6yENZjkdb/BKQs= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 80E53216C3B; Tue, 26 Feb 2013 22:45:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 583FB301ACD0; Wed, 27 Feb 2013 09:45:11 +1100 (EST) From: Mark Andrews References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> <512CC4FD.2020804@si6networks.com> <20130226223612.40B74301ABF7@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 27 Feb 2013 09:36:12 +1100." <20130226223612.40B74301ABF7@drugs.dv.isc.org> Date: Wed, 27 Feb 2013 09:45:11 +1100 Message-Id: <20130226224511.583FB301ACD0@drugs.dv.isc.org> Cc: Ted Lemon , Michael Richardson , Michael Thomas , Mark Townsley , Dave Taht , Jari Arkko , "BrzoBecausezowski, John" , Fernando Gont , "homenet@ietf.org Group" , David Lamparter , Lorenzo Colitti Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 22:45:38 -0000 In message <20130226223612.40B74301ABF7@drugs.dv.isc.org>, Mark Andrews writes: > > In message <512CC4FD.2020804@si6networks.com>, Fernando Gont writes: > > On 02/26/2013 09:19 AM, Ted Lemon wrote: > > > Homenets aren't zeroconf--there has to be a way, at a minimum, to > > > communicate a prefix and a DNS server address. This can be done > > > with RA, or with RA+stateless DHCPv6, or with stateful DHCPv6. So > > > in a homenet we can expect that there _will_ be a mechanism that > > > _could_ be made to work for setting up DNS; the questions are: > > > > > > (1) Which ways do we support, if any? > > > > Stupid question: > > Can we enforce requirements on host implementations as a result of > > homenet? (e.g., among all the nice pieces of DDNS, how many of them are > > widely implemented? and if not widely implemented, can we push changes > > in this area?) > > Windows and MacOS both support DDNS. You have to turn the latter on. > Thats well over half of homenet boxes. > > > If we cannot do that, but can spec functionality in, say, home routers, > > then something along the lines of what I sketched in my previous email > > might make more sense. > > > > > > > (2) How do we resolve the question of who is the local DNS server? > > > > You mean the authoritative DNS server for nodes in the local network? > > You make a SOA query for the name you want to add. You remove > labels until you get a SOA response (there are optimisations that > can be applied to make this quicker). You lookup the NS RRset now > that you have the containing zone. If the master server (see the > SOA record) is in the NS RRset you send to it otherwise you try all > the NS's until you get SUCCESS or REFUSED. If you get NOTIMP you > move onto the next server. When you have exhausted all the servers > you stop. > > NOTIMP indicates that update / update forwarding is not supported/enabled. > REFUSED means you hit a acl. > SUCCESS means you update was accepted. > > This is bog standard update processing. It works with split namespaces. Code to do the above has been part of libresolv/libbind since 1997. nsupdate calls that code to do its work. > If you are updating PTR records you look for CNAME records with the > initial SOA query in case RFC 2317 delegations are present and you > update the owner name of the PTR to match the target of the CNAME. > You then restart the process. > > > > As far as I can tell, this whole notion has been punted in favor of > > > multi-subnet mDNS; my concern is that we are going to wind up with a > > > new protocol that's a weird amalgam of mDNS and DNS but shares little > > > code with existing implementations of either protocol/ > > > > Since I was not involved in such discussions, just double-checking: I > > guess the whole argument for DNS had to do with > > * No need for authoritative servers? > > * Availability of "local" zones, as opposed to global zones? > > * Something (technical :-) ) else? > > > > I think that it shouldn't be hard to come up with something to make DNS > > work with local zones, without relying on multicast (and thus avoiding > > the need to do mDNS). If there's interest in exploring this path, I > > could give this some thought -- just checking the mDNS thing is not > > casted into stone, such that I avoid wasting time unnecessarily... > > > > Thanks! > > > > Best regards, > > -- > > Fernando Gont > > e-mail: fernando@gont.com.ar || fgont@si6networks.com > > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > > > > > -- > > Fernando Gont > > SI6 Networks > > e-mail: fgont@si6networks.com > > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > > > > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mellon@fugue.com Tue Feb 26 16:08:39 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1606921F85A2 for ; Tue, 26 Feb 2013 16:08:39 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+g9-qEoGr8X for ; Tue, 26 Feb 2013 16:08:38 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A92D721F859C for ; Tue, 26 Feb 2013 16:08:38 -0800 (PST) Received: from [192.168.1.2] (121.sub-70-192-71.myvzw.com [70.192.71.121]) by toccata.fugue.com (Postfix) with ESMTPSA id 07BAD2380907; Tue, 26 Feb 2013 19:08:25 -0500 (EST) References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <8CE251F5-CA78-44F1-9C60-B50734758CA7@fugue.com> X-Mailer: iPad Mail (10B146) From: Ted Lemon Date: Tue, 26 Feb 2013 19:08:23 -0500 To: Ole Troan Cc: Fernando Gont , "homenet@ietf.org" Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 00:08:39 -0000 On Feb 26, 2013, at 3:16 PM, Ole Troan wrote: > see: > http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01 Wow, that's all IPR'd up... From mellon@fugue.com Tue Feb 26 16:20:46 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C2421F862B for ; Tue, 26 Feb 2013 16:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5yLAh0-aahP for ; Tue, 26 Feb 2013 16:20:42 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5103421F862A for ; Tue, 26 Feb 2013 16:20:42 -0800 (PST) Received: from [192.168.1.2] (121.sub-70-192-71.myvzw.com [70.192.71.121]) by toccata.fugue.com (Postfix) with ESMTPSA id 21F262380907; Tue, 26 Feb 2013 19:20:38 -0500 (EST) References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> <48F0F7E1-B0C1-455F-A0EA-FD82BAD2EF7A@fugue.com> <5322F4D7-8A16-4821-A63E-29DFBC556614@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-64927995-661D-4EC7-AAD5-69666BC47631 Content-Transfer-Encoding: 7bit Message-Id: <7ACAA66E-4F7F-41E9-86ED-58D9CB06C0A0@fugue.com> X-Mailer: iPad Mail (10B146) From: Ted Lemon Date: Tue, 26 Feb 2013 19:20:37 -0500 To: Cameron Byrne Cc: Ole Troan , "homenet@ietf.org" , james woodyatt , "lorenzo@google.com" Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 00:20:48 -0000 --Apple-Mail-64927995-661D-4EC7-AAD5-69666BC47631 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Feb 26, 2013, at 4:33 PM, Cameron Byrne wrote: > Routing is better? >=20 Yes. > Warning ... my home network includes exactly 1 802.11g AP that cost $50 6 y= ears ago and effectively is Zero configuration. >=20 You think it's zeroconf, but it's using DHCP on both ends. It's not zeroco= nf, but it doesn't require configuration by you. That is what we are tryin= g to achieve here. You aren't the only person who is skeptical, but the ir= ony is that various people have demonstrated working models of key functiona= lity, so the skepticism seems misplaced.= --Apple-Mail-64927995-661D-4EC7-AAD5-69666BC47631 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On Feb 26, 2013, at 4:33 PM, Cameron Byrne <cb.list6@gmail.com> wrote:

Routing is better?

Yes.

Warning ... my home network includes exactly 1 802.11g AP that cost $50 6 years ago and effectively is Zero configuration.

You think it's zeroconf, but it's using DHCP on both ends.   It's not zeroconf, but it doesn't require configuration by you.   That is what we are trying to achieve here.   You aren't the only person who is skeptical, but the irony is that various people have demonstrated working models of key functionality, so the skepticism seems misplaced.
--Apple-Mail-64927995-661D-4EC7-AAD5-69666BC47631-- From marka@isc.org Tue Feb 26 16:34:06 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511AC21F8552 for ; Tue, 26 Feb 2013 16:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijUHr9SCs7Oy for ; Tue, 26 Feb 2013 16:34:05 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id B730121F8600 for ; Tue, 26 Feb 2013 16:33:59 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 565C45F9943; Wed, 27 Feb 2013 00:33:48 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1361925238; bh=nG2K7sQS0ImoRKy1Ij6jqQe0tiDhO7Szv0+3Zu23NcY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Zyn2pqjfuKV0coFhOLnJtIRWAWGzx/rfHNcbalEBvfjQPfSAuUECu2XNKT2uAAIhq 0BXt4oRwHYLGUoVlRJrfsMjwipua8qu2Zf+9PFOJgZ6MN4usbNuBQ1x9sqNRt8AGad jlMqxJzTzKU3WG2emjhHYjIvjo1UKNo/Rbl7ffKY= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:f5b5:34f:65a7:a779]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id AE949216C3B; Wed, 27 Feb 2013 00:33:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D938A301BC80; Wed, 27 Feb 2013 11:33:42 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <5126E021.6020103@mtcc.com> <81675C1D-FFA8-452D-B8BD-147533074F13@fugue.com> <51278850.5080102@mtcc.com> <7C9831DB-E0DC-43E1-AEDC-BA2DA1D8A6A4@fugue.com> <512C589E.9040104@si6networks.com> <512C938C.4080702@gmail.com> <512C96CF.5090906@si6networks.com> <512CC4FD.2020804@si6networks.com> <8AB7DF5E-8CB6-44D7-A04F-757D9E1528D8@fugue.com> In-reply-to: Your message of "Tue, 26 Feb 2013 11:24:10 CDT." <8AB7DF5E-8CB6-44D7-A04F-757D9E1528D8@fugue.com> Date: Wed, 27 Feb 2013 11:33:42 +1100 Message-Id: <20130227003342.D938A301BC80@drugs.dv.isc.org> Cc: Fernando Gont , "homenet@ietf.org Group" Subject: Re: [homenet] NPTv6-only home networks X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 00:34:06 -0000 In message <8AB7DF5E-8CB6-44D7-A04F-757D9E1528D8@fugue.com>, Ted Lemon writes: > On Feb 26, 2013, at 9:21 AM, Fernando Gont wrote: > > If we cannot do that, but can spec functionality in, say, home routers, > > then something along the lines of what I sketched in my previous email > > might make more sense. > > I dont think it cuts that way. If we specify a system for doing this, and i > t gets general support in home gateways, particularly if it's supported by at > least some operating systems, then we will probably see more implementations > follow the spec. So we should choose the solution we want, not settle for > something. > > I don't mean to suggest that what you've proposed isn't a good solution; simp > ly that we should prefer it because it's a better solution, if it is, not bec > ause it's more likely to see widespread deployment. At this stage in the li > fe of IPv4, SunOS didn't even have a built-in DNS resolver, and had determine > d that Yellow Pages was the way to do naming. (NIS, for those of us still o > ld enough to remember SunOS, but not old enough to remember YP.) SunOS always has a DNS resolver. It was the BIND 4.8 code. Whether hostname lookups where configured to use it or not was another matter. > As for "not needing authoritative DNS in the homenet," I think we've generall > y agreed that we at least need it so we can publish names externally; the rea > l question is how we arrange for that to happen. I think if we need it at a > ll, we might as well just use it, and not develop a new protocol suite to do > homenet naming. > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mcr@sandelman.ca Tue Feb 26 20:53:14 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928ED21F8514 for ; Tue, 26 Feb 2013 20:53:14 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YMXzBf3tWx2 for ; Tue, 26 Feb 2013 20:53:13 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 552C621F84A9 for ; Tue, 26 Feb 2013 20:53:13 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 029AE20168 for ; Wed, 27 Feb 2013 00:00:22 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 3D95863A5C; Tue, 26 Feb 2013 23:52:01 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2E90963A5B for ; Tue, 26 Feb 2013 23:52:01 -0500 (EST) From: Michael Richardson To: "homenet@ietf.org" In-Reply-To: References: <11123.1361496693@sandelman.ca> <23737.1361542581@sandelman.ca> <396B8B22-1169-44E6-A342-C56DC9B03585@apple.com> <8C48B86A895913448548E6D15DA7553B7A0975@xmb-rcd-x09.cisco.com> <129D9591-DC6E-473D-912F-587BC3383DAA@apple.com> <1D1732D1-AC03-450A-ADD2-611F2FB1C7D9@apple.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 04:53:14 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "james" =3D=3D james woodyatt writes: james> Correct. But remember: I *never* write NAT66 when what I mean james> is NPTv6. I really did mean NAT66 and not NPTv6. james> In this scenario, we would number HOMENET domains with 16 james> bits of ULA subnet identifier and 64 bits of interface james> identifier for hosts on each subnet. Then we would NAT66 the james> ULA /48 prefix into whatever addresses are in the pool of james> longer prefixes the service provider gives us because they james> won't give us a /48 at an acceptable price. We would not use james> NPTv6, as that doesn't work. If we must assume that the ISPs will be dorks, then I'd rather just stick to triple-NAT'ed IPv4, and then the clueful people will get a tunnel to sixxs or some place clueful. I seem to recall that this is what we did with the ISDN, X.25 and the rest of the incumbent carrier controlled protocols we had in the 1980s: we used them as pipes for something decent. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUS2Q8YqHRg3pndX9AQLhmAP+Ku65TNygkPfcE81Tsrs8/u0TPpSYFzjn 5GBPq1PEUsLnX80tMVGCWYC7SPCruUM1uCTS/8SDFJtivIUXCMcDgiln3ce85dDM amwe33Fn9L7a5F20iBMDHdUV8ht1H8AipOI28oZU4fODDWJqVPOBgy7jgemP3EaR fHJFjU7u1/I= =XT+O -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Feb 26 20:54:47 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5477F21F86EB for ; Tue, 26 Feb 2013 20:54:47 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DWJRvcRo3Sd for ; Tue, 26 Feb 2013 20:54:46 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 4646B21F84D3 for ; Tue, 26 Feb 2013 20:54:46 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8EAD320168 for ; Wed, 27 Feb 2013 00:01:55 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id A36ED63A5C; Tue, 26 Feb 2013 23:53:35 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 91F8B63A5B for ; Tue, 26 Feb 2013 23:53:35 -0500 (EST) From: Michael Richardson To: "homenet@ietf.org" In-Reply-To: <070E0E14-538D-42DF-8B5F-B149122A5C1F@fugue.com> References: <512CCF34.9010705@si6networks.com> <27626.1361907344@sandelman.ca> <070E0E14-538D-42DF-8B5F-B149122A5C1F@fugue.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 04:54:47 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ted" =3D=3D Ted Lemon writes: Fernando> May I introduce a third option? mDNS for the local net, Fernando> DNS to glue the multiple segments. That way, there's no Fernando> additional code needed on the clients, no extensions Fernando> needed for DNS, and just some software on the boxes Fernando> linking the different network segments. >> You are saying that we would reduce the problem of getting >> something like dynamic DNS update working on every printer and TV >> appliance, into the problem of getting dynamic DNS working on at >> least one router that listens on every subnet on which mDNS is >> enabled. Ted> Ah, I read this wrong. This does actually make a certain Ted> amount of sense. Beware though that it is not as simple a Ted> problem as you might first imagine, because mDNS deals poorly Ted> with name clashes, and name clashes when switching subnets are Ted> par for the course, because the name in the old location Ted> persists for longer than the time it takes to switch networks. So, my take on this is that you mean, mdnsext might actually have some work= to do. - improve name clashes due to subnet switching. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUS2RT4qHRg3pndX9AQIyogQAzcj41MtKvOd+5nfm8oqp2m9jMqu/ddt1 YWOpcYfmnKi8l3KhMWYzUHVheT1jsopM8vXy16P5E63whTuqK8K/KQCGt+1a8IVb E7kOtqzRz4EpRD4FTO43gz7WBoGqFIwG+ijYt2TKybXdxBjE306bPGBoj5dTkpsM QgFTMfTAaRc= =IrfN -----END PGP SIGNATURE----- --=-=-=-- From v6ops@globis.net Tue Feb 26 23:40:53 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A66421F868B for ; Tue, 26 Feb 2013 23:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0zeDvwh9Jv1 for ; Tue, 26 Feb 2013 23:40:52 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 53B0D21F8615 for ; Tue, 26 Feb 2013 23:40:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9E47D87005F; Wed, 27 Feb 2013 08:35:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9XK4JMRH2cq; Wed, 27 Feb 2013 08:35:15 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 3A0CE870049; Wed, 27 Feb 2013 08:35:15 +0100 (CET) Message-ID: <512DB72D.5000302@globis.net> Date: Wed, 27 Feb 2013 08:35:09 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Ole Troan References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> In-Reply-To: <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "homenet@ietf.org" , Ted Lemon Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 07:40:53 -0000 Ole Troan wrote: >> My understanding was that they were going to extend mDNS to work on >> multiple segments, rather than gluing mDNS "islands" with DNS... but I >> have not really followed the discussions in the mdnsext. > > see: > http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01 > > cheers, > Ole > > >From the quoted draft: "for the purposes of this document, assume that each link has its own unique Unicast DNS domain name", which I don't think is acceptable in Homenet. I don't want my phone's name to change when I walk out to the shed. From ot@cisco.com Tue Feb 26 23:51:27 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC06821F8706 for ; Tue, 26 Feb 2013 23:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJU-Q8TI9yHc for ; Tue, 26 Feb 2013 23:51:27 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9032321F8589 for ; Tue, 26 Feb 2013 23:51:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=858; q=dns/txt; s=iport; t=1361951486; x=1363161086; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=MXd1ybu9IpxBTUjONZM6lHrzeH3xa6q0QslhoMB1ZtU=; b=SSTtnaZDxLomyrhmlwN00FFdfSFbwS4OYgOAXAgADZzpCz/B9go7YBAj 7UjBE3/U8njVIwGzC5S0jtuh5o5NdLjy/X9ESLQYJEpYLptQ9V3JPRok5 kunJXxnOKabcjT/IIzk4Z+K+spn8aGt89yk7qbzsLf59jkrF5DMvDPZuE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEi6LVGQ/khR/2dsb2JhbABEwikJexZzgh8BAQEDAXkQCw44VwaIIAa+e45hMweCX2EDlkCQaIMJ X-IronPort-AV: E=Sophos;i="4.84,746,1355097600"; d="scan'208";a="12097716" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 27 Feb 2013 07:51:14 +0000 Received: from dhcp-10-61-98-92.cisco.com (dhcp-10-61-98-92.cisco.com [10.61.98.92]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1R7pBbD005090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Feb 2013 07:51:13 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <512DB72D.5000302@globis.net> Date: Wed, 27 Feb 2013 08:51:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4D344FD0-DA83-49D2-B4FA-BB8240412D9D@cisco.com> References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> <512DB72D.5000302@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1499) Cc: Fernando Gont , "homenet@ietf.org" , Ted Lemon Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 07:51:28 -0000 >> =46rom the quoted draft: "for the purposes of this document, assume = that > each link has its own unique Unicast DNS domain name", > which I don't think is acceptable in Homenet. I don't want my phone's > name to change when I walk out to the shed. in a service discovery world, would you even care about what the phone's = name is? does a name really have any meaning without a service associated with = it? let us assume that we don't want anyone to remember these names. the UI = will present a list=20 of available services, given where you are. in that sense I really don't care what the domain name for my local link = or site is either. internally I don't use them, for access into my home when I'm outside I = need to type in the externally visible domain into my service discovery domain registry once. cheers, Ole= From v6ops@globis.net Wed Feb 27 00:51:55 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DD221F85D6 for ; Wed, 27 Feb 2013 00:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw5aTCiPBjXI for ; Wed, 27 Feb 2013 00:51:54 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 61C7121F85A1 for ; Wed, 27 Feb 2013 00:51:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0DED887007E; Wed, 27 Feb 2013 09:46:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DqmNZMvwDFp; Wed, 27 Feb 2013 09:46:15 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 51564870066; Wed, 27 Feb 2013 09:46:15 +0100 (CET) Message-ID: <512DC7D1.5030101@globis.net> Date: Wed, 27 Feb 2013 09:46:09 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Ole Troan References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> <512DB72D.5000302@globis.net> <4D344FD0-DA83-49D2-B4FA-BB8240412D9D@cisco.com> In-Reply-To: <4D344FD0-DA83-49D2-B4FA-BB8240412D9D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "homenet@ietf.org" , Ted Lemon Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 08:51:55 -0000 > Ole Troan > 27 February 2013 08:51 > > > in a service discovery world, would you even care about what the > phone's name is? Theoretically fine, but in combination with autoconfig of links, the domain names are also likely to be meaningless and changing, which means service discovery becomes a "must" for all homenet nodes. And there's the possibility of difficult to debug name clashes as "myphone" or "mygamestation" moves between links. > does a name really have any meaning without a service associated with it? > URLs have meaning (rfc1738). It's going to be tough to know when your browser (connecting from off-net) can cache http://myphone.building1.isp1.com or not. Cookie handling too (keyed on URL, which is hard linked to hostname, which will change when the phone moves to http://myphone.building2.isp1.com). Or is there some magic to handle this that scales to the whole Internet? At least if just the IPv6 address changed we'd only have to deal with caching hostname -> IPv6 addresses lookups. > let us assume that we don't want anyone to remember these names. the > UI will present a list > of available services, given where you are. > Right, but the FQDN changes every time a device moves, not just the address, which either means large amounts of service discovery traffic (like Appletalk ZIP/NBP + "the Finder" which had huge scaling issues), or large amounts of update traffic plus potential caching issues of anything linked to URL (and in turn to hostname). > in that sense I really don't care what the domain name for my local > link or site is either. > internally I don't use them, for access into my home when I'm outside > I need to type in the externally visible > domain into my service discovery domain registry once. > cheers, > Ole > Ray Hunter > 27 February 2013 08:35 > >From the quoted draft: "for the purposes of this document, assume that > each link has its own unique Unicast DNS domain name", > which I don't think is acceptable in Homenet. I don't want my phone's > name to change when I walk out to the shed. > ------------------------------------------------------------------------ From mellon@fugue.com Wed Feb 27 06:26:31 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876B021F8602 for ; Wed, 27 Feb 2013 06:26:31 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc3Id7lhh+Jr for ; Wed, 27 Feb 2013 06:26:31 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A430221F85BB for ; Wed, 27 Feb 2013 06:26:21 -0800 (PST) Received: from kali-64.home (pool-108-46-184-29.nycmny.fios.verizon.net [108.46.184.29]) by toccata.fugue.com (Postfix) with ESMTPSA id A42072380503; Wed, 27 Feb 2013 09:26:20 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <29879.1361940815@sandelman.ca> Date: Wed, 27 Feb 2013 09:26:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8A0363D9-E786-4BED-A75F-145EFA253217@fugue.com> References: <512CCF34.9010705@si6networks.com> <27626.1361907344@sandelman.ca> <070E0E14-538D-42DF-8B5F-B149122A5C1F@fugue.com> <29879.1361940815@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1499) Cc: "homenet@ietf.org" Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:26:31 -0000 On Feb 26, 2013, at 11:53 PM, Michael Richardson = wrote: > So, my take on this is that you mean, mdnsext might actually have some = work to do. > - improve name clashes due to subnet switching. Oh no, I think name clashes are already too good. I want mdnsext to = get rid of them! :) From mellon@fugue.com Wed Feb 27 06:35:41 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508F521F870E for ; Wed, 27 Feb 2013 06:35:41 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwc3dSoeztIe for ; Wed, 27 Feb 2013 06:35:40 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id D4A0221F86BE for ; Wed, 27 Feb 2013 06:35:40 -0800 (PST) Received: from kali-64.home (pool-108-46-184-29.nycmny.fios.verizon.net [108.46.184.29]) by toccata.fugue.com (Postfix) with ESMTPSA id 2896B2380503; Wed, 27 Feb 2013 09:35:39 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <4D344FD0-DA83-49D2-B4FA-BB8240412D9D@cisco.com> Date: Wed, 27 Feb 2013 09:35:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4CD33773-4521-493D-ACB1-294CC5813BE7@fugue.com> References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> <512DB72D.5000302@globis.net> <4D344FD0-DA83-49D2-B4FA-BB8240412D9D@cisco.com> To: Ole Troan X-Mailer: Apple Mail (2.1499) Cc: Ray Hunter , "homenet@ietf.org" , Fernando Gont Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:35:41 -0000 On Feb 27, 2013, at 2:51 AM, Ole Troan wrote: > let us assume that we don't want anyone to remember these names. the = UI will present a list=20 > of available services, given where you are. Why would we assume that? Devices have names. My phone has a name, = my laptop has a name. How else would I know which device I was talking = to? I don't want my phone to just be "iPhone" in the discovery list. = And if it has a name, I want it to have the same name everywhere. = Adding an extra layer of indirection doesn't make that problem any = easier. This is a really important problem, and what you are proposing is moving = in exactly the wrong direction: a multiply-indirected naming hierarchy = that will almost certainly display artifacts that will confuse the heck = out of users, because at the bottom of the hierarchy names aren't = consistent. We've seen examples of this in the past--I'm sure that = Stuart and Dave can tell you war stories. Keeping names consistent across subnets is possible. It can definitely = be done with DHCP, and there are RFCs documenting how it's done. If it = can be done with DHCP, it can be done with whatever protocol we settle = on, whether it's DHCP, mDNS, DNS+CGA+TSIG, or some other thing. From mellon@fugue.com Wed Feb 27 07:10:31 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689D021F86C2 for ; Wed, 27 Feb 2013 07:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77+j02WQpiep for ; Wed, 27 Feb 2013 07:10:30 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC1321F86B8 for ; Wed, 27 Feb 2013 07:10:30 -0800 (PST) Received: from [10.0.1.12] (user-387gmsm.cable.mindspring.com [208.120.91.150]) by toccata.fugue.com (Postfix) with ESMTPSA id DA21823815F2; Wed, 27 Feb 2013 10:10:28 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <512E1E5D.1090209@mtcc.com> Date: Wed, 27 Feb 2013 10:10:27 -0500 Content-Transfer-Encoding: 7bit Message-Id: <3C55EF57-E6C7-4258-B934-7E8A2F82D61F@fugue.com> References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> <512DB72D.5000302@globis.net> <4D344FD0-DA83-49D2-B4FA-BB8240412D9D@cisco.com> <512DC7D1.5030101@globis.net> <512E1E5D.1090209@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1499) Cc: Ray Hunter , "homenet@ietf.org" , Fernando Gont , Ole Troan Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:10:31 -0000 On Feb 27, 2013, at 9:55 AM, Michael Thomas wrote: > if I really want to replenish its digital toothpaste, I'd almost > certainly surf to https://mikestoothbrush.mtcc.com to make certain I'm > not being tricked into resupplying ot.1027.holidayinn.com's toothbrush. Where can I get one of these internet-retoothpasteable toothbrushes? From mattia.rossi.mailinglists@gmail.com Wed Feb 27 08:22:12 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE5621F86B8 for ; Wed, 27 Feb 2013 08:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.865 X-Spam-Level: X-Spam-Status: No, score=-2.865 tagged_above=-999 required=5 tests=[AWL=0.734, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlpW0C8qN4dl for ; Wed, 27 Feb 2013 08:22:08 -0800 (PST) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id D8A7421F8667 for ; Wed, 27 Feb 2013 08:22:04 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so648399eei.7 for ; Wed, 27 Feb 2013 08:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FvFM3sEmlL9KtLZK+HDsB68g+CCYmnIK6S+KMiqfxzM=; b=s3BmbAKX1di/qAHBmbluY4NWVkDQ/dAc6/glUA6pBfPAxcgiIL6wGU+USU+hbWbUAv lj/yAtIx/i0Gvkf2U6TxEon1PSU6p8RNcewXgtkTBmsg+9+I6k8Jvqz/+xCgOjTbuI0J FS0JvMSRfvoMlGGZVFITBJ3WyFc6ATZUw08q3bhlnqmO7E2nHcQULKTjZowbS1fUXUUE rOK18awqYGtDdIjenAd3l4/hFzYStQwK0C+7GZmUEhxBu4g5l9/lBXe819OaqIJdyNPq OjxeyOjYtnVDvtnkfYWOS3ILeF5MP8Tr7GM/JK8JrkF64SO+6RwpKSViWSC4B8eIC4oA R2Mw== X-Received: by 10.14.219.7 with SMTP id l7mr7581736eep.12.1361982123858; Wed, 27 Feb 2013 08:22:03 -0800 (PST) Received: from [192.168.0.101] (vpn.static.83-173-212-209.cybernet.ch. [83.173.212.209]) by mx.google.com with ESMTPS id q42sm7216886eem.14.2013.02.27.08.22.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 08:22:02 -0800 (PST) Message-ID: <512E32A8.1070408@gmail.com> Date: Wed, 27 Feb 2013 17:22:00 +0100 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> <512DB72D.5000302@globis.net> <4D344FD0-DA83-49D2-B4FA-BB8240412D9D@cisco.com> <4CD33773-4521-493D-ACB1-294CC5813BE7@fugue.com> In-Reply-To: <4CD33773-4521-493D-ACB1-294CC5813BE7@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:22:12 -0000 Am 27.02.2013 15:35, schrieb Ted Lemon: > On Feb 27, 2013, at 2:51 AM, Ole Troan wrote: >> let us assume that we don't want anyone to remember these names. the UI will present a list >> of available services, given where you are. > Why would we assume that? Devices have names. My phone has a name, my laptop has a name. How else would I know which device I was talking to? I don't want my phone to just be "iPhone" in the discovery list. And if it has a name, I want it to have the same name everywhere. Adding an extra layer of indirection doesn't make that problem any easier. > > This is a really important problem, and what you are proposing is moving in exactly the wrong direction: a multiply-indirected naming hierarchy that will almost certainly display artifacts that will confuse the heck out of users, because at the bottom of the hierarchy names aren't consistent. We've seen examples of this in the past--I'm sure that Stuart and Dave can tell you war stories. I believe this is what Wide Area Bonjour does these days: If you use mDNS on one Network/Domain, you'll end up as mydevice.networkone.net, and if you move to another Network/Domain you'll end up as mydevice.networktwo.net Still, someone from a third WAB network knows, that it's the same device (if the device name is unique enough - but in homenet that shouldn't be a problem). WAB works using a unicast DNS server, Long Lived Queries and Dynamic Updates per network segment. I don't think that's the way to go in the homenet though. WAB is intended to cross the boundaries of the home network, while we're talking what to do within the boundaries. If we could cross subnets without DNS and without confusing domain names it would be better I think. But as we might want to allow people who want a domain structure to set it up, it might be a good idea to recommend the inclusion of a DNS server capable of dynamic DNS updates in each homenet router... Can be switched off by default... Might be something for a future draft "naming of devices in the homenet". Is anyone already working on something like that? > Keeping names consistent across subnets is possible. It can definitely be done with DHCP, and there are RFCs documenting how it's done. If it can be done with DHCP, it can be done with whatever protocol we settle on, whether it's DHCP, mDNS, DNS+CGA+TSIG, or some other thing. > From mike@mtcc.com Wed Feb 27 08:41:00 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F74B21F859D for ; Wed, 27 Feb 2013 08:41:00 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1+bHIdDN0HK for ; Wed, 27 Feb 2013 08:40:59 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 570FE21F87BA for ; Wed, 27 Feb 2013 08:40:58 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1REeHKI014127 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 27 Feb 2013 06:40:18 -0800 Message-ID: <512E1AD1.4090303@mtcc.com> Date: Wed, 27 Feb 2013 06:40:17 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ted Lemon References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> <512DB72D.5000302@globis.net> <4D344FD0-DA83-49D2-B4FA-BB8240412D9D@cisco.com> <4CD33773-4521-493D-ACB1-294CC5813BE7@fugue.com> In-Reply-To: <4CD33773-4521-493D-ACB1-294CC5813BE7@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=719; t=1361976018; x=1362840018; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Naming=20and=20Service=20Di scovery |Sender:=20 |To:=20Ted=20Lemon=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=VrieRadDiIzrzAu1UnH2Xlm/vZvOtOfdYDmcHDUBh18=; b=nEo9fIggJ0V7w/OBvzFrjFR3hV108aF/Bwsr1GHzf19QhokHwHbsZnG6db pWIHn174izRd5UBQXnGwUj2Tk56SxNpeOXvrZzmANn4Y0yI6KOk2HyufGJtt ecuhhSEt73b0RKAQ48T0b/XXhS9o8HPn9gGcDPMzQ8LhuFqmZl1h0=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ole Troan , "homenet@ietf.org" , Fernando Gont , Ray Hunter Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:41:00 -0000 On 02/27/2013 06:35 AM, Ted Lemon wrote: > On Feb 27, 2013, at 2:51 AM, Ole Troan wrote: >> let us assume that we don't want anyone to remember these names. the UI will present a list >> of available services, given where you are. > Why would we assume that? Devices have names. My phone has a name, my laptop has a name. How else would I know which device I was talking to? I don't want my phone to just be "iPhone" in the discovery list. And if it has a name, I want it to have the same name everywhere. Adding an extra layer of indirection doesn't make that problem any easier. > Indeed. I wonder how people would feel about fungible services like, oh say, "toothbrush". Mike From mellon@fugue.com Wed Feb 27 08:49:23 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DF721F87A4 for ; Wed, 27 Feb 2013 08:49:23 -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.130, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7LSRqKsob+s for ; Wed, 27 Feb 2013 08:49:22 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id DFCFC21F877B for ; Wed, 27 Feb 2013 08:49:22 -0800 (PST) Received: from [10.0.1.12] (user-387gmsm.cable.mindspring.com [208.120.91.150]) by toccata.fugue.com (Postfix) with ESMTPSA id BAE8F2380503; Wed, 27 Feb 2013 11:49:20 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ted Lemon In-Reply-To: <512E32A8.1070408@gmail.com> Date: Wed, 27 Feb 2013 11:49:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <45864630-F78F-49C4-AF9F-A10DCF3C4487@fugue.com> References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> <512DB72D.5000302@globis.net> <4D344FD0-DA83-49D2-B4FA-BB8240412D9D@cisco.com> <4CD33773-4521-493D-ACB1-294CC5813BE7@fugue.com> <512E32A8.1070408@gmail.com> To: Mattia Rossi X-Mailer: Apple Mail (2.1499) Cc: homenet@ietf.org Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:49:23 -0000 On Feb 27, 2013, at 11:22 AM, Mattia Rossi = wrote: > I believe this is what Wide Area Bonjour does these days: If you use = mDNS on one Network/Domain, you'll end up asmydevice.networkone.net, and = if you move to another Network/Domain you'll end up as = mydevice.networktwo.net This is certainly less bad than what CeroWRT does with mDNS across = multiple subnets within the homenet now. > Still, someone from a third WAB network knows, that it's the same = device (if the device name is unique enough - but in homenet that = shouldn't be a problem). How do they know this? And if they can know this, why not just use the = same name in both places? Would it be easy for me to create an attack = based on the tendency for people to make assumptions like this, if such = a tendency in fact exists? > WAB works using a unicast DNS server, Long Lived Queries and Dynamic = Updates per network segment. I don't think that's the way to go in the = homenet though. WAB is intended to cross the boundaries of the home = network, while we're talking what to do within the boundaries. Yup. > If we could cross subnets without DNS and without confusing domain = names it would be better I think. > But as we might want to allow people who want a domain structure to = set it up, it might be a good idea to recommend the inclusion of a DNS = server capable of dynamic DNS updates in each homenet router... > Can be switched off by default... If it's switched off by default, it won't work, so there's no point in = specifying it. I think what CeroWRT (and perhaps OpenWRT) do here is = actually exactly right: it's on by default, but just uses a restricted = domain. If you want global naming, you can set it up. I think more = work on making this easy for a non-geek end-user to set up is worth = doing, but I think it's actually a much better basis for naming on a = homenet than mdns. > Might be something for a future draft "naming of devices in the = homenet". Is anyone already working on something like that? We have Stuart's draft, which actually makes me even less enthusiastic = about mDNS in this context, since apparently Apple's patented the use of = mDNS to solve this problem.=20 Lee Howard's written a draft that thoroughly analyzes the state of the = art for dealing with the rDNS side of this, and I wrote a draft talking = about how to make rDNS work with DHCP+PD. I don't think anyone has = talked about how to handle the forward zone, other than what you've seen = here from Dave T=E4ht and Simon Kelley, which I think is a very good = start and ought to be written up. From mike@mtcc.com Wed Feb 27 08:56:19 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC39C21F8756 for ; Wed, 27 Feb 2013 08:56:18 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTFylEcfcrcd for ; Wed, 27 Feb 2013 08:56:16 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id F184A21F87B3 for ; Wed, 27 Feb 2013 08:56:12 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1REtPRN019872 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 27 Feb 2013 06:55:25 -0800 Message-ID: <512E1E5D.1090209@mtcc.com> Date: Wed, 27 Feb 2013 06:55:25 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ray Hunter References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> <512DB72D.5000302@globis.net> <4D344FD0-DA83-49D2-B4FA-BB8240412D9D@cisco.com> <512DC7D1.5030101@globis.net> In-Reply-To: <512DC7D1.5030101@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1036; t=1361976926; x=1362840926; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Naming=20and=20Service=20Di scovery |Sender:=20 |To:=20Ray=20Hunter=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=YbICcjTxtoDnil102TS3X86e5gxKvdxO/izDaUWeh48=; b=PGajAcpd6o5RoJ/qVj5s6+0oHnHt/IDDYKCp7CP5U0dbSHt+4tj/GoSdud P2fwNRYg9PtD05ULCw3n1STReKU14/xzVudfL3j6+jUHBLBpeeX15R51uOKN /HYy3ionGB1+ULW7m4pC3PKO/miGbzEO3FpoyhApQZ3SJJrFFv72E=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ole Troan , "homenet@ietf.org" , Ted Lemon , Fernando Gont Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 16:56:19 -0000 On 02/27/2013 12:46 AM, Ray Hunter wrote: > > does a name really have any meaning without a service associated with it? > > URLs have meaning (rfc1738). It's going to be tough to know when your > browser (connecting from off-net) can cache > http://myphone.building1.isp1.com or not. Cookie handling too (keyed on > URL, which is hard linked to hostname, which will change when the phone > moves to http://myphone.building2.isp1.com). > Allow me to poke at that assumption: why should we expect that the name (assuming there's only one, which is a bad assumption IMO), changes instead of the address record(s)? If I travel around with my toothbrush, shouldn't I expect it to remain named "mikestoothbrush.mtcc.com"? Perhaps it may update a local dns to "mikestoothbrush.1027.holidayinn.com" too, but if I really want to replenish its digital toothpaste, I'd almost certainly surf to https://mikestoothbrush.mtcc.com to make certain I'm not being tricked into resupplying ot.1027.holidayinn.com's toothbrush. Mike From owen@delong.com Wed Feb 27 12:02:01 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6938A21F8890 for ; Wed, 27 Feb 2013 12:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8uavF1LXPd5 for ; Wed, 27 Feb 2013 12:02:00 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCCA21F888C for ; Wed, 27 Feb 2013 12:02:00 -0800 (PST) Received: from tc01-dhcp153.delong.com (delong-tc02-dhcp03 [192.159.10.153]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r1RJvEjl025508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Feb 2013 11:57:14 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r1RJvEjl025508 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1361995035; bh=2yEBpVutgV44TrjQDQgLJ1mAbQk=; h=From:Content-Type:Message-Id:Mime-Version:Subject:Date:References: To:In-Reply-To; b=Ur31ZGLvFmZaTdhJZZyydSH2rfEfBaAo34ZFwsdn6DqVrTiXdMn4fTkmAXg2TtY8M dkHuJriPQCWh0iKZXKqqqiWsmN9uU3rp8cT0fYTRxLE/9X7rbiHAVztjHQDFopHkw0 tvUi/ye+vp0BTw2SIjOow6FEpqZ0AxYrDlXKra40= From: Owen DeLong Content-Type: multipart/alternative; boundary="Apple-Mail=_A75C400B-06BB-496F-A8F3-00BEEC5DD101" Message-Id: <3624F311-F149-486A-961E-3F7C4D82D643@delong.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Wed, 27 Feb 2013 11:57:14 -0800 References: <8D032AC7-F73D-4FFE-9605-CE135EE6A3AE@ecs.soton.ac.uk> To: Tim Chown , homenet@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Wed, 27 Feb 2013 11:57:15 -0800 (PST) X-Mailman-Approved-At: Wed, 27 Feb 2013 12:06:03 -0800 Subject: Re: [homenet] [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:02:01 -0000 --Apple-Mail=_A75C400B-06BB-496F-A8F3-00BEEC5DD101 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm not on the home net list and I need another list like I need a hole = in the head. However, I think section 3.4.1 is reasonably well written. I think it = would be good if the following were added: ISPs are strongly encouraged to issue /48s to residential customers = whenever requested or hinted by the home gateway. Also, it appears that section 3.4.1 assumes a custom will change ISPs by = disconnecting provider A and then connecting provider B. It does not = appear to make a provision for connecting provider B and having a period = of transition with dual prefixes. This possibility should be considered = and addressed, IMHO. Owen On Feb 27, 2013, at 5:56 AM, Tim Chown wrote: >=20 > On 26 Feb 2013, at 14:07, "Brzozowski, John" = wrote: >=20 >> [jjmb] incorrect I have both, just stating that I have both. = Apologies if >> I was not clear. I also have a good # of home routers actively using = IPv6 >> enabled broadband today, ~3%. >=20 > Congratulations, btw. That must be a large number when converted to = real customers :) >=20 > The homenet architecture assumes a CPE rather than a single host. It = discusses ISP allocations in section 3.4.1 of = http://tools.ietf.org/html/draft-ietf-homenet-arch-07. As that text is = in WGLC, any comments on that section would be welcome (preferably on = the homenet list). >=20 > Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_A75C400B-06BB-496F-A8F3-00BEEC5DD101 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I'm = not on the home net list and I need another list like I need a hole in = the head.

However, I think section 3.4.1 is = reasonably well written. I think it would be good if
the = following were added:

ISPs are strongly = encouraged to issue /48s to residential customers whenever requested or = hinted by the home gateway.

Also, it appears = that section 3.4.1 assumes a custom will change ISPs by disconnecting = provider A and then connecting provider B. It does not appear to make a = provision for connecting provider B and having a period of transition = with dual prefixes. This possibility should be considered and addressed, = IMHO.

Owen


On Feb 27, 2013, at 5:56 AM, Tim Chown <tjc@ecs.soton.ac.uk> = wrote:

John_Brzozowski@Cable.Co= mcast.com> wrote:

[jjmb] = incorrect I have both, just stating that I have both.  Apologies = if
I was not clear.  I also have a good # of home routers = actively using IPv6
enabled broadband today, = ~3%.

Congratulations, btw. That must be a = large number when converted to real customers = :)

The homenet architecture assumes a CPE = rather than a single host. It discusses ISP allocations in section 3.4.1 = of http://tool= s.ietf.org/html/draft-ietf-homenet-arch-07.  As that text is in = WGLC, any comments on that section would be welcome (preferably on the = homenet = list).

Tim
___________________________= ____________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail=_A75C400B-06BB-496F-A8F3-00BEEC5DD101-- From tjc@ecs.soton.ac.uk Wed Feb 27 12:22:03 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AC621F87FB for ; Wed, 27 Feb 2013 12:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbSvX+nIpa+8 for ; Wed, 27 Feb 2013 12:22:00 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 129E321F87F6 for ; Wed, 27 Feb 2013 12:21:55 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r1RKLitC010184; Wed, 27 Feb 2013 20:21:44 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r1RKLitC010184 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1361996505; bh=9pfO6j+6zLxFMRwcFFR3glGPcZ0=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=XShxzB4Y2pFq5BBGJyvcDGdN25yyyTVDefd+VnxryWb9EJQpORq72Nx0p4laycunu Q30NksiY23pHV4n7NdUMeiikR5MXRRptB29ViZ8V52ULoBcBnaAgexWCm+MqHarPDD mIcKnYWa8ddoSDzbUoazWt+D8F0HNkb6yuUw/g8A= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p1QKLi0430619027fe ret-id none; Wed, 27 Feb 2013 20:21:44 +0000 Received: from [192.168.1.103] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r1RKKI0r005186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Feb 2013 20:20:20 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_43429354-37C1-443A-A78C-5EF25584BC23" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <3624F311-F149-486A-961E-3F7C4D82D643@delong.com> Date: Wed, 27 Feb 2013 20:20:19 +0000 Message-ID: References: <8D032AC7-F73D-4FFE-9605-CE135EE6A3AE@ecs.soton.ac.uk> <3624F311-F149-486A-961E-3F7C4D82D643@delong.com> <795E88C7-3879-4CAB-A743-7005C3CF818E@ecs.soton.ac.uk> To: Owen DeLong X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p1QKLi043061902700; tid=p1QKLi0430619027fe; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r1RKLitC010184 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: homenet@ietf.org Subject: Re: [homenet] [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:22:03 -0000 --Apple-Mail=_43429354-37C1-443A-A78C-5EF25584BC23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 Feb 2013, at 19:57, Owen DeLong wrote: > I'm not on the home net list and I need another list like I need a = hole in the head. I know the feeling :) > However, I think section 3.4.1 is reasonably well written. I think it = would be good if > the following were added: >=20 > ISPs are strongly encouraged to issue /48s to residential customers = whenever requested or hinted by the home gateway. >=20 > Also, it appears that section 3.4.1 assumes a custom will change ISPs = by disconnecting provider A and then connecting provider B. It does not = appear to make a provision for connecting provider B and having a period = of transition with dual prefixes. This possibility should be considered = and addressed, IMHO. Thanks for the comments. I've added that into the WGLC feedback list. Tim > Owen >=20 >=20 > On Feb 27, 2013, at 5:56 AM, Tim Chown wrote: >=20 >>=20 >> On 26 Feb 2013, at 14:07, "Brzozowski, John" = wrote: >>=20 >>> [jjmb] incorrect I have both, just stating that I have both. = Apologies if >>> I was not clear. I also have a good # of home routers actively = using IPv6 >>> enabled broadband today, ~3%. >>=20 >> Congratulations, btw. That must be a large number when converted to = real customers :) >>=20 >> The homenet architecture assumes a CPE rather than a single host. It = discusses ISP allocations in section 3.4.1 of = http://tools.ietf.org/html/draft-ietf-homenet-arch-07. As that text is = in WGLC, any comments on that section would be welcome (preferably on = the homenet list). >>=20 >> Tim >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_43429354-37C1-443A-A78C-5EF25584BC23 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii owen@delong.com> wrote:
I'm not on the home net list = and I need another list like I need a hole in the = head.

I know the feeling = :)

However, I think section 3.4.1 is reasonably = well written. I think it would be good if
the following were = added:

ISPs are strongly encouraged to issue = /48s to residential customers whenever requested or hinted by the home = gateway.

Also, it appears that section 3.4.1 = assumes a custom will change ISPs by disconnecting provider A and then = connecting provider B. It does not appear to make a provision for = connecting provider B and having a period of transition with dual = prefixes. This possibility should be considered and addressed, = IMHO.

Thanks for the comments. = I've added that into the WGLC feedback = list.

Tim

tjc@ecs.soton.ac.uk> = wrote:

John_Brzozowski@Cable.Co= mcast.com> wrote:

[jjmb] = incorrect I have both, just stating that I have both.  Apologies = if
I was not clear.  I also have a good # of home routers = actively using IPv6
enabled broadband today, = ~3%.

Congratulations, btw. That must be a = large number when converted to real customers = :)

The homenet architecture assumes a CPE = rather than a single host. It discusses ISP allocations in section 3.4.1 = of http://tool= s.ietf.org/html/draft-ietf-homenet-arch-07.  As that text is in = WGLC, any comments on that section would be welcome (preferably on the = homenet = list).

Tim
___________________________= ____________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

_________= ______________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.= org/mailman/listinfo/homenet

= --Apple-Mail=_43429354-37C1-443A-A78C-5EF25584BC23-- From v6ops@globis.net Wed Feb 27 12:27:19 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBE821F85D7 for ; Wed, 27 Feb 2013 12:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B12VMD7yLRPC for ; Wed, 27 Feb 2013 12:27:19 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0310D21F8530 for ; Wed, 27 Feb 2013 12:27:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 4F018870061; Wed, 27 Feb 2013 21:21:53 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3WbOeRSplB9; Wed, 27 Feb 2013 21:21:24 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 43EBD87005F; Wed, 27 Feb 2013 21:21:24 +0100 (CET) Message-ID: <512E6ABE.20809@globis.net> Date: Wed, 27 Feb 2013 21:21:18 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Michael Thomas References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> <512DB72D.5000302@globis.net> <4D344FD0-DA83-49D2-B4FA-BB8240412D9D@cisco.com> <512DC7D1.5030101@globis.net> <512E1E5D.1090209@mtcc.com> In-Reply-To: <512E1E5D.1090209@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ole Troan , "homenet@ietf.org" , Ted Lemon , Fernando Gont Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:27:20 -0000 Michael Thomas wrote: > On 02/27/2013 12:46 AM, Ray Hunter wrote: >> >> [Ole] does a name really have any meaning without a service >> associated with it? >> >> [Ray] URLs have meaning (rfc1738). It's going to be tough to know >> when your >> browser (connecting from off-net) can cache >> http://myphone.building1.isp1.com or not. Cookie handling too (keyed on >> URL, which is hard linked to hostname, which will change when the phone >> moves to http://myphone.building2.isp1.com). > [Mike] Allow me to poke at that assumption: why should we expect that > the name (assuming there's only one, which is a bad assumption IMO), > changes instead of the address record(s)? If I travel around with my > toothbrush, shouldn't I expect it to remain named > "mikestoothbrush.mtcc.com"? > Perhaps it may update a local dns to > "mikestoothbrush.1027.holidayinn.com" > too, but if I really want to replenish its digital toothpaste, I'd almost > certainly surf to https://mikestoothbrush.mtcc.com to make certain I'm > not being tricked into resupplying ot.1027.holidayinn.com's toothbrush. > [Ray] Mike, your quoting in the above message was rather strange, so I've tried to re clarify who wrote what. [Ray] http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01 is proposing that both the domain name and the IPv6 address change as nodes move across subnets within homenet AFAICS. [Ray] Changing domain names (and thus URL) when a device moves within homenet is bad IMHO. From mike@mtcc.com Wed Feb 27 14:32:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5802421F888F for ; Wed, 27 Feb 2013 14:32:05 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXB4VPjUdLAB for ; Wed, 27 Feb 2013 14:32:03 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA7821F84AE for ; Wed, 27 Feb 2013 14:32:01 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1RKVKOm016543 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 27 Feb 2013 12:31:21 -0800 Message-ID: <512E6D18.9000107@mtcc.com> Date: Wed, 27 Feb 2013 12:31:20 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ray Hunter References: <512CCF34.9010705@si6networks.com> <512CE911.6070003@si6networks.com> <4DE5B9EA-0874-4EE9-B463-F543CA4EB40F@cisco.com> <512DB72D.5000302@globis.net> <4D344FD0-DA83-49D2-B4FA-BB8240412D9D@cisco.com> <512DC7D1.5030101@globis.net> <512E1E5D.1090209@mtcc.com> <512E6ABE.20809@globis.net> In-Reply-To: <512E6ABE.20809@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1998; t=1361997081; x=1362861081; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Naming=20and=20Service=20Di scovery |Sender:=20 |To:=20Ray=20Hunter=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=aRNTnq+e3qz2kkzP5jjrueQBaTFC9eKl/B227HbLNCY=; b=tXJhkvPAEKKY1s+gxB7i5HRvYak2jqnhlDxXKgFyTiJ1KekMIlrIKrmGg2 xI9sPrRBaWy1YNIkfePh56f2OWrjlh87YNiQTI+27lGdHlxv3DspggChEmXf stT5+qUYIAmqqXf3Hf6WvnecwmRGU5o6bAoUT+W0U4fTvRSou16Z0=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Ole Troan , "homenet@ietf.org" , Ted Lemon , Fernando Gont Subject: Re: [homenet] Naming and Service Discovery X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 22:32:05 -0000 On 02/27/2013 12:21 PM, Ray Hunter wrote: > Michael Thomas wrote: >> On 02/27/2013 12:46 AM, Ray Hunter wrote: >>> [Ole] does a name really have any meaning without a service >>> associated with it? >>> >>> [Ray] URLs have meaning (rfc1738). It's going to be tough to know >>> when your >>> browser (connecting from off-net) can cache >>> http://myphone.building1.isp1.com or not. Cookie handling too (keyed on >>> URL, which is hard linked to hostname, which will change when the phone >>> moves to http://myphone.building2.isp1.com). >> [Mike] Allow me to poke at that assumption: why should we expect that >> the name (assuming there's only one, which is a bad assumption IMO), >> changes instead of the address record(s)? If I travel around with my >> toothbrush, shouldn't I expect it to remain named >> "mikestoothbrush.mtcc.com"? >> Perhaps it may update a local dns to >> "mikestoothbrush.1027.holidayinn.com" >> too, but if I really want to replenish its digital toothpaste, I'd almost >> certainly surf to https://mikestoothbrush.mtcc.com to make certain I'm >> not being tricked into resupplying ot.1027.holidayinn.com's toothbrush. >> > [Ray] Mike, your quoting in the above message was rather strange, so > I've tried to re clarify who wrote what. > [Ray] http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01 is > proposing that both the domain name and the IPv6 address change as nodes > move across subnets within homenet AFAICS. > [Ray] Changing domain names (and thus URL) when a device moves within > homenet is bad IMHO. Let me understand: mdnsext-hybrid says that my domain name changes as I move across subnets, and you think that's bad. If so, I agree. At least to the extent that I don't really care very much what a local (m)DNS wants to name my device so long as the device updates its address records for my names as I move. .local and its kin are a horrible hack that don't meet the requirements of a mobile world. Mike From mike@mtcc.com Thu Feb 28 14:09:51 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC6A21F8B8D for ; Thu, 28 Feb 2013 14:09:51 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKVCZ8PnHxPV for ; Thu, 28 Feb 2013 14:09:49 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 583E921F8B4C for ; Thu, 28 Feb 2013 14:09:49 -0800 (PST) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r1SM9cuw030195 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 28 Feb 2013 14:09:39 -0800 Message-ID: <512FD5A2.4020109@mtcc.com> Date: Thu, 28 Feb 2013 14:09:38 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6465; t=1362089380; x=1362953380; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20last=20call=20comments=20on=20section=203.7 |Sender:=20 |To:=20=22=22=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=8U+vShRerFWXSG0MApUb8vS5l36LNTiu0yM5H0BWmuQ=; b=eITBK6G6lggT+cKn1ldFwX9c5L6NOm9VTmbCFkotzoVijfmbClrAjGLsUo 9gmQmdbIP46pSOQob/ItexaXB/rYpiFFSE/YsOzDdRgLEGrG+SQjNb7eM/P/ mCfM74cq5EydRf6F7VS1QCpMPqMglQ5vaj1zd9O09RtQRVDYa+UEA=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: [homenet] last call comments on section 3.7 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:09:51 -0000 In general, I do not think this is ready to go. From what I can see, there is a significant amount of disagreement about whether mdns and/or sd have a place in the homenet architecture, and more than a little bit of groping around as to what the problems are that need to be solved. This section is both prescriptive in ways it ought not be, and speculative in ways that an architecture document shouldn't be doing. I personally think that enumerating requirements for what any solution ought to solve for is way more important, but is sadly lacking in this section. I think there is an unanswered question in this wg as to whether naming should take a posture of how to integrate local naming into a wider global scope, or figuring out how to adapt globally scoped naming into a local context. In practical terms: whether we start with mdns and .local and figure out how to hack it, or do we start with DNS and figure out how to make it work against requirements. I will again say that the lack of well agreed requirements for what we're doing hinders resolving this question. 3.7.1 Service Discovery This section starts out with telling us how it will be presented to the user (GUI) without any reference to why a user or anything else needs service discovery. As service discovery is not common on the internet today, I think this requires a lot more motivation/requirements before jumping and telling us that out of scope GUI's will come to the rescue -- it's not even clear that machine-machine interfaces to find and configure, say, my IP speakers to my IP home entertainment system won't be the norm. Bottom line: remove the "how" and get immediately to the "why". Then we can have a discussion. 3.7.2 Assigning Names I think this can be easily rewritten to not need any informative references to yet to be approved drafts that are not agreed upon. 3.7.3 Namespaces It's not clear to me why a single namespace is "desirable". Do rebellious teenagers really want to be part of their fuddy-duddy parent's namespace? Does it even matter, architecturally? At least some motivation would be helpful. Part of my uncomfort here is that there is a hidden assumption that a "home" is an indivisible unit. Is that really true? I'm not sure why ISP provided naming should be considered the default: we really don't know what will be the case, and obviously ISP's have a big downside both from changing ISP's, as well as the multiple-ISP's standpoint. I think that we can more safely say that this service is just some "cloud" service provided somewhere on the net since there isn't any locality requirement that I'm aware of. This section dwells in solution space far more than I think it ought, and is highly speculative (eg, .sitelocal, ulqdn, etc). Instead of speculating, it would be better to say what characteristics we want, and what requirements we need to fulfill. 3.7.4 Homenet name service Somewhere in this document we really need to make clear how mobility figures into all of this. That is, what happens when things move around and what the implications are for naming, both in my home, and on yours. I don't think we should compare and contrast mdns as being "zeroconf" with the implication that DNS is not. You can achieve "zeroconf" using service announcement and not require multicast at all (at least not to announce the service). In fact, until we have something resembling rough consensus, I don't really think it's appropriate to favor one or the other in this document. Again, ditch the references to ISP with something "cloud-like". I don't understand what mDNS has to do with service announcement to a repository. mDNS is a way to find names in lieu of a repository (that is, each device is it's own authoritative name service). Sending naming/service announcements to a repository is an adjunct of the repository protocols and has nothing to do with mDNS that I can figure out. More speculation about mDNS vs. SRV records without any motivation of what is trying to be accomplished and why... it just sort of appears out of thin air here. I think more thought needs to be given to adding names automatically to a repository. It mentions that a user may choose to do so, but what if there's no meaningful "user" such as my IP-speakers with no UI? Should it try or not? (I think it ought, but that's me). More to the point: what are the implications of things that don't have meaningful UI's. There should be some more discussion of the differences between a locally significant domain name, and a globally significant one. What happens when people camp on names they don't own? How might that interact with mobility? More speculation about dnydns without any motivation for why it's interesting and/or significant. There seems to be no mention of the relationship between local/home resolvers if the local resolver isn't the authoritative resolver. In particular, it's not an unusual situation to have a "cloud" (read: high bandwidth, well connected...) authoritative dns be a slave to a local master. Or if you don't like that, some other way to achieve similar goals of not wanting my home network have to know how to deal with ddos's on nameservers, as one for-instance. 3.7.5 Independent Operation I'm generally skeptical that anything these days works well when you pull the plug on the Internet. There are so many hidden assumptions about connectivity that I don't think we should try to do anything heroic here. 3.7.6 Considerations for LLN's First I'll say that it's not just LLN's that have problems with chatty networks: it's anything with a battery. This should be rewritten from that perspective and stay away from speculation about whether proxies are needed for a particular technology that doesn't necessarily have consensus. More to the point: this architecture should have considerations throughout about battery driven devices and their considerations, and not just whether mdns will cause daily trips to the store to buy new batteries. 3.7.7 DNS resolver discovery I don't understand this section: is there anything we need to do beyond what SLAAC and/or DHCP do now? If there is, it might be nice to enumerate what the problem is. --- Overall, section 3.7 leaves me more confused than enlightened. It reads more like a stream of consciousness than an architecture. Mike From john_brzozowski@cable.comcast.com Thu Feb 28 17:45:51 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B8521F8802 for ; Thu, 28 Feb 2013 17:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.028 X-Spam-Level: X-Spam-Status: No, score=-104.028 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cknDkHJO58E for ; Thu, 28 Feb 2013 17:45:50 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 9B11321F8814 for ; Thu, 28 Feb 2013 17:45:50 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.58650238; Thu, 28 Feb 2013 18:15:08 -0700 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 28 Feb 2013 20:45:46 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Thu, 28 Feb 2013 20:45:46 -0500 From: "Brzozowski, John" To: "homenet@ietf.org" Thread-Topic: [v6ops] new draft: draft-shishio-v6ops-dpvt Thread-Index: AQHOFh5+/dzS9cbAc0ie1KTMDHbgxQ== Date: Fri, 1 Mar 2013 01:45:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.55.72] Content-Type: multipart/mixed; boundary="_002_BD87928F6BFAEF4EBEB883E1C4F587723405C7D9PACDCEXMB01cabl_" MIME-Version: 1.0 Subject: [homenet] FW: [v6ops] new draft: draft-shishio-v6ops-dpvt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 01:45:51 -0000 --_002_BD87928F6BFAEF4EBEB883E1C4F587723405C7D9PACDCEXMB01cabl_ Content-Type: text/plain; charset="us-ascii" Content-ID: <2AFAD18AC242424D828ED7F486FEC5AE@cable.comcast.com> Content-Transfer-Encoding: quoted-printable Tim, Per your request below here are some comments pertaining to the section you mention below. * The section seems to hint at two extremes stable on one end and very dynamic i.e. at each CER reboot. I think it is important to note that there is middle ground here and that providers typically have good reason for requiring prefix changes, largely related to network capacity management. It is not clear to me if this need to be called out in the text, however, I thought you should know. * Agreed regarding /64 subnet lengths * This section does not differentiate between a residential service and a commercial or SOHO service. Is this outlined elsewhere in the draft? Does it need to be? * Note - some devices today can only utilize a /64 and nothing more these would not break. * No NPTv6 please * ULAs support could be introduced at a later date * Agreed regarding bridging avoidance * How is "relatively stable prefix" defined? * Good text regarding PIA * Regarding renumbering also note that operators take precautions to ensure this is seamless as well including lease time lowering in advance of the renumbering event. We have been doing this for years. * Forced renumbering for privacy sounds unfortunate but based on various emails I have seen lately this seems to be something that must be supported. * Agreed that service discovery is essential I hope these comments are useful, I recognize I was not overly verbose. I hope this is a feature not a bug. Please let know if you wish to discuss further. John -----Original Message----- From: Tim Chown Date: Wednesday, February 27, 2013 5:56 AM To: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt > >On 26 Feb 2013, at 14:07, "Brzozowski, John" > wrote: > > >[jjmb] incorrect I have both, just stating that I have both. Apologies if >I was not clear. I also have a good # of home routers actively using IPv6 >enabled broadband today, ~3%. > > > > >Congratulations, btw. That must be a large number when converted to real >customers :) > > >The homenet architecture assumes a CPE rather than a single host. It >discusses ISP allocations in section 3.4.1 of >http://tools.ietf.org/html/draft-ietf-homenet-arch-07. As that text > is in WGLC, any comments on that section would be welcome (preferably on >the homenet list). > > >Tim --_002_BD87928F6BFAEF4EBEB883E1C4F587723405C7D9PACDCEXMB01cabl_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=130; creation-date="Fri, 01 Mar 2013 01:45:46 GMT"; modification-date="Fri, 01 Mar 2013 01:45:46 GMT" Content-ID: <84DB2C559FC85544AA69EBDA7F35EF4C@cable.comcast.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1h aWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHMNCg== --_002_BD87928F6BFAEF4EBEB883E1C4F587723405C7D9PACDCEXMB01cabl_--