From nobody Fri Apr 1 17:18:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A0B12D12F for ; Fri, 1 Apr 2016 17:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK8CVyhxV2vc for ; Fri, 1 Apr 2016 17:18:54 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 548AD12D101 for ; Fri, 1 Apr 2016 17:18:53 -0700 (PDT) X-SENDER-IP: 10.64.163.157 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.24,428,1454994000"; d="scan'208";a="1022501952" Received: from unknown (HELO exchpapp16.corp.twcable.com) ([10.64.163.157]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 01 Apr 2016 20:16:46 -0400 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp16.corp.twcable.com (10.64.163.157) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 1 Apr 2016 20:18:52 -0400 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1156.000; Fri, 1 Apr 2016 20:18:52 -0400 From: "Howard, Lee" To: 'IPv6 Operations' Thread-Topic: Jabber room Thread-Index: AQHRjHU7e+QtFGzFYECw/fSN+FN9LA== Date: Sat, 2 Apr 2016 00:18:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.239] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22232.005 x-tm-as-result: No--31.374100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <520155AD50E63A48A3FF6B64867EE845@twcable.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [v6ops] Jabber room X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 00:18:56 -0000 As a way of encouraging participation, the chairs would like to point out that all WGs have an associated Jabber room, in our case v6ops@jabber.ietf.org As an experiment, it would be good to know that people with good language skills are in the Jabber room, to help out when a speaker uses slang or an unfamiliar word in English. Since we=B9re in Buenos Aires, Spanish and English would be especially useful. As always, we=B9re also looking for a Jabber scribe, who will let remote participants know as slides change, and can relay comments from the Jabber room to the physical room. Any volunteers? More information on the use of Jabber at IETF is at https://www.ietf.org/jabber/ More information on Jabber scribing at https://tools.ietf.org/html/rfc7649 Thanks, Lee ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Sat Apr 2 11:43:00 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785E512D197 for ; Sat, 2 Apr 2016 11:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.53 X-Spam-Level: X-Spam-Status: No, score=-114.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dO5_kqfgqxM7 for ; Sat, 2 Apr 2016 11:42:56 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B51412D182 for ; Sat, 2 Apr 2016 11:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12210; q=dns/txt; s=iport; t=1459622576; x=1460832176; h=from:to:subject:date:message-id:references:mime-version; bh=FeWq0bl5mhgActfdhZKlSWARBIAHi7hMnV1HJ8c0AT8=; b=GDw3H1Z0d1xicMdxOSjJNswVlFi4M6NqR/dKMDHqrca8GSt0hAy48jFB q7tYWXfxtsvYyL7woljRW8XJLEDHNXvpL5wkhB5+Nk0ilLVLfrMxiBQJm ed2NoHLzW48Csdc0C/YH3DWgtj9LAwjYZC3RjO3l5kfJfYgjTPQnKKH6Y I=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJBQCGEQBX/4MNJK1DFwOCa0xTdwYGt?= =?us-ascii?q?iuEfoFyFwEJgjyCZkoCgSg6EgEBAQEBAQFlHAuEQQEBAQMBAQEBaxALAgEZAwE?= =?us-ascii?q?CFg4EBycLFAcCCAIEEwkFiBEICQUsxAsBAQEBAQEBAQEBAQEBAQEBAQEBAQENC?= =?us-ascii?q?IgVglWEBiE4AQwCBwkIggFLGIIrBYVkkh0Bgx+BZm2FXoI3gWhOg3+IWodYh0E?= =?us-ascii?q?BDxgCOYIygTVshyh+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,432,1454976000"; d="asc'?scan'208,217";a="256673005" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Apr 2016 18:42:54 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u32Igsno029911 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 2 Apr 2016 18:42:54 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 2 Apr 2016 13:42:53 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Sat, 2 Apr 2016 13:42:53 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org" Thread-Topic: [95attendees] Please consider acting as a "jabber scribe" during IETF 95 working group sessons Thread-Index: AQHRjO5SB1cjBhqSjkW2zC5LcGCWlw== Date: Sat, 2 Apr 2016 18:42:53 +0000 Message-ID: <05121DA7-80FD-43EB-AED6-81DDAB46BE97@cisco.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.164.122] Content-Type: multipart/signed; boundary="Apple-Mail=_2E69AFD5-B670-41F0-A5AD-DA5D6A90C994"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Fwd: [95attendees] Please consider acting as a "jabber scribe" during IETF 95 working group sessons X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 18:42:58 -0000 --Apple-Mail=_2E69AFD5-B670-41F0-A5AD-DA5D6A90C994 Content-Type: multipart/alternative; boundary="Apple-Mail=_DEE72F9D-35D4-43A8-BCB5-ECCEFAAAC656" --Apple-Mail=_DEE72F9D-35D4-43A8-BCB5-ECCEFAAAC656 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We will need a jabber scribe and someone to take notes/minutes Monday = afternoon. > Begin forwarded message: >=20 > From: Dan York > Subject: [95attendees] Please consider acting as a "jabber scribe" = during IETF 95 working group sessons > Date: April 2, 2016 at 11:45:37 AM GMT-3 > To: "95attendees@ietf.org" <95attendees@ietf.org> >=20 > IETF 95 attendees, >=20 > Given that we'll have remote attendees for many of the working groups, = I would encourage people to consider volunteering as a "jabber scribe" = in the working groups you attend this week. This role is critical in = helping remote attendees be able to participate in the discussions going = on in the rooms here in Buenos Aires. >=20 > If you are newer to IETF meetings, acting as a jabber scribe is a = great way to learn more about the process and get involved. It has = helped me learn the names of people involved with groups and also, quite = frankly, helped me keep focused on paying attention to what is going on = in the sessions. >=20 > The most important part of the role is helping relay questions from = remote participants to the room by going up to the mic and asking the = question on behalf of the remote attendee. >=20 > All you need is an account on a Jabber server (a list of servers that = allow public registration: https://xmpp.net/directory.php = ) and a client (a list of clients: = http://xmpp.org/software/clients.html = ) >=20 > Anyway, throughout the week the working groups will be looking for = volunteers - and even if someone else volunteers having a second person = available as a backup is always great to have. >=20 > Please consider helping out this way if you can! > Thanks, > Dan >=20 > P.S. If you'd like more information about the role, Peter St. Andre = and I captured some suggestions in this document: = http://tools.ietf.org/html/rfc7649 >=20 > -- > Dan York > Senior Content Strategist, Internet Society > york@isoc.org +1-802-735-1624 > Jabber: york@jabber.isoc.org > Skype: danyork http://twitter.com/danyork = >=20 > http://www.internetsociety.org/ >=20 >=20 >=20 > _______________________________________________ > 95attendees mailing list > 95attendees@ietf.org > https://www.ietf.org/mailman/listinfo/95attendees --Apple-Mail=_DEE72F9D-35D4-43A8-BCB5-ECCEFAAAC656 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii We will need a jabber scribe and someone to take = notes/minutes Monday afternoon.

Begin = forwarded message:

From: = Dan York <york@isoc.org>
Subject: = [95attendees] = Please consider acting as a "jabber scribe" during IETF 95 working group = sessons
Date: = April 2, 2016 at 11:45:37 AM = GMT-3
To: = "95attendees@ietf.org" = <95attendees@ietf.org>

IETF 95 attendees,

Given that we'll have remote attendees for many of the = working groups, I would encourage people to consider volunteering as a = "jabber scribe" in the working groups you attend this week.  This = role is critical in helping remote attendees be able to participate in the discussions going on in the rooms here in Buenos = Aires.

If you are newer to IETF meetings, acting as a jabber = scribe is a great way to learn more about the process and get involved. =  It has helped me learn the names of people involved with groups = and also, quite frankly, helped me keep focused on paying attention to what is going on in the sessions.

The most important part of the role is helping relay = questions from remote participants to the room by going up to the mic = and asking the question on behalf of the remote attendee.

All you need is an account on a Jabber server (a list of = servers that allow public registration: https://xmpp.net/directory.php ) and a client (a = list of clients: http://xmpp.org/software/clients.html )

Anyway, throughout the week the working groups will be = looking for volunteers - and even if someone else volunteers having a = second person available as a backup is always great to have.

Please consider helping out this way if you can!
Thanks,
Dan

P.S. If you'd like more information about the role, = Peter St. Andre and I captured some suggestions in this = document: http://tools.ietf.org/html/rfc7649 

--
Dan York
Senior Content Strategist, = Internet Society
york@isoc.org   = +1-802-735-1624
Jabber: york@jabber.isoc.org 
Skype: danyork =   http://twitter.com/danyork

http://www.internetsociety.org/




_______________________________________________
95attendees = mailing list
95attendees@ietf.org
https://www.ietf.org/mailman/listinfo/95attendees

= --Apple-Mail=_DEE72F9D-35D4-43A8-BCB5-ECCEFAAAC656-- --Apple-Mail=_2E69AFD5-B670-41F0-A5AD-DA5D6A90C994 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVwASrEayAOS/EQ8MAQLIvQ//SRiMHYHZj57uYsx/77KDKNSoKBddfiLC UOYv6QqrAkaeFHe2BEmd5nokSPr8cnfF8q/Fz47tD1i4z2Hb+uEl4eSUrfH6WNev L4lk7PjDGkRn0YJYKEM//tGd7o/N38LivZb+Jc2nNEzdzfohOTh3MuRv9k6NUgwx 9lPm9YdRSYXcxYaRieCqcY+aRCuAfp9XX6RqqRrcFg54D43fKdRANknr7csMPMXE wYdGsLoH8b547U21561Mr+337kwjWvpL8uNTU4JXdcFMnuSiZOZNAtQ/cjxbD81P Y2HdvonrzgVTq0lxEu5lmG+zJxYxTgyShbQDprJMCry7wzTZnU8rfekmQR5akICi GKPCmJ5mGVyDpsG96aGElJEHg0XTJprxWp0Zmo+WEr2Pbuu9KPne2PnNWisP2t+/ QY4mR0VJndP4HVCSfIIk86E1cxF/SijWBkGwEmpOeToJS+ftgkAQkqtqSrFDvfHD JA3U487+xfLlq+xUgmNxlBJuGkg6wLsB8lkzTfe6AQTyFrHqXWz26Mg/SrKhC0mO zQu+BdfiggovKZQ+48oMQp4YV/nczWgA2MyjsQ3XTmz4IwpCJYAk5pkAeZvKolOd tzPRQUyK0nJDfoLHGvTsCk94YG1jtiOVdpGrWGEEv7++bALobAd27tLzlYiHfSxR CfurSiDbjKQ= =wdvr -----END PGP SIGNATURE----- --Apple-Mail=_2E69AFD5-B670-41F0-A5AD-DA5D6A90C994-- From nobody Sun Apr 3 01:55:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA50412D1E1 for ; Sun, 3 Apr 2016 01:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J57f9C3W7U4d for ; Sun, 3 Apr 2016 01:55:28 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866A512D1D7 for ; Sun, 3 Apr 2016 01:55:27 -0700 (PDT) Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id B939715EC29 for ; Sun, 3 Apr 2016 10:55:24 +0200 (CEST) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 85DEA50F849 for ; Sun, 3 Apr 2016 10:55:24 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 5DD178A0F; Sun, 3 Apr 2016 10:55:24 +0200 (CEST) Date: Sun, 3 Apr 2016 10:55:24 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20160403085524.GA84794@ernw.de> References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 08:55:31 -0000 Hi Ole, On Sat, Mar 12, 2016 at 06:23:50PM +0100, otroan@employees.org wrote: > it depends on the platform and how big forwarding table your switch can handle. > as far as I many switches flood,( and if you want my personal opinion, we should change hosts so that they no longer send MLD joins for link-local groups.) wouldn't this (your personal suggestion) - require updating RFC 4861 where it's stated (sect. 7.2.1 on Interface Initialization): "Joining the solicited-node multicast address is done using a Multicast Listener Discovery such as [MLD] or [MLDv2] protocols." - maybe break ND on some host OSs/platforms (depending on their interpretation of the exact statement above)? [it should be noted I consider that statement a quite unfortunate example of ambiguous wording in an RFC as "is done" can be both read as a descriptive and prescriptive/normative statement] thanks Enno > > Best regards, > Ole > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Sun Apr 3 02:10:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D85E12D523 for ; Sun, 3 Apr 2016 02:10:55 -0700 (PDT) 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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acxOHijIHS0h for ; Sun, 3 Apr 2016 02:10:53 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F00B12D51A for ; Sun, 3 Apr 2016 02:10:53 -0700 (PDT) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id B8DCC15EC29 for ; Sun, 3 Apr 2016 11:10:50 +0200 (CEST) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 6DEFA50F86A for ; Sun, 3 Apr 2016 11:10:50 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 3D76F8A1A; Sun, 3 Apr 2016 11:10:50 +0200 (CEST) Date: Sun, 3 Apr 2016 11:10:50 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20160403091050.GB84794@ernw.de> References: <01905480-57D0-4F61-B68D-0B90EA428698@employees.org> <56CCA922.6020907@gmail.com> <85A832A3-24D3-4443-BD59-DD0D62E3B8C6@employees.org> <56CCAE04.6010308@gmail.com> <56D74640.2060502@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D74640.2060502@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 09:10:55 -0000 Hi, On Thu, Mar 03, 2016 at 09:00:00AM +1300, Brian E Carpenter wrote: > I'm sorry to distract the group with a practical question, but I'm a bit stumped. > My question is below. > > In the thread "Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)", on > 24/02/2016 08:07, Brian E Carpenter wrote: > > On 24/02/2016 07:53, otroan@employees.org wrote: > >>>> MLD joins for the solicited node multicast address has turned out to have little practical purpose. I am thinking of going the other way and stop sending joins for link-local multicast groups. > >>> > >>> Yes. What is the possible use of a link-local "join"? The packets are just there > >>> on the link anyway, so "joining" is entirely an internal matter for each node. I'd like to add that several MLD Querier implementations do not even store FF02:-scoped groups. When we did some testing a while ago (details here: https://www.its.fh-muenster.de/doc/Security_Implications_of_MLD_in_IPv6_Networks.pdf) the Cisco router involved (running IOS 15.4.3) didn't show anything on "show ipv6 mld groups" even after (Win|Linux|BSD) on the local link had sent their reports for solicited-node. best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Sun Apr 3 13:28:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7194D12D570 for ; Sun, 3 Apr 2016 13:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrsih9cJxmVs for ; Sun, 3 Apr 2016 13:28:30 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D65312D562 for ; Sun, 3 Apr 2016 13:28:30 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id zm5so129292084pac.0 for ; Sun, 03 Apr 2016 13:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=5CW0vSK9GpWW1tWayqGKOq1WgrGSzJwBgw5d/8i8ie4=; b=Dnbg1FdsHfX1DGuwAY8yl6f9ulf1AoJ3y9Dmcdo8WgoCBd/l1+Kg5gr5tIue4MXZgk ZqKoiJE06aIMkRp6mum0+XfoLaNS8V5TnEbbZib++drLRSmLit9kATO60c+2gkxK0cx4 6YEfYLSKZD/37RuwB9ivH54106LsWx/bMhtdVbL4TIj1ebygumfTBXpe5WX+E4fwOpsu nFoAI/yyIHtL6TINqbgLbgwTuYWdoWiQCxpa1Ve3SvZIJHAGm0oQUtwOds2Uea4aAfkU 69RdsGjpL7q3XDlM8NP6uNNfXfl3FJkGQBYif/K1pgmNFNx53KRba5L5E8rYwjemWP0n ZKXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=5CW0vSK9GpWW1tWayqGKOq1WgrGSzJwBgw5d/8i8ie4=; b=Xsau3hmmo/VyfvhKcxtkPEj933uhVagITtVP4hMG63jynXQTfyx2p9yhRF1zbYcwPn WG3t6M+h4zsoehvZR96PzmmERRty5NdULphJbIaCO0rVU/2I71bQgQ97I2hc9E8b6GPT G+Hv5If5PMzmqpB6sXVD04oEZ2zX28NoFOEEgHJXA26TSFjWrYMqPiYXDbederJfBpmg 8RBZMnVPB1sTEECJTvLvqN1mDiQGQxXUkaZOug08tMVr3KBZe4Yl2EKuqTqiBOQjt2Yy bDyvgd91IQuGppm/YOxDNF31KlbWzwetHszKrgGKtdLDrjIRHEAwN7c0U4fknzZz6LGG jSZA== X-Gm-Message-State: AD7BkJL/RSRBOUwJD14XB5uobdcHwWDvELS3q88JqyywEZzkpPBbLQTR3BSyb8V+/uUehA== X-Received: by 10.66.136.78 with SMTP id py14mr41240115pab.113.1459715309964; Sun, 03 Apr 2016 13:28:29 -0700 (PDT) Received: from ?IPv6:2406:e007:483d:1:28cc:dc4c:9703:6781? ([2406:e007:483d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u21sm34156044pfa.60.2016.04.03.13.28.27 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Apr 2016 13:28:28 -0700 (PDT) To: Enno Rey , v6ops@ietf.org References: <01905480-57D0-4F61-B68D-0B90EA428698@employees.org> <56CCA922.6020907@gmail.com> <85A832A3-24D3-4443-BD59-DD0D62E3B8C6@employees.org> <56CCAE04.6010308@gmail.com> <56D74640.2060502@gmail.com> <20160403091050.GB84794@ernw.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <57017CE9.1070003@gmail.com> Date: Mon, 4 Apr 2016 08:28:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160403091050.GB84794@ernw.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 20:28:32 -0000 On 03/04/2016 21:10, Enno Rey wrote: > Hi, > > On Thu, Mar 03, 2016 at 09:00:00AM +1300, Brian E Carpenter wrote: >> I'm sorry to distract the group with a practical question, but I'm a bit stumped. >> My question is below. >> >> In the thread "Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)", on >> 24/02/2016 08:07, Brian E Carpenter wrote: >>> On 24/02/2016 07:53, otroan@employees.org wrote: >>>>>> MLD joins for the solicited node multicast address has turned out to have little practical purpose. I am thinking of going the other way and stop sending joins for link-local multicast groups. >>>>> >>>>> Yes. What is the possible use of a link-local "join"? The packets are just there >>>>> on the link anyway, so "joining" is entirely an internal matter for each node. Of course, when I wrote that I completely overlooked the layer violation implemented on many switches. > I'd like to add that several MLD Querier implementations do not even store FF02:-scoped groups. > When we did some testing a while ago (details here: https://www.its.fh-muenster.de/doc/Security_Implications_of_MLD_in_IPv6_Networks.pdf) the Cisco router involved (running IOS 15.4.3) didn't show anything on "show ipv6 mld groups" even after (Win|Linux|BSD) on the local link had sent their reports for solicited-node. But did it actually forward the packets? Brian From nobody Sun Apr 3 13:42:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB3812D544 for ; Sun, 3 Apr 2016 13:42:25 -0700 (PDT) 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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1WFFtuHJxpY for ; Sun, 3 Apr 2016 13:42:23 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C85412D11D for ; Sun, 3 Apr 2016 13:42:22 -0700 (PDT) Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 775B915EC29 for ; Sun, 3 Apr 2016 22:42:20 +0200 (CEST) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 357294119B for ; Sun, 3 Apr 2016 22:42:20 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id F1AF88C44; Sun, 3 Apr 2016 22:42:19 +0200 (CEST) Date: Sun, 3 Apr 2016 22:42:19 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20160403204219.GA86847@ernw.de> References: <01905480-57D0-4F61-B68D-0B90EA428698@employees.org> <56CCA922.6020907@gmail.com> <85A832A3-24D3-4443-BD59-DD0D62E3B8C6@employees.org> <56CCAE04.6010308@gmail.com> <56D74640.2060502@gmail.com> <20160403091050.GB84794@ernw.de> <57017CE9.1070003@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57017CE9.1070003@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 20:42:25 -0000 Brian, On Mon, Apr 04, 2016 at 08:28:25AM +1200, Brian E Carpenter wrote: > On 03/04/2016 21:10, Enno Rey wrote: > > Hi, > > > > On Thu, Mar 03, 2016 at 09:00:00AM +1300, Brian E Carpenter wrote: > >> I'm sorry to distract the group with a practical question, but I'm a bit stumped. > >> My question is below. > >> > > > I'd like to add that several MLD Querier implementations do not even store FF02:-scoped groups. > > When we did some testing a while ago (details here: https://www.its.fh-muenster.de/doc/Security_Implications_of_MLD_in_IPv6_Networks.pdf) the Cisco router involved (running IOS 15.4.3) didn't show anything on "show ipv6 mld groups" even after (Win|Linux|BSD) on the local link had sent their reports for solicited-node. > > But did it actually forward the packets? > it did, at least where it was involved in inter-domain multicast forwarding (no need for a router to forward packets to solicited-node at any point or do I overlook sth here?). point is that draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node assumes/relies on the routers/MLD queriers actually knowing the solicited-node groups of the individual nodes on the adjacent link which might be a questionable assumption (which, admittedly, is discussed in Relaxed Mitigation Mode section). best Enno > Brian -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Sun Apr 3 15:25:02 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B422112D648 for ; Sun, 3 Apr 2016 15:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5iLb8OwreJB for ; Sun, 3 Apr 2016 15:24:59 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064D012D606 for ; Sun, 3 Apr 2016 15:24:59 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id c4so33902844vkb.3 for ; Sun, 03 Apr 2016 15:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=aWxxAOaL9H7jZ5OfrdwSAnyTnrnPTkMPm9nLzf2mYho=; b=coi2djf8i/rDB2r4dIwlD8aviad2jwWZg2YKr7WINc7Re6X9EWuJ6kvA7BimG+kAxE FkB2qj//xYmn+2NiFaCSlmPd1kAFuQO9/X2Rs7Re+NF7p5/g6jt8d94R2Zel5aOOKsrW zW2XrpPizbpIKq5LybLMnj9rAabwF4CjW3j9+YjSDHaAcFGRWs5n0ktByd8ygooyEpxu W24TtSnjlQ/g25A5FVog+4DEeg208KA9N67pH3eFO7U6/j01OEkyL/qUvP53IQJsyCKZ pcLYpu9CgQM89z48mblpKXSSuKliljfzKhfSkc0og82qFfQL0Bz2K7WA2WDpyNXb3kFc CB3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=aWxxAOaL9H7jZ5OfrdwSAnyTnrnPTkMPm9nLzf2mYho=; b=HURx6xzXaLkCHHuIAJIVCngz5vFFp7/+C0D7FYFMYLngPCIPnr1Y55LyGD/fX+iZhl 6GaTNbQc+8NUV5ERcIQ9OJqbjTxbJ8bcN+wntDNQ60G+AtJHLBix8u9+6de8FCbiftrl Fhx7GCvl8/HQycy1Bv4gCvTg9L7/DP6DpGUuCXRf5oc/Uemkt9umaVSfFWPv3uVgNg+N soz1zWZ1dMGJlSD2fBpOL+hjqmjYC8XUk3rh19hbuAOypelHbJdY1CpIECIup1GICFe6 w0lXPNo37XpxAd/f85zJERtttz4bzlo2DEsohQCRbni7KDfOa5UTG6IeVUXG3Rzgdn1P BhMA== X-Gm-Message-State: AD7BkJJQGqyFFjdqCo+QnA/e3NpoQC3LyTVU6Hj+PuN+CKSQOMwQPlnbKrNvqxV7/i3aRNw4SAAMCgTH/7oR/A== MIME-Version: 1.0 X-Received: by 10.31.48.216 with SMTP id w207mr517022vkw.36.1459722298080; Sun, 03 Apr 2016 15:24:58 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Sun, 3 Apr 2016 15:24:57 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Sun, 3 Apr 2016 15:24:57 -0700 (PDT) In-Reply-To: <20160403204219.GA86847@ernw.de> References: <01905480-57D0-4F61-B68D-0B90EA428698@employees.org> <56CCA922.6020907@gmail.com> <85A832A3-24D3-4443-BD59-DD0D62E3B8C6@employees.org> <56CCAE04.6010308@gmail.com> <56D74640.2060502@gmail.com> <20160403091050.GB84794@ernw.de> <57017CE9.1070003@gmail.com> <20160403204219.GA86847@ernw.de> Date: Mon, 4 Apr 2016 08:24:57 +1000 Message-ID: From: Mark Smith To: Enno Rey Content-Type: multipart/alternative; boundary=001a1143fd040c449f052f9c151a Archived-At: Cc: v6ops list Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 22:25:00 -0000 --001a1143fd040c449f052f9c151a Content-Type: text/plain; charset=UTF-8 Hi, On 4 Apr 2016 06:42, "Enno Rey" wrote: > > Brian, > > On Mon, Apr 04, 2016 at 08:28:25AM +1200, Brian E Carpenter wrote: > > On 03/04/2016 21:10, Enno Rey wrote: > > > Hi, > > > > > > On Thu, Mar 03, 2016 at 09:00:00AM +1300, Brian E Carpenter wrote: > > >> I'm sorry to distract the group with a practical question, but I'm a bit stumped. > > >> My question is below. > > >> > > > > > I'd like to add that several MLD Querier implementations do not even store FF02:-scoped groups. > > > When we did some testing a while ago (details here: https://www.its.fh-muenster.de/doc/Security_Implications_of_MLD_in_IPv6_Networks.pdf) the Cisco router involved (running IOS 15.4.3) didn't show anything on "show ipv6 mld groups" even after (Win|Linux|BSD) on the local link had sent their reports for solicited-node. > > > > But did it actually forward the packets? > > > > it did, at least where it was involved in inter-domain multicast forwarding (no need for a router to forward packets to solicited-node at any point or do I overlook sth here?). > point is that draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node assumes/relies on the routers/MLD queriers actually knowing the solicited-node groups of the individual nodes on the adjacent link which might be a questionable assumption So haven't come across anywhere where it permits MLD routers to ignore slctd Node group membership in MLD announcements, which is why I've said that MLD routers act as per RFC2710 or RFC3810 without modification to discover on link slctd node multicast groups (excepting that multicast forwarding doesn't need to be enabled) If they are ignoring them, they're actively choosing to, so if implementing what I've proposed, that bit of code would need to be disabled. (which, admittedly, is discussed in Relaxed Mitigation Mode section). > Relaxed Mitigation Mode is about tolerating listeners that don't send MLD for slctd Node groups, or for when MLD multicasts might not be reliable (although that might be a smaller problem than mcast ND NS or mcast RS and/or RA loss) Regards, Mark. > best > > Enno > > > > > > > > Brian > > -- > Enno Rey > > ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de > Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 > > Handelsregister Mannheim: HRB 337135 > Geschaeftsfuehrer: Enno Rey > > ======================================================= > Blog: www.insinuator.net || Conference: www.troopers.de > Twitter: @Enno_Insinuator > ======================================================= > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a1143fd040c449f052f9c151a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

On 4 Apr 2016 06:42, "Enno Rey" <erey@ernw.de> wrote:
>
> Brian,
>
> On Mon, Apr 04, 2016 at 08:28:25AM +1200, Brian E Carpenter wrote:
> > On 03/04/2016 21:10, Enno Rey wrote:
> > > Hi,
> > >
> > > On Thu, Mar 03, 2016 at 09:00:00AM +1300, Brian E Carpenter = wrote:
> > >> I'm sorry to distract the group with a practical que= stion, but I'm a bit stumped.
> > >> My question is below.
> > >>
> >
> > > I'd like to add that several MLD Querier implementations= do not even store FF02:-scoped groups.
> > > When we did some testing a while ago (details here: https://www.its.fh-muenster.de/doc/Security_Implications_of_= MLD_in_IPv6_Networks.pdf) the Cisco router involved (running IOS 15.4.3= ) didn't show anything on "show ipv6 mld groups" even after (= Win|Linux|BSD) on the local link had sent their reports for solicited-node.=
> >
> > But did it actually forward the packets?
> >
>
> it did, at least where it was involved in inter-domain multicast forwa= rding (no need for a router to forward packets to solicited-node at any poi= nt or do I overlook sth here?).
> point is that draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node assume= s/relies on the routers/MLD queriers actually knowing the solicited-node gr= oups of the individual nodes on the adjacent link which might be a question= able assumption

So haven't come across anywhere where it permits MLD rou= ters to ignore slctd Node group membership in MLD announcements, which is w= hy I've said that MLD routers act as per RFC2710 or RFC3810 without mod= ification to discover on link slctd node multicast groups (excepting that m= ulticast forwarding doesn't need to be enabled)

If they are ignoring them, they're actively choosing to,= so if implementing what I've proposed, that bit of code would need to = be disabled.

(which, admittedly, is discussed in Relaxed Mitigation Mode= section).
>

Relaxed Mitigation Mode is about tolerating listeners that d= on't send MLD for slctd Node groups, or for when MLD multicasts might n= ot be reliable (although that might be a smaller problem than mcast ND NS o= r mcast RS and/or RA loss)

Regards,
Mark.

> best
>
> Enno
>
>
>
>
>
>
> >=C2=A0 =C2=A0 =C2=A0Brian
>
> --
> Enno Rey
>
> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>
> Handelsregister Mannheim: HRB 337135
> Geschaeftsfuehrer: Enno Rey
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
> Blog: www.insinuator.net || = Conference: www.troopers.de
> Twitter: @Enno_Insinuator
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a1143fd040c449f052f9c151a-- From nobody Mon Apr 4 09:51:48 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA6D12D7C7 for ; Mon, 4 Apr 2016 09:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2C749hMLYY4 for ; Mon, 4 Apr 2016 09:51:42 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881BE12D7B7 for ; Mon, 4 Apr 2016 09:51:42 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id i4so64801464qkc.3 for ; Mon, 04 Apr 2016 09:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=LT2PGcfmE9YtzVMMcFxKy7o88nclRy2Ol4uyX+5Dpyk=; b=i9l6pRrXM0szILGRFTSIoDMgERX+yGAyQIzWy5FTEAsLbJlvweJfMEjoQ6X+fBL4q9 HbqEDpiFMmsRCk18Viw+xDujYmPTLbb26yM5aWycEo0wo9NYsfCo0xs2DPjpRUa0hlDi ThRat7xWKiQu/hYmOrUSNW1PrsF3LVKMCDhUEbEqOzl5+k0y6aasna95Zc5WGMJA39BV V7lkGDI0/jiNJ0Oz3h74DSmB77EveNGk36xExcBY4eYmCgaVEQHfJ9sb1IbTwjM1bqiX nSqJMnCQfIWx5VXNXbZymVFN3lQ0lilmBP2Q89Jvk4QGh6Rg0o0nhqdTVfr1BD9IhfjI 9jRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=LT2PGcfmE9YtzVMMcFxKy7o88nclRy2Ol4uyX+5Dpyk=; b=iQe+mszERTPNPntRqdK8IRYHTnyjhLtDIUJoTFWqTbfQkzbggi+UUBcOGiLkPgus2Z k83S1DMJ+GWM+ecURmMhbZ6GeurqYFdznTnuIOFQaUiNTayY14ypewQP+u8dBT2BiOb/ W+7Q8JVaOB+MhoUw5VM/i+zab4AQFUICqQxLJecqxxWnh/yIk7fDXF7hQA7Es6mR13La 7GAXqPjAMSOsR1M5s1g9W5DSuAlNDGQ51hXDqWn62owqCwysA9OrSt4ueuivlP0DYtBq BgiDZ12ibFypqc86KesBoiJdYJM60OoLhXDLm3VaRX9iCk5YhAi5cMZKkS9I7lQh/kxq GYFw== X-Gm-Message-State: AD7BkJIEAmKnDtU2EBvHirqdGh6UN3kn3t9P0ChjSlXFpzNlYIU8bOPEAJVn3ZtAEPN4Yw== X-Received: by 10.55.74.14 with SMTP id x14mr35534193qka.70.1459788701653; Mon, 04 Apr 2016 09:51:41 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:c547:e845:1149:6d19? ([2001:67c:370:176:c547:e845:1149:6d19]) by smtp.googlemail.com with ESMTPSA id v65sm12590350qhc.6.2016.04.04.09.51.40 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2016 09:51:40 -0700 (PDT) To: v6ops@ietf.org References: From: Alejandro Acosta Message-ID: <57029B98.7050100@gmail.com> Date: Mon, 4 Apr 2016 12:21:36 -0430 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Jabber room X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 16:51:45 -0000 I can do this. Alejandro, El 4/1/2016 a las 7:48 PM, Howard, Lee escribió: > As a way of encouraging participation, the chairs would like to point out > that all WGs have an associated Jabber room, in our case > v6ops@jabber.ietf.org > > As an experiment, it would be good to know that people with good language > skills are in the Jabber room, to help out when a speaker uses slang or an > unfamiliar word in English. Since wečre in Buenos Aires, Spanish and > English would be especially useful. > > As always, wečre also looking for a Jabber scribe, who will let remote > participants know as slides change, and can relay comments from the Jabber > room to the physical room. Any volunteers? > > More information on the use of Jabber at IETF is at > https://www.ietf.org/jabber/ > > More information on Jabber scribing at https://tools.ietf.org/html/rfc7649 > Thanks, > > Lee > > > ________________________________ > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Apr 4 11:51:29 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE71212D7E8 for ; Mon, 4 Apr 2016 11:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7ezR-J6Q4Y3 for ; Mon, 4 Apr 2016 11:51:25 -0700 (PDT) Received: from cdpipgw01.twcable.com (unknown [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id A5CAA12D7F9 for ; Mon, 4 Apr 2016 11:51:21 -0700 (PDT) X-SENDER-IP: 10.64.163.161 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.24,441,1454994000"; d="scan'208";a="1240952537" Received: from unknown (HELO exchpapp20.corp.twcable.com) ([10.64.163.161]) by cdpipgw01.twcable.com with ESMTP/TLS/AES256-SHA; 04 Apr 2016 14:49:28 -0400 Received: from EXCHPAPP15.corp.twcable.com (10.64.163.156) by exchpapp20.corp.twcable.com (10.64.163.161) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 4 Apr 2016 14:51:19 -0400 Received: from EXCHPAPP15.corp.twcable.com ([10.245.162.20]) by exchpapp15.corp.twcable.com ([10.245.162.20]) with mapi id 15.00.1156.000; Mon, 4 Apr 2016 14:51:19 -0400 From: "Howard, Lee" To: 'IPv6 Operations' Thread-Topic: reminder: no session tomorrow Thread-Index: AQHRjqL59Icd38QhQEa+ggJg7LeY+Q== Date: Mon, 4 Apr 2016 18:51:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.163.240] x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22238.004 x-tm-as-result: No--33.185400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [v6ops] reminder: no session tomorrow X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:51:26 -0000 Based on our small number of agenda items, v6ops has completed its face to face meeting for the week. We encourage further discussion on the mailing list. Lee ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nobody Mon Apr 4 14:37:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD11812D1AA for ; Mon, 4 Apr 2016 14:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_-4sM8nw4GG for ; Mon, 4 Apr 2016 14:37:20 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37DEE12D14A for ; Mon, 4 Apr 2016 14:37:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0CC33A2; Mon, 4 Apr 2016 23:37:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1459805838; bh=gGlYHDEzQNxpT3FZlrsOAUFGz32Hj51Lyk7kB/+nvjk=; h=Date:From:To:Subject:From; b=yyC0KqE0iWGlnY8pyLUoMFy0egAvPkRcQJOe2LGMoqsIkARGbBkEEsQYilh+F5Atd fEkcWmpDMSZVPB7e6QrFZGgVeJVA4TjoCdPrgzbRLVuyvfpQFtBO7BNz5rG2ECNLrE +09/fmpszgDa0cOL6HV8B7TF0oxqjsIsFDIXHrRQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 03E4AA1 for ; Mon, 4 Apr 2016 23:37:18 +0200 (CEST) Date: Mon, 4 Apr 2016 23:37:17 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [v6ops] draft-van-beijnum-multi-mtu-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 21:37:22 -0000 Hi, I'll be presenting https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 in 6man on Wednesday. There are operational considerations here, so I encourage people to drop in and/or comment on this draft. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Apr 5 05:13:56 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FC212D536 for ; Tue, 5 Apr 2016 05:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT29ucgF6DFS for ; Tue, 5 Apr 2016 05:13:52 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DA012D1CC for ; Tue, 5 Apr 2016 05:13:50 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u35CDko4031803 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2016 13:13:47 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local Message-ID: <5703ABF9.2000907@foobar.org> Date: Tue, 05 Apr 2016 13:13:45 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Mikael Abrahamsson References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-van-beijnum-multi-mtu-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 12:13:55 -0000 Mikael Abrahamsson wrote: > I'll be presenting > https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 in 6man on > Wednesday. There are operational considerations here, so I encourage > people to drop in and/or comment on this draft. I'm pretty sure the added complication of what's suggested in this draft is not going to make ipv6 networking either better or easier. Sometimes worse is better. Nick From nobody Tue Apr 5 06:01:31 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3FD12D5D6 for ; Tue, 5 Apr 2016 06:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wapmd0nnPtDH for ; Tue, 5 Apr 2016 06:01:27 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0597012D681 for ; Tue, 5 Apr 2016 06:01:26 -0700 (PDT) Received: from dhcp-b257.meeting.ietf.org ([IPv6:2001:67c:370:176:a1e9:33d0:3819:48]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u35D1J6E093568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 Apr 2016 13:01:21 GMT (envelope-from joelja@bogus.com) To: otroan@employees.org, Mark Smith References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org> From: joel jaeggli Message-ID: <91a3ea5b-f12b-f1b1-d0e1-885faa2d1e90@bogus.com> Date: Tue, 5 Apr 2016 10:01:18 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2kDiRkpPm2wgqDt802qCKVhcGH04T1qcn" Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 13:01:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2kDiRkpPm2wgqDt802qCKVhcGH04T1qcn Content-Type: multipart/mixed; boundary="nVS3utRgpLrdcMH29FM73qvd5d7aAurjw" From: joel jaeggli To: otroan@employees.org, Mark Smith Cc: v6ops list Message-ID: <91a3ea5b-f12b-f1b1-d0e1-885faa2d1e90@bogus.com> Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org> In-Reply-To: <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org> --nVS3utRgpLrdcMH29FM73qvd5d7aAurjw Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/29/16 6:51 AM, otroan@employees.org wrote: >>>>> Yes. It's a bug in RFC2460 that this ambiguity arises. >>>>=20 >>>> I took it as a feature. IMO, the idea of a chain enables this >>>> feature, and I don't think it should be so quickly dismissed as >>>> potentially useful. >>>>=20 >>>> I appreciate that not everyone agrees, though. >>>=20 >>> It does break PMTUD though. >>>=20 >>=20 >> Which I think is because of an expectation that the device >> identified in the packet source address (the "sender") is >> responsible for creating the whole packet. It can't be a "unicast >> source address" field if there are multiple sources of the >> information in the packet. >>=20 >> It also breaks troubleshooting methods and assumptions about the >> source address field that have been true for IPv6, IPv4 and many, >> if not all, past layer 3 protocols. >>=20 >> One perspective on tunneling is that when it modifies the packet, >> it adds another source address field to record that another device, >> other than the original packet source device, has made additions to >> the packet. Encapsulation does not alter the wrapped packet, except perhaps by decreasing the ttl. > indeed, and is why 2460 bis states: "Extension headers must never be > inserted by any node other than the source of the packet. IP > Encapsulation must be used to meet any requirement for inserting > headers, for example, as defined in [RFC2473]." >=20 > cheers, Ole >=20 >=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 --nVS3utRgpLrdcMH29FM73qvd5d7aAurjw-- --2kDiRkpPm2wgqDt802qCKVhcGH04T1qcn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlcDtx4ACgkQ8AA1q7Z/VrJ4IQCeM1xuN80YQijqYpxf4eTpc/O7 BwAAnA599eMIB2DyjOuNz4cl2bnE+6U0 =VB5l -----END PGP SIGNATURE----- --2kDiRkpPm2wgqDt802qCKVhcGH04T1qcn-- From nobody Tue Apr 5 10:00:21 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450DF12D7C2 for ; Tue, 5 Apr 2016 10:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jv6Jiq9sTNYT for ; Tue, 5 Apr 2016 10:00:17 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6030E12D70F for ; Tue, 5 Apr 2016 10:00:17 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id c4so25752279vkb.3 for ; Tue, 05 Apr 2016 10:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=GqqqCp/9ctGJ61Aza6QH2Q/sqfdkvfEsMZpP5WCPI7U=; b=r0oVO+1QLUJE60kA62E598OMiZ8Un7cgiGP0bGfFaGCYjG2zjgptVJsWpQzl9vUQgq f0hwS59B4LAADeCKGkFgkc2khlcc3Vj98AJQpSuyud4lWQMKZaJEv6hJ66sAm6xJhPd0 A8OPFgem76s/R3sT4zH0x+J4TJOfmitx92YQ1uwBQoi6TwkSYXsnUrD10oZ8/NCHepVX Ln7svJpEi4gYa04SNXGvI4ibBE8o++BMLbvBVbNIkPuU9vZSZZUFBo2mlWi2lZVOZOCq V5725Jh9mOz4CUe7Z+4NOGuUc9n7MStRTplTsiAvZYLFSOqShMKV8tJlBgzk93iU2z64 SONQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=GqqqCp/9ctGJ61Aza6QH2Q/sqfdkvfEsMZpP5WCPI7U=; b=Q93ngWiTZNrrIiM89ZQKoeuPzWLajYkm7mMxm1gZOpAlFh/VoiYcfMb+XVQJ7npzjm 3nBYn2/dmtn0d0cigV8+9cSox8axihO/3dWA3c42wA3PcSAIv8pb1eW7hxOoaKmZcOqx LQFDKxqhB3cPy4RcWxi3OzE6E2/cmRk2AWtdGVBEepwXx+Bq5RlXnKgadaFLc4T/lIhP Io6n9GMpZxcpfJTGN9Q3SixEAbV+lmYZThirZJGECvJAH+25jJvmfCXYoUK47UR2nFj4 lkm2jljtJLuzYfc34tWq0cNEmGbmY7OKPFHdpGDnCoTlpJWxMrwehcinKC+GNq2QdxYj 9mBw== X-Gm-Message-State: AD7BkJJpuRCUjgu4yRU9eDh5887gmXfxw3vEZpcFEZ+wNYnzRHEMMPqc7EWcoLaevJsHn5RIjDW5kTr3ew6uGA== MIME-Version: 1.0 X-Received: by 10.31.48.216 with SMTP id w207mr5898561vkw.36.1459875616455; Tue, 05 Apr 2016 10:00:16 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Tue, 5 Apr 2016 10:00:16 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Tue, 5 Apr 2016 10:00:16 -0700 (PDT) In-Reply-To: <91a3ea5b-f12b-f1b1-d0e1-885faa2d1e90@bogus.com> References: <566C93D0-62FF-4700-BC05-7F9AF12AF1BD@employees.org> <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org> <91a3ea5b-f12b-f1b1-d0e1-885faa2d1e90@bogus.com> Date: Wed, 6 Apr 2016 03:00:16 +1000 Message-ID: From: Mark Smith To: joel jaeggli Content-Type: multipart/alternative; boundary=001a1143fd0489005a052fbfc779 Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:00:19 -0000 --001a1143fd0489005a052fbfc779 Content-Type: text/plain; charset=UTF-8 On 5 Apr 2016 11:01 PM, "joel jaeggli" wrote: > > On 3/29/16 6:51 AM, otroan@employees.org wrote: > >>>>> Yes. It's a bug in RFC2460 that this ambiguity arises. > >>>> > >>>> I took it as a feature. IMO, the idea of a chain enables this > >>>> feature, and I don't think it should be so quickly dismissed as > >>>> potentially useful. > >>>> > >>>> I appreciate that not everyone agrees, though. > >>> > >>> It does break PMTUD though. > >>> > >> > >> Which I think is because of an expectation that the device > >> identified in the packet source address (the "sender") is > >> responsible for creating the whole packet. It can't be a "unicast > >> source address" field if there are multiple sources of the > >> information in the packet. > >> > >> It also breaks troubleshooting methods and assumptions about the > >> source address field that have been true for IPv6, IPv4 and many, > >> if not all, past layer 3 protocols. > >> > >> One perspective on tunneling is that when it modifies the packet, > >> it adds another source address field to record that another device, > >> other than the original packet source device, has made additions to > >> the packet. > > Encapsulation does not alter the wrapped packet, except perhaps by > decreasing the ttl. > I agree, I was using "modified" in the sense that if you don't consider what layers these actions are taking place, the packet originally sent has been modified compared to after it has been encapsulated. The thing about tunneling though is what and by whom it was added is clear and unambiguous because of encapsulation. Adding, deleting or changing EHs in the network would be silent about who made the changes (except when modification records who did the change e.g. RH0). In this case the packet source address has lost its much of its clarity, because there are now multiple sources of the information in the packet. Regards, Mark. > > indeed, and is why 2460 bis states: "Extension headers must never be > > inserted by any node other than the source of the packet. IP > > Encapsulation must be used to meet any requirement for inserting > > headers, for example, as defined in [RFC2473]." > > > > cheers, Ole > > > > > > > > _______________________________________________ v6ops mailing list > > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > --001a1143fd0489005a052fbfc779 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 5 Apr 2016 11:01 PM, "joel jaeggli" <joelja@bogus.com> wrote:
>
> On 3/29/16 6:51 AM, otroan@emp= loyees.org wrote:
> >>>>> Yes. It's a bug in RFC2460 that this ambiguit= y arises.
> >>>>
> >>>> I took it as a feature. IMO, the idea of a chain enab= les this
> >>>> feature, and I don't think it should be so quickl= y dismissed as
> >>>> potentially useful.
> >>>>
> >>>> I appreciate that not everyone agrees, though.
> >>>
> >>> It does break PMTUD though.
> >>>
> >>
> >> Which I think is because of an expectation that the device > >> identified in the packet source address (the "sender&quo= t;) is
> >> responsible for creating the whole packet. It can't be a = "unicast
> >> source address" field if there are multiple sources of t= he
> >> information in the packet.
> >>
> >> It also breaks troubleshooting methods and assumptions about = the
> >> source address field that have been true for IPv6, IPv4 and m= any,
> >> if not all, past layer 3 protocols.
> >>
> >> One perspective on tunneling is that when it modifies the pac= ket,
> >> it adds another source address field to record that another d= evice,
> >> other than the original packet source device, has made additi= ons to
> >> the packet.
>
> Encapsulation does not alter the wrapped packet, except perhaps by
> decreasing the ttl.
>

I agree, I was using "modified" in the sense that = if you don't consider what layers these actions are taking place, the p= acket originally sent has been modified compared to after it has been encap= sulated. The thing about tunneling though is what and by whom it was added = is clear and unambiguous because of encapsulation.

Adding, deleting or changing EHs in the network would be sil= ent about who made the changes (except when modification records who did th= e change e.g. RH0). In this case the packet source address has lost its muc= h of its clarity, because there are now multiple sources of the information= in the packet.

Regards,
Mark.

> > indeed, and is why 2460 bis states: "Extensio= n headers must never be
> > inserted by any node other than the source of the packet.=C2=A0 I= P
> > Encapsulation must be used to meet any requirement for inserting<= br> > > headers, for example, as defined in [RFC2473]."
> >
> > cheers, Ole
> >
> >
> >
> > _______________________________________________ v6ops mailing lis= t
> > v6ops@ietf.org https://www.ietf.org/mailman/li= stinfo/v6ops
> >
>
>

--001a1143fd0489005a052fbfc779-- From nobody Tue Apr 5 10:41:06 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C0912D901 for ; Tue, 5 Apr 2016 10:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de-c74LYUX48 for ; Tue, 5 Apr 2016 10:41:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A8212D53D for ; Tue, 5 Apr 2016 10:41:00 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u35HejMh023309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 Apr 2016 10:40:46 -0700 (PDT) To: Mark Smith , joel jaeggli References: <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org> <91a3ea5b-f12b-f1b1-d0e1-885faa2d1e90@bogus.com> From: Joe Touch Message-ID: <5703F89D.3080203@isi.edu> Date: Tue, 5 Apr 2016 10:40:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:41:01 -0000 On 4/5/2016 10:00 AM, Mark Smith wrote: > Adding, deleting or changing EHs in the network would be silent about > who made the changes (except when modification records who did the > change e.g. RH0). In this case the packet source address has lost its > much of its clarity, because there are now multiple sources of the > information in the packet. Given the pervasive presence of NAT and other header rewriting devices, there are already many such sources. Unless the header is authenticated, there are no assurances as to exactly where the information therein originated. Joe From nobody Tue Apr 5 20:41:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A534F12D712 for ; Tue, 5 Apr 2016 20:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th_oU-TKFzzF for ; Tue, 5 Apr 2016 20:41:20 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BD812D704 for ; Tue, 5 Apr 2016 20:41:20 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id k1so43096107vkb.0 for ; Tue, 05 Apr 2016 20:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8WBzeJ01dsYJ+9BW6vxowkHxYhxqFphHFXiARKmP3Xk=; b=V2tVG49Yw6GD2OyPGPk+fH79drfG9pvaCz872xnKi/mYZXJFa/pcbfF4zdkRtb43bZ ZHvpzUyMIFOwNXMF6iDJ9R7wQAo94KSbK/krshBnpuiUzx9cOKsbrCaY0akFECqaVwzH 5D6ORnvecaaBUbSMxXFCl6zivU1C50xZQQTmT1+ssFzow6+PE60DRucbsCBx71lFLAHC hgts5MiByBWdN4+lmjOLhRpQzJnK/qkZy+fbqjxQOSF0nI/9JAb1FkUfANWhclSAvp+R 9OpyjeFj3jGDzG2M5hYlRciBUKz8W7ChE8LMQYSG9Tx2FWsh/tyU/dc6TGeLaijSxmVr NcJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8WBzeJ01dsYJ+9BW6vxowkHxYhxqFphHFXiARKmP3Xk=; b=EiH3neyW3GHd/7AtEL4gEX03AVBJHcSqg2UhtouY8/7xz/arWx6xbVy19hW4MUS6RL hjNf+39/xzXL4RQFWFFPsau2bTnLHK+oRWiV1kW8wfwFwSQ6bZXkNgR2dtyKDxK1lg1M i+KvKHlz2Dc2SytXNjIEHmP8xB4sSKEqNSe3hLWDq0huueiJn82oqcmmcflHPsTFKxQn Ez5lIco2Hp4Z7RVGCuAoUETxJHUepTheddY8eJXNwg4UWaAFe8eVcwFCqt/9/UORRsjp zoB1zyW5Ryr2BHF1WYVhz3RLqB2tsr++2FpA2puHi433+G0F0/bif/wZ+eRPlYzFICT/ 8m0Q== X-Gm-Message-State: AD7BkJKcUIdT3t4OGTRurJOUZeR3ulzCWhUPjSEM9jes8ZNNxMRia6fwShEXgVu8KeRgDDtfxveGZwiEHmqTPQ== MIME-Version: 1.0 X-Received: by 10.176.65.33 with SMTP id j30mr11541048uad.142.1459914079344; Tue, 05 Apr 2016 20:41:19 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Tue, 5 Apr 2016 20:41:19 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Tue, 5 Apr 2016 20:41:19 -0700 (PDT) In-Reply-To: <5703F89D.3080203@isi.edu> References: <56E892B8.9030902@foobar.org> <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org> <91a3ea5b-f12b-f1b1-d0e1-885faa2d1e90@bogus.com> <5703F89D.3080203@isi.edu> Date: Wed, 6 Apr 2016 13:41:19 +1000 Message-ID: From: Mark Smith To: Joe Touch Content-Type: multipart/alternative; boundary=94eb2c1246441a20eb052fc8bcc6 Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 03:41:21 -0000 --94eb2c1246441a20eb052fc8bcc6 Content-Type: text/plain; charset=UTF-8 On 6 Apr 2016 3:40 AM, "Joe Touch" wrote: > > > > On 4/5/2016 10:00 AM, Mark Smith wrote: > > Adding, deleting or changing EHs in the network would be silent about > > who made the changes (except when modification records who did the > > change e.g. RH0). In this case the packet source address has lost its > > much of its clarity, because there are now multiple sources of the > > information in the packet. > > Given the pervasive presence of NAT Not in the IPv6 Internet yet I hope. and other header rewriting devices, > there are already many such sources. Unless the header is authenticated, > there are no assurances as to exactly where the information therein > originated. > So that sounds a bit like an argument that if the IP packet is not authenticated, then devices processing them don't have to respect the protocols at all, because there is nothing to prevent the changes being detected. Regards, Mark. > Joe --94eb2c1246441a20eb052fc8bcc6 Content-Type: text/html; charset=UTF-8


On 6 Apr 2016 3:40 AM, "Joe Touch" <touch@isi.edu> wrote:
>
>
>
> On 4/5/2016 10:00 AM, Mark Smith wrote:
> > Adding, deleting or changing EHs in the network would be silent about
> > who made the changes (except when modification records who did the
> > change e.g. RH0). In this case the packet source address has lost its
> > much of its clarity, because there are now multiple sources of the
> > information in the packet.
>
> Given the pervasive presence of NAT

Not in the IPv6 Internet yet I hope.

and other header rewriting devices,
> there are already many such sources. Unless the header is authenticated,
> there are no assurances as to exactly where the information therein
> originated.
>

So that sounds a bit like an argument that if the IP packet is not authenticated, then devices processing them don't have to respect the protocols at all, because there is nothing to prevent the changes being detected.

Regards,
Mark.

> Joe

--94eb2c1246441a20eb052fc8bcc6-- From nobody Wed Apr 6 02:54:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C26B12D160 for ; Wed, 6 Apr 2016 02:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnLFcR_DJ0z5 for ; Wed, 6 Apr 2016 02:54:30 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 290FA12D14F for ; Wed, 6 Apr 2016 02:54:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AC58D4033A; Wed, 6 Apr 2016 11:54:28 +0200 (CEST) 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 aiZvA42jnWly; Wed, 6 Apr 2016 11:54:26 +0200 (CEST) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C2A534032B; Wed, 6 Apr 2016 11:54:25 +0200 (CEST) Message-ID: <5704DCD0.1090907@globis.net> Date: Wed, 06 Apr 2016 11:54:24 +0200 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Joe Touch References: <394925FE-FAB1-4FFC-B1CF-4F64CC58F613@employees.org> <56E94275.20700@foobar.org> <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org> <91a3ea5b-f12b-f1b1-d0e1-885faa2d1e90@bogus.com> <5703F89D.3080203@isi.edu> In-Reply-To: <5703F89D.3080203@isi.edu> Content-Type: multipart/alternative; boundary="------------040105060208030706000400" Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 09:54:32 -0000 This is a multi-part message in MIME format. --------------040105060208030706000400 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Joe Touch wrote: > On 4/5/2016 10:00 AM, Mark Smith wrote: >> Adding, deleting or changing EHs in the network would be silent about >> who made the changes (except when modification records who did the >> change e.g. RH0). In this case the packet source address has lost its >> much of its clarity, because there are now multiple sources of the >> information in the packet. > > Given the pervasive presence of NAT and other header rewriting devices, > there are already many such sources. Unless the header is authenticated, > there are no assurances as to exactly where the information therein > originated. > > Joe > > NAT is not pervasively present in IPv6 networks, so that's not really relevant to the discussion. The outer packet headers can't be fully invariant end to end, because some fields have to/ may be rewritten along the path, even in normal operations e.g. HBH options, flow label, and hop count. So any protection of header content would have to be very limited in scope. But even authenticated headers get messed around, so that's also no solution in and of itself. Look at the hoops that people have to jump through (both technical and legal) to make https and other strong end to end transports work over NAT and proxies. IMHO the end to end principle is still worth fighting for. But IMVHO another consequence of the end to end principle is that if you want end to end protection, you'd better do it yourself, at a layer you control, and not rely on any underlying infra to guarantee it for you. On a routed network, there's always a man in the middle. So you can never trust headers in the general case, even if they're authenticated. Whilst the end to end principle itself doesn't preclude in-flight deep-packet-inspection (where appropriate/legally justified/technically possible). [Note: Your lawyers may disagree. You may be subject to different laws.] -- regards, RayH --------------040105060208030706000400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Joe Touch wrote:
On 4/5/2016 10:00 AM, Mark Smith wrote:

Adding, deleting or changing EHs in the network would be silent about
who made the changes (except when modification records who did the
change e.g. RH0). In this case the packet source address has lost its
much of its clarity, because there are now multiple sources of the
information in the packet.


Given the pervasive presence of NAT and other header rewriting devices,
there are already many such sources. Unless the header is authenticated,
there are no assurances as to exactly where the information therein
originated.

Joe
NAT is not pervasively present in IPv6 networks, so that's not really relevant to the discussion.

The outer packet headers can't be fully invariant end to end, because some fields have to/ may be rewritten along the path, even in normal operations e.g. HBH options, flow label, and hop count. So any protection of header content would have to be very limited in scope.

But even authenticated headers get messed around, so that's also no solution in and of itself.  Look at the hoops that people have to jump through (both technical and legal) to make https and other strong end to end transports work over NAT and proxies.

IMHO the end to end principle is still worth fighting for.

But IMVHO another consequence of the end to end principle is that if you want end to end protection, you'd better do it yourself, at a layer you control, and not rely on any underlying infra to guarantee it for you. On a routed network, there's always a man in the middle. So you can never trust headers in the general case, even if they're authenticated.

Whilst the end to end principle itself doesn't preclude in-flight deep-packet-inspection (where appropriate/legally justified/technically possible). [Note: Your lawyers may disagree. You may be subject to different laws.]

--
regards,
RayH
--------------040105060208030706000400-- From nobody Wed Apr 6 08:31:50 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DD112D09F for ; Wed, 6 Apr 2016 08:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTDhPIhPBpdX for ; Wed, 6 Apr 2016 08:31:46 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969B512D0AC for ; Wed, 6 Apr 2016 08:31:45 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A6C2C6365C for ; Wed, 6 Apr 2016 17:31:42 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [195.30.0.251]) by mobil.space.net (Postfix) with ESMTP id 6576D63649; Wed, 6 Apr 2016 17:31:42 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 544A820A3D; Wed, 6 Apr 2016 17:31:42 +0200 (CEST) Date: Wed, 6 Apr 2016 17:31:42 +0200 From: Gert Doering To: Nick Hilliard Message-ID: <20160406153142.GU56633@Space.Net> References: <5703ABF9.2000907@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5703ABF9.2000907@foobar.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-van-beijnum-multi-mtu-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:31:49 -0000 Hi, On Tue, Apr 05, 2016 at 01:13:45PM +0100, Nick Hilliard wrote: > Mikael Abrahamsson wrote: > > I'll be presenting > > https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-05 in 6man on > > Wednesday. There are operational considerations here, so I encourage > > people to drop in and/or comment on this draft. > > I'm pretty sure the added complication of what's suggested in this draft > is not going to make ipv6 networking either better or easier. > > Sometimes worse is better. I totally see this as being great fun for IXP routers. The draft really only seems to be talking about end-system talking to each other, but for routers, it's quite a bit more complex. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Apr 6 09:09:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3BC12D559 for ; Wed, 6 Apr 2016 09:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G-JGSF9RWjs for ; Wed, 6 Apr 2016 09:09:54 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EED312D524 for ; Wed, 6 Apr 2016 09:09:52 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u36G9nou084444 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2016 17:09:49 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local Message-ID: <570534CC.3020603@foobar.org> Date: Wed, 06 Apr 2016 17:09:48 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Gert Doering References: <5703ABF9.2000907@foobar.org> <20160406153142.GU56633@Space.Net> In-Reply-To: <20160406153142.GU56633@Space.Net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-van-beijnum-multi-mtu-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 16:09:56 -0000 Gert Doering wrote: > I totally see this as being great fun for IXP routers. > > The draft really only seems to be talking about end-system talking to > each other, but for routers, it's quite a bit more complex. it's not just IXPs routers: the protocol adds failure modes at the bottom of the protocol stack, some of which will end up with packets being blackholed. Operationally, it's a good idea to avoid situations like this: apart from trashing connectivity, problems relating to network layer blackholes are troublesome to debug and fix. Maybe it would have been different if this idea had been suggested in 1996, but it's 20 years since ipv6 was first deployed and I'm not convinced that the use case is sufficient to justify digging out the foundations of the protocol, particularly when RA already supports a per-broadcast-domain dynamic MTU option anyway. Nick From nobody Wed Apr 6 10:26:05 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB1012D6DC for ; Wed, 6 Apr 2016 10:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0qmPhyEur-E for ; Wed, 6 Apr 2016 10:25:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9DF12D6D1 for ; Wed, 6 Apr 2016 10:25:45 -0700 (PDT) Received: from [128.9.184.182] ([128.9.184.182]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u36HP5Xv005057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Apr 2016 10:25:06 -0700 (PDT) To: Mark Smith References: <3AE1DE20-D735-4262-A3FB-7C01F30BAFA2@employees.org> <56E96F74.7000206@foobar.org> <56E98086.5040209@foobar.org> <20160328183844.GR62900@Space.Net> <56F9A22B.2030301@isi.edu> <5E619124-0A60-45BB-86AA-7F7D5CC614AD@cisco.com> <56F9AE53.8060903@gmail.com> <56F9BEA3.9050409@isi.edu> <4542AA33-F4FA-4F52-B5FE-9ABF2627CD5E@cisco.com> <56F9C856.2030403@gmail.com> <56F9C915.9070408@isi.edu> <47A7C6D0-9DCA-4FE3-9CBF-8A9101D48763@employees.org> <91a3ea5b-f12b-f1b1-d0e1-885faa2d1e90@bogus.com> <5703F89D.3080203@isi.edu> From: Joe Touch Message-ID: <5705466F.4030306@isi.edu> Date: Wed, 6 Apr 2016 10:25:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:25:58 -0000 On 4/5/2016 8:41 PM, Mark Smith wrote: >> Unless the header is authenticated, >> there are no assurances as to exactly where the information therein >> originated. > > So that sounds a bit like an argument that if the IP packet is not > authenticated, then devices processing them don't have to respect the > protocols at all, because there is nothing to prevent the changes being > detected. It means there are no assurances. That does not mean that intermediate devices have no rules or consequences - it means that the receiver cannot *assume* otherwise. Joe From nobody Wed Apr 6 10:38:35 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC71912D0F3 for ; Wed, 6 Apr 2016 10:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sy8R1typrOxR for ; Wed, 6 Apr 2016 10:38:31 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D1512D51E for ; Wed, 6 Apr 2016 10:38:31 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D46E2A2; Wed, 6 Apr 2016 19:38:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1459964308; bh=Z0jLQrgNEUorvU5GoBdN62S9Gc8+qQ01LU3zNBHxgfA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=I+V5AE9KaycOiCcOVPJxqxpXikn3r1vhjeZjXaXiQi5JDMI4eoW2DaMNjzHtZmK6g u2Ja5wMlfQiOZz4tCB3nfPazI6vXL4kOr14139MQt/ixxv5mDsw5ewVf71AIbMu16u 0fhXq6H2+WgL8DdT5rPtPJLc5WjxOgKsBvF8cQCc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D093EA1; Wed, 6 Apr 2016 19:38:28 +0200 (CEST) Date: Wed, 6 Apr 2016 19:38:28 +0200 (CEST) From: Mikael Abrahamsson To: Nick Hilliard In-Reply-To: <570534CC.3020603@foobar.org> Message-ID: References: <5703ABF9.2000907@foobar.org> <20160406153142.GU56633@Space.Net> <570534CC.3020603@foobar.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-van-beijnum-multi-mtu-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:38:34 -0000 On Wed, 6 Apr 2016, Nick Hilliard wrote: > foundations of the protocol, particularly when RA already supports a > per-broadcast-domain dynamic MTU option anyway. That option is mostly just useful for lowering the MTU from 1500 to something lower, not raising it... -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Apr 7 05:00:19 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E82912D0C6 for ; Thu, 7 Apr 2016 05:00:17 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZabs8401nhS for ; Thu, 7 Apr 2016 05:00:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 2604E12D6D9 for ; Thu, 7 Apr 2016 05:00:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1ao8bQ-0000EdC; Thu, 7 Apr 2016 14:00:00 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <5703ABF9.2000907@foobar.org> <20160406153142.GU56633@Space.Net> <570534CC.3020603@foobar.org> In-reply-to: Your message of "Wed, 06 Apr 2016 17:09:48 +0100 ." <570534CC.3020603@foobar.org> Date: Thu, 07 Apr 2016 14:00:00 +0200 Archived-At: Subject: Re: [v6ops] draft-van-beijnum-multi-mtu-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:00:17 -0000 >Gert Doering wrote: >> I totally see this as being great fun for IXP routers. >> >> The draft really only seems to be talking about end-system talking to >> each other, but for routers, it's quite a bit more complex. > >it's not just IXPs routers: the protocol adds failure modes at the >bottom of the protocol stack, some of which will end up with packets >being blackholed. Operationally, it's a good idea to avoid situations >like this: apart from trashing connectivity, problems relating to >network layer blackholes are troublesome to debug and fix. Assuming two nodes (hosts or routers) have announced such a larger MTU. And they have verified (using ICMP, or whatever) that is is actually possible to exchange packets at a bigger MTU. Then what problems do you expect in todays networks? Do you expect bridges to corrupt packets even though the test packet work out. (And is a there a class of devices known to do this) Do you expect a spanning tree protocol to pick a route through different bridges. (Does anyone expect to deploy ethernet jumbograms in such an environment) Or maybe other source of failure. I assume that to be safe, this option should be disabled by default and would require explicit action by an admin to be turned on. From nobody Thu Apr 7 15:39:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA11512D755 for ; Thu, 7 Apr 2016 15:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4iquCz4mwGm for ; Thu, 7 Apr 2016 15:39:03 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9F812D73D for ; Thu, 7 Apr 2016 15:39:01 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org (089-101-070076.ntlworld.ie [89.101.70.76] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.14.9) with ESMTPSA id u37Mcvjt042611 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Apr 2016 23:38:58 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070076.ntlworld.ie [89.101.70.76] (may be forged) claimed to be cupcake.foobar.org Message-ID: <5706E181.50208@foobar.org> Date: Thu, 07 Apr 2016 23:38:57 +0100 From: Nick Hilliard User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Philip Homburg References: <5703ABF9.2000907@foobar.org> <20160406153142.GU56633@Space.Net> <570534CC.3020603@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-van-beijnum-multi-mtu-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:39:05 -0000 Philip Homburg wrote: > Assuming two nodes (hosts or routers) have announced such a larger MTU. And > they have verified (using ICMP, or whatever) that is is actually possible > to exchange packets at a bigger MTU. > > Then what problems do you expect in todays networks? for starters, multicast and broken implementations. If there are routers doing this negotiation, then this may change the path mtu mid-flight, which could cause problems if the path mtu drops unexpectedly, which it might easily if lots of things are dynamically negotiated. Or if the MTU negotiation takes place at the first hop and the endpoints are left thinking that they can handle an mtu of 9200 bytes while the intermediate path might only support 1500 and the fragmenting router is already rate limiting icmp6 toobig responses. Or several of the situations mentioned in rfc2923. The issue is that the use case is not sufficiently compelling to warrant introducing low level changes in a protocol which has been around for 20 years and has a wide deployment, where operational experience tells us that problems relating to MTU path mismatches are a huge headache which are difficult to debug. Nick From nobody Fri Apr 8 04:27:59 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1E112D7C6; Fri, 8 Apr 2016 04:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x78XUcAKApia; Fri, 8 Apr 2016 04:27:52 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239E012D6B3; Fri, 8 Apr 2016 04:27:52 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 7DCF7D7887; Fri, 8 Apr 2016 04:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:subject:date:message-id:to:mime-version; s= selector1; bh=P9pGALzfzx5HWirbEuvfz6Ix06w=; b=Pa/Lhoh/hsX/YEdkBm l3cSr7lBJTAa2KGmK8AKDacr6x9T4ryKJgSCuFxJ6i2roAncCAOl3jpe2F20Lo1B sciW25UdvrtJ+lYNH2takkZGZTpDfSnNcU6oM+Kphlkx0AhC6Bt2Dr063o6/N12T bw2YUS18gWeLwfvzdJCnrV3Lk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:subject:date:message-id:to:mime-version; q=dns; s= selector1; b=BOA58PxnnAtQsFLC+r7bypUUj+GkpPzxKy7LA1hSynY6QrrZMyC 1sSoFSaH30eOpNaokZX6n83CR21FOoTo0DJrXqQLzQpGoJ+b2pCtIWspaCG21fWA IDPlCHuPJ/otop/IBgu7h+lKiB75e9Wb1hsaJUdsYRdik3XsPT2qggjU= Received: from h.hanazo.no (dhcp-895e.meeting.ietf.org [31.133.137.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 40C76D7884; Fri, 8 Apr 2016 04:27:51 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id CAC071437E10; Fri, 8 Apr 2016 08:27:47 -0300 (ART) From: otroan@employees.org X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_A1C2970F-7E0B-430B-85D7-CB702FB9E11B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 8 Apr 2016 08:27:46 -0300 Message-Id: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> To: 6man WG , v6ops list Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [v6ops] DNS AAAA for free X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 11:27:58 -0000 --Apple-Mail=_A1C2970F-7E0B-430B-85D7-CB702FB9E11B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here is an interesting draft being presented in dnsop today. = https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?includ= e_text=3D1 The proposal is to allow AAAA records in response to A queries. Best regards, Ole --Apple-Mail=_A1C2970F-7E0B-430B-85D7-CB702FB9E11B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXB5WzAAoJEL7aWKiYQt923j0P/RnNiGRMJPMPD3utFiGqUYby IpfAPnOUiZwxnnMNlASUGmNDds/+lgmgMLoo68m2HjliC1iScXJWadJd/gR4bzqD 4EzQMTSNcKWvAa077+dgIfOQR8L2Wjet6zBYX4qsOCpjhx1znOfNUCAEE8js2Gqj M7Qe6KWsyrgycO/dF+mz6jPzULd3ILOTmjw4m+qhxGzOS4IB+Ii7mNfXv4c5+3Fb utTl+ZLb/qsQjpo7k6g5MsVA5WItP9s1LgH9uzVsNanZFki7Ckp0P6GWc8482Uzu qCbjaz/9VaOR3q/hZvQfrcPEMUKtgkCdxOAzDSj+7Jkd+2Gmdf9eHcLY8GZ6nQgM TDBfH0eO/hdtVPjh/v0xToNYRaWtfLZ3qvzx7HTD74bGzFHyoC+8GYyttcHyBSYp G8cKmOyAyqJXIxY3kYZFREeJbEXF775b3mIO7fLmXKqORophPUgVRah+wPJY+gqB x7tZg/fQ8Q2IFgWiFKZ5hzlpLSjT3zIKrJDpbIUtow1pL5qcRx1DVnN5V6+wqMXr gIMRAK0xcXsKYwcG33evBmW65F+pgbfft1usuDIj4r37yKhZ0M83elfabh/jqfq6 mEeGMwNJO8sRhN53VfTuco2ppSf5zUfGMowukgSiO4FWUZi/zX31rGWPVrReCd4D SGRjPIMutIfv1SEgJUMo =rTDj -----END PGP SIGNATURE----- --Apple-Mail=_A1C2970F-7E0B-430B-85D7-CB702FB9E11B-- From nobody Fri Apr 8 05:45:42 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0952412D822 for ; Fri, 8 Apr 2016 05:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgWMtmnGmvtt for ; Fri, 8 Apr 2016 05:45:39 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 3021F12D711 for ; Fri, 8 Apr 2016 05:45:37 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aoVn0-0000GYC; Fri, 8 Apr 2016 14:45:30 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <5703ABF9.2000907@foobar.org> <20160406153142.GU56633@Space.Net> <570534CC.3020603@foobar.org> <5706E181.50208@foobar.org> In-reply-to: Your message of "Thu, 07 Apr 2016 23:38:57 +0100 ." <5706E181.50208@foobar.org> Date: Fri, 08 Apr 2016 14:45:29 +0200 Archived-At: Subject: Re: [v6ops] draft-van-beijnum-multi-mtu-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:45:41 -0000 >> Then what problems do you expect in todays networks? > >for starters, multicast and broken implementations. Broken implementations can do anything, including breaking things. I don't think we can say much more about broken implementations. Except for statistics about current brokenness on the internet. I naively assumed that multicast would be out of scope because of the use of neighbor discovery. >If there are >routers doing this negotiation, then this may change the path mtu >mid-flight, which could cause problems if the path mtu drops >unexpectedly, which it might easily if lots of things are dynamically >negotiated. How is that different from today's internet? If traffic gets rerouted, the PMTU may get lower. Do you think it is more likely that the MTU will drop in an ethernet jumbogram context than on the internet as a whole (taking into account the huge number of tunnels that is still present on the IPv6 internet) >Or if the MTU negotiation takes place at the first hop and >the endpoints are left thinking that they can handle an mtu of 9200 >bytes while the intermediate path might only support 1500 and the >fragmenting router is already rate limiting icmp6 toobig responses. So you are saying that PMTU doesn't work? I sort of agree with that. But if that's the case, then we should pass an RFC that states that the IPv6 link MTU always has to be exactly 1280. Otherwise, any network that runs at an MTU of 1500 can hit a tunnel that has a lower MTU. The same way I expect any router that routes between links with different MTU to be carefully monitored with respect to packet to big ICMPs. Let me also say that I find this a really sad statement. It essentially blocks all forward progress because some people may misconfigure their routers. >The issue is that the use case is not sufficiently compelling to warrant >introducing low level changes in a protocol which has been around for 20 >years and has a wide deployment, where operational experience tells us >that problems relating to MTU path mismatches are a huge headache which >are difficult to debug. In my perception, ever since Gbit/s ethernet interfaces generally started supporting ethernet packets bigger than 1500, people have been looking at either the IEEE or the IETF to find a way to make this autoconfigurable. So the way I see it, this is a huge step forward. Something that should have been done decades ago. Yes, we have a PMTU problem. But the logical conclusion of giving in to that, is that every link will run at 1280. Or, the middle boxes start messing with TCP MSS options, just like they do for IPv4. From nobody Fri Apr 8 19:05:50 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE1912D5B2 for ; Fri, 8 Apr 2016 19:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAJBbSD6ksmB for ; Fri, 8 Apr 2016 19:05:44 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD51C12D126 for ; Fri, 8 Apr 2016 19:05:44 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 5D255D7884; Fri, 8 Apr 2016 19:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=CwC4luATqkUO8Dt2mCKEtO93Jpk=; b= CCnh7wa7kQ3D9JBegjJm/jdEfPwtvPFDmxadnHHoBTVz5uVOdGFAiaCgfrm9U2Wr NvCVXhrgpGNGL5HG559+Vapwmg6f69E15YpQ6gg5BlHeQBWeFv7wH+d2abklInBG 9fE3hJ2/HaLOjP19RdiDK6rbTpidAbQ4SpIvC5tn7es= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=qiEkaTgqC7zl6UWfDUDIjxcTXf QMFvjmvW4hjHeXVSEWnJyW8bDZatVD2dzNBCIvyOevbGr4jKseTZCxtx2c7pUDTu lPeFMJwLsVTv3vcr8UKhho07PqacEQLDW9YzsLsHUE4O4UeYj1IoR93bJYCZdaT9 fo6KECmo7GLA8/cEA= Received: from h.hanazo.no (unknown [88.128.83.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id C209AD7882; Fri, 8 Apr 2016 19:05:40 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by h.hanazo.no (Postfix) with ESMTP id 8F21B143F6C9; Sat, 9 Apr 2016 04:05:28 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_471EC608-D302-4628-B96D-F262BEEADDE1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <20160403085524.GA84794@ernw.de> Date: Sat, 9 Apr 2016 04:05:27 +0200 Message-Id: <79928889-1E53-45F3-914A-E5811497D194@employees.org> References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> <20160403085524.GA84794@ernw.de> To: Enno Rey X-Mailer: Apple Mail (2.3124) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 02:05:47 -0000 --Apple-Mail=_471EC608-D302-4628-B96D-F262BEEADDE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Enno, Apologies for the late reply, IETF made following email patchy. > Hi Ole, >=20 > On Sat, Mar 12, 2016 at 06:23:50PM +0100, otroan@employees.org wrote: >=20 >> it depends on the platform and how big forwarding table your switch = can handle. >> as far as I many switches flood,( and if you want my personal = opinion, we should change hosts so that they no longer send MLD joins = for link-local groups.) >=20 > wouldn't this (your personal suggestion) > - require updating RFC 4861 where it's stated (sect. 7.2.1 on = Interface Initialization): "Joining the solicited-node multicast > address is done using a Multicast Listener Discovery such as [MLD] = or > [MLDv2] protocols." Yes, we would have to update 4861. > - maybe break ND on some host OSs/platforms (depending on their = interpretation of the exact statement above)? Given that the only reason why we added the MLD requirement was to = support MLD snooping bridges, I don't think there is anything in the ND = protocol that expects MLD for anything. > [it should be noted I consider that statement a quite unfortunate = example of ambiguous wording in an RFC as "is done" can be both read as = a descriptive and prescriptive/normative statement] Interoperability is king. I think implementors are smart enough to see = what requirements are there to achieve interoperability, and which are = merely suggestions. And yes we use RFC2119 language for both cases. :-) Best regards, Ole --Apple-Mail=_471EC608-D302-4628-B96D-F262BEEADDE1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXCGNoAAoJEL7aWKiYQt92euIQAMwOesQEnfTyhDeYNWpjvSPb sITn7EfWeA48pYs2lrkljb4IZY6V2+OSQACSwP89Qy3AvvdUTM74RFO1BEq3d9Mw jTYlFvPNiva2qcSQP3kld5P6bPZ7kJwgmm+jpc/+OvVdkP6jZKsptzBRFFNMvdsO DZEuNCHrCZQ8T27rZkbjG2oyGdneB8hgAhmx4w9iMAN6up4BDYpqQo+3O6brnJHS j0CLAOvnx5o2o/qesgKFev22/Kw6cGibBqDal8N3EzP3KgsOWzgUQ7WCpJEI1E2F WJzR2H21ZWX8vjCwLrugm44xtKAKYCgFHoQDy6hX7SUfotgMGpwTIGJm8p+bPwxf dMHqTHRBP7QH3xtmkhO2QNSn1lnJiDPUVttYKV4mBbRrEKWh6DmRXuZ14aN4hZDe SBiKNzkTOo8UyFzHgtQFl5kJN0zSIy5HfnF8xkrxJ4RE+GIdTCHSMCZXrT/dn1HW bm4yd0c431KWapZgKcP7obS66dVz+bmPFlVKCfJSWqUHm3+PHgwqf0lu4dxNv+Hb vpOPLAog3lja2JcKDvWPmzQH57ic3epWmm8zlw4nxDbtLgPJLu1Jv4QmFCsRnK+T XiYTSPA6KpWU6FO02Zv2WxewIbsWp9JBermCpEHyM1Z/v91f4vMD8RUhhdAKDW8M dycPDOIK63SljAYK3vG6 =QhJd -----END PGP SIGNATURE----- --Apple-Mail=_471EC608-D302-4628-B96D-F262BEEADDE1-- From nobody Fri Apr 8 19:14:30 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B28712D180; Fri, 8 Apr 2016 19:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGSfcxh6qz1q; Fri, 8 Apr 2016 19:14:22 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F32B12D551; Fri, 8 Apr 2016 19:14:22 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id CD947D7884; Fri, 8 Apr 2016 19:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=C11fJDhebNqWXPAk3fur6zXE6Rc=; b= TUcLty4ovARlJ+2m0VbdZwwc3cUBkBQ0JibON/gnwC2zlMHtQOdAMq25yQh6N040 JaFScOMrHr739bbr/X/f4e7O+ZlwD3Fbz/aev8QX/OF6U5aZ4kKF0FfOdhfLyaFZ nK3LtfYZrsLP2OYVF1XJKzCHMZw8avzStaRne0Lw4wg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=ZR8a2h053ifk+VAXR42gWdOoTX dO27I0PWfFwPBv0Bo2Ot1JDrJs3Gbx9ltjwTZZTEIxBRkJZL0H43+2lDghWE9+5s +oXoBFtnQSAhJL+jkEGWd1ji3d9ygZD2ly/ETWcLI3vzVtVSm0jSUR+6IK0NwGKz GMVz2b4OuB+7tbJOY= Received: from h.hanazo.no (unknown [88.128.83.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id DB322D7882; Fri, 8 Apr 2016 19:14:19 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by h.hanazo.no (Postfix) with ESMTP id BC3DC143F8C0; Sat, 9 Apr 2016 04:14:07 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BF1DCEBF-1745-40AD-A0F9-0F86FD621BFB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Sat, 9 Apr 2016 04:14:07 +0200 Message-Id: References: <20160317130356.3746.55282.idtracker@ietfa.amsl.com> To: joel jaeggli X-Mailer: Apple Mail (2.3124) Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world@ietf.org, v6ops-chairs@ietf.org, Alia Atlas , draft-ietf-v6ops-ipv6-ehs-in-real-world.all@tools.ietf.org, The IESG Subject: Re: [v6ops] Alia Atlas' Abstain on draft-ietf-v6ops-ipv6-ehs-in-real-world-02: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 02:14:24 -0000 --Apple-Mail=_BF1DCEBF-1745-40AD-A0F9-0F86FD621BFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> Alia Atlas has entered the following ballot position for >> draft-ietf-v6ops-ipv6-ehs-in-real-world-02: Abstain >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> = https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I also agree with Alvaro. >=20 > notwithstanding that the call has already occurred and I don't expect > to change anyone's minds anyways I would direct attention to the = current > discussion of the follow-on draft in the v6ops working group . too late for this draft I guess... >=20 > = https://mailarchive.ietf.org/arch/search/?email_list=3Dv6ops&gbt=3D1&qdr=3D= w&q=3Ddraft-gont-v6ops-ipv6-ehs-packet-drops >=20 >=20 > the wide diversity of opinions there is very much why the measurement > is purposefully neutral. I think we are fooling ourselves if we think that measurements are = neutral. Having measurements are good. We should have many of them from different = sources, and the underlaying data and methods should be available to the = community for review. But they should not be published as RFCs. And in this particular draft the presentation of the findings certainly = is not. e.g 11.88% | (17.60%/20.80%) is certainly a funny way of saying 2.5%. Best regards, Ole --Apple-Mail=_BF1DCEBF-1745-40AD-A0F9-0F86FD621BFB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXCGVvAAoJEL7aWKiYQt92gNoP/i2rziS4lKm5goIE5uQu0Klq GF0QCVRDZ6C2PYPtAypAJBbOR8OfwxT+jRIfxKl0exTeUdr/1cLcJ7hyvgUD9Cf2 Zf7YFTriSEqGIcUlxgV1CoZQlhHd4ZT1Ij2ggRz/NfusyDGfpz/I9KbW0NbV9QXM EleHFu98t84Gt+YuKZMn4G8UsbSlXJJers2w39nmexGrzeShAtrwZOYkpaMJpR5M enVaRaB4N3QF0xJO25YdaiqAlmktp+h9yPagY3eAmsj/q5wxPzTWyYQmpWTqVK+M bGa5sZgoM5xftg6GNV/bfTYgVXPZgAgU56osddLUMZ5P+KzXAe45wWNw3cAw+WO2 K5AdMH2ZpsaFv7d30OR1lMwxvwRGpuhWa1biQ5qR3GqjPTkPMo3MnbY0kn/zkfif mbceIQc7HlQr5YuCeSVphDTWPeFU12rzel77FsiO2eTGI1kZAegoRIE8jRgAwRDC RtzLM8keFhMwiX2xUMKr+FTTe2rVYrsYAQITYbeY3Joo6nws9ALrmkWjL9uyjg3w 8Um/Rq1o4Aq9mxE+m5oC0h0g1BQX+1sxat4MkgBIP0YkS1SnEZQz1N++wUkZoafg 6/NkfM3VxMcu0k8dgqc/PUhk8kujrFHxRyCJqOtSVfDDg9Uv7C6BxyNvscUmJAz8 KARfCHZvnypVp9BQVKo2 =uelx -----END PGP SIGNATURE----- --Apple-Mail=_BF1DCEBF-1745-40AD-A0F9-0F86FD621BFB-- From nobody Fri Apr 8 20:35:12 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9819512D6B4 for ; Fri, 8 Apr 2016 20:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzprXk4TfZQ6 for ; Fri, 8 Apr 2016 20:35:08 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD5912D607 for ; Fri, 8 Apr 2016 20:35:08 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id e128so86878604pfe.3 for ; Fri, 08 Apr 2016 20:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3dJ5VCWjM3D+IzYASaOItqpek3AamUcNC1sDUIlZRrI=; b=akkYhiC05ZKJ7LFRecYN1sxOLdjyIMJhnA2rRxAoCO8KAMw3JRZ2WYyVk+RrlOHpwf n8sH7eSbLcN+4n8QdnLAcuWt7+XIXCzats3qSLw2UxLTpN33LIQlWwp3VGQZvHQTJ66G UAiBU5Wtb3SVUjZNTY1QCpKLoLabwTE7WVHb79eOJs59jZkZXZ0YNeUgAjSIzPAiK1ml EQCmU5QccPMu/L60Qqo5IwZheTQFD+mKK43dued9G16O5Gccr+SBPlubYEIn0Nv1+c7S pKqfvHv4X3ppOqRdvcO9JMcBrsEKuU2k/G0fh266KbexJfKWnc4OiabkQLipdOktc/Ly +JdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=3dJ5VCWjM3D+IzYASaOItqpek3AamUcNC1sDUIlZRrI=; b=hR4vD3YZk9yXnOLnrxIBneVGwMUuToN14eysmXqE7MSKaFPkLRAGebkrCIv1rVh3lL gWx/7umTHE5ohxfArFvfLu1sVUbuTfzZIZDM/ZLWJJvY9ImgkwdT9OAdWRyTwx4q8fH4 A4fllK+lwhBc76oMmZ7YIQVJRIcszZNZ3xiEhCyHZyAy0bWeNunPs/b1VFbHc9iYN8Mi TQrGyTkncpm245ZteXR69LEq3L5BdpOV5GQ/CRVukmAZAarlNF/WmVqpPHUs8VEvXCRJ MBfIajMBhqf1UiJvZDgmZuJOZ7oRgHGb8XoM+KTGj+8x3lK/SVhDZwiT1hrxyuTA6YBn Zscg== X-Gm-Message-State: AD7BkJJbsLTGhZRwoSL0sfyHy0WiiFdok77G3pCX29KfLlfL4ebQuYveHiafyZWMyN8tsA== X-Received: by 10.98.0.202 with SMTP id 193mr17064349pfa.120.1460172908153; Fri, 08 Apr 2016 20:35:08 -0700 (PDT) Received: from ?IPv6:2406:e007:7c81:1:28cc:dc4c:9703:6781? ([2406:e007:7c81:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f8sm21542112pfj.49.2016.04.08.20.35.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 20:35:06 -0700 (PDT) To: otroan@employees.org, Enno Rey References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> <20160403085524.GA84794@ernw.de> <79928889-1E53-45F3-914A-E5811497D194@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <57087872.9070703@gmail.com> Date: Sat, 9 Apr 2016 15:35:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <79928889-1E53-45F3-914A-E5811497D194@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 03:35:10 -0000 On 09/04/2016 14:05, otroan@employees.org wrote: > Enno, > > Apologies for the late reply, IETF made following email patchy. > >> Hi Ole, >> >> On Sat, Mar 12, 2016 at 06:23:50PM +0100, otroan@employees.org wrote: >> >>> it depends on the platform and how big forwarding table your switch can handle. >>> as far as I many switches flood,( and if you want my personal opinion, we should change hosts so that they no longer send MLD joins for link-local groups.) >> >> wouldn't this (your personal suggestion) >> - require updating RFC 4861 where it's stated (sect. 7.2.1 on Interface Initialization): "Joining the solicited-node multicast >> address is done using a Multicast Listener Discovery such as [MLD] or >> [MLDv2] protocols." > > Yes, we would have to update 4861. > >> - maybe break ND on some host OSs/platforms (depending on their interpretation of the exact statement above)? > > Given that the only reason why we added the MLD requirement was to support MLD snooping bridges, I don't think there is anything in the ND protocol that expects MLD for anything. I'm sure that's true, and logically it's the same for any protocol that uses link-local multicast for anything: bridges that aren't bridges, because they drop LL multicasts by default, force implementations to perform MLD joins. Worse, bridges that aren't bridges *and* have defective MLD snooping by default break such protocols. I'm not sure what the IETF can do about this except scream and shout. Brian > >> [it should be noted I consider that statement a quite unfortunate example of ambiguous wording in an RFC as "is done" can be both read as a descriptive and prescriptive/normative statement] > > Interoperability is king. I think implementors are smart enough to see what requirements are there to achieve interoperability, and which are merely suggestions. And yes we use RFC2119 language for both cases. :-) > > Best regards, > Ole > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Apr 8 20:46:07 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573FD12D6DC for ; Fri, 8 Apr 2016 20:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hdVBqvVF3d4 for ; Fri, 8 Apr 2016 20:46:05 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF0F12D6A6 for ; Fri, 8 Apr 2016 20:46:05 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id t129so73006991vkg.2 for ; Fri, 08 Apr 2016 20:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qdCDD+/jPaSXRN822u2HhzkNR2jsZ0c/2a4G7uw7ei4=; b=qxNaWPfsqvY34wg3ckkFpERbVH52eJHWspEJkFfvmL5a0IXAmaaX7rwo/vaKWRdiQX x6BZK7zaXmQ38IpvZglRVXHX+2lP1T+6pLMBu54vaGZcdpjmruBN8izi+T0uotoyrqtl u2ed+UmPIE4sXY+ZSTAAo7eUf91bBfFW64Z+4JW8bHYE6oBhXOeAzjcRmobLC+hK0Acf vTUg6D300nJPU2ly6BLLLJhiDNt/1p+3zJe0DtKWalZqHLMy+yU1UCUnNyoIZY9hQ1s/ W9c68rITUKwFt21SmMpLxY0o1SMnI2+kBT5pUmxXngrqXlkCXXZcuQDFJkNkRm1bFl6E 34RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qdCDD+/jPaSXRN822u2HhzkNR2jsZ0c/2a4G7uw7ei4=; b=XlS77Yw7aq4/+G8CK8kEq6uLX0GY3qKoWmLYE+waozj78x0lpHQLvl5c32zbyL6CvX 97+vAJXB3W5RAzCLD/dYXpLpA8TltQrdE01IlFW2O5yOcSNelrVr88DolbU5GNj0sY+5 Ivhir5M8pvCuOGywzyW1ecaIj2R73OIPn65z6VoZ9pBv8IKNps4F6tEArex0mkvd8yne qVUJiDST29Or1I5GEcJ/QZGU7uYI0bov7SiMjx0EdF8HRB4hOWSF1WHnkjfr5zUlvbjE nTMeZ+tYWGpHuwpHQVhpjzv56MXlCam1CcHVj5ExAmZLi5dT6AoudbfDyHngvUZrOx5G c6oA== X-Gm-Message-State: AD7BkJIEyb6KaMbznROudsTpqodKIwQYKz5k1zSrm58z9Zb479fABElBx6zvHGF5vQXeWybu1smX4jNe8ZGO1A== X-Received: by 10.31.58.83 with SMTP id h80mr5938801vka.149.1460173564465; Fri, 08 Apr 2016 20:46:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.32.228 with HTTP; Fri, 8 Apr 2016 20:45:35 -0700 (PDT) In-Reply-To: <79928889-1E53-45F3-914A-E5811497D194@employees.org> References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> <20160403085524.GA84794@ernw.de> <79928889-1E53-45F3-914A-E5811497D194@employees.org> From: Mark Smith Date: Sat, 9 Apr 2016 13:45:35 +1000 Message-ID: To: Ole Troan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 03:46:07 -0000 On 9 April 2016 at 12:05, wrote: > Enno, > > Apologies for the late reply, IETF made following email patchy. > >> Hi Ole, >> >> On Sat, Mar 12, 2016 at 06:23:50PM +0100, otroan@employees.org wrote: >> >>> it depends on the platform and how big forwarding table your switch can handle. >>> as far as I many switches flood,( and if you want my personal opinion, we should change hosts so that they no longer send MLD joins for link-local groups.) >> >> wouldn't this (your personal suggestion) >> - require updating RFC 4861 where it's stated (sect. 7.2.1 on Interface Initialization): "Joining the solicited-node multicast >> address is done using a Multicast Listener Discovery such as [MLD] or >> [MLDv2] protocols." > > Yes, we would have to update 4861. > You also have to update a number of other RFCs that talk about or refer to solicited-node multicast groups and MLD, RFC2710, "MLD messages ARE sent for multicast addresses whose scope is 2 (link-local), including Solicited-Node multicast addresses [ADDR- ARCH], except for the link-scope, all-nodes address (FF02::1)." RFC3810, which only excepts FF02::1 as a special case, "The link-scope all-nodes multicast address, (FF02::1), is handled as a special case. On all nodes -- that is all hosts and routers, including multicast routers -- listening to packets destined to the all-nodes multicast address, from all sources, is permanently enabled on all interfaces on which multicast listening is supported. No MLD messages are ever sent regarding neither the link-scope all-nodes multicast address, nor any multicast address of scope 0 (reserved) or 1 (node-local)." RFC3590, "As the unspecified address is only used when there is no link-local address, RFC 2710 implementations discarding these packets will have no affect on the packet's sender as the use should only be for joining the link-local solicited-node multicast group [RFC 2462]." RFC4862, "Note that when a node joins a multicast address, it typically sends a Multicast Listener Discovery (MLD) report message [RFC2710] [RFC3810] for the multicast address. In the case of Duplicate Address Detection, the MLD report message is required in order to inform MLD- snooping switches, rather than routers, to forward multicast packets. [...]" >> - maybe break ND on some host OSs/platforms (depending on their interpretation of the exact statement above)? > > Given that the only reason why we added the MLD requirement was to support MLD snooping bridges, I don't think there is anything in the ND protocol that expects MLD for anything. > You're right, there is nothing in the ND protocol that expects MLD. Although my answers weren't coming through, I did see your comment at the end of my presentation in the v6ops session on Monday. >From what I remember, you expressed a concern about coupling MLD and ND operation. I don't think my proposal is doing that - ND can operate without the MLD information I'm suggesting leveraging, although it is more vulnerable to the ND cache exhaustion attack. The dependency that ND operation would place on MLD is completely optional. So it is a trade-off - an optional dependency on MLD's collection of Solicited-Node multicast group information to provide ND with more information about what is possibly on the link, to gain less exposure to ND cache resource exhaustion attacks from remote attackers. There may be other future opportunities to leverage information collected MLD for SNMGs that will never be possible if they are deprecated. For example, MLDv2s for SNMGs, if collected, would provide a complete list of at least one Link-Local address of each of the nodes attached to the link, as LLs are used for MLDv2 source addresses (except the initial ones when LLs aren't available). If nodes then supported either Node Information Queries (as it appears Apple devices already do), or InverseND, then using that list of LL addresses, a router could ask each of the nodes what its other IPv6 addresses are, giving the router a complete list of all of the IPv6 unicast and anycast addresses present on the link. There would now be no need for the router to send ND NSes at all, as it would know all possible destinations on the link. Regards, Mark. >> [it should be noted I consider that statement a quite unfortunate example of ambiguous wording in an RFC as "is done" can be both read as a descriptive and prescriptive/normative statement] > > Interoperability is king. I think implementors are smart enough to see what requirements are there to achieve interoperability, and which are merely suggestions. And yes we use RFC2119 language for both cases. :-) > > Best regards, > Ole > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sat Apr 9 01:07:34 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7D812D10D for ; Sat, 9 Apr 2016 01:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeKHsbiGi6ah for ; Sat, 9 Apr 2016 01:07:31 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5BAA12D0C7 for ; Sat, 9 Apr 2016 01:07:30 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id q128so156628431iof.3 for ; Sat, 09 Apr 2016 01:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q0zVp2+uZaoH/xwocJMAlvInGTgLLE6VLBYZtDq3qII=; b=P2Iznr9RZ8ZB5UF1qkQZA9ugproIoikCz+oRDTJw3kxWN4lMkb1exjs8n/b1/aZoZs gmv/ntFRx80jMj6NOPVdToywx1117YCdUiwz3bRJtoFlV9+gYDtiQRHtEDGSOKrBcazJ kMwWi35KW1nAgDfgzBYMUVrEy+VJEHDCfbAF8t142T12HmBl0aDzDrImCp6A1dLJFVLU SItz89ftJ5hWyxtlZB5GJQ/q4QE4y2LLFyAcH8DUWw21l6QqnYMy1VxoZiPMzDXd+jYF seRZRPkxbekVDVNk5sLURdk8K9Y1N6wj5/BliZFqATEy25ypEWZzd/8nkHqcnyq8VCWJ TIxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q0zVp2+uZaoH/xwocJMAlvInGTgLLE6VLBYZtDq3qII=; b=flrAgvojuiL7Be+ZG3uYQGQFpy266gHelu6h1+NhphIBGKPhyOR9e0ZhWlZ3zHE4Tq xX2/OVKg38g/m/WPAV2uQ8AuOLdCMCXFba8AZvA8cPr1ViZtBBtpLoVbvz87/f6u6J/+ qp0HWl7OqtTKyz6FGD97+u53Ty45DfCiXUm8GQsxB2EX6BEq6Nk2SvnC+mjYiYfgyTWc lFwDd5CJcmZzjfN6C5PuUl6Icw6X+JqbFf0J7HzIzIsWmRhYtmkKA42DLbyjlE4gmQa0 AYoWEOJZR+C+VifU6PHkF2114zJCd0+2TXOQnmIgHlMLv/a8nRL1I24FHhoQHM7Bc3RT 0vrQ== X-Gm-Message-State: AD7BkJJXtRw9+4Zp0Wzqb0+SIJLJDzxnUoII0bc3C5koPscezQqPG5QT+EJ5Ck/vxUshRFreQCnRUkb8X5XwkpM7 X-Received: by 10.107.30.71 with SMTP id e68mr13819183ioe.145.1460189249918; Sat, 09 Apr 2016 01:07:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.227.84 with HTTP; Sat, 9 Apr 2016 01:07:10 -0700 (PDT) In-Reply-To: <07119903-475A-4D7E-848D-3320C1AB546C@gguy.me> References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> <07119903-475A-4D7E-848D-3320C1AB546C@gguy.me> From: Erik Kline Date: Sat, 9 Apr 2016 17:07:10 +0900 Message-ID: To: Geordie Guy Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 6man WG , v6ops list Subject: Re: [v6ops] DNS AAAA for free X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 08:07:33 -0000 So far I fail to see the benefit. Host that think they can do IPv6 generally ask for AAAAs first, or nearly simultaneously with As if they're doing connection racing. So I don't see how this helps. On 9 April 2016 at 16:55, Geordie Guy wrote: > This is genuinely awesome. > > Geordie > > Sent from my mobile. Please excuse any unusual brevity or typos while I'm on the go. > >> On 8 Apr 2016, at 9:27 PM, otroan@employees.org wrote: >> >> Here is an interesting draft being presented in dnsop today. >> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1 >> >> The proposal is to allow AAAA records in response to A queries. >> >> Best regards, >> Ole >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Apr 9 01:59:14 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA9212D15A for ; Sat, 9 Apr 2016 01:59:12 -0700 (PDT) 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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNAbKjE2TYUc for ; Sat, 9 Apr 2016 01:59:10 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B06812D158 for ; Sat, 9 Apr 2016 01:59:09 -0700 (PDT) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 7191315EC29 for ; Sat, 9 Apr 2016 10:59:02 +0200 (CEST) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 4A5D34E2172 for ; Sat, 9 Apr 2016 10:59:05 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 80B698B13; Sat, 9 Apr 2016 10:59:06 +0200 (CEST) Date: Sat, 9 Apr 2016 10:59:06 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20160409085906.GB11980@ernw.de> References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> <20160403085524.GA84794@ernw.de> <79928889-1E53-45F3-914A-E5811497D194@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79928889-1E53-45F3-914A-E5811497D194@employees.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 08:59:12 -0000 Ole, On Sat, Apr 09, 2016 at 04:05:27AM +0200, otroan@employees.org wrote: > > > > wouldn't this (your personal suggestion) > > - require updating RFC 4861 where it's stated (sect. 7.2.1 on Interface Initialization): "Joining the solicited-node multicast > > address is done using a Multicast Listener Discovery such as [MLD] or > > [MLDv2] protocols." > > Yes, we would have to update 4861. why is it that such a statement from *your* side sounds a bit like a threat? ;-) > > > - maybe break ND on some host OSs/platforms (depending on their interpretation of the exact statement above)? > > Given that the only reason why we added the MLD requirement was to support MLD snooping bridges, I don't think there is anything in the ND protocol that expects MLD for anything. if just the implementors knew/had realized this... in reality host operating systems behave quite differently in this space. admittedly on quite some one can disable/block MLD *without* breaking ND, e.g. see https://www.insinuator.net/2014/09/mld-and-neighbor-discovery-are-they-related/. > > > [it should be noted I consider that statement a quite unfortunate example of ambiguous wording in an RFC as "is done" can be both read as a descriptive and prescriptive/normative statement] > > Interoperability is king. I think implementors are smart enough to see what requirements are there to achieve interoperability, and which are merely suggestions. And yes we use RFC2119 language for both cases. :-) ;-) have a great weekend everybody (and safe travels home), Enno > > Best regards, > Ole -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Sat Apr 9 02:18:01 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7F612D159 for ; Sat, 9 Apr 2016 02:17:59 -0700 (PDT) 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=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lclG2MLGUb8K for ; Sat, 9 Apr 2016 02:17:57 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C79912D17E for ; Sat, 9 Apr 2016 02:17:56 -0700 (PDT) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id A47A515EC29 for ; Sat, 9 Apr 2016 11:17:50 +0200 (CEST) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 7B6F64E2191 for ; Sat, 9 Apr 2016 11:17:53 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 9C9EE8B19; Sat, 9 Apr 2016 11:17:54 +0200 (CEST) Date: Sat, 9 Apr 2016 11:17:54 +0200 From: Enno Rey To: v6ops@ietf.org Message-ID: <20160409091754.GC11980@ernw.de> References: <56D7B667.6020009@gmail.com> <56E36583.606@pluribusnetworks.com> <702316D0-55E8-440D-B689-9035E1DDA1F9@employees.org> <20160403085524.GA84794@ernw.de> <79928889-1E53-45F3-914A-E5811497D194@employees.org> <57087872.9070703@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57087872.9070703@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [v6ops] Practical question about MLD join for LL multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 09:18:00 -0000 Brian, On Sat, Apr 09, 2016 at 03:35:14PM +1200, Brian E Carpenter wrote: > >> - maybe break ND on some host OSs/platforms (depending on their interpretation of the exact statement above)? > > > > Given that the only reason why we added the MLD requirement was to support MLD snooping bridges, I don't think there is anything in the ND protocol that expects MLD for anything. > > I'm sure that's true alas, it's not. there's host OSs out there (I hear the not-so-rarely-used one from Redmond is amongst those) whose ND behavior becomes erratic once MLD is suppressed. sure, we can take a stance of "well, they're to blame for not reading the specs with sufficient scrutiny or they have a reputation of deviating from specs anyway or whatever". my point is that using wording like "is done" in the relevant section of RFC 4861 hasn't exactly helped their (implementors') job. I agree with Ole though that we won't see a change in/update to 4861 anytime soon. , and logically it's the same for any protocol that uses > link-local multicast for anything: bridges that aren't bridges, because they > drop LL multicasts by default, force implementations to perform MLD joins. > Worse, bridges that aren't bridges *and* have defective MLD snooping by default fortunately, to the best of my knowledge, as of today there's none which actually have MLD snooping on by default. > break such protocols. > > I'm not sure what the IETF can do about this except scream and shout. (maybe just sometimes) re-connect to the real-world of operational reality out there? I'm aware that's a harsh and potentially unjust statement. Though I wish the comments made on the mic in sunset4 on Tuesday could serve as a wake-up call somehow... best Enno > > Brian > > > > >> [it should be noted I consider that statement a quite unfortunate example of ambiguous wording in an RFC as "is done" can be both read as a descriptive and prescriptive/normative statement] > > > > Interoperability is king. I think implementors are smart enough to see what requirements are there to achieve interoperability, and which are merely suggestions. And yes we use RFC2119 language for both cases. :-) > > > > Best regards, > > Ole > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Sat Apr 9 03:55:20 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF9C12D0E6; Sat, 9 Apr 2016 03:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UgKezw3pyEO; Sat, 9 Apr 2016 03:55:14 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D9D12D0BB; Sat, 9 Apr 2016 03:55:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A547838; Sat, 9 Apr 2016 12:55:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :content-type:content-type:mime-version:subject:subject:received :received; s=mail; t=1460199309; bh=4W+o1sPFvXJfBB4RHmBskjwW/V50 m/j3COY2A2a5w0E=; b=H2fvv1QO7l38sOz2kxayHoEJ7Tl+k0HW+ArU9wzyU4p6 4IaiMLHlWFmFCloNAoIsu0fslL5r+8B71gF24xLzpJdKI/y+8bdUU5JF6bL97vxf Lcr1D9r9/OOqzT/GCq8oNruR9s6MFFU6C9j7r1PDghOI3eKyUqB53AgeAun9AbQ= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YpcSBgfCY9BC; Sat, 9 Apr 2016 12:55:09 +0200 (CEST) Received: from [IPv6:2a00:8640:1::3c8b:3db7:267:4e94] (unknown [IPv6:2a00:8640:1:0:3c8b:3db7:267:4e94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 800B337; Sat, 9 Apr 2016 12:55:06 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E9B6D0AD-539B-46F9-92CB-268AD4A022AF"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> Date: Sat, 9 Apr 2016 12:55:05 +0200 Message-Id: <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> To: otroan@employees.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] DNS AAAA for free X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 10:55:16 -0000 --Apple-Mail=_E9B6D0AD-539B-46F9-92CB-268AD4A022AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 08 Apr 2016, at 13:27, otroan@employees.org wrote: >=20 > Here is an interesting draft being presented in dnsop today. > = https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?includ= e_text=3D1 >=20 > The proposal is to allow AAAA records in response to A queries. One question: if clients send requests for both A and AAAA records = simultaneously, how will including the AAAA answer in the A request = help? The client will just get the AAAA answer twice: once on the A = request and once on the AAAA request. If lookups were serialised and the = A request/response was completed before starting the AAAA request it = would make the second request unnecessary, but that's not what I see in = practice... It looks like good intentions, I'm just trying to figure out how this = would work in practice :) Cheers! Sander --Apple-Mail=_E9B6D0AD-539B-46F9-92CB-268AD4A022AF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXCN+JAAoJEKAtA7D+JBO5zugH/iRbnTGny3OJ1r6QyEuJJyDJ qvFvGgzNqewxmx9TuP9AEV8cdlcFo3tOTOvZW+pLBq6XSpJioSn9brA0UtS2gFfV mNG5s++qvZhlspxU3zRPJGIy8hrgyOLJe7/rO0DAbY4QEHG9Yxc23MWd/25z0Cdv Q2GlGfRFMiZL3Ml4cjg8r3zigRC3bVIRUmq4o28fgFhKRZDVu4IjQ7XnI2/m5+gS +GVsJwzLA7G5RhTu8z8d878Sq/emCe8dfAAuFVlch+UrHciwdehO8kTjNnI6NMit mJHrLQy/QB2WGP5ZLUCQTc1zdSF2+kuxtWpq++e/8D4nMIXw4lXU6cS7WwfSAvo= =b0Py -----END PGP SIGNATURE----- --Apple-Mail=_E9B6D0AD-539B-46F9-92CB-268AD4A022AF-- From nobody Sat Apr 9 06:11:18 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D3D12D69B; Sat, 9 Apr 2016 06:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9-TNCZ6FV_S; Sat, 9 Apr 2016 06:11:12 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E66012D69A; Sat, 9 Apr 2016 06:11:12 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id e185so166820082vkb.1; Sat, 09 Apr 2016 06:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=rNhXv2jjs5r/ChBBNbmkrVSX/H+m3LIwdO0cyxuHnIU=; b=t8+Fj361+iAe/u7lqzRPZMhK5p9zDbGR0yY1kEcPl2qT31lcvnDavZE9R1VzDXho8U 8xE8eqKBxklXvrHBqBbUMoSypTCd8gc7Aj8rqB40rmFRIA6CaXiS5KBi6xFe54rgDjFe HcH6zvn7rH0Gj+XvzK5GnYkK3jui/WIA3bCT+Ykc/pTsROZsDWJoryYVZ14SxoNMEyKs +wQdzyS6m0Dzfd2CUydJNu+XJV3iIWqo5H/89ft3dJDj/e4KSBYrfZzm3As4kMhVEa9j YAH7IGPzdSldnhkgjXNiYH3QM8TaJbzRqF0OxCFprqiQFKmfOQaq4jLD6D/hPVAPuiyw G3Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rNhXv2jjs5r/ChBBNbmkrVSX/H+m3LIwdO0cyxuHnIU=; b=IhpTYbAAQXlS2Cpn/6XvhKBrFHDNBI7lyR+4kjSXYvGnRZUjhUIcdBotIfCp8rOion FlfCsK+6UwS8OpnGXZQEud3ka1HgHDxD4003G8UL4uL4wTNcsBcvNQMlR6hdR+5iHF7L Cfrww8AL+EPkawKZ2V0N0e2HU6HZicn/yICRIT8XtzGaRt58fXDE0+JuyH/EMm0PXjoW ZcGmmSBOccfFklDd7fiI8eX4IXI3rjQd69py8KI0JzZJsGWUk24fyWIYukMBScd8oFP6 tRg6emfFv00IngMbO5WNoUz/twk2qWfZeYP3PVfKEjogecG96ilG5cQgutFEsdofB1vH ApGQ== X-Gm-Message-State: AD7BkJL8jsw8XIqqTiMpYH05HuIDdZ9PxxMDjzm89Vu54vhIiUAmpF3uC9huNOIZEhCSfumkgUyIZLvJIH7q+g== MIME-Version: 1.0 X-Received: by 10.31.54.75 with SMTP id d72mr6644899vka.30.1460207471332; Sat, 09 Apr 2016 06:11:11 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Sat, 9 Apr 2016 06:11:11 -0700 (PDT) Received: by 10.159.32.228 with HTTP; Sat, 9 Apr 2016 06:11:11 -0700 (PDT) In-Reply-To: <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> Date: Sat, 9 Apr 2016 23:11:11 +1000 Message-ID: From: Mark Smith To: Sander Steffann Content-Type: multipart/alternative; boundary=001a11430a1ea0946d05300d0b1d Archived-At: Cc: 6man WG , v6ops list Subject: Re: [v6ops] DNS AAAA for free X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 13:11:14 -0000 --001a11430a1ea0946d05300d0b1d Content-Type: text/plain; charset=UTF-8 On 9 Apr 2016 8:55 PM, "Sander Steffann" wrote: > > Hi, > > > On 08 Apr 2016, at 13:27, otroan@employees.org wrote: > > > > Here is an interesting draft being presented in dnsop today. > > https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1 > > > > The proposal is to allow AAAA records in response to A queries. > > One question: if clients send requests for both A and AAAA records simultaneously, how will including the AAAA answer in the A request help? The client will just get the AAAA answer twice: once on the A request and once on the AAAA request. If lookups were serialised and the A request/response was completed before starting the AAAA request it would make the second request unnecessary, but that's not what I see in practice... > > It looks like good intentions, I'm just trying to figure out how this would work in practice :) > Having briefly looked at it, it seems there is an efficiency benefit. However, answering an A query with both an A and AAAA response might incentivise just sending A queries. Perhaps the opposite would be better - sending an AAAA query would result in an AAAA and A answer. That might create a small and subtle incentive to use and prefer IPv6, with Happy Eyeballs covering over IPv6 failures. Regards, Mark. > Cheers! > Sander > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a11430a1ea0946d05300d0b1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 9 Apr 2016 8:55 PM, "Sander Steffann" <sander@steffann.nl> wrote:
>
> Hi,
>
> > On 08 Apr 2016, at 13:27, otroan@employees.org wrote:
> >
> > Here is an interesting draft being presented in dnsop today.
> > https://datatracker.ietf.org/doc/draft-vavr= usa-dnsop-aaaa-for-free/?include_text=3D1
> >
> > The proposal is to allow AAAA records in response to A queries. >
> One question: if clients send requests for both A and AAAA records sim= ultaneously, how will including the AAAA answer in the A request help? The = client will just get the AAAA answer twice: once on the A request and once = on the AAAA request. If lookups were serialised and the A request/response = was completed before starting the AAAA request it would make the second req= uest unnecessary, but that's not what I see in practice...
>
> It looks like good intentions, I'm just trying to figure out how t= his would work in practice :)
>

Having briefly looked at it, it seems there is an efficiency= benefit. However, answering an A query with both an A and AAAA response mi= ght incentivise just sending A queries.

Perhaps the opposite would be better - sending an AAAA query= would result in an AAAA and A answer. That might create a small and subtle= incentive to use and prefer IPv6, with Happy Eyeballs covering over IPv6 f= ailures.

Regards,
Mark.=C2=A0

> Cheers!
> Sander
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> -------------------------------------------------------------------- >

--001a11430a1ea0946d05300d0b1d-- From nobody Sat Apr 9 08:03:28 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677B512B014; Sat, 9 Apr 2016 08:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KASnK8eJcBgN; Sat, 9 Apr 2016 08:03:25 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C57912B01A; Sat, 9 Apr 2016 08:03:25 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id 2so163016326ioy.1; Sat, 09 Apr 2016 08:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=Q75Iuyherk37BE4KtXx2W/GDoYlQIgayGnLxBLCniNI=; b=E88t2BukXFaqa1TP7iraICylJpcvIsa0KB7XcBc0IZHiO/BJ63DYkpgf8BLYWysZnn 247YXgJgdH6TP8LUX254XvgnCC/zDOEYVmTaWFuVXUtkTRnPGtJv5L/gEWKPeQcczwLJ oFWIcK43VZyeDc9py69WtNm2sP8TxBkFhZ+CTvgmAo6rfn3wMQpGKbfbioIWXHe6Rb38 0w3R0FqKeqI9XIaWVlcahLs44PUWywUF0v6qQOnRYk1OifaRipul9nh4+pQPwAwPkBLt bHX2y/v0UhUlgr9Hi2bOBlVOY+4kgXpJ3imQsAbtvIm/+Tv3FZQdxK/FCojE2X1AyHZz D6vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Q75Iuyherk37BE4KtXx2W/GDoYlQIgayGnLxBLCniNI=; b=Sf82arRPxS+gMbCrhLpaHuINxSuBkhcSfLwww6eNw9XnOo+qAW8jKW0ZmdvM8gHDa+ 0e7Wthzq9owG1pPJn72KDR8TH0ByBQZc9R6tJX7keRNPPA2nA/O4Kg3hTVgQxq6hUUoL YyNssH9aj2FPO1tWMcNgMH6uYdhCZkhNIRx175pzBsXEjSd6VEOnLhHYrh7oQj4AftU3 pyfYKd9tF54JNW3C1t328eDc9by3aogc0BFbQ2eiiyNS82z8QpSESDchwkmD42O3c2s3 Au9RDzbPTvYgpYJHxrnS7wlyhgvC2YLNVI4uJGCZlLBUh6y15n1S+edeprVfzK4BPhOe HZsg== X-Gm-Message-State: AD7BkJLaatqgR6pCtSBD6WhwMqgOoakAydiEBLftbwxt1YgppYuPk56sV7vx9Ee1tMlEXhgt6WPSZA2IXQhBKg== MIME-Version: 1.0 X-Received: by 10.107.13.65 with SMTP id 62mr15310756ion.186.1460214204385; Sat, 09 Apr 2016 08:03:24 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.107.200.14 with HTTP; Sat, 9 Apr 2016 08:03:24 -0700 (PDT) In-Reply-To: References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> Date: Sat, 9 Apr 2016 12:03:24 -0300 X-Google-Sender-Auth: IQANPdLWBR2VKtG8d7Bih25rGjw Message-ID: From: Erik Nygren To: Mark Smith Content-Type: multipart/alternative; boundary=001a113ff0ccf2d18505300e9cbb Archived-At: Cc: 6man WG , v6ops list Subject: Re: [v6ops] DNS AAAA for free X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 15:03:26 -0000 --001a113ff0ccf2d18505300e9cbb Content-Type: text/plain; charset=UTF-8 On Sat, Apr 9, 2016 at 10:11 AM, Mark Smith wrote: > > On 9 Apr 2016 8:55 PM, "Sander Steffann" wrote: > > > > > Perhaps the opposite would be better - sending an AAAA query would > result in an AAAA and A answer. That might create a small and subtle > incentive to use and prefer IPv6, with Happy Eyeballs covering over IPv6 > failures. > +1 Motivations to do this alongside AAAA query responses rather than A queries: - Encourage sending AAAA queries first (generally a good practice) - Don't penalize devices that receive dual-stacked connectivity and do both AAAA and A lookups in cases when the A lookup gets dropped. - Helps DNS64 in the case of a NOERROR for the AAAA if the corresponding A record can be carried alongside. Although... Pros: helps for dual-stacked clients with IPv4-only content. Cons: removes a tiny motivation to dual-stack (in cases where clients behind DNS64 only do a AAAA lookup having a AAAA record improves DNS lookup time during DNS cache misses). If we also look at something like this for stubs to resolvers, once enough resolvers implement this it could let stubs do AAAA lookups serially and only kick off a A lookup if no AAAA (or an empty AAAA with no A additional) is returned. (Although it would be undesirable for servers to wait for a A record before returning a AAAA record, so they'd only want to tag on the A if they already have one in-cache.) Erik --001a113ff0ccf2d18505300e9cbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 9, 2016 at 10:11 AM, Mark Smith <markzzz= smith@gmail.com> wrote:


On 9 Apr 2016 8:55 PM, "Sander Steffann" <sander@steffann.nl> wrote:
>

> Perhaps the opposite would be better - s= ending an AAAA query would result in an AAAA and A answer. That might creat= e a small and subtle incentive to use and prefer IPv6, with Happy Eyeballs = covering over IPv6 failures.

=C2=A0
+1 <= br>
Motivations to do this alongside AAAA query responses rat= her than A queries:
  • Encourage sending AAAA queries first (genera= lly a good practice)
  • Don't penalize devices that receive dual-s= tacked connectivity and do both AAAA and A lookups in cases when the A look= up gets dropped.
  • Helps DNS64 in the case of a NOERROR for the A= AAA if the corresponding A record can be carried alongside.=C2=A0 Although.= .. Pros: helps for dual-stacked clients with IPv4-only content.=C2=A0 Cons:= removes a tiny motivation to dual-stack (in cases where clients behind DNS= 64 only do a AAAA lookup having a AAAA record improves DNS lookup time duri= ng DNS cache misses).
If we also look at something = like this for stubs to resolvers, once enough resolvers implement this it c= ould let stubs do AAAA lookups serially and only kick off a A lookup if no = AAAA (or an empty AAAA with no A additional) is returned.=C2=A0 (Although i= t would be undesirable for servers to wait for a A record before returning = a AAAA record, so they'd only want to tag on the A if they already have= one in-cache.)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik


--001a113ff0ccf2d18505300e9cbb-- From nobody Mon Apr 11 09:22:21 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC20112D09D; Sat, 9 Apr 2016 00:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_FAIL=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfZQ3PMfzY-p; Sat, 9 Apr 2016 00:55:34 -0700 (PDT) Received: from mail.gguy.me (2001-44b8-314b-5f01-62a4-4cff-fe5f-1144.static.ipv6.internode.on.net [IPv6:2001:44b8:314b:5f01:62a4:4cff:fe5f:1144]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F392512D0C7; Sat, 9 Apr 2016 00:55:33 -0700 (PDT) Received: from [192.168.1.102] (ppp59-167-129-219.static.internode.on.net [59.167.129.219]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.gguy.me (Postfix) with ESMTPSA id 17EE536200BB; Sat, 9 Apr 2016 17:55:31 +1000 (AEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Geordie Guy X-Mailer: iPhone Mail (13E234) In-Reply-To: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> Date: Sat, 9 Apr 2016 17:55:30 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <07119903-475A-4D7E-848D-3320C1AB546C@gguy.me> References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> To: otroan@employees.org Archived-At: X-Mailman-Approved-At: Mon, 11 Apr 2016 09:22:19 -0700 Cc: v6ops list , 6man WG Subject: Re: [v6ops] DNS AAAA for free X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 07:55:36 -0000 This is genuinely awesome.=20 Geordie Sent from my mobile. Please excuse any unusual brevity or typos while I'm on= the go.=20 > On 8 Apr 2016, at 9:27 PM, otroan@employees.org wrote: >=20 > Here is an interesting draft being presented in dnsop today. > https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?includ= e_text=3D1 >=20 > The proposal is to allow AAAA records in response to A queries. >=20 > Best regards, > Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Apr 11 09:22:24 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57FF12B006; Sat, 9 Apr 2016 07:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQs-UXVcYPWH; Sat, 9 Apr 2016 07:32:56 -0700 (PDT) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E6A12009C; Sat, 9 Apr 2016 07:32:56 -0700 (PDT) Received: from [192.168.1.44] ([68.41.30.73]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0Lhwwu-1bc04e1ZTe-00n9FX; Sat, 09 Apr 2016 16:32:50 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D86F9F83-0695-4243-A2DB-E6C5CEF6F5F7"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: James R Cutler In-Reply-To: <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> Date: Sat, 9 Apr 2016 10:32:38 -0400 Message-Id: References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> To: otroan@employees.org X-Mailer: Apple Mail (2.3124) X-Provags-ID: V03:K0:7rmSkndSw0EZSZnsxx8K+v7Uw70VJNQCS5MFP15vq9HANoSPC6h I2AfiiFKuBjHW5AK7HTpEoOFdPb+NT1/hCTSIKEV15VYqYreQjlQon+F7UAjsrxsC+WLs2Y AvSBPo+efpkUWI3qDjTqC9nhSJdvjqoCpZslTnZiJgwE3R01tbCmxqnaVLQjOggB37hbhZx Vx7bVPbKjlykcdZyF7wvw== X-UI-Out-Filterresults: notjunk:1;V01:K0:OmGe4s2nb2M=:XDEl8/LLCI0ht2bKsVQQ/T R6RgG5yD1OlSog26LsoyW+6+y3ZsAPwmgQ4D1ENVy3ElYoNEKzXuPmkjt0Q+qgSnY7NQWixxr 5pmcmC6n7U2HYb3jkEgrpdJEqIO8HMXRQI/co6BippiFbWipxnRpVtjeaOMQ5DH4KIAITlfFy yk7XKvHU/WbIcJx5VPe0th+mG7g0b5KQ9V9Gstq/2CWvMkGXiRjIcDQw4iRiQCMZLltva0mzC amo2xORifW2AeLNv/mWF4dZri8CG+ZjoQHW5bi3ozDnEQOJZQ52JNBnD2L4przFcVQsyxIjob Nh9uuqLbtG/uGpG6GpfQY6U63dCHWml5sZySc1UAMkLgy5QmCqt3+CE/pBlZfie2k7BDAVzVU yqH/VnpEFubE8ufUM7jhPyhoWHD142yppT3Y35wJybndj8tTdjpZa9yaQ14pGY3S8qzIgUEFL /ewfIe7aSihVWUlahvgwjS48igfPmdDCc55hO2vAVtvCtU95VN5GRNjnnrruMoN6O+ayVxHw6 vpDwg7sS/rKowSQcdk4OqVj+bZYREjIG53KbLCtJbMdl6K5BsXW19OG08pud+icmBLwv6FyKQ eCvpe605eMw6OXSnobLDkudeBMckhP76AWqix0LcP2sc7BCmAqa6p5Wv/mGsGmdotOCYbh76u 2h0zGuESkfJ6x+yLlRR4Q2JCgHot9FKPobvr7warR8HPq4bhqnCPSeJhKCA/rjw0MYGbasmvS LMTOOYuOT7HaXu+LaMvJCm3dNUuRDvMXAOuzqm6U4616ghbo6NA5uAh6aN8= Archived-At: X-Mailman-Approved-At: Mon, 11 Apr 2016 09:22:19 -0700 Cc: v6ops list , 6man WG Subject: Re: [v6ops] DNS AAAA for free X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 14:32:58 -0000 --Apple-Mail=_D86F9F83-0695-4243-A2DB-E6C5CEF6F5F7 Content-Type: multipart/alternative; boundary="Apple-Mail=_D1086BC1-89DC-4F3B-B35D-3F71EAB14EFE" --Apple-Mail=_D1086BC1-89DC-4F3B-B35D-3F71EAB14EFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 08 Apr 2016, at 13:27, otroan@employees.org = wrote: >=20 > Here is an interesting draft being presented in dnsop today. > = https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?includ= e_text=3D1 = >=20 > The proposal is to allow AAAA records in response to A queries. In most conversations it is considered polite to answer the question = asked and not to provide confusing extra data. This proposal violates = that. James R. Cutler James.cutler@consultant.com PGP keys at http://pgp.mit.edu --Apple-Mail=_D1086BC1-89DC-4F3B-B35D-3F71EAB14EFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 08 Apr 2016, at = 13:27, otroan@employees.org wrote:

Here is an interesting draft being presented = in dnsop today.
https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-f= ree/?include_text=3D1

The proposal is = to allow AAAA records in response to A = queries.

In most = conversations it is considered polite to answer the question asked and = not to provide confusing extra data. This proposal violates = that.

James R. Cutler
James.cutler@consultant.com
PGP keys at http://pgp.mit.edu


= = --Apple-Mail=_D1086BC1-89DC-4F3B-B35D-3F71EAB14EFE-- --Apple-Mail=_D86F9F83-0695-4243-A2DB-E6C5CEF6F5F7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.28 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXCRKPAAoJEFTPx1V3wJTLVwkQALKKmm9Y3HCQCj7mGreB2oOk tt8+oD66HQzpjzsJCpQmkhJrSIkobhmOIi1k87XAN2GmNRcUZ03yvfhQD/Hs4AtY nfBESZ7P6/5UsJR551MRaZbUyKurQRBOlKGqVJOWW3FopljbmXRThd6RzE2VR9az qlVHIvkBKl/euKJAsSa0FqwTSk825q2uCctyf/Z0R8Rl503I//DHIXEiaX2o4xb/ gIeKa/SwGuC4sXd9mtvBRMcjQny+SEepLGSU270/Db2bGsxeBbUmnInG3TA1Jq2+ ZdnT6R6LixHXdjUzYAQSUne8qM6dhaZI6K0O7SMuLP9KWd7QIuCimn8xAfwdDin0 rp2qTAfAEwVUjKt58g1i3D7VMaMdDmKhKSncC9daWyBOm8AieS1T017uOqXxvFSq 8i9TAOzcYeDmLhTzd4opYecpG73vLcW+VkIRI/hdi0boSV/GBQFOGlhQFscFYA5B 9KHmKwgN84gVaEfLeWvdr4hq5175g8MfwAFL1D8yBK1an39gvWRZIMJ0FyiRjQKf QaKgqImGrQZafWH9LQpCrS1wntmO3YOSK2gNT+n5a82UGfxDC8Kmjrgf/a4z5Iv7 /1rEGO93mj9DTLmYzh1jg2kA2oBFqk5jvxxVFkEr1JLwiRFgf8+5NMjdJklg+cqc dBeUDsak3Ulsu2t+4H7G =KVNn -----END PGP SIGNATURE----- --Apple-Mail=_D86F9F83-0695-4243-A2DB-E6C5CEF6F5F7-- From nobody Mon Apr 11 11:16:11 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A1512E6A6; Mon, 11 Apr 2016 11:16:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160411181608.13173.86256.idtracker@ietfa.amsl.com> Date: Mon, 11 Apr 2016 11:16:08 -0700 Archived-At: Cc: v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world@ietf.org, v6ops-chairs@ietf.org, draft-ietf-v6ops-ipv6-ehs-in-real-world.all@tools.ietf.org, The IESG , joelja@gmail.com, rfc-editor@rfc-editor.org Subject: [v6ops] Document Action: 'Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World' to Informational RFC (draft-ietf-v6ops-ipv6-ehs-in-real-world-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 18:16:08 -0000 The IESG has approved the following document: - 'Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World' (draft-ietf-v6ops-ipv6-ehs-in-real-world-02.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-in-real-world/ Technical Summary This document presents real-world data regarding the extent to which packets with IPv6 extension headers are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results), and where in the network such dropping occurs The document is an informational draft, intended it to solicit operational advice on treatment of packets with EH. Working Group Summary Interest level has varied; related work was presented at IEPG and v6ops besides this draft. About 250 mailing list comments from more than 30 people over 16 months, good discussion at several WG meetings. During WGLC there were affirmative comments, some nits which have been addressed. There were some controversial elements, but they have been addressed. The document makes no recommendations; the WG is considering another document, and may suggest 6man work. There have been no formal reviews, nor do I think any are necessary. Document Quality The authors tested several kinds of EH packets to many hosts on many networks. The described results; may be taken as a problem statement, or simply as feedback to the IETF on the success of Extension Headers. Personnel Shepherd: Lee Howard AD: Joel Jaeggli From nobody Mon Apr 11 19:24:37 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C6912DDF9 for ; Mon, 11 Apr 2016 19:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr-DqOuegCUl for ; Mon, 11 Apr 2016 19:24:34 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8AD12DDF6 for ; Mon, 11 Apr 2016 19:24:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u3C2Of9v015172; Mon, 11 Apr 2016 19:24:41 -0700 Received: from XCH-BLV-508.nw.nos.boeing.com (xch-blv-508.nw.nos.boeing.com [130.247.25.198]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u3C2Odhc015158 (version=TLSv1/SSLv3 cipher=AES128-SHA256 bits=128 verify=OK); Mon, 11 Apr 2016 19:24:40 -0700 Received: from XCH-BLV-105.nw.nos.boeing.com ([169.254.5.181]) by XCH-BLV-508.nw.nos.boeing.com ([169.254.8.20]) with mapi id 14.03.0294.000; Mon, 11 Apr 2016 19:24:29 -0700 From: "Templin, Fred L" To: Philip Homburg , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-van-beijnum-multi-mtu-05 Thread-Index: AQHRkZSYCfF8V9rGy06Uh6bxuf0qbZ+FoSfw Date: Tue, 12 Apr 2016 02:24:29 +0000 Message-ID: <2134F8430051B64F815C691A62D9831835902D27@XCH-BLV-105.nw.nos.boeing.com> References: <5703ABF9.2000907@foobar.org> <20160406153142.GU56633@Space.Net> <570534CC.3020603@foobar.org> <5706E181.50208@foobar.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-van-beijnum-multi-mtu-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 02:24:36 -0000 Hi, > Yes, we have a PMTU problem. But the logical conclusion of giving in to t= hat, > is that every link will run at 1280. Or, the middle boxes start messing > with TCP MSS options, just like they do for IPv4. If every link runs at 1280, then tunnels will be forced to fragment. Thanks - Fred fred.l.templin@boeing.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Apr 12 08:08:17 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919C012EECF for ; Tue, 12 Apr 2016 08:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=longwinters-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBa29QL2cCJf for ; Tue, 12 Apr 2016 08:08:15 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3930912EEC2 for ; Tue, 12 Apr 2016 08:08:15 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id o126so32064793iod.0 for ; Tue, 12 Apr 2016 08:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longwinters-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=g99OEgE3FeXaglNM9z4SRpSiUYhBnfEI/UY3kz4O+4g=; b=Bp1j/YmmONbhtRuPHp2KOjcM3V0WEZoD6R+uxRjUqP6wzqvW8aZX+CHwSMlyF1MDr5 IJqMymJi7+S2MBCUTbrGR5l4/rahEWkvKFNYva2kOmbNaHmmvPBBl+PibpkLV56E83YE sxtTbIy6Zm0SsRSQq3u0KrYlAG+NYHkl/WIdCiEpn7sLcN/d3LzdBDBmFnCDsghOm/6L EwNZNcYpyH89GD8m8W4TFFME0NmOtcAzI0CTmRgVMWRIzX32l2+1HrB+kFBcZSv75Xtj QHy2hcb/M0ne1Lp2F9hVEGlDYncgy6NsC+YkRA5qvXpT8pL1JTyv+vzc8N1Y3pj1zvP1 v3jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=g99OEgE3FeXaglNM9z4SRpSiUYhBnfEI/UY3kz4O+4g=; b=UJ4DGn/AdvPb5IIrs93EgXa34KUk2VphNw4ReaoEmi5okr0vdKo7qREhyRppKFc8Vv arFf9RszFaNUbOa0xxV5+mxbgraXh0auenAkstBytljkf19uzaUNekHQ0CMXalTC+VzE Cb1vdWyy7UVWgnzdkq0P2W0hFmdwTEGiHxu+fGMrFxYD5yrntuKx2jlHELFY5W8ZUy5e 1M7FH2HkJQl+DXO1L9fUlKy2rf8gSjFBUL6BU7p0GT8ruHqCmoVoD9CA+wdfLLDYP6/7 0vNdtRFeZLpASzogrk4+pmrz/7cHmqD9pjd2YpoMCUha4WO18EwIEV+p7Fji+JMT6eJK vfCw== X-Gm-Message-State: AOPr4FUxgJjR4xZYmdqDuS3ipcn6ahjiTl2T+U/TZhjs/KHW/QiCsituDU6G7rEQGNO4WA== X-Received: by 10.107.164.100 with SMTP id n97mr4583689ioe.93.1460473694345; Tue, 12 Apr 2016 08:08:14 -0700 (PDT) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com. [209.85.213.169]) by smtp.gmail.com with ESMTPSA id m37sm20689709ioi.3.2016.04.12.08.08.13 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2016 08:08:13 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id gy3so110003920igb.1 for ; Tue, 12 Apr 2016 08:08:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.64.179 with SMTP id p19mr4526643igs.25.1460473693181; Tue, 12 Apr 2016 08:08:13 -0700 (PDT) Received: by 10.50.205.7 with HTTP; Tue, 12 Apr 2016 08:08:13 -0700 (PDT) In-Reply-To: References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> <07119903-475A-4D7E-848D-3320C1AB546C@gguy.me> Date: Tue, 12 Apr 2016 08:08:13 -0700 X-Gmail-Original-Message-ID: Message-ID: From: Robert To: Erik Kline , otroan@employees.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] DNS AAAA for free X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 15:08:16 -0000 On 9 April 2016 at 01:07, Erik Kline wrote: > So far I fail to see the benefit. > > Host that think they can do IPv6 generally ask for AAAAs first, or > nearly simultaneously with As if they're doing connection racing. So > I don't see how this helps. There's a bit of an explanation in the RFC, which I think boils down to: a) stub resolvers on dual stack hosts issue two DNS queries, but treat it as a single request so if either response is lost the stub resolver will try the whole thing again b) maybe your resolver is anycast and the two queries end up different hosts I was a little skeptical of the impact of "a)" so I wrote up a quick getaddrinfo program and tested it out on what I had handy by blocking either A or AAAA queries from the client. Linux (glibc 2.22): No blocking: 0.002s Blocking AAAA: 15.019s Blocking A: getaddrinfo: Temporary failure in name resolution FreeBSD 10.3: No blocking: 0.002s Blocking AAAA: 15.036s Blocking A: 15.047s MacOSX 10.11.4 (on wifi): No blocking: 0.008s Blocking AAAA: 5.016s Blocking A: 30.079s So yeah, in the worst case you can really impact performance of getaddrinfo. Even in the normal case, getaddrinfo sends two queries and is bounded by the worst, so the client is twice as likely to see failure. I'm not sold that returning AAAAs in A is the right thing, it seems like returning As in AAAA would be a better mode of operation. Fewer clients that would need to be updated, encourages checking for AAAAs first and could save you the second lookup. As the draft is written today, I feel like in 20 years people will be wondering why everything does a A query and only ever gets back AAAA data. From nobody Tue Apr 12 08:59:13 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAC912D893; Tue, 12 Apr 2016 08:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsR2gFJy4fIg; Tue, 12 Apr 2016 08:59:09 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04B812D5EF; Tue, 12 Apr 2016 08:59:08 -0700 (PDT) Received: from [85.158.137.67] by server-12.bemta-3.messagelabs.com id B1/E6-19343-A4B1D075; Tue, 12 Apr 2016 15:59:06 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFKsWRWlGSWpSXmKPExsUy9d9HH11Pad5 wg5mrlC3mv1vNZPHy7Hsmi51HjrJbnD62l9mBxWPnrLvsHkuW/GTyWPX4InsAcxRrZl5SfkUC a8anb98YCxZPZKxYueEmawPjkn7GLkZODiGBTYwSN78lQtgHGCWmXLHuYuQCsk8wStz5t4cdJ MEmoCvRPmsVM4gtIuAtsf7IDRYQm1nAQuLm891AcQ4OYQE1iV/TykBMEQF1iQvH0yCq3SSW/3 rICmKzCKhK7Hh4hw3E5hUIlfh04ggbxKoGJonGth4WkF5OgUCJ92s1QGoYBWQlvjSuZobYJC5 x68l8JhBbQkBAYsme88wQtqjEy8f/WCFsBYlLi7pYIerzJDb33oLaJShxcuYTlgmMIrOQjJqF pGwWkrJZQFcwC2hKrN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWMGsWpRWWpRbqGpnpJRZnpG SW5iZk5uoYGxnq5qcXFiempOYlJxXrJ+bmbGIHxyAAEOxjXbPc8xCjJwaQkynvwPU+4EF9Sfk plRmJxRnxRaU5q8SFGGQ4OJQne+5K84UKCRanpqRVpmTnAxACTluDgURLh/QqS5i0uSMwtzky HSJ1i1OX40XF/LZMQS15+XqqUOO8TkCIBkKKM0jy4EbAkdYlRVkqYlxHoKCGegtSi3MwSVPlX jOIcjErCvM9BpvBk5pXAbXoFdAQT0BHP/nGCHFGSiJCSamDM0jZ7bGV6SKigXMFu7Uv3iVp57 H3x7GbJ8tIOCpM6H75asMn5b+iHuVYHutgPBVkrCxxx+czVfYmtzNhd/LvfzON8Fl8CFM0kn2 ZvbH0rK/YrtXKPeq/c0tSnp86nT73HtShwRp9X9pGHAi1zNrRlPJ19InvmP2aPzdkzwpibYk7 vSLAUNlViKc5INNRiLipOBAD2RE53TQMAAA== X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-14.tower-139.messagelabs.com!1460476745!14430706!1 X-Originating-IP: [149.254.241.76] X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19767 invoked from network); 12 Apr 2016 15:59:05 -0000 Received: from unknown (HELO smtpml01.ee.co.uk) (149.254.241.76) by server-14.tower-139.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Apr 2016 15:59:05 -0000 Received: from EEUKWV0940.EEAD.EEINT.CO.UK (Not Verified[10.246.209.217]) by smtpml01.ee.co.uk with MailMarshal (v7, 2, 3, 6978) id ; Tue, 12 Apr 2016 16:58:54 +0100 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by EEUKWV0940.EEAD.EEINT.CO.UK with Trustwave SEG (v7, 3, 6, 7949) id ; Tue, 12 Apr 2016 16:59:03 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a56::62c:2a56]) with mapi id 14.03.0195.001; Tue, 12 Apr 2016 16:59:03 +0100 From: "Heatley, Nick" To: Erik Nygren , Mark Smith Thread-Topic: [v6ops] DNS AAAA for free Thread-Index: AQHRkYm/HWFaQj7wFUyUNYlvePqZ/J+BaLSAgAAmB4CAAB9aAIAEzP7A Date: Tue, 12 Apr 2016 15:59:03 +0000 Message-ID: <6536E263028723489CCD5B6821D4B213170F6D7C@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: multipart/alternative; boundary="_000_6536E263028723489CCD5B6821D4B213170F6D7CUK30S005EXS06EE_" MIME-Version: 1.0 Archived-At: Cc: v6ops list , 6man WG Subject: Re: [v6ops] DNS AAAA for free X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 15:59:11 -0000 --_000_6536E263028723489CCD5B6821D4B213170F6D7CUK30S005EXS06EE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpbmtpbmcgZnVydGhlciBvbiBETlM2NCBhbmQgdGhlIGNvbXBhdGliaWxpdHkgKGxpbWl0YXRp b25zKSBvZiBETlNTRUMgd2l0aCBETlM2NCwgSSB3YXMgd29uZGVyaW5nIGlmIHRoZSBhZGRpdGlv bmFsIEEgcmVjb3JkIGluIGFuIEFBQUEgcXVlcnkgY291bGQgYWRkIHZhbHVlIGhlcmU/DQoNCkEg c3R1YiByZXNvbHZlciB0aGF0IHN1cHBvcnRzIGxvY2FsIHN5bnRoZXNpcyBvZiBBQUFBIHJlY29y ZHMsIHNvIGRvZXMgbm90IHJlcXVpcmUgRE5TNjQgZnJvbSB0aGUgbmV0d29yaywgY291bGQgdXNl IHRoZSBBIHJlY29yZCBmb3Igc3ludGhlc2lzLg0KSW4gYSBuZXR3b3JrIHdpdGggc2VjdXJpdHkg YXdhcmUgUkROU1MgdGhlbiB0aGUgc3R1YiByZXNvbHZlciBjYW4gcmVxdWVzdCBvbmx5IEFBQUEs IHNldCB0aGUgRE8gYml0LCBhbmQgIGNhbiBnZXQgdGhlIEROU1NFQyBBIHJlY29yZCBiYWNrIChp cyB0aGlzIHRydWU/KQ0KU28gaXQgY2FuIGhlbHAgd2l0aCBjb21wYXRpYmlsaXR5IG9mIEROU1NF QyBvbiBzdHViIHJlc29sdmVycywgd2hlbiBsb2NhbCBzeW50aGVzaXMgaXMgc3VwcG9ydGVkIGFu ZCBzb21lIHN0YWJsZSBlcXVpbGlicml1bSBjYW4gYmUgZm91bmQgYmV0d2VlbiBuZWVkIGZvciBE TlM2NCBhbmQgZGVzaXJlIGZvciBETlNTRUMuDQpJcyBteSB0aGlua2luZyBjb3JyZWN0Pw0KDQpG cm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBF cmlrIE55Z3Jlbg0KU2VudDogMDkgQXByaWwgMjAxNiAxNjowMw0KVG86IE1hcmsgU21pdGgNCkNj OiA2bWFuIFdHOyB2Nm9wcyBsaXN0DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBETlMgQUFBQSBmb3Ig ZnJlZQ0KDQpPbiBTYXQsIEFwciA5LCAyMDE2IGF0IDEwOjExIEFNLCBNYXJrIFNtaXRoIDxtYXJr enp6c21pdGhAZ21haWwuY29tPG1haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tPj4gd3JvdGU6 DQoNCk9uIDkgQXByIDIwMTYgODo1NSBQTSwgIlNhbmRlciBTdGVmZmFubiIgPHNhbmRlckBzdGVm ZmFubi5ubDxtYWlsdG86c2FuZGVyQHN0ZWZmYW5uLm5sPj4gd3JvdGU6DQo+DQoNCj4gUGVyaGFw cyB0aGUgb3Bwb3NpdGUgd291bGQgYmUgYmV0dGVyIC0gc2VuZGluZyBhbiBBQUFBIHF1ZXJ5IHdv dWxkIHJlc3VsdCBpbiBhbiBBQUFBIGFuZCBBIGFuc3dlci4gVGhhdCBtaWdodCBjcmVhdGUgYSBz bWFsbCBhbmQgc3VidGxlIGluY2VudGl2ZSB0byB1c2UgYW5kIHByZWZlciBJUHY2LCB3aXRoIEhh cHB5IEV5ZWJhbGxzIGNvdmVyaW5nIG92ZXIgSVB2NiBmYWlsdXJlcy4NCg0KKzENCk1vdGl2YXRp b25zIHRvIGRvIHRoaXMgYWxvbmdzaWRlIEFBQUEgcXVlcnkgcmVzcG9uc2VzIHJhdGhlciB0aGFu IEEgcXVlcmllczoNCg0KICAqICAgRW5jb3VyYWdlIHNlbmRpbmcgQUFBQSBxdWVyaWVzIGZpcnN0 IChnZW5lcmFsbHkgYSBnb29kIHByYWN0aWNlKQ0KICAqICAgRG9uJ3QgcGVuYWxpemUgZGV2aWNl cyB0aGF0IHJlY2VpdmUgZHVhbC1zdGFja2VkIGNvbm5lY3Rpdml0eSBhbmQgZG8gYm90aCBBQUFB IGFuZCBBIGxvb2t1cHMgaW4gY2FzZXMgd2hlbiB0aGUgQSBsb29rdXAgZ2V0cyBkcm9wcGVkLg0K ICAqICAgSGVscHMgRE5TNjQgaW4gdGhlIGNhc2Ugb2YgYSBOT0VSUk9SIGZvciB0aGUgQUFBQSBp ZiB0aGUgY29ycmVzcG9uZGluZyBBIHJlY29yZCBjYW4gYmUgY2FycmllZCBhbG9uZ3NpZGUuICBB bHRob3VnaC4uLiBQcm9zOiBoZWxwcyBmb3IgZHVhbC1zdGFja2VkIGNsaWVudHMgd2l0aCBJUHY0 LW9ubHkgY29udGVudC4gIENvbnM6IHJlbW92ZXMgYSB0aW55IG1vdGl2YXRpb24gdG8gZHVhbC1z dGFjayAoaW4gY2FzZXMgd2hlcmUgY2xpZW50cyBiZWhpbmQgRE5TNjQgb25seSBkbyBhIEFBQUEg bG9va3VwIGhhdmluZyBhIEFBQUEgcmVjb3JkIGltcHJvdmVzIEROUyBsb29rdXAgdGltZSBkdXJp bmcgRE5TIGNhY2hlIG1pc3NlcykuDQpJZiB3ZSBhbHNvIGxvb2sgYXQgc29tZXRoaW5nIGxpa2Ug dGhpcyBmb3Igc3R1YnMgdG8gcmVzb2x2ZXJzLCBvbmNlIGVub3VnaCByZXNvbHZlcnMgaW1wbGVt ZW50IHRoaXMgaXQgY291bGQgbGV0IHN0dWJzIGRvIEFBQUEgbG9va3VwcyBzZXJpYWxseSBhbmQg b25seSBraWNrIG9mZiBhIEEgbG9va3VwIGlmIG5vIEFBQUEgKG9yIGFuIGVtcHR5IEFBQUEgd2l0 aCBubyBBIGFkZGl0aW9uYWwpIGlzIHJldHVybmVkLiAgKEFsdGhvdWdoIGl0IHdvdWxkIGJlIHVu ZGVzaXJhYmxlIGZvciBzZXJ2ZXJzIHRvIHdhaXQgZm9yIGEgQSByZWNvcmQgYmVmb3JlIHJldHVy bmluZyBhIEFBQUEgcmVjb3JkLCBzbyB0aGV5J2Qgb25seSB3YW50IHRvIHRhZyBvbiB0aGUgQSBp ZiB0aGV5IGFscmVhZHkgaGF2ZSBvbmUgaW4tY2FjaGUuKQ0KICAgICAgICAgICAgIEVyaWsNCg0K DQoNCk5PVElDRSBBTkQgRElTQ0xBSU1FUg0KVGhpcyBlbWFpbCBjb250YWlucyBCVCBpbmZvcm1h dGlvbiwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBJdCdzIG1lYW50 IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gDQpJZiB5 b3UncmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGUgdGhhdCBkaXNjbG9zaW5nLCBj b3B5aW5nLCBkaXN0cmlidXRpbmcgb3IgdXNpbmcgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJp dGVkLiANCklmIHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2UgbGV0 IG1lIGtub3cgaW1tZWRpYXRlbHkgb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5rIHlv dS4NCg0KV2UgbW9uaXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29yZCB5b3VyIGVt YWlscy4NCg0KRUUgTGltaXRlZCANClJlZ2lzdGVyZWQgb2ZmaWNlOlRyaWRlbnQgUGxhY2UsIE1v c3F1aXRvIFdheSwgSGF0ZmllbGQsIEhlcnRmb3Jkc2hpcmUsIEFMMTAgOUJXDQpSZWdpc3RlcmVk IGluIEVuZ2xhbmQgbm86IDAyMzgyMTYxDQoNCkVFIExpbWl0ZWQgaXMgYSB3aG9sbHkgb3duZWQg c3Vic2lkaWFyeSBvZjoNCg0KQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjDQpSZWdpc3Rl cmVkIG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKDQpSZWdpc3RlcmVk IGluIEVuZ2xhbmQgbm86IDE4MDAwMDANCg== --_000_6536E263028723489CCD5B6821D4B213170F6D7CUK30S005EXS06EE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1HQjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6NDQxNjU1NzEyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDc2NjY3NjQ4 O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDox MDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODgu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpbmtpbmcgZnVydGhlciBvbiBETlM2NCBhbmQg dGhlIGNvbXBhdGliaWxpdHkgKGxpbWl0YXRpb25zKSBvZiBETlNTRUMgd2l0aCBETlM2NCwgSSB3 YXMgd29uZGVyaW5nIGlmIHRoZSBhZGRpdGlvbmFsIEEgcmVjb3JkIGluIGFuIEFBQUEgcXVlcnkg Y291bGQgYWRkIHZhbHVlDQogaGVyZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkEgc3R1YiByZXNvbHZlciB0aGF0IHN1 cHBvcnRzIGxvY2FsIHN5bnRoZXNpcyBvZiBBQUFBIHJlY29yZHMsIHNvIGRvZXMgbm90IHJlcXVp cmUgRE5TNjQgZnJvbSB0aGUgbmV0d29yaywgY291bGQgdXNlIHRoZSBBIHJlY29yZCBmb3Igc3lu dGhlc2lzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIGEgbmV0d29yayB3aXRo IHNlY3VyaXR5IGF3YXJlIFJETlNTIHRoZW4gdGhlIHN0dWIgcmVzb2x2ZXIgY2FuIHJlcXVlc3Qg b25seSBBQUFBLCBzZXQgdGhlIERPIGJpdCwgYW5kICZuYnNwO2NhbiBnZXQgdGhlIEROU1NFQyBB IHJlY29yZCBiYWNrIChpcyB0aGlzIHRydWU/KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5TbyBpdCBjYW4gaGVscCB3aXRoIGNvbXBhdGliaWxpdHkgb2YgRE5TU0VDIG9uIHN0dWIgcmVz b2x2ZXJzLCB3aGVuIGxvY2FsIHN5bnRoZXNpcyBpcyBzdXBwb3J0ZWQgYW5kIHNvbWUgc3RhYmxl IGVxdWlsaWJyaXVtIGNhbiBiZSBmb3VuZCBiZXR3ZWVuIG5lZWQgZm9yIEROUzY0DQogYW5kIGRl c2lyZSBmb3IgRE5TU0VDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JcyBteSB0aGlu a2luZyBjb3JyZWN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWsgTnlncmVuPGJyPg0KPGI+U2VudDo8L2I+ IDA5IEFwcmlsIDIwMTYgMTY6MDM8YnI+DQo8Yj5Ubzo8L2I+IE1hcmsgU21pdGg8YnI+DQo8Yj5D Yzo8L2I+IDZtYW4gV0c7IHY2b3BzIGxpc3Q8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9w c10gRE5TIEFBQUEgZm9yIGZyZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBTYXQsIEFwciA5LCAyMDE2IGF0IDEwOjExIEFNLCBNYXJrIFNtaXRoICZsdDs8YSBocmVm PSJtYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcmt6enpz bWl0aEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxwPjxicj4NCk9uIDkgQXByIDIwMTYgODo1NSBQTSwgJnF1b3Q7U2Fu ZGVyIFN0ZWZmYW5uJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2FuZGVyQHN0ZWZmYW5uLm5s IiB0YXJnZXQ9Il9ibGFuayI+c2FuZGVyQHN0ZWZmYW5uLm5sPC9hPiZndDsgd3JvdGU6PGJyPg0K Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHA+Jmd0OyBQZXJoYXBzIHRoZSBvcHBvc2l0ZSB3b3VsZCBi ZSBiZXR0ZXIgLSBzZW5kaW5nIGFuIEFBQUEgcXVlcnkgd291bGQgcmVzdWx0IGluIGFuIEFBQUEg YW5kIEEgYW5zd2VyLiBUaGF0IG1pZ2h0IGNyZWF0ZSBhIHNtYWxsIGFuZCBzdWJ0bGUgaW5jZW50 aXZlIHRvIHVzZSBhbmQgcHJlZmVyIElQdjYsIHdpdGggSGFwcHkgRXllYmFsbHMgY292ZXJpbmcg b3ZlciBJUHY2IGZhaWx1cmVzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mIzQz OzEgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N b3RpdmF0aW9ucyB0byBkbyB0aGlzIGFsb25nc2lkZSBBQUFBIHF1ZXJ5IHJlc3BvbnNlcyByYXRo ZXIgdGhhbiBBIHF1ZXJpZXM6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkVuY291cmFnZSBz ZW5kaW5nIEFBQUEgcXVlcmllcyBmaXJzdCAoZ2VuZXJhbGx5IGEgZ29vZCBwcmFjdGljZSk8bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+DQpEb24ndCBwZW5hbGl6ZSBkZXZpY2VzIHRoYXQgcmVjZWl2ZSBkdWFsLXN0YWNrZWQgY29u bmVjdGl2aXR5IGFuZCBkbyBib3RoIEFBQUEgYW5kIEEgbG9va3VwcyBpbiBjYXNlcyB3aGVuIHRo ZSBBIGxvb2t1cCBnZXRzIGRyb3BwZWQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSGVscHMgRE5TNjQgaW4gdGhlIGNhc2Ug b2YgYSBOT0VSUk9SIGZvciB0aGUgQUFBQSBpZiB0aGUgY29ycmVzcG9uZGluZyBBIHJlY29yZCBj YW4gYmUgY2FycmllZCBhbG9uZ3NpZGUuJm5ic3A7IEFsdGhvdWdoLi4uIFByb3M6IGhlbHBzIGZv ciBkdWFsLXN0YWNrZWQgY2xpZW50cyB3aXRoIElQdjQtb25seSBjb250ZW50LiZuYnNwOyBDb25z OiByZW1vdmVzIGEgdGlueSBtb3RpdmF0aW9uIHRvIGR1YWwtc3RhY2sgKGluIGNhc2VzIHdoZXJl IGNsaWVudHMgYmVoaW5kDQogRE5TNjQgb25seSBkbyBhIEFBQUEgbG9va3VwIGhhdmluZyBhIEFB QUEgcmVjb3JkIGltcHJvdmVzIEROUyBsb29rdXAgdGltZSBkdXJpbmcgRE5TIGNhY2hlIG1pc3Nl cykuPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPklmIHdlIGFsc28gbG9vayBhdCBzb21l dGhpbmcgbGlrZSB0aGlzIGZvciBzdHVicyB0byByZXNvbHZlcnMsIG9uY2UgZW5vdWdoIHJlc29s dmVycyBpbXBsZW1lbnQgdGhpcyBpdCBjb3VsZCBsZXQgc3R1YnMgZG8gQUFBQSBsb29rdXBzIHNl cmlhbGx5IGFuZCBvbmx5IGtpY2sgb2ZmIGEgQSBsb29rdXAgaWYgbm8gQUFBQSAob3IgYW4gZW1w dHkgQUFBQSB3aXRoDQogbm8gQSBhZGRpdGlvbmFsKSBpcyByZXR1cm5lZC4mbmJzcDsgKEFsdGhv dWdoIGl0IHdvdWxkIGJlIHVuZGVzaXJhYmxlIGZvciBzZXJ2ZXJzIHRvIHdhaXQgZm9yIGEgQSBy ZWNvcmQgYmVmb3JlIHJldHVybmluZyBhIEFBQUEgcmVjb3JkLCBzbyB0aGV5J2Qgb25seSB3YW50 IHRvIHRhZyBvbiB0aGUgQSBpZiB0aGV5IGFscmVhZHkgaGF2ZSBvbmUgaW4tY2FjaGUuKTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEVyaWs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQoNCjxQPk5PVElDRSBB TkQgRElTQ0xBSU1FUjxCUj5UaGlzIGVtYWlsIGNvbnRhaW5zIEJUIGluZm9ybWF0aW9uLCB3aGlj aCBtYXkgYmUgDQpwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gSXQncyBtZWFudCBvbmx5IGZv ciB0aGUgaW5kaXZpZHVhbChzKSBvciBlbnRpdHkgDQpuYW1lZCBhYm92ZS4gPEJSPklmIHlvdSdy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90ZSB0aGF0IGRpc2Nsb3NpbmcsIA0KY29w eWluZywgZGlzdHJpYnV0aW5nIG9yIHVzaW5nIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRl ZC4gPEJSPklmIHlvdSd2ZSANCnJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBs ZXQgbWUga25vdyBpbW1lZGlhdGVseSBvbiB0aGUgZW1haWwgDQphZGRyZXNzIGFib3ZlLiBUaGFu ayB5b3UuPC9QPg0KPFA+V2UgbW9uaXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29y ZCB5b3VyIGVtYWlscy48L1A+DQo8UD5FRSBMaW1pdGVkIDxCUj5SZWdpc3RlcmVkIG9mZmljZTpU cmlkZW50IFBsYWNlLCBNb3NxdWl0byBXYXksIEhhdGZpZWxkLCANCkhlcnRmb3Jkc2hpcmUsIEFM MTAgOUJXPEJSPlJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBubzogMDIzODIxNjE8L1A+DQo8UD5FRSBM aW1pdGVkIGlzIGEgd2hvbGx5IG93bmVkIHN1YnNpZGlhcnkgb2Y6PC9QPg0KPFA+QnJpdGlzaCBU ZWxlY29tbXVuaWNhdGlvbnMgcGxjPEJSPlJlZ2lzdGVyZWQgb2ZmaWNlOiA4MSBOZXdnYXRlIFN0 cmVldCBMb25kb24gDQpFQzFBIDdBSjxCUj5SZWdpc3RlcmVkIGluIEVuZ2xhbmQgbm86IDE4MDAw MDA8L1A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6536E263028723489CCD5B6821D4B213170F6D7CUK30S005EXS06EE_-- From nobody Wed Apr 13 04:18:45 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2388912D540 for ; Wed, 13 Apr 2016 04:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHyiIHN5QjjY for ; Wed, 13 Apr 2016 04:18:37 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C9812D99F for ; Wed, 13 Apr 2016 04:18:36 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0010.outbound.protection.outlook.com [213.199.154.10]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-14-g5VLurNmR2CtKWyMbu2FoA-1; Wed, 13 Apr 2016 12:18:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MT2ydvn3qnxIY2wL/uktujSiz1CAt95uyB1PVjVUbE0=; b=ZENRZHvfPBlZXaZhv0svlXN4bvm60rGgAiNUI9TD3kZy8IJwuR3voOR1dTHwAkF+aLVxUmMXmQizX618EhqSGw0Gv47+CoevyHeqh0ZgMGcyTpcoE/GeFn4/0M2P/MdgBwQMluy6RD+kzheljEh+9YtEc1OkY4hE/1enIulCLqk= Received: from DBXPR07MB462.eurprd07.prod.outlook.com (10.141.231.140) by DBXPR07MB462.eurprd07.prod.outlook.com (10.141.231.140) with Microsoft SMTP Server (TLS) id 15.1.466.12; Wed, 13 Apr 2016 11:18:24 +0000 Received: from DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) by DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) with mapi id 15.01.0466.018; Wed, 13 Apr 2016 11:18:24 +0000 From: Tim Chown To: Mark Smith Thread-Topic: [v6ops] DNS AAAA for free Thread-Index: AQHRlXYxcVsCMD2MzkKuvkhxRo9AJg== Date: Wed, 13 Apr 2016 11:18:24 +0000 Message-ID: <90CC41CF-9F3D-44DB-8A23-AFB34321748E@jisc.ac.uk> References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org> <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:a93e:5914:9e35:ffe3] x-ms-office365-filtering-correlation-id: 6c3af208-809d-4f63-c3ec-08d3638d546c x-microsoft-exchange-diagnostics: 1; DBXPR07MB462; 5:wCXbP+QoJx16jcoCxQIHPHy2ZWBNs0gpURYlfE/kM/JJ6mC92Nr7XlYmqpVHKavWx5lHwgtSXeXgZ7mm3caeS9r1KU+52kRFsxLNQ/MKmxW5IaMK+Helxhc5ttMQ3ZRsbMiyeKu8NBucMPFyP7x2UkkYzrru+wDZ4gyVyymSyL4rp4D5rFqIiC8Tq912NjJ1; 24:sRbY82J7C0HnXDJ9pFmSQMaS/L9lWjsltV+khG4YvuuK2M3Hov7QvDdLtvMaJYQxVe4jvE9tQvt5Sr0jLym228RcBiVoeH2DSeVlNF23NXs=; 7:NXMN3f0t/ZOp7DqXpZ0hddnOHCfuqVd9CpdFwLSsywdSZWJVlswSaSAzUMghjgP1irIoNdF49NQ72FatxHCUzZT01n1HamTYh0mTQQWgfjWYOMiJTvG7bfr12RYA0unK/L6xB/EmM7JjIiNENwBInr6Jt6fxj++mmuVeHKIwzoFZUJ8v6Pxz+f5zbLsUSk/vRtHV3/7+FWA3OcD8GYXVfyar159Z4EA9k29ICptMzsU=; 20:Se+VsswdyLr2qGMEffw/RWyerve45cbdKf1+DxnZOU7WnfDcgrMzIzMyxOKxONTvYd5FYTiFBXzpJoKpAg+OEorXZpn2xmmlNEMq7XNcLBbtPIvVxqNSOAVchX71k5gM8I157AI/g0B1lLFdeLRfL/FN9j4hSmz19k5OYBg/gNc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB462; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DBXPR07MB462; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB462; x-forefront-prvs: 0911D5CE78 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(24454002)(3660700001)(82746002)(3280700002)(92566002)(561944003)(5008740100001)(33656002)(122556002)(2906002)(15975445007)(4326007)(74482002)(77096005)(81166005)(50226001)(2950100001)(19580405001)(86362001)(10400500002)(57306001)(110136002)(5004730100002)(16236675004)(189998001)(19580395003)(6116002)(586003)(106116001)(1220700001)(36756003)(50986999)(87936001)(1096002)(76176999)(19617315012)(83716003)(5002640100001)(102836003)(11100500001)(3826002)(104396002)(217873001)(4533004); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB462; H:DBXPR07MB462.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2016 11:18:24.6387 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB462 X-MC-Unique: g5VLurNmR2CtKWyMbu2FoA-1 Content-Type: multipart/alternative; boundary="_000_90CC41CF9F3D44DB8A23AFB34321748Ejiscacuk_" Archived-At: Cc: 6man WG , v6ops list Subject: Re: [v6ops] DNS AAAA for free X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 11:18:40 -0000 --_000_90CC41CF9F3D44DB8A23AFB34321748Ejiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T24gOSBBcHIgMjAxNiwgYXQgMTQ6MTEsIE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5j b208bWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb20+PiB3cm90ZToNCg0KT24gOSBBcHIgMjAx NiA4OjU1IFBNLCAiU2FuZGVyIFN0ZWZmYW5uIiA8c2FuZGVyQHN0ZWZmYW5uLm5sPG1haWx0bzpz YW5kZXJAc3RlZmZhbm4ubmw+PiB3cm90ZToNCj4NCj4gSGksDQo+DQo+ID4gT24gMDggQXByIDIw MTYsIGF0IDEzOjI3LCBvdHJvYW5AZW1wbG95ZWVzLm9yZzxtYWlsdG86b3Ryb2FuQGVtcGxveWVl cy5vcmc+IHdyb3RlOg0KPiA+DQo+ID4gSGVyZSBpcyBhbiBpbnRlcmVzdGluZyBkcmFmdCBiZWlu ZyBwcmVzZW50ZWQgaW4gZG5zb3AgdG9kYXkuDQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtdmF2cnVzYS1kbnNvcC1hYWFhLWZvci1mcmVlLz9pbmNsdWRlX3RleHQ9 MQ0KPiA+DQo+ID4gVGhlIHByb3Bvc2FsIGlzIHRvIGFsbG93IEFBQUEgcmVjb3JkcyBpbiByZXNw b25zZSB0byBBIHF1ZXJpZXMuDQo+DQo+IE9uZSBxdWVzdGlvbjogaWYgY2xpZW50cyBzZW5kIHJl cXVlc3RzIGZvciBib3RoIEEgYW5kIEFBQUEgcmVjb3JkcyBzaW11bHRhbmVvdXNseSwgaG93IHdp bGwgaW5jbHVkaW5nIHRoZSBBQUFBIGFuc3dlciBpbiB0aGUgQSByZXF1ZXN0IGhlbHA/IFRoZSBj bGllbnQgd2lsbCBqdXN0IGdldCB0aGUgQUFBQSBhbnN3ZXIgdHdpY2U6IG9uY2Ugb24gdGhlIEEg cmVxdWVzdCBhbmQgb25jZSBvbiB0aGUgQUFBQSByZXF1ZXN0LiBJZiBsb29rdXBzIHdlcmUgc2Vy aWFsaXNlZCBhbmQgdGhlIEEgcmVxdWVzdC9yZXNwb25zZSB3YXMgY29tcGxldGVkIGJlZm9yZSBz dGFydGluZyB0aGUgQUFBQSByZXF1ZXN0IGl0IHdvdWxkIG1ha2UgdGhlIHNlY29uZCByZXF1ZXN0 IHVubmVjZXNzYXJ5LCBidXQgdGhhdCdzIG5vdCB3aGF0IEkgc2VlIGluIHByYWN0aWNlLi4uDQo+ DQo+IEl0IGxvb2tzIGxpa2UgZ29vZCBpbnRlbnRpb25zLCBJJ20ganVzdCB0cnlpbmcgdG8gZmln dXJlIG91dCBob3cgdGhpcyB3b3VsZCB3b3JrIGluIHByYWN0aWNlIDopDQoNCkhhdmluZyBicmll Zmx5IGxvb2tlZCBhdCBpdCwgaXQgc2VlbXMgdGhlcmUgaXMgYW4gZWZmaWNpZW5jeSBiZW5lZml0 LiBIb3dldmVyLCBhbnN3ZXJpbmcgYW4gQSBxdWVyeSB3aXRoIGJvdGggYW4gQSBhbmQgQUFBQSBy ZXNwb25zZSBtaWdodCBpbmNlbnRpdmlzZSBqdXN0IHNlbmRpbmcgQSBxdWVyaWVzLg0KDQpQZXJo YXBzIHRoZSBvcHBvc2l0ZSB3b3VsZCBiZSBiZXR0ZXIgLSBzZW5kaW5nIGFuIEFBQUEgcXVlcnkg d291bGQgcmVzdWx0IGluIGFuIEFBQUEgYW5kIEEgYW5zd2VyLiBUaGF0IG1pZ2h0IGNyZWF0ZSBh IHNtYWxsIGFuZCBzdWJ0bGUgaW5jZW50aXZlIHRvIHVzZSBhbmQgcHJlZmVyIElQdjYsIHdpdGgg SGFwcHkgRXllYmFsbHMgY292ZXJpbmcgb3ZlciBJUHY2IGZhaWx1cmVzLg0KDQpJIGFtIGF3YXJl IG9mIElTUHMgd2hvIGhhdmUgZGVwbG95ZWQgSVB2NiB0byB0aGVpciBjdXN0b21lcnMsIGtub3dp bmcgdGhleSBuZWVkZWQgdG8gc2NhbGUgdGhlaXIgRE5TIHByb3Zpc2lvbiwgYnV0IGhhdmUgc3Rp bGwgaGFkIHRvIGhvbGQgZnVydGhlciBkZXBsb3ltZW50IHVudGlsIHRoaXMgd2FzIGFjaGlldmVk LiAgSXTigJlzIG5vdCBhIGh1Z2UgaXNzdWUsIGJ1dCBhbnkgbWVhc3VyZXMgdG8gaGVscCBhZGRy ZXNzIHNjYWxhYmlsaXR5IGFzIHlvdSBhZGQgSVB2NiBhcmUgbGlrZWx5IHRvIGJlIHdlbGNvbWVk Lg0KDQpCdXQgYXMgb3RoZXJzIGhhdmUgcG9pbnRlZCBvdXQsIHRoZXJlIGFyZSBwcmFjdGljYWxp dGllcyB3aXRoIHRoZSBwcm9wb3NhbC4NCg0KVGltDQo= --_000_90CC41CF9F3D44DB8A23AFB34321748Ejiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <8813FCC4FA39AD4F848FB29B14619D65@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA5IEFwciAyMDE2LCBhdCAxNDox MSwgTWFyayBTbWl0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb20i IGNsYXNzPSIiPm1hcmt6enpzbWl0aEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8cCBkaXI9Imx0ciIgY2xhc3M9IiI+T24gOSBBcHIgMjAxNiA4OjU1IFBN LCAmcXVvdDtTYW5kZXIgU3RlZmZhbm4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzYW5kZXJA c3RlZmZhbm4ubmwiIGNsYXNzPSIiPnNhbmRlckBzdGVmZmFubi5ubDwvYT4mZ3Q7IHdyb3RlOjxi ciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEhpLDxiciBjbGFzcz0iIj4NCiZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgT24gMDggQXByIDIwMTYsIGF0IDEzOjI3LCA8YSBo cmVmPSJtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmciIGNsYXNzPSIiPm90cm9hbkBlbXBsb3ll ZXMub3JnPC9hPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7ICZndDsgSGVyZSBpcyBhbiBpbnRlcmVzdGluZyBkcmFmdCBiZWluZyBwcmVzZW50ZWQgaW4g ZG5zb3AgdG9kYXkuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZhdnJ1c2EtZG5zb3AtYWFhYS1mb3ItZnJlZS8/ aW5jbHVkZV90ZXh0PTEiIGNsYXNzPSIiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtdmF2cnVzYS1kbnNvcC1hYWFhLWZvci1mcmVlLz9pbmNsdWRlX3RleHQ9MTwvYT48 YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgVGhlIHByb3Bv c2FsIGlzIHRvIGFsbG93IEFBQUEgcmVjb3JkcyBpbiByZXNwb25zZSB0byBBIHF1ZXJpZXMuPGJy IGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgT25lIHF1ZXN0aW9uOiBpZiBjbGll bnRzIHNlbmQgcmVxdWVzdHMgZm9yIGJvdGggQSBhbmQgQUFBQSByZWNvcmRzIHNpbXVsdGFuZW91 c2x5LCBob3cgd2lsbCBpbmNsdWRpbmcgdGhlIEFBQUEgYW5zd2VyIGluIHRoZSBBIHJlcXVlc3Qg aGVscD8gVGhlIGNsaWVudCB3aWxsIGp1c3QgZ2V0IHRoZSBBQUFBIGFuc3dlciB0d2ljZTogb25j ZSBvbiB0aGUgQSByZXF1ZXN0IGFuZCBvbmNlIG9uIHRoZSBBQUFBIHJlcXVlc3QuIElmIGxvb2t1 cHMgd2VyZQ0KIHNlcmlhbGlzZWQgYW5kIHRoZSBBIHJlcXVlc3QvcmVzcG9uc2Ugd2FzIGNvbXBs ZXRlZCBiZWZvcmUgc3RhcnRpbmcgdGhlIEFBQUEgcmVxdWVzdCBpdCB3b3VsZCBtYWtlIHRoZSBz ZWNvbmQgcmVxdWVzdCB1bm5lY2Vzc2FyeSwgYnV0IHRoYXQncyBub3Qgd2hhdCBJIHNlZSBpbiBw cmFjdGljZS4uLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEl0IGxvb2tz IGxpa2UgZ29vZCBpbnRlbnRpb25zLCBJJ20ganVzdCB0cnlpbmcgdG8gZmlndXJlIG91dCBob3cg dGhpcyB3b3VsZCB3b3JrIGluIHByYWN0aWNlIDopPGJyIGNsYXNzPSIiPg0KPC9wPg0KPHAgZGly PSJsdHIiIGNsYXNzPSIiPkhhdmluZyBicmllZmx5IGxvb2tlZCBhdCBpdCwgaXQgc2VlbXMgdGhl cmUgaXMgYW4gZWZmaWNpZW5jeSBiZW5lZml0LiBIb3dldmVyLCBhbnN3ZXJpbmcgYW4gQSBxdWVy eSB3aXRoIGJvdGggYW4gQSBhbmQgQUFBQSByZXNwb25zZSBtaWdodCBpbmNlbnRpdmlzZSBqdXN0 IHNlbmRpbmcgQSBxdWVyaWVzLjwvcD4NCjxwIGRpcj0ibHRyIiBjbGFzcz0iIj5QZXJoYXBzIHRo ZSBvcHBvc2l0ZSB3b3VsZCBiZSBiZXR0ZXIgLSBzZW5kaW5nIGFuIEFBQUEgcXVlcnkgd291bGQg cmVzdWx0IGluIGFuIEFBQUEgYW5kIEEgYW5zd2VyLiBUaGF0IG1pZ2h0IGNyZWF0ZSBhIHNtYWxs IGFuZCBzdWJ0bGUgaW5jZW50aXZlIHRvIHVzZSBhbmQgcHJlZmVyIElQdjYsIHdpdGggSGFwcHkg RXllYmFsbHMgY292ZXJpbmcgb3ZlciBJUHY2IGZhaWx1cmVzLjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdiBjbGFzcz0iIj5JIGFtIGF3YXJlIG9mIElTUHMgd2hvIGhhdmUgZGVwbG95 ZWQgSVB2NiB0byB0aGVpciBjdXN0b21lcnMsIGtub3dpbmcgdGhleSBuZWVkZWQgdG8gc2NhbGUg dGhlaXIgRE5TIHByb3Zpc2lvbiwgYnV0IGhhdmUgc3RpbGwgaGFkIHRvIGhvbGQgZnVydGhlciBk ZXBsb3ltZW50IHVudGlsIHRoaXMgd2FzIGFjaGlldmVkLiAmbmJzcDtJdOKAmXMgbm90IGEgaHVn ZSBpc3N1ZSwgYnV0IGFueSBtZWFzdXJlcyB0byBoZWxwIGFkZHJlc3Mgc2NhbGFiaWxpdHkNCiBh cyB5b3UgYWRkIElQdjYgYXJlIGxpa2VseSB0byBiZSB3ZWxjb21lZC48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJ1dCBhcyBvdGhlcnMg aGF2ZSBwb2ludGVkIG91dCwgdGhlcmUgYXJlIHByYWN0aWNhbGl0aWVzIHdpdGggdGhlIHByb3Bv c2FsLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VGltPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_90CC41CF9F3D44DB8A23AFB34321748Ejiscacuk_-- From nobody Fri Apr 22 05:20:44 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7A512DB5F for ; Fri, 22 Apr 2016 05:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.765 X-Spam-Level: X-Spam-Status: No, score=0.765 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kno5-IPqswzq for ; Fri, 22 Apr 2016 05:20:40 -0700 (PDT) Received: from swip.net (mailfe01.tele2.nl [212.247.154.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2B54D12E547 for ; Fri, 22 Apr 2016 05:20:39 -0700 (PDT) X-T2-Spam-Status: Yes, hits=7.6 required=5.0 tests=BAYES_80, HTML_MESSAGE,PYZOR_CHECK,SPF_SOFTFAIL X-T2-Spam-Flag: Yes Received: from [79.173.87.11] (account cxu-9md-48b@tele2.nl HELO vrzrjt.com) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPSA id 624667352; Fri, 22 Apr 2016 14:20:32 +0200 Received-SPF: softfail receiver=mailfe01.swip.net; client-ip=79.173.87.11; envelope-from=jdenoy@jdlabs.fr From: Joel Jaeggli To: "stef" , "surfer" , "swm" , "trejrco" , "v6ops" Date: Fri, 22 Apr 2016 15:20:24 +0300 Message-ID: <0000bc92cfba$3486d5d9$a8f03540$@jdlabs.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_694A4A14.5952886B" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdGV0QA5hy54t7ufOIi8R5AbwLrcdA== Content-Language: en-us Archived-At: Subject: [v6ops] Fw: new message X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 12:20:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_694A4A14.5952886B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello! You have a new message, please read Joel Jaeggli ------=_NextPart_000_0001_694A4A14.5952886B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<= span lang=3DEN-US>Hello!

 

You have a new message, please read http://condonetworkdc.co= m/management.php

 

Joel Jaeggli

------=_NextPart_000_0001_694A4A14.5952886B-- From nobody Mon Apr 25 13:40:39 2016 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D8E12D0F2; Mon, 25 Apr 2016 13:40:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160425204038.30238.54907.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2016 13:40:38 -0700 Archived-At: Cc: v6ops@ietf.org, v6ops-chairs@ietf.org, fred.baker@cisco.com Subject: [v6ops] v6ops - New Meeting Session Request for IETF 96 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 20:40:39 -0000 A new meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: opsec homenet pcp sunset4 6man aqm dnsop isis opsawg ospf tsvwg Second Priority: tsvarea intarea mif lmap rtgwg softwire Special Requests: --------------------------------------------------------- From nobody Fri Apr 29 16:52:32 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA1E12D501 for ; Fri, 29 Apr 2016 16:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbu_987pwngr for ; Fri, 29 Apr 2016 16:52:29 -0700 (PDT) Received: from nm17-vm2.bullet.mail.ne1.yahoo.com (nm17-vm2.bullet.mail.ne1.yahoo.com [98.138.91.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8C412D756 for ; Fri, 29 Apr 2016 16:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1461973948; bh=8wKIPUEiVsrcc5pYSKIb5ki6Zvb7vRsK0f38FbnVdgg=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=XmB4mBXIK3a4LPzz4HJu0nzjAnZgCAPn2tNHJI7vlDNUdXkdpwF4ZUzn4VDSgxMmTf+BYYNOdIpLWum19CLugbEPdUjkthmtH2sHJIjluSlwEz8ePnVIp5nezEsAbJ8myX8DollyorGyPeyOymvngy2jvMcvt9kEJ6vL5ZPZBVtXlNSMWJVJU3TwWo0CQL2KCs2SVt8Acl1fOo7E6xGv2aSsxl3+SPeehaWYbV7AA4TNYtYh82HsFRyWtIu3LfiW0rBbalxpmcSJZ6YSKRXWR/Cd+GXroxJGwVDKJoNM15eMiXK3EY68xex9YUpMZS+xDaq2ze8Lfy4x4C3++1VnhQ== Received: from [98.138.100.112] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2016 23:52:28 -0000 Received: from [98.138.226.165] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2016 23:52:28 -0000 Received: from [127.0.0.1] by omp1066.mail.ne1.yahoo.com with NNFMP; 29 Apr 2016 23:52:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 510642.93477.bm@omp1066.mail.ne1.yahoo.com X-YMail-OSG: BmBg_1sVM1ln34VrQBwJoR5igqXK7blDkUYC1YDgzK5E_V6yKQmveEWtKq5bufv OGon88D0XF73Ag.qQCIF0Jcp2Lnkxo0JSCLJqu6jLP2IvWygaAZujsghYEXL9su8PzLO2MZap_pX PaI35v_Yrd81vH1LtQnhfgl4OQjP6MvksaPFFcrkdluTWcx5rmOSkYKSGjf8vQT4X_iIVMeT7QO0 17f2ILIqEfpTj9YcHTLs6Q.JA.HjdRPDcyq43W_i4EfzftvIPbnUo7cKYEjgyG0uRFuIyGIT1iAH Plxyl7awj8S2ynFmhzdjl9sxoPqWxHMhUdB3GRUmu1vDFOtoGizlTr_51j0yzhuNCY0cO2iQYBjo Fo01vBi7cTu6WswegmksLPMh2rZn2JdGMXgJwtEJ2SbLvG6Mrl7Ovhhq6sbUIseNI.ed.1.7cpVF Yxdx88iNjsrZxH.b9w.CkECH8jsQR45VZN4CqtL0lNe2y_DE4qXWpWRCe3mRzFOEEahFw7zhPyHN W3ouLDY9UBF0TcVWZC5xPzyu02dtmwkEGSWAkSvAC8rT6BBMYrs4yR1Z.OkTB1XRknO1jcbG4ytm PitSMGDNFpKXTgG2eA3QcTwlQZ4mFJRxNNWoacwo4xKts4ZSbkHx. Received: by 98.138.105.213; Fri, 29 Apr 2016 23:52:28 +0000 Date: Fri, 29 Apr 2016 23:52:27 +0000 (UTC) From: To: V6ops List , "6man@ietf.org" <6man@ietf.org> Message-ID: <384661159.3916418.1461973947146.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <384661159.3916418.1461973947146.JavaMail.yahoo.ref@mail.yahoo.com> Archived-At: Subject: [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 23:52:30 -0000 People, We are forming teams of new-ish people to start working together to review drafts and pose comments on the list. This team has 2 people from Latin America (more will be joining over time). They wish to study drafts in the v6ops/ 6man/ sunset WGs. The discussions will be conducted in Spanish or English. The first draft they are reading is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability They are to read the draft and have 5 questions ready for discussion. (They have started.) The questions can be either things they do not understand, things they think need to be clearer in the draft or need to be fixed. I would appreciate your help very much for both of the following, please let me know. 1. If you will be able to help them in Colombia / Argentina time zone in a webinar in Spanish or English. Commitment is one hour per month live and some email contact. 2. If you will be able to help them via email support only. Please help, if you can. BTW, a number of other teams have also started including: Spanish DNSOP, and Portugese 6lo / 6tisch / roll, and English 6lo / 6tisch / roll. Other groups are forming. Thank you all very much. Nalini Elkins IETF Mentoring Team Inside Products, Inc. www.insidethestack.com (831) 659-8360 From nobody Fri Apr 29 18:04:23 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2D712D13F for ; Fri, 29 Apr 2016 18:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoKOlNz2qixS for ; Fri, 29 Apr 2016 18:04:18 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC6412D0CF for ; Fri, 29 Apr 2016 18:04:17 -0700 (PDT) Received: by mail-ig0-x234.google.com with SMTP id m9so34178347ige.1 for ; Fri, 29 Apr 2016 18:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N4WvF4LMG/LYRXbzkURV8EtXmkc9yMX7g6zRXLiv90o=; b=KSwrFW/zssL0JyIx8hvjIuGbVJZcEUGA7nweKQSdLrUJMDZ42tuns4ZS1MvwtXjIwO LxnHYtRPQF/3oHNgpFWtVcqeKmOzNzaAlicxWRkB/7mXhiYIf6HEOQqyyS51jyVMOLmT 7Yap4kv1pkthnFq4syIbLrNIG4OJfoISv2cN5grsjFENabISUAlhO3GMkuN/e11vNtdg 1hugageOE0lCMcPlKAxrg39xKsyUIUPmeDYGNEOK61jJcLrgnXar4giKclWNoDGSLz7k xwMW8rH3C7Es6iz2/uhPsAzs3C0C1GqbAgSXUHttdqEMIZ3xb0Ryf5aS7VPpLPIdDAuM uNVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N4WvF4LMG/LYRXbzkURV8EtXmkc9yMX7g6zRXLiv90o=; b=B4jYv2XHMljciKRp1YcRvo0MrvpNQfwBEvDF8hFh0POViJBPhtE33yiheIA0k8oCPt 8oZr3qmqOXGhwHz+EFaJ5gwUgU7qcmY16sF3jVt+2drEvBrb38GleOXNwiLnd+biO1qj dd11bkKGLKlJWvknbhSTDCMAA9h9kZM99EJkdZnj+PdOc8E2QzhlGx458dGSLfGuaf2G plaq3loq7vO1J0wj487dKEBVbGL2sR/rEmwY2PyT6DUJFsE67u6NR89bBljouqWnX0OZ klRJ7m5lG0Ap5+EyfR0wFgB25mU48wvN2HDxqXIrtPFBrKLMFhsycLIZEF1MYOQ7B7vz OFLA== X-Gm-Message-State: AOPr4FVIw/Cv7xoi5w3mv89t8ovejj/gmdayzMH00uv8ueyS1cnPErbA5QE6ZalRR5L+zL8n3EPTr8PHwFPCtRzH X-Received: by 10.50.150.107 with SMTP id uh11mr7665979igb.1.1461978257107; Fri, 29 Apr 2016 18:04:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.227.84 with HTTP; Fri, 29 Apr 2016 18:03:57 -0700 (PDT) In-Reply-To: <384661159.3916418.1461973947146.JavaMail.yahoo@mail.yahoo.com> References: <384661159.3916418.1461973947146.JavaMail.yahoo.ref@mail.yahoo.com> <384661159.3916418.1461973947146.JavaMail.yahoo@mail.yahoo.com> From: Erik Kline Date: Sat, 30 Apr 2016 10:03:57 +0900 Message-ID: To: nalini.elkins@insidethestack.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: V6ops List , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 01:04:20 -0000 Why start with a document in IESG review as opposed to, say, a document that still currently under discussion in a working group? On 30 April 2016 at 08:52, wrote: > People, > > > We are forming teams of new-ish people to start working together to review drafts and pose comments on the list. > > This team has 2 people from Latin America (more will be joining over time). They wish to study drafts in the v6ops/ 6man/ sunset WGs. The discussions will be conducted in Spanish or English. > > The first draft they are reading is: > > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability > > They are to read the draft and have 5 questions ready for discussion. (They have started.) The questions can be either things they do not understand, things they think need to be clearer in the draft or need to be fixed. > > I would appreciate your help very much for both of the following, please let me know. > > 1. If you will be able to help them in Colombia / Argentina time zone in a webinar in Spanish or English. Commitment is one hour per month live and some email contact. > > 2. If you will be able to help them via email support only. > > Please help, if you can. > > BTW, a number of other teams have also started including: Spanish DNSOP, and Portugese 6lo / 6tisch / roll, and English 6lo / 6tisch / roll. Other groups are forming. > > > Thank you all very much. > > Nalini Elkins > IETF Mentoring Team > > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Apr 29 20:52:26 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B8E12D546 for ; Fri, 29 Apr 2016 20:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arKUqVKOBbJW for ; Fri, 29 Apr 2016 20:52:24 -0700 (PDT) Received: from nm2-vm5.bullet.mail.ne1.yahoo.com (nm2-vm5.bullet.mail.ne1.yahoo.com [98.138.91.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA0312D154 for ; Fri, 29 Apr 2016 20:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1461988342; bh=uJpID9kSgxkJ6r+JSgeqm4ByT/8b36FrB/XYnpCLqH0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=JzUaueM1/ukd4MQX3gVg1C+C1/SiHqW395Hb3ey3GybyPgnxUqd1poaR3xEIe+s+mnbHpXY+hrEiNMnqtBCk63q8E+kZToBOlG3oKP0RGBr0aX/z/7bdj4N83zZHFjmYjZEdZF82DzX1n/MRoXYcsZAGgfXQceRHWqDLCnH3xBgQRXTSR+RuajwGmzKwgdz+6B/jP5esC8Xm4+7FtxJnxtXIx2Ujgnq7ECtkGr3oFz/FObHx5E1pLE6zlYiDBqDYnwDYK0np6LlvxKjKneiHW/unR1A+JwDZUrWAyu0wOEeqNDKgZtg4YKNwEcudHsV/Tot8HWl1ARNvOPrmfBXeXg== Received: from [98.138.226.179] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 03:52:22 -0000 Received: from [98.138.89.170] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 03:52:22 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 03:52:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 899807.87287.bm@omp1026.mail.ne1.yahoo.com X-YMail-OSG: IAmri_gVM1l1z6SYK7vK_ZI4PRmZEBktxpTb5HnlnDcLyblgZPB9BCBmJmqd4sq GCN8p4SHDjYV3a.eZQZyfgteM45WXIukZJFQ0yYmFrCmqW9Un_4RepH9O3hvvM6LJ3.MlLLXLHor 6I9rJ4QqbaFNKBZSLtIb7193qFzoG1faUMKbv.VsIPfOiyzRSRg5LiF7ZFqwCqeGWRH4cOcJvgw2 ujfLOpp.ExD.r9oT2NLKwyP9BgX0Ln.m42JkUi05p9twI9NYoWtuMgRNzFBxI99PpT7zzPl4578D BhHlwxhTFd0Da7h2DWUYzpdvX1M1NrfUi17kNYPOEMGT2uQVKmOleDEt.7BnLm9x0mXASAc1NVcd Dd6fVN2M579K434mitqx7GA5J9xcQ2_27n3_H48Vo_uuds_f_PNQRmofbqzyhqBqPuCzPRXPi6oM aLrux1TkMoYnvRAJAMUfERBTKGfVjx5vKNJiNYiGeJ0X9Z2TLusqa_HkrJQkpmgZOtlMBlHTHQBZ 11myJchofHVlXd0qUgnIEOaVJMRR_D0dtF5tfxeEJRpvTl1H_myXrVPz0E8k- Received: by 98.138.105.202; Sat, 30 Apr 2016 03:52:22 +0000 Date: Sat, 30 Apr 2016 03:52:21 +0000 (UTC) From: To: Erik Kline Message-ID: <1241265919.4069125.1461988341893.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: V6ops List , "6man@ietf.org" <6man@ietf.org>, "mentoring-coordinators@ietf.org" Subject: Re: [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 03:52:25 -0000 Erik, I am giving people space to find their interests. I told the team to look in either "Active Internet-Drafts" or "Related Internet-Drafts" for a drafts that seemed interesting to them. They came up with 5 drafts. The drafts they picked all happen to be in some phase of having been adopted by the WG. This is fine. The first one is: draft-ietf-v6ops-host-addr-availability-06 It will take time for a Review Team to become really functional and work together well. My hope is that over time, they will stay together & go through the drafts that are individual submissions as well. It will also take time to get a mentor (or mentors) integrated into the team. So, whatever they start with is fine. Actually, this may be more information than you were asking for, but my hope is that the Mentoring program introduce 3 other types of review groups: 1. Internet Draft Review teams (started) 2. Draft Authoring Teams (look for co-authors to help draft) 3. Draft refining teams (have a draft not yet submitted to WG, needs polish) 4. Dry run teams (draft has slot on agenda, needs help to prep) We will start a new type of team after each of the next 3 IETFs. Right now, I am concentrating on #1 - Internet Draft Review Teams. We have about 50 people signed up to be a part of such groups, so I need to get the process really worked out & the teams solid & we can move to the next step. Appreciate any comments. Thanks, Nalini Elkins IETF Mentoring Team Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Erik Kline To: nalini.elkins@insidethestack.com Cc: V6ops List ; "6man@ietf.org" <6man@ietf.org> Sent: Friday, April 29, 2016 6:03 PM Subject: Re: [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish Why start with a document in IESG review as opposed to, say, a document that still currently under discussion in a working group? On 30 April 2016 at 08:52, wrote: > People, > > > We are forming teams of new-ish people to start working together to review drafts and pose comments on the list. > > This team has 2 people from Latin America (more will be joining over time). They wish to study drafts in the v6ops/ 6man/ sunset WGs. The discussions will be conducted in Spanish or English. > > The first draft they are reading is: > > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability > > They are to read the draft and have 5 questions ready for discussion. (They have started.) The questions can be either things they do not understand, things they think need to be clearer in the draft or need to be fixed. > > I would appreciate your help very much for both of the following, please let me know. > > 1. If you will be able to help them in Colombia / Argentina time zone in a webinar in Spanish or English. Commitment is one hour per month live and some email contact. > > 2. If you will be able to help them via email support only. > > Please help, if you can. > > BTW, a number of other teams have also started including: Spanish DNSOP, and Portugese 6lo / 6tisch / roll, and English 6lo / 6tisch / roll. Other groups are forming. > > > Thank you all very much. > > Nalini Elkins > IETF Mentoring Team > > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Apr 29 22:54:02 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640D112B04A; Fri, 29 Apr 2016 22:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.517 X-Spam-Level: X-Spam-Status: No, score=-115.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-zENl1jI9Ae; Fri, 29 Apr 2016 22:53:56 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B4312B03F; Fri, 29 Apr 2016 22:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2705; q=dns/txt; s=iport; t=1461995636; x=1463205236; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=frm/Il05DHin7xppBjlCHn5fUdYX6CeP3hVkK32A6xM=; b=ifPPHli1Ltk9OfhDWCNUjm+RzhvvkULyyOkjeDh6xl+ycCLt5rEpvZNb meOV/HAjE0QOTDySZgzEY35xSEw3T9E0NXLFCUIIlaAcEMtt50dVxBGGz 5dmHZvrAgNeO97qIqFpaNUSSdWDSN/8KcoBA+SlsgPAloLvT1enrIZzBJ g=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAgAiRyRX/4UNJK1dgzhTfQa5ag6Bd?= =?us-ascii?q?iSFbAKBJDgUAQEBAQEBAWUnhEEBAQEDAXkFCwIBCBguMiUCBA4FDogUCA7DRgE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQ0EBIgXglaHaIIrBZgTAYMngWdtiBuPEY8vA?= =?us-ascii?q?R4BQ4I2gTVsiAJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,554,1454976000"; d="asc'?scan'208";a="268074565" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2016 05:53:54 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3U5rrJf006621 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 30 Apr 2016 05:53:54 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 30 Apr 2016 00:53:52 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Sat, 30 Apr 2016 00:53:52 -0500 From: "Fred Baker (fred)" To: Nalini Elkins Thread-Topic: [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish Thread-Index: AQHRoqSsxZDCHMWw6EyjN+b11r24tg== Date: Sat, 30 Apr 2016 05:53:52 +0000 Message-ID: <2ECC125B-DD52-488A-8B59-05FD7BB98318@cisco.com> References: <1241265919.4069125.1461988341893.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1241265919.4069125.1461988341893.JavaMail.yahoo@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_52F3BB29-A304-4361-873A-946F2F038E04"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: V6ops List , "6man@ietf.org" <6man@ietf.org>, "mentoring-coordinators@ietf.org" Subject: Re: [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 05:53:58 -0000 --Apple-Mail=_52F3BB29-A304-4361-873A-946F2F038E04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 29, 2016, at 8:52 PM, nalini.elkins@insidethestack.com wrote: >=20 > Erik, >=20 > I am giving people space to find their interests. I told the team to = look in either "Active Internet-Drafts" or "Related Internet-Drafts" for = a drafts that seemed interesting to them. >=20 > They came up with 5 drafts. The drafts they picked all happen to be = in some phase of having been adopted by the WG. This is fine. The first = one is: >=20 > draft-ietf-v6ops-host-addr-availability-06 I assume you're looking at = https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/.= You might want to think a little harder about its status. The = datatracker actually tracks four different statuses for a document - has = it been updated within the past six months (which we call "active"), = what has the working group done with it, what does the IESG think about = it, and what does the IANA think about it. In this case, it's active, it = has cleared the working group and submitted to the IESG, it's on the = IESG telechat scheduled next Thursday, and the IANA agrees that it = doesn't ask them to do anything. Erik's point is that, barring IESG objections, we're unlikely to change = it at this point. If the team wants to make a difference, in v6ops = draft-ietf-v6ops-unique-ipv6-prefix-per-host would be a better choice. --Apple-Mail=_52F3BB29-A304-4361-873A-946F2F038E04 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVyRIcEayAOS/EQ8MAQI13A/8D0CtY/18HiC71cAeO64hwl8vByldIOsN ZtvCwwq5xLTdyMPPr9bBE6GnHWZqpjtLVvuTJRbJPv+G4esra7wZ/Qg3n0lTUyaU XcqgOAThuIVq8bZLHkrIlQ9iYrdUnnszKJzWPNMb7DUMkr1S4SGB7iIapVNWwZUh bknkO1r6tz18VgSG5JC35841gLIVz+54lS5tysumB7bZPWe5oBUZTXGmmL58kSrH OtKjERNE6rEyILja3NjFJs7C3D0x/hvbAKMtLWUzEJY3PrbEpb8gPAls+FIstxEv pqS1OUhTVyRbSUwRVan0uP5rwZcg5vexm+zU0aj56eA5uSkBGLybn+KOc2G04dyq y36qFaM56PcTjGtaTT5YAlSvaGDAQqjSgUSQlUbeX121FhQVGXvE9JKpeHpfGMiw zSUL7RmaM+rFEs2eamU+nH3EjdDX3hMMm6oHBghTWojPhwdwD8MLeAXl1eentqDM mX1jlRI5lCvyaPwXYGFW7U2WlqqmFzlg/cMJYQku795lUJRXkFW2RddhzfHBCxPq OQWyo9UKj9FcXIBDNFihVcuf0jqHewiOPacOPNFR0mLZ4PMlmCLHktF5hNh2k6ir +ZjAgu0V5AJRI11rzR8KP7sAKPpbIRvAJh87fxEzqLOLMryVH4Y0vddEvMdgLly9 6VXUkAXWr7A= =SrUh -----END PGP SIGNATURE----- --Apple-Mail=_52F3BB29-A304-4361-873A-946F2F038E04-- From nobody Fri Apr 29 23:46:15 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA97D12B02B; Fri, 29 Apr 2016 23:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nF2midzURvmr; Fri, 29 Apr 2016 23:46:04 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3433712B00A; Fri, 29 Apr 2016 23:46:03 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id a17so66736072wme.0; Fri, 29 Apr 2016 23:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Y5YRkGrLOykykWaUuZ8WkoeZrBaKdt7N9uRCoI8wztE=; b=0VoR9jW75RO7fP4RTk4C6drIeNMXit8/WSkRKDZ5dQp7d/8PwcuUqc8kP2KUdepZ3O bKJzP5cy7r2uSqLpUob8bHCsU5GTqtJh0zZVeR8/FBONbk3b0Q8FiArZ8MGIvfCdTBHV UxE996bfszzcrpQDJEBCJnsZZprbVYdjUJ7i0p0LAyNvQiIiEW5PoXk1Qd9Zck95pyOk tGCqNLrT3gFCgE/1fwgAQZx/82cNznEnCGO+qbTj2a4wuXW0ofiI7bBZcM5cTi3dMvYk b1ZbECPnsw5TFh7sfF59b8AqoaHCZ/27PiAyafAFIc01Dulob975cbSizqweahcR5iSI i1iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Y5YRkGrLOykykWaUuZ8WkoeZrBaKdt7N9uRCoI8wztE=; b=VAYi0Q/Rye8WF4Py+N10e9qcezOe7YByiXisqdORVQDiRpDCe9TfNq/xBNgNBANWiF S1QeuUXEAmJkAglHMP10S5tHnx2rnKx0uHVydA2VKH2VJ/Ol84tBj/+SqJUSrRId2NlA +gS2iMv1CBl50bpsXeEQqxr3AuwcqOG8IyX7RLLNgzUbykuU2/NLFN79o4i9UwzJt/zn DqgaHxD1/O0twjLRw9xkPZsG/8v0vwZsiX1iXgeIoVP1ebul6EWAYdDf9apozLHEu1ZC 5B/SMlm0b3RvZmCU+juOHoNc4C3ykeOgkh7AsZQxBZEgpVPKnr2MwkpAQvWSL3a8eQdW /K1g== X-Gm-Message-State: AOPr4FVH5RNfru+kCRxqnPM5EZ2PpKXFZ5KaHDyaj03sZBGzhOFB0QX6YVTFO8cukzkprtCcDOKX62hyDu9tVg== X-Received: by 10.194.37.106 with SMTP id x10mr25884198wjj.135.1461998761804; Fri, 29 Apr 2016 23:46:01 -0700 (PDT) MIME-Version: 1.0 Sender: edwinsc@gmail.com Received: by 10.28.181.143 with HTTP; Fri, 29 Apr 2016 23:45:32 -0700 (PDT) In-Reply-To: <2ECC125B-DD52-488A-8B59-05FD7BB98318@cisco.com> References: <1241265919.4069125.1461988341893.JavaMail.yahoo@mail.yahoo.com> <2ECC125B-DD52-488A-8B59-05FD7BB98318@cisco.com> From: Edwin Cordeiro Date: Sat, 30 Apr 2016 08:45:32 +0200 X-Google-Sender-Auth: HjVVZwBY8T1bp0Mw02uoyX425fg Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=047d7b603e2adc0a4e0531ae1c44 Archived-At: Cc: V6ops List , "6man@ietf.org" <6man@ietf.org>, "mentoring-coordinators@ietf.org" Subject: Re: [v6ops] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 06:46:08 -0000 --047d7b603e2adc0a4e0531ae1c44 Content-Type: text/plain; charset=UTF-8 Nalini, I'm not sure if I have enough experience to be a mentor, but I'm willing to help if you think I can. BR Edwin Cordeiro On Sat, Apr 30, 2016 at 7:53 AM, Fred Baker (fred) wrote: > > > On Apr 29, 2016, at 8:52 PM, nalini.elkins@insidethestack.com wrote: > > > > Erik, > > > > I am giving people space to find their interests. I told the team to > look in either "Active Internet-Drafts" or "Related Internet-Drafts" for a > drafts that seemed interesting to them. > > > > They came up with 5 drafts. The drafts they picked all happen to be in > some phase of having been adopted by the WG. This is fine. The first one > is: > > > > draft-ietf-v6ops-host-addr-availability-06 > > I assume you're looking at > https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/. > > You might want to think a little harder about its status. The datatracker > actually tracks four different statuses for a document - has it been > updated within the past six months (which we call "active"), what has the > working group done with it, what does the IESG think about it, and what > does the IANA think about it. In this case, it's active, it has cleared the > working group and submitted to the IESG, it's on the IESG telechat > scheduled next Thursday, and the IANA agrees that it doesn't ask them to do > anything. > > Erik's point is that, barring IESG objections, we're unlikely to change it > at this point. If the team wants to make a difference, in v6ops > draft-ietf-v6ops-unique-ipv6-prefix-per-host would be a better choice. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b603e2adc0a4e0531ae1c44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nalini,

I&= #39;m not sure if I have enough experience to be a mentor, but I'm will= ing to help if you think I can.

BR

Edwin Cordeiro

On Sat, Apr 30, 2016 at 7:53 AM, Fred Baker = (fred) <fred@cisco.com> wrote:

> On Apr 29, 2016, at 8:52 PM, nalini.elkins@insidethestack.com wrote:
>
> Erik,
>
> I am giving people space to find their interests.=C2=A0 =C2=A0I told t= he team to look in either "Active Internet-Drafts" or "Relat= ed Internet-Drafts" for a drafts that seemed interesting to them.
>
> They came up with 5 drafts.=C2=A0 The drafts they picked all happen to= be in some phase of having been adopted by the WG. This is fine.=C2=A0 The= first one is:
>
> draft-ietf-v6ops-host-addr-availability-06

I assume you're looking at https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-ava= ilability/.

You might want to think a little harder about its status. The datatracker a= ctually tracks four different statuses for a document - has it been updated= within the past six months (which we call "active"), what has th= e working group done with it, what does the IESG think about it, and what d= oes the IANA think about it. In this case, it's active, it has cleared = the working group and submitted to the IESG, it's on the IESG telechat = scheduled next Thursday, and the IANA agrees that it doesn't ask them t= o do anything.

Erik's point is that, barring IESG objections, we're unlikely to ch= ange it at this point. If the team wants to make a difference, in v6ops dra= ft-ietf-v6ops-unique-ipv6-prefix-per-host would be a better choice.

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


--047d7b603e2adc0a4e0531ae1c44-- From nobody Sat Apr 30 06:25:22 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91C412D13F for ; Sat, 30 Apr 2016 06:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O9R1RPIPxTC for ; Sat, 30 Apr 2016 06:25:16 -0700 (PDT) Received: from nm19-vm5.bullet.mail.ne1.yahoo.com (nm19-vm5.bullet.mail.ne1.yahoo.com [98.138.91.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B96612D13B for ; Sat, 30 Apr 2016 06:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1462022712; bh=v/r4oTfgFBE0gNktijSFH2kVDdL9/DYFW2q/pjMrYOs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=o3Ty+/kN6nf/0SvZ8vvMYEkB1FyzBp7MkpKhfnv/nsH/yIbik/w2FVmlnQtWtwrw55v8lwvtO/8OYo9yhev0533ctW+C4rAVs7yYe3n5eeJcZmDn4BpCM75NLF0+t+a/f7DX1RCjCeBFIicXaEmVM8Lk9e5sUrALjWaAxR+W9Onoi+tQxD02FZO9G3Rn3QLcYrEpqg7UWFg5/jCb+nQ9UvlpvSLO7699mulu8c7w8R96U49HmQaRRRSWEsXos9s9bY8rU0cPfGuINfCr1fX5VVqQkhMGucxYpuqBiIuamw4oTmwTL5X6qJV2wXOFCn02Q7AH7QPFCt5hq/Q8EPNBWg== Received: from [98.138.100.112] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 13:25:12 -0000 Received: from [98.138.87.7] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 13:25:11 -0000 Received: from [127.0.0.1] by omp1007.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 13:25:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 974687.68079.bm@omp1007.mail.ne1.yahoo.com X-YMail-OSG: HIs3kRsVM1mCEIEyXpFuNDrX6Qw2rzU.2EYDU6w5UDLDRexxBzyJpnVxq9gHRlD 5w8SY3CMBuWodWLDXF_QJ_8xFNeqoei4GVmv1ySs.Vn1J.qXrxo_vGTUZXOL2Ddevk67hJPOgJzv yLPWHzJ8b47YSfoOlSO28va1jtPPPpUMJF33lzxtK3UjxAnLBc_gvsTUT.VJg._VkHLD_2td4Bfd 14dVFWPgJHT_4UdkQss0qH7_CX3vae9haoiBM.blrptvT9I59hwnXGS_nYhL98SpDUwYcvFGb5wT 9pVrZFTyUBAnbid_V0RpgpPLElq9j1quVyqlbbYck5fgV0p3_SHe62.uL8J_cAhBe8arZrBNBsSW 3hkRuH6801gLGGbsWXRE4fb7q_Ko0MYPhyeGrB8bNs4DdP3EJSJQTHjL1h76qIM5toqdJHQH34nL 06lAztpIXIahzxELk24h4z26mNHfw2i2eRtptDW0qiid6dFa7u9ZdOC7eAKylGf4eerIz77Z.fkp cdODMmf6e_MX8u1YhEt4xw32Eia_QBdxnmW6haz.SwQ9LM2COZCfS35Up_Th5ZoJNlaQVSNbIDzT jgF25OJItJ5I- Received: by 98.138.105.227; Sat, 30 Apr 2016 13:25:11 +0000 Date: Sat, 30 Apr 2016 13:25:10 +0000 (UTC) From: To: "Fred Baker (fred)" Message-ID: <433694511.4134048.1462022710928.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <2ECC125B-DD52-488A-8B59-05FD7BB98318@cisco.com> References: <2ECC125B-DD52-488A-8B59-05FD7BB98318@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4134047_99542133.1462022710926" Archived-At: Cc: V6ops List , "6man@ietf.org" <6man@ietf.org>, "mentoring-coordinators@ietf.org" Subject: Re: [v6ops] [Mentoring-coordinators] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 13:25:18 -0000 ------=_Part_4134047_99542133.1462022710926 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >> I am giving people space to find their interests.=C2=A0 I told the team = to look in either "Active Internet-Drafts" or "Related Internet-Drafts" for= a drafts that seemed interesting to them. >>=20 >> They came up with 5 drafts.=C2=A0 The drafts they picked all happen to b= e in some phase of having been adopted by the WG. This is fine.=C2=A0 The f= irst one is: >=20 >> draft-ietf-v6ops-host-addr-availability-06 >I assume you're looking at https://datatracker.ietf.org/doc/draft-ietf-v6o= ps-host-addr-availability/. >You might want to think a little harder about its status. The datatracker = actually tracks four different statuses for a document - has it been update= d within the past six months (which we >call "active"), what has the workin= g group done with it, what does the IESG think about it, and what does the = IANA think about it. In this case, it's active, it has cleared the working = group >and submitted to the IESG, it's on the IESG telechat scheduled next = Thursday, and the IANA agrees that it doesn't ask them to do anything. >Erik's point is that, barring IESG objections, we're unlikely to change it= at this point. If the team wants to make a difference, in v6ops draft-ietf= -v6ops-unique-ipv6-prefix-per-host=C2=A0>would be a better choice. Thanks for explaining. =C2=A0The other drafts that the group is interested = in are: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-considerations/ https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/ https://datatracker.ietf.org/doc/draft-ietf-6man-rdnss-rfc6106bis/ draft-ietf-v6ops-ipv6-ehs-in-real-world-02 =C2=A0=20 But, I will suggest=C2=A0draft-ietf-v6ops-unique-ipv6-prefix-per-host to th= em. Thanks,Nalini =C2=A0 ------=_Part_4134047_99542133.1462022710926 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

>> I am gi= ving people space to find their interests.  I told the team to look i= n either "Active Internet-Drafts" or "Related Internet-Drafts" for a drafts= that seemed interesting to them.
>>
>> They came up wit= h 5 drafts.  The drafts they picked all happen to be in some phase of = having been adopted by the WG. This is fine.  The first one is:
>= ;
>> draft-ietf-v6ops-host-addr-availability-06

>I assu= me you're looking at https://datatracker.ietf.org/doc/draft-ietf-v6ops-host= -addr-availability/.

>You might want to think a little harder abo= ut its status. The datatracker actually tracks four different statuses for = a document - has it been updated within the past six months (which we >c= all "active"), what has the working group done with it, what does the IESG = think about it, and what does the IANA think about it. In this case, it's a= ctive, it has cleared the working group >and submitted to the IESG, it's= on the IESG telechat scheduled next Thursday, and the IANA agrees that it = doesn't ask them to do anything.

>Erik's point is that, barring IESG objections, we're unl= ikely to change it at this point. If the team wants to make a difference, i= n v6ops draft-ietf-v6ops-unique-ipv6-prefix-per-host 
>would be a better choice.
<= div id=3D"yui_3_16_0_ym19_1_1462022088176_20109">
Thanks for explaining.  The other dr= afts that the group is interested in are:

https://datatracker.ietf= .org/doc/draft-ietf-v6ops-ula-usage-considerations/
https://datatracker.= ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/
https://datatracker.= ietf.org/doc/draft-ietf-6man-rdnss-rfc6106bis/
draft-ietf-v6ops-ipv6-ehs= -in-real-world-02
 
But, I will suggest draft-ietf-v6ops-unique-ipv6-prefix-per-host to them.
<= div id=3D"yui_3_16_0_ym19_1_1462022088176_20161">
<= div id=3D"yui_3_16_0_ym19_1_1462022088176_20161">Thanks,
Nalini
 

------=_Part_4134047_99542133.1462022710926-- From nobody Sat Apr 30 06:30:57 2016 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B08B12B01D for ; Sat, 30 Apr 2016 06:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7Kj4S0GDiTz for ; Sat, 30 Apr 2016 06:30:45 -0700 (PDT) Received: from nm20-vm0.bullet.mail.ne1.yahoo.com (nm20-vm0.bullet.mail.ne1.yahoo.com [98.138.91.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED57812D153 for ; Sat, 30 Apr 2016 06:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1462023041; bh=tmQLQZ0+IBzrcI77Sr/Aley6sG0zXCl6Bn8yaiU8p5A=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=XM7EZArDonQd3I6PlZ8Qegj5/s8URSfxSx8h9dyOeIbQvGihNPvy/m0zFPNQ4YCHMVmW6ltI9PEKyJPLNoJcScAnc/YcugV0FMpMXp6jRGvTfOZH5aRMIVOajdhhZz8D11mSqCsSFr/aggo4K/xNf5PerCbK96wvA0uWuEnw/Zf7ZIzclNjncQDRl3At4o+Y1EEFNdkdj3OOhlXtDdnwxr//5nrKLka0sf7ajTW4eogXexzWn69n8Ulp4JUkWeNFwSkxH42Zn33cuYwALiNrR3iKxuP4BRpgRmzGvBNkkci4CcBElLg5Cy4AXZmUyLzAxPZzFnmlKnXp41677qlnFQ== Received: from [98.138.226.176] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 13:30:41 -0000 Received: from [98.138.89.252] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 13:30:41 -0000 Received: from [127.0.0.1] by omp1044.mail.ne1.yahoo.com with NNFMP; 30 Apr 2016 13:30:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 540723.74005.bm@omp1044.mail.ne1.yahoo.com X-YMail-OSG: ldKKK24VM1mRXv2XZRnlL5ThlOUvxCNhz17xCO5k2BEVPFQm.j3VM8Q7__KV589 a0CxqV2mlLRPm5hqf8OvMcOXCrDvcWw4sCkMgGw0ZI77gaGxF6p3KBiglQa8i10ldSp2gAiQm6NI SJ1FZ.OMA1lPdLJ4RpR6kWb2tLbD._L354rNDoHj8yofiSesM5iNYrQSCSCCYaXlV9VdRyQM0u58 JkRsHnolXwxGGj3f4OXhMgVrigjR0leXudvbVHLVuLoA4oA6juzTdLf44P_v5tUHjIMU8cqAFIfg rKJf3mIzcusohjcbtGup43dNY9.Qwg1Dx4BHArr.QEvKcjP83wvvOTl_JM3VK7IoIL5cJrG9GXZk c5.hnx0ALjWZIDBUJkpTPb6r_d.1X8LCdpPNN4klhpV7Ths5fO.q80bKdskBBnv4unjYuKpyCM4h qVY4YNyHG50cbAtjrHNQd8tw2BRISiKtBciS7ccwJ7lngpdE2fXtw1SLLjfWgiEmP08btYHMw1Sa _92xwxqmUhXbB Received: by 98.138.105.253; Sat, 30 Apr 2016 13:30:41 +0000 Date: Sat, 30 Apr 2016 13:30:40 +0000 (UTC) From: To: Edwin Cordeiro , "Fred Baker (fred)" Message-ID: <2114139823.4097517.1462023040623.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4097516_73119864.1462023040618" Archived-At: Cc: V6ops List , "6man@ietf.org" <6man@ietf.org>, "mentoring-coordinators@ietf.org" Subject: Re: [v6ops] [Mentoring-coordinators] Remote Mentor Needed: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 13:30:46 -0000 ------=_Part_4097516_73119864.1462023040618 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Edwin. =C2=A0I am sure you will be great.=C2=A0Ideally, I want each= team to have 2 mentors who can participate in webinars (1 hour per month) = and email contact and a third mentor who can participate by email only. =C2= =A0 This way, no one is overly burdened & there is no bottleneck (where no = mentors are available.) So, folks, if we can get 2 more mentors, that will be wonderful. =C2=A0 Nalini From: Edwin Cordeiro To: Fred Baker (fred) =20 Cc: V6ops List ; "6man@ietf.org" <6man@ietf.org>; "mentorin= g-coordinators@ietf.org" ; Nalini Elkins <= nalini.elkins@insidethestack.com> Sent: Friday, April 29, 2016 11:45 PM Subject: Re: [Mentoring-coordinators] [v6ops] Remote Mentor Needed: Intern= et Draft Review Team: v6ops / 6man/ sunset4 : Spanish =20 Nalini, I'm not sure if I have enough experience to be a mentor, but I'm willing to= help if you think I can. BR Edwin Cordeiro On Sat, Apr 30, 2016 at 7:53 AM, Fred Baker (fred) wrote: > On Apr 29, 2016, at 8:52 PM, nalini.elkins@insidethestack.com wrote: > > Erik, > > I am giving people space to find their interests.=C2=A0 =C2=A0I told the = team to look in either "Active Internet-Drafts" or "Related Internet-Drafts= " for a drafts that seemed interesting to them. > > They came up with 5 drafts.=C2=A0 The drafts they picked all happen to be= in some phase of having been adopted by the WG. This is fine.=C2=A0 The fi= rst one is: > > draft-ietf-v6ops-host-addr-availability-06 I assume you're looking at https://datatracker.ietf.org/doc/draft-ietf-v6op= s-host-addr-availability/. You might want to think a little harder about its status. The datatracker a= ctually tracks four different statuses for a document - has it been updated= within the past six months (which we call "active"), what has the working = group done with it, what does the IESG think about it, and what does the IA= NA think about it. In this case, it's active, it has cleared the working gr= oup and submitted to the IESG, it's on the IESG telechat scheduled next Thu= rsday, and the IANA agrees that it doesn't ask them to do anything. Erik's point is that, barring IESG objections, we're unlikely to change it = at this point. If the team wants to make a difference, in v6ops draft-ietf-= v6ops-unique-ipv6-prefix-per-host would be a better choice. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ mentoring-coordinators mailing list mentoring-coordinators@ietf.org https://www.ietf.org/mailman/listinfo/mentoring-coordinators ------=_Part_4097516_73119864.1462023040618 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Edwin.  I am sure you will= be great.
 
Ideally, I want each team to have 2 mentors who= can participate in webinars (1 hour per month) and email contact and a thi= rd mentor who can participate by email only.   This way, no one is ove= rly burdened & there is no bottleneck (where no mentors are available.)=

So, folks, if we can get 2 more mentors, that= will be wonderful.  

Nalini


From: Edwin C= ordeiro <edwin@scordeiro.net>
To: Fred Baker (fred) <fred@cisco.com>
Cc: V6ops List <v6ops@ietf.org>;= "6man@ietf.org" <6man@ietf.org>; "mentoring-coordinators@ietf.org" &= lt;mentoring-coordinators@ietf.org>; Nalini Elkins <nalini.elkins@ins= idethestack.com>
Sent:<= /b> Friday, April 29, 2016 11:45 PM
Subject: Re: [Mentoring-coordinators] [v6ops] Remote Mentor N= eeded: Internet Draft Review Team: v6ops / 6man/ sunset4 : Spanish

Nalini,

I'm not sure i= f I have enough experience to be a mentor, but I'm willing to help if you t= hink I can.

BR

<= div dir=3D"ltr">
Ed= win Cordeiro

On Sat, Apr 30, 20= 16 at 7:53 AM, Fred Baker (fred) <fred@cisco.com> wrote:

> On Apr 29, 2016, at 8:52 PM, nalini.elkins@insidethestack.com = wrote:
>
> Erik,
>
> I am giving people space to find their interests.   I told t= he team to look in either "Active Internet-Drafts" or "Related Internet-Dra= fts" for a drafts that seemed interesting to them.
>
> They came up with 5 drafts.  The drafts they picked all happen to= be in some phase of having been adopted by the WG. This is fine.  The= first one is:
>
> draft-ietf-v6ops-host-addr-availability-06

I assume you're looking at https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-= addr-availability/.

You might want to think a little harder about its status. The datatracker a= ctually tracks four different statuses for a document - has it been updated= within the past six months (which we call "active"), what has the working = group done with it, what does the IESG think about it, and what does the IA= NA think about it. In this case, it's active, it has cleared the working gr= oup and submitted to the IESG, it's on the IESG telechat scheduled next Thu= rsday, and the IANA agrees that it doesn't ask them to do anything.

Erik's point is that, barring IESG objections, we're unlikely to change it = at this point. If the team wants to make a difference, in v6ops draft-ietf-= v6ops-unique-ipv6-prefix-per-host would be a better choice.

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


=



= ------=_Part_4097516_73119864.1462023040618--