From joelja@bogus.com Sun Dec 2 18:27:01 2012 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 9B4B521F8919 for ; Sun, 2 Dec 2012 18:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.064 X-Spam-Level: X-Spam-Status: No, score=-102.064 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HivY2TznVQ9s for ; Sun, 2 Dec 2012 18:27:01 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2184221F8918 for ; Sun, 2 Dec 2012 18:27:01 -0800 (PST) Received: from joels-MacBook-Air.local (c-98-207-206-4.hsd1.ca.comcast.net [98.207.206.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qB32QxZp012445 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 3 Dec 2012 02:27:00 GMT (envelope-from joelja@bogus.com) Message-ID: <50BBB82E.7010105@bogus.com> Date: Sun, 02 Dec 2012 12:21:02 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: multipart/mixed; boundary="------------070000010909020708030703" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 03 Dec 2012 02:27:00 +0000 (UTC) Subject: [v6ops] Milestone Dates between now and IETF 86 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 02:27:01 -0000 This is a multi-part message in MIME format. --------------070000010909020708030703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Having a long gap between a Novemeber meeting and one in march is dangerous from the perspective of momentum if documents are only going to rev on the basis of impending deadlines (I'm as guilty of this as anyone). That said these are the milestone dates to be aware of for IETF 86. ** * *2013-02-18 (Monday):*Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, upload usingIETF ID Submission Tool . * *2013-02-25 (Monday):*Internet Draft final submission cut-off by UTC 24:00, upload usingIETF ID Submission Tool . * *2013-02-27 (Wednesday):*Draft Working Group agendas due by UTC 24:00 * *2013-03-04 (Monday):*Revised Working Group agendas due by UTC 24:00 * *2013-03-10 - 2013-03-15: 86th IETF Meeting in Orlando, Florida, USA.* --------------070000010909020708030703 Content-Type: text/calendar; name="86-important-dates.ics" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="86-important-dates.ics" BEGIN:VCALENDAR METHOD:PUBLISH VERSION:2.0 X-WR-CALNAME:IETF 86 Important Dates PRODID:-//Apple Inc.//iCal 4.0.4//EN X-APPLE-CALENDAR-COLOR:#492BA1 X-WR-TIMEZONE:America/Los_Angeles CALSCALE:GREGORIAN BEGIN:VEVENT CREATED:20121011T172155Z UID:F9C7F12B-4B51-4124-9D52-23A3CFA63B3B DTEND;VALUE=DATE:20121215 TRANSP:TRANSPARENT SUMMARY:IETF Online Registration opens DTSTART;VALUE=DATE:20121210 DTSTAMP:20121011T184242Z SEQUENCE:4 BEGIN:VALARM X-WR-ALARMUID:CA299C71-4A6F-4A9D-B26A-31527DB8E09D TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172232Z UID:BD4E082A-5C9D-4BD6-A131-8516A2BE5FC0 URL;VALUE=URI:https://datatracker.ietf.org/cgi-bin/wg/wg_session_request er.cgi DTEND;VALUE=DATE:20121211 TRANSP:TRANSPARENT SUMMARY:Working Group and BOF scheduling begins. DTSTART;VALUE=DATE:20121210 DTSTAMP:20121011T184320Z SEQUENCE:7 DESCRIPTION:To request a Working Group session\, use the IETF Meeting Se ssion Request Tool BEGIN:VALARM X-WR-ALARMUID:6DD7B6C1-4AAD-4B6C-8621-117D7115F868 TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172418Z UID:4C4E4A2E-51BF-442D-A578-31EE7414078E URL;VALUE=URI:https://datatracker.ietf.org/cgi-bin/wg/wg_session_request er.cgi DTEND;VALUE=DATE:20130115 TRANSP:TRANSPARENT SUMMARY:Cutoff date for requests to schedule Working Group meetings at U TC 24:00. DTSTART;VALUE=DATE:20130114 DTSTAMP:20121011T184333Z SEQUENCE:5 DESCRIPTION:To request a Working Group session\, use the IETF Meeting Se ssion Request Tool BEGIN:VALARM X-WR-ALARMUID:B7AECB14-D6CB-454D-A990-B965F9BB34C2 TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172445Z UID:2581E481-95F7-4D12-96BB-07659E003089 URL;VALUE=URI:http://www.ietf.org/iesg/bof-procedures.html DTEND;VALUE=DATE:20130129 TRANSP:TRANSPARENT SUMMARY:Cutoff date for BOF proposal requests to Area Directors at UTC 2 4:00 DTSTART;VALUE=DATE:20130128 DTSTAMP:20121011T184427Z SEQUENCE:7 DESCRIPTION:To request a BOF\, please see instructions on Requesting a B OF BEGIN:VALARM X-WR-ALARMUID:BC05610E-654D-42B5-9F2F-1476957A5898 TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172540Z UID:17122F68-6F93-4A6E-BD17-2E07C74E9296 DTEND;VALUE=DATE:20130201 TRANSP:TRANSPARENT SUMMARY:Cutoff date for Area Directors to approve BOFs at UTC 24:00 DTSTART;VALUE=DATE:20130131 DTSTAMP:20121011T184436Z SEQUENCE:3 BEGIN:VALARM X-WR-ALARMUID:975456EA-0C1A-48FF-BB06-09CA0BB48C86 TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172554Z UID:ED1265EC-A31D-41D4-A53D-76A778FA6BA7 DTEND;VALUE=DATE:20130208 TRANSP:TRANSPARENT SUMMARY:Preliminary agenda published for comment. DTSTART;VALUE=DATE:20130207 DTSTAMP:20121011T184451Z SEQUENCE:3 BEGIN:VALARM X-WR-ALARMUID:3AC50668-D205-488F-9B35-1EFB8496ED76 TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172606Z UID:C38EF1F2-CEFC-4A8D-BA44-FFC1111CE6F6 DTEND;VALUE=DATE:20130212 TRANSP:TRANSPARENT SUMMARY:Cutoff date for requests to reschedule Working Group and BOF mee tings UTC 24:00 DTSTART;VALUE=DATE:20130211 DTSTAMP:20121011T184500Z SEQUENCE:3 BEGIN:VALARM X-WR-ALARMUID:D996084A-ECBB-40FF-85D2-83F37FF38FD6 TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172618Z UID:A92F3B70-8298-48C2-AD2E-16912F5C2B9C DTEND;VALUE=DATE:20130212 TRANSP:TRANSPARENT SUMMARY:Working Group Chair approval for initial document (Version -00) submissions appreciated by UTC 24:00 DTSTART;VALUE=DATE:20130211 DTSTAMP:20121011T184509Z SEQUENCE:3 BEGIN:VALARM X-WR-ALARMUID:1FF06A9C-E512-4AE6-B238-233D05F94416 TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172629Z UID:72904634-94A3-4F97-8FBB-072FC74BB57C DTEND;VALUE=DATE:20130216 TRANSP:TRANSPARENT SUMMARY:Final agenda to be published DTSTART;VALUE=DATE:20130215 DTSTAMP:20121011T184518Z SEQUENCE:3 BEGIN:VALARM X-WR-ALARMUID:AEFA51AB-0854-4993-A2A7-EEDE2DF973B2 TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172642Z UID:072696D9-78CC-4CCC-AF12-23341ADA99D0 DTEND;VALUE=DATE:20130219 TRANSP:TRANSPARENT SUMMARY:Internet Draft Cut-off for initial document (-00) submission by UTC 24:00 DTSTART;VALUE=DATE:20130218 DTSTAMP:20121011T184531Z SEQUENCE:4 URL;VALUE=URI:https://datatracker.ietf.org/submit/ BEGIN:VALARM X-WR-ALARMUID:2F075341-AC8B-44CB-887A-7C47CCB17D2D TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172705Z UID:647FE6D1-36F4-4705-89C7-1BC1A1CBF108 DTEND;VALUE=DATE:20130226 TRANSP:TRANSPARENT SUMMARY:Internet Draft final submission cut-off by UTC 24:00 DTSTART;VALUE=DATE:20130225 DTSTAMP:20121011T184543Z SEQUENCE:4 URL;VALUE=URI:https://datatracker.ietf.org/submit/ BEGIN:VALARM X-WR-ALARMUID:9AC8A19B-D21B-4AA0-B680-E89ECBF96F8E TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172800Z UID:9489CD1D-407D-435D-B15A-FA54C6EEECE1 DTEND;VALUE=DATE:20130302 TRANSP:TRANSPARENT SUMMARY:Early Bird registration and payment cut-off at UTC 24:00 DTSTART;VALUE=DATE:20130301 DTSTAMP:20121011T184553Z SEQUENCE:3 BEGIN:VALARM X-WR-ALARMUID:667213B6-04D5-47FE-8F10-5E054F83EE79 TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172812Z UID:7F2DEEA4-D514-49EF-A731-1C239D6B8C7F DTEND;VALUE=DATE:20130305 TRANSP:TRANSPARENT SUMMARY:Revised Working Group agendas due by UTC 24:00 DTSTART;VALUE=DATE:20130304 DTSTAMP:20121011T184608Z SEQUENCE:4 URL;VALUE=URI:https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi BEGIN:VALARM X-WR-ALARMUID:B430EFB0-3436-4310-B182-3CD2606D2787 TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172829Z UID:69DBC085-784E-4716-95F5-E84F983C32E9 DTEND;VALUE=DATE:20130305 TRANSP:TRANSPARENT SUMMARY:Registration cancellation cut-off at UTC 24:00 DTSTART;VALUE=DATE:20130304 DTSTAMP:20121011T184615Z SEQUENCE:3 BEGIN:VALARM X-WR-ALARMUID:18167297-D2CE-4856-9D6D-62B66A15B4D0 TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172847Z UID:E978C395-7A9B-4D85-B50B-9C8911014E09 DTEND;VALUE=DATE:20130309 TRANSP:TRANSPARENT SUMMARY:Final Pre-Registration and Pre-Payment cut-off at 17:00 local me eting time DTSTART;VALUE=DATE:20130308 DTSTAMP:20121011T184623Z SEQUENCE:3 BEGIN:VALARM X-WR-ALARMUID:154E786F-2A63-4F99-AB76-889E43F37C5A TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172907Z UID:A4EA35D2-4666-485F-B0DE-11F9E092BF74 DTEND;VALUE=DATE:20130316 TRANSP:TRANSPARENT SUMMARY:86th IETF Meeting in Orlando\, Florida\, USA DTSTART;VALUE=DATE:20130310 DTSTAMP:20121011T184633Z SEQUENCE:4 BEGIN:VALARM X-WR-ALARMUID:D2F86F37-7A65-4409-B0D3-E8C8E817F4DE TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172928Z UID:F0864563-AEB0-4599-92F3-5A88CBF58BAD DTEND;VALUE=DATE:20130413 TRANSP:TRANSPARENT SUMMARY:Proceedings submission cutoff date by UTC 24:00 DTSTART;VALUE=DATE:20130412 DTSTAMP:20121011T184644Z SEQUENCE:4 URL;VALUE=URI:https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi BEGIN:VALARM X-WR-ALARMUID:17B10F22-1665-4043-9E52-A410EDE6CAF9 TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT BEGIN:VEVENT CREATED:20121011T172950Z UID:25485867-18AA-4398-9DFA-584E6347710C DTEND;VALUE=DATE:20130502 TRANSP:TRANSPARENT SUMMARY:Proceedings submission corrections cutoff date by UTC 24:00 DTSTART;VALUE=DATE:20130501 DTSTAMP:20121011T184710Z SEQUENCE:4 URL;VALUE=URI:https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi BEGIN:VALARM X-WR-ALARMUID:0C286527-81C9-45DA-8B9E-35E145AC39B4 TRIGGER:PT10H ATTACH;VALUE=URI:Basso ACTION:AUDIO END:VALARM END:VEVENT END:VCALENDAR --------------070000010909020708030703-- From ek@google.com Tue Dec 4 02:24:07 2012 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 6C90721F89AE for ; Tue, 4 Dec 2012 02:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03-D+Hij-JuR for ; Tue, 4 Dec 2012 02:24:06 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id D952D21F89B8 for ; Tue, 4 Dec 2012 02:24:05 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so542042qad.10 for ; Tue, 04 Dec 2012 02:24:05 -0800 (PST) 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:content-type; bh=hGnlgA6zHmFpi8CS0WvfjUXGBhtCkiOpNQLQYqq9Gqw=; b=njBga1ETrUKqC/3k9nhIjWHhOlIcTs9+46gGRD+EGStcKg1bYhmtkTPbncDBaAGlNE g7oGA9x4rD/Aq/Vh7rdCLry3rrMP9jHbipNIf6itiX/jbV/dCGq4W0DWjLgZaFp4mFib FDAhL/+qY9k7+oqpoM0NBjwTlFYPXUJ8OiLTlDsGBqh1sFNvwsgtv4K24KkNjxSHuNy9 xl4y0tN3j5vo0vqCJ2BlcDAWMRgC0D6MlOhm9afbvq8QghFOTnM9H2UpPoRvUkiYNjTO kTOedovg6y228UrOEHd4E3krwHhWtGtM4hRQe4SNx/hGXa8mxl8puBxdg//1Jx9UBEiH 7G6g== X-Google-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:content-type:x-gm-message-state; bh=hGnlgA6zHmFpi8CS0WvfjUXGBhtCkiOpNQLQYqq9Gqw=; b=O3n2M6meZtamBW9e7aJEPL6B7UczkbjDQuRu7qZnwJ5XOLxndH64h0lIusMGIfGJeC MBx0hqfEoFKWHA7HQ/dQHVRamxj2hN+amUSaYjMvTDwZy4CD8YPDtXDZEBksO7197zjk 5NBz8r0eHmw8rrouqTS6WRyskrqkiDHpsn0Ce7ZwhKRxbCfSnz7RVcyyBJWG2BSTh69o Bt/Wve/t4mTwnHP42S84XP+DLkOwxourk4jFmdxHWt6DygVLIYECS+OhJlJnLoUr4pGu ZMyvPQ4kZzYu+4E1Q6GoygwXalN5IeQccB9BYi+gGpwjn4gaWP7Y4XERTWpQiJFQts87 umTQ== Received: by 10.229.170.232 with SMTP id e40mr5067910qcz.68.1354616645105; Tue, 04 Dec 2012 02:24:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.171.66 with HTTP; Tue, 4 Dec 2012 02:23:44 -0800 (PST) In-Reply-To: References: <00ad01cdc7f9$4b72eee0$e258cca0$@asgard.org> <20121124113402.GA8432@spike.0x539.de> <20121124191227.GR19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412048@mbx-01.win.nominum.com> <20121125104739.GV19111@Space.Net> <8D23D4052ABE7A4490E77B1A012B630747412650@mbx-01.win.nominum.com> <20121125163645.GA19111@Space.Net> <50B29240.1010205@lacnic.net> From: Erik Kline Date: Tue, 4 Dec 2012 19:23:44 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQn1SuFNDhqF1Fdfu5S+bMVTa2FIVV36YtE7LSlBhrsbaeKdbJfZUOem8F9hdw6dc8B549zQYND22eBPju5rynmssSsRHx8N7vlQA1J7HbuyeHhb9PN0lVayI7aeVB8wPlIBpHuQ5/PlmPhvKEM3NkNFqXs4WYdekb6geCb8DtTZhsyNaF5sxYllWqecoGmM/Y+s+ikp Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new version of IPv6 rDNS for ISPs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 10:24:07 -0000 On 26 November 2012 12:13, Mikael Abrahamsson wrote: > On Sun, 25 Nov 2012, Arturo Servin wrote: > >> The "problem" with WHOIS is not scalability. It is that it does >> not contain information about single IP addresses. The granularity just goes >> to some level of allocation from ISPs to other entities. > > > It depends on what problem you're trying to solve. If you want to convey > "ip-w-x-y-z.isp.net", because people want to get an idea what ISP you're > using, then you don't need individualism. Ingrained in my fingers now is the idea that the quickest way for me to get some concept of the origin of an IP address was to do a traceroute[6] to it without the -n flag. Even if the host doesn't have a PTR itself most ISPs do have records for some parts of their infrastructure, which is often sufficient. +1 to the "autogenerate PTRs according to format '%foo'" feature; seems handy. It's something I've been wanting to get around to myself for a while now. (For that matter, I think DNS servers could autogenerate AAAAs for ip6.arpa names and As for in-addr.arpa names as well. :-) ----- With respect to the draft, I think section 2.1 seems mislabeled. "No response" sounds like it's describing a "drop the query" approach, when really it's more like "non-existent domainname" (as the error name implies :). Also, you might note that applications that do these kinds of lookups may cache the NXDOMAINs differently from affirmative answers, depending on the SOA values. If a provider is seeing a high number of such lookups from the same (not-deliberately-abusive) source it may want to consider adjusting the NACK timing or just providing some more cacheable answer. But I have no idea what that kind of traffic looks like to an ISP, and it's probably not a big problem. From rafiee@hpi.uni-potsdam.de Tue Dec 4 02:41:09 2012 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 7F1F521F86EE; Tue, 4 Dec 2012 02:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUwNzhaR1nfm; Tue, 4 Dec 2012 02:41:08 -0800 (PST) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id C377921F86AB; Tue, 4 Dec 2012 02:41:08 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id AD868D2C9F; Tue, 4 Dec 2012 11:41:06 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Tue, 4 Dec 2012 11:41:06 +0100 From: "Rafiee, Hosnieh" To: "DNSOP@ietf.org" Date: Tue, 4 Dec 2012 11:41:05 +0100 Thread-Topic: New version available, Please comment on draft-rafiee-intarea-cga-tsig-01.txt Thread-Index: Ac3JBFwvFEnPMQYYT+CKEJ+BPKWaXgAAJcyQAkGrajA= Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: [v6ops] New version available, Please comment on draft-rafiee-intarea-cga-tsig-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 10:41:09 -0000 DQpIZWxsbywNCkkgcmV2aXNlZCAgbXkgZHJhZnQtcmFmaWVlLWludGFyZWEtY2dhLXRzaWcgaW5j b3Jwb3JhdGluZyB5b3VyIGNvbW1lbnRzIHRoYXQgSSByZWNlaXZlZCBieSBlbWFpbC4gUGxlYXNl IHJldmlldyBteSByZXZpc2VkIGRvY3VtZW50Lg0KQmVzdCBSZWdhcmRzLA0KSG9zbmllaA0KDQoN ClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtcmFmaWVlLWludGFyZWEtY2dhLXRzaWctMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFmaWVlLWludGFyZWEtY2dhLXRzaWcN Ckh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFmaWVl LWludGFyZWEtY2dhLXRzaWctMDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtcmFmaWVlLWludGFyZWEtY2dhLXRzaWctMDENCg0KQWJzdHJh Y3Q6DQogICBUaGUgZmlyc3Qgc3RlcCBpbiB0aGUgVHJhbnNhY3Rpb24gU0lHbmF0dXJlIChUU0lH KSAoUkZDIDI4NDUpIHByb2Nlc3MNCiAgIGlzIHRoZSBnZW5lcmF0aW9uIG9mIGEgc2hhcmVkIHNl Y3JldCB0byBiZSB1c2VkIGJldHdlZW4gYSBETlMgc2VydmVyDQogICBhbmQgYSBob3N0LiBUaGUg c2Vjb25kIHN0ZXAgaXMgdGhlIG1hbnVhbCBleGNoYW5nZSBvZiB0aGUgc2hhcmVkDQogICBzZWNy ZXQgYmV0d2VlbiB0aGUgRE5TIHNlcnZlciBhbmQgdGhlIGhvc3QuIFRoaXMgZG9jdW1lbnQsIENH QS1UU0lHLA0KICAgcHJvcG9zZXMgYSBwb3NzaWJsZSB3YXkgdG8gYXV0b21hdGUgdGhlIG5vdyBt YW51YWwgcHJvY2VzcyB1c2VkIGZvcg0KICAgdGhlIGF1dGhlbnRpY2F0aW9uIG9mIGEgbm9kZSB3 aXRoIGEgRE5TIHNlcnZlciBkdXJpbmcgdGhlIEROUyBVcGRhdGUNCiAgIHByb2Nlc3MgYnkgdXNp bmcgdGhlIHNhbWUgcGFyYW1ldGVycyBhcyBhcmUgdXNlZCBpbiBnZW5lcmF0aW5nIGENCiAgIHNl Y3VyZSBhZGRyZXNzIGluIElQdjYgbmV0d29ya3MsIGkuZS4sIENyeXB0b2dyYXBoaWNhbGx5IEdl bmVyYXRlZA0KICAgQWRkcmVzc2VzIChDR0EpIChSRkMgMzk3MikuIENHQS1UU0lHIGZhY2lsaXRh dGVzIHRoaXMgYXV0aGVudGljYXRpb24NCiAgIHByb2Nlc3MgYW5kIHJlZHVjZXMgdGhlIHRpbWUg bmVlZGVkIGZvciBETlMgVXBkYXRlcy4gVGhlIGN1cnJlbnQNCiAgIHNpZ25hdHVyZSBnZW5lcmF0 aW9uIHByb2Nlc3MgYW5kIHZlcmlmaWNhdGlvbiBtZWNoYW5pc20gaW4gVFNJRyBhcmUNCiAgIHRo dXMgcmVwbGFjZWQgd2l0aCBDR0EuIFRoaXMgYWxnb3JpdGhtIGlzIGFkZGVkLCBhcyBhbiBleHRl bnNpb24sIHRvDQogICBUU0lHIHRvIGVsaW1pbmF0ZSB0aGUgaHVtYW4gaW50ZXJ2ZW50aW9uIG5l ZWRlZCBmb3IgZ2VuZXJhdGlvbiBhbmQNCiAgIGV4Y2hhbmdlIG9mIGtleXMgYmV0d2VlbiBhIERO UyBzZXJ2ZXIgYW5kIGEgaG9zdCB3aGVuIFNFY3VyZSBOZWlnaGJvcg0KICAgRGlzY292ZXJ5IChT RU5EKSAoUkZDIDM5NzEpIGlzIHVzZWQuDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From iesg-secretary@ietf.org Thu Dec 6 13:44:30 2012 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 D7DAF21F8965; Thu, 6 Dec 2012 13:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT3jRQqmhKcT; Thu, 6 Dec 2012 13:44:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE3221F8933; Thu, 6 Dec 2012 13:44:30 -0800 (PST) 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: 4.36 Message-ID: <20121206214430.15335.30515.idtracker@ietfa.amsl.com> Date: Thu, 06 Dec 2012 13:44:30 -0800 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (IPv6 Guidance for Internet Content and Application Service Providers) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 21:44:31 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'IPv6 Guidance for Internet Content and Application Service Providers' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-12-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers, or to any enterprise network preparing for IPv6 users. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Fri Dec 7 14:36:38 2012 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 A74A821F862A; Fri, 7 Dec 2012 14:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LciTgN68l4Y0; Fri, 7 Dec 2012 14:36:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81CD21F84F0; Fri, 7 Dec 2012 14:36:37 -0800 (PST) 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: 4.36 Message-ID: <20121207223637.31325.8570.idtracker@ietfa.amsl.com> Date: Fri, 07 Dec 2012 14:36:37 -0800 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (464XLAT: Combination of Stateful and Stateless Translation) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 22:36:38 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - '464XLAT: Combination of Stateful and Stateless Translation' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-12-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1730/ From sm@resistor.net Sun Dec 9 09:09:00 2012 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 D840921F8C9C for ; Sun, 9 Dec 2012 09:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbZijVQ2tSSR for ; Sun, 9 Dec 2012 09:09:00 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BED21F8C7E for ; Sun, 9 Dec 2012 09:09:00 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qB9H8sex024583 for ; Sun, 9 Dec 2012 09:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1355072938; bh=nFNsQeT8O9qqqgWneHgOz+teRTZ7pKFHxruJYSubT+4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=EHPYLis8BuxeHIxurpEDeiPkMNLDnCv9UEZNVlXA+Vd049GIQlDescswNHdKURVVW RPiYGom5hRJjP0nf+gGy6/5mh9aJKVUB2dRuWDkzaT4t/Izkf5wWoiaWyPo9riSwXy +1Ugy7acLYaoD1cYwoNwA75o3j3bQrkhX2BAI79E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1355072938; i=@resistor.net; bh=nFNsQeT8O9qqqgWneHgOz+teRTZ7pKFHxruJYSubT+4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=WPW//Oaw8B+YX2LlW3BFqcZHRzJvCLdEoq6Cq+DOezrEz7sols3NLHKcP1YzHXMtp krBvSPLjnYhKY1MGyC7CTM1B5tiNbcjv7X8ZuwIFNf75L8jaOKwjWp//7wdQPiKvxY CtMI4arCtYnh+iKT9zAgZZEJjSARY8Cowdmg/0+s= Message-Id: <6.2.5.6.2.20121209085216.0922af70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 09 Dec 2012 09:08:03 -0800 To: v6ops@ietf.org From: SM In-Reply-To: <20121207223637.31325.8570.idtracker@ietfa.amsl.com> References: <20121207223637.31325.8570.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [v6ops] Last Call: (464XLAT: Combination of Stateful and Stateless Translation) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 17:09:01 -0000 At 14:36 07-12-2012, The IESG wrote: >The IESG has received a request from the IPv6 Operations WG (v6ops) to >consider the following document: >- '464XLAT: Combination of Stateful and Stateless Translation' > as Best Current Practice > >The IESG plans to make a decision in the next few weeks, and solicits I'll label this comment as a nit as the intended status of the draft has already been discussed outside the working group. Section 2 mentions that: "This BCP only applies when the following two criteria are present:" The document is about specific use cases. Documents about architecture are usually published as Informational. There are as usual the exceptions. There is a "test" that is used for IPR material on the Standards Track. This "test" cannot be applied to a BCP. RFC 2119 usage in the draft seems to be more about conformance than interoperability. I don't see a strong case for a BCP; I suggest an Informational status. Regards, -sm From julien.ietf@gmail.com Tue Dec 11 11:48:30 2012 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 5035D21F8608 for ; Tue, 11 Dec 2012 11:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GL9b5-qBTcOx for ; Tue, 11 Dec 2012 11:48:29 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C50521F858F for ; Tue, 11 Dec 2012 11:48:29 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1806390eaa.31 for ; Tue, 11 Dec 2012 11:48:28 -0800 (PST) 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:content-type; bh=M81aYI5ococF0AAejoFamQTzlcM2bQvt33uvZrIE/5E=; b=pPyvBsSJegMGzV+bLuS+B7zNjFPzfPwo3zkAl27wWRSPlGEH7BQaz+stOo5cSLPIVn vghxXmyRgfQDP4VIEy1kb7IkBuXA8AjFxXhVsYLzUJBASxoFQtDKF7K5B5fjWkUQQGAR 07s1Vp8FNvXpv9TsB1dk+HJgqhy/J/WU35962IZ//74iXTBwvXTo4n2OGx4wsg8O/g1T h8b1QpRTPhmZ5jQlbQz3yr2kvg4WDhQnSxExRl66eIQm7YezFD3Wq97WslM3w/+NfZnN eY4sAxOtbtLbl53mhn3O7aAv+icRGjtmLSB/GL67at8d5GK0HS1u2VISMkhyORkomxxd U+bA== MIME-Version: 1.0 Received: by 10.14.225.194 with SMTP id z42mr63497996eep.22.1355255308842; Tue, 11 Dec 2012 11:48:28 -0800 (PST) Received: by 10.223.191.136 with HTTP; Tue, 11 Dec 2012 11:48:28 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Dec 2012 11:48:28 -0800 Message-ID: From: Julien Laganier To: jouni korhonen Content-Type: multipart/alternative; boundary=047d7b66f24b43780d04d098f75f Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 19:48:30 -0000 --047d7b66f24b43780d04d098f75f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 29, 2012 at 12:17 AM, jouni korhonen wrote: > > On Nov 28, 2012, at 7:52 PM, Julien Laganier wrote: > > > Rajiv and Jouni, > > > > > > On Sun, Nov 25, 2012 at 4:58 AM, jouni korhonen > wrote: > > Hi, > > > > On Sun, Nov 25, 2012 at 12:07 PM, Rajiv Asati (rajiva) > wrote: > > > > > > Indeed. No DAD by GGSN/PGW for the /64 assigned to the UE. > > > > Correct. > > > > > > I know that there's no DAD for addresses in the /64. > > > > My comment was about NUD... > > And no NUD either. > When you say that PGW/GGSN don't do NUD, are you talking about a standard specification, or an implementation? --julien --047d7b66f24b43780d04d098f75f Content-Type: text/html; charset=ISO-8859-1 On Thu, Nov 29, 2012 at 12:17 AM, jouni korhonen <jouni.nospam@gmail.com> wrote:

On Nov 28, 2012, at 7:52 PM, Julien Laganier wrote:

> Rajiv and Jouni,
>
>
> On Sun, Nov 25, 2012 at 4:58 AM, jouni korhonen <jouni.nospam@gmail.com> wrote:
> Hi,
>
> On Sun, Nov 25, 2012 at 12:07 PM, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:
> >
> > Indeed. No DAD by GGSN/PGW for the /64 assigned to the UE.
>
> Correct.
>
>
> I know that there's no DAD for addresses in the /64.
>
> My comment was about NUD...

And no NUD either.

When you say that PGW/GGSN don't do NUD, are you talking about a standard specification, or an implementation?

--julien
--047d7b66f24b43780d04d098f75f-- From jouni.nospam@gmail.com Tue Dec 11 13:03:22 2012 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 2778D21F8529 for ; Tue, 11 Dec 2012 13:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxKYuTmz+rIN for ; Tue, 11 Dec 2012 13:03:21 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 61ADF21F8525 for ; Tue, 11 Dec 2012 13:03:21 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3583215lah.31 for ; Tue, 11 Dec 2012 13:03:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=s4jbdXTXFYm+I2DPNnkAClpb58uRqJkTukNKsUhGYoU=; b=qopWQasbLfGbijvNsJwL0Xqfpzq+Pa+gn+nJiCYLyBp7yG8lnlQyOWgXJRZT2l5PTo tC6lNwHUIEP0GKPibANoaQUquVUDdiSXS2e2jxNgG8ceypFiDlorbZFP5+U+dFgfZ1qL 1yTjWIx+J6T1SeMn7MUU7W4jJFk8yjQZNt1Bzh9UJUk9y/VAXBHpvaALC4sz4tOefdrI YRGOd8jeQ14x1OI/hak+Q+iteoDf1R5N++ajPvSV3Wo5xikfN+uo9yb2pDvpU/bGZkCI q8weDIfXiH4My8RTZLkIuy7ztifGe2FkmhO6LhEGp4QKM8wi6KE2hqLpxuPApOaG+//P jd2w== Received: by 10.112.82.166 with SMTP id j6mr8184358lby.25.1355259800220; Tue, 11 Dec 2012 13:03:20 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id pw17sm9778040lab.5.2012.12.11.13.03.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Dec 2012 13:03:19 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: Date: Tue, 11 Dec 2012 23:03:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> References: To: Julien Laganier X-Mailer: Apple Mail (2.1499) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 21:03:22 -0000 On Dec 11, 2012, at 9:48 PM, Julien Laganier = wrote: > > I know that there's no DAD for addresses in the /64. > > > > My comment was about NUD... >=20 > And no NUD either. >=20 > When you say that PGW/GGSN don't do NUD, are you talking about a = standard specification, or an implementation? >=20 > --julien Both. For the specification part, I admit, I felt a bit uneasy with my = statement ;) However, I do not see a reason why to do so, since the /64 = independent of the IID gets forwarded to the UE in any case. - Jouni= From joelja@bogus.com Tue Dec 11 21:54:51 2012 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 C03C221F88DE for ; Tue, 11 Dec 2012 21:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.22 X-Spam-Level: X-Spam-Status: No, score=-102.22 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byxo8wry84hO for ; Tue, 11 Dec 2012 21:54:50 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 07A0E21F8DBF for ; Tue, 11 Dec 2012 21:54:49 -0800 (PST) Received: from joels-MacBook-Air.local (c-98-207-206-4.hsd1.ca.comcast.net [98.207.206.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qBC5smvs042969 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Wed, 12 Dec 2012 05:54:48 GMT (envelope-from joelja@bogus.com) Message-ID: <50C81C22.8050303@bogus.com> Date: Tue, 11 Dec 2012 21:54:42 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: IPv6 Ops WG References: <20121212054440.32552.71045.idtracker@ietfa.amsl.com> In-Reply-To: <20121212054440.32552.71045.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121212054440.32552.71045.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 12 Dec 2012 05:54:48 +0000 (UTC) Subject: [v6ops] Fwd: v6ops - New Meeting Session Request for IETF 86 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 05:54:51 -0000 FYI this was my initial request. other working groups that have requested sessions that currently list us as a conflict are: dhc, netconf -------- Original Message -------- Subject: v6ops - New Meeting Session Request for IETF 86 Date: Tue, 11 Dec 2012 21:44:40 -0800 From: "IETF Meeting Session Request Tool" To: session-request@ietf.org CC: v6ops-ads@tools.ietf.org, fred.baker@cisco.com, joelja@bogus.com, jjaeggli@zynga.com A new meeting session request has just been submitted by %s, a chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Joel Jaeggli Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 300 Conflicts to Avoid: First Priority: 6man behave homenet softwire opsarea opsawg pcp Special Requests: --------------------------------------------------------- From alexandru.petrescu@gmail.com Thu Dec 13 08:26:50 2012 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 3DBD521F8B13 for ; Thu, 13 Dec 2012 08:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.889 X-Spam-Level: X-Spam-Status: No, score=-9.889 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUZXqha59V3F for ; Thu, 13 Dec 2012 08:26:49 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2989421F8B0C for ; Thu, 13 Dec 2012 08:26:48 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qBDGQlj7022031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Dec 2012 17:26:47 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qBDGQllb013343 for ; Thu, 13 Dec 2012 17:26:47 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qBDGQc7a018390 for ; Thu, 13 Dec 2012 17:26:47 +0100 Message-ID: <50CA01BF.4010203@gmail.com> Date: Thu, 13 Dec 2012 17:26:39 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <001b01cd9eb7$2d05c8d0$87115a70$@tndh.net> In-Reply-To: <001b01cd9eb7$2d05c8d0$87115a70$@tndh.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:26:50 -0000 Le 30/09/2012 04:56, Tony Hain a écrit : > It is not required that the same address be assigned on both > interfaces, just that the UE must defend and respond for the address > used on the wan interface as if it was connected to the lan. LEt me bring back this topic, after a few experiments. The requirement that UE defends that address is only required only when the cellular link is not point-to-point (i.e. it is Ethernet-compatible, like CDC-Ethernet, and does ND). In other more mundance cases like ptp links with ppp software the Access Router on that ptp link will never send NS (it's a 'no ARP' interface) and have a connected route and just deliver. And on these ptp links the 64share trick of re-advertising the received /64 works without proxy ND. Alex I can't think of any cases > where using the duplicated address breaks anything, but it does seem > like there might be some diagnostic benefit to having a predictable > offset on the lan interface address. It is not like there is a > shortage of addresses and we need to duplicate as a conservation > measure... ;) > > Tony > >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Cameron Byrne Sent: >> Saturday, September 29, 2012 2:51 PM To: Eric Vyncke (evyncke) Cc: >> v6ops@ietf.org; draft-byrne-v6ops-64share@tools.ietf.org Subject: >> Re: [v6ops] new draft: draft-byrne-v6ops-64share >> >> On Sat, Sep 29, 2012 at 2:27 PM, Eric Vyncke (evyncke) >> wrote: >>> Isn't it easier to copy the MTU option from the RA received by >>> the handset to the RA sent on the LAN? Of course, when there is >>> no MTU option in the received RA on the WAN link, then, a SHOULD >>> set MTU option to 1480 seems good >>> >> >> Yes, this will be the logic that we will bring to the text of > draft-binet-v6ops- >> cellular-host-reqs-rfc3316update >> >> CB >> >>> -éric >>> >>>> -----Original Message----- From: v6ops-bounces@ietf.org >>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Cameron Byrne >>>> Sent: samedi 29 septembre 2012 21:26 To: Mikael Abrahamsson >>>> Cc: v6ops@ietf.org; draft-byrne-v6ops-64share@tools.ietf.org >>>> Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share >>>> >>>> On Sat, Sep 29, 2012 at 10:35 AM, Mikael Abrahamsson >>>> wrote: >>>>> On Sat, 29 Sep 2012, fred@cisco.com wrote: >>>>> >>>>>> A new draft has been posted, at >>>>>> http://tools.ietf.org/html/draft-byrne-v6ops-64share. >>>>>> Please take a look at it and comment. >>>>> >>>>> >>>>> I have read it and support that it's a valuable topic to >>>>> publicise an RFC on. >>>>> >>>>> The last paragraph of section 3 about MTU makes sense, but I >>>>> would like to see a little bit more elaboration on why 1440 >>>>> was chosen (rationale). I understand the rationale, but I am >>>>> not sure all readers of >>>> the document do. >>>>> >>>> >>>> I tried to keep it concise, and the MTU issue is quite >>>> important and does require explanation, as you mentioned ... >>>> but on thinking it over more, it would be better to simply >>>> reference this behavior in the more comprehensive >>>> draft-binet-v6ops-cellular-host-reqs-rfc3316update >>>> >>>> So, i will remove the MTU bit from draft-byrne-v6ops-64share >>>> and just make sure it gets covered well in >>>> draft-binet-v6ops-cellular-host-reqs- rfc3316update >>>> >>>> FYI to folks that might be lost here. The 3GPP architecture is >>>> heavily reliant on IP-in-IP/UDP tunnels called GTP (GPRS >>>> tunneling >> protocol). >>>> More often than not, the infrastructure links are set at 1500 >>>> bytes, the cell phone interface is 1500 bytes, and therefore >>>> the GTP tunnels packets need to fragmented since they are >>>> carrying 1500 byte tunneled packets within an IP packet that >>>> will no longer fit on a 1500 byte link. Not pretty. So, >>>> sometimes the carriers get the handsets manually set to a >>>> lower MTU. And, sometimes the HTTP proxies reset the >> MSS to avoid fragments. >>>> >>>> Given that RA can advertise MTU, this is a good opportunity to >>>> properly and dynamically set the mobile device's MTU without >>>> causing lots of fragment reassembly state in the network or >>>> otherwise mucking with MSS. This will also be relevant and >>>> true for devices on the tethered LAN since all those packets >>>> will be put into the MTU constrained GTP tunnels on their way >>>> through the mobile provider and to >> the Internet. >>>> >>>> CB >>>> >>>>> -- Mikael Abrahamsson email: swmike@swm.pp.se >>>>> >>>>> _______________________________________________ v6ops >>>>> mailing list v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Thu Dec 13 08:32:52 2012 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 BB77F21F8A85 for ; Thu, 13 Dec 2012 08:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaoezCbEotBf for ; Thu, 13 Dec 2012 08:32:52 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id D3C1921F8A94 for ; Thu, 13 Dec 2012 08:32:51 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qBDGWos4026275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Dec 2012 17:32:50 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qBDGWo6p015481 for ; Thu, 13 Dec 2012 17:32:50 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qBDGWkeb012718 for ; Thu, 13 Dec 2012 17:32:50 +0100 Message-ID: <50CA032E.2040700@gmail.com> Date: Thu, 13 Dec 2012 17:32:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:32:52 -0000 Le 22/11/2012 02:14, Julien Laganier a écrit : > Hello, > > I have a question regarding the interaction between NUD and the > method described in this draft. > > The GGSN/PGW acting as a default router advertises via IPv6 RAs a > /64 prefix over the point-to-point link to the User Equipment. > > Assuming the User Equipment employs the method described in this > draft and uses "the 3GPP network assigned /64 to assign itself a > /128 subnet address to the 3GPP radio interface for consistent > network reachability and the same address with a /64 subnet to the > tethered LAN interface.The tethered LAN interface may then advertise > the /64 subnet to the LAN with RA." > > Now a host on the tethered LAN will configure an IPv6 address with > SLAAC based on the advertized /64, and starts to use it. > > When a downlink packets sent towards a host on the tethered LAN > arrives at the GGSN/PGW, who believes the /64 is onlink, if the > GGSN/PGW attempts NUD towards that destination address, in the > current description of the method the UE will not reply (it has > configured only one /128 on its interface facing the 3GPP network). > Thus it seems GGSN/PGW initiated NUD will fail. > > So it seems to me that the current method would work only if a) the > GGSN/PGW doesn't perform NUD for downlink packets sent over the > point-to-point link, I agree, the current method will work if the Access Router does not make NS towards the User Equipment for the IP address of a Host within the LAN. If it does, and the UE doesn't answer then communication fails. This way of _not_ doing ND on ptp links is natural with many cellular links, but non-natural with _some_ cellular connections (CDC-Ethernet). Some operators of cellular links support both ways in the same cellular network (i.e. the UE decides, not the operator, whether to start a noARP ppp connection or start a ND-enabled CDC-Ethernet, using same SIM card, on same operator). Alex > or b) the UE answers NUD probes for all addresses in the /64. > > Is this correct? > > Thanks, > > --julien > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Thu Dec 13 08:37:09 2012 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 4A03121F8A7B for ; Thu, 13 Dec 2012 08:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.82 X-Spam-Level: X-Spam-Status: No, score=-9.82 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G2Af19V0R0U for ; Thu, 13 Dec 2012 08:37:08 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8C221F8A70 for ; Thu, 13 Dec 2012 08:37:08 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qBDGb7qO028366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Dec 2012 17:37:07 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qBDGb7A4016576 for ; Thu, 13 Dec 2012 17:37:07 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qBDGb6bd023951 for ; Thu, 13 Dec 2012 17:37:06 +0100 Message-ID: <50CA0432.5040406@gmail.com> Date: Thu, 13 Dec 2012 17:37:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:37:09 -0000 Le 22/11/2012 04:47, Cameron Byrne a écrit : > On Wed, Nov 21, 2012 at 5:14 PM, Julien Laganier > wrote: >> Hello, >> >> I have a question regarding the interaction between NUD and the >> method described in this draft. >> >> The GGSN/PGW acting as a default router advertises via IPv6 RAs a >> /64 prefix over the point-to-point link to the User Equipment. >> >> Assuming the User Equipment employs the method described in this >> draft and uses "the 3GPP network assigned /64 to assign itself a >> /128 subnet address to the 3GPP radio interface for consistent >> network reachability and the same address with a /64 subnet to the >> tethered LAN interface.The tethered LAN interface may then >> advertise the /64 subnet to the LAN with RA." >> >> Now a host on the tethered LAN will configure an IPv6 address with >> SLAAC based on the advertized /64, and starts to use it. >> >> When a downlink packets sent towards a host on the tethered LAN >> arrives at the GGSN/PGW, who believes the /64 is onlink, if the >> GGSN/PGW attempts NUD towards that destination address, in the >> current description of the method the UE will not reply (it has >> configured only one /128 on its interface facing the 3GPP >> network). Thus it seems GGSN/PGW initiated NUD will fail. >> >> So it seems to me that the current method would work only if a) >> the GGSN/PGW doesn't perform NUD for downlink packets sent over >> the point-to-point link, or b) the UE answers NUD probes for all >> addresses in the /64. >> >> Is this correct? >> > > AFAIK, the GGSN/PGW does not do NUD. The /64 is considered off-link > [1] and therefore no host resolution is done I think he meant ND (its ip-mac resolution part), not just the particular unreachability detection NUD. AFAIK there exist operators which do ND on the cellular links, in some cases. BEsides always sending RA on cellular links, it may send NS if it's EThernet compatible. The section you cite in [1] has several problems (i.e. it's wrong), especially with respect to its claims vs 3GPP specs vs deployments, but we could discuss separately. Alex > > [1] http://tools.ietf.org/html/rfc6459#section-5.2 > > > > > > CB > >> Thanks, >> >> --julien >> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Thu Dec 13 08:40:30 2012 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 EE8DD21F8B03 for ; Thu, 13 Dec 2012 08:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-mesgj81GCJ for ; Thu, 13 Dec 2012 08:40:29 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id BFC0521F8AF9 for ; Thu, 13 Dec 2012 08:40:28 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qBDGeNmT027766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Dec 2012 17:40:23 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qBDGeNBH017478 for ; Thu, 13 Dec 2012 17:40:23 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qBDGeMuZ025570 for ; Thu, 13 Dec 2012 17:40:23 +0100 Message-ID: <50CA04F7.6080502@gmail.com> Date: Thu, 13 Dec 2012 17:40:23 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:40:30 -0000 Le 25/11/2012 11:07, Rajiv Asati (rajiva) a écrit : > > Indeed. No DAD by GGSN/PGW for the /64 assigned to the UE. One does not do a DAD on a prefix (be it /64 or any <128), right? DAD would need to be done by the UE not by GGSN/PGW. I haven't seen DAD on these links but I may try to find. DAD is just one part of ND, others are NUD, SLAAC, etc. > BTW, the below text in the security consideration section reads as > if GGSN/PGW and UE are on-link (wrt IPv6), if read together with the > next line. Certainly they must be on-link, can't be offlink. Alex > > // 9. Security Considerations > > .. .. > > > and the fact that the UE and the first-hop router (PDN-GW/GGSN or > SGW) are the only nodes on the link. For off-link IPv6 attacks, the > 3GPP EPS is as vulnerable as any IPv6 system. > > > > Cheers, Rajiv > > > > > // 5.2. IPv6 Address Configuration > > .. .. > > > In the 3GPP link model, the /64 prefix assigned to the UE cannot be > used for on-link determination (because the L-bit in the Prefix > Information Option (PIO) in the RA must always be set to zero). If > the advertised prefix is used for SLAAC, then the A-bit in the PIO > must be set to one. Details of the 3GPP link-model and address > > > > > > > > -----Original Message----- From: Cameron Byrne > Date: Wednesday, November 21, 2012 10:47 PM To: Julien Laganier > Cc: "v6ops@ietf.org" , > "draft-byrne-v6ops-64share@tools.ietf.org" > Subject: Re: [v6ops] NUD > and draft-byrne-v6ops-64share-03 > >> On Wed, Nov 21, 2012 at 5:14 PM, Julien Laganier >> wrote: >>> Hello, >>> >>> I have a question regarding the interaction between NUD and the >>> method described in this draft. >>> >>> The GGSN/PGW acting as a default router advertises via IPv6 RAs a >>> /64 prefix over the point-to-point link to the User Equipment. >>> >>> Assuming the User Equipment employs the method described in this >>> draft and uses "the 3GPP network assigned /64 to assign itself a >>> /128 subnet address to the 3GPP radio interface for consistent >>> network reachability and the same address with a /64 subnet to >>> the tethered LAN interface.The tethered LAN interface may then >>> advertise the /64 subnet to the LAN with RA." >>> >>> Now a host on the tethered LAN will configure an IPv6 address >>> with SLAAC based on the advertized /64, and starts to use it. >>> >>> When a downlink packets sent towards a host on the tethered LAN >>> arrives at the GGSN/PGW, who believes the /64 is onlink, if the >>> GGSN/PGW attempts NUD towards that destination address, in the >>> current description of the method the UE will not reply (it has >>> configured only one /128 on its interface facing the 3GPP >>> network). Thus it seems GGSN/PGW initiated NUD will fail. >>> >>> So it seems to me that the current method would work only if a) >>> the GGSN/PGW doesn't perform NUD for downlink packets sent over >>> the point-to-point link, or b) the UE answers NUD probes for all >>> addresses in the /64. >>> >>> Is this correct? >>> >> >> AFAIK, the GGSN/PGW does not do NUD. The /64 is considered >> off-link [1] and therefore no host resolution is done >> >> [1] http://tools.ietf.org/html/rfc6459#section-5.2 >> >> >> >> >> >> CB >> >>> Thanks, >>> >>> --julien >>> >>> >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Thu Dec 13 08:41:48 2012 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 3710021F8B07 for ; Thu, 13 Dec 2012 08:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.782 X-Spam-Level: X-Spam-Status: No, score=-9.782 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRs1pmV+ANsB for ; Thu, 13 Dec 2012 08:41:47 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id D825921F8B03 for ; Thu, 13 Dec 2012 08:41:46 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qBDGfc74008258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Dec 2012 17:41:38 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qBDGfc0T017775 for ; Thu, 13 Dec 2012 17:41:38 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qBDGfb6k026095 for ; Thu, 13 Dec 2012 17:41:38 +0100 Message-ID: <50CA0542.9010405@gmail.com> Date: Thu, 13 Dec 2012 17:41:38 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:41:48 -0000 Le 29/11/2012 09:17, jouni korhonen a écrit : > > On Nov 28, 2012, at 7:52 PM, Julien Laganier wrote: > >> Rajiv and Jouni, >> >> >> On Sun, Nov 25, 2012 at 4:58 AM, jouni korhonen >> wrote: Hi, >> >> On Sun, Nov 25, 2012 at 12:07 PM, Rajiv Asati (rajiva) >> wrote: >>> >>> Indeed. No DAD by GGSN/PGW for the /64 assigned to the UE. >> >> Correct. >> >> >> I know that there's no DAD for addresses in the /64. >> >> My comment was about NUD... > > And no NUD either. Ok no NUD but yes ND - the ip-mac NS/NA resolution part. Alex > > - Jouni > > >> >> --julien > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Thu Dec 13 08:44:41 2012 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 93DD821F8B16 for ; Thu, 13 Dec 2012 08:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.769 X-Spam-Level: X-Spam-Status: No, score=-9.769 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pGJqkfJJGDd for ; Thu, 13 Dec 2012 08:44:41 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8E32721F8B07 for ; Thu, 13 Dec 2012 08:44:37 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qBDGiZkd009665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Dec 2012 17:44:35 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qBDGiZhg018567 for ; Thu, 13 Dec 2012 17:44:35 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qBDGiYqX027546 for ; Thu, 13 Dec 2012 17:44:34 +0100 Message-ID: <50CA05F2.50001@gmail.com> Date: Thu, 13 Dec 2012 17:44:34 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> In-Reply-To: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:44:41 -0000 Le 11/12/2012 22:03, Jouni Korhonen a écrit : > > On Dec 11, 2012, at 9:48 PM, Julien Laganier > wrote: > >>> I know that there's no DAD for addresses in the /64. >>> >>> My comment was about NUD... >> >> And no NUD either. >> >> When you say that PGW/GGSN don't do NUD, are you talking about a >> standard specification, or an implementation? >> >> --julien > > Both. For the specification part, I admit, I felt a bit uneasy with > my statement ;) However, I do not see a reason why to do so, since > the /64 independent of the IID gets forwarded to the UE in any case. IT some cases it doesn't. If the link is CDC-Ethernet (a form of 3GPP cellular long-range link, but relying on the use of IEEE-assigned MAC addresses) then not the entire /64 is forwarded to the UE. There is first a NS/NA for the address within that /64 (as we know with WiFi). If no answer NA then packets get dropped. Alex > > - Jouni _______________________________________________ v6ops > mailing list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From cb.list6@gmail.com Thu Dec 13 08:46:06 2012 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 49D5A21F8B90 for ; Thu, 13 Dec 2012 08:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLWYMuaD9O3Q for ; Thu, 13 Dec 2012 08:46:06 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D07621F8B8A for ; Thu, 13 Dec 2012 08:46:05 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1949011lbk.31 for ; Thu, 13 Dec 2012 08:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FZuYFk5Wackm82+gOokaYHUU6vsv/Ezrybh+ydDJgZk=; b=xMf6JfNYQL9BCY31uOZtnne7Sg8ArdsC7OR6SvCfib+Jv4r1JMpkUf81tvM6KIR7FZ nEWPuPFSwucDvvr5CRWBFd219ehJnJhaO5xar+wp7xxtSEMylhNVwu9O36FpjAFryVlZ izxeXKUExQ9g7AbAc4v2WlTcjjy33iFepugfwhD5m/WU39gQWku6VCMF5sgiBGD6qj4B WyhIDn1o807K+J9W/gfLUk7SfxyBzzmX4NB4VPRj1ea8ZKkH3WRyCR3E8Opha2y4+pjK dKrH6H6diR9xUfS93fALjIMhWODrbNxFXK5zVAU4ISDtx04gCOAsGW38cpZh/duV4wNh +Wag== MIME-Version: 1.0 Received: by 10.152.108.42 with SMTP id hh10mr66133lab.4.1355417164412; Thu, 13 Dec 2012 08:46:04 -0800 (PST) Received: by 10.112.44.36 with HTTP; Thu, 13 Dec 2012 08:46:04 -0800 (PST) Date: Thu, 13 Dec 2012 08:46:04 -0800 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] Update of draft-byrne-v6ops-64share-03 as WG doc X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:46:06 -0000 FYI, I will be posting an update soon. If you have any text change suggestions, please send them to me to captured in the next rev. Thanks, Cameron From alexandru.petrescu@gmail.com Thu Dec 13 09:06:49 2012 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 CADED21F8B7A for ; Thu, 13 Dec 2012 09:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.758 X-Spam-Level: X-Spam-Status: No, score=-9.758 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeuzhCiOao1Q for ; Thu, 13 Dec 2012 09:06:48 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2F54321F8B1A for ; Thu, 13 Dec 2012 09:06:46 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qBDH6d0X010981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Dec 2012 18:06:39 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qBDH6dkr026787; Thu, 13 Dec 2012 18:06:39 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qBDH6ZCk006795; Thu, 13 Dec 2012 18:06:39 +0100 Message-ID: <50CA0B1C.3000509@gmail.com> Date: Thu, 13 Dec 2012 18:06:36 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IMADALI Sofiane , DECREMPS Sylvain Subject: Re: [v6ops] example method (was: single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 17:06:49 -0000 Le 27/08/2012 10:54, Lorenzo Colitti a écrit : > Ok, so how about the following? Comments welcome. > > 0. If you get a DHCPv6 prefix delegation: congratulations. You live in > the glorious future. Your carrier has a release 10 network, and is > providing you with tethering (either because they're a just that nice, > or because you paid extra for the privilege). The CLAT simply behaves > like an RFC 6204 router. Done. > > Now for the rest of us. Since we're still here, it means we only have a > single /64. If you don't want to implement tethering, do nothing. If you > do want to implement tethering, proceed as follows (cell0 is the > upstream interface, wlan0 is the downstream): > > 1. Enable tethering only when cell0 is a point-to-point interface (e.g., > 3G, LTE, ...). > 2. When enabling tethering, take the IPv6 address of cell0 (which you > were already using, and need to continue to use because you have open > connections to it), and assign it to wlan0 instead of cell0 > 3. Treat cell0 as unnumbered; when sending out packets, use the IP > address assigned to wlan0. > 4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa like > a standard IPv6 router (decrement TTL, etc.) > 5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa > like a standard IPv6 multicast router (But I don't know anything about > multicast, so I'll shut up now.) > 6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you, > they will fail DAD. > > So far so good. There is no bridging, and since the upstream is a > point-to-point interface, there are no loops. The above method describes how this was made to work. We here have tried it, approximately, and we came up with the following two alternative methods - one ok, one not ok. On the UE CLI us traditional 3G+ ptp connections, in this order, and it works ok. - set forwarding to 1 (and loose ability to configure default route upon reception of RA). - put ppp0 up - put eth0 up - read the address assigned on ppp0 and assign it on eth0 with plen 64 - update radvd.conf/eth0 to put that /64 prefix - add default route through ppp0 (has to be done manually, because ppp0 didnt do it and being a router ignores the default route part of the RA). On the UE use new LTE USB key which support CDC-Ethernet. This LTE USB key has a IEEE-assigned MAC address despite being 3GPP. On CLI do this: - set forwarding to 1. - put wwan0 up - put eth0 up - read address on wwan0 and assign it on eth0 - update radvd.conf/eth0 to put that /64 prefix - add default route through wwan0. On this configuration the operator's router (GGSN?) sends NS on the wwan0 interface for any dst address derived of that /64. The UE does not respond to such an NS, it only responds to the NS for the address which it formed to self. (This can be solved by either proxyND or by maybe operator adding a Full route (instead of currently a Connected Route). OR other.) Alex Note that this is *not* > RFC 4389. But it does not need to be. > > We haven't talked about CLAT yet. There are two cases here: > > 1. The CLAT implementation can use the same IPv6 address as the phone. > In this case, no problem. > 2. The CLAT implementation cannot use the same IPv6 address as the > phone. In this case, either: > a) the CLAT does DAD for that other address as well, or: > b) picks an address that "shouldn't collide" (remi's reserved IID) > > It's as simple as that. So, as far as I can see, the only issue left to > discuss is "do we do 2a or 2b"? > > On Mon, Aug 27, 2012 at 10:09 AM, Hemant Singh (shemant) > > wrote: > > Victor (and also replying to Rajiv in one email), > > -----Original Message----- > From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com > ] > Sent: Sunday, August 26, 2012 8:04 PM > To: Hemant Singh (shemant) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] single /64, ND Proxy, and > draft-ietf-v6ops-464xlat-07.txt > > >I cannot speak for every operator, but for some of us trying to deploy > >IPv6, if I cannot do it with tethering, I cannot deploy it (part > of the > >service). Not supporting tethering would inhibit my ability to > deploy (in > >my case - perhaps for others). > > Got it - you need tethering immediately. Ok, back to the ND Proxy > issues then. > > My wife turns on her cell phone and this CLAT phone uses the > reserved IID and thus does not issue any RA with the ND Proxy P-bit. > A tethered client in a home IPv6 router uses the RA to get a SLAAC > IPv6 address. Behind the IPv6 CPE router is a network bridge. > Subsequently, I turn on my cell phone that supports only an ND Proxy > and a single /64. Before my phone is able to send an RA with the > P-bit set, the bridged behind home router looped my wife's phone RA > to my phone and my phone loops the RA back to the SP. Additionally, > what does my tethered client do if the client receives two different > RA's as described above and specifically how is proxying of NA's > done? Is the NA sent to the ND Proxy phone or the reserved IID > phone when the tethered node has only one interface to receive an NS on? > > Soon as one says tethering, testing for what is working code is very > broad because there could be whole network behind one tethered > client. This is the same point Ray Hunter is making and it would be > good to reply to his email at the URL below. > > http://www.ietf.org/mail-archive/web/v6ops/current/msg13960.html > > Regards, > > Hemant > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From cb.list6@gmail.com Thu Dec 13 15:26:30 2012 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 C40C421F890E for ; Thu, 13 Dec 2012 15:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.236 X-Spam-Level: X-Spam-Status: No, score=-3.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaFSBaSlSVRM for ; Thu, 13 Dec 2012 15:26:26 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F13F21F888E for ; Thu, 13 Dec 2012 15:26:26 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2259901lbk.31 for ; Thu, 13 Dec 2012 15:26:25 -0800 (PST) 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:content-type:content-transfer-encoding; bh=yiYRtDy8N77gs/VUJMM1b97T6Pva7StIXAKEZcdqYq0=; b=AOGHv7LuwnfYp1zE6ITnC6+zjPbCXsnUc/Lk8QvykF76KtZh3Yfy5oZLsvEDHxWHlz zKrIB4VM7pg2IITV/UOlYPn+D1tg772jOUSvHz/hEhlBWH8tGp61yKb0Oj5DIvYHNY14 9qB23bwznKXY0OxCk8rWBjStgvBRhqGWZFX0D0dOyQjoDA4qoUKpgF00SopdVzky4gTV yJ3lGRKc0uVIfLJ42F4yWGT6vfy7ghBREa6w3TUIgZA8hyetE11cE4R370HLOZUn6780 c2ALBQMKvazfhg6WloBfk98wQBqZo0/Gq1QlL0KuxM0WnbBsqPPYbF2a7gCz6VbARXPr B0KQ== MIME-Version: 1.0 Received: by 10.152.124.111 with SMTP id mh15mr745264lab.20.1355441185279; Thu, 13 Dec 2012 15:26:25 -0800 (PST) Received: by 10.112.44.36 with HTTP; Thu, 13 Dec 2012 15:26:25 -0800 (PST) In-Reply-To: <50CA05F2.50001@gmail.com> References: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> <50CA05F2.50001@gmail.com> Date: Thu, 13 Dec 2012 15:26:25 -0800 Message-ID: From: Cameron Byrne To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:26:31 -0000 Alex, On Thu, Dec 13, 2012 at 8:44 AM, Alexandru Petrescu wrote: > Le 11/12/2012 22:03, Jouni Korhonen a =E9crit : > >> >> On Dec 11, 2012, at 9:48 PM, Julien Laganier >> wrote: >> >>>> I know that there's no DAD for addresses in the /64. >>>> >>>> My comment was about NUD... >>> >>> >>> And no NUD either. >>> >>> When you say that PGW/GGSN don't do NUD, are you talking about a >>> standard specification, or an implementation? >>> >>> --julien >> >> >> Both. For the specification part, I admit, I felt a bit uneasy with >> my statement ;) However, I do not see a reason why to do so, since >> the /64 independent of the IID gets forwarded to the UE in any case. > > > IT some cases it doesn't. > > If the link is CDC-Ethernet (a form of 3GPP cellular long-range link, > but relying on the use of IEEE-assigned MAC addresses) then not the > entire /64 is forwarded to the UE. There is first a NS/NA for the > address within that /64 (as we know with WiFi). If no answer NA then > packets get dropped. > > Alex > As far as i know, CDC-Ethernet has nothing to do with 3GPP networks and does not change the network operations or behavior in any way of the network. What i think you are describing is the USB LTE devices may present to the host computer a CDC-Ethernet interface. These USB devices do all manner of "interesting things" to make the host computer inter-operate with the 3GPP network... for example, proving a MAC address or presenting a DHCPv6 server that appears to be coming from the the WAN but in fact is just a function of the local USB software that extracts things like DNS servers from the 3GPP PCO to pass on to the host that would not otherwise be able to parse this info. >> >> - Jouni _______________________________________________ v6ops >> >> mailing list v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From julien.ietf@gmail.com Thu Dec 13 16:55:32 2012 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 E8BF721F8A11 for ; Thu, 13 Dec 2012 16:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRrk0vxTl49d for ; Thu, 13 Dec 2012 16:55:31 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20A1E21F8A0C for ; Thu, 13 Dec 2012 16:55:30 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1664325eek.31 for ; Thu, 13 Dec 2012 16:55:30 -0800 (PST) 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:content-type; bh=448h4VktpxkFbpjxQ4iEDbC4MpZ8WiVcI0EhM+Fzldk=; b=JyE572wQWLihjnEvGadIXvMiGtBf6+OKTkzPkDitE2kQwgayfgmmxR/6d/H3KFpzFs /+AwIZQdFBnKb0977HYm5gBT3csNiu4GShfvGA0S+gZotCZL5l/PnP/GTfXW/BehcSD/ I1kHY+lN49P0/0/BMYbH/3vZRYPGxX4Iwxx6y+PbWfOJtBQMYfRVc92OQMGwlLaPQATY ZWDGYCdiUAjENYZXLAFHCSsqZ3jee0PRGFbV44IGxfgsQS/69aKpNzUJYZlmif3tYVvX 42G/zOFX4ROJBZq7nE9OQL9fh7sVLDE8Ru0o2ZUWAyrOPjHKghG43yJIMhsKXJGb/Uv3 giQw== MIME-Version: 1.0 Received: by 10.14.0.71 with SMTP id 47mr10032321eea.19.1355446530159; Thu, 13 Dec 2012 16:55:30 -0800 (PST) Received: by 10.223.65.68 with HTTP; Thu, 13 Dec 2012 16:55:29 -0800 (PST) In-Reply-To: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> References: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> Date: Thu, 13 Dec 2012 16:55:29 -0800 Message-ID: From: Julien Laganier To: Jouni Korhonen Content-Type: multipart/alternative; boundary=047d7b66f329f1341804d0c57c9e Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 00:55:32 -0000 --047d7b66f329f1341804d0c57c9e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 11, 2012 at 1:03 PM, Jouni Korhonen wrote: > > On Dec 11, 2012, at 9:48 PM, Julien Laganier > wrote: > > > > I know that there's no DAD for addresses in the /64. > > > > > > My comment was about NUD... > > > > And no NUD either. > > > > When you say that PGW/GGSN don't do NUD, are you talking about a > standard specification, or an implementation? > > > > --julien > > Both. For the specification part, I admit, I felt a bit uneasy with my > statement ;) However, I do not see a reason why to do so, since the /64 > independent of the IID gets forwarded to the UE in any case. I am not aware of a specification that says PGW/GGSN do not do NUD. A reason to do so would be full compliance to RFC 4861 such that the PGW/GGSN verify that the neighbors (i.e., the UE) it is sending packets to are indeed reachable and not sent in a black hole. This is independent from the forwarding / routing decision and/or address resolution. So it seems the document should clarify that the described mechanism works only under the assumption that PGW/GGSN do not do NUD. --julien --047d7b66f329f1341804d0c57c9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Dec 11, 2012 at 1:03 PM, Jouni Korhonen <jouni.nospam@gmail.c= om> wrote:

On Dec 11, 2012, at 9:48 PM, Julien Laganier <julien.ietf@gmail.com> wrote:

> > I know that there's no DAD for addresses in the /64.
> >
> > My comment was about NUD...
>
> And no NUD either.
>
> When you say that PGW/GGSN don't do NUD, are you talking about a s= tandard specification, or an implementation?
>
> --julien

Both. For the specification part, I admit, I felt a bit uneasy with m= y statement ;) However, I do not see a reason why to do so, since the /64 i= ndependent of the IID gets forwarded to the UE in any case.

I am not aware of a specification that says PGW/GGSN do= not do NUD. A reason to do so would be full compliance to RFC 4861 such th= at the PGW/GGSN verify that the neighbors (i.e., the UE) it is sending pack= ets to are indeed reachable and not sent in a black hole. This is independe= nt from the forwarding / routing decision and/or address resolution.

So it seems the document should clarify that the descri= bed mechanism works only under the assumption that PGW/GGSN do not do NUD.<= /div>

--julien
--047d7b66f329f1341804d0c57c9e-- From lorenzo@google.com Thu Dec 13 20:11:28 2012 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 1976B21F8C16 for ; Thu, 13 Dec 2012 20:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOgOO6SCZYpe for ; Thu, 13 Dec 2012 20:11:27 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5447721F8C06 for ; Thu, 13 Dec 2012 20:11:27 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so3052913oag.31 for ; Thu, 13 Dec 2012 20:11:21 -0800 (PST) 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:content-type; bh=++hiBSq3XYGEtARQdo4WO04kdQxQo7mvvJSYTpCUweA=; b=WADJEF0S9MZES3rpTeqwhxOauUyR9DU6ImyEtGP8yyz0eodO5YiwySERp8vcF/dGiV 1u7a8B3IV7uvCqw3q57ZOfqvZ8faSuE8JBnuiY+9tcDkCfzipwMrjIMfovQwxDPjc6a9 NYFq0skw4HD2c2KdhfgTnlSQei9oHWnW4MztTNYmH2HMnLzVsA3FMBJ+vESSpzB0DA0t 9Dkus95pNzt1djzjISGXeOjTQAEpb1aGlr+fxY0KTSfXXgTC/XgaH2cDWPKbHqhvIbV5 IZEBvn38SZDeQwc16B9sxKG512axRwKe1WVPgBTiWYNq9w5QiybnAWMxrXftPBL1YFdQ IqVw== X-Google-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:content-type:x-gm-message-state; bh=++hiBSq3XYGEtARQdo4WO04kdQxQo7mvvJSYTpCUweA=; b=pJKvfugdOuXeX0qQX2qXPxuDmSoEAaIu16o/GyXIxKW9sT54bLGhgG7SONyhte1IOs 3Syut8wxppOOlPglejRW75ZkW6smMadNTcFGc6HnVInjgcaPCcNUCiAYpSsGXjyVxlon i+9qs29jWaAzQtZg7TOMOyRqzGw4b70enzj/Fn+JsOR9+LQFhFAROr5h2FuFJoa+rdX8 BXQ9Jj+N3al1Yc1DrbXFeMQFKfoQVgX9C5ZJKFTWbNRxtBr+JaU0q6MdCOb77QVtTXJV Spc0AA99+ZxslFyIWT5XY2NFy0U5VzvXjtMTM4c4C/4EsIq/8i2XuyVeB7kgsMrde6UH VgKA== Received: by 10.182.54.102 with SMTP id i6mr3509580obp.67.1355458280895; Thu, 13 Dec 2012 20:11:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.36.165 with HTTP; Thu, 13 Dec 2012 20:11:00 -0800 (PST) In-Reply-To: <50CA01BF.4010203@gmail.com> References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <001b01cd9eb7$2d05c8d0$87115a70$@tndh.net> <50CA01BF.4010203@gmail.com> From: Lorenzo Colitti Date: Fri, 14 Dec 2012 13:11:00 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=14dae93a114557362c04d0c839e7 X-Gm-Message-State: ALoCoQn6k2HpayY63xj9jfB/ZALzKCd0U1+YLxKJoedhpwtJqUbtnRMYRrDuqHRj0hVoldKoEF7SGJCTwpFgtHNf4gZy10lKN5N9OkMQhCSzqpUr/rk3JAT0ormyocR14yRuU9i9781Noel9aAN2/bOa+3zxcerzSHcfmrWN5K7e9BtwgqCncINQfIUKfKK7t60CkL7tm2Rg Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 04:11:28 -0000 --14dae93a114557362c04d0c839e7 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 14, 2012 at 1:26 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > The requirement that UE defends that address is only required only when > the cellular link is not point-to-point (i.e. it is Ethernet-compatible, > like CDC-Ethernet, and does ND). > > In other more mundance cases like ptp links with ppp software the > AccessRouter on that ptp link will never send NS (it's a 'no ARP' > interface) and have a connected route and just deliver. And on these ptp > links the 64share trick of re-advertising the received /64 works without > proxy ND. > No, it won't work. Suppose I turn on /64 sharing on my phone, and the phone: 1. Is connected to the IPv6 Internet through its cell interface (which is a point-to-point link). 2. Is sharing 2001:db8::/64 3. Has IPv6 address 2001:db8::dead:beef. (It must have an IPv6 address on its cell interface, or it can't reach the IPv6 Internet). If a host behind the phone autoconfigures the address 2001:db8::dead:beef, it will not be able to receive replies from the Internet. It can send packets from 2001:db8::dead:beef, and the phone will (probably) send them to the Internet, but when as someone on the Internet sends a packet to 2001:db8::dead:beef, the phone will receive it through the cellular interface and terminate it - because that address belongs to the phone. So the host needs to be told "don't use 2001:db8::dead:beef, because it belongs to someone else on this link". DAD is the way to do that. --14dae93a114557362c04d0c839e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri= , Dec 14, 2012 at 1:26 AM, Alexandru Petrescu <alexandru.petres= cu@gmail.com> wrote:
The requirement t= hat UE defends that address is only required only when
the cellular link is not point-to-point (i.e. it is Ethernet-compatible, like CDC-Ethernet, and does ND).

In other more mundance cases like ptp links with ppp software the AccessRou= ter on that ptp link will never send NS (it's a 'no ARP' interf= ace)=A0and have a connected route and just deliver. =A0And on these ptp lin= ks the=A064share trick of re-advertising the received /64 works without pro= xy ND.

No, it won't work. Suppose I turn on /= 64 sharing on my phone, and the phone:

1. Is conne= cted to the IPv6 Internet through its cell interface (which is a point-to-p= oint link).
2. Is sharing 2001:db8::/64
3. Has IPv6 address 2001:db8::de= ad:beef. (It must have an IPv6 address on its cell interface, or it can'= ;t reach the IPv6 Internet).

If a host behind the = phone autoconfigures the address 2001:db8::dead:beef, it will not be able t= o receive replies from the Internet. It can send packets from 2001:db8::dea= d:beef, and the phone will (probably) send them to the Internet, but when a= s someone on the Internet sends a packet to 2001:db8::dead:beef, the phone = will receive it through the cellular interface and terminate it - because t= hat address belongs to the phone.

So the host needs to be told "don't use 2001:d= b8::dead:beef, because it belongs to someone else on this link". DAD i= s the way to do that.
--14dae93a114557362c04d0c839e7-- From alexandru.petrescu@gmail.com Fri Dec 14 01:32:36 2012 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 E2B0A21F85C3 for ; Fri, 14 Dec 2012 01:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.749 X-Spam-Level: X-Spam-Status: No, score=-9.749 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ufScbA37Fg6 for ; Fri, 14 Dec 2012 01:32:35 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 55FBC21F8573 for ; Fri, 14 Dec 2012 01:32:35 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qBE9WV3x007928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Dec 2012 10:32:31 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qBE9WVMl015535; Fri, 14 Dec 2012 10:32:31 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qBE9WOkA027497; Fri, 14 Dec 2012 10:32:31 +0100 Message-ID: <50CAF229.60607@gmail.com> Date: Fri, 14 Dec 2012 10:32:25 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Cameron Byrne References: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> <50CA05F2.50001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 09:32:37 -0000 Hi Cameron, I agree with your point about CDC-Ethernet being specific to something else than 3GPP. But the behaviour of the 3GPP cellular link is very much different if I open it with CDC-Ethernet, than if I do it with ppp. This behaviour makes many statements in cellular-specific RFCs less relevant. Le 14/12/2012 00:26, Cameron Byrne a écrit : > Alex, > > > On Thu, Dec 13, 2012 at 8:44 AM, Alexandru Petrescu > wrote: >> Le 11/12/2012 22:03, Jouni Korhonen a écrit : >> >>> >>> On Dec 11, 2012, at 9:48 PM, Julien Laganier >>> wrote: >>> >>>>> I know that there's no DAD for addresses in the /64. >>>>> >>>>> My comment was about NUD... >>>> >>>> >>>> And no NUD either. >>>> >>>> When you say that PGW/GGSN don't do NUD, are you talking about >>>> a standard specification, or an implementation? >>>> >>>> --julien >>> >>> >>> Both. For the specification part, I admit, I felt a bit uneasy >>> with my statement ;) However, I do not see a reason why to do >>> so, since the /64 independent of the IID gets forwarded to the UE >>> in any case. >> >> >> IT some cases it doesn't. >> >> If the link is CDC-Ethernet (a form of 3GPP cellular long-range >> link, but relying on the use of IEEE-assigned MAC addresses) then >> not the entire /64 is forwarded to the UE. There is first a NS/NA >> for the address within that /64 (as we know with WiFi). If no >> answer NA then packets get dropped. >> >> Alex >> > > As far as i know, CDC-Ethernet has nothing to do with 3GPP networks > and does not change the network operations or behavior in any way of > the network. > > What i think you are describing is the USB LTE devices may present to > the host computer a CDC-Ethernet interface. Yes. > These USB devices do all manner of "interesting things" to make the > host computer inter-operate with the 3GPP network... YEs. Some of these interesting things, and different from ppp, are the following: Contrary to setting up a connection with pppd, setting it up with CDC-Ethernet (use e.g. 'qmi') will provoke that the Access Router sends NS on the interface. With pppd the AR never sends NS on the interface. Again, contrary to pppd, the link-local address of the UE is not enforced by the AR, but enforced by the UE. Still contrary to pppd, the Interface ID is not enforced by AR, but formed by the UE. The Interface ID is formed from a central registry guaranteeing uniqueness (as opposed to pppd generating apparently random unique ids). That registry is oui.txt at IEEE. The Interface ID is formed from this oui.txt-based 'MAC' address according to a rule (AFAIK non-std). That rule is the following: use the first 3 bytes of the 'MAC' address, and use the last 3 bytes as 0. Then do the rest like in RFC2464. > for example, proving a MAC address or presenting a DHCPv6 server that > appears to be coming from the the WAN but in fact is just a function > of the local USB software that extracts things like DNS servers from > the 3GPP PCO to pass on to the host that would not otherwise be able > to parse this info. I could visualize this idea of an intermediate entity (the key) proving a MAC address, something like the LTE USB key originating some ND messaging, to make think something. But, the src address of the NS I see is the link-local address which I believe to belong to the Access Router in the infrastructure. Because that address is also the next-hop of the default route of UE. The MAC address in Source link-layer address of that NS is a MAC address which is not of that LTE USB key (the MAC address of the LTE USB key is from oui.txt and . About presenting a DHCPv6 server - not sure it's the case here, because we sent DHCPv6 Solicit and Informatio-Request on this interface and no answer. Maybe elsewhere it does. About extracting the DNS server from the 3GPP PCO - this is something not done locally. I don't know whether the network does not put that DNS in 3GPP PCO, or that we can't extract it here. (a pppd connection on same operator with same SIM card but with a non-CDC-Ethernet key won't deliver the DNS server address either). Yours, Alex >>> >>> - Jouni _______________________________________________ v6ops >>> >>> mailing list v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From alexandru.petrescu@gmail.com Fri Dec 14 01:41:23 2012 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 747A021F8707 for ; Fri, 14 Dec 2012 01:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.041 X-Spam-Level: X-Spam-Status: No, score=-10.041 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3IPxlm+UZwj for ; Fri, 14 Dec 2012 01:41:22 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 533B321F86B7 for ; Fri, 14 Dec 2012 01:41:22 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qBE9fK01011632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Dec 2012 10:41:20 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qBE9fK4e020315; Fri, 14 Dec 2012 10:41:20 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qBE9fFfC026587; Fri, 14 Dec 2012 10:41:19 +0100 Message-ID: <50CAF43C.7090305@gmail.com> Date: Fri, 14 Dec 2012 10:41:16 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <001b01cd9eb7$2d05c8d0$87115a70$@tndh.net> <50CA01BF.4010203@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 09:41:23 -0000 Le 14/12/2012 05:11, Lorenzo Colitti a écrit : > On Fri, Dec 14, 2012 at 1:26 AM, Alexandru Petrescu > > > wrote: > > The requirement that UE defends that address is only required only > when the cellular link is not point-to-point (i.e. it is > Ethernet-compatible, like CDC-Ethernet, and does ND). > > In other more mundance cases like ptp links with ppp software the > AccessRouter on that ptp link will never send NS (it's a 'no ARP' > interface) and have a connected route and just deliver. And on > these ptp links the 64share trick of re-advertising the received /64 > works without proxy ND. > > > No, it won't work. Suppose I turn on /64 sharing on my phone, and > the phone: > > 1. Is connected to the IPv6 Internet through its cell interface > (which is a point-to-point link). 2. Is sharing 2001:db8::/64 3. Has > IPv6 address 2001:db8::dead:beef. (It must have an IPv6 address on > its cell interface, or it can't reach the IPv6 Internet). > > If a host behind the phone autoconfigures the address > 2001:db8::dead:beef, it will not be able to receive replies from the > Internet. It can send packets from 2001:db8::dead:beef, and the phone > will (probably) send them to the Internet, but when as someone on the > Internet sends a packet to 2001:db8::dead:beef, the phone will > receive it through the cellular interface and terminate it - because > that address belongs to the phone. Yes, and there are several ways to avoid that. One of them is to substitute 2001:db80::1 for 2001:db80::dead:beef on the cell iface of UE. A laptop on a LAN would rarely if ever self-configure an address ending with ::1. This was suggested by somebody else. > So the host needs to be told "don't use 2001:db8::dead:beef, because > it belongs to someone else on this link". DAD is the way to do that. Yes, this way of dealing with the above problem is to trigger DAD on the LAN iface of UE by assigning it same 2001:db80::dead:beef as assigned on the cell iface of UE. Alex From swmike@swm.pp.se Fri Dec 14 01:55:00 2012 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 84E7021F86F6 for ; Fri, 14 Dec 2012 01:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAu8o+DaS+xB for ; Fri, 14 Dec 2012 01:55:00 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id EDF3C21F86AA for ; Fri, 14 Dec 2012 01:54:59 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 763A09C; Fri, 14 Dec 2012 10:54:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 71A159A; Fri, 14 Dec 2012 10:54:57 +0100 (CET) Date: Fri, 14 Dec 2012 10:54:57 +0100 (CET) From: Mikael Abrahamsson To: Julien Laganier In-Reply-To: Message-ID: References: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 09:55:00 -0000 On Thu, 13 Dec 2012, Julien Laganier wrote: > I am not aware of a specification that says PGW/GGSN do not do NUD. A > reason to do so would be full compliance to RFC 4861 such that the > PGW/GGSN verify that the neighbors (i.e., the UE) it is sending packets > to are indeed reachable and not sent in a black hole. This is > independent from the forwarding / routing decision and/or address > resolution. Would you expect a router to do NUD if it has the following configuration: ipv6 route 2001:DB8::/64 serial1/0 As far as I can discern, this is what the SPGW does, it creates a /64 route towards it's GTP interface, and since there is no NS being done, there can't be any NUD, right? -- Mikael Abrahamsson email: swmike@swm.pp.se From cb.list6@gmail.com Fri Dec 14 04:03:32 2012 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 6C50021F845B for ; Fri, 14 Dec 2012 04:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.196 X-Spam-Level: X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djGHh3+tJjc7 for ; Fri, 14 Dec 2012 04:03:31 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8EF621F845A for ; Fri, 14 Dec 2012 04:03:30 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2696691lbk.31 for ; Fri, 14 Dec 2012 04:03:29 -0800 (PST) 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:content-type; bh=WgtxozFPwYLcIgNvVl0N8Awc/WbZP9X4XWurEf+iN2Q=; b=aIQz6T0CgafWr8D3zBlgajo0yrEzbHVDXPC2fi1Fwy6lElLUSKOyBETAEMEO+NtLTI LX7kn21OEZ4fKZoC2R1bivRUB9HxbOz7Vuk2bjKvvKNvfLS3KgrvtZlGtQaCQnWb34Jj QFEkeXDgMW6cMq6P7yiRZE6jz3bEZFNhbyZL2xxkhguBcnnTSuAnXiswqPpmI/Kmc631 0d9FnmbFDhJm/Gc2gsL71gdI+ch2D9Uh42BCxoLxrewv/Gp/ndy/t0Tp1h4mAJ55Ctqb ZM7WmHNSJeI0/42EAx6aKAvG9V6jsyNIHZld2NApmTwPLgfyPDO6vwR3Sh3wpoNHG9Q7 heJA== MIME-Version: 1.0 Received: by 10.152.124.15 with SMTP id me15mr2462882lab.5.1355486609855; Fri, 14 Dec 2012 04:03:29 -0800 (PST) Received: by 10.112.44.36 with HTTP; Fri, 14 Dec 2012 04:03:29 -0800 (PST) Received: by 10.112.44.36 with HTTP; Fri, 14 Dec 2012 04:03:29 -0800 (PST) In-Reply-To: <50CAF229.60607@gmail.com> References: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> <50CA05F2.50001@gmail.com> <50CAF229.60607@gmail.com> Date: Fri, 14 Dec 2012 04:03:29 -0800 Message-ID: From: Cameron Byrne To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=f46d04374581e0d4e404d0ced19c Cc: v6ops@ietf.org Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 12:03:32 -0000 --f46d04374581e0d4e404d0ced19c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sent from ipv6-only Android On Dec 14, 2012 1:32 AM, "Alexandru Petrescu" wrote: > > Hi Cameron, > > I agree with your point about CDC-Ethernet being specific to something > else than 3GPP. > > But the behaviour of the 3GPP cellular link is very much different if I > open it with CDC-Ethernet, than if I do it with ppp. > > This behaviour makes many statements in cellular-specific RFCs less > relevant. > > Le 14/12/2012 00:26, Cameron Byrne a =E9crit : > >> Alex, >> >> >> On Thu, Dec 13, 2012 at 8:44 AM, Alexandru Petrescu >> wrote: >>> >>> Le 11/12/2012 22:03, Jouni Korhonen a =E9crit : >>> >>>> >>>> On Dec 11, 2012, at 9:48 PM, Julien Laganier >>>> wrote: >>>> >>>>>> I know that there's no DAD for addresses in the /64. >>>>>> >>>>>> My comment was about NUD... >>>>> >>>>> >>>>> >>>>> And no NUD either. >>>>> >>>>> When you say that PGW/GGSN don't do NUD, are you talking about >>>>> a standard specification, or an implementation? >>>>> >>>>> --julien >>>> >>>> >>>> >>>> Both. For the specification part, I admit, I felt a bit uneasy >>>> with my statement ;) However, I do not see a reason why to do >>>> so, since the /64 independent of the IID gets forwarded to the UE >>>> in any case. >>> >>> >>> >>> IT some cases it doesn't. >>> >>> If the link is CDC-Ethernet (a form of 3GPP cellular long-range >>> link, but relying on the use of IEEE-assigned MAC addresses) then >>> not the entire /64 is forwarded to the UE. There is first a NS/NA >>> for the address within that /64 (as we know with WiFi). If no >>> answer NA then packets get dropped. >>> >>> Alex >>> >> >> As far as i know, CDC-Ethernet has nothing to do with 3GPP networks >> and does not change the network operations or behavior in any way of >> the network. >> >> What i think you are describing is the USB LTE devices may present to >> the host computer a CDC-Ethernet interface. > > > Yes. > > >> These USB devices do all manner of "interesting things" to make the >> host computer inter-operate with the 3GPP network... > > > YEs. Some of these interesting things, and different from ppp, are the > following: > > Contrary to setting up a connection with pppd, setting it up with > CDC-Ethernet (use e.g. 'qmi') will provoke that the Access Router sends > NS on the interface. With pppd the AR never sends NS on the interface. > > Again, contrary to pppd, the link-local address of the UE is not > enforced by the AR, but enforced by the UE. > > Still contrary to pppd, the Interface ID is not enforced by AR, but > formed by the UE. > > The Interface ID is formed from a central registry guaranteeing > uniqueness (as opposed to pppd generating apparently random unique ids). > That registry is oui.txt at IEEE. > > The Interface ID is formed from this oui.txt-based 'MAC' address > according to a rule (AFAIK non-std). That rule is the following: use > the first 3 bytes of the 'MAC' address, and use the last 3 bytes as 0. > Then do the rest like in RFC2464. > > >> for example, proving a MAC address or presenting a DHCPv6 server that >> appears to be coming from the the WAN but in fact is just a function >> of the local USB software that extracts things like DNS servers from >> the 3GPP PCO to pass on to the host that would not otherwise be able >> to parse this info. > > > I could visualize this idea of an intermediate entity (the key) proving > a MAC address, something like the LTE USB key originating some ND > messaging, to make think something. > > But, the src address of the NS I see is the link-local address which I > believe to belong to the Access Router in the infrastructure. Because > that address is also the next-hop of the default route of UE. The MAC > address in Source link-layer address of that NS is a MAC address which > is not of that LTE USB key (the MAC address of the LTE USB key is from > oui.txt and . > Do you have conclusive data that the ns is coming from the ggsn and not a synthetic creation of thr key? This data sounds circumstantial. In any event cdc ethernet and ppp are relationships between the usb key and the host. They are not relationships between the host and the network or the key and the network. This relationship is unnatural and causes a lot of issues. I agree with your point that the UE defined in my 3gpp64share draft should explicitly expect a p2p interface. CB > About presenting a DHCPv6 server - not sure it's the case here, because > we sent DHCPv6 Solicit and Informatio-Request on this interface and no > answer. Maybe elsewhere it does. > > About extracting the DNS server from the 3GPP PCO - this is something > not done locally. I don't know whether the network does not put that > DNS in 3GPP PCO, or that we can't extract it here. (a pppd connection on > same operator with same SIM card but with a non-CDC-Ethernet key won't > deliver the DNS server address either). > > Yours, > > Alex > > >>>> >>>> - Jouni _______________________________________________ v6ops >>>> >>>> mailing list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> >>> >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> >> > > --f46d04374581e0d4e404d0ced19c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Dec 14, 2012 1:32 AM, "Alexandru Petrescu" <alexandru.petrescu@gmail.com> wrote= :
>
> Hi Cameron,
>
> I agree with your point about CDC-Ethernet being specific to something=
> else than 3GPP.
>
> But the behaviour of the 3GPP cellular link is very much different if = I
> open it with CDC-Ethernet, than if I do it with ppp.
>
> This behaviour makes many statements in cellular-specific RFCs less > relevant.
>
> Le 14/12/2012 00:26, Cameron Byrne a =E9crit :
>
>> Alex,
>>
>>
>> On Thu, Dec 13, 2012 at 8:44 AM, Alexandru Petrescu
>> <alexandru.petr= escu@gmail.com> wrote:
>>>
>>> Le 11/12/2012 22:03, Jouni Korhonen a =E9crit :
>>>
>>>>
>>>> On Dec 11, 2012, at 9:48 PM, Julien Laganier
>>>> <julien.ietf@g= mail.com> wrote:
>>>>
>>>>>> I know that there's no DAD for addresses in th= e /64.
>>>>>>
>>>>>> My comment was about NUD...
>>>>>
>>>>>
>>>>>
>>>>> And no NUD either.
>>>>>
>>>>> When you say that PGW/GGSN don't do NUD, are you t= alking about
>>>>> a standard specification, or an implementation?
>>>>>
>>>>> --julien
>>>>
>>>>
>>>>
>>>> Both. For the specification part, I admit, I felt a bit un= easy
>>>> with my statement ;) However, I do not see a reason why to= do
>>>> so, since the /64 independent of the IID gets forwarded to= the UE
>>>> in any case.
>>>
>>>
>>>
>>> IT some cases it doesn't.
>>>
>>> If the link is CDC-Ethernet (a form of 3GPP cellular long-rang= e
>>> link, but relying on the use of IEEE-assigned MAC addresses) t= hen
>>> not the entire /64 is forwarded to the UE. =A0There is first a= NS/NA
>>> for the address within that /64 (as we know with WiFi). =A0If = no
>>> answer NA then packets get dropped.
>>>
>>> Alex
>>>
>>
>> As far as i know, CDC-Ethernet has nothing to do with 3GPP network= s
>> and does not change the network operations or behavior in any way = of
>> =A0the network.
>>
>> What i think you are describing is the USB LTE devices may present= to
>> the host computer a CDC-Ethernet interface.
>
>
> Yes.
>
>
>> These USB devices do all manner of "interesting things" = to make the
>> host computer inter-operate with the 3GPP network...
>
>
> YEs. =A0Some of these interesting things, and different from ppp, are = the
> following:
>
> Contrary to setting up a connection with pppd, setting it up with
> CDC-Ethernet (use e.g. 'qmi') will provoke that the Access Rou= ter sends
> NS on the interface. =A0With pppd the AR never sends NS on the interfa= ce.
>
> Again, contrary to pppd, the link-local address of the UE is not
> enforced by the AR, but enforced by the UE.
>
> Still contrary to pppd, the Interface ID is not enforced by AR, but > formed by the UE.
>
> The Interface ID is formed from a central registry guaranteeing
> uniqueness (as opposed to pppd generating apparently random unique ids= ).
> =A0That registry is oui.txt at IEEE.
>
> The Interface ID is formed from this oui.txt-based 'MAC' addre= ss
> according to a rule (AFAIK non-std). =A0That rule is the following: us= e
> the first 3 bytes of the 'MAC' address, and use the last 3 byt= es as 0.
> Then do the rest like in RFC2464.
>
>
>> for example, proving a MAC address or presenting a DHCPv6 server t= hat
>> appears to be coming from the the WAN but in fact is just a functi= on
>> of the local USB software that extracts things like DNS servers fr= om
>> the 3GPP PCO to pass on to the host that would not otherwise be ab= le
>> to parse this info.
>
>
> I could visualize this idea of an intermediate entity (the key) provin= g
> a MAC address, something like the LTE USB key originating some ND
> messaging, to make think something.
>
> But, the src address of the NS I see is the link-local address which I=
> believe to belong to the Access Router in the infrastructure. =A0Becau= se
> that address is also the next-hop of the default route of UE. =A0The M= AC
> address in Source link-layer address of that NS is a MAC address which=
> is not of that LTE USB key (the MAC address of the LTE USB key is from=
> oui.txt and .
>

Do you have conclusive data that the ns is coming from the g= gsn and not a synthetic creation of thr key?

This data sounds circumstantial.

In any event cdc ethernet and ppp are relationships between = the usb key and the host. They are not relationships between the host and t= he network or the key and the network. This relationship is unnatural and c= auses a lot of issues. I agree with your point that the UE defined in my 3g= pp64share draft should explicitly expect a p2p interface.

CB

> About presenting a DHCPv6 server - not sure it's th= e case here, because
> we sent DHCPv6 Solicit and Informatio-Request on this interface and no=
> answer. =A0Maybe =A0elsewhere it does.
>
> About extracting the DNS server from the 3GPP PCO - this is something<= br> > not done locally. =A0I don't know whether the network does not put= that
> DNS in 3GPP PCO, or that we can't extract it here. (a pppd connect= ion on
> same operator with same SIM card but with a non-CDC-Ethernet key won&#= 39;t
> deliver the DNS server address either).
>
> Yours,
>
> Alex
>
>
>>>>
>>>> - Jouni _______________________________________________ v6= ops
>>>>
>>>> mailing list v6ops@ietf.= org
>>>> ht= tps://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>>
>>>
>>>
>>> _______________________________________________ v6ops mailing = list
>>> =A0v6ops@ietf.org https://www.ietf.org/mail= man/listinfo/v6ops
>>
>>
>>
>
>

--f46d04374581e0d4e404d0ced19c-- From alexandru.petrescu@gmail.com Fri Dec 14 05:07:58 2012 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 E61E421F8703 for ; Fri, 14 Dec 2012 05:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.756 X-Spam-Level: X-Spam-Status: No, score=-9.756 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tzADVXgZF1d for ; Fri, 14 Dec 2012 05:07:58 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 95EDF21F86E8 for ; Fri, 14 Dec 2012 05:07:57 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qBED7tLI018423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Dec 2012 14:07:55 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qBED7sw8002681; Fri, 14 Dec 2012 14:07:55 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qBED7kYW012184; Fri, 14 Dec 2012 14:07:54 +0100 Message-ID: <50CB24A2.1030904@gmail.com> Date: Fri, 14 Dec 2012 14:07:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Cameron Byrne References: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> <50CA05F2.50001@gmail.com> <50CAF229.60607@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 13:07:59 -0000 Le 14/12/2012 13:03, Cameron Byrne a écrit : > Sent from ipv6-only Android On Dec 14, 2012 1:32 AM, "Alexandru > Petrescu" > wrote: >> >> Hi Cameron, >> >> I agree with your point about CDC-Ethernet being specific to >> something else than 3GPP. >> >> But the behaviour of the 3GPP cellular link is very much different >> if I open it with CDC-Ethernet, than if I do it with ppp. >> >> This behaviour makes many statements in cellular-specific RFCs >> less relevant. >> >> Le 14/12/2012 00:26, Cameron Byrne a écrit : >> >>> Alex, >>> >>> >>> On Thu, Dec 13, 2012 at 8:44 AM, Alexandru Petrescu >>> >> > > wrote: >>>> >>>> Le 11/12/2012 22:03, Jouni Korhonen a écrit : >>>> >>>>> >>>>> On Dec 11, 2012, at 9:48 PM, Julien Laganier >>>>> > >>>>> wrote: >>>>> >>>>>>> I know that there's no DAD for addresses in the /64. >>>>>>> >>>>>>> My comment was about NUD... >>>>>> >>>>>> >>>>>> >>>>>> And no NUD either. >>>>>> >>>>>> When you say that PGW/GGSN don't do NUD, are you talking >>>>>> about a standard specification, or an implementation? >>>>>> >>>>>> --julien >>>>> >>>>> >>>>> >>>>> Both. For the specification part, I admit, I felt a bit >>>>> uneasy with my statement ;) However, I do not see a reason >>>>> why to do so, since the /64 independent of the IID gets >>>>> forwarded to the UE in any case. >>>> >>>> >>>> >>>> IT some cases it doesn't. >>>> >>>> If the link is CDC-Ethernet (a form of 3GPP cellular >>>> long-range link, but relying on the use of IEEE-assigned MAC >>>> addresses) then not the entire /64 is forwarded to the UE. >>>> There is first a NS/NA for the address within that /64 (as we >>>> know with WiFi). If no answer NA then packets get dropped. >>>> >>>> Alex >>>> >>> >>> As far as i know, CDC-Ethernet has nothing to do with 3GPP >>> networks and does not change the network operations or behavior >>> in any way of the network. >>> >>> What i think you are describing is the USB LTE devices may >>> present to the host computer a CDC-Ethernet interface. >> >> >> Yes. >> >> >>> These USB devices do all manner of "interesting things" to make >>> the host computer inter-operate with the 3GPP network... >> >> >> YEs. Some of these interesting things, and different from ppp, are >> the following: >> >> Contrary to setting up a connection with pppd, setting it up with >> CDC-Ethernet (use e.g. 'qmi') will provoke that the Access Router >> sends NS on the interface. With pppd the AR never sends NS on the >> interface. >> >> Again, contrary to pppd, the link-local address of the UE is not >> enforced by the AR, but enforced by the UE. >> >> Still contrary to pppd, the Interface ID is not enforced by AR, >> but formed by the UE. >> >> The Interface ID is formed from a central registry guaranteeing >> uniqueness (as opposed to pppd generating apparently random unique >> ids). That registry is oui.txt at IEEE. >> >> The Interface ID is formed from this oui.txt-based 'MAC' address >> according to a rule (AFAIK non-std). That rule is the following: >> use the first 3 bytes of the 'MAC' address, and use the last 3 >> bytes as 0. Then do the rest like in RFC2464. >> >> >>> for example, proving a MAC address or presenting a DHCPv6 server >>> that appears to be coming from the the WAN but in fact is just a >>> function of the local USB software that extracts things like DNS >>> servers from the 3GPP PCO to pass on to the host that would not >>> otherwise be able to parse this info. >> >> >> I could visualize this idea of an intermediate entity (the key) >> proving a MAC address, something like the LTE USB key originating >> some ND messaging, to make think something. >> >> But, the src address of the NS I see is the link-local address >> which I believe to belong to the Access Router in the >> infrastructure. Because that address is also the next-hop of the >> default route of UE. The MAC address in Source link-layer address >> of that NS is a MAC address which is not of that LTE USB key (the >> MAC address of the LTE USB key is from oui.txt and . >> > > Do you have conclusive data that the ns is coming from the ggsn and > not a synthetic creation of thr key? YEs, I tend to think so. The reasons are: - the NS is sent when the connection is put up. - the NS also shows up right after the UE sends a echo request. The target address in NS is equal to the src of the echo request. - the MAC address in the Source link-layer is not that of the key. - the src address is a link-local address which is not of the key. - the src address is the same as the default route of the UE. There are also RAs and they seem originated by the GGSN, not by the key, right? Anyways, whatever 'hiding' and 'performing on behalf of' and 'proxy' this key does, and whoever this NS sends (be it the GGSN or the key), if I don't reply to the NS then the data packet is not delivered to me. This means that I must run a form of proxy ND for 64share to work on CDC-Ethernet cellular links. > This data sounds circumstantial. Well, yes circumstantial to some but norm to me. > In any event cdc ethernet and ppp are relationships between the usb > key and the host. They are not relationships between the host and the > network or the key and the network. This relationship is unnatural > and causes a lot of issues. I agree with your point that the UE > defined in my 3gpp64share draft should explicitly expect a p2p > interface. YEs, I agree. The ptp interface could be described. There are pure ptp interfaces which dont run ND and whose addresses are dictated by the network, and there are ptp interfaces whose addresses are IEEE MAC and which run ND. Alex > > CB > >> About presenting a DHCPv6 server - not sure it's the case here, >> because we sent DHCPv6 Solicit and Informatio-Request on this >> interface and no answer. Maybe elsewhere it does. >> >> About extracting the DNS server from the 3GPP PCO - this is >> something not done locally. I don't know whether the network does >> not put that DNS in 3GPP PCO, or that we can't extract it here. (a >> pppd connection on same operator with same SIM card but with a >> non-CDC-Ethernet key won't deliver the DNS server address either). >> >> Yours, >> >> Alex >> >> >>>>> >>>>> - Jouni _______________________________________________ >>>>> v6ops >>>>> >>>>> mailing list v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >>> >> >> > From jounikor@gmail.com Fri Dec 14 05:39:29 2012 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 1E40F21F8562 for ; Fri, 14 Dec 2012 05:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PNi8khiWLBs for ; Fri, 14 Dec 2012 05:39:28 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 571D521F8542 for ; Fri, 14 Dec 2012 05:39:28 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2763928lah.31 for ; Fri, 14 Dec 2012 05:39:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3EnUncVH9L0yq9vxEy31mzkmQHx2e36qFx8ONoqSWJU=; b=KFcPthJIwKDrDGoHzQCb3o+GXTJtHzUYX1iCd/DFr0vhjDlMBHGbvMoUmFKYheWMri rI8qI+JfzJGNDHwS2SNuF6gHq2GTlUi7mNBSVVURb/4FpmYyNrIIcU8IY3DccfWS4QN9 ZBI0iEWg+oUARrBYjcp27jhLEKtj1r4F0+w3vFdJzy6ZjIN0GawsV9+hgq9HV/12xrcJ 6U0pfQvbqy4g7PJfsnF9ecl6yWuiRvpQPeE2gKklzMY9p5DwJXX0XRRitndjhMvyIVnU UQBqSMdz6xyyfjwWnrOCtOGSMMji/LKL/mvM9ZEU2HsDUrDE0bNG3NgoLTUjPsESzZUV YF+w== Received: by 10.152.125.237 with SMTP id mt13mr2661046lab.45.1355492367398; Fri, 14 Dec 2012 05:39:27 -0800 (PST) Received: from [192.168.250.121] ([194.100.71.98]) by mx.google.com with ESMTPS id pm16sm1853275lab.8.2012.12.14.05.39.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 05:39:26 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: <50CAF229.60607@gmail.com> Date: Fri, 14 Dec 2012 15:39:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> <50CA05F2.50001@gmail.com> <50CAF229.60607@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 13:39:29 -0000 On Dec 14, 2012, at 11:32 AM, Alexandru Petrescu = wrote: > Hi Cameron, >=20 > I agree with your point about CDC-Ethernet being specific to something > else than 3GPP. >=20 > But the behaviour of the 3GPP cellular link is very much different if = I > open it with CDC-Ethernet, than if I do it with ppp. >=20 > This behaviour makes many statements in cellular-specific RFCs less > relevant. Say.. if the driver and the UE misbehaves which one is to correct? The driver & the UE or the network (and its specifications)? - Jouni= From alexandru.petrescu@gmail.com Fri Dec 14 05:58:00 2012 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 02AD221F85C7 for ; Fri, 14 Dec 2012 05:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQuugOdLIGJ6 for ; Fri, 14 Dec 2012 05:57:59 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id C1F2E21F85BF for ; Fri, 14 Dec 2012 05:57:52 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qBEDvotV011834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Dec 2012 14:57:50 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qBEDvnvj024539; Fri, 14 Dec 2012 14:57:50 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qBEDvjPQ011529; Fri, 14 Dec 2012 14:57:49 +0100 Message-ID: <50CB3059.9050002@gmail.com> Date: Fri, 14 Dec 2012 14:57:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jouni Korhonen References: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> <50CA05F2.50001@gmail.com> <50CAF229.60607@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 13:58:00 -0000 Le 14/12/2012 14:39, Jouni Korhonen a écrit : > > On Dec 14, 2012, at 11:32 AM, Alexandru Petrescu > wrote: > >> Hi Cameron, >> >> I agree with your point about CDC-Ethernet being specific to >> something else than 3GPP. >> >> But the behaviour of the 3GPP cellular link is very much different >> if I open it with CDC-Ethernet, than if I do it with ppp. >> >> This behaviour makes many statements in cellular-specific RFCs >> less relevant. > > Say.. if the driver and the UE misbehaves which one is to correct? > The driver & the UE or the network (and its specifications)? That sounds wise and although I have a preference I wouldn't put it bluntly. Should 64share ack the existence of cellular ptp links with IEEE MAC addresses and ND (instead of network-dictated UE IID and noARP)? Are they the future of cellular links? Or are they misbehaving? Alex > > - Jouni > From julien.ietf@gmail.com Fri Dec 14 11:30:35 2012 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 E824321F8B49 for ; Fri, 14 Dec 2012 11:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WODtPnb+59rK for ; Fri, 14 Dec 2012 11:30:35 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDD121F8B44 for ; Fri, 14 Dec 2012 11:30:35 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so2217699eek.31 for ; Fri, 14 Dec 2012 11:30:34 -0800 (PST) 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:content-type:content-transfer-encoding; bh=NWjCK2ae/Z4KtKB/p80vLCO36+V9Iega4peky0fyhVY=; b=0uzYPadX3bTexc4lEwzp4AFwdKU/EjX4befiSDWrGt1SZmnilwc1fGnHyLQysDD0wO WtSvx23dBNfe1rxYlNlzbVRvLOsBOkDWcmlvDtng86rpP+dhB5TsG5g6IrOLfNGRJaXf YXphqGjDqsx9fSkFK3ho4iuKQS6EQ3+RQ/ruomCKG+1tbnJpglVjoVXOa++stCASTgl9 U7YtFMufXEVtArY2v6H/WSDOuVEROBcVSlmxPmMhoHcbTt2NRE65Am09wBYZFqSGo70D HUPgN7qDFy8JuF63qCG3Q1fA9/TaCOTr4MSJtPMGJtz4duAQSnHEz/QMzv8MgWYB28hV GVQA== MIME-Version: 1.0 Received: by 10.14.0.133 with SMTP id 5mr17217597eeb.29.1355513434346; Fri, 14 Dec 2012 11:30:34 -0800 (PST) Received: by 10.223.65.68 with HTTP; Fri, 14 Dec 2012 11:30:34 -0800 (PST) In-Reply-To: References: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> Date: Fri, 14 Dec 2012 11:30:34 -0800 Message-ID: From: Julien Laganier To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 19:30:36 -0000 On Fri, Dec 14, 2012 at 1:54 AM, Mikael Abrahamsson wrot= e: > > On Thu, 13 Dec 2012, Julien Laganier wrote: > >> I am not aware of a specification that says PGW/GGSN do not do NUD. A re= ason to do so would be full compliance to RFC 4861 such that the PGW/GGSN v= erify that the neighbors (i.e., the UE) it is sending packets to are indeed= reachable and not sent in a black hole. This is independent from the forwa= rding / routing decision and/or address resolution. > > > Would you expect a router to do NUD if it has the following configuration= : > > ipv6 route 2001:DB8::/64 serial1/0 > > As far as I can discern, this is what the SPGW does, it creates a /64 rou= te towards it's GTP interface, and since there is no NS being done, there c= an't be any NUD, right? I am not sure how material my expectations are to this discussion. Reading our specifications (RFC 4861 for that matter), the fact that the PGW/GGSN doesn't need to send NS for address resolution on the GTP interface doesn't seem to dispense it from performing NUD: Neighbor Unreachability Detection is used for all paths between hosts and neighboring nodes, including host-to-host, host-to-router, and router-to-host communication. Neighbor Unreachability Detection may also be used between routers, but is not required if an equivalent mechanism is available, for example, as part of the routing protocols. Now I am not saying the PGW/GGSN should do NUD (this is a different discussion); what I am saying is that given the mechanism proposed in the draft relies on the PGW/GGSN not doing NUD, the draft should mention that. --julien From xing@cernet.edu.cn Fri Dec 14 16:21:25 2012 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 0B2EA21F8A94; Fri, 14 Dec 2012 16:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3BWX762xW1S; Fri, 14 Dec 2012 16:21:24 -0800 (PST) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 97AAC21F8A91; Fri, 14 Dec 2012 16:21:23 -0800 (PST) Received: from [127.0.0.1] (unknown [210.138.34.107]) by centos (Coremail) with SMTP id AQAAf3A7VwavwMtQpj8RAA--.54956S5; Sat, 15 Dec 2012 08:13:37 +0800 (CST) Message-ID: <50CBB3C5.40502@cernet.edu.cn> Date: Sat, 15 Dec 2012 07:18:29 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Tore Anderson References: <509CB678.9090402@redpill-linpro.com> In-Reply-To: <509CB678.9090402@redpill-linpro.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3A7VwavwMtQpj8RAA--.54956S5 X-Coremail-Antispam: 1UD129KBjvJXoW7Cr47Xw45GFyxurykurWxZwb_yoW8WFWrpa 45Wr4ag3sxXw18Gwn5Zwn5ur1Yva9aga98XFnrtr43Ca9xGas7tr1xKFWagryDWr1DWr4D Xayjy3y5Xw40vFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUqG14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUXVWUAwA2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14 v26r1j6r1xM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAF wI0_Gr0_Cr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4j6r4UJwAS0I0E0xvYzxvE52x082 IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUXVWUAwAv 7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4x0x7 Aq67IIx4CEVc8vx2IErcIFxwCY02Avz4vEOx0_twCF04k20xvY0x0EwIxGrwC20s026c02 F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw 1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r 1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x0JUq NtxUUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: "v6ops@ietf.org" , sunset4@ietf.org Subject: Re: [v6ops] draft-anderson-siit-dc-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 00:21:25 -0000 Hi, Tore and All, Thanks for your interesting draft. I also noticed that you presented this concept in RIPE64 https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf Due to the deployment of VMs in the DC, the depletion of the IPv4 address is a big issue and your draft presents a solution. I would like to see the discussion of your draft in v6ops. Regards, xing Tore Anderson 写é“: > Good morning, > > I've just uploaded a new draft: > > Filename: draft-anderson-siit-dc > Revision: 00 > Title: Stateless IP/ICMP Translation in IPv6 Data Centre Environments > Creation date: 2012-11-09 > WG ID: Individual Submission > Number of pages: 18 > URL: http://www.ietf.org/internet-drafts/draft-anderson-siit-dc-00.txt > Status: http://datatracker.ietf.org/doc/draft-anderson-siit-dc > Htmlized: http://tools.ietf.org/html/draft-anderson-siit-dc-00 > > Abstract: > This document describes the use of Stateless IP/ICMP Translation > (SIIT) in data centre environments in order to simultaneously > facilitate IPv6 deployment and IPv4 address conservation. It > describes the overall architecture, and provides guidelines for both > operators and implementers. > > It's my first ever draft, so go easy on me. Note that this draft may be > relevant to the discussion of draft-lopez-v6ops-dc-ipv6, as it documents > in more technical detail a way to implement the "Next Generation Stage" > briefly described in section 2.3. > > I do not know whether the discussion of this draft fits the best in > v6ops or sunset4, so this message is cross-posted to both WGs. > > Best regards, > From jounikor@gmail.com Sat Dec 15 04:23:23 2012 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 195FB21F84F0 for ; Sat, 15 Dec 2012 04:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+KV-uJ8W3ov for ; Sat, 15 Dec 2012 04:23:22 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04CB021F84EB for ; Sat, 15 Dec 2012 04:23:21 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1727257eaa.31 for ; Sat, 15 Dec 2012 04:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ab49uhkZBmuqqHnr/cRsZ+R3WoHvFQ/sqM4LtSvv20o=; b=qGeIk3P2gijHID/sHhXzzgGKY83iZ0kRWtZEc7QR8acvE/Ewf6kZiwZc7aAWUEGLR1 oji99cfjBxNebjWT1+PkipilLoPpvVtbHTX2bOKXX5Xdt8GzzgQU3nPSfcVEqXzeUFz4 qb4DtARGe40shxUUFHUDGdCVP1gBxCHpbSsqj2C9xzvy6SglQezdCf+eyH7fN96zjZIZ nD4SAnPpGke/XSvfmHlQXkzuLBbVN+ThZqMjh+rMuANIYxGKl0o9ihi5oFrC8w+fm5bq isekoP0LnglnPn1CittaD/JKPhkWh8jXorj3CmnQwYTiwNmtsBB/WSCvrGEeI/qkHsTn my7w== Received: by 10.14.221.5 with SMTP id q5mr23487761eep.33.1355574201095; Sat, 15 Dec 2012 04:23:21 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id f49sm15593338eep.12.2012.12.15.04.23.19 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Dec 2012 04:23:20 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: <50CB3059.9050002@gmail.com> Date: Sat, 15 Dec 2012 14:23:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> <50CA05F2.50001@gmail.com> <50CAF229.60607@gmail.com> <50CB3059.9050002@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org, Jouni Korhonen Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 12:23:23 -0000 On Dec 14, 2012, at 3:57 PM, Alexandru Petrescu = wrote: > Le 14/12/2012 14:39, Jouni Korhonen a =E9crit : >>=20 >> On Dec 14, 2012, at 11:32 AM, Alexandru Petrescu >> wrote: >>=20 >>> Hi Cameron, >>>=20 >>> I agree with your point about CDC-Ethernet being specific to >>> something else than 3GPP. >>>=20 >>> But the behaviour of the 3GPP cellular link is very much different >>> if I open it with CDC-Ethernet, than if I do it with ppp. >>>=20 >>> This behaviour makes many statements in cellular-specific RFCs >>> less relevant. >>=20 >> Say.. if the driver and the UE misbehaves which one is to correct? >> The driver & the UE or the network (and its specifications)? >=20 > That sounds wise and although I have a preference I wouldn't put it = bluntly. >=20 > Should 64share ack the existence of cellular ptp links with IEEE MAC > addresses and ND (instead of network-dictated UE IID and noARP)? Are > they the future of cellular links? Or are they misbehaving? Generally about this "topic". The 3GPP link has no link-layer addresses. If the driver/UE goes and tries to do e.g. address resolution, something is definitely wrong on the UE side. Some USB drivers and GGSNs try to = fix the situation and synthesise SLLAs and TLLAs into NDP messages.. just to keep misbehaving UEs happy. It is a hack and the sustainable approach would be fixing the UEs. - JOuni >=20 > Alex >=20 >=20 >>=20 >> - Jouni >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jounikor@gmail.com Sun Dec 16 12:08:59 2012 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 73F7C21F89A1 for ; Sun, 16 Dec 2012 12:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT30tq2hlJhk for ; Sun, 16 Dec 2012 12:08:58 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3183F21F899D for ; Sun, 16 Dec 2012 12:08:58 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so2113729eaa.31 for ; Sun, 16 Dec 2012 12:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=mQYGMxEWQQxIR0jypFjRF2eogHEUkNBrQYx3AO6d2jE=; b=LCRJO20A4YCsknpQkAQfz1ajbepcCDUsddSv5gXXSqwQPaECMnOywiNGYkAwQh0Guw 0vWrSa1gX7qmoyyCpsoksw/jO/RCJWCOGM+U07eNw19bPWra5C9J/1YF8iEeo7S3stbh LYxYtYS01U8WWFQuhBP1t6A5lfCIl8spCCyXgp3L7OxBJp3OglC4/wePh34ZLhfESp6q 9U1fCQEhUE5K3FAujrsFG9Wib/1Bs5EDoKGJtZRO9q1fspnlT3Mla1U6L9Ly1NesEKAD d+vDa7gF4Q7vzXqc5cGmOe5eAOIbDvbD7PYMmognknxz+EIDTTle0kI/qeea/+0EmdxY YmTw== Received: by 10.14.0.71 with SMTP id 47mr34281916eea.19.1355688537344; Sun, 16 Dec 2012 12:08:57 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id l3sm24558473eem.14.2012.12.16.12.08.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Dec 2012 12:08:54 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: Date: Sun, 16 Dec 2012 22:09:00 +0200 Content-Transfer-Encoding: 7bit Message-Id: <0311FD87-4F2F-410E-8587-A8C1A7E62F17@gmail.com> References: <35C2D3FC-17C2-48FD-8B50-7E0B6F716151@gmail.com> <50CA05F2.50001@gmail.com> <50CAF229.60607@gmail.com> <50CB3059.9050002@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org Subject: Re: [v6ops] NUD and draft-byrne-v6ops-64share-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 20:08:59 -0000 On Dec 15, 2012, at 2:23 PM, Jouni Korhonen wrote: > > Generally about this "topic". The 3GPP link has no link-layer addresses. > If the driver/UE goes and tries to do e.g. address resolution, something > is definitely wrong on the UE side. Some USB drivers and GGSNs try to fix ^^^^^^^^^^^ Correcting myself.. modem firmwares. > the situation and synthesise SLLAs and TLLAs into NDP messages.. just to > keep misbehaving UEs happy. It is a hack and the sustainable approach > would be fixing the UEs. > > - JOuni > > >> >> Alex >> >> >>> >>> - Jouni >>> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From internet-drafts@ietf.org Mon Dec 17 08:27:15 2012 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 46A3821F8B37; Mon, 17 Dec 2012 08:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdb5F83FKJ+H; Mon, 17 Dec 2012 08:27:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C039921F8536; Mon, 17 Dec 2012 08:27:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121217162710.27852.36513.idtracker@ietfa.amsl.com> Date: Mon, 17 Dec 2012 08:27:10 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 16:27:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Sharing /64 3GPP Mobile Interface Subnet to a LAN Author(s) : Cameron Byrne Dan Drown Filename : draft-ietf-v6ops-64share-00.txt Pages : 6 Date : 2012-12-14 Abstract: This document describes a known and implemented method of sharing a /64 IPv6 prefix from a User Equipment 3GPP radio interface to a tethered LAN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-64share-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lorenzo@google.com Mon Dec 17 18:32:40 2012 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 C3A7021F86B8 for ; Mon, 17 Dec 2012 18:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnwpeXqkaD6R for ; Mon, 17 Dec 2012 18:32:40 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2C90621F86E3 for ; Mon, 17 Dec 2012 18:32:39 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id qd14so129151ieb.20 for ; Mon, 17 Dec 2012 18:32:39 -0800 (PST) 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:content-type; bh=1/uI51+POp/nDPZ+WNw2Bhx/DxabSTuzZzWNejfsqUc=; b=Y6ba7blHpshtTanSeMvAAvz3A180uSlEw3su9znR7Cs91pkr+e4Bkcj7jVAfYh55nK MplWQ2GvId0N1D0LTp4p5vE1kmDO7QckyvoIA/NiTUB32/rwCA/c+AkNoA8U0TnVZ+Oo TnHRiBka2MIoP2Nf+TPcUGE3a87LFn5t2IDfao7IMRraAMU9b5Z90rAzGTP02pAOMvqq QAN2bNIDHD5Q4xNG7BumVjq6KHZNnOsTXZW9nZHflAMYgGzK6M5Vd3I9BRP7JpD1TkDi 1eGFlELtpM/T8qi+d5P4TlTUpdQP8+g4Asry5JQGwfxH5Wz2YAQsW2SGJfJxiWtQbHBB vJuw== X-Google-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:content-type:x-gm-message-state; bh=1/uI51+POp/nDPZ+WNw2Bhx/DxabSTuzZzWNejfsqUc=; b=c//C2jhganeNMFy+f7dw8OWbW/Mw4gDB6hnc7z0z47LU31XdqdbkXTXtdwoBBQ6rO5 zVy74fFs7otsivu6yr7dwjFMX8tWPA2BPeaP1BAGaB3wMkiysdssB+JF9oJ6MDeh+T0y EpsKS8nmxfID2iUX0C4xTSDPwmKgKEZ9jRetP8m/2QhwDbEJUxe6MLI1htwlord1BSvg /B4dxezF5R/893IN8GmSKtgEbuMj3hsSSd3a9T/fky+1SZSyQ+lg05joOwG2izL4CRgk Ib7bZSnO0X6VIWHXzBK4Tzebehdgtfh0nyic2WiD5AnWdqzsiVFn66I7N1SZ+0zA1MfA ASUQ== Received: by 10.42.180.65 with SMTP id bt1mr416011icb.41.1355797959546; Mon, 17 Dec 2012 18:32:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.113.1 with HTTP; Mon, 17 Dec 2012 18:32:18 -0800 (PST) In-Reply-To: <50CA0B1C.3000509@gmail.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <50CA0B1C.3000509@gmail.com> From: Lorenzo Colitti Date: Tue, 18 Dec 2012 11:32:18 +0900 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=90e6ba6e81d8c4179f04d1174fe1 X-Gm-Message-State: ALoCoQk4+n5j6bCTLvfnPelmmhCrw9jJqFwUEua1l9fs4KUXlexzP+RwHj06zUJU4NBRR5R6vAvYHWfI8PDqJArVizV0FPdD+6jeFYugHvwfn80Oa+XRmd5tdI1S4aNm2zw449mCggI3lRd5sLhCzIZ8tjn+32m2pvLdMOXqjXohsJ0SUmLFcfQ9rDwl0JuQTUznmi6DjQ1q Cc: v6ops@ietf.org, DECREMPS Sylvain , IMADALI Sofiane Subject: Re: [v6ops] example method (was: single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 02:32:40 -0000 --90e6ba6e81d8c4179f04d1174fe1 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 14, 2012 at 2:06 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > On the UE use new LTE USB key which support CDC-Ethernet. This LTE USB > key has a IEEE-assigned MAC address despite being 3GPP. [...] > On this configuration the operator's router (GGSN?) sends NS on the wwan0 > interface for any dst address derived of that /64. Do you know for sure that the operator's router is sending the NS message? Could it be the USB key faking it? --90e6ba6e81d8c4179f04d1174fe1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri= , Dec 14, 2012 at 2:06 AM, Alexandru Petrescu <alexandru.petres= cu@gmail.com> wrote:
On the UE use new= LTE USB key which support CDC-Ethernet. =A0This LTE USB key has a IEEE-ass= igned MAC address despite being 3GPP. =A0[...]
On this configuration the operator's router (GGSN?) sends NS on the wwa= n0 interface for any dst address derived of that /64.

=
Do you know for sure that the operator's router is sending t= he NS message? Could it be the USB key faking it?
--90e6ba6e81d8c4179f04d1174fe1-- From alexandru.petrescu@gmail.com Tue Dec 18 00:06:01 2012 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 5204521F85D3 for ; Tue, 18 Dec 2012 00:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.062 X-Spam-Level: X-Spam-Status: No, score=-10.062 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvliL1nKBqxE for ; Tue, 18 Dec 2012 00:06:00 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD4721F84E8 for ; Tue, 18 Dec 2012 00:06:00 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id qBI85vJM020237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Dec 2012 09:05:57 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id qBI85uk4026455; Tue, 18 Dec 2012 09:05:57 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id qBI85p5u003337; Tue, 18 Dec 2012 09:05:56 +0100 Message-ID: <50D023DF.30109@gmail.com> Date: Tue, 18 Dec 2012 09:05:51 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <50CA0B1C.3000509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, DECREMPS Sylvain , IMADALI Sofiane Subject: Re: [v6ops] example method X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 08:06:01 -0000 Le 18/12/2012 03:32, Lorenzo Colitti a écrit : > On Fri, Dec 14, 2012 at 2:06 AM, Alexandru Petrescu > > > wrote: > > On the UE use new LTE USB key which support CDC-Ethernet. This LTE > USB key has a IEEE-assigned MAC address despite being 3GPP. [...] > On this configuration the operator's router (GGSN?) sends NS on the > wwan0 interface for any dst address derived of that /64. > > > Do you know for sure that the operator's router is sending the NS > message? Could it be the USB key faking it? If it is the key faking it then it is a very good fake. The NS is sent at the reception of a EchoReply (initially, an EchoRequest was sent by the UE towards a CN on the internet). The EchoReply is not delivered to the UE until a NA is sent by the UE. The src address of the NS is that of the Gateway - the same as the next-hop of the default route entry in the rt table. The Source link layer address field in NS is that of the Gateway (and not of the key; the key has a different Source link layer address). It is the same Source link layer address as present in the RA. That makes me think it is not the key faking it. If it is faked then it is a very good fake. Also, if this NS is a key-fake then is not somethink I could influence on the classic IP stack on the computer. Alex From jounikor@gmail.com Tue Dec 18 04:55:35 2012 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 0EEA021F88DB for ; Tue, 18 Dec 2012 04:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YwAslDSpNea for ; Tue, 18 Dec 2012 04:55:34 -0800 (PST) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1821F888F for ; Tue, 18 Dec 2012 04:55:33 -0800 (PST) Received: by mail-ee0-f49.google.com with SMTP id c4so304809eek.36 for ; Tue, 18 Dec 2012 04:55:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=RyPMhKEvkpnuYgMTRRes/CKDQy1UQIUWxBg1T4NFu1c=; b=KQiaRjjbKztfoZRYJ7ecSxpKKryTHdxtTe3QaPifxqxHUUdimXRWp3JoFJ5/WYQOVp oXpK9DaXEZk4NZ6Gut18q8V+few8A0c1CpKPGmn3aDJ//eIITYKwdpQ42pbEVuDzkIAo yzpvHc15z02HauuTmin9E+PiZEul/CwVQ6oo1hP+kBZ2alRobIylcRXu6RQA8KpOLdXC AXSVVfP2NXIgvQ0g7pO4iniVrQnA2qIsw2UpkNe0ebyxDxXrHF0LcOmUSTD8YAK/17yq 1RYk/537XLyowOMcb1wCR+vaRf2MDw/EGez1imMvyBWTI9ei97cAiHDdbXpqhq0lOXh7 qyXg== X-Received: by 10.14.174.198 with SMTP id x46mr5404689eel.23.1355835333239; Tue, 18 Dec 2012 04:55:33 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id 46sm3114156eeg.4.2012.12.18.04.55.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Dec 2012 04:55:30 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: <50D023DF.30109@gmail.com> Date: Tue, 18 Dec 2012 14:55:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1C760943-22CD-4590-A4FA-799C5C3C6B1F@gmail.com> References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <50CA0B1C.3000509@gmail.com> <50D023DF.30109@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: v6ops@ietf.org, DECREMPS Sylvain , IMADALI Sofiane Subject: Re: [v6ops] example method X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 12:55:35 -0000 Alex, On Dec 18, 2012, at 10:05 AM, Alexandru Petrescu = wrote: > Le 18/12/2012 03:32, Lorenzo Colitti a =E9crit : >> On Fri, Dec 14, 2012 at 2:06 AM, Alexandru Petrescu >> > >> wrote: >>=20 >> On the UE use new LTE USB key which support CDC-Ethernet. This LTE >> USB key has a IEEE-assigned MAC address despite being 3GPP. [...] >> On this configuration the operator's router (GGSN?) sends NS on the >> wwan0 interface for any dst address derived of that /64. >>=20 >>=20 >> Do you know for sure that the operator's router is sending the NS >> message? Could it be the USB key faking it? >=20 > If it is the key faking it then it is a very good fake. A lot can be done in a modem firmware. > The NS is sent at the reception of a EchoReply (initially, an > EchoRequest was sent by the UE towards a CN on the internet). The > EchoReply is not delivered to the UE until a NA is sent by the UE. In order to stop the "guess work" why don't you say whose USB dongle and whose GGSN you are testing against. Even more nicer would be providing a GTP capture ;) > The src address of the NS is that of the Gateway - the same as the > next-hop of the default route entry in the rt table. The Source link > layer address field in NS is that of the Gateway (and not of the key; > the key has a different Source link layer address). It is the same > Source link layer address as present in the RA. Please, don't keep saying "the SLLA of the GW" since the link technology has none. And yes, some gateways synthesise those but they still are not real link-layer addresses per se. Just there to keep sad software = happy.. - Jouni > That makes me think it is not the key faking it. If it is faked then = it > is a very good fake. > Also, if this NS is a key-fake then is not somethink I could influence > on the classic IP stack on the computer. >=20 > Alex >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Tue Dec 18 05:45:04 2012 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 C713F21F87F7 for ; Tue, 18 Dec 2012 05:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChOddLXQnpvc for ; Tue, 18 Dec 2012 05:45:04 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 20A9221F871D for ; Tue, 18 Dec 2012 05:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=126; q=dns/txt; s=iport; t=1355838304; x=1357047904; h=date:from:message-id:to:subject:cc; bh=d00avLyIqeyCJruoW/GcV5/QFu2MuFHKELabjjjkk1w=; b=TYeqrlRjD8rfTDmckOQT/eoOMOLeEHr0nia1wDcQIDXK40lBUlhu+hxX iIUb+yNNS5GsR/Qocm/W5E3TfKmKKQ8iOxMNwhDqwd+adPh4hERp40jYm Eswz2NFFxdPcdh4VUM3R06HV12cnXkjZnY+NwN7s3NSau74u8gHIk4Tpa Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicNAPdy0FCrRDoH/2dsb2JhbABEhXSmFQGRFwQDfhZzgx48LYh6DagOkEuNY4MpA4hhjkWPLIMU X-IronPort-AV: E=Sophos;i="4.84,309,1355097600"; d="scan'208";a="64295929" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 18 Dec 2012 13:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBIDj10I025306; Tue, 18 Dec 2012 13:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id qBIDj1203010; Tue, 18 Dec 2012 05:45:01 -0800 (PST) Date: Tue, 18 Dec 2012 05:45:01 -0800 (PST) From: Message-Id: <201212181345.qBIDj1203010@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-64share@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 13:45:04 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-64share. Please take a look at it and comment. From alexandru.petrescu@gmail.com Tue Dec 18 06:08:10 2012 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 6468D21F8A09 for ; Tue, 18 Dec 2012 06:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+gT1imx-tdN for ; Tue, 18 Dec 2012 06:08:09 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 681A721F89D2 for ; Tue, 18 Dec 2012 06:08:09 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id hm2so411965wib.16 for ; Tue, 18 Dec 2012 06:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mq7qvftPMk1sAfnoduevniCW6Q5amBNGyiKYDPf6DUI=; b=IEN7GVvEc6DtRRJeimEJSvUsEHuACYfnM4NR3GgwvFnMDqli2tUwcAKLu6/+i6zo/R uw8d8trOm8QQf7abaVgcwB6EFPDpO9JlEsH0Vh1c1y+gfO5yXEPn794GP/9CotHXG49x 2830dKYu5dAv0Y+0eaydER8kFswIp0GKAUqahtlC7DyfFrWjJABdsF+A1UK6UnGsEqNa /M6q2sxCrqzQMO5Hn4D+8RezZNGx84V+60kPO0b2GUiITmQVFMInCHA6wHRro/jjhH9D 6BkSGIE2FOXT9XbhjJTDhxSRNtz/oqc6H8XSJors04I0ZOwMUN/3o88kSLy1Pq+hL9ns o+Qw== X-Received: by 10.194.77.13 with SMTP id o13mr4593298wjw.58.1355839688450; Tue, 18 Dec 2012 06:08:08 -0800 (PST) Received: from [192.168.250.116] (APuteaux-652-1-78-137.w90-61.abo.wanadoo.fr. [90.61.237.137]) by mx.google.com with ESMTPS id l5sm2821420wia.10.2012.12.18.06.08.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Dec 2012 06:08:07 -0800 (PST) Message-ID: <50D078C4.90604@gmail.com> Date: Tue, 18 Dec 2012 15:08:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jouni Korhonen References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> <75B6FA9F576969419E42BECB86CB1B89077E3D@xmb-rcd-x06.cisco.com> <50CA0B1C.3000509@gmail.com> <50D023DF.30109@gmail.com> <1C760943-22CD-4590-A4FA-799C5C3C6B1F@gmail.com> In-Reply-To: <1C760943-22CD-4590-A4FA-799C5C3C6B1F@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, DECREMPS Sylvain , IMADALI Sofiane Subject: Re: [v6ops] example method X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 14:08:10 -0000 Le 18/12/2012 13:55, Jouni Korhonen a écrit : > > Alex, > > On Dec 18, 2012, at 10:05 AM, Alexandru Petrescu > wrote: > >> Le 18/12/2012 03:32, Lorenzo Colitti a écrit : >>> On Fri, Dec 14, 2012 at 2:06 AM, Alexandru Petrescu >>> >> > wrote: >>> >>> On the UE use new LTE USB key which support CDC-Ethernet. This >>> LTE USB key has a IEEE-assigned MAC address despite being 3GPP. >>> [...] On this configuration the operator's router (GGSN?) sends >>> NS on the wwan0 interface for any dst address derived of that >>> /64. >>> >>> >>> Do you know for sure that the operator's router is sending the >>> NS message? Could it be the USB key faking it? >> >> If it is the key faking it then it is a very good fake. > > A lot can be done in a modem firmware. I don't doubt that. >> The NS is sent at the reception of a EchoReply (initially, an >> EchoRequest was sent by the UE towards a CN on the internet). The >> EchoReply is not delivered to the UE until a NA is sent by the UE. > > In order to stop the "guess work" why don't you say whose USB dongle > and whose GGSN you are testing against. Even more nicer would be > providing a GTP capture ;) For the key I thought I already said, it's a bandrich. The software is CDC-Ether on recent linux with qmi. Whose GGSN - I believe it is 208 01 and 02. The GTP capture - can I obtain it on the UE? How? I can send wireshark dumps of the RA, and the NS, on that interface of UE, and the state of the rt table and ifconfig on UE. >> The src address of the NS is that of the Gateway - the same as the >> next-hop of the default route entry in the rt table. The Source >> link layer address field in NS is that of the Gateway (and not of >> the key; the key has a different Source link layer address). It is >> the same Source link layer address as present in the RA. > > Please, don't keep saying "the SLLA of the GW" since the link > technology has none. And yes, some gateways synthesise those but they > still are not real link-layer addresses per se. Just there to keep > sad software happy. Does the Gateway has a link-local address? The SLLA present in the RA sent by the Gateway is part of the IID of that link-local address. Whether it's the CDC-Ether who makes that up (intercept RA sent by Gateway, read ll address, fake a SLLA, insert in RA, update the len fields, etc.) - then that's another matter. Alex > > - Jouni > >> That makes me think it is not the key faking it. If it is faked >> then it is a very good fake. Also, if this NS is a key-fake then is >> not somethink I could influence on the classic IP stack on the >> computer. >> >> Alex >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From cb.list6@gmail.com Wed Dec 19 07:42:47 2012 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 8A14E21F8866; Wed, 19 Dec 2012 07:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.115 X-Spam-Level: X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhwZL4NZWlmp; Wed, 19 Dec 2012 07:42:46 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by ietfa.amsl.com (Postfix) with ESMTP id 30CE521F882E; Wed, 19 Dec 2012 07:42:45 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id p5so1578813lag.19 for ; Wed, 19 Dec 2012 07:42:45 -0800 (PST) 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:content-type; bh=UG1Pr5kk4p3gqrGWzk276NKC+n7XhfTwpMDbsFToOwE=; b=sqRrGVcGl1a/pKkwH7S+m2s1wTCJ3o489tQ0WJ4wwB25W1FFGaYWrHF3NbzsHDCJZk TzhKEHwQ0PBXB60wiEPSFehpXI41Hg1vP/6chPwK6C6Xv9J9SdDFu70yUI8CQqy83VPY 3QsXz3HCNILsNR9QHPPVK/YsBUnxU74eKwG6fgcx/onE4n76ByPAUhcJUYoNF2U7rCst gnBYeFE4OgSOB/OC5YoxIBLLkO9Jwh4AC74fHb6Ao4kwXIUIARjDDf6/29YRud84Gpi1 i72WewXQKRK0i5tI9R78qKT+xiUnNRkAi5oC8Io6ax9lEgds+a2GegzobVznbyYnRXkv 136g== MIME-Version: 1.0 Received: by 10.152.144.130 with SMTP id sm2mr5724093lab.49.1355931765063; Wed, 19 Dec 2012 07:42:45 -0800 (PST) Received: by 10.112.44.36 with HTTP; Wed, 19 Dec 2012 07:42:44 -0800 (PST) In-Reply-To: <50CBB3C5.40502@cernet.edu.cn> References: <509CB678.9090402@redpill-linpro.com> <50CBB3C5.40502@cernet.edu.cn> Date: Wed, 19 Dec 2012 07:42:44 -0800 Message-ID: From: Cameron Byrne To: Xing Li Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" , sunset4@ietf.org, Tore Anderson Subject: Re: [v6ops] draft-anderson-siit-dc-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:42:47 -0000 On Fri, Dec 14, 2012 at 3:18 PM, Xing Li wrote: > Hi, Tore and All, > > Thanks for your interesting draft. I also noticed that you presented this > concept in RIPE64 > https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf > Due to the deployment of VMs in the DC, the depletion of the IPv4 address is > a big issue and your draft presents a solution. I would like to see the > discussion of your draft in v6ops. > > Regards, > > xing +1, i have read the draft and i believe it is something we need to work on. More and more ipv6-only networks are popping up (TMO USA for mobile, TerraStream at DT for fixed line, Red Pill in data center, CERNET2 in backbone ...), and i believe Tore has outlined a sensible path for achieving this in a data centers ...what's more... it is a running code... errr.. network. I urge the chairs for sunset4 and v6ops to make a call on which WG should own it and then take on the task of stewarding it into a WG document. This draft is clearly about running an IPv6 network (so v6ops), but the main feature is shutting off ipv4 (so sunset4) editorial comments sent directly to the author. CB From sarikaya2012@gmail.com Wed Dec 19 11:42:07 2012 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 40D6D21F87B2; Wed, 19 Dec 2012 11:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SxQwZMjZptD; Wed, 19 Dec 2012 11:42:06 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3366621F8750; Wed, 19 Dec 2012 11:42:06 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id k13so3421309iea.22 for ; Wed, 19 Dec 2012 11:42:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KxzfFWduTYf9T71PsSTLzbGk/CIkMtvJe3c7W8tTAHM=; b=f6i4sWDoZOIrgdyPx9yrOMo7dOd2K+Jxc2fHlQnSfDaPIbSIwyL9CLNGUS42p13XqM M+XbCXNG/xvCuE2Gyyxdv2kQ8Yp7xAmZJ4X4rZ4Mq3AFtJ3+SVWvPv/hsEGAktura3Rq jc95KQkXsqtQpYrGptO4de+eKRqcqFbiwHBxUArjNKqAtvX1G7EHpkRl443JmIRKHR6O acI+u4KDveQBP3HhCcvPL+j5OqYE+M47OzGnfyXXPkXHQpf+dzmFf81FPraSsvINGo6r pnkpaGUPX4ob8N94diRk4pv8nccj4Avw7yIHNcaLNIDI8SrrMFc+4j36OMt2Lf7q31lu hTMQ== MIME-Version: 1.0 Received: by 10.50.57.225 with SMTP id l1mr8314576igq.37.1355946125683; Wed, 19 Dec 2012 11:42:05 -0800 (PST) Received: by 10.231.244.4 with HTTP; Wed, 19 Dec 2012 11:42:05 -0800 (PST) In-Reply-To: References: <509CB678.9090402@redpill-linpro.com> <50CBB3C5.40502@cernet.edu.cn> Date: Wed, 19 Dec 2012 13:42:05 -0600 Message-ID: From: Behcet Sarikaya To: Cameron Byrne Content-Type: multipart/alternative; boundary=14dae934111527ede704d139cf6f Cc: "v6ops@ietf.org" , Tore Anderson , sunset4@ietf.org Subject: Re: [v6ops] [sunset4] draft-anderson-siit-dc-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 19:42:07 -0000 --14dae934111527ede704d139cf6f Content-Type: text/plain; charset=ISO-8859-1 Hi Cameron, Please post your comments to the list. Regards, Behcet On Wed, Dec 19, 2012 at 9:42 AM, Cameron Byrne wrote: > On Fri, Dec 14, 2012 at 3:18 PM, Xing Li wrote: > > Hi, Tore and All, > > > > Thanks for your interesting draft. I also noticed that you presented this > > concept in RIPE64 > > > https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf > > Due to the deployment of VMs in the DC, the depletion of the IPv4 > address is > > a big issue and your draft presents a solution. I would like to see the > > discussion of your draft in v6ops. > > > > Regards, > > > > xing > > +1, i have read the draft and i believe it is something we need to > work on. More and more ipv6-only networks are popping up (TMO USA for > mobile, TerraStream at DT for fixed line, Red Pill in data center, > CERNET2 in backbone ...), and i believe Tore has outlined a sensible > path for achieving this in a data centers ...what's more... it is a > running code... errr.. network. > > I urge the chairs for sunset4 and v6ops to make a call on which WG > should own it and then take on the task of stewarding it into a WG > document. This draft is clearly about running an IPv6 network (so > v6ops), but the main feature is shutting off ipv4 (so sunset4) > > editorial comments sent directly to the author. > > CB > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > --14dae934111527ede704d139cf6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cameron,

Please post your comments to the list.

Regards,
Behcet

On Wed, Dec 19, 2012 at 9:42= AM, Cameron Byrne <cb.list6@gmail.com> wrote:
On Fri, Dec 14, 2012 at 3:= 18 PM, Xing Li <xing@cernet.edu.cn= > wrote:
> Hi, Tore and All,
>
> Thanks for your interesting draft. I also noticed that you presented t= his
> concept in RIPE64
> https://ripe64.rip= e.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.= pdf
> Due to the deployment of VMs in the DC, the depletion of the IPv4 addr= ess is
> a big issue and your draft presents a solution. I would like to see th= e
> discussion of your draft in v6ops.
>
> Regards,
>
> xing

+1, i have read the draft and i believe it is something we need to work on. =A0More and more ipv6-only networks are popping up (TMO USA for mobile, TerraStream at DT for fixed line, Red Pill in data center,
CERNET2 in backbone ...), and i believe Tore has outlined a sensible
path for achieving this in a data centers ...what's more... it is a
running code... errr.. network.

I urge the chairs for sunset4 and v6ops to make a call on which WG
should own it and then take on the task of stewarding it into a WG
document. =A0This draft is clearly about running an IPv6 network (so
v6ops), but the main feature is shutting off ipv4 (so sunset4)

editorial comments sent directly to the author.

CB
_____________________= __________________________
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4

--14dae934111527ede704d139cf6f-- From brian.e.carpenter@gmail.com Thu Dec 20 00:03:07 2012 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 DBEAA21F84FF for ; Thu, 20 Dec 2012 00:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.6 X-Spam-Level: X-Spam-Status: No, score=-101.6 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiTGAIiboegV for ; Thu, 20 Dec 2012 00:03:07 -0800 (PST) Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by ietfa.amsl.com (Postfix) with ESMTP id 36F8621F84F5 for ; Thu, 20 Dec 2012 00:03:07 -0800 (PST) Received: by mail-ea0-f169.google.com with SMTP id a12so1231493eaa.0 for ; Thu, 20 Dec 2012 00:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=GpRX8WyhLknQtuF9A1A2ZGskfKTx7Elej+lBkpjcECY=; b=kc9Lw5pPxJKk45QTZzRQsiRbz/kwLh9a+T/8ioCHlsYopuuvfzey6FL0p6xduYhsj3 JL3DovglV3rZQ8khP16Gnp6O1w0bxnZzuuCsac3Z7HhkHDp+SnoZJYp3SxX7wugzX99T wwZ1Q68R6I9qD9zSNZDvu9tw76CbhBKxnZ6elt8P1s2IkYkauVdeVUZwR54JKnSE/9PB b3EJl994uX9ltAesnL2bmSjPwhfinILSf9gKKXYZe/sg2z8JKWx/M+cgnd5n8nOupJEU 2dnch7JCdcH/OXx5WLQqqPZGUdp1HoOLM09ynEIprBsu1uS/pZYnLhVCi9q8uDjc9sGA qFLQ== X-Received: by 10.14.219.72 with SMTP id l48mr21370897eep.37.1355990586369; Thu, 20 Dec 2012 00:03:06 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-199.as13285.net. [2.102.219.199]) by mx.google.com with ESMTPS id e2sm13900891eeo.8.2012.12.20.00.03.04 (version=SSLv3 cipher=OTHER); Thu, 20 Dec 2012 00:03:05 -0800 (PST) Message-ID: <50D2C643.6050608@gmail.com> Date: Thu, 20 Dec 2012 08:03:15 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 08:03:08 -0000 ICMPv6 PTB filtering is a well known operational problem for PMTUD. I see that RFC 4890, ICMPv6 Filtering Recommendations, is an Informational RFC. Is it time to promote it to BCP? Regards Brian Carpenter From sander@steffann.nl Thu Dec 20 00:12:29 2012 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 2033E21F8A94 for ; Thu, 20 Dec 2012 00:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.985 X-Spam-Level: * X-Spam-Status: No, score=1.985 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_XBL=3.033, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP4hFwXbvZFy for ; Thu, 20 Dec 2012 00:12:28 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 6A82721F8A92 for ; Thu, 20 Dec 2012 00:12:28 -0800 (PST) Received: from [192.168.88.183] (unknown [194.126.10.110]) by mail.sintact.nl (Postfix) with ESMTP id 0A769200E; Thu, 20 Dec 2012 09:12:26 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sander Steffann In-Reply-To: <50D2C643.6050608@gmail.com> Date: Thu, 20 Dec 2012 10:12:25 +0200 Content-Transfer-Encoding: 7bit Message-Id: <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> References: <50D2C643.6050608@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) Cc: IPv6 Operations Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 08:12:29 -0000 Hi, > ICMPv6 PTB filtering is a well known operational problem > for PMTUD. I see that RFC 4890, ICMPv6 Filtering Recommendations, > is an Informational RFC. > > Is it time to promote it to BCP? Yes please! It is already used like a BCP, so lets label it as such. Met vriendelijke groet, Sander Steffann From tjc@ecs.soton.ac.uk Thu Dec 20 00:41:16 2012 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 2BEBA21F85D0 for ; Thu, 20 Dec 2012 00:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=-1.314, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ET7uDgb2T9Mk for ; Thu, 20 Dec 2012 00:41:15 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 2A10C21F85C3 for ; Thu, 20 Dec 2012 00:41:15 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qBK8f9tK016873; Thu, 20 Dec 2012 08:41:09 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk qBK8f9tK016873 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1355992869; bh=yvF4HfrRVwZ3erP4k74H7YESFVU=; h=References:Mime-Version:In-Reply-To:Cc:From:Subject:Date:To; b=fekw2Cuz9WCqOzA3BVDvti+ojrXbiGKDex3bx5+dZpFrrb3+griFZRKUKtT/+cXpB yuccYso856k3l/mA4DzpeKNrBL7fecrbx1VNgtAmpbEeg/XitW2oDwBiRDRrDlQ++g 9Bqx0HF+tFFI9b/3f+1UR5X5gqAL3L+XOVv/PScA= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id oBJ8f90430651759xl ret-id none; Thu, 20 Dec 2012 08:41:09 +0000 Received: from [192.168.1.101] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qBK8f1g9022080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Dec 2012 08:41:05 GMT References: <50D2C643.6050608@gmail.com> <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> Mime-Version: 1.0 (1.0) In-Reply-To: <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: X-Mailer: iPad Mail (10A523) From: Tim Chown Date: Thu, 20 Dec 2012 08:43:46 +0000 To: Sander Steffann X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=oBJ8f9043065175900; tid=oBJ8f90430651759xl; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: qBK8f9tK016873 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: IPv6 Operations Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 08:41:16 -0000 On 20 Dec 2012, at 08:12, Sander Steffann wrote: > Hi, >=20 >> ICMPv6 PTB filtering is a well known operational problem >> for PMTUD. I see that RFC 4890, ICMPv6 Filtering Recommendations, >> is an Informational RFC. >>=20 >> Is it time to promote it to BCP? >=20 > Yes please! It is already used like a BCP, so lets label it as such. On this aspect, certainly. The rest of the text should also be reviewed if w= e're promoting it. Tim= From cpignata@cisco.com Thu Dec 20 05:38:57 2012 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 E82CE21F8B54 for ; Thu, 20 Dec 2012 05:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.269 X-Spam-Level: X-Spam-Status: No, score=-110.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufJnwBFJz6i0 for ; Thu, 20 Dec 2012 05:38:56 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F34F121F8997 for ; Thu, 20 Dec 2012 05:38:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=606; q=dns/txt; s=iport; t=1356010736; x=1357220336; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=O0kCTLayKtK+8oIlI2/HSduO5Mht/Gc0+4CK8CfesQg=; b=C102AZ4/6c6deECkxF45sMzyaOiLTCRLwz3QiTJATfm0QAj+Y7FmHXBh i+ESmZzt1Igeo4wnZ3a/WVnQNkR1mpNAkBStKObRd5MycmrxpUgR4FciZ JG3LoaNE6RykHtPt8TVSdLxKpRRAvpOtbuYgeYECb1MSzzEyecAu0VsLb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFACcU01CtJXG//2dsb2JhbABEhXO3ehZzgh4BAQEDAQEBATc0CwULAgEIIhQQIQYLJQIEDgUIh3kDCQYMrz4NiVEEi2lpg2JhA5Q1jQ2FEYJ0giI X-IronPort-AV: E=Sophos;i="4.84,322,1355097600"; d="scan'208";a="152057399" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 20 Dec 2012 13:38:55 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBKDcte1023570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Dec 2012 13:38:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.159]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 07:38:55 -0600 From: "Carlos Pignataro (cpignata)" To: Brian E Carpenter Thread-Topic: [v6ops] ICMPv6 Filtering Recommendations to BCP? Thread-Index: AQHN3rdaTV9cegJ7RkeyQscSPLYkcw== Date: Thu, 20 Dec 2012 13:38:54 +0000 Message-ID: <95067C434CE250468B77282634C96ED32280F82C@xmb-aln-x02.cisco.com> References: <50D2C643.6050608@gmail.com> In-Reply-To: <50D2C643.6050608@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.52.103] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 13:38:57 -0000 One (not mutually-exclusive) alternative is also to finish draft-ietf-opsec= -icmp-filtering. Thanks, -- Carlos. On Dec 20, 2012, at 3:03 AM, Brian E Carpenter wrote: > ICMPv6 PTB filtering is a well known operational problem > for PMTUD. I see that RFC 4890, ICMPv6 Filtering Recommendations, > is an Informational RFC. >=20 > Is it time to promote it to BCP? >=20 > Regards > Brian Carpenter >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From jhw@apple.com Thu Dec 20 10:51:25 2012 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 DA93721F8920 for ; Thu, 20 Dec 2012 10:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id km0a9t7GcswM for ; Thu, 20 Dec 2012 10:51:25 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4A56A21F88C5 for ; Thu, 20 Dec 2012 10:51:25 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MFC000Z5F190632@mail-out.apple.com> for v6ops@ietf.org; Thu, 20 Dec 2012 10:51:14 -0800 (PST) X-AuditID: 11807137-b7f156d000005a91-2c-50d35e227d13 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 0B.7D.23185.22E53D05; Thu, 20 Dec 2012 10:51:14 -0800 (PST) Received: from kallisti.apple.com ([17.193.13.64]) by chive.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MFC00F6JF1DU130@chive.apple.com> for v6ops@ietf.org; Thu, 20 Dec 2012 10:51:14 -0800 (PST) From: james woodyatt In-reply-to: <50D2C643.6050608@gmail.com> Date: Thu, 20 Dec 2012 10:51:13 -0800 Message-id: References: <50D2C643.6050608@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.1643) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FDMr6sUdznAoO+orsXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcbvnOWtBE1PFrimb2RoYTzF2MXJwSAiYSDyYxtTFyAlkiklc uLeeDcQWEpjAJLFmrmQXIxeQPYVJ4u+JR+wgCWYBLYn1O4+DNfAK6ElsvbMZLC4sYCvR8PUB mM0moCLx7fJdJpD5nAKaElf32IGEWQRUJX7u+sUEMUZT4smPFkYIW1viybsLrBAjbSQ6z6xj gbhBQ+L09Elg9SIChhL/n35mhLhTVuLShZXMExgFZiG5aBaSi2YhGbuAkXkVo2BRak5ipaGZ XmJBQU6qXnJ+7iZGcNgVmu9g3P5X7hCjAAejEg9vhMXlACHWxLLiytxDjBIczEoivLlaQCHe lMTKqtSi/Pii0pzU4kOM0hwsSuK8MusvBQgJpCeWpGanphakFsFkmTg4pRoYaz9bbQl4yXp9 S+LW58WqtqtWF+5OuN+8/pXh5S0P39zImXf2TUxIOeu9PTN/rNBUsDq9bC+nkuWCD3fTuxdt /hZq36L2rTvsusJvuQDZDfK/7uvZcqmkyW6KNOK65uC0ucby0hH3uDzurxtWWJ3fKfuNJefR 0chNzHsOOnYreoaenaf+i/22hhJLcUaioRZzUXEiAFAvDWQ3AgAA Cc: list Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:51:26 -0000 On Dec 20, 2012, at 24:03 , Brian E Carpenter wrote: > > Is it time to promote it to BCP? Strike while the iron is still warmer than ambient temperature. -- james woodyatt core os networking From rja.lists@gmail.com Fri Dec 21 06:37:33 2012 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 01C0321F8652 for ; Fri, 21 Dec 2012 06:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bom4cCnSI71H for ; Fri, 21 Dec 2012 06:37:30 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id DEE5821F8682 for ; Fri, 21 Dec 2012 06:37:29 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id n11so5254646vch.30 for ; Fri, 21 Dec 2012 06:37:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=WS7jELZmjNYI5m7DKuaLltP/9Cnxn9Q+xcDaj0yKz9A=; b=0aPVsHH90sohCda3VV1UDNMgokQOcEolla6Xl9KlZfJJY5T1lmuZ7byEUbY12u8fNc OFNhM5+klPXnO5kMXwJ88krD96sSaLnN3ViowCuhz4Z5GKXsk3G6SVIxYJhCWgEwyfg8 NBbC0CAz42m//AHZQyCVPfZKHO/dLVzrpML6sPUlrXpLU3KRDLuudMj/87E0xzctRUdY rJy2nes7bWaoBzDPvpn9u1VZ2mmzh4+UhK23x5KKXGIKVs0tCb24PMMz9KJ0ZHodoAud ToQ1S+xgNjzJdT847Zj44T+j1hbyioNtodHBL4zUfHilFbO57qkwJWoanZL+AFc/D2R2 27aA== X-Received: by 10.220.107.5 with SMTP id z5mr20421409vco.22.1356100649220; Fri, 21 Dec 2012 06:37:29 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id yu4sm9294211veb.7.2012.12.21.06.37.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Dec 2012 06:37:28 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 21 Dec 2012 09:37:27 -0500 Message-Id: <06A3D3CC-CA71-4BDD-A35B-31EC7AE7CBBB@gmail.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 14:37:33 -0000 Earlier, Tim Chown wrote, in part: > On this aspect, certainly. +1 > The rest of the text should also be reviewed if we're promoting it. +1 Aside: One possible approach to both of the objectives above would be to begin a longer-than-normal WG Last Call on promoting RFC-4890 to BCP -- "longer-than-normal", perhaps 4 weeks, to permit WG folks ample time to review the whole document (i.e., RFC 4890). Yours, Ran From elwynd@dial.pipex.com Fri Dec 21 08:58:47 2012 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 2C3AD21F84EA for ; Fri, 21 Dec 2012 08:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmVSh-LqTIMK for ; Fri, 21 Dec 2012 08:58:46 -0800 (PST) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by ietfa.amsl.com (Postfix) with ESMTP id A982E21F84E6 for ; Fri, 21 Dec 2012 08:58:46 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Tm5vo-0000pI-E8; Fri, 21 Dec 2012 16:58:44 +0000 From: Elwyn Davies To: Tim Chown In-Reply-To: References: <50D2C643.6050608@gmail.com> <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> Content-Type: text/plain Date: Fri, 21 Dec 2012 16:58:11 +0000 Message-Id: <1356109091.11916.15400.camel@mightyatom> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 16:58:47 -0000 Hi. On Thu, 2012-12-20 at 08:43 +0000, Tim Chown wrote: > On 20 Dec 2012, at 08:12, Sander Steffann wrote: > > > Hi, > > > >> ICMPv6 PTB filtering is a well known operational problem > >> for PMTUD. I see that RFC 4890, ICMPv6 Filtering Recommendations, > >> is an Informational RFC. > >> > >> Is it time to promote it to BCP? Those with long memories will remember that progressing this doc as a BCP was discussed when it was originally written, but it was not thought that there was enough common practice to justify this designation at the time. I'm glad it seems to have been useful :-) > > > > Yes please! It is already used like a BCP, so lets label it as such. > > On this aspect, certainly. The rest of the text should also be reviewed if we're promoting it. Right: Checking the IANA list, there have been at least 5 new codes put into service (154-158) since the document was written. As one of the original authors, I'd be happy to put in some extra cycles to update the text, but I have not been deeply involved in IPv6 operational matters for some years so would need input from those more involved at the moment to bring the text up to date. The filter script in the appendix could doubtless do with a check as well. Regards, Elwyn > > Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mohacsi@niif.hu Sat Dec 22 09:49:43 2012 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 C6DD721F89E8 for ; Sat, 22 Dec 2012 09:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.596 X-Spam-Level: X-Spam-Status: No, score=0.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m04pDxVymRb for ; Sat, 22 Dec 2012 09:49:43 -0800 (PST) Received: from strudel.ki.iif.hu (strudel.ki.iif.hu [IPv6:2001:738:0:411:20f:1fff:fe6e:ec1e]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC0C21F89A4 for ; Sat, 22 Dec 2012 09:49:42 -0800 (PST) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by strudel.ki.iif.hu (Postfix) with ESMTP id 7EC4440C; Sat, 22 Dec 2012 18:49:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from strudel.ki.iif.hu ([IPv6:::ffff:193.6.222.244]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id 8cGP0hhdGyod; Sat, 22 Dec 2012 18:49:34 +0100 (CET) Received: by strudel.ki.iif.hu (Postfix, from userid 9002) id 38C4A40F; Sat, 22 Dec 2012 18:49:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by strudel.ki.iif.hu (Postfix) with ESMTP id 2BAE840C; Sat, 22 Dec 2012 18:49:34 +0100 (CET) Date: Sat, 22 Dec 2012 18:49:34 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@strudel.ki.iif.hu To: Elwyn Davies In-Reply-To: <1356109091.11916.15400.camel@mightyatom> Message-ID: References: <50D2C643.6050608@gmail.com> <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> <1356109091.11916.15400.camel@mightyatom> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 17:49:43 -0000 Dear All, As an other author of the draft, I am also ready to contribute and send updates. Best Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Director Network and Multimedia NIIF/HUNGARNET, HUNGARY Co-chair of Hungarian IPv6 Forum Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Fri, 21 Dec 2012, Elwyn Davies wrote: > Hi. > On Thu, 2012-12-20 at 08:43 +0000, Tim Chown wrote: >> On 20 Dec 2012, at 08:12, Sander Steffann wrote: >> >>> Hi, >>> >>>> ICMPv6 PTB filtering is a well known operational problem >>>> for PMTUD. I see that RFC 4890, ICMPv6 Filtering Recommendations, >>>> is an Informational RFC. >>>> >>>> Is it time to promote it to BCP? > Those with long memories will remember that progressing this doc as a > BCP was discussed when it was originally written, but it was not thought > that there was enough common practice to justify this designation at the > time. I'm glad it seems to have been useful :-) > >>> >>> Yes please! It is already used like a BCP, so lets label it as such. >> >> On this aspect, certainly. The rest of the text should also be reviewed if we're promoting it. > > Right: Checking the IANA list, there have been at least 5 new codes put > into service (154-158) since the document was written. > > As one of the original authors, I'd be happy to put in some extra cycles > to update the text, but I have not been deeply involved in IPv6 > operational matters for some years so would need input from those more > involved at the moment to bring the text up to date. > > The filter script in the appendix could doubtless do with a check as > well. > > Regards, > Elwyn > >> >> Tim >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Sun Dec 23 15:16:35 2012 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 AD5AD21F8B73; Sun, 23 Dec 2012 15:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLJ-j9wSNUJZ; Sun, 23 Dec 2012 15:16:35 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4F221F8B7A; Sun, 23 Dec 2012 15:16:35 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qBNNGL75027026 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 23 Dec 2012 23:16:21 GMT (envelope-from joelja@bogus.com) Message-ID: <50D790BF.4050701@bogus.com> Date: Sun, 23 Dec 2012 15:16:15 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Cameron Byrne References: <509CB678.9090402@redpill-linpro.com> <50CBB3C5.40502@cernet.edu.cn> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 23 Dec 2012 23:16:22 +0000 (UTC) Cc: "v6ops@ietf.org" , Tore Anderson , sunset4@ietf.org Subject: Re: [v6ops] [sunset4] draft-anderson-siit-dc-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 23:16:35 -0000 On 12/19/12 7:42 AM, Cameron Byrne wrote: > On Fri, Dec 14, 2012 at 3:18 PM, Xing Li wrote: >> Hi, Tore and All, >> >> Thanks for your interesting draft. I also noticed that you presented this >> concept in RIPE64 >> https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf >> Due to the deployment of VMs in the DC, the depletion of the IPv4 address is >> a big issue and your draft presents a solution. I would like to see the >> discussion of your draft in v6ops. >> >> Regards, >> >> xing > +1, i have read the draft and i believe it is something we need to > work on. More and more ipv6-only networks are popping up (TMO USA for > mobile, TerraStream at DT for fixed line, Red Pill in data center, > CERNET2 in backbone ...), and i believe Tore has outlined a sensible > path for achieving this in a data centers ...what's more... it is a > running code... errr.. network. > > I urge the chairs for sunset4 and v6ops to make a call on which WG > should own it and then take on the task of stewarding it into a WG > document. This draft is clearly about running an IPv6 network (so > v6ops), but the main feature is shutting off ipv4 (so sunset4) I do see operating v6 only networks as germain to v6ops. there is clearly an intersection with sunset4 or behave/softwire/et al on how legacy ipv4 needs are supported if at all. > editorial comments sent directly to the author. > > CB > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 > From marc.blanchet@viagenie.ca Sun Dec 23 16:51:22 2012 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 234D321F8BC2; Sun, 23 Dec 2012 16:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.218 X-Spam-Level: X-Spam-Status: No, score=-102.218 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9q9Uz1m+N0a; Sun, 23 Dec 2012 16:51:21 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 80FAD21F8B66; Sun, 23 Dec 2012 16:51:21 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7C180403AE; Sun, 23 Dec 2012 19:51:15 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <50D790BF.4050701@bogus.com> Date: Sun, 23 Dec 2012 19:51:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <73367FC1-8017-42D9-986F-686D44A97AEB@viagenie.ca> References: <509CB678.9090402@redpill-linpro.com> <50CBB3C5.40502@cernet.edu.cn> <50D790BF.4050701@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1283) Cc: sunset4@ietf.org, "v6ops@ietf.org" , Tore Anderson Subject: Re: [v6ops] [sunset4] draft-anderson-siit-dc-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 00:51:22 -0000 Le 2012-12-23 =E0 18:16, joel jaeggli a =E9crit : >=20 > On 12/19/12 7:42 AM, Cameron Byrne wrote: >> On Fri, Dec 14, 2012 at 3:18 PM, Xing Li wrote: >>> Hi, Tore and All, >>>=20 >>> Thanks for your interesting draft. I also noticed that you presented = this >>> concept in RIPE64 >>> = https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6= _Only_Data_Centres.pdf >>> Due to the deployment of VMs in the DC, the depletion of the IPv4 = address is >>> a big issue and your draft presents a solution. I would like to see = the >>> discussion of your draft in v6ops. >>>=20 >>> Regards, >>>=20 >>> xing >> +1, i have read the draft and i believe it is something we need to >> work on. More and more ipv6-only networks are popping up (TMO USA = for >> mobile, TerraStream at DT for fixed line, Red Pill in data center, >> CERNET2 in backbone ...), and i believe Tore has outlined a sensible >> path for achieving this in a data centers ...what's more... it is a >> running code... errr.. network. >>=20 >> I urge the chairs for sunset4 and v6ops to make a call on which WG >> should own it and then take on the task of stewarding it into a WG >> document. This draft is clearly about running an IPv6 network (so >> v6ops), but the main feature is shutting off ipv4 (so sunset4) > I do see operating v6 only networks as germain to v6ops. there is = clearly an intersection with sunset4 or behave/softwire/et al on how = legacy ipv4 needs are supported if at all. right. but sunset4 may do protocol work. Marc. >> editorial comments sent directly to the author. >>=20 >> CB >> _______________________________________________ >> sunset4 mailing list >> sunset4@ietf.org >> https://www.ietf.org/mailman/listinfo/sunset4 >>=20 >=20 > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 From fred@cisco.com Wed Dec 26 21:47:52 2012 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 795B021F8945 for ; Wed, 26 Dec 2012 21:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.218 X-Spam-Level: X-Spam-Status: No, score=-110.218 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swFmfsfFmhUH for ; Wed, 26 Dec 2012 21:47:51 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 534C521F87E5 for ; Wed, 26 Dec 2012 21:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=989; q=dns/txt; s=iport; t=1356587271; x=1357796871; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8qZUNRKCm0i2GPBNxClsKy8zyxXxszIjWsJ2AIi/+QE=; b=C1oFn3bkUvlRtREBqvXCf+ckEIhgmlfpOjktwgR2SgdUy/IhhABBH3bJ T/6Pf76guMou9h82yXWyf6O9YFq5ObUZCTKOgyo5ekru7GFspUecrgmMF 97q4aE/dTQFyUEXbY0pMBQLXdZxb9ZVZaRpA+OtyzAOWPZFE9XwEEw3/a E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8FAJTf21CtJV2b/2dsb2JhbABEhXO3dxZzgh4BAQEEAQEBNzQLEAIBCBgKFBAnCyUCBA4FCIgLDLVlBIxXC4NXYQOmVIJ0gW01 X-IronPort-AV: E=Sophos;i="4.84,360,1355097600"; d="scan'208";a="156750447" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 27 Dec 2012 05:47:50 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBR5looS006680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Dec 2012 05:47:50 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 26 Dec 2012 23:47:50 -0600 From: "Fred Baker (fred)" To: IPv6 Operations Thread-Topic: [v6ops] ICMPv6 Filtering Recommendations to BCP? Thread-Index: AQHN4/W0GpyeTrLnOkiS5I608FEg+g== Date: Thu, 27 Dec 2012 05:47:50 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553B7260BB@xmb-rcd-x09.cisco.com> References: <50D2C643.6050608@gmail.com> <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ron Bonica Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 05:47:52 -0000 I'll give this a few more days to percolate; most of us are some variation = on a holiday right now, and those that aren't are likely to be in February.= If I see more email supporting this action, I'll initiate the indicated la= st call, and let it run through January. On Dec 20, 2012, at 12:43 AM, Tim Chown wrote: > On 20 Dec 2012, at 08:12, Sander Steffann wrote: >=20 >> Hi, >>=20 >>> ICMPv6 PTB filtering is a well known operational problem >>> for PMTUD. I see that RFC 4890, ICMPv6 Filtering Recommendations, >>> is an Informational RFC. >>>=20 >>> Is it time to promote it to BCP? >>=20 >> Yes please! It is already used like a BCP, so lets label it as such. >=20 > On this aspect, certainly. The rest of the text should also be reviewed i= f we're promoting it. >=20 > Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Thu Dec 27 09:53:28 2012 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 E462B21F8D65 for ; Thu, 27 Dec 2012 09:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqG5nxXkXnZr for ; Thu, 27 Dec 2012 09:53:08 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id F24F621F8D64 for ; Thu, 27 Dec 2012 09:52:56 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qBRHqoC5079465 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 27 Dec 2012 17:52:50 GMT (envelope-from joelja@bogus.com) Message-ID: <50DC8AED.9050009@bogus.com> Date: Thu, 27 Dec 2012 09:52:45 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <50D2C643.6050608@gmail.com> <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> <8C48B86A895913448548E6D15DA7553B7260BB@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553B7260BB@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 27 Dec 2012 17:52:50 +0000 (UTC) Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 17:53:28 -0000 On 12/26/12 9:47 PM, Fred Baker (fred) wrote: > I'll give this a few more days to percolate; most of us are some variation on a holiday right now, and those that aren't are likely to be in February. If I see more email supporting this action, I'll initiate the indicated last call, and let it run through January. I generally think of the existing informational doucments in the series as imutable, so changing the status of an informational document implies a new document which doesn't seem that hard in light of a probaable consensus to do so. > On Dec 20, 2012, at 12:43 AM, Tim Chown wrote: >> On 20 Dec 2012, at 08:12, Sander Steffann wrote: >> >>> Hi, >>> >>>> ICMPv6 PTB filtering is a well known operational problem >>>> for PMTUD. I see that RFC 4890, ICMPv6 Filtering Recommendations, >>>> is an Informational RFC. >>>> >>>> Is it time to promote it to BCP? >>> Yes please! It is already used like a BCP, so lets label it as such. >> On this aspect, certainly. The rest of the text should also be reviewed if we're promoting it. >> >> Tim >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From wesley.george@twcable.com Thu Dec 27 10:13:33 2012 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 1EF0721F8D6B for ; Thu, 27 Dec 2012 10:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIfkodIJ+zRz for ; Thu, 27 Dec 2012 10:13:32 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8248321F8D6A for ; Thu, 27 Dec 2012 10:13:32 -0800 (PST) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,363,1355115600"; d="scan'208";a="3725904" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 27 Dec 2012 13:12:49 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Thu, 27 Dec 2012 13:13:31 -0500 From: "George, Wes" To: joel jaeggli , "Fred Baker (fred)" Date: Thu, 27 Dec 2012 13:13:46 -0500 Thread-Topic: [v6ops] ICMPv6 Filtering Recommendations to BCP? Thread-Index: Ac3kWx+7ODWnnF58ReSfNsRKF02l5AAAKvBQ Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033A7B50DB@PRVPEXVS15.corp.twcable.com> References: <50D2C643.6050608@gmail.com> <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> <8C48B86A895913448548E6D15DA7553B7260BB@xmb-rcd-x09.cisco.com> <50DC8AED.9050009@bogus.com> In-Reply-To: <50DC8AED.9050009@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 18:13:33 -0000 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of joel jaeggli > > I generally think of the existing informational doucments in the series > as imutable, so changing the status of an informational document implies > a new document [WEG] +1 > > On Dec 20, 2012, at 12:43 AM, Tim Chown wrote: > >> On 20 Dec 2012, at 08:12, Sander Steffann wrote: > >>> > >>>> ICMPv6 PTB filtering is a well known operational problem for PMTUD. > >>>> I see that RFC 4890, ICMPv6 Filtering Recommendations, is an > >>>> Informational RFC. > >>>> > >>>> Is it time to promote it to BCP? > >>> Yes please! It is already used like a BCP, so lets label it as such. > >> On this aspect, certainly. The rest of the text should also be > reviewed if we're promoting it. [WEG] The rest of the world (as in, those who don't regularly go for a swim= in the IETF process cistern) sees an RFC as an RFC. The status or class of= document matters very little as long as it is a product of consensus and n= ot obsolete. So changing 4890 just for the sake of the status seems to me l= ike busywork. Those who follow it now will continue to do so, those who do = not won't suddenly start simply because we change the status. I would suppo= rt a new BCP draft if it provides updated guidance from what is already ava= ilable and therefore updates or obsoletes the existing document. Wes George 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 marc.blanchet@viagenie.ca Thu Dec 27 11:12:49 2012 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 ED86421F8D73 for ; Thu, 27 Dec 2012 11:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.217 X-Spam-Level: X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZkMJHjBF-cL for ; Thu, 27 Dec 2012 11:12:49 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED4F21F8D72 for ; Thu, 27 Dec 2012 11:12:49 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5D4BF403A8; Thu, 27 Dec 2012 14:12:48 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923033A7B50DB@PRVPEXVS15.corp.twcable.com> Date: Thu, 27 Dec 2012 14:12:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <457F60F8-6319-40C2-8C50-A0F78A601470@viagenie.ca> References: <50D2C643.6050608@gmail.com> <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> <8C48B86A895913448548E6D15DA7553B7260BB@xmb-rcd-x09.cisco.com> <50DC8AED.9050009@bogus.com> <2671C6CDFBB59E47B64C10B3E0BD5923033A7B50DB@PRVPEXVS15.corp.twcable.com> To: "George, Wes" X-Mailer: Apple Mail (2.1283) Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 19:12:50 -0000 Le 2012-12-27 =E0 13:13, George, Wes a =E9crit : >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >> Of joel jaeggli >>=20 >> I generally think of the existing informational doucments in the = series >> as imutable, so changing the status of an informational document = implies >> a new document > [WEG] +1 >>> On Dec 20, 2012, at 12:43 AM, Tim Chown wrote: >>>> On 20 Dec 2012, at 08:12, Sander Steffann = wrote: >>>>>=20 >>>>>> ICMPv6 PTB filtering is a well known operational problem for = PMTUD. >>>>>> I see that RFC 4890, ICMPv6 Filtering Recommendations, is an >>>>>> Informational RFC. >>>>>>=20 >>>>>> Is it time to promote it to BCP? >>>>> Yes please! It is already used like a BCP, so lets label it as = such. >>>> On this aspect, certainly. The rest of the text should also be >> reviewed if we're promoting it. >=20 > [WEG] The rest of the world (as in, those who don't regularly go for a = swim in the IETF process cistern) sees an RFC as an RFC. The status or = class of document matters very little as long as it is a product of = consensus and not obsolete. So changing 4890 just for the sake of the = status seems to me like busywork. Those who follow it now will continue = to do so, those who do not won't suddenly start simply because we change = the status. I would support a new BCP draft if it provides updated = guidance from what is already available and therefore updates or = obsoletes the existing document. I respectfully disagree: - I agree that changing status is not the most important move and maybe = not change anything in some circles. - however, it is a good tool for a lot of people to better enforce good = practice. BCP is sending a stronger signal.=20 So I agree we should aim at BCP for this one, even if in some circles, = it might not change anything; in some, it will. Marc. >=20 > Wes George >=20 > 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 brian.e.carpenter@gmail.com Fri Dec 28 00:09:24 2012 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 7B85921F84CF for ; Fri, 28 Dec 2012 00:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.582 X-Spam-Level: X-Spam-Status: No, score=-101.582 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCn9R6ErvS8a for ; Fri, 28 Dec 2012 00:09:24 -0800 (PST) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id A613121F84C7 for ; Fri, 28 Dec 2012 00:09:23 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id z53so4910884wey.34 for ; Fri, 28 Dec 2012 00:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Wam0f3IWwMpsnscA5ue2e1PhM4oCpyxU348fxeVFJYU=; b=jULXRQ0o/s5Tz8ClhFckUL5vddVevJeP9+y2aI6Kd+xc6NPZq3JEUabbreNv5do8yR sKdNKmrqpIXTIHvmhnVQspZJAUhqCIBWUmxX4BGnEkKsEL2vBTuV+pLVRgvWUZtQblUv 2TQ7yxJ/UZDujHSUxaSqmw6pRwNJfkMivzKmQVVdr2yVVY8nA14ICNi7C8OkannFn/Es lIsFip0COCWXZjtwod+Kl/bDHl+Ba32jw62Etv1/VR1iDePJzDjgFDGL/AjvloJ/21nH wDDQKNE3ZzjGf+OViVQtwKfG1qHDP0gf/W7XjZbXSOR10pjiPDyC0Kqz7Oill3e1quk0 hltg== X-Received: by 10.194.173.195 with SMTP id bm3mr52215263wjc.32.1356682162602; Fri, 28 Dec 2012 00:09:22 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-72.as13285.net. [2.102.217.72]) by mx.google.com with ESMTPS id hu8sm38929828wib.6.2012.12.28.00.09.21 (version=SSLv3 cipher=OTHER); Fri, 28 Dec 2012 00:09:21 -0800 (PST) Message-ID: <50DD53BE.5080303@gmail.com> Date: Fri, 28 Dec 2012 08:09:34 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marc Blanchet References: <50D2C643.6050608@gmail.com> <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> <8C48B86A895913448548E6D15DA7553B7260BB@xmb-rcd-x09.cisco.com> <50DC8AED.9050009@bogus.com> <2671C6CDFBB59E47B64C10B3E0BD5923033A7B50DB@PRVPEXVS15.corp.twcable.com> <457F60F8-6319-40C2-8C50-A0F78A601470@viagenie.ca> In-Reply-To: <457F60F8-6319-40C2-8C50-A0F78A601470@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 08:09:24 -0000 On 27/12/2012 19:12, Marc Blanchet wrote: > Le 2012-12-27 =C3=A0 13:13, George, Wes a =C3=A9crit : =2E.. >> [WEG] The rest of the world (as in, those who don't regularly go for a= swim in the IETF process cistern) sees an RFC as an RFC. The status or c= lass of document matters very little as long as it is a product of consen= sus and not obsolete. So changing 4890 just for the sake of the status se= ems to me like busywork. Those who follow it now will continue to do so, = those who do not won't suddenly start simply because we change the status= =2E I would support a new BCP draft if it provides updated guidance from = what is already available and therefore updates or obsoletes the existing= document. >=20 > I respectfully disagree: > - I agree that changing status is not the most important move and maybe= not change anything in some circles. > - however, it is a good tool for a lot of people to better enforce good= practice. BCP is sending a stronger signal.=20 >=20 > So I agree we should aim at BCP for this one, even if in some circles, = it might not change anything; in some, it will. I agree with you both. I would suggest a two-stage process 1. Reclassify RFC 4890 as BCP. With a well-constructed writeup and IETF L= ast Call message, that could be done in a month. 2. Kick off an update document that will replace it when finished, which = among other things will have BCP boilerplate and SHOULD language. That will take some= time. Brian From joelja@bogus.com Sat Dec 29 19:31:45 2012 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 5E26721F88B0 for ; Sat, 29 Dec 2012 19:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-hisUYvJKQt for ; Sat, 29 Dec 2012 19:31:45 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id EC7DA21F88AC for ; Sat, 29 Dec 2012 19:31:44 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qBU3Vc0r014016 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 30 Dec 2012 03:31:39 GMT (envelope-from joelja@bogus.com) Message-ID: <50DFB597.1040902@bogus.com> Date: Sat, 29 Dec 2012 19:31:35 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Brian E Carpenter References: <50D2C643.6050608@gmail.com> <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> <8C48B86A895913448548E6D15DA7553B7260BB@xmb-rcd-x09.cisco.com> <50DC8AED.9050009@bogus.com> <2671C6CDFBB59E47B64C10B3E0BD5923033A7B50DB@PRVPEXVS15.corp.twcable.com> <457F60F8-6319-40C2-8C50-A0F78A601470@viagenie.ca> <50DD53BE.5080303@gmail.com> In-Reply-To: <50DD53BE.5080303@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 30 Dec 2012 03:31:39 +0000 (UTC) Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 03:31:45 -0000 On 12/28/12 12:09 AM, Brian E Carpenter wrote: > On 27/12/2012 19:12, Marc Blanchet wrote: >> Le 2012-12-27 à 13:13, George, Wes a écrit : > ... >>> [WEG] The rest of the world (as in, those who don't regularly go for a swim in the IETF process cistern) sees an RFC as an RFC. The status or class of document matters very little as long as it is a product of consensus and not obsolete. So changing 4890 just for the sake of the status seems to me like busywork. Those who follow it now will continue to do so, those who do not won't suddenly start simply because we change the status. I would support a new BCP draft if it provides updated guidance from what is already available and therefore updates or obsoletes the existing document. >> I respectfully disagree: >> - I agree that changing status is not the most important move and maybe not change anything in some circles. >> - however, it is a good tool for a lot of people to better enforce good practice. BCP is sending a stronger signal. >> >> So I agree we should aim at BCP for this one, even if in some circles, it might not change anything; in some, it will. > I agree with you both. I would suggest a two-stage process > > 1. Reclassify RFC 4890 as BCP. With a well-constructed writeup and IETF Last Call > message, that could be done in a month. > > 2. Kick off an update document that will replace it when finished, which among other > things will have BCP boilerplate and SHOULD language. That will take some time. if one is intent on producing a new document anyway it would seem simpler to just obsolete the old one in the process. e.g. 1 implies 2 is not imminent. > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Sun Dec 30 00:13:24 2012 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 879DF21F8767 for ; Sun, 30 Dec 2012 00:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.584 X-Spam-Level: X-Spam-Status: No, score=-101.584 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV7ph2V4Bgep for ; Sun, 30 Dec 2012 00:13:24 -0800 (PST) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id B361421F8734 for ; Sun, 30 Dec 2012 00:13:23 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id z2so5474212wey.32 for ; Sun, 30 Dec 2012 00:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Rt2UoQ9wRtuJFQX6NWN7IrWwcZOP0abWRLV//AFkgEU=; b=uKcujvm3RGUWXUHO+53CH/7WQ+QeFg5RreJjS4fYFDYH5IkvLAvgByGv/hOMk3llJe iIciz0oRS/OPGar7yv5Jtz1idoz+RixfdO3LTODH0QUhvKUeJQS90LivNtHR0l78PqlZ aWqU+ugDLUEJOEVvm5DzBY8kIAUfMR1TBZnbh84p6sAEplPjT744x2m0L7FoaZdND3EX EciJoSQ2rVDKenXYLwBzNB2Z1+13hkiRnyPysdlyAkRkez2nF+wpwXQLLPtDgYFY96xM Bnb5gkBn/PmFS87S0jTM+aBNI1piCbNpT31YnjLzWSw3z0qH4D8jqar8Nz/fK3MRArbG RUpg== X-Received: by 10.180.20.198 with SMTP id p6mr42423906wie.19.1356855202682; Sun, 30 Dec 2012 00:13:22 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-229.as13285.net. [2.102.217.229]) by mx.google.com with ESMTPS id ew4sm63434366wid.11.2012.12.30.00.13.20 (version=SSLv3 cipher=OTHER); Sun, 30 Dec 2012 00:13:21 -0800 (PST) Message-ID: <50DFF7B5.6010309@gmail.com> Date: Sun, 30 Dec 2012 08:13:41 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <50D2C643.6050608@gmail.com> <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> <8C48B86A895913448548E6D15DA7553B7260BB@xmb-rcd-x09.cisco.com> <50DC8AED.9050009@bogus.com> <2671C6CDFBB59E47B64C10B3E0BD5923033A7B50DB@PRVPEXVS15.corp.twcable.com> <457F60F8-6319-40C2-8C50-A0F78A601470@viagenie.ca> <50DD53BE.5080303@gmail.com> <50DFB597.1040902@bogus.com> In-Reply-To: <50DFB597.1040902@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 08:13:24 -0000 On 30/12/2012 03:31, joel jaeggli wrote: > On 12/28/12 12:09 AM, Brian E Carpenter wrote: >> On 27/12/2012 19:12, Marc Blanchet wrote: >>> Le 2012-12-27 =C3=A0 13:13, George, Wes a =C3=A9crit : >> ... >>>> [WEG] The rest of the world (as in, those who don't regularly go for= >>>> a swim in the IETF process cistern) sees an RFC as an RFC. The >>>> status or class of document matters very little as long as it is a >>>> product of consensus and not obsolete. So changing 4890 just for the= >>>> sake of the status seems to me like busywork. Those who follow it >>>> now will continue to do so, those who do not won't suddenly start >>>> simply because we change the status. I would support a new BCP draft= >>>> if it provides updated guidance from what is already available and >>>> therefore updates or obsoletes the existing document. >>> I respectfully disagree: >>> - I agree that changing status is not the most important move and >>> maybe not change anything in some circles. >>> - however, it is a good tool for a lot of people to better enforce >>> good practice. BCP is sending a stronger signal. >>> >>> So I agree we should aim at BCP for this one, even if in some >>> circles, it might not change anything; in some, it will. >> I agree with you both. I would suggest a two-stage process >> >> 1. Reclassify RFC 4890 as BCP. With a well-constructed writeup and >> IETF Last Call >> message, that could be done in a month. >> >> 2. Kick off an update document that will replace it when finished, >> which among other >> things will have BCP boilerplate and SHOULD language. That will take >> some time. > if one is intent on producing a new document anyway it would seem > simpler to just obsolete the old one in the process. e.g. 1 implies 2 > is not imminent. Well, fair enough, and there might be procedural issues about option 1 anyway. I'd much appreciate an effort by the authors of 4890 to achieve 2= as quickly as possible. Brian From marc.blanchet@viagenie.ca Sun Dec 30 07:20:57 2012 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 D795121F87EA for ; Sun, 30 Dec 2012 07:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Yodgy41NdQ3 for ; Sun, 30 Dec 2012 07:20:57 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 63BEE21F87B3 for ; Sun, 30 Dec 2012 07:20:57 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4B477403A4; Sun, 30 Dec 2012 10:20:54 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <50DFB597.1040902@bogus.com> Date: Sun, 30 Dec 2012 10:20:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50D2C643.6050608@gmail.com> <73ADCCB0-4EF9-4D0D-888A-16917A51EDD7@steffann.nl> <8C48B86A895913448548E6D15DA7553B7260BB@xmb-rcd-x09.cisco.com> <50DC8AED.9050009@bogus.com> <2671C6CDFBB59E47B64C10B3E0BD5923033A7B50DB@PRVPEXVS15.corp.twcable.com> <457F60F8-6319-40C2-8C50-A0F78A601470@viagenie.ca> <50DD53BE.5080303@gmail.com> <50DFB597.1040902@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1283) Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] ICMPv6 Filtering Recommendations to BCP? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2012 15:20:58 -0000 Le 2012-12-29 =E0 22:31, joel jaeggli a =E9crit : > On 12/28/12 12:09 AM, Brian E Carpenter wrote: >> On 27/12/2012 19:12, Marc Blanchet wrote: >>> Le 2012-12-27 =E0 13:13, George, Wes a =E9crit : >> ... >>>> [WEG] The rest of the world (as in, those who don't regularly go = for a swim in the IETF process cistern) sees an RFC as an RFC. The = status or class of document matters very little as long as it is a = product of consensus and not obsolete. So changing 4890 just for the = sake of the status seems to me like busywork. Those who follow it now = will continue to do so, those who do not won't suddenly start simply = because we change the status. I would support a new BCP draft if it = provides updated guidance from what is already available and therefore = updates or obsoletes the existing document. >>> I respectfully disagree: >>> - I agree that changing status is not the most important move and = maybe not change anything in some circles. >>> - however, it is a good tool for a lot of people to better enforce = good practice. BCP is sending a stronger signal. >>>=20 >>> So I agree we should aim at BCP for this one, even if in some = circles, it might not change anything; in some, it will. >> I agree with you both. I would suggest a two-stage process >>=20 >> 1. Reclassify RFC 4890 as BCP. With a well-constructed writeup and = IETF Last Call >> message, that could be done in a month. >>=20 >> 2. Kick off an update document that will replace it when finished, = which among other >> things will have BCP boilerplate and SHOULD language. That will take = some time. > if one is intent on producing a new document anyway it would seem = simpler to just obsolete the old one in the process. e.g. 1 implies 2 = is not imminent. I agree with Joel. Looks better to write new version of the document, = target as BCP and obsolete the previous one. That way there is an = incentive to move the new one forward and we accomplish all this with = the "least" amount of efforts (procedurally). Marc. >> Brian >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20