From nobody Fri Dec 1 01:09:58 2017 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 770FA127333 for ; Fri, 1 Dec 2017 01:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfmr1sydzCjZ for ; Fri, 1 Dec 2017 01:09:55 -0800 (PST) Received: from patsy.thehobsons.co.uk (ruthandcrusoe.plus.com [81.174.150.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40C6126D45 for ; Fri, 1 Dec 2017 01:09:55 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from simons-macbookpro.lan (unknown [80.229.10.150]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 141C31BC37 for ; Fri, 1 Dec 2017 09:09:03 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson X-Priority: Medium In-Reply-To: <1600f552856.edeb728d17491.789678005895704045@shytyi.net> Date: Fri, 1 Dec 2017 09:08:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <691BF030-AC2C-4E91-BAB8-0A5BD0DE8CD6@thehobsons.co.uk> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> <1600f552856.edeb728d17491.789678005895704045@shytyi.net> To: "v6ops@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 09:09:57 -0000 Dmytro Shytyi wrote: > v6opsers, what could be a nice motivation for such vendors as Qualcomm = to change their policy regarding the DHCPv6_PD support Someone saying something like "We want $very-large-number* of modems for = our next model of $device but it needs to pass DHCPv6 traffic - if your = modem can't do that we'll have to use $competitors device". Basically, = they'll change the design if they think there's a commercial gain from = doing it - and that means a large customer demanding the functionality. So there's that catch-22 issue. Phone manufacturers probably aren't = asking for it as they know there isn't demand because the cellular = networks don't support it. Network operators probably aren't supporting = it because they know there are very few devices that can use it. Modem = manufacturers are blocking the traffic because $reason and no-one is = demanding enough units for them to change the design. * Where very-large-number means "many millions".= From nobody Fri Dec 1 01:26:44 2017 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 314B5126D45 for ; Fri, 1 Dec 2017 01:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J85Ur-jxFhXj for ; Fri, 1 Dec 2017 01:26:40 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3DE124BAC for ; Fri, 1 Dec 2017 01:26:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vB19QZKb006091; Fri, 1 Dec 2017 10:26:35 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BF73D2044F0; Fri, 1 Dec 2017 10:26:35 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AEF5C201758; Fri, 1 Dec 2017 10:26:35 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vB19QZpd001613; Fri, 1 Dec 2017 10:26:35 +0100 From: Alexandre PETRESCU To: =?UTF-8?Q?Bj=c3=b8rn_Mork?= References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> <87D21F39-7C1D-4F08-A3EE-39882C8832E6@cisco.com> <87a7z37fny.fsf@miraculix.mork.no> Cc: "v6ops@ietf.org" , "Bernie Volz (volz)" Organization: CEA Message-ID: <362c66a5-9e4a-9da3-61a2-f5bcf6625ed7@cea.fr> Date: Fri, 1 Dec 2017 10:26:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <87a7z37fny.fsf@miraculix.mork.no> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080007000108020307010608" Archived-At: Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 09:26:43 -0000 This is a cryptographically signed message in MIME format. --------------ms080007000108020307010608 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: quoted-printable Bj=C3=B8rn, Le 30/11/2017 =C3=A0 20:03, Bj=C3=B8rn Mork a =C3=A9crit : >> On Nov 30, 2017, at 11:18 AM, Alexandre Petrescu >> > >> wrote: >>=20 >> v6opsers, >>=20 >> We succeeded in making DHCPv6 PD work natively on a cellular link.=20 >> I would claim it to be a first[*]. Packet dump available upon >> request. >>=20 >> The UE device is a Huawei E392u-12 USB dongle produced in 2011. >> It hosts a baseband processor Qualcomm model MDM9600 (or model >> MDM9200, or an Intel - not sure). >=20 > MDM9200. =20 Noted. I would like to ask you how do you know it's an MDM9200 in Huawei=20 E392u-12 USB dongle? Did you open the USB dongle and saw MDM9200=20 printed on a IC packaging? We could only open one cover and cant see=20 the IC; further intrusion seems to risk to break it mechanically. > Not that it matters much... Well it does matter, because it may mean progress or counter-progress. I am saying it's MDM9600 because Huawei announced the E392 to include a=20 Qualcomm MDM9600, in year 2011: > =E2=80=9CWe are pleased to collaborate with Qualcomm to announce the wo= rld=E2=80=99s > first multi-mode LTE TDD Dongle E392 based on Qualcomm=E2=80=99s MDM960= 0, > which is anticipated to be commercially available in the third > quarter of 2011,=E2=80=9D said [...] of Huawei Devices India. On the same MDM920x product line, the MDM9207 is more recent, probably=20 year 2016, whereas MDM9200 is surely year 2011. MDM9207 does block=20 DHCPv6 whereas MDM9200 does not block DHCPv6. It would be a counter-progress if newer chipsets blocked DHCPv6 whereas=20 older chipsets allowed it. That's why I suppose the E392 to be hosting a different Qualcomm product = line - the MDM9600. That MDM9600 product line would supposedly support=20 DHCPv6 throughout all its subsequent generations. But I really dont know whether E392 holds a MDM9200 or a MDM9600; so I=20 have to go again through this painful Qualcomm 'business case' via=20 Sierra and Orange, to ask them again to unblock multicast/547. If I knew precisely that E392 holds MDM9200 I could tell them: why=20 MDM9200 allows DHCPv6 whereas MDM9207 blocks it? Until then I can only tell them: why MDM9200-or-MDM9600 allows DHCPv6=20 whereas MDM9207 blocks it? (add to that the fact that some xda-developpers say that E392 is=20 probably hosting an Intel modem, rather than Qualcomm) >> It lets all standard DHCPv6 messaging through. The DHCPv6 client=20 >> 'odhcpv6' is running on linux laptop. >=20 > Can't help being a bit curious about the Linux driver used for this=20 > test? PPP? qmi_wwan? Something else? For this test we used ModemManager with mmcli command line. We did not=20 use pppd. The kernel modules were: qmi_wwan, cdc_wdm, option and=20 usb_wwan. It was first necessary to switch the dongle from "USB=20 storage" mode to "modem" mode. To achieve that it was necessary to use=20 a proprietary string. That proprietary string is found by first=20 sniffing the serial line on a Windows machine. This whole paragraph is=20 publicly documented by programmers in forums. > (crossing fingers for qmi_wwan :-) Yes :-) Alex >=20 >> DHCPv6-PD is blocked on other baseband processors, including >> Qualcomm and Balong versions; they are hosted by many smartphones, >> USB cellular dongles, mobile personal WiFi hotspots and IoT >> devices. A sample list is available upon request. >=20 > Yes, the "smarter" these things get, the harder it is to make them > work properly. >=20 >=20 > Bj=C3=B8rn >=20 > _______________________________________________ dhcwg mailing list=20 > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg >=20 --------------ms080007000108020307010608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Signature cryptographique S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC C2AwggWCMIIEaqADAgECAgIYEjANBgkqhkiG9w0BAQsFADA9MQswCQYDVQQGEwJGUjEMMAoG A1UECgwDQ0VBMSAwHgYDVQQDDBdDRUEgQUMgVXRpbGlzYXRldXIgMjAzMTAeFw0xNzExMjcx MTUzMThaFw0yMDExMjcxMTUzMThaMFUxCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANjZWExFDAS BgNVBAsMC1V0aWxpc2F0ZXVyMSIwIAYDVQQDDBlQRVRSRVNDVSBBbGV4YW5kcmUgMjIyMDQw MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxflZNm4uFO1gfpGFsdm8+ijK5FnS fr24rrT8KW0oz8cV8u+UZ55M/bqidvqSXGGz3C480T6DZsfXoTsvqD5ZLE+F8II6J2g5NU8J mKX95WafZuQo8DC2EnkDu2jH0kU58PGyJqzlQ1ThJw+E90C4yg55q5ekRRv13L7W4D38+eO6 2LLQyplKiyjXJRFnrYPCQWKdmaoa3+gXm88N0z9SH1VnKDB7nN0WKcgkB8xFFW9ShkDriTj4 WOtBlX5I49L6nc2f5jgRR7ur63vWwWV57guJDYgdbciTIMsoanyOMkblfZko71HlcYOQcext cIzx7W14tLdo5Lbk5sbTLTPCUwIDAQABo4ICcjCCAm4wHQYDVR0OBBYEFJiCut4KQg9+Gt1J iu2nte1qatj0MB8GA1UdIwQYMBaAFOEcbJodbegbsvFP/cZ0LCdXBYhzMIHIBgNVHSAEgcAw gb0wgboGCisGAQQB4GABBgcwgaswJQYIKwYBBQUHAgEWGWh0dHA6Ly93d3ctaWdjLmNlYS5m ci9wYy8wgYEGCCsGAQUFBwICMHUwDRYDQ0VBMAYCAQICAQAaZFZvdXMgZGV2ZXogYWNjZXB0 ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBjZSBj ZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAkBgNVHREEHTAbgRlhbGV4YW5kcmUucGV0cmVzY3VAY2VhLmZyMFEGA1Ud HwRKMEgwRqBEoEKGQGh0dHA6Ly9jcmwtYWMtdXRpbGlzYXRldXIuY2VhLmZyL2NybC9jZWFf YWNfdXRpbGlzYXRldXJfMjAzMS5jcmwwcwYJYIZIAYb4QgENBGYWZFZvdXMgZGV2ZXogYWNj ZXB0ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBj ZSBjZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwUAYIKwYBBQUHAQEERDBCMEAGCCsG AQUFBzAChjRodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvY2VhX2FjX3V0aWxpc2F0ZXVyXzIw MzEuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQC77Z707Ko1uZGK3utBHUQUUyTD4pRjmFxFozU2 kwdk6a8hdHTaaRqjPSUIbfeoZVpZCynd12VynalWcoXM40Bf+bhMN3pAavULka7+oAEQyYuI 7OQ8dE/t3R43Ai8dx0npk+ziPQrlD7tAgMsK8Qd+V7ZhUI0A1ANJXWzZ7DYV6jR4t9nwxlsk Kll2PaD+hTIiP86YVsiHMiu0ZhRGrYJf/U1myMQc28b4LdTofpwh22z8DLHlFoGjGipwYbpb oFn998AOsc2fvujB0Y+AahlKK8lecqOTXJNQaRUrE1dl/n2Xu8GK3KIRtcoo7QTDOTzx/BiN 5EC8XdsqNMRXmc1GMIIF1jCCA76gAwIBAgIBCTANBgkqhkiG9w0BAQsFADBeMQswCQYDVQQG EwJGUjEMMAoGA1UECgwDQ0VBMRcwFQYDVQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwC QUMxGzAZBgNVBAMMEkNFQSBBQyBSYWNpbmUgMjA0MTAeFw0xNjA0MTkwNzM0NTNaFw0zMTA0 MTYwNzM0NTNaMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBB QyBVdGlsaXNhdGV1ciAyMDMxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvWDF ixM71KL9p38YSLTYgXRTceZWAD0RSg7NylBGPXNHYbceuGKDhRIeX58FIi+JiVFFejFI6jpE impm3MgsXQ5O08clieLLBNCjVzpAMPTO5lXuz0j28ey5AVPwhEw7ngUCtmHaWh8v1eY6xrLV C/porFjHycFbd4oj6QLfyghoo/RXWglYPNjilkCBrRe+jKxM3QYYVD6rouvGrF58SlpGCfwX FA88OcYC24kH8YOOYvh8Ld/p+ty7QUiDq53YmVZ5iDUc3pt3r9pN61zJ83FPEhZbC8+KHDTb D0TXaot2No4u8wk0s0jBpicVN4hxfS+LiFcTsFmsorDW6L7GIwIDAQABo4IBvjCCAbowDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU4Rxsmh1t6Buy8U/9xnQsJ1cFiHMwHwYDVR0jBBgw FoAUoBGJ+Jq/poSxKQc3U0Htl5VCex0wgcgGA1UdIASBwDCBvTCBugYKKwYBBAHgYAEGBzCB qzAlBggrBgEFBQcCARYZaHR0cDovL3d3dy1pZ2MuY2VhLmZyL3BjLzCBgQYIKwYBBQUHAgIw dTANFgNDRUEwBgIBAgIBABpkVm91cyBkZXZleiBhY2NlcHRlciBsYSBwb2xpdGlxdWUgZGUg Y2VydGlmaWNhdGlvbiBhdmFudCBkJ3V0aWxpc2VyIGNlIGNlcnRpZmljYXQsIGNmLiB3d3ct aWdjLmNlYS5mcjAOBgNVHQ8BAf8EBAMCAQYwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2Ny bC1hYy1yYWNpbmUuY2VhLmZyL2NybC9hYy1yYWNpbmUtMjA0MS5jcmwwRwYIKwYBBQUHAQEE OzA5MDcGCCsGAQUFBzAChitodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvYWMtcmFjaW5lLTIw NDEuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQALtUqrZEfol/oEtIOlM3SaHCPHblVt8TdY88IB 3qCpg5lJ8rWU7g8jAsc0moYYor0hrvb17XjXECYL76MOJBCQYEKfWnkTYqAyMTsKee+kK8Xw 5P8wzPPjXA3tUvRm8oHEGYcSfLEzdj+UT+F+E4MnkV1nUOCEJq2Krx+lu1IJQJRCbjUQF+ES ICwTDQE7FHzGGKVsGOEjkbYhDS/+4r5GPbc983y5d94S0ISYmM1klOSeRNGelcnl0fJbH0zs 1y8+YJWg3gWL1j7aNo+sQQCrPrYQnmufAm3HQr42+u0AbFvOX5XKwF1YAx7XpJWuUGeXkjqx 8xIWisShEc/S+Gm4mdKcUgym5C7gkA0nzbmBIJI3iSLRqk/m2Re7R5vC3fF3uyfT9mGeAnNa E9b7ZkBzhrSfFToylbvqnAYvxVcYFCE1XhVMHxKvRiiW9L/u9vHuAbTRaXBFzObrXF6UohLR XNqJKKaPYkRLgrVm6b303Ogp50u6DiSgvI4Dh7x9K9IqpJ/+csqdXpoVdhQjhcA5JZRNrv3q 0zVf/Q93GT3VHOgaeMkEa9Sn30x4GmZfuNon/zSagJZkLO72K3wa6XQbGf8MZP/QtSMGPzrN eVUgp4H6l9hcQINVHmimTrcZa7/22K0FD56epY/OqAXwIWOb9i+jdDIoW5c5pW+/BDDasTGC AvMwggLvAgEBMEMwPTELMAkGA1UEBhMCRlIxDDAKBgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VB IEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMA0GCWCGSAFlAwQCAQUAoIIBgTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEyMDEwOTI2MzVaMC8GCSqGSIb3 DQEJBDEiBCD4ggv/DLF26JXmrFZGym2r6pWy5MaKvf2GHPNGZh+PIDBSBgkrBgEEAYI3EAQx RTBDMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBBQyBVdGls aXNhdGV1ciAyMDMxAgIYEjBUBgsqhkiG9w0BCRACCzFFoEMwPTELMAkGA1UEBhMCRlIxDDAK BgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEAu1tW9ryfYylRkY2RBdgPybCUPj3V2ZADtHtSBZDby+s4y7I6P55p 7+NSgfIT//EspVB8uaci1BELp+M1Un6IvoqKwu6vedZUWRWkTR1QR/XvZBtX0bSTjtBwmtXB VFDboarUwphfFaceksuXFUr6tlLx863NTiHh/JmvUei2rLXNDF3G2S5U6SfyOz13XLKmUtb/ isgGleyBH69+NtYgGOvon9euZf4uPS011qIQAIHTXGGQwXju4QBxvr1HBZTkX7Pbqkvi6fvA dKGgeJlRlqOPYhC4qGkpkzHwL0nzFm9OATOj4zeF1M4Vov5E/qR2gkEF7KnLVLTH7L36z0Yr xQAAAAAAAA== --------------ms080007000108020307010608-- From nobody Fri Dec 1 02:00:15 2017 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 E1D8B127333 for ; Fri, 1 Dec 2017 02:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mork.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ePPeOxGBMS0 for ; Fri, 1 Dec 2017 02:00:10 -0800 (PST) Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5DF12702E for ; Fri, 1 Dec 2017 02:00:09 -0800 (PST) Received: from miraculix.mork.no ([IPv6:2a02:2121:2c3:2a22:34c0:14ff:fe74:3b2f]) (authenticated bits=0) by canardo.mork.no (8.15.2/8.15.2) with ESMTPSA id vB19xtv1003441 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Dec 2017 10:59:56 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1512122397; bh=w8Ed73WxMXeRwm3fJCMqb0RexM7g8OJci2Rm+xDjZx0=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=A81Q5Xr7v6MNPgv8jSOLvnX+6MiUtP5GXQ1CNIl+crDo9Jc4cL5gcxj2ib+k9L8ys bP4bHD41oJRThxNbMB9wvjslunwls8OHqsxjKz5CH83JwkJlOM5SznxySmcmCgVPzS yEArbQ/fZwxRQoBWVvpgQYfe6YoLXi4vi7oxjj1Q= Received: from bjorn by miraculix.mork.no with local (Exim 4.89) (envelope-from ) id 1eKi6o-0004MX-DS; Fri, 01 Dec 2017 10:59:50 +0100 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: Alexandre PETRESCU Cc: "v6ops\@ietf.org" , "Bernie Volz \(volz\)" Organization: m References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> <87D21F39-7C1D-4F08-A3EE-39882C8832E6@cisco.com> <87a7z37fny.fsf@miraculix.mork.no> <362c66a5-9e4a-9da3-61a2-f5bcf6625ed7@cea.fr> Date: Fri, 01 Dec 2017 10:59:50 +0100 In-Reply-To: <362c66a5-9e4a-9da3-61a2-f5bcf6625ed7@cea.fr> (Alexandre PETRESCU's message of "Fri, 1 Dec 2017 10:26:35 +0100") Message-ID: <877eu66a5l.fsf@miraculix.mork.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.99.2 at canardo X-Virus-Status: Clean Archived-At: Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 10:00:13 -0000 Alexandre PETRESCU writes: >> MDM9200.=20=20 > > Noted. > > I would like to ask you how do you know it's an MDM9200 in Huawei > E392u-12 USB dongle? Did you open the USB dongle and saw MDM9200 > printed on a IC packaging? We could only open one cover and cant see > the IC; further intrusion seems to risk to break it mechanically. Mostly because the E392u-12 is a European variant and the MDM9200 is the chipset of that generation with support for the European LTE bands. You can also get a hint from the Qualcomm baseband revision: root@miraculix:/tmp# qmicli -d /dev/cdc-wdm1 --dms-get-revision [/dev/cdc-wdm1] Device revision retrieved: Revision: 'M9200B-SCAQDBZD-3.0.350025T 1 [Aug 11 2011 02:00:00]' > I am saying it's MDM9600 because Huawei announced the E392 to include > a Qualcomm MDM9600, in year 2011: >> =E2=80=9CWe are pleased to collaborate with Qualcomm to announce the wor= ld=E2=80=99s >> first multi-mode LTE TDD Dongle E392 based on Qualcomm=E2=80=99s MDM9600, >> which is anticipated to be commercially available in the third >> quarter of 2011,=E2=80=9D said [...] of Huawei Devices India. I believe there were many variants of the E392. Some of those intended for other markets than Europe were probably based on MDM9600. Huawei can tell you more. > On the same MDM920x product line, the MDM9207 is more recent, probably > year 2016, whereas MDM9200 is surely year 2011. MDM9207 does block > DHCPv6 whereas MDM9200 does not block DHCPv6. These are different chipset generations despite the similar names. The MDM9207 is much closer related to e.g. the MDM9235 than to the MDM9200. Marketing names means nothing. It's just a name. > It would be a counter-progress if newer chipsets blocked DHCPv6 > whereas older chipsets allowed it. Well, that's progress for you :-) I don't think they intentionally block anything, but they often mess up when trying to add more intelligence in the firmware. Note that these "modems" are running Linux themselves and provide bridge or router function between the host USB connection and the actual radio interface. Ideally. Most of the time it's neither a bridge nor a modem, but something in-between. Which is where you get into trouble... One possible explanation could be that newer firmwares try to handle DHCPv6 themselves, intercepting any DHCPv6 request from the host. > That's why I suppose the E392 to be hosting a different Qualcomm > product line - the MDM9600. That MDM9600 product line would > supposedly support DHCPv6 throughout all its subsequent generations. > > But I really dont know whether E392 holds a MDM9200 or a MDM9600; so I > have to go again through this painful Qualcomm 'business case' via > Sierra and Orange, to ask them again to unblock multicast/547. > > If I knew precisely that E392 holds MDM9200 I could tell them: why > MDM9200 allows DHCPv6 whereas MDM9207 blocks it? > > Until then I can only tell them: why MDM9200-or-MDM9600 allows DHCPv6 > whereas MDM9207 blocks it? MDM9200 and MDM9600 are mostly identical from a software point of view. The MDM9207 is very different. Qualcomm can probably tell you if it is possible to configure an MDM9207 firmware for DHCPv6 pass through. Bj=C3=B8rn From nobody Fri Dec 1 02:00:52 2017 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 1B881127B57 for ; Fri, 1 Dec 2017 02:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLieiJ2PNvn9 for ; Fri, 1 Dec 2017 02:00:47 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA3D12896F for ; Fri, 1 Dec 2017 02:00:47 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vB1A0jLk107581 for ; Fri, 1 Dec 2017 11:00:45 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 36448204707 for ; Fri, 1 Dec 2017 11:00:45 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2CF89204670 for ; Fri, 1 Dec 2017 11:00:45 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vB1A0i03027025 for ; Fri, 1 Dec 2017 11:00:45 +0100 To: v6ops@ietf.org References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> <1600f552856.edeb728d17491.789678005895704045@shytyi.net> <691BF030-AC2C-4E91-BAB8-0A5BD0DE8CD6@thehobsons.co.uk> From: Alexandre Petrescu Message-ID: <5e16a466-a17c-3dfe-5fdf-565a6e84bb0f@gmail.com> Date: Fri, 1 Dec 2017 11:00:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <691BF030-AC2C-4E91-BAB8-0A5BD0DE8CD6@thehobsons.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 10:00:50 -0000 Le 01/12/2017 à 10:08, Simon Hobson a écrit : > Dmytro Shytyi wrote: > >> v6opsers, what could be a nice motivation for such vendors as >> Qualcomm to change their policy regarding the DHCPv6_PD support > > Someone saying something like "We want $very-large-number* of modems > for our next model of $device but it needs to pass DHCPv6 traffic - > if your modem can't do that we'll have to use $competitors device". > Basically, they'll change the design if they think there's a > commercial gain from doing it - and that means a large customer > demanding the functionality. > > So there's that catch-22 issue. Phone manufacturers probably aren't > asking for it as they know there isn't demand because the cellular > networks don't support it. Network operators probably aren't > supporting it because they know there are very few devices that can > use it. Modem manufacturers are blocking the traffic because $reason > and no-one is demanding enough units for them to change the design. Some operator does support DHCPv6-PD on PGW to UE. Some modem and dongle do support DHCPv6-PD on UE. Some prototypes shown it to work ok. Further deployment needs removal of DHCPv6 blocking. $reason would yield value :-) Alex > > * Where very-large-number means "many millions". > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Dec 1 02:24:00 2017 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 93395127337 for ; Fri, 1 Dec 2017 02:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOlMXTCGt72z for ; Fri, 1 Dec 2017 02:23:57 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098BB127333 for ; Fri, 1 Dec 2017 02:23:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vB1ANrnP032679; Fri, 1 Dec 2017 11:23:53 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 54DB820519F; Fri, 1 Dec 2017 11:23:53 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4559C204EAA; Fri, 1 Dec 2017 11:23:53 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vB1ANr2h014526; Fri, 1 Dec 2017 11:23:53 +0100 To: =?UTF-8?Q?Bj=c3=b8rn_Mork?= Cc: "v6ops@ietf.org" , "Bernie Volz (volz)" References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> <87D21F39-7C1D-4F08-A3EE-39882C8832E6@cisco.com> <87a7z37fny.fsf@miraculix.mork.no> <362c66a5-9e4a-9da3-61a2-f5bcf6625ed7@cea.fr> <877eu66a5l.fsf@miraculix.mork.no> From: Alexandre Petrescu Message-ID: <1dc3efc1-548d-ce01-833d-b7f7e749856d@gmail.com> Date: Fri, 1 Dec 2017 11:23:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <877eu66a5l.fsf@miraculix.mork.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr Archived-At: Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 10:23:58 -0000 Le 01/12/2017 à 10:59, Bjørn Mork a écrit : > [...]. We will check the version as you indicated. >> It would be a counter-progress if newer chipsets blocked DHCPv6 >> whereas older chipsets allowed it. > Well, that's progress for you :-) > > I don't think they intentionally block anything, but they often mess up > when trying to add more intelligence in the firmware. I can agree.  But adding more intelligence should not hamper existing features like DHCPv6-PD. All should co-exist there. > Note that these > "modems" are running Linux themselves and provide bridge or router > function between the host USB connection and the actual radio > interface. Ideally. Most of the time it's neither a bridge nor a modem, > but something in-between. Which is where you get into trouble... > > One possible explanation could be that newer firmwares try to handle > DHCPv6 themselves, intercepting any DHCPv6 request from the host. Could be.  To that, the answer is that modem that intercepts DHCPv6 request and generates new ones is harmful. Not only it theoretically violates layering but may lead to situations where software version after version leads to effective blocking of DHCPv6-PD. The initial intention was good (support DHCP) and the end result is blocking DHCP. What should be done in modems is to let everything IP through; modem is at layer2, not layer3. > > >> That's why I suppose the E392 to be hosting a different Qualcomm >> product line - the MDM9600. That MDM9600 product line would >> supposedly support DHCPv6 throughout all its subsequent generations. >> >> But I really dont know whether E392 holds a MDM9200 or a MDM9600; so I >> have to go again through this painful Qualcomm 'business case' via >> Sierra and Orange, to ask them again to unblock multicast/547. >> >> If I knew precisely that E392 holds MDM9200 I could tell them: why >> MDM9200 allows DHCPv6 whereas MDM9207 blocks it? >> >> Until then I can only tell them: why MDM9200-or-MDM9600 allows DHCPv6 >> whereas MDM9207 blocks it? > MDM9200 and MDM9600 are mostly identical from a software point of view. > The MDM9207 is very different. Qualcomm can probably tell you if it is > possible to configure an MDM9207 firmware for DHCPv6 pass through. I will ask again. They can tell indeed whether it is possible.  What they seem to _not_ want to do is to do it themselves.  It's not clear though whether they'd allow me (or a programmer with me)  to modify the firmware to let DHCPv6 pass through. Alex > > > Bjørn > From nobody Fri Dec 1 02:50:08 2017 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 D1953127735 for ; Fri, 1 Dec 2017 02:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCjgNjLdYkEX for ; Fri, 1 Dec 2017 02:50:05 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3971C127333 for ; Fri, 1 Dec 2017 02:50:05 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vB1Ao3OH002256 for ; Fri, 1 Dec 2017 11:50:03 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 89226207BEA for ; Fri, 1 Dec 2017 11:50:03 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 76F84201669 for ; Fri, 1 Dec 2017 11:50:03 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vB1Ao3gm001796 for ; Fri, 1 Dec 2017 11:50:03 +0100 To: v6ops@ietf.org References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> <87D21F39-7C1D-4F08-A3EE-39882C8832E6@cisco.com> <87a7z37fny.fsf@miraculix.mork.no> <362c66a5-9e4a-9da3-61a2-f5bcf6625ed7@cea.fr> <877eu66a5l.fsf@miraculix.mork.no> <1dc3efc1-548d-ce01-833d-b7f7e749856d@gmail.com> From: Alexandre Petrescu Message-ID: <20583ac4-fcce-f93c-9416-8657d603160e@gmail.com> Date: Fri, 1 Dec 2017 11:50:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1dc3efc1-548d-ce01-833d-b7f7e749856d@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 10:50:07 -0000 Le 01/12/2017 à 11:23, Alexandre Petrescu a écrit : > > Le 01/12/2017 à 10:59, Bjørn Mork a écrit : >> [...]. > > We will check the version as you indicated. Our USB dongle Huawei E392u-12 yields: > [/dev/cdc-wdm0] Device revision retrieved: Revision: > 'M9200B-SCAQWBZD-3.3.330160T 1 [Sep 07 2012 04:00:00]' It says "M9200B"; I suppose that means the baseband processor is "MDM9200". I will use that in my conversations, thank you very much. Alex From nobody Fri Dec 1 05:03:51 2017 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 A88AE127337 for ; Fri, 1 Dec 2017 05:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krsUMAae9bXJ for ; Fri, 1 Dec 2017 05:03:48 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1399D126CD8 for ; Fri, 1 Dec 2017 05:03:47 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vB1D3hIk003538; Fri, 1 Dec 2017 14:03:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2C0082046FD; Fri, 1 Dec 2017 14:03:43 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 11F3B207CB8; Fri, 1 Dec 2017 14:03:43 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vB1D3ghN014638; Fri, 1 Dec 2017 14:03:42 +0100 To: =?UTF-8?Q?Bj=c3=b8rn_Mork?= Cc: "v6ops@ietf.org" , "Bernie Volz (volz)" References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> <87D21F39-7C1D-4F08-A3EE-39882C8832E6@cisco.com> <87a7z37fny.fsf@miraculix.mork.no> <362c66a5-9e4a-9da3-61a2-f5bcf6625ed7@cea.fr> <877eu66a5l.fsf@miraculix.mork.no> From: Alexandre PETRESCU Organization: CEA Message-ID: Date: Fri, 1 Dec 2017 14:03:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <877eu66a5l.fsf@miraculix.mork.no> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000809050302040407050507" Archived-At: Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok - intermediary entities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 13:03:51 -0000 This is a cryptographically signed message in MIME format. --------------ms000809050302040407050507 Content-Type: multipart/alternative; boundary="------------F601CC03C158E99FC09DB999" Content-Language: fr This is a multi-part message in MIME format. --------------F601CC03C158E99FC09DB999 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable For the DHCPv6-PD successful working, the address used in forming the=20 Solicit of 'odhcpv6' on laptop is the same address as in the Solicit=20 that PGW receives. So there is no address translation, like a NAT would do. I did not bother to compare the each field of the contents of DHCPv6=20 messages, but the packet dumps at laptop and at PGW are available. Because of this I dont think there is any proxying or translation=20 between the CPU that executes 'odhcpv6' and the PGW.=C2=A0 That looks goo= d. Le 01/12/2017 =C3=A0 10:59, Bj=C3=B8rn Mork a =C3=A9crit=C2=A0: > [...] > I don't think they intentionally block anything, but they often mess up= > when trying to add more intelligence in the firmware. Note that these > "modems" are running Linux themselves and provide bridge or router > function between the host USB connection and the actual radio > interface. Ideally. Most of the time it's neither a bridge nor a modem= , > but something in-between. Which is where you get into trouble... In RFC terms this is very much about a "Host-IMP" interface.=C2=A0=C2=A0 = Host is=20 the Host as we know it, and IMP stands for "Interface Message Processor".= This intermediary proxying entities is indeed what can create problems. To clarify it, it would be advantageous to use common terminology. These publicly available block sch=C3=A9mas show what you call firmware, = modem, bridge, router, radio interface. Many call them "Baseband Processor",=C2=A0 "Baseband signal processing", = for=20 what I call modem, then "Radio frequency module", "PMIC" for what I=20 never call, and finally=C2=A0 "Application system", "ARM", "Application=20 processor", or laptop, for the entity that executes the DHCP client.=C2=A0= =20 Some also use the term 'chipset' but that's really unclear. 3GPP uses the term "User Equipment", UE. Some other SDO uses the term "Mobile Terminal", MT. For example: Alex > > One possible explanation could be that newer firmwares try to handle > DHCPv6 themselves, intercepting any DHCPv6 request from the host. > > >> That's why I suppose the E392 to be hosting a different Qualcomm >> product line - the MDM9600. That MDM9600 product line would >> supposedly support DHCPv6 throughout all its subsequent generations. >> >> But I really dont know whether E392 holds a MDM9200 or a MDM9600; so I= >> have to go again through this painful Qualcomm 'business case' via >> Sierra and Orange, to ask them again to unblock multicast/547. >> >> If I knew precisely that E392 holds MDM9200 I could tell them: why >> MDM9200 allows DHCPv6 whereas MDM9207 blocks it? >> >> Until then I can only tell them: why MDM9200-or-MDM9600 allows DHCPv6 >> whereas MDM9207 blocks it? > MDM9200 and MDM9600 are mostly identical from a software point of view.= > The MDM9207 is very different. Qualcomm can probably tell you if it is > possible to configure an MDM9207 firmware for DHCPv6 pass through. > > > Bj=C3=B8rn > --------------F601CC03C158E99FC09DB999 Content-Type: multipart/related; boundary="------------477E8FB3A06F26D262C6CA65" --------------477E8FB3A06F26D262C6CA65 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable For the DHCPv6-PD successful working, the address used in forming the Solicit of 'odhcpv6' on laptop is the same address as in the Solicit that PGW receives.

So there is no address translation, like a NAT would do.

I did not bother to compare the each field of the contents of DHCPv6 messages, but the packet dumps at laptop and at PGW are available.
Because of this I dont think there is any proxying or translation between the CPU that executes 'odhcpv6' and the PGW.=C2=A0 That looks= good.

Le 01/12/2017 =C3=A0 10:59, Bj=C3=B8rn Mork a =C3=A9crit=C2=A0:
[...] 
I don't think they intentionally block anything, but=
 they often mess up
when trying to add more intelligence in the firmware.  Note that these
"modems" are running Linux themselves and provide bridge or router
function between the host USB connection and the actual radio
interface. Ideally.  Most of the time it's neither a bridge nor a modem,
but something in-between.  Which is where you get into trouble...

In RFC terms this is very much about a "Host-IMP" interface.=C2=A0=C2= =A0 Host is the Host as we know it, and IMP stands for "Interface Message Processor".

This intermediary proxying entities is indeed what can create problems.

To clarify it, it would be advantageous to use common terminology.
These publicly available block sch=C3=A9mas show what you call firmwa= re, modem, bridge, router, radio interface.

Many call them "Baseband Processor",=C2=A0 "Baseband signal processin= g", for what I call modem, then "Radio frequency module", "PMIC" for what I never call, and finally=C2=A0 "Application system", "ARM", "Application processor", or laptop, for the entity that executes the DHCP client.=C2=A0 Some also use the term 'chipset' but that's really= unclear.

3GPP uses the term "User Equipment", UE.

Some other SDO uses the term "Mobile Terminal", MT.


For example:
3D""
3D""



Alex


One possible explanation could be that newer firmwares try to handle
DHCPv6 themselves, intercepting any DHCPv6 request from the host.



That's why I suppose the E392 to be hosting a diff=
erent Qualcomm
product line - the MDM9600.  That MDM9600 product line would
supposedly support DHCPv6 throughout all its subsequent generations.

But I really dont know whether E392 holds a MDM9200 or a MDM9600; so I
have to go again through this painful Qualcomm 'business case' via
Sierra and Orange, to ask them again to unblock multicast/547.

If I knew precisely that E392 holds MDM9200 I could tell them: why
MDM9200 allows DHCPv6 whereas MDM9207 blocks it?

Until then I can only tell them: why MDM9200-or-MDM9600 allows DHCPv6
whereas MDM9207 blocks it?

MDM9200 and MDM9600 are mostly identical from a software point of view.
The MDM9207 is very different. Qualcomm can probably tell you if it is
possible to configure an MDM9207 firmware for DHCPv6 pass through.


Bj=C3=B8rn

--------------477E8FB3A06F26D262C6CA65 Content-Type: image/png; name="mllbbkdnkjpangmp.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="mllbbkdnkjpangmp.png" iVBORw0KGgoAAAANSUhEUgAAAZAAAAFrCAIAAABwiEhBAAAa2UlEQVR4nO2dO47dOrZAK9Bk Gnjp69QzqMxjsHNnB2gUNIv2BCq5seNb8UXPwhO4NQJ1oC5iF3+i+P+shQ1DRyIpiZJWkTyU z9MBADAIT60PAG7w5MCV4LIEuenl5eUyO0BbuCkHw2qoy00hCfyJAXqAO3IwrBp6eXkxN136 6zB8598RQHO4IwcjvEmFsGA+uCMHwyMsVzJP4lslADSHO3Iwngw8Ccz11sSuveQ9coB0uCkH I7CFdXx863cOb2lrTlzKMzMCdALCGoxbbZ/LxIENMYBO4NYcjPRxq+j0AM3h7hwMq2Ws0xqO q/6jtubsCXp2BNAc7sjB0DziUdKtjwfTGmAEuCNH4smBK4E/e0jhxU8J4A7ckQAwDAgLAIYB YQHAMCAsABgGhAUAw4CwAGAYEBYADAPCAoBhQFgAMAwICwCGAWEBwDAgLAAYBoQFAMOAsABg GBAWAAwDwgKAYUBYAEXYBNZNIStD9hJ/iAOCsACKIFWilvd93/ddLasE53qrffYPZK5939/e 3s4scpOW8kyT+cSagrAAimAVlqtBdK63NrvMNOfCaSJrySqllmYCEBZAEaxdwrvCMsuRjbXj Slj+nY4IwgIogss+nsSBLazzI8ICgGz43eRfsCamS3ggLIBCeDTh6ifK3p8aLNc6g6aMzOzq o2sgf1wQFsBIhAtoMlWdICyAkUBYAABjgLBgUeJmlkNbEBYsCsIaEYQVyQ4dkHIFU4S17/vz 8/cVIrGSs4OwItm27fWvv4nXv/5uVRUN20f7vv/8+Z8VAmFNAsJCWCsEwpoEhIWwVgiENQkI a3RhJY5hNVcJwoIbICyEtUIgrElAWAhrhUBYk4CwENYKgbAmAWGNLqwUEFYrEFYkCAthrRAI axIQ1ujCokuIsBYCYSGsFQJhTQLCQlgrBMKahIxP6ddvj1tqCNy1SlZaKIMKKwWE1QqEFUmW p/T8I39XWL15BGFNHAhrEkoISzWgtMaR66NWgvoNAnNZJjY/Jp7LoMKiS4iwFqKQsEw3SelY /fX6199fvz00i11qzroGYQWCsFqBsCJJf0pDDGKVjmtwSmsxIazLK4iwENYqZBGWSzERwqKF FXEFERbCWoXs4z7mAJNaeSks2SWkhRV+BREWwlqFQsKSCy5DaaLZPg+6u2TncuKywkoBYbUC YUVS4im1WqyJCxCWH4TVCoQVCcJqfpB0CREWhDKEShCW/woiLIS1CggLYa0QCGsSOhFWD4cx qLBSQFitQFiR9GAKhNXq6iOsViCsSIo+pXL+gTkLYTN4dUxZUCvD369eR1h0CRHWQpR7Ss1p VpqDzK3SR9ZJWAjLegURFsJahQotLPXRfLdZs9iZwNMuQ1jWK4iwENYqVHhK1S40YcmtLh8h rJAriLAQ1ipU6xK+2np8atnTJURYl1cQYSGsVajQJZQtLNdW/6A7wioEwmoFwoqk5lNaVDcI KwKE1QqEFQnCGl1YdAkR1kK0eko7DIQ1cSCsSUBYCGuFQFiTgLBGF1YKCKsVCCsShIWwVgiE NQkIa3Rh0SVEWAuBsBDWCoGwJgFhIawVAmFNAsJCWCsEwpoEhDW6sFJAWK1AWJEgLIS1QiCs SUBYowuLLiHCWogsT+n5zHz99hg6ENbEgbAmIaOwmjztecWBsGYNhDUJCAthrRAIaxIQ1ujC SgFhtQJhRYKwENYKgbAmAWHlEtZmo4Kw6BIirIVAWLmEZZaDsPoJhDUJTYQV0QapICCENXEg rEloJaxbmkBY/iuIsBDWKvQjrG3b1K9UyPaXXFY/Da3tWhZy1xfZhXW3QhKFlQLCagXCiqRD YZlb1RppNDOlpqqGwrq731ZXH2G1AmFF0s8YlrVlFC4ss4RFhEWXEGEtRPMWVi5hyZcBmwjL +n4iwuokENYkdCisV9EE08rveQxLHsmtn4xFWAgLQmkirD4jXVhqAWH1FghrEhDW6MJKAWG1 AmFFgrByCetVjJ0hrN4CYU0CwsolrE1Al7C3QFiTgLByCUsGwuotENYk9Cms8NIy7jdjC0v7 7hJhNQ+ENQkIK6Ow1DItrN4CYU1CV8KyNk8uP+YyV6teLYPuCAtC6UdYmpJMiWiD2ZuYzp7r LHI5iG8JewuENQn9COv14+0W6Q7tZ7hMEWwfPy/WXFjyUP/v/7/wak5XgbAmoR9h+VtY58rO W1iqu8oYVm+BsCahH2HJcsxBK+mmPsewZHaE1VsgrEnoSlhtA2FNHAhrEhDW6MJKAWG1AmFF grByCeu10RhWCgirFQgrEoSVUVjR+028gnQJEdYqIKxcwto+g7C6CoQ1CZMJK+UwMp4Cg+69 BcKahMmElXgWCGvWQFiTUEFYav6UnMWuTbNyfbxMYH5U/++7WYjfSoOOYaWAsFqBsCKpI6xN /DSD5heZzDWR3ZVA23pZSIhYEyvBdCXC6iEQ1iRUa2FJYVkdsXlfFVSv5mm/oKV9DLFeIWHJ oEvYWyCsSWjSwgoRFi2s8CuIsBDWKlRrYW22X6KXz7n142UC86MpLHmEtLAkCKsVCCuSml3C HmI+YaWAsFqBsCJZQViBPbWMXUKE1VsgrEmoIKxRotUpICyEBaEgrNGFVX8Ma9u28MTPz9/D s6hkt3aBsBYCYSGsCFuFC+UUVgkVIqwVQVgIK0VYz8/fzwPQtsoEWtNJbpWJ5SYtvSrEzI6w 1mIDAcK6K6zNrapzQQpr++wpa3aXFq3ZEdZytHpKO4z0qlAlzPotoakM1eNzKcklLK2FhbAg CISVS1ibmKRaU1j7vkc/jbeE9fz83Yx//OOfmmI0hbmEJdef/UqEBdcgrLzC2sRLSHWEVa1L aDri1JPZDZRrQsawzIxaeoQF/wNh5RLWa6MuYeUxLLPZ5ZdaJzGPsPRx117JWFna6Tc3RSeR XhXqYiGs3mIqYb13D8LqX1hbozGsFJjp3gqEFX/6zU3RSSCsiQNhVQVhISzPFWzYJRwlEFZV EFb/wnoVXxQirMpx+QIQwqoKwhpCWNH7TbyCCAth9QXC6l9Y2re6cwhLTbM6kZvONZ63/GSC n7Y5Vj8/z9jaxFQsrShztpdMYx4bwmoMwupfWDKm6RJutgnoPwPmoLsSmIb66Z01qjWgrMqj hXWtD0VIYvVvNAgLYZUgpIVlNYhs5lgNcivBpRZdKRFWqD7M5ccHatPj8fj169eZQFuvpURY PUTGqvjXv39VE1bRdwldwlIL57uEnhaWlkC9NuhvhblaWK4GHcK60IfWwjIVpjyltbCsskNY PUSWqjjvimm6hJctLM9bfjKB+mgtxNOwkppzHYa2BmFZ9HEuyFaSZjHNUAir/0isivPSx2VM vILlhFUiLuVSIhDWJ2G5WlgIa6DI2MJCWKakFPVthbCcwtJaWHQJB4qMVXGrqHIX95Jp5mEh rCBheVR1LpjCehedx1t7zFhZ2uk3N0UnkaVLqAgvEGEhrBtECKs+CKt/YaXsN/EK9t8lbB4I qyoIawhhqebVNN8SThMIqyoIq39hyewIq7dAWFVBWAjLcwURFsLqC4SFsDxXEGEhrPf3z/NC 24Kw+heW9FTNV3NSQFityC8sOflAm7sg52HJBOZ0hzOBmV0rYbuapYWwhhAWg+7dxvzCCrHJ 2QQzvaYl8BvNnwBhjSIslR1hdRgLCUtaQ2siXepGS+8RlplRW5mxsrTTb26KTgJhTRyLCstM 4BeW5iOE1XMgrIljdWH5u4ThTTDP69MIayxhqRIqCysFhNWKGsJ6F108LYGpKuUjmd4qLJkA YQ0trOj9Frq4lyCsVjSeh5WlEE9pnnt633dPp+Dc5LlaCGt0YdElRFgZFJO3KOsduX3GdXb+ NAgLYa0QCKsq8o7cHLjOzp8YYSGsFQJhVcXlnSw0N0UnkV4VqgS+JewtEFYQv379MldGvPEj 78j9A1ejSTs7icorEzQ3RSeRWBVbo2kNKSCsVnQqLKubIvbouaebDLqHt9HkY1xfIvWFdf6L sHqL5YS12Wauq03WNe+OmVzWlNHCSiSLRzzaWkdYr3QJO44VhbUZU65M+2gJ/MIyFyYQlmx2 aQ2x8zHW2mVaSs+OzFyuEuS/lYXlOhGEhbAklVpYt4T1ftXCkvf3cMIycXnE+lETjcsypqGs 5ciPX7897ioji7CisyMshHWDtsIK2XWfwjL9FS0sVwKrmKzppTdPYdU0DsLqPxDW7S6hakm5 ikJYHmH5m1oezVUTVsp+C13cSxBWK5oJ61307GTizf12tDUlwgoRltZ6Mi1mpqkmrO0zCKur WE5YbelQWK6HU1spXeYZdL8UlirBKiyt2FYtrGjTJV7B6BIQVisQVvzpN3lKcz3q/ZS22UBY nQTCqgrCKm2rLAWqEpiH1VsgrKogrAqR3sJSywirt5hKWI/uQVj9C+vrt4eMasJKAWG1Il5Y JVBDGK0P5JqawtIe495cyaD7xIGwLJie6l9bDYXVWzCGNXEgrE/4b5qetVVBWOr7MjUpwfxX PufaV2xa4nIHnGsMa+NXc/oLhPU/tK+xIxK0pbSwtMfYZSIlLPlRk5SWEWGpK4iwEFYMLmHV P5JwqgnL5aNXWxtKNrKsWboVlmpLIqyuAmFZQFhZhOX3SLddQlkC3xL2FgjLAsLyPMPb1Ys1 rpXmpj67hCn7bXX1EVYrEFYkFZ5S1bkLEdar6BW6NpU7zlxF0SXsLRCWBYQ1dERXhalUhNVb ICwLCGvoSKkKrVV4N2/iFURYCCsGhDV0ZKmK+q/maL/bdjdvc5UgrKpoX8NHJGgLwsooLL4l 7DYQ1idChFX/qEIoIazwzlFIMu27wm6FpX0fWk1YdAkRVjza3dOtpxTZRXCrwHBhVQiENXEg LB+dt6okeXWwGXMRZHdYW+NKL5O9fm5haUWZyZoLa2Ome5cxj7C2cchYX/L0SwtLbTXnYbnS bw5tKRG4kjUUluusEVYPMZWwWv9/okHMJyxPes1rl8LKq5vo7CYVhJUCwmoFwoo/fYSVS1jy TG9lLHFlQ0BYrcgpLPkXMsUvefPOJyyzS6j9h1kyzRBdwuj9lriyISCsVmQWVrp3EJZVWEou 1iaSNJqWxiosM1lbYalTY9C9t1hOWGaby/px+/y70P4ErgLHFVaWx76hbrJkR1gdxuTCklgV 5heTaZ/wEjSLDSesms6Sl6n5YSOsnmNyYWnL2i9unZvOjyqZTGP6yCzhUnnjCmvQSKwK9Qph ZWHxLiHC8rWGEltYlyWEt7AibnRrIc1N0Uk07MxG372JIKxWFP+W0CoaM4FfZC6FuXbhEVZc R8DMlasfZH40+2vmGi3MhknE4UX/mFh6VVyeYAlhxd0JJwirFWvNwzqXo1tYWlElhGVdL1Vi 3W+WHy5sJazoY0BYCOsGwwnLXLh1suZCBWGZj7GZcfsY+tlsrxBqJZhtt8u9IywThNUKhBV6 suYCwkJY0wfCqo3VNRGYhZQQlnKKaSXNNaZoPCaSRnNlaSUs19khrB4CYdVmix238pz4UVJY prZcLaxLH6kFba68KvzyMCoISwbvEvYWCKs2KX9IPedeWlimbrIIK+4wEJYGwmpFG2GpiaNx ArqbPmN9ydMvISzr+kthmc0lTzJXllbCko0+hNVbIKxUIoTVYQtLe1D9610p1SZPC8tc1kpu LqyUCky/iHF5EVYrqgpLPS3y1ZzNNq10u5pZemunR39jWB1GD/OwEFZvsa6w5AuDX758keqR bxpqC553CW8J6/j8Bd9+E2shzRWTN/71718IK5B935+fv68Q6wpLGkR7z9n01LvxIo51zS1h HT3NdJ8pBhVWItu2/V6AdYXlUY+1x+dKkyKso5t3CWcKhDUx6wrrPXgMy1yQaRKFdfC/NSCs jyuYUgLCakIv3xLmLU0rOWN9ydNvbopOAmFNDML6pBJFFje59pKxvuTpNzdFJ4GwJgZh1QZh ISzXFURYlyCs2iAshFXoBmgtkxogrAwCups+Y33J029uik4CYU0MwqoNwkJYritIl/CSOYWl JhxYZ1GZI+vWj64E2tbLMjWTIiyE5bqCCOuSaYVlFYqmD21NSALXVjmTy5MFYSEszxVEWJdM Kyy/lVyGev94U0e+afj++bcLtU1+YVnLz1hf8vSbm6KTQFgTM62wXO0mWljTx6DCSr8BWsuk BtMKy6otKRGX4C4TaFutwpJZEBbCqgDCakL+LmFzEBbCCryCdAkvQVhF2ATmpoz1JU+/uSk6 CYQ1MXMKq2cQFsJyXUGEdQnCqg3CQliuK4iwLkFYtUFYCKvQDdBaJjWYSlijkLG+5Ok3N0Un 0aoqCl3Z8BsgTgEyo7as+P37948fP7Q1/qJcaxKZR1iLg7B6FlaIy8L/mFmT5RWWVtq2bT9+ /HDl8q/MC8KaBITVrbACTXRLWGbKosL6/fu3X1in0c6Vrn9lIVpLTUvmAWFNAsLqU1jnA1ai hXX+4JtcGSYoHVeX8IdA+6jcJHP98ccfyjtSTCqvEtaZQJZjtuAQ1uQgrN6EJQXkGs2MxtxL dmFpaTwtLE9DSdukhOU5Bj8IaxIQVlfCCmwr5eL8bd3AZ94ji83RJQwRltYlDCzczOIHYU0C wupHWJVtdaQJ67cxoqStlD6ypvxtG8OSPrIuy3IQ1nIgrE6EFW0rra8Xkf2GooYFYU0CwupB WInGSWyareAshDUJCKsHYR20sAqDsCYBYXUirCPWWSnCShzDGgiENQkIqx9hHUN9SzgWCGsS EFZXwjo+O2vLjbkjhNUEhBUJwupNWIdwVkiDK7xLaG3KIawmIKxIEFaHwjpKvppzGOZqLZMa IKxJQFh9Cuvt7e0cYAq5guHC0l4kPBBWIxBWJAirT2Gpq5P3WltXtpZJDRDWJCCsnoVV5wZo LZMaIKxJQFgIq7VMaoCwJgFhjS6s8DEsV/bWMqkBwpoEhIWwWsukBghrEhAWwmotkxogrEmI njMNGUm/gtwAfhAWZGNrOuoMUB+ENSrnH8DWRwFQFYQ1KqrR3vpARoXaGxGENSTn2yc8cilQ eyOCsIZEGxltfThDQtWNCMIaEoQFa4KwxsP87rn1EQFUAmGNR/+TZQAKgbDGA2HBsiCsgZms M/j09PTy8nIuPD09qQXzo6eQs4QSx3a5a6gAF2BgJhPW8aEbpSe1Xi3LBIl7CQdP9QNXYmDW EZY1QeJewkFY/cCVGJi5hXWIvqHisl+mtcvMrpy/zHP55eVFW2MWYpbgSQC5oFoHZnphnciP ly0srfUkvWNNYyZQQ2nWAziMBqBrAWeVgDodmEWEJdeUEJbWPvLsXcvl34qwSkCdDsYu2D5+ furt7a31ceXh5YPjo6Uj17y8vHz58kV9tHImUKU9iW8e5XptWe7i6enpzz//lIekjkRmUQVq JWhnAXlBWOPBPCxYFoQ1HggLlgVhjQfCgmVBWEPCy8+wJghrSBAWrAnCGhKEBWuCsEYFW8GC IKxRQViwIAhrVBAWLAjCGhhsBauBsAYGYcFqIKxSmNM7J6B1pcLqIKxSbNv2PhePx6N1pcLq IKxSICyA7CCsUiAsgOwgrFIgLIDsIKxSICyA7CCsUmQU1uPxUMsNPYiwoDkIqxQICyA7CKsU pYWl5kaZH+W/GUFY0ByEVYqiwpKFb9umJZAiywjCguYgrFLUaWGpBNqU9Fy71g6jdaXC6iCs UhQVllrz+EAmRlgwKwirFHmFZTadLsewsoOwoDkIqxTMwwLIDsIqBcICyA7CKgXCAsgOwioF wgLIDsIqBcICyA7CKkWEsFxZ5KyFiOy5QFjQHIRVikLzsFxUaNAhLGgOwipFSgtLm7Pumm/1 Lt7U8aTxl4CwYCAQVikShSVXqhaWtl6ayJX33fE2z/v9RhnCguYgrFIUEtZDYM0iE5gT380S EBYMBMIqRbUWliuvtfFFCwuGBmGVIq+w/GNYZhaPqhjDgnFBWKWo8LVdZRAWNAdhlQJhAWQH YZUCYQFkB2GVAmEBZAdhlQJhAWQHYZVim5HWlQqrg7AAYBgQFgAMA8ICgGFAWAAwDAgLAIYB YQHAMCAsABgGhAUAw4CwAGAYEBYADAPCAoBhQFgAMAwICwCGAWEBwDAgLAAYBoQFAMOAsABg GBAWAAwDwgKAYUBYADAMCAsukL89cet3KEb/0Yq4H+Coc9YN69ZVJ3V+qQRhwQUrC8vzMTBX IdoKy1yOvknugrDgAtcNKv+cngv7vqtNaqXMfiZwZVf/dvKTYi5haYfnqYrDURvWM9XK3Pfd rAqttCaY90PNg0FYcIHZM7Lestom6xrNaGZ29ZwfTZ9JdQCec/dUxSHcLYs6vGdqCsuVoK3Q ERZ0jXmDHsZAhquZIBc0YVmzy2ZFD8KyfnS5W241SzDP1LXpuBKWdb/VMC8Qwopk27av3x65 ovkDE86+74+suJ4Nq18Om7DUpnP55O3tTVvveYzlsp9t256fv2cMrX1knvvb25spEZlLK8F/ ptZavUxgVsKPfHhufnPTeXG1eijEbMJ6/evvXDGWsN6z4hfW4R2osrY+zNaWP/utyt+27efP /2QMV0tQ7U4qw9rc8I9huc5UJrb2jq11qzb9zsctYblOpwQIK1JY1stj/eOjpbfesomXuaiw +qeQsLIfZPYytfLrCKstCCteWNrCYYyGbmLUxsx7KbtwEFafwsr1BylwXwhrMJoI67C12NVH q7DMEhJBWH0KqyYIazx6EJb2rzmWoRWijVbEgbAQFsIaj56FpRJYx7kYw0oBYR0Ia0T6F5aZ 178ykM6F5Sot114GEla5wYEKwso46hoNwso86K4tMOjuOTWE5VkZUXJlYTUBYcULy+zfuYQl 02uCy/ItUjVhKdW6Tt88u8MQtHUhpRKaCCtjVVhviYhKKCQs68GrlfIOt55C+oiHBGFFCqsr agorxD6HcfuGpDxiJ0m3ElauqjAzRlRFIWFZZ8DKw9aEpZlOW5MOwkJY94QVuOC5cc2UirGE lasqzLZJRFWUFpbr4K2vectGVt7+NcJCWGWFpb1Gp73Ucnx+nt/e3iJOfxRhuarC2sK6WxWl heU62vP9ULNjqPIiLCdbblqfUCjaf3JQ7tw398N5XA3cHMYDLBdSKjz7uScK625VmCkjqiJ7 JbgO3n/i5ikgLABYFIQFAMOAsABgGBAWAAwDwgKAYUBYADAMCAsAhgFhAcAwICwAGIb/AlTX qpUg+eQVAAAAAElFTkSuQmCC --------------477E8FB3A06F26D262C6CA65 Content-Type: image/png; name="ahbkglnbafpgigpj.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ahbkglnbafpgigpj.png" iVBORw0KGgoAAAANSUhEUgAAAbcAAANqCAIAAACBypJkAAAgAElEQVR4nO2934vUWtr3vf6n oZQwJ3P8Prw2koN9LLZMmEOxcciZOO0wTx4QaW9uAiLTMhBB9LnBILQDm2zoPWx4wtvigUHZ D+zQeoOQ6gOhysO8B9f05TK/atXq+rHqqu8HweqqVHWS+l6fXmslWVE1AACAftS6VwAAAJwG lgQAgCFgSQAAGAKWBACAIWBJAAAYApYEAIAhYEkAABgClgQAgCFgSQAAGAKWBACAIWBJAAAY ApYEAIAhYEkAABgClgQAgCFgSQAAGAKWBACAIWBJAAAYApYEAIAhYEkAABgClgQAgCFgSQAA GAKWBACAIWBJAAAYApYEDuF5Xp7n9DjLMs/zwjBU56RpSi8lSeJ5Hj32fV9pZFmmf2CWZY1X G88URbHKDQSbCCwJHCKO4ziO6XEURUmShGFI4quqSik1mUzquvY8T/dpXddhGHb6Lssy/sA8 zz3Py7IsDMOlbwkQhALAEeq6LoqCG4me5xVFoVsyCIK6rvM8D4IgTdMoijjHF7HkurcbAADM YDmWZUlGI/3xAkEQTCaTKIrSNJ1MJuq8aTlsSf1XNHrcJNAVbR4AAFwQ8lqiQfqjtuRkMvF9 n+zJb+FRyJltyTRNqQmJtiQAYFMhZ5VlGQQBtSjblmTZNXxn0uMOwzBNU1gSzE07WACsF9/3 fd+nx3qPO45jMh29RJ3uqqpqM0vS8R/dswCY0G3JtTl7kBXvGgAAqAcsefblq1P/YElgQuMv Kzc8AbAGlgQAgCF6u7dr1yIsCQBwAbQlAQBgCFgSAACGgCUBAGAIWBIAAIaAJQEAYAhYEgAA hoAlAQBgCFgSAACGgCUBAGAIWBIAsAAWMqPN2unetL4NXrsWYUkANggHpbEoycCSAIAF4KA0 YEkAgEM4KA1YEgDgEA5KA5YEADiEg9KAJcE64XsclmWpzqcET5IkjmP9iGEcx77v8490q1j+ ELoRGL2UZRndfXvgl6ZpyjexAa7hoDRgSbBO+B5baZr6vh9FUa3d7zBNU76Vgu/7dAOvuq6D INDv7eV5Hv1YFAWJEpZ0mf39/ePj4+l02vmqg9JYiGROT09hSWBDWZae59XnZqTHfHtYE0vm eR4EAX9gURTUlizLkpqfQRBUVUUCpeYqWTJJkkabFKwG7hN06tJBaVxEMqenp4eHhzs7O/1n Ubq3wbCka5ATPc+jO74WRUGurFuW7Oxx6/eAJciSURRRXz6O4yiKfN/P87yqKmp4ep7n+z4U uRba52DrunRQGhaSOTk5OTg4+LccZ5xr7t4Gd54oD9ZFXddRFJHI6roOgoAf111tyaqqfN/X b5ndaEvyuCQvRj8qLaJpmtJvp8bpWncA+Dc7OzuHh4duSsNCMru7ux0buUGWtP4bCJYBOYuP 2yilqA1Y9/S4qbHJzcDGuKTneZ1tSc/z8jyfTCa+71OPOwxDjE6uBd0bo9Ho4ODg5OREf3Xt lliIZMbj8dHR0Xe67Nsda19jWNJx8jxXStFAJD3O85xe6huX1NubdV3zECTZdnhcMo5jsiQ9 w58JVkanHPVX126JxUrm29Bk3+5Y+xrDkgA4RaccGQelsSjJwJIAgAXgoDRgSQCAQzgoDVgS AOAQDkoDlgQAOISD0oAlAQAO4aA0YEkAgEM4KA1YEgDgEA5KA5YEADiEg9JYmCX7WPsaw5IA bBAOSmNhltyUDYYlAXAZB6UBSwIAHMJBacCSAACHcFAasCQAwCEclAYsCQBwCAelAUsCABzC QWnAkgAAh3BQGguzJM6XBABcHAelsTBLbsoGw5IAuIyD0oAlAQAO4aA0YEkAgEM4KA1YEgDg EA5KA5YEADiEg9KAJQEADuGgNGBJAIBDOCiNhUjm5OQElgQALAAHpWEtmel0enx8vL+/PxqN 1MC55mtfY1gSgA3CQWlYSObo6Ghvb695jc2mbDAsCYDLOCgNC8kcHh7u7Ow0LTmdTjdig2FJ AFzGQWlYS+b09LSpy/39/ePjY12XDm4wLAmAyzgojYtLhnT5XbuSdengBsOSALiMg9JYlGSa HfDRaHRwcODgBsOSALiMg9JYvCUPDg5OTk6c3WBYEoBV0jkWN7z82i2xLEt27ggHN/jilozj mP8keJ5XlqX5e9M0TdO0/eRkMul7SxiGRVHQ47IsgyCgX93+nGGUUkVRhGE417sAuCCdY3HD y6/dEsuy5KZs8EIsmWUZPU6SJIoi8/d2WtL3/aqq+t6iWzKKoiRJ6rquqsrzvIF3tUEjGqyF 5mDcLF06KA1Ycm7alqyqipp4QRBMJhNqbNIzWZZR840ekCWLouC4pGmqlCJR6h+SZRm1VX3f Z0vGcRyGITc8q6qizaEHcRz7vs+f1vhRb0uGYcgNYfpFSik0M8Ey6LTkgC4dlMZ2WXL4CzOh /r7H7ft+WZbcxEuSJAxDauXled5nSd4/URSlaUoW0z8kSRLP8/I8pzYjW5JeJZmmadq2ZBAE tEwcx40f2ZJpmtLzeZ4HQRCGYRzHhpkGYEm4fGIMLDkftdaWJOPU500zhhtlqseSZVnGcex5 nlKKLal/CD2mD9F73Dq+71M7VLckrQ/9rsaPSrOkvrZFUVCTk9qwF99FAFyQtYsClrwQuiUn kwk19LgZWNd1WZaNtqTv+/V5M5MsGYZhkiTUxU6SpNEgJTrbkp7ncWc/CAL6Ffy7uPEYxzG1 H/UfVast2YB+48V3EQAW7OzsHB4enp6eKseksXWWvLgo6+/HJUmC+qHnLMv0ccnJZMKjjWxJ as15nhdFURRF1NDjcUn6EBq7bIxLcrtPKUXdZP138UBkEAT6uCT9qFrjkuq8+UmP0ZYEq4fl 6LI0ttGSnau6KPS2pOd5S/1dDbiL3fmjAPTqWve6AFMM5agvv3ZLwJJLLzA+vMNNztUASwIH MZSjvvzaLQFLosA2FVhyEzGUo7782i0BS6LANhVYchMxlCPjoDRgSbAxwJLbgIPSWJgl+1j7 GsOSYoAltwEHpbEwS27KBqPANhdYchtwUBqwJNgYYMltwEFpwJJgY4AltwEHpQFLgo0BltwG HJQGLAk2BlhyG3BQGrAk2BhgyW3AQWnAkmBjgCW3AQelAUuCjQGW3AYclAYsCTYGWHIbcFAa sCTYGGDJbcBBacCSYGOAJbcBB6UBS4KNAZbcBhyUxsIs2cfa1xiWFAMsuQ04KI2FWXJTNhgF trnAktuAg9KAJcHGAEtuAw5KA5YEGwMsuQ04KA1YEmwMsOQ24KA0YEmwMcCS24CD0thGS85k mRkA9uA72gYclMY2WnLml3TR7xksB1hyG3BQGrBkxzpf9HsGC2I6nb7X0C3JT47H43WvJlgk DkoDluxY54t+z2BxjEaj4eGRk5OTda8jWCQOSgOW7Fjni37PYHEcHBwMKHI0Gq17BcGCcVAa sGTHOl/0ewaL4+TkZMCSBwcH615BsGAclAYs2bHOF/2ewUIZ6HSjuy0PB6UBS3as80W/Z7BQ +jrd6G6LxEFpLMySfax9jWHJTaev043utkgclMbCLLkpGwxLbiKdnW50t0XioDRgyf5msFIw piO0O93obkvFQWnAkmADaHe60d2WioPSgCW/rSoaki7T6HSjuy0VB6UBS363tvCjs+idbnS3 BeOgNGBJsBnonW50twXjoDRgSbAxcKcb3W3BOCgNWBJsDNTpRndbNg5KA5YEGwN1uvf399e9 ImCJOCgNWBJsEqPR6Pj4eN1rAZaIg9KAJcHq6DzdShjr3scbj3JPGrAkWB0O5gHpcg0BIem1 5P7+/vHx8XQ6dXyDkeM14mAekC7XEBCSXksy+/v7fKKGgxuMHK8RB/OAdLmGgJDMtiQxGo3o vI21rzFy7A4O5gHpcg0BIYElgT0O5gHpcg0BIZlhSZIjetygEwfzgHS5hoCQ9FpSl6PLG4wc rxEH84B0uYaAkOBMIGCPg3lAulxDQEhgSWCPg3lAulxDQEhgSWCPg3lAulxDQEhgSWCPg3lA ulxDQEhgSWCPg3lAulxDQEhgydlkWeZ5nlLK87yiKOq6TtO0vViappPJxOQDy7KkD6RPYyaT SRiGdA5WHMfDH1JVVZZlfa+GYdj48GXgYB42Ll3iERASgZYcj8dHR0e7u7vv379fyNfseV6e 53Vd53nu+35VVb7vtxejl0w+MI7jNE3TNG2oMAzDMAzruqZfMSDBuq6zLBsw6QItub+/33la WO1kHlZTHsAcASGRY0mWI18vtChL+r6fJAn/SM09Mh39It/36bHv+77vk55838/zPAgCWkZ3 VpqmURSFYah7cDKZKKW4NUrLx3FMb0/TNMsy3/fpxyzL+AE9maYp/S5q8C7Qknt7e52XGNRO 5mE15QHMERASCZZsyHHhlqyqKo5jz/OofdduS5KYuJnJliyKwvO8siwbH0hKbbQE2x9LHfOq quhBmqae500mkzRNybBxHNNoAD0ZBEF9Pj6wDEsyrEsH87Ca8gDmCAiJBEseHh7u7Oy0LbkQ 9M2vqkopVZYl6Yw8RYv1WTKKIlqAm41FUQRBQEtGURRFET3faEuWZUk2pB9Ji/QjPWBL0pPU tuWviSy5pH2i1L8n1lPu5WE15QHMERCSvhhskiVp3U5PTxu6XEhbktpx1B6sqooee55HeyPP c2ow0pBlWZbkL1qSW3Pc0NMfU69Z73Tr45JBEFDjUW9LNiwZRRFbcjVtycasow7mYTXlAcwR EBI5lmRYl4vqcfP4I0ltMpmQhqidGAQBGY3GK8l9vu97ntcYSaRPm0wmPICYJAkJt/GSUora mI1xSd2S1FRkdeofu/Bxyc4pmWsn87Ca8gDmCAiJQEuCleFgHpAu1xAQElgS2ONgHpAu1xAQ ElgS2ONgHpAu1xAQElgS2ONgHpAu1xAQElgS2ONgHpAu1xAQElgS2ONgHpAu1xAQkt7Thjdl g5HjNeJgHpAu1xAQErQlgT0O5gHpcg0BIYElgT0O5gHpcg0BIYElgT0O5gHpcg0BIYElgT0O 5gHpcg0BIYElL0oYhvq12HSJd3uZvquq2/OTz7wEWyllON3vsnEwD8LSJQABIYElLwo5jiYz pxko2pYcfntjfnLXLEmzh5yennauydoDIDtdAhAQEljyooRhGAQBNQOTJAmCoDG3I83Qw3MF KW3+3c75yent+mxA9bmLaQpL+kyac2gFG/j+/Xtak52dncPDQ8xVDuZCQEhgyYsShiFNBFnX tT4LJBFFEU8tTnYjgdKrnbfQ4Q/UZ5akuSOTJEmSRClFT65mA9mSDOYqB+YICIkES66R+nwW 8SAIqCFJXeayLOkmEOp8CkiyZH0+4Tntz775yXkqyfpcmroT6Vdzg3Rd20530Vh7ANZSHsAc ASHpi8EmWXKZX/FsSGrUxOO5csMwTJKEphxPkqTPknXX/OQDbUm6rZg6n+t3NaOTjbbk7u7u 0dHReDyuncyDsHQJQEBIYMmLQgYsy1IpVZYlWZKmN/c8j+5sM2DJ9vzkA+OSdD8J8mMYhjPv 2b0QyJKd05U7mAdh6RKAgJDAkmAG0+m0fS8HwsE8IF2uISAksCSwx8E8IF2uISAksCSwx8E8 IF2uISAksCSwx8E8IF2uISAksCSwx8E8IF2uISAksCSwx8E8IF2uISAksCSwx8E8IF2uISAk F7Xky1ev+XzjKztX3777oJS6c/cevUo/Pn324uat27zYzVu3z758/SV/M7p0mV6lH+nVl69e f/p8dmXnKv+on9L88tVr5NgdBBSAXXkAcwSEpNeSdHHFzA1++er1/QcP6fGjx0/u3L1HOvv0 +ezsy9enz16wJUlwnz6fXbt+4+mzF9eu3/glf3P25evNW7ffvvswunT50+czevDjTz9fu36D 3s7C/fW3j/QkcuwOAgrArjyAOQJC0mvJzsstZlry/oOHSqlr12+QE69dv0FOZEuefflKElRK /frbx7MvX+8/ePj02YvRpcvctHz67AV95i/5mys7V+ld+icgx44goADsygOYIyAkQ5ZkWJcz e9y//vaRTHfn7r237z5cu36DJKg7jtx37fqNt+8+UOeampxv3304+/J1dOkyW/LX3z6SJXVd IsfuIKAA7MoDmCMgJEaWJDrngNHbkvyJNBz56PETal2225I3b93mgUhqbLIESZr0mW/ffaDn Hz1+QsOXruU4yzKa+MfzPJoVba4peJn2jOUzt0s5MGO5gAKwKw9gjoCQzLbk8BwwnZakMUTS ZcOS+rgkPcPjkr/+9pGalj/+9DPJ8eWr1zQuyYOYruXY8zyapTzPc9/3rS3ZnrHcKUseHx9j rnJgh4CQ9FpSl+PABvdZkoYaz86HHfVj3CQ+bktSI5F77nSMm8YolVI//vQzf6aDOfZ9P0kS /pEsSXOgKaWCIJhMJjSvODUSsyyj6cqVUnzbhs4Zy2m79JmBSKDq/I4RaoUzlu/t7anzucp1 XQooALvymItGh6Ou684ZlM2nVeZ57xt/JvkX+b5fluXwh6RpypFrs8CyEhCSXktuygav15JV VdFsu9QAJEtGUUTqpKnFub1J00fSxJHU9uQPac9YrpSiySV5lkmas5I+J89ztcIZy8mSDOvS wTysIF2np6fPnz8333uNDkfn1935ZB/ca9H/QNKfTLbwzE9rS1ZnrrJ6/vx5Z1eDP2rt3+My YlBvliXXhb5naNbIPM+p78zL6I/V+bzltcGM5UqpxozlSmt+1t/PWL6qLe7gvz+frT0DqykP ukvazs4ObfgsdXyj0eGgrzKOY/qWlVK+7/OTZEB6F/1NVa1mI/0ZbjxJf5L5x6IoyrKkzkcQ BGRh/pF+tX8O9UhoZbinYr6B9MZ2V4NfXfv3uMAYfLdpfbtj7WtsuAErgJp41LWpqoqaDHpb kuCmRH3eJ6qqim4Cwcu0ZyxX/W1JupeOWuGM5Y225P7+Po3GOJiHhaerIUfGfO81OhztZiNJ ip5sWJIGbRofyPPV60/SeE5jMQpMHMdRFNEHTiYTanJyq5a6I5RSmhOa0mW+gY0909ClgJAs y5Lta3Ju3rpNI5X0b3Tp8s1bt/XD2XTAR3VdYGOxAauBmwOU2sa4JD/JLQLqCiltiIpoz1iu +sclqXLUCmcsJ0uanD8r7F+z5Tw/+m6kDgQ18eq6zrKMv99OS9KfUvX9OGOapkmSkObIaPR8 oy1JyaSPoljqn6xbsigKvWdDN1miHy+47YeHhzJCopZnycY1OXQAh47G0KEbtiQdrtEvVew7 VmO+AW6id6I3iL5RJwEFMDNd0+n06OiIToPr098A7Q4HPUN7L89z+iPKt+Gk0UZakv+O6r0T vYWotJ5EY1xS73xwW7JhSfI1PbnAtiQd+OW/pgJCsiJL3n/w8Oat23SSOT1z7foNtiRfkkj/ +k76mWsD3GRDLdmHgAIwT9d4PNZ1ab6XGh0O6vPSyIxSKggCPqyn37edlEfv0tuS+mgj3VWJ fxGPLZL72uOSuiX5Du/05MXHJTvPipERkiVakpNB1+SQE6nTTS1HtmT7dKKLbwBYAQIKwCJd pMvV721n6ZQjIyAkq2hL0j86sfza9RvUkHz56nVfW/Llq9fmzUlYco0IKACka9kICMmqLfno 8ROl1NNnL3RLNsYlR5cuw5IbgYACQLqWjYCQrNqSdIn323cfdEuenV+yTT30vku2kWPXEFAA SNeyERCSZVly7RsAVoCDeUC6XENASGBJYI+DeUC6XENASGBJYI+DeUC6XENASGBJYI+DeUC6 XENASGBJYI+DeUC6XENASGDJGdAlrvq1E/X3MwbSMzxdRV3XaZq2r63mK3bpXWVZ6s8opYqi aExE2PjVjemFVGuei5nrsHAczMNmpWsbEBASWHIG+gwueZ7zdbg8jwA9QwojY/ZZkqdsSZIk iqL2JC4mExHW/VePzVwHO05OTvqurHAwD5uVrm1AQEhgyRk0LElzBeqTr9CPNDeP53mTycTa ko2JCC0sObwOdtCEQIZz1wv7B0teHAEhgSVn0Oj2FkXRsBvNf0XzFJD7Zva4afKCRo+77pqI UF+A58gasOTwOtjRmFxyb2+P509zMA+bla5tQEBIJFhyqbQbdH1tSZ7wijzV2HXs1jAMyXft tiTTmIiw/S10vqtzHZa3Z/b395V7eVhNeQBzBISkLwabZMllfsUd3d72uKR+ExKaJmvAkjxZ dMOSnRMRWlhyYB3saLQlR6PRwcFB3/3Zhf2DJS+OgJDAkjPoHBzsPMbNyguCYHhckiambvS4 syxrTETY6HHzasy0ZN862KHfQPHk5ER/ycE8bFa6tgEBIYElwQz6bsZdO5kHpMs1BIQEllwK PMs0o9/lZlN+xUwczMM2pGuzEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7X EBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY 42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7X EBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY 42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7X EBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBAS1cembDByvEYczAPS5RoC QoK2JLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDH wTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4h ICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDH wTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4h ICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDH wTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4h ICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDH wTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4h ICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDH wTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4h ICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDH wTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4h ICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDH wTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4hICSwJLDHwTwgXa4h ICSdMTg5OYElwWwczAPS5RoCQqLH4PT09ODgYDQaqd4WpnsbjByvEQfzgHS5hoCQKKVOT08P Dw93dnaUzqZsMHK8RhzMA9LlGgJCopRq+hGWBIY4mAekyzUEhIRicHp6enR0tLu7+82Su7u7 R0dH4/HY8Q1GjteIg3lAulxDQEgaMRiPx0O6dHCDkeM14mAekC7XEBCSgb71d4xGo+PjYwc3 GDleIw7mAelyDQEhmWHJnZ2dw8PD09NTZzcYOV4jDuYB6XINASHptaQuR5c3GDleIw7mAely DQEhwbU3wB4H84B0uYaAkMCSwB4H84B0uYaAkMCSwB4H84B0uYaAkMCSwB4H84B0uYaAkMCS wB4H84B0uYaAkMCSwB4H84B0uYaAkMCSwB4H84B0uYaAkMCSwB4H8yApXVVVNS6BS9M0CAJ6 NQzDNE0bb1FKVVVV13WSJPSWIAjKslz1qn+/Smv/HpcUA1gSzMbBPIhMl74aJMc0TcMw7Fyy qiqSKekyjmPf91ezns+fP9+IS1EWFQNYEszGwTyITJe+GtTA9H2fJNhesqqqRvsxCII8z1ez nhtxWfOiYgBLgtk4mAeR6WqsRhAE3O9uL0ka1R0ahmGWZctdxfPfrkO6FBASWBLY42AeFp6u NaLvZ35Mfe0gCNqDkrXWliyKghau65qalmvckP/5v+6v/au8YAy6878pVdG3AWAFOJgHkeni 1aiqyvO8qqraDUZeUh+XTJLE87y+hucy1lNnf3/fzekWFxUDWBLMxsE8iEwXr4behNSPd+tL No5x+76vlFrluGTjNgcCQgJLAnsczAPS1aYsy85DPQunfQ+YWkRIYElgj4N52Kp0pWna6OSu e406EBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBAS WBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42Ae kC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBASWBLY42AekC7XEBAS WBLY42AekC7XEBASWBLY42AekC7XEBCSXkvSbOzT6dTxDUaO14iDeUC6XENASHotyei6dHCD keM14mAekC7XEBCS2ZbUdengBiPHa8TBPFHSC10AACAASURBVAhIF935i8myLMuyxjNlWdJt wuq6TtM0iqLGh6RpGsdxXddlWQZBQG9MkmT1myMgJEaW5OakgxsMS64RB/OwgnRNp9Pj4+Pl 7dWqqnzfp8d5nnuel2UZKY+fqc9vOUu6nEwmjQ8hS04mE8/z6IZiZVn6vr+aG3PrGIbkx59+ vnb9Bj0eXbp85+49enJ06XKjufby1evGj2/ffbiyc1Upde36jV9/+/hL/obe9fTZi7MvX3/J 3/CSZ9rdg+nHi0im2deea4PXnmOwGhzMw1LTdXJycnBwQDW2vL3asCSprW3Juq593/c8r/P+ iGTJPM/1Zmae5yu76yxjGJK37z7QkqS80aXLZ1++Pn324v6Dh/xd0IOXr17zk6TRO3fvkRDv 3L336PGTa9dv/JK/Ofvy9eat22/ffRhduvzp8xk9ePvuA7v44pJRjeM2c23wGnMMVomDeVhG ukiOo9FIb8Isb682etxFUbR73LQk3W678/6IZEnudxNFUbB/V4Z5SMhiT5+9ePrsBT1m/Z0N WpI/4dHjJ48eP1FK/frbx7MvX+8/eEgfxU1LbodSq/OCksGZQGA2DuZh4elqyHEF6G1JgtuS 1MumJ6mvHcdxe1Cy1tqStHxVVUVRUNNyxZtDmOztO3fvvXz1+tr1G9Tie/nq9ZWdq2/ffeDv gh60e9z0/K+/fST30Sd8+nx2Zefq02cvlFL0IaNLl+8/ePjo8RP6EHpwEcnAkmA2DuZh4ek6 Pj6m45YNlrdXByxZ13UYhjTO6Ps+9bU7Rxsb45J0DKeve75UzENC/WtqGz56/IQf83dBD7gt +fTZi5u3btOTnz6fkRzPtIHIa9dvPH324srOVVrmys5Vbj++fPWa32stGVgSzMbBPCwpXXTE Ru93L2+vDluS+uNhGHITUj/ezXQe4/Z939lxybNzu/FxG9Kc/l3QA73HffPW7afPXvySv9Fb ndQOPdPGJX/97SM1LWn5sy9fqV9/QcnAkmA2DuZhBemiYcrV7+2F4HJb8tPnM3V+YJoe653i Tkv++tvHRhv//oOH3Jakj+IeeuNo+KfPZxeUDCwJZuNgHrYzXWmarmxAYF4EhASWBPY4mAek yzUEhGRuSzrIMr9iMITa/AKwKw9gjoCQ9MUA4QCzEVAAduUBzFl4SBpjkTRGSaONhPnBa1gS LB1YEsxkGZbkk3t+/e0jnX9+ZecqXW+zyhggHGA2sCSYCSwJthpYEsxk9T1u80sPYUmwdGBJ MJPltSXpZHJyotNtyTAMi6LQn8mybC3T2IHVA0uCmSy1x80XKW6YJeu69n2/c54SsIlMp9Px eNz5EiwJZrJUS559+UpTWqzHkkopz/PoQnrf96nDn2VZURTc/y+KIgxDmrSOn6nrOkkSuiAf COD9+/dKqd3d3aOjo4YuYUkwEwEh6bVknudVVdE8yTQZsj5rU13XURTRM0VReJ5XliW/1Jj7 E2w0ZElmb2/P5fsgraY8gDkCQjKjxx2GYZZlJEd6UJZlHMee5yml2JI8aR3N4ERtzJ4rZYAQ 3LwP0mrKA5gjICR9MfiuLalbMgzDJEmqqgqCIEkSfVwyTVOalwltSUk02pKsyOPjYwEFYFce wJzhkLQn9VngeTy/5G8Wch1OryXV+bgkd7TJkjT7iOd5URRFUUSNTX3gssa4pCzYkqPR6ODg 4OTkhF+CJcFMDEPicpZmtyX1AUdDcIxbEqenpw05Mi4ne6nlAcyZ15JXdq7S3cHoZgxKKTop kh4ope4/eMhTRlJT8eat27wYv+vlq9fUlqRbhp19+fro8ZM7d+/RwnTFzv0HD+kzeQbf+SxJ 6LcWMiTPc5wvuSXAkmAmFpZszCI+unSZtPhL/oZm2L156zZPxEu3yiEJ3rx1m2YmpysXf/zp 55u3btP9c+hznj57QQvTjW3vP3ho0iXvteSKdyXYRGBJMBMLS9KZjzQnOTcMaQFqVNJVN+r8 zjZsVZ6lnKC2JE17Tp/ALU2CbrIIS4IlAkuCmVhbUin1408//5K/4d43W5LfpTcP6Tocakuy NKmpeO36jSs7V0mp+r10YEmwdGBJMBNrS965e49ai2Q33ZLcJKTb1+hDjfpL1OMmgarzu+jQ wtSQhCXB0oElwUwEhASWBPYIKAC78gDmCAgJLAnsEVAAduUBzBEQkkYM6FbDo9EI4QCzEVAA c5UHsEBASCgG3+TIrHvfgg1AQAGYlAe4CAJCopT6To6wJDBHQAHMLI917+ONR0BIlFLT6fT4 +JhmeIElwRwIKICZ5bHufbzxCAiJHoPvdLnG3Qo2BQEFYF4ewA4BIemMwXQ6RTjAbAQUgEV5 gLkQEBKcCQTsEVAAduUBzBEQElgS2COgAOzKA5gjICSwJLBHQAHYlQcwR0BIYElgj4ACsCsP YI6AkMCSwB4BBWBXHsAcASGBJYE9AgrArjyAOQJCAksCewQUgF15AHMEhASWBPYIKAC78gDm CAgJLAnssSsAujkJzxFN80jrdywZXbrM94FqL8aTUf+Sv/n0+eza9Rv8lrfvPtBLV3au8mPi 5avXsORagCXBVnMRS/LtR2iGfbrfEz3z8tVrugFee7Eff/p5dOnyp89nnz6f0c32eMr+a9dv PHr8hGftZ73++ttH/VYnsOSKgSXBVmNtSbrh8q+/ffz0+Wx06TLd6oQtefblK920ZHgxajDS Y7px6J2796jN+PTZC74TKd1rFJZcF7Ak2GouYkm6MdPTZy8ePX7StiTfRrmxGLUlz758pQ41 3UaKluebL5+d36SUf9fCywOYA0uCreYilqTWH9mtsy3ZtxiNS3Iz80y7X2i7Lfno8ROTm+TB kssDlgRbzUUsSfeSp4Zhw5I8LtlejAYrSY5Xdq7SmCN3qB89fkJyZG+SbWHJNQJLgq3mIpY8 +/L1zt17d+7eY0vy8Wj6sW8xakvSQe1Hj5803sVHycmkrFRYcl3AkmCrEVAAduUBzBEQElgS 2COgAOzKY+GUZRkEATWEwzCcTCZpmnqeN5lM6rouisL3/clkEoYhL9N4V5qmnV9QVVV1XSdJ QosFQVCW5Wo2itdh7d/jkmIAS4LZCCgA8/LgG568f/9+4XvS9/04julxGIZJkqRpqpSiJ8mS aZoGQUDLBEGQZVkURUmS1HVdVZXneSTExhdUVRW9kV6N49j3/YWv/wACQgJLAnusC0C/Kmau oyt8WMb8H51IZL2e4/H46Ohod3eXV3jhlizLsm2uNE2jKPI8rygKsmSWZY2WYBzH1PAc+IKq qmq8KwiCPM8XuwkDwJJgq7mIJemgystXr+e6MGZllvy/5afn//ul6mLhlsyyjHrQRVFwhzpN 0ziO0zT1fZ8sWdd1mqbU6Y6iiOSYJAl1ugd63NzvJsIwzLJssZswACwJtpqFWPLR4ye//vbx ys5VEgSd6siPz86vTRxduvz23Yf7Dx7SknQaEL2klOKz0OnHl69ev333gX68dv2GhSX/z//3 9n/+r/udllw4RVFwV7qu66Io2JJ1XQdBEEVRo7EZxzH1tRnf99stRHXeliyKoq5rMik1LVez acTaNQdLgrVhXQB6CfGlhGdfvtJ12UqbnIIu0D47vwbx/oOH9CNfsn12fh0OnWX56fMZfcid u/doATtL8nqenJwcHByMRiNe4WWPS0ZRpFuSjOb7fhRFvEySJEmSeJ7HrcLOfrT6flyS3qIb eQXAkmCruYglqS1Jgvv0+Yz0p5SiiSpYoPxYf+bsy9eXr17TktycpGf4pZu3btOI5wXHJXlj SZc7OzvLsCS1+GhDwjAktelO9H1fXyYIgslkQj1xeoYXbnxBjWPctDzGJWFJsCIWYsnRpcvc YLx56zYPU5JA+SX6d//BQ1Lhnbv3rl2/QWePk0l5fiCy5KLakuvex4unLMv20fDlAUuCrWYh PW4aQ6THd+7eG126zM1D6ozrP/K45LXrN3jk8eat26Ra3ZI81rk9luSzKblNuu41qmtYEmw5 AgrArjyAOQJCAksCewQUgF15AHMEhASWBPYIKAC78gDmCAgJLAnssS4APrGxcSaQa/9gyYsD S4Kt5iKWpGPcv/72kU4XX3slzFUewBxYEmw1i7IkXzbz9NkLPjD9628feb7Ip89e0IS79BKd X8kvvXz1mh7fvHW7cVdFPiZuJ2JY8uLAkmCrWUiPmzRHl83wSY73Hzy8c/ceTU5OJr156za9 RFfdKO36nJu3bnO3nc+vpM/k8ysXWx7AHFgSbDUXb0vSP75shuYbP/vy9Zf8DZ0mycvwWZOq dX0OzWpOzUx9OgylXasDS64LWBJsNQu3ZKMtSXe/oVtvc1tS/8cXONKP+mU83JaEJdcLLAm2 moVbUp/IRx+XvP/gIY9LqvNLtvklblfSkGVjXBKWXC+wJNhqBBSAXXkAcwSEBJYE9ggoALvy AOYICAksCewRUAB25QHMERASWBLYI6AA7MoDmCMgJLAksEdAAdiVBzBHQEhgSWCPgAKwKw9g joCQwJLAHgEFYFcewBwBIYElgT0CCsCuPBbLZDKJoohO+aQbHGZZxhca+b6v302b9zzD95id TCb8YxzH+jJ0V5w8z5VS7U9bKgJCAksCewQUwFzlcXp6enh4eHp6utjdGMcx3e2rrmu632GW ZfqtwaIoau95undNWZae5/GNZBu3SEzTVL9PdxRFnuc1blG7bASEBJYE9ggoAJPyeP/+/eHh 4c7ODrXLFn4PRc/zGrfraliyfX9EtmR9ftfZ+vxms57ncWtRtyS1NIui8Dxvses/jICQwJLA HgEFMPDvp+NflFL6nbiXYcmqqrgI+Vc0etztWx7qlqR70lKjcjKZsDTr7y2ZpindL6zzzt3L Q0BIYElgj4AC6Pv3/H+//H/+x/+rlg/tRupu817V25J9e15vS5INdbHSS7ol9Tss0oevYOuI tX+bF/ynYElgjYACmFkeel+bWHiPuzEuqeaxJI9L+r5Po5N1XfNjtmRVVdTSbDxeAQJCAksC ewQUgGF50HEb0uXCLVnXtX6MuygKE0syaZo2Rht5KJMtmaapfgiIDhAtfCv6VnXt3+OiYtDc tNXsQbDRCCiAecvj9PR0PB6vZW9vKAJCAksCewQUgF15rBh9zJFY9xrNgYCQwJLAHgEFYFce wBwBIYElgT0CCsCuPIA5AkICSwJ7BBSAXXkAcwSEBJYE9ggoALvyAOYICAksCewRUAB25QHM ERASWBLYI6AA7MoDmCMgJLAksEdAAdiVBzBHQEhgSWCPgAKwKw9gjoCQwJLAnuUVwNNnL+4/ eEiPX756rZ9QfWXn6v0HD/VnfsnfwJLOIt+SeZ7znCJxHNNjntaJLgUNgqA9sxPYBlZjSfr3 S/7m5q3b9Pj+g4cvX71eY3kAc+Rb0vf9yWQymUxo2iWyJE0aWpYlzYo888p8sOk8f/785OSk /TwsCWYi3JJ5ntM8IpPJhGb6JEvStKBVVZElJ5PJimc/Bitmb29PKTUajQ4ODnRdrtGSeo97 9eUBzBFuycZNM9iSfO09v0q3NFr+DgfrgSzJjEYjuv0L2pJgJsItyVok6EeawpOe4bk8wzAs ikKB7eO/P58tI5ewpBiUbEt2tiXLsuT54tmSaEvKptGW3N3dPTo6Go/HyyuAp89e8K+7snP1 bLDHvTxjwpIXR6olT09PvxuXJLhpybf6pR8xLikesiTLkZ8XUAAW5QHmQkBI9Bjos9Z/d4x7 eC/gGLd4Tk5OOifoFlAA5uUB7BAQEqXUycnJwcFB84aatIX6+ZJ9hGGI8yW3EwEFMLM81r2P Nx4BIaGOVMeo/Lr3LdgABBTAzPJY9z7eeASEhGIwHo+Pjo729/dhSTAHiy0A/cg1HeO+eev2 6NJlXmB06fLNW7ev7FzV/5w/ffbi5q3b9JgP78CS7iDGksx0Oj0+Pt7f30c4wGxWYEml1I8/ /Xz25esv+Rvdgzdv3abLt58+e3Ht+g168tr1G4s93g1LXhx5lvy2aSvelWATWYElr12/QSdO Pnr85Nr1G21Lvnz1+tr1G2/ffVhleQBzYEmw1azAkk+fvaBO9+jSZepcNyxJC1Or887de58W epY7LHlxYEmw1Szckk+fvWhYkpqK1JB8+ep1pyX1T3j0+Aks6RSwJNhqFlsANML46fPZp89n 167foBbiy1evHz1+QkdpOi155+49vpbx0eMnsKRrwJJgq1lsAZAc9aPVZMm37z4opd6++9Bp yV9/+8jvIsnCkk4h3JI0h4X57mgvz7OrAZEIKAC78gDmCAjJItuSnVaN45imNAfyEFAAduUB zBEQkl5LFkVB1qP7N3ie5/t+lmW+71PvJssyfbY0Wj7P8yAI+Jm6NWUG2ET29vb29vYaU13U IgrArjyAOQJCMrvH7Xlenuc0rWSWZTRbWpqmYRjy0lEU0TO0vD6LGmYMEoA+cxrNDHR6elqL KAC78gDmCAhJryWzLAvDkBqS9BT9SHKkB2VZxnHseZ5Sii0ZRRE3Nnk3AXnQ5FFLmoXXkX8K lrwwSrAlgyDobEvqlgzDMEkSOkSTJIk+LpmmKe6KI4bGLLzqvEUpoADsygOYIyAkvZYkDzbG JbmjTa/SDXA8z4uiKIoiamzqA5c1xiVFwJZsTMQroADsygOYIyAkvZbkR3pb0uK2DTjGLYDD w8P2oZtaRAHYlQcwR0BIZluS2pJKKYsJyauq0g/yAGEIKAC78gDmCAjJbEsC0IeAArArD2CO gJDAksAeAQVgVx7AHAEhgSWBPQIKwK48gDkCQgJLAnsEFIBdeQBzBIQElgT2CCgAu/IA5ggI CSwJ7BFQAHblAcwREBJYEtgjoADsygOYIyAksCSwR0AB2JUHMEdASGBJYI+AArArD2COgJD0 WpLmizTfF53Lx3Gc57n9DgZuI6AA7MoDmCMgJAtrS3Zasqoq3/dtdi1whtPT08PDQ5pQsoGA ArArD2COgJDMaEtOJhOaezwIAt/34zimKX9o5oswDOkSb5o9iOejpGfog4IgsJgjA7jD+/fv eULJw8PDk5MTfklAAdiVBzBHQEhmWJKniUyShCxJ+qOXaNGyLNX5HR3CMGxMipEkCS8JNhG2 JDMajQ4ODk5OTgQUgF15AHMEhKTXknmek/LIcUVRkCXpR3pA001S5fB9cqixGQTBZDKp65oW U0Acu7u7avMLwK48gDkCQtIXg39bst2W1C3peV5VVSRBWp7fT7NS1mhLbj6NtqQ+Ea+AArAr D2COgJDMsKQ+LhkEQcOS1GwMw9DzPGpXcrOR25IYl9x0yJI0KNk4hiOgAOzKA5gjICS9lqT/ 9LakxY0ZcIxbAOPxuPMAdy2iAOzKA5gjICQzLMltSbvbOSRJgvMlBSOgAOzKA5gjICQzLAnA AAIKwK48gDkCQgJLAnsEFIBdeQBzBIQElgT2CCgAu/IA5ggICSwJ7BFQAHblAcwREBJYEtgj oADsygOYIyAksCSwR0AB2JUHMEdASGBJYI+AArArD2COgJDAksAeAQVgVx7AHAEh6bXkvLPw 0qwWjSeDIKiqyn4HA7cRUAB25QHMERCShbUlOy2ZZVljIjWwiZycnND0Fg0EFIBdeQBzBIRk RluyLEueCY2m4NUnRtNn4SVLNmbhnUwmnuet9ksBi2dvb08ptbe3d3x8PJ1O+XkBBWBXHsAc ASGZYckoipIkqeuaLZmmKbmvKApalGbh5ekmG41HzAkkALIks7+/T7oUUAB25QHMERCSGTOn +b5PNkzTlCxJP9IDfRZesmR7Fl6amlcBcYxGI6XUf38+W3uIV18ewBwl3pLttqRuSX0W3sa4 JM/Ci7akABptSXXenBRQAHblAcwREJIZltTHJWm6crZknueNWXj1mzdQWxLjkjJgS3Jfm54X UAB25QHMERCSXkvSf3pb0uLGDDjGLYPnz583jtsQAgrArjyAOQJCMsOSZVl6nqe0cca5CMMQ 50sKRkAB2JUHMEdASGZYEoABBBSAXXkAcwSEBJYE9ggoALvyAOYICAksCewRUAB25QHMERAS WBLYI6AA7MoDmCMgJLAksEdAAdiVBzBHQEhgSWCPgAKwKw9gjoCQwJLAHgEFYFcewBwBIYEl gT0CCsCuPIA5AkICSwJ7BBSAXXkAcwSEpNeSdMnN8PWFw/OZx3FME14AqQgoALvyAOYICEmv JbMsq+va8zyLCxOJqqp837ffu8AN3r9/v7u7e3R01J6uXEAB2JUHMEdASGZY0vd9tmQURTSD pFKqLMskSTzPo2l3aXKgsiyDINAv+sa0aQJ4//49T5jW0KWAArArD2COgJD0WpKIooifStOU REnzpNEsQWRJ6nfzBEJJkvADi5mEgFPolmR2dnYODw8FFIBdeQBzBISk15LUBoyiiNqJNM+u 53kkyiiK6BmyJKmQ5y1X5/e90WecBJKAJYEhAkLSFwNFM55FUcRHYCaTiVKKRirpAR29YUty W5JBW1IAeluS5Hh6ekovCSgAu/IA5ggISa8licYh7CAIgiCgB3RDG92SVVXRuKRS/x7WxLik AOjozfPnz1mOjIACsCsPYI6AkPRa8uJ7B8e4xSOgAOzKA5gjICRLtGSSJDhfUjYCCsCuPIA5 AkKyREsC8QgoALvyAOYICAksCewRUAB25QHMERASWBLYI6AA7MoDmCMgJLAksEdAAdiVBzBH QEhgSWCPgAKwKw9gjoCQwJLAHgEFYFcewBwBIYElgT0CCsCuPIA5AkICSwJ7BBSAXXkAcwSE ZMiSURQNz8JLu6DvpSzLGpd1A2EIKAC78gDmCAhJryVpLp+ZlhzG932aNQNsNMfHx+2LuGsR BWBXHsAcASHptaTneXEc65akCdNos9M0zfOc7vpQVZXneTSpGk2e5nkeTXKBOYFksLe3154Q qBZRAHblAcwREJJeS+Z5nqapbsmiKEh/JMQkSWiWyaqqlFJFUdDUvHVd53nOD/R5fMGGQpZs z58moADsygOYIyAkM2ZOoznQ6AH3wWk63jAM6RmyZF3XjQl36/Pbhykgl//+fLb2EK++PIA5 SrAl67putCXruqbpI/n+NmVZqu8tSU1IBm1JGTTaknz3GwEFYFcewBwBIZnPkkmSKKUmkwk9 oF3Alqy1mzrQGzEuKQOyZPtOigIKwK48gDkCQjJkyYuDY9wyODk5ad9mthZRAHblAcwREJIl WjLPc5wvKRsBBWBXHsAcASFZblsSyEZAAdiVBzBHQEhgSWCPgAKwKw9gjoCQwJLAHgEFYFce wBwBIYElgT0CCsCuPIA5AkICSwJ7BBSAXXkAcwSEBJYE9ggoALvyAOYICAksCewRUAB25QHM ERASWBLYI6AA7MoDmCMgJPNZct7QtJeP4zjP87k+BDiLgAKwKw9gjoCQLLct2f70qqp831/I h4PVMJ1Op9Np50sCCsCuPIA5AkIyw5KTyYSm/1FKFUVBS8dxrJSi58Mw9H1fnc+8y5On0RXc NG8QTdbL13QHQUBz9IKN4P3790qp/f394+Pjhi4FFIBdeQBzBIRkhiV55l3eYLJeVVV5npMl wzCs65qmm+T3e55HVqXp1CaTCb+EiYI2C7Iko+tSQAHYlQcwR0BIZve4aUJydT4db5ZlpEXa fpYjzc6bZRm1NLntWVUVtTp93yfbpmnamK8XbCL7+/tq8wvArjyAOQJC0heD5rPUJFRdbUnd kkqpPM+pBUoL8CfQTSBqtCU3jUZbkjg4ODg5ORFQAHblAcwREJIZlqSDLVQY1Jasvx+XJDnW 55akhmcQBEEQkDSpRam0tiTGJTcL3ZKN0UkBBWBXHsAcASExbUsyelvS87x5dxmOcW8c79+/ 7zx0U4soALvyAOYICEkjBtPp9Pj4eH9/fygcPPKYZdm8uyxJEpwvKQYBBTBXeQALBISEYjAe j4+OjnZ3d78NPK1734INQEABmJQHuAgCQqKU+k6OsCQwR0ABzCyPde/jjUdASJRSJycnBwcH o9EIlgTzIaAAZpbHuvfxxiMgJHoMvtPlGncr2BQEFIB5eQA7BISkHQM6gINwgNkIKIB5ywPM i4CQzH0mEACMgAKwKw9gjoCQwJLAHgEFYFcewBwBIYElgT0CCsCuPIA5AkICSwJ7BBSAXXkA cwSEpNeSfIE2AH0IKAC78gDmCAhJryWVUrAkqOv69PT08PDw5OSk/ZKAArArD2COgJCgLQlm wHMCjUYjmjCNXxJQAHblAcwREBJYEsygPb8k61JAAdiVBzBHQEhmW7LjGm8Azq//X3uC11Ie wBwBIemLAdqS4N/gvjfgIggICSwJZoB7KIKLICAkvZZc8a4EzoL7cYOLICAksCSwR0AB2JUH MEdASGBJYI+AArArD2COgJDAksAeAQVgVx7AHAEhgSWBPQIKwK48gDkCQgJLAnsEFIBdeQBz BIQElgT2CCgAu/IA5ggICSwJ7BFQAHblAcwREBJYEtgjoADsygOYIyAksCSwR0AB2JUHMEdA SHotWRRFGIbm+6Jz+TiO8zy338HAbQQUgF15AHMEhGRhbclOS1ZV5fu+za4FzjAejzun4K1F FIBdeQBzBIRkRltyMpkEQaCUCoLA9/04jn3fV0p5nleWZRiGNE9MGIa0fJZl/Ax9UBAEZVmu 8EsBC4ZmuxiNRoeHh6enp/pLAgrArjyAOQJCMsOSaZoGQVDXdZIkZEnSH71Ei5ZlqdS/lw/D MI5j/YOSJMHcQhtNY+a0nZ0d1qWAArArD2COgJD0WjLPc1IeOa4oCrIk/UgP0jTl5iRZkhaj tudkMqnrmhbrmcgVbDA7Oztq8wvArjyAOQJC0heDf1uy3ZbULel5XlVVJEFant/veR4dt0Fb ctNp39GBm5MCCsCuPIA5AkIyw5L6uGQQBA1LUrMxDEPP86hdyc1GbktiXHLTYUvqfW1CQAHY lQcwR0BIei1J/+ltySiK5t1BOMYty42caQAAHmdJREFUALrTbOO4DSGgAOzKA5gjICQzLMlt STqoPe8OSpIE50sKRkAB2JUHMEdASGZYEoABBBSAXXkAcwSEBJYE9ggoALvyAOYICAksCewR UAB25QHMERASWBLYI6AA7MoDmCMgJLAksEdAAdiVBzBHQEhgSWCPgAKwKw9gjoCQwJLAHgEF YFcewBwBIYElgT0CCsCuPIA5AkICSwJ7BBSAXXkAcwSEZMiSYRgmSaKU4ukqaAbJyWTCUwE1 5kkDW4WAArArD2COgJD0WjLLMroEm2xYVVV9bkmaR7I+v0w7y7JV7nTgDgIKwK48gDkCQtJr Sc/ziqKgjWxMvquUovl+6rqmZcB2IqAA7MoDmCMgJL2WTJKEN7IsS2ozUluyPc1P70ytQDpr T/BaygOYIyAkfTFQ3EhUSlVVlee57/tBEDTakmVZYpLdrUVAAdiVBzBHQEhMLVnXdRRFSqnG uCR5c2V7HDiFgAKwKw9gjoCQzGHJqqo8z6Nj3DTppFLKYmpeIAYBBWBXHsAcASHpteSKdyXY RAQUgF15AHMEhASWBPYIKAC78gDmCAgJLAnsEVAAduUBzBEQElgS2COgAOzKA5gjICSwJLBH QAHYlQcwR0BIYElgj4ACsCsPYI6AkMCSwB4BBWBXHsAcASGBJYE9AgrArjyAOQJCAksCewQU gF15AHMEhASWBPYIKAC78gDmCAiJjSWrqoqiiC7iVkrRNd1xHOd5vpTdDFxFQAHYlQcwR0BI bCxJQkyShOa5SNM0TVOakXcpuxmslfF4fHx8PJ1O2y8JKAC78gDmCAhJryU9zyvLMo5jmtWC J/6ZTCae59Xn85bXdZ1lGc15EQRBWZar2vlgRbx//54ysLe3d3R0NB6P+SUBBWBXHsAcASHp tSRPS964YUNRFNTF5rZkFEWNZ4Ak2JLM7u7u8+fPT09PBRSAXXkAcwSEpNeScRxTV5oKg+8C RvNL1uc3vVFKBUFAr+rLA/Hs7OyozS8Au/IA5ggISV8M/m1J+qEsS3U+P7nelmQ5UnsTbUmR NNqSOzs7h4eHp6entYgCsCsPYI6AkMywZPuOsjwuyW1JkmaNcUmhkCV1OTICCsCuPIA5AkLS a8mBze486QfHuKUyHo9PTk46XxJQAHblAcwREBIbS9L5ko0nkyTB+ZLbhoACsCsPYI6AkNhY EgBCQAHYlQcwR0BIYElgj4ACsCsPYI6AkMCSwB4BBWBXHsAcASGBJYE9AgrArjyAOQJCAksC ewQUgF15AHMEhASWBPYIKAC78gDmCAgJLAnsEVAAduUBzBEQElgS2COgAOzKA5gjICRzWzJJ kqIo6HEURXzlYgOa+cJ8V4ZhyB9L0Cy/5p8AVo+AArArD2COgJDMZ0ndXDT9T58l56Vtybqu 4zhuzNsGVo8+oWQDAQVgVx7AHAEhGZrtgua50JuEPOtPWZae58VxrFtSfwuRZZlSyvM83/fp MU2QEccxT5ZBy5MlG780z/P2pZBgxezt7XVOdVGLKAC78gDmCAhJryU9z6uqimzIM/2QyyaT ie/7eZ6naapbUmlT9pIlPc/L87yqKs/zyJJFURRFof9WUiR9svp+0l+efwiskb29vca0ady6 FFAAduUBzBEQkl5L8nxoel/Y9/2iKMh3jG5GnmaNZ+TlD6F31XVdVZVSajKZxHHM9xej39Ke 9JfeooBj7O7uHh0dqc0vALvyAOYICElfDIbakrxQoy1J0JS9fW3J+tySaZrSEGcYhkEQ6J/M k/6iLekCeluSGI1GBwcHJycnAgrArjyAOQJC0mvJ4XFJomFJfcre9rgkNy3JkqRCpVQURZ7n kSUbk/5iXNIF2JIsR35JQAHYlQcwR0BIei3Z+ey8Z+fobUmLacxxjNsFDg4OOg/d1CIKwK48 gDkCQjKfJevvz5ecCY9gWpwwVFUVj40CNxFQAHblAcwREJK5LQkAI6AA7MoDmCMgJLAksEdA AdiVBzBHQEhgSWCPgAKwKw9gjoCQwJLAHgEFYFcewBwBIYElgT0CCsCuPIA5AkICSwJ7BBSA XXkAcwSEBJYE9ggoALvyAOYICAksCewRUAB25QHMERASWBLYI6AA7MoDmCMgJL2W5Auo0zT1 fX9gF8y7yxrPxHGc5/lcHwIcQUAB2JUHMEdASHotSeaiOSkGLGmxyxrP0HS8i/p8sEoEFIBd eQBzBIRkqMdNs+0mSaJbjC/NpousaYozmiYyCALf9+M4pknIaYYLnuaHl6fZ2Ei+VVXVdR0E gcVcGGDtCCgAu/IA5ggIyZAloyiiuS10S4Zh2JifnGeKJJ/GcUxCDMOQp1mjNqm+/GQy4Q9p TMgGNgUBBWBXHsAcASHptSTNAsmwGUma1HKcTCY8myS/xD/yLJPcnKRdRtOvUVuSmpA8sTnY RNYe4tWXBzBHQEL6YvDt2UZbkqG5I1VXW1K3JM15ThIkq/InUFu1RltyYxFQAHblAcwREJK5 LcmNPm5L6uOSQRA0LEkNzzAMaZhSKUV3AVNaWxLjkhuKgAKwKw9gjoCQ9FrS/OwcvS1pcQMG HOPeXAQUgF15AHMEhKTXkua+47ak3W0bkiTB+ZIbioACsCsPYI6AkMzucQPQh4ACsCsPYI6A kMCSwB4BBWBXHsAcASGBJYE9AgrArjyAOQJCAksCewQUgF15AHMEhASWBPYIKAC78gDmCAgJ LAnsEVAAduUBzBEQElgS2COgAOzKA5gjICSwJLBHQAHYlQcwR0BIjCyZJAldcE2XGNIFiMk5 nc/XdU1XefN8Fp7n0TxAfReGg41DQAHYlQcwR0BIjCxJ8/rU5/OW02U5NDFa5/NZltV1HUWR 53lkTLr6myYWgiXFIKAA7MoDmCMgJEaWpHlz63MD0mO6HrHveZoIoygKejJNU5JmURSwpBgE FIBdeQBzBITEdFySndjQX9/z3MwMgiDP8zRNeYogWFIMAgrArjyAOQJCYmrJKIriOKY+NU2P Ro/7nueZd9X5NL3U3Q6CIIoisuTM6V2B+6w9wWspD2COgJD0xaD5LA0s8vEZpZQ+4Nh4vqoq PlZDj9mSC7/dGFgjAgrArjyAOQJCYmpJ/YA1Pabpzjqfp1FIfm8QBGzJ+nxK82V8H2DFCCgA u/IA5ggIiaklAWgjoADsygOYIyAkvZbUoeMwADQQUAB25QHMERAStCWBPQIKwK48gDkCQgJL AnsEFIBdeQBzlnJqxcrp3rQV70qwiShYEmwxCAeYDSwJthmEA8wGlgTbDMIBZgNLgm0G4QCz gSXBNoNwgNnAkmCbQTjAbGBJsM2oIAjo6mx1PplFrc2wC0ANS4LtRtFckDRrpFKqqqoalgTf A0uCbUbV5xPoKqXiOKZLuWFJoANLgm1G1XUdx3GWZUqpsix938+yjCy5kiuCwGawdpHBkmBd fNeWrKoqz3Pf94MgQFsSMLAk2GYU3xtWnQ9KRlGklIIlAQNLgm3mu2PcZEm6NwMsCRhYEmwz CAeYDSwJthmEA8wGlgTbDMIBZgNLgm0G4QCzgSXBNoNwgNnAkmCbQTjAbGBJsM0gHGA2sCTY ZhAOMBtYEmwzCAeYDSwJthmEA8wGlgTbDMIBZgNLgm0G4QCzgSXBNoNwgNnAkmCbQTjAbGBJ sM0gHGA2sCTYZhAOMBtYEmwzCAeYDSwJthmEA8xmKfcbc4x172PgLggHuCi7u7vrXgVTjo+P j4+P170WYMOAJcGFOD09VUqdnJyse0WM2N/f39/fX/dagA0DlgQX4vDwUCl1eHi47hWZzXQ6 pc71dDpd97qATQKWBBdiZ2dHKbWzs7PuFZnN8fExWRKdbjAXsCSwh7rbxOnp6bpXZwb7+/u0 quh0g7mAJYE91N0mHO90c3cbnW4wL7AksIe624TjnW7ubqPTDeYFlgQXQlePy51u7m6j0w3m BZYEF+L58+dKqefPnz9//vz9+/frXp1enp/Da7vuNQIbAywJLspmXbiyWWsLXACJAbXv+3pv tCgKfuz7flVVRVH4vk8Ll2XpeZ7+9s3yTmNty7IMgoA2NgzDyWRSVZW+N7IsS9M0juPGwkmS rGkLwKrZpHyDJUEq5B91J8ZxnCQJP5Nlmed5DdFstCV93ycD1nUdhmGSJFVV8ebnee55Hlly Mpn4vp+maV3XVVUFQUCPgXg2Kd9gSQxbMs9z3ZLU0tTfvrmWLMuSt5RpWJLMSPshCAJerPEj EMwm5RssCb3HHYah3uOmLqfuTeqQ6m/fXEtmWRaGYV3XvMlhGDZ63EVRkCWzLONWZ/29TIFs NinfYEkMtCXTNA2CQKoli6LQ24NFUZAlG/pDW3LL2aR8gyUxbMkoiqRasv5+XDKKogFLYlxy a9mkfIMl0TjGnWWZfoy7LEvBliTf6d3tPkvWOMa9rWxSvoGbbLQlAZgJEgMuymZ5Z7PWFrgA EgMuhN5VPzo6Wvfq9KJPzKGcn5sDOAUsCS6Erp7xeLzu1enl4OBAX9WDg4N1rxHYGGBJYI8+ 0Y7j9wg7OTnRLbkpN+oBLgBLAnuOjo42ortNjEYjWtXRaLTudQGbBCwJ7BmPxxvR3Sa4043u NpgLWBJciN3dXfe72wR3utHdBnMBS4ILQZ1u97vbxGg0QncbzAssCS4Edbrd724TBwcH6G6D eYElwTfU+nB/Dc1XEggDXzz4hlLq7MvX1f+by5JrWcO5VhIIA188+AYsCUuCNvjiwTdgSVgS tMEXD74BS8KSoA2+ePANWBKWBG3wxYNvwJKwJGiDLx58Y6aDfsnf8Gkxo0uXf8nfkD6Yp89e nH35ev/BQ32xt+8+rMCST5+9GF26/OnzGa3nlZ2r9Py16zfu3L1Hj2/eun3z1m1e/v6Dhzdv 3eZV5ZdgSaCDLx58w8SSbJ+Xr16TlZRSv/728ezL17fvPpA67z94+PLVa1rs0eMnLKllW1Ip df/BQ309aZWUUmRPciKtG1uSfvz0+eza9RtkeVgS6OCLB9+Yy5LUTPvxp5/ZkuTER4+frMuS d+7eI03zetL63Ll7j/R389bt+w8ektwbljz78vXHn36+dv0GLAka4IsH35jXkqQY3ZKkHr3H fWXn6sp63PcfPHz67MWVnau8niRN1h+t8J2792jJhiUbWwdLAgJfPPiGRVuSRir1tiTZh9Rz 89btgT7sMix5dj4QSa7Ux0x//e0jOfHX3z6OLl0mVzbakgNDk7Dk1oIvHnxj4eOSnz6f8UGe lVny7bsP1IalBiO9So/ZiTyIiXFJMBN88eAbcx3jpsbaWc8xbm6gvXz1+srOVTp4shpLUpP2 ys5V/fD6jz/9fGXnqt5yvHb9RuMY9/D4KSy5teCLB9/A+ZKwJGiDLx58A5aEJUEbfPHgG7Ak LAna4IsH34AlYUnQBl88+AYsCUuCNvjiwTdgSVgStMEXD74BS8KSoA2+ePANtT7cX0PzlQTC wBcPAABDwJIAADAELAkAAEPAkgAAMAQsCQAAQ8CSAAAwBCwJAABDwJIAADAELAkAAEPAkgAA MAQsCQAAQ8CSAAAwBCwJAABDwJIAADAELAkAAEPAkgAAMAQsCQAAQ8CSAAAwBCwJAABDwJIA ADAELAkAAEPAkgAAMAQsCQAAQ8CSAAAwBCwJAABDwJIAADAELAkAAEPAkgCAbqqqUhpxHNd1 7fs+PxOGYeMtZVkGQcCvTiaTNE09z5tMJnVdF0Xh+/5kMgnDUP8E/V1pmq5+S4eBJQEA3VRV 5fs+P/Y8ryxL3/eLouh7i+/7JNO6rsMwTJIkTVM2LFkyTdMgCGiZIAiyLIuiKEkS/i1VVS13 w+YElgQAdDOvJenVxpNpmkZR5HleURRkySzLgiAoy5KXieOYGp5L2pALAksCALqZ2eNuNPqy LKMedFEU3KFO0zSO4zRNSa+k0TRNqdMdRRHJMUkS6nS72OMGAIBOuC1JdiMnDrQli6LgrjT9 yJas6zoIgiiKGo3NOI6pr834vp/n+bo3/XsW7l0AgAz0Hje1/upBS9bfj0tGUaRbsixLpZTv +1EU8TJJkiRJ4nlelmX0TBAEeZ4vb6MsgCUBAN3olqzrmg68DFuyqir9GHdVVWzJuq6TJKE2 KS8TBMFkMqG2Kj3DC7sDLAkAAEPAkgAAS+gsH/EjeDK3CgAAFgUsCQAAQ8CSAAAwBCwJAABD wJIAADAELAkAAEPAkgAAMAQsCQAAQ8CSAAAwBCwJAABDwJIAADAELAkAmAN9Fl6a0SeO44FL ufkWN+r8Ljc0S5DneTxDWpZlnuetekuMgSUBAHPA0/HWdR0EAU9F3rd8GIY0d+RkMqHl6S0E LcP3vXETWBIAMAfWlqzrOs9zfktRFNx+pLviLHvNrYElAQBzMNzjZiEyuiX5HorUiqTbjeV5 7nJ3u8Z9bwAA5tTnbUmaxpwagHO1JfV7PCQaTstoFSoGAEiBe9zUZaa2pMW4ZF3XZVkGQUAt ypWtvwWwJABgDvRxyTiO6VZfw5bkNlkURfX5MW7+tPYtvF0DlgQAgCFgSQDAwhB5JxwJ2wAA AMsDlgQAgCFgSQAAGAKWBAD0UlWVPshIx6b1E8vp0mwdPpZd13VZlkopOgKe57lSik/6UUrR h/Pxcf3MSqeAJQEAvdDZ4/yYzm3k88k7IXtOJpP6/GAOeTCKIs/z+HpttiQ9qGFJAMAmYmfJ IAjId0EQ0Jnkk8lEKaVfu82WjOOYGqSwJABg85jZ4+YzzBlqPEZRRJfW0DnnaZqSCoMgoAnT 2JKk3SzL3LUkAAD0wW1JmqiCnDizLUnDkXSBNllSvwKHVKvOLVlVVZ7nvu9TC3Q92znMynwM ANg49B43twdnWrKqqiAIlFJlWZIl6Yrv+rzbTh1wtmRd11EUqa4phVwAlgQA9KJbsq5rmvfM xJJkxvp8xiA+6l3XNbcZdUuSPWFJAADYPGBJAIA9Ii/cbiBwkwAAYIHAkgAAMAQsCQAAQ8CS AAAwBCwJAABDwJIAADAELAkAAEPAkgAAMAQsCQAAQ8CSAAAwBCwJAABDLNeSpx8//uWvf/vd 7//wu9//Ye/P4fHP/5rr7ePx+Ir/w7zv0rni/3DF/6H9/N6fw9/9/g/PX/xX4/mj1//83e// cPT6n3VdX//jn2jNG/8O/uM/p9MpLf/3J//oXOZ3v//D35/8Q//k45//Rb+UPqG9Skev/3nF /+F3v//DFf8HWoE+/v7kH9f/+CfzncAb8v7DB/N39aHvor7V03/XdDrt3F5rTj9+HN4/S2U8 Hj9/8V/8LV//45/WuDI6jd0OFsgSLfn+w4e2O8yVNx6PqbzH47H1Ouz9OWxb8uTNm06R1XV9 /Y9/uuL/MJ1Op9Npn/7I+LQ8/w1o/9OLh8yi//vLX/+m/9725/TVHpVoe837oF9Ne/Iif2+Y mdVI20Lf2ng8bm/sRTj++V/Djl4q7e+R83CRlC4EfbeDxbJES1JlcjuCEtbZsmtDxWC+fB/U fOOmn/5ku01Ha0gNTFJ8u7zH4zG9vU8T9Ma9P4f8S1nKVNv8CacfP9ICJL69P4f0zMmbN51N 4Ol0yjI11wR5f4FyoQ80XJi2vd1mt4b21cmbN4v6wHl/NcWGZcRdBP7DCeSxLEtSeTSiQ0U+ 3CnQO+kXb4a0LUkr1jA4wQ3JerBfOfASDRHoiqzP/1roy+vOOv34kf4Y6G9pt9carRjDjhV7 n9x98Z4vNbHN+/u0AgtpwxLrajFRbK74P3QKmmK2wM0ETqHqVi/m+h//dP2Pf+KWC3lqOp3q wzF/f/KPRgOtAcmuoZKZnTXqoFEcD/7jPztlRNIx1AR9CLfaai3QDYnrDUle1c7cD1Q+dfD1 GqZfNKAV2quN1lbjV/Do51/++re+kdZO2Pu0Yxt/tOjJvz/5x+nHj7RbaG83vmt93ci2f3/y j/F4zH/M9AX0LNEwa6NPYBKko9f/5LHUv/z1b7QA/Tlp/PnsbCPrrV1a4Pjnfx3//C9aH0rO 6cePlI3fGQwE1+ep6/MgOXRglabT6RX/B47B8E7o/F6GP7P9S49//lffIQF9TfQd2/jTPtfY t2xU3ZLXFf+Hv/z1b7yLj3/+Fw8RNsZi5v1lemOtk/cfPuz9OaQvm2LUyCVrdNjRTMOSlOaD //hPSoa+CY11o3R2tln6Rks7o8yu102nv7fz0xqW/Mtf/0Y1M1dTjj6ERzDbemXl8Zc7Ho87 v2v+EP5M3YD6VtNmnrx5w9/U786PctTaWPNAkNpDtLQAD8Loq9T+u9sYCeU/fvpq8BhI5za2 4VGUgb3N6qGFG3/2aAV4yGV4J7S/F9r2gc/k3a6/1PjHcWqMmfDCXCYzD9BtG6r+vlDpGyJR cumSMvjYLjcz59qP9EWaD1EtpG9FkuIq4gFB0g1npT181tlk40GodteV+9qN58kmjaqgpnrd X36N0DNcPybbTr+Uo9/2Po8U65tDi3ELjgZJ+Y3seg4DfQh/QuNbazRbZgapMUTLY7hU4e3N b/+NIaHwMvT5emuRvin9l3KTTe9z6JhYgwPTPmDVaEjO3Ant72XmZ+q7nbsvrEVqRzdWgBsE lNtGVNCQ1FGN5gnvYt6Jja4oQW0x83EustVcg4yNArNDH+znhmR9Pr7GHmykpNG5a//Zb7dk aQMbXuPP2ftzSC81+rad+7ae1Vw1Gf9qyKvuanbRM/qX0jmarCu7PcZKb9FbrPytNaQ2M0hU +Y3eht6Mamx+Z8u60QVpr3DnNzXsQZOTbPQNb0RXD6FJNbW/l+HPbLza2WPTO1X6Y97wRpmg IamjGlGmb0jfRwMnu5hYkpsD5iev1Is7g0QPU0OF/MdftyfR6Nzxv/ZIK9HuvxM85N8+fESb 1jmqwLJo/yLDc+Km02mjIVl3iaC9TF8blqAvpbFiurloPzR6u/q4wXCQOvuVOo2GamfLun0e UkOjjbEC/V+fGtqj2w0aZ0TQ8DE9pm/T5NQxTmD7exn+TH23d55+x//oMyl1lKLrf/wT/Qnn 751+keGI1pagGsXT7pcNpGqmJbm/1hBBowfaFuiizlzhsZu2CmnFptNpu7fVKa8BOpsndWtk kKAWEEW8MSBA0LZ37lvDs3A6h6XoHzuosyHWeeIUM2Al2nuNb422Tu99Dwdp5lk+jfZUZ8ta /wPTaOfWsyRi3ZbUhwh5edrwdqNveCf0DT0PfKa+2/vO6NQtyS1H2j/HP/+LdsvR63+ScBd4 5pYMVOOQcWNwTS/peeHOe+OvYvuE7XY6F3UhAf8NaKuQN7ytJJMzlvTN6Rsc6HS97hrazMb+ oVVty8KwfU3r01cn/PbOgwzDB9BnWqnRFNWPk5oEabjJxkd++Zn210Q7vNGY1fek3fmbfQMj vGKNgQL+vY2utMlO6PxeBj6z/n63m5xPyrE8+I//pC+IPvPo9T/p7Tg1vYH6ndaH6mwstCuH YjE8aMin2tg13Rd1Whxliz6toUI+TNGuzLnOthkY0hpQMLmm7Z2BM4cMD910nlpUtxopncpr t1X1ZnW75dsQd7u3q6/tzCC1/zTqjUE+p2fgA/Ux37orRZ0XCzQO+LThoYZ2IHlAqT1WSxpq pGvmTugbeh74TH0zO9PYOK2NW45X/B8oJ2zJxqE8QCg9NO0g1q0DL8c//2vm5W7cvLIe3VjI oZv6+w5IZ5OtbbHOwawBhoWuHz3go5ncmqC8Xv/jn/Sjk31tAZNDN50HQJh2u6+x2vRdsy9I kY3DAvryjcay/q21DwLMDBL/SaOV5zMc26NpdatddvLmDX+hvEznSX+N4zl8QHn4TzL9dtYK P0lr2NAuN/fa6Zq5Ezq/l+HP1Hc7X6RAEaKL6BsNWFpGP0LIBzMH2vLbjPpd61Tqxm7iMyf0 f8N9lr7BEcMGWt8B9PaRpZmwd9qfxicVN3rW7cGsAWYqtX0g6Ir/Q7shYLJvZx5DqPsbkvrv ok/oHOJsH9znte08L11v/XUeutH/PpkEqX0iYWOUU09R49P2/hzq46q0wu3vvfPQnMklj7wC jX+dUaE/SG35ztwJA0PPnZ/Z2O111wws/GeY4CGvxlBA5+4CNVlSPwrZ+Q3NO7VP34E8wwZa 36Gb4QuoO+Hzh9tyaf+NJeY6pdakF6w3c/RLgBk+2DK8b2ceuhluSNbfD2DRKbHtZfTv+i9/ /Rvvt84tbV/lwvtNv+qc12dmkLjt017g9ONHcqjefmSrPn/xX40BYu5XtrdRn59J38aZ6Be0 0N7o0yutWOefq+Gd0Pe99H1mZ7Ecnc8v9bueq5voVX3l288ABvNLAgDAELAkAAAMAUsCAMAQ sCQAAAwBSwIAwBCwJAAADAFLAgDAELAkAAAMAUsCAMAQsCQAAAwBSwIAwBCwJAAADAFLAgDA ELAkAAAMAUsCAMAQsCQAAAwBSwIAwBCwJAAADAFLAgDAEP8/jCU7ue8rTr4AAAAASUVORK5C YII= --------------477E8FB3A06F26D262C6CA65-- --------------F601CC03C158E99FC09DB999-- --------------ms000809050302040407050507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Signature cryptographique S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC C2AwggWCMIIEaqADAgECAgIYEjANBgkqhkiG9w0BAQsFADA9MQswCQYDVQQGEwJGUjEMMAoG A1UECgwDQ0VBMSAwHgYDVQQDDBdDRUEgQUMgVXRpbGlzYXRldXIgMjAzMTAeFw0xNzExMjcx MTUzMThaFw0yMDExMjcxMTUzMThaMFUxCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANjZWExFDAS BgNVBAsMC1V0aWxpc2F0ZXVyMSIwIAYDVQQDDBlQRVRSRVNDVSBBbGV4YW5kcmUgMjIyMDQw MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxflZNm4uFO1gfpGFsdm8+ijK5FnS fr24rrT8KW0oz8cV8u+UZ55M/bqidvqSXGGz3C480T6DZsfXoTsvqD5ZLE+F8II6J2g5NU8J mKX95WafZuQo8DC2EnkDu2jH0kU58PGyJqzlQ1ThJw+E90C4yg55q5ekRRv13L7W4D38+eO6 2LLQyplKiyjXJRFnrYPCQWKdmaoa3+gXm88N0z9SH1VnKDB7nN0WKcgkB8xFFW9ShkDriTj4 WOtBlX5I49L6nc2f5jgRR7ur63vWwWV57guJDYgdbciTIMsoanyOMkblfZko71HlcYOQcext cIzx7W14tLdo5Lbk5sbTLTPCUwIDAQABo4ICcjCCAm4wHQYDVR0OBBYEFJiCut4KQg9+Gt1J iu2nte1qatj0MB8GA1UdIwQYMBaAFOEcbJodbegbsvFP/cZ0LCdXBYhzMIHIBgNVHSAEgcAw gb0wgboGCisGAQQB4GABBgcwgaswJQYIKwYBBQUHAgEWGWh0dHA6Ly93d3ctaWdjLmNlYS5m ci9wYy8wgYEGCCsGAQUFBwICMHUwDRYDQ0VBMAYCAQICAQAaZFZvdXMgZGV2ZXogYWNjZXB0 ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBjZSBj ZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAkBgNVHREEHTAbgRlhbGV4YW5kcmUucGV0cmVzY3VAY2VhLmZyMFEGA1Ud HwRKMEgwRqBEoEKGQGh0dHA6Ly9jcmwtYWMtdXRpbGlzYXRldXIuY2VhLmZyL2NybC9jZWFf YWNfdXRpbGlzYXRldXJfMjAzMS5jcmwwcwYJYIZIAYb4QgENBGYWZFZvdXMgZGV2ZXogYWNj ZXB0ZXIgbGEgcG9saXRpcXVlIGRlIGNlcnRpZmljYXRpb24gYXZhbnQgZCd1dGlsaXNlciBj ZSBjZXJ0aWZpY2F0LCBjZi4gd3d3LWlnYy5jZWEuZnIwUAYIKwYBBQUHAQEERDBCMEAGCCsG AQUFBzAChjRodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvY2VhX2FjX3V0aWxpc2F0ZXVyXzIw MzEuY2VyMA0GCSqGSIb3DQEBCwUAA4IBAQC77Z707Ko1uZGK3utBHUQUUyTD4pRjmFxFozU2 kwdk6a8hdHTaaRqjPSUIbfeoZVpZCynd12VynalWcoXM40Bf+bhMN3pAavULka7+oAEQyYuI 7OQ8dE/t3R43Ai8dx0npk+ziPQrlD7tAgMsK8Qd+V7ZhUI0A1ANJXWzZ7DYV6jR4t9nwxlsk Kll2PaD+hTIiP86YVsiHMiu0ZhRGrYJf/U1myMQc28b4LdTofpwh22z8DLHlFoGjGipwYbpb oFn998AOsc2fvujB0Y+AahlKK8lecqOTXJNQaRUrE1dl/n2Xu8GK3KIRtcoo7QTDOTzx/BiN 5EC8XdsqNMRXmc1GMIIF1jCCA76gAwIBAgIBCTANBgkqhkiG9w0BAQsFADBeMQswCQYDVQQG EwJGUjEMMAoGA1UECgwDQ0VBMRcwFQYDVQQLDA4wMDAyIDc3NTY4NTAxOTELMAkGA1UECwwC QUMxGzAZBgNVBAMMEkNFQSBBQyBSYWNpbmUgMjA0MTAeFw0xNjA0MTkwNzM0NTNaFw0zMTA0 MTYwNzM0NTNaMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBB QyBVdGlsaXNhdGV1ciAyMDMxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvWDF ixM71KL9p38YSLTYgXRTceZWAD0RSg7NylBGPXNHYbceuGKDhRIeX58FIi+JiVFFejFI6jpE impm3MgsXQ5O08clieLLBNCjVzpAMPTO5lXuz0j28ey5AVPwhEw7ngUCtmHaWh8v1eY6xrLV C/porFjHycFbd4oj6QLfyghoo/RXWglYPNjilkCBrRe+jKxM3QYYVD6rouvGrF58SlpGCfwX FA88OcYC24kH8YOOYvh8Ld/p+ty7QUiDq53YmVZ5iDUc3pt3r9pN61zJ83FPEhZbC8+KHDTb D0TXaot2No4u8wk0s0jBpicVN4hxfS+LiFcTsFmsorDW6L7GIwIDAQABo4IBvjCCAbowDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU4Rxsmh1t6Buy8U/9xnQsJ1cFiHMwHwYDVR0jBBgw FoAUoBGJ+Jq/poSxKQc3U0Htl5VCex0wgcgGA1UdIASBwDCBvTCBugYKKwYBBAHgYAEGBzCB qzAlBggrBgEFBQcCARYZaHR0cDovL3d3dy1pZ2MuY2VhLmZyL3BjLzCBgQYIKwYBBQUHAgIw dTANFgNDRUEwBgIBAgIBABpkVm91cyBkZXZleiBhY2NlcHRlciBsYSBwb2xpdGlxdWUgZGUg Y2VydGlmaWNhdGlvbiBhdmFudCBkJ3V0aWxpc2VyIGNlIGNlcnRpZmljYXQsIGNmLiB3d3ct aWdjLmNlYS5mcjAOBgNVHQ8BAf8EBAMCAQYwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2Ny bC1hYy1yYWNpbmUuY2VhLmZyL2NybC9hYy1yYWNpbmUtMjA0MS5jcmwwRwYIKwYBBQUHAQEE OzA5MDcGCCsGAQUFBzAChitodHRwOi8vd3d3LWlnYy5jZWEuZnIvYWMvYWMtcmFjaW5lLTIw NDEuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQALtUqrZEfol/oEtIOlM3SaHCPHblVt8TdY88IB 3qCpg5lJ8rWU7g8jAsc0moYYor0hrvb17XjXECYL76MOJBCQYEKfWnkTYqAyMTsKee+kK8Xw 5P8wzPPjXA3tUvRm8oHEGYcSfLEzdj+UT+F+E4MnkV1nUOCEJq2Krx+lu1IJQJRCbjUQF+ES ICwTDQE7FHzGGKVsGOEjkbYhDS/+4r5GPbc983y5d94S0ISYmM1klOSeRNGelcnl0fJbH0zs 1y8+YJWg3gWL1j7aNo+sQQCrPrYQnmufAm3HQr42+u0AbFvOX5XKwF1YAx7XpJWuUGeXkjqx 8xIWisShEc/S+Gm4mdKcUgym5C7gkA0nzbmBIJI3iSLRqk/m2Re7R5vC3fF3uyfT9mGeAnNa E9b7ZkBzhrSfFToylbvqnAYvxVcYFCE1XhVMHxKvRiiW9L/u9vHuAbTRaXBFzObrXF6UohLR XNqJKKaPYkRLgrVm6b303Ogp50u6DiSgvI4Dh7x9K9IqpJ/+csqdXpoVdhQjhcA5JZRNrv3q 0zVf/Q93GT3VHOgaeMkEa9Sn30x4GmZfuNon/zSagJZkLO72K3wa6XQbGf8MZP/QtSMGPzrN eVUgp4H6l9hcQINVHmimTrcZa7/22K0FD56epY/OqAXwIWOb9i+jdDIoW5c5pW+/BDDasTGC AvMwggLvAgEBMEMwPTELMAkGA1UEBhMCRlIxDDAKBgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VB IEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMA0GCWCGSAFlAwQCAQUAoIIBgTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEyMDExMzAzNDJaMC8GCSqGSIb3 DQEJBDEiBCDAGroQGEaKGiIsaam4IOYRwDs/AgYnI3hwBtNJspGelDBSBgkrBgEEAYI3EAQx RTBDMD0xCzAJBgNVBAYTAkZSMQwwCgYDVQQKDANDRUExIDAeBgNVBAMMF0NFQSBBQyBVdGls aXNhdGV1ciAyMDMxAgIYEjBUBgsqhkiG9w0BCRACCzFFoEMwPTELMAkGA1UEBhMCRlIxDDAK BgNVBAoMA0NFQTEgMB4GA1UEAwwXQ0VBIEFDIFV0aWxpc2F0ZXVyIDIwMzECAhgSMGwGCSqG SIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJ KoZIhvcNAQEBBQAEggEAnOPyaLM29iEnxxI0K6PKtFfPMCVjGCxvRni9yktaGv9nLA76ox0i 7JOcdVlyf0Xf6uweF6k1A2mqLZMgwBqNV+S7mTsMBB+eFqwUPFGXJghrrBUofFWlgvvh79zO 0j5eCyR4rK7Ria7DpUimVHPMD2yYQvpMErzDrdjjDoDBc5ZoQ4YRCrI1XEkBPOeU5xyw+Syn vE4mSZiaH3r76lS4JVsXOxcxaA+5dx6Yi6dIHBL1fB1oYgRzVzUqboV6SogAFCnMSKyPAnGZ TF0Bu5y7/lOrPr4tUnuBj5GxrximaWlJOou+tM8mkl8rT94LCEwntVvU4tHJOVShMXBBiSFH 6gAAAAAAAA== --------------ms000809050302040407050507-- From nobody Sat Dec 2 06:57:41 2017 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 670011286B1 for ; Sat, 2 Dec 2017 06:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dti_UNHmecXT for ; Sat, 2 Dec 2017 06:57:37 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226431200F3 for ; Sat, 2 Dec 2017 06:57:36 -0800 (PST) Received: from [192.168.3.67] (109-155-16-190.fibertel.com.ar [190.16.155.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2CC34826E6; Sat, 2 Dec 2017 15:57:31 +0100 (CET) To: Alexandre Petrescu , v6ops@ietf.org References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> From: Fernando Gont Message-ID: <6c73c369-c489-1ab6-e2e5-94cde2f75ae0@si6networks.com> Date: Sat, 2 Dec 2017 21:40:36 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2017 14:57:39 -0000 On 12/01/2017 12:18 AM, Alexandre Petrescu wrote: > v6opsers, > > We succeeded in making DHCPv6 PD work natively on a cellular link. > I would claim it to be a first[*]. > Packet dump available upon request. > > The UE device is a Huawei E392u-12 USB dongle produced in 2011.  It > hosts a baseband processor Qualcomm model MDM9600 (or model MDM9200, or > an Intel - not sure).  It lets all standard DHCPv6 messaging through. > The DHCPv6 client 'odhcpv6' is running on linux laptop. > > The mobile operator's PGW assigns a /56 and sets proper forwarding for > it.  The PGW runs on a big Cisco platform. > > After the successful DHCP exchange the laptop is able to ping google > with a src address which is manually derived out of the /56 delegated > prefix. Please send all the "available upong request" that -- either on-list, or off-list. This stuff is always good to have handy. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Dec 3 05:29:28 2017 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 F271A120713 for ; Sun, 3 Dec 2017 05:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGygAE-YLlQz for ; Sun, 3 Dec 2017 05:29:24 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5881205F1 for ; Sun, 3 Dec 2017 05:29:24 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vB3DTLkN092997; Sun, 3 Dec 2017 14:29:21 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C1156201B10; Sun, 3 Dec 2017 14:29:21 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B3E55201857; Sun, 3 Dec 2017 14:29:21 +0100 (CET) Received: from [132.166.84.99] ([132.166.84.99]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vB3DTLO4003216; Sun, 3 Dec 2017 14:29:21 +0100 To: Fernando Gont , v6ops@ietf.org References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> <6c73c369-c489-1ab6-e2e5-94cde2f75ae0@si6networks.com> From: Alexandre Petrescu Message-ID: <0ac3a909-fe27-75a8-848c-cd283f5f6005@gmail.com> Date: Sun, 3 Dec 2017 14:29:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <6c73c369-c489-1ab6-e2e5-94cde2f75ae0@si6networks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 13:29:26 -0000 Le 02/12/2017 à 14:40, Fernando Gont a écrit : > On 12/01/2017 12:18 AM, Alexandre Petrescu wrote: >> v6opsers, >> >> We succeeded in making DHCPv6 PD work natively on a cellular link. >> I would claim it to be a first[*]. >> Packet dump available upon request. >> >> The UE device is a Huawei E392u-12 USB dongle produced in 2011.  It >> hosts a baseband processor Qualcomm model MDM9600 (or model MDM9200, or >> an Intel - not sure).  It lets all standard DHCPv6 messaging through. >> The DHCPv6 client 'odhcpv6' is running on linux laptop. >> >> The mobile operator's PGW assigns a /56 and sets proper forwarding for >> it.  The PGW runs on a big Cisco platform. >> >> After the successful DHCP exchange the laptop is able to ping google >> with a src address which is manually derived out of the /56 delegated >> prefix. > > Please send all the "available upong request" that -- either on-list, or > off-list. This stuff is always good to have handy. The topology was the following: laptop --- USBdongle ---- SGW --- PGW ---- Internet ---- google.com The pcap captures are captured on laptop (not on USB dongle). The txt captures are on PGW. The pcap and txt captures are simulatenous, but serve distinct purposes. The pcaps served to identify DHCPv6-PD works, that ping google works, that there is Release, which 'modem' works, etc. On txt captures operator needed to identify DHCPv6-PD works, but also other things like 48req-56reply problem, ClientID-00 syntax error absence, prefix-exclude for double state avoidance, etc. I sent you dumps off-list. Alex > > Thanks, > From nobody Mon Dec 4 15:30:26 2017 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 69C0A128DF3; Mon, 4 Dec 2017 15:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yt0-4Ndjj07l; Mon, 4 Dec 2017 15:30:17 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD3D128D69; Mon, 4 Dec 2017 15:30:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2548CB80D91; Mon, 4 Dec 2017 15:30:01 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, v6ops@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20171204233001.2548CB80D91@rfc-editor.org> Date: Mon, 4 Dec 2017 15:30:01 -0800 (PST) Archived-At: Subject: [v6ops] =?utf-8?q?RFC_8273_on_Unique_IPv6_Prefix_per_Host?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 23:30:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8273 Title: Unique IPv6 Prefix per Host Author: J. Brzozowski, G. Van de Velde Status: Informational Stream: IETF Date: December 2017 Mailbox: john_brzozowski@cable.comcast.com, gunter.van_de_velde@nokia.com Pages: 10 Characters: 22867 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-unique-ipv6-prefix-per-host-13.txt URL: https://www.rfc-editor.org/info/rfc8273 DOI: 10.17487/RFC8273 This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Dec 6 03:00:54 2017 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 D3E1E1296B3 for ; Wed, 6 Dec 2017 03:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81pSJPlSLsn6 for ; Wed, 6 Dec 2017 03:00:47 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC5F4127876 for ; Wed, 6 Dec 2017 03:00:45 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vB6B0cr3012709; Wed, 6 Dec 2017 12:00:38 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5580A204B2F; Wed, 6 Dec 2017 12:00:38 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 450D3201C31; Wed, 6 Dec 2017 12:00:38 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vB6B0cuq013913; Wed, 6 Dec 2017 12:00:38 +0100 To: Ca By , Owen DeLong Cc: v6ops@ietf.org References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> From: Alexandre Petrescu Message-ID: <6bed89e7-d0b8-21cd-88f0-f689372e9cf5@gmail.com> Date: Wed, 6 Dec 2017 12:00:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6 and Apple iPhone LTE interface (was: reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 11:00:54 -0000 Le 21/09/2017 à 14:02, Ca By a écrit : [...] >>> But you cant have simultaneously CLAT and DHCPv6-PD on the >> same client. >>> >>> >>> I do not agree, Please state what is structurally preventing >>> this. RFC6877 specifically calls for using dhcpv6-pd >> >> RFC is one thing, but many implementations block some RFCs. >> >> What structurally prevents this is that there are very numerous >> Android devices. > > Say the same about Apple. Show me Apple running dhcpv6 on LTE > interface. It's hard to say. Before trying DHCPv6, an iPhone user can not set the PDP type; so it's not possible to set it to 'IPv6'. The operator does offer IPv6 and advises Android users to put 'IPv6' in the PDP type, called 'APN protocol'. Is there an iPhone app that could set the PDP type to 'IPv6', without jailbreaking? Alex From nobody Wed Dec 6 10:26:20 2017 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 E20AF124F57 for ; Wed, 6 Dec 2017 10:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ylm4cJve9ZRf for ; Wed, 6 Dec 2017 10:26:17 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8100A1241F5 for ; Wed, 6 Dec 2017 10:26:17 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id l24so2641956pfj.6 for ; Wed, 06 Dec 2017 10:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kpZOhd9XC2XEoOlcNqGNN6GC5DIrwaqI7F1/O5tB33I=; b=KYqv2UxHnKTNcWJA9rNrwujq9SX7F1sWP+mOyNlzVVLzAlckdqxdhi8iUVdmWxc62y Ov6nhHVrvCYPoA4JwikmUqKN8jIa9ROlDxipPIgc2eaxRfBH+tESUHiC+J4U0Hk5yeCH 6BCFZS4+2ZfWGbmxGYn4gqRKhQrbjww+8YfWeU9hs1LrRmEdODueg9Q5tCdQk1hQbVWb H/OnFfVwrBTrTIWHJPuqZGrSiENPtFmsDl9khN5KFwDCQtyHGkVFQW5yk4mgBgy/yYqs qlOx3n8kcO3k3D/suFlLZmheCTGs5LDP6fHgmAuwM4kn7Nj5fk5lFQ5F33qE88EFwHg5 gstA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kpZOhd9XC2XEoOlcNqGNN6GC5DIrwaqI7F1/O5tB33I=; b=ZFUE4HUL76X7h1P02tpWj1CjdpoZymOZd3Ec3wX3nSj0tgEl0MZVhV6ZNg/ZFWuAtn CiNKA0pAWHB5M/bWnsSTqBksI+Q0oW9TRIH6lZaHn4YSTMoWmrEgLwXfGgXXcRgYMlAy OJyOaj5qmR0+Lw3Ji7WJxXr+49zhRoooki9U41FwIQ5SnDWRedjihAGuIVacJq+IPTmQ 3LNYDchI1cuVeNFzwizPJmoV1055aClJ7ha8jnmsAMKbNH2OqWkKd8+TiFSqa1mqXQrT HQ6LxvX7Zx82wkqGrylAo01Zf+Es9vOWChQs6k+d79FZv0M3OmaSScwUc3tHEZuBm5ad HwiA== X-Gm-Message-State: AKGB3mI0Zf34sNBUrEAdpzUH8CaLkpelrwd216J3Iyz8ocdJZ2LUF2tz mE06xbX6/nOpmNXhoF0bNcMTCw== X-Google-Smtp-Source: AGs4zMYz08zaC5fM4GNubYsKwgH9V9ihC17rAQevhHCm/apMVKLaPIp8u3lz5la97XBYVlFCHhGpGA== X-Received: by 10.101.88.15 with SMTP id g15mr5192024pgr.361.1512584776858; Wed, 06 Dec 2017 10:26:16 -0800 (PST) Received: from ?IPv6:2620::10e7:10:c024:ab19:761c:7477? ([2620:0:10e7:10:c024:ab19:761c:7477]) by smtp.gmail.com with ESMTPSA id 83sm6887222pfq.12.2017.12.06.10.26.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Dec 2017 10:26:16 -0800 (PST) From: james woodyatt Message-Id: <9D3908C3-2665-43E1-AD1C-1C6EB8546C9F@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_15962CD6-E553-4AC5-BF43-1CFD8A646D34" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 6 Dec 2017 10:26:14 -0800 In-Reply-To: <6bed89e7-d0b8-21cd-88f0-f689372e9cf5@gmail.com> Cc: "v6ops@ietf.org WG" To: Alexandre Petrescu References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> <6bed89e7-d0b8-21cd-88f0-f689372e9cf5@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] IPv6 and Apple iPhone LTE interface (was: reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 18:26:19 -0000 --Apple-Mail=_15962CD6-E553-4AC5-BF43-1CFD8A646D34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 6, 2017, at 03:00, Alexandre Petrescu = wrote: >=20 > Is there an iPhone app that could set the PDP type to 'IPv6', without = jailbreaking? You need a carrier bundle to configure that setting. --james woodyatt > --Apple-Mail=_15962CD6-E553-4AC5-BF43-1CFD8A646D34 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii On Dec 6, 2017, at 03:00, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

Is there an iPhone app that could set the PDP type to 'IPv6', without jailbreaking?

You need a carrier bundle to configure that setting.


--james woodyatt <jhw@google.com>



--Apple-Mail=_15962CD6-E553-4AC5-BF43-1CFD8A646D34-- From nobody Thu Dec 7 03:45:26 2017 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 4D68512940F for ; Thu, 7 Dec 2017 03:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yf4wxRE4mDoi for ; Thu, 7 Dec 2017 03:45:23 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A422128BB7 for ; Thu, 7 Dec 2017 03:45:23 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vB7BjL81046162; Thu, 7 Dec 2017 12:45:21 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4024A202CB3; Thu, 7 Dec 2017 12:45:21 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 29DA3202B96; Thu, 7 Dec 2017 12:45:21 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vB7BjKvU022283; Thu, 7 Dec 2017 12:45:21 +0100 To: james woodyatt Cc: "v6ops@ietf.org WG" References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> <6bed89e7-d0b8-21cd-88f0-f689372e9cf5@gmail.com> <9D3908C3-2665-43E1-AD1C-1C6EB8546C9F@google.com> From: Alexandre Petrescu Message-ID: <4f3b150f-d136-53f8-9151-21ecd5ebf94f@gmail.com> Date: Thu, 7 Dec 2017 12:45:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <9D3908C3-2665-43E1-AD1C-1C6EB8546C9F@google.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6 and Apple iPhone LTE interface X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 11:45:25 -0000 Le 06/12/2017 à 19:26, james woodyatt a écrit : > On Dec 6, 2017, at 03:00, Alexandre Petrescu > > > wrote: >> >> Is there an iPhone app that could set the PDP type to 'IPv6', >> without jailbreaking? > > You need a carrier bundle to configure that setting. Yes I need it. That carrier does not offer a bundle to configure that setting for iPhone. For Android, the carrier indicates to the user the typical step-by-step Parameter changing of the "APN protocol" from IPv4 to IPv6. Alex From nobody Mon Dec 11 23:21:02 2017 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 56ADC1277BB; Mon, 11 Dec 2017 23:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0vkUT-ZGXGK; Mon, 11 Dec 2017 23:20:55 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CFC1241FC; Mon, 11 Dec 2017 23:20:54 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id a12so22018002lfe.4; Mon, 11 Dec 2017 23:20:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=H37ulJZoJ2bsC4KS3lsrCHbLt72+TS81HOOernS4rdg=; b=HvTloF/+yuowanKik/WHrbU6pxZQvusGez8hbdWIJCap1j6hAMR23TusjWPciadgk1 YJa4nlD43dL0aD+2LKJoyp2odAUDk+YnTy/vj8FGVry7Sf/Asor8Bh+HsmPRznUc+rir qmrYrcCvcihf1Sv0IUg7GC/JohFiPr/iCqQT2qji2bdT1hm3XMKAP3cWrfVAUJE+JOQw WHhNgXa7Lmp9LCAlujPjax2u59FaO19fym9BsajDL1gGmtISZjTFO4vtGxDa8HXnsos/ m1JvtsY7mqickDGDWpLD22sqBVRkfAocERd0Una2+CXEB/UpFlYLaOvg5rbWIIVAdrkw mDyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=H37ulJZoJ2bsC4KS3lsrCHbLt72+TS81HOOernS4rdg=; b=ge43dwi6AoOf/l1sWprwB4BnLyQh+QbqLRroVQEywxT6VWPKi4BGqgMHSNuZwAR9da XC4zqOFORh12DBwJc8NDA4p3Y6ve3WGW/FFX5ydMwGep8ZvXSkF3o9U6aqTUtXyfq9+Z LTiJnvoZ0xiBLnumBvsC2Z1eszCALjxJpbZqxKx0XAUu2q2hHcj0tgQJbFsDbs5dofvb mOzsxEPhth4twR1dWp/KwYlnHfaVdw/maLXSPpAnWTZeTSYr2nUX0JUipN3qlt4NmcMy gzC6s4EtWwHgoIshmp1YknFKNUSsTAIBu224XPO0sVWhQnq6dAMuItyYTWOJPDkE6OXY 2XSA== X-Gm-Message-State: AKGB3mLsFOImYZwQP8aServ0P/qWhod4rPRce1asRZX3UnNfEO61CnEB 6ZnilOZd2Y0Xz5BgHbH1EJYP8qo9TXqhJsXnusCy5Q== X-Google-Smtp-Source: ACJfBoue3sM61DBOCmuUqBZN2qsBWkhlp48q/6bsl8VEF/4ouEKRy4FRTb5bS2ocHhmXPIPNIhpEpQdk2TJbrZGhCs0= X-Received: by 10.46.20.5 with SMTP id u5mr1573227ljd.9.1513063252644; Mon, 11 Dec 2017 23:20:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.2.212 with HTTP; Mon, 11 Dec 2017 23:20:31 -0800 (PST) From: Naveen Kottapalli Date: Tue, 12 Dec 2017 12:50:31 +0530 Message-ID: To: 6man WG , v6ops list Content-Type: multipart/alternative; boundary="f403045fc116b257f405601f7d1f" Archived-At: Subject: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 07:20:56 -0000 --f403045fc116b257f405601f7d1f Content-Type: text/plain; charset="UTF-8" Hello, In our recent testing, we observed that Windows 10 doesn't honour 'M' flag in RA. It's not just Windows 10, same behaviour is observed with latest Mac OS as well. Is there any specification reference to support this? Your valuable input is highly appreciated. Yours, Naveen. --f403045fc116b257f405601f7d1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

In our recent testing, we observ= ed that Windows 10 doesn't honour 'M' flag in RA.=C2=A0 It'= s not just Windows 10, same behaviour is observed with latest Mac OS as wel= l.=C2=A0 Is there any specification reference to support this?
Your valuable input is highly appreciated.

Yours,
Naveen.
--f403045fc116b257f405601f7d1f-- From nobody Mon Dec 11 23:26:20 2017 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 6559B127869 for ; Mon, 11 Dec 2017 23:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0KWH70RIDr6 for ; Mon, 11 Dec 2017 23:26:16 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF4B1277BB for ; Mon, 11 Dec 2017 23:26:16 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id z11so2844738ybm.1 for ; Mon, 11 Dec 2017 23:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Gg8+FRF0bdpZO9dOcy0QYY7zRCP9y2IU2qml4G+f0Rs=; b=MvUGjCKIbm8XRQpvY4t6qpISTk0pwYZRPI+JPk+/wR8H9bdAZOeC7n1C3ecQGgaWQ1 MK5Eb9QT9Gn3/csomYJHbAVV/Mva5+x0S5mVTxvFy6z2wvRMljq3RtzJhlaXVPL8un/M IvTnyrFSOkHze6yLXm52nfJ+goWuruZoqKxtkUKsqQwBYKYnrD3WLou6lnSZAYnwRpnD t1s+YOLMItSifyRjl4XzmeLHtwWs8dRbLi2X7G44SSSuINXuxiM4CjHQE5rcevGPHrsk zofnCH1QyJ5vuPtAgGt8kRwCM1zqwD4beJLySSGqZfY4XCpltd9/HNNIgPwfNj2n+Tkr xOsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Gg8+FRF0bdpZO9dOcy0QYY7zRCP9y2IU2qml4G+f0Rs=; b=ZfpYklkNqwulBnacAHRjageskECqODXyJlMRyVb5G19rQ2p57JIGNYqqboB9qgG2dY 4wktc5zOaY/HRl3OetQ2GR6mvf4ftute4EGNgJDUtsjoCtn3/JoJSx+l+XPNkb/t3eup fqdOg5LT8Ma1CmQu5Bj97MOlCYn2yJEqm8PDABFYv+wEwnrSV8t2kqAAXpCkOpthodOX P/U6kcJ9+85vSm4C46sUN5kzf3VdH7hpCfWmCnJGJZaIoVDjvRjKDX30owhIWniQ0/vM Rp601aTVrK/yPqAv1gxpn5rwUIiFvYkJFRLYICgLkYWrTE57aIQQ8dhXm+q5pns3hoFM KY2A== X-Gm-Message-State: AKGB3mKa3JNuzMRHCEVMrtXiwjHk47CL9arLQ3Ms9vQzlBrYWtFnkYIS FOiI5qdYGa7by6KKp/iTsD1rsLcDaWdzPpX3mnplNw== X-Google-Smtp-Source: ACJfBouFPXSkswA+X2BcLw0fpCq5UvdN87cbeh7bgdC6lpEMFs5p/sFKPxPnkLRx97dH+lvOQTrtDspNbMJ9GvLx0Tw= X-Received: by 10.37.77.65 with SMTP id a62mr2282322ybb.185.1513063575172; Mon, 11 Dec 2017 23:26:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.185.199 with HTTP; Mon, 11 Dec 2017 23:25:54 -0800 (PST) In-Reply-To: References: From: Erik Kline Date: Tue, 12 Dec 2017 16:25:54 +0900 Message-ID: To: Naveen Kottapalli Cc: 6man WG , v6ops list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113c5646f7191505601f90ab" Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 07:26:18 -0000 --001a113c5646f7191505601f90ab Content-Type: text/plain; charset="UTF-8" What does it really mean, to "honour the 'M' flag"? Those bits are advisory /at best/. On 12 December 2017 at 16:20, Naveen Kottapalli wrote: > Hello, > > In our recent testing, we observed that Windows 10 doesn't honour 'M' flag > in RA. It's not just Windows 10, same behaviour is observed with latest Mac > OS as well. Is there any specification reference to support this? > > Your valuable input is highly appreciated. > > Yours, > Naveen. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a113c5646f7191505601f90ab Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgZvoZH/c/5Vt6gJQCB3rJ7P3Ed++zXTsw cozv2fGQdHMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMjEy MDcyNjE1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBADCkpapDRdckdH+HC9P6H/N2hoN3hfRg50B50HFghebglqbuwQbb VmBk7LzOwmzmYNgwtk7/914UFB2CnH6Jb3RDHgQdSGjg+XTZju92xdygbm6djFZ+mKFN5rI5GjGa 5kfwfqTwFVzTc2KGB/IWMF5zg6OFf2S7SXLLNHd4JcxKF9kRnxg3e1ma/4e8fQ5rQQFIpqdA8Luw k1wAbm379dwcfQz8a5ljOBfVSCECsI78xSsKuUjbEkB27KF18+iUYdqY6vl7vnqRQZP+/J6We71Y H1dHUPZwlV1cx6xVTPbrnaZ3UQAJBAHKEjWv171VrOew/BeC21M6KtffWwgCQM8= --001a113c5646f7191505601f90ab-- From nobody Mon Dec 11 23:40:42 2017 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 BCFF21293F9; Mon, 11 Dec 2017 23:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYg73m4mHw_y; Mon, 11 Dec 2017 23:40:35 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56D91293F2; Mon, 11 Dec 2017 23:40:34 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id x204so22042509lfa.11; Mon, 11 Dec 2017 23:40:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PCpmkq3307SrmqTTeWQVMn8McUSs/aAwK5oq9Be0T+8=; b=bGWazaVvWp5S0waWS+FZ24IcY3FJeX6JoIJAxBxg/2A9Z6ej1f84fFYwPqag/cy85t K4zxwTtbO1jG4ejJFuxuD1+Xod5/dCDhUZePKU8RAM3OQvymiK4x/Q2l0opz8pNzj1V9 kszRBlwPod5xoNUz09aPqsOfjJ0PKTZPzHZReVUOCzkWnPl7/yyg4mSfE1JX5h2nKz1O wE/X9qOoXm6alt+vPtXYGEZOfAt0JiM/8zIGJYsZdUKmEeh7WRFdtdaH4JONY4do3aqa 1ZZY16Y2TrpFd+KeD2G0sZhWP10uPOHuD4tCyEzIHPtYJIgvGZBHPdL9QTEWvksFizh4 0DBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PCpmkq3307SrmqTTeWQVMn8McUSs/aAwK5oq9Be0T+8=; b=Gnp95jlOfiQ35ZK+eBBm9bp/bCbGO4yoX8Qox8BtgwgV4e+gw/T0B2RcNtR9U5X9Cd IXwj8rWFqcsC631JL2y1+lxd3GHw57i1mNCyc4vPPxsNLbFua/GLlVQPY/ZDBgbnMAKR n5PSGMPGBmMP+bPnujJGheroegXmy/QACRx1BFm4SoWvUpSB9IPBtIr6d9+C5dlh83Jh EJ8sifSOaP3nWmoAVKWIP7XIHpt5GxTT6GwRer76hYmYJ2Am1l9obSPAmxg5eTEiE4qD 8kjeHZd5HPHsfWlom0e+gMAc92wIu7VHE+u7Cf8rxunfzhqYuexTldFPwynPsM/C+5EH +EgQ== X-Gm-Message-State: AKGB3mJG/71hn2PPoAKFR40ahoeodHTXICVwMJ+98ug/cAn6uJMXKn8n jEGmnI9AY7Uz9Ik5jEcegQNjiBJiD1x7H+akOzE= X-Google-Smtp-Source: ACJfBou2rkFVV/ZKj0wigboCRbz+pBVnzRIeLjzozZxl+DT2AgTbG49bgib8ZttttkM/8FrmuQdW6CytyrAihquijDs= X-Received: by 10.46.23.20 with SMTP id l20mr1440983lje.25.1513064433126; Mon, 11 Dec 2017 23:40:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.2.212 with HTTP; Mon, 11 Dec 2017 23:40:12 -0800 (PST) In-Reply-To: References: From: Naveen Kottapalli Date: Tue, 12 Dec 2017 13:10:12 +0530 Message-ID: To: Erik Kline Cc: 6man WG , v6ops list Content-Type: multipart/alternative; boundary="001a114b6b6c0f10c005601fc405" Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 07:40:37 -0000 --001a114b6b6c0f10c005601fc405 Content-Type: text/plain; charset="UTF-8" I mean that though the 'M' bit is set to 0, client initiated DHCPv6 Solicit. Yours, Naveen. On 12 December 2017 at 12:55, Erik Kline wrote: > What does it really mean, to "honour the 'M' flag"? Those bits are > advisory /at best/. > > On 12 December 2017 at 16:20, Naveen Kottapalli > wrote: > > Hello, > > > > In our recent testing, we observed that Windows 10 doesn't honour 'M' > flag > > in RA. It's not just Windows 10, same behaviour is observed with latest > Mac > > OS as well. Is there any specification reference to support this? > > > > Your valuable input is highly appreciated. > > > > Yours, > > Naveen. > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > --001a114b6b6c0f10c005601fc405 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I mean that though the 'M' bit is set to 0, client= initiated DHCPv6 Solicit.

Yo= urs,
Naveen.

On 12 December 2017 at 12:55, Erik Kline <ek@go= ogle.com> wrote:
What doe= s it really mean, to "honour the 'M' flag"?=C2=A0 Those b= its are
advisory /at best/.

On 12 December 2017 at 16:20, Naveen Kottapalli <naveen.sarma@gmail.com> wrote:
> Hello,
>
> In our recent testing, we observed that Windows 10 doesn't honour = 'M' flag
> in RA.=C2=A0 It's not just Windows 10, same behaviour is observed = with latest Mac
> OS as well.=C2=A0 Is there any specification reference to support this= ?
>
> Your valuable input is highly appreciated.
>
> Yours,
> Naveen.
>
> -----------------------------------------------------= ---------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> ------------------------------------------------------------= --------
>

--001a114b6b6c0f10c005601fc405-- From nobody Mon Dec 11 23:45:50 2017 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 70DF91267BB; Mon, 11 Dec 2017 23:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG-ceMzkV0cL; Mon, 11 Dec 2017 23:45:40 -0800 (PST) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4381293FD; Mon, 11 Dec 2017 23:45:40 -0800 (PST) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 1886F2732B; Tue, 12 Dec 2017 08:45:39 +0100 (CET) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id EEA0B658849; Tue, 12 Dec 2017 08:45:38 +0100 (CET) Received: by ws26.ernw.net (Postfix, from userid 1002) id CA8C1393B4; Tue, 12 Dec 2017 08:45:38 +0100 (CET) Date: Tue, 12 Dec 2017 08:45:38 +0100 From: Enno Rey To: Naveen Kottapalli Cc: Erik Kline , v6ops list , 6man WG Message-ID: <20171212074538.GB48853@ernw.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 07:45:43 -0000 Hi, On Tue, Dec 12, 2017 at 01:10:12PM +0530, Naveen Kottapalli wrote: > I mean that though the 'M' bit is set to 0, client initiated DHCPv6 Solicit. that's a deliberate decision from Microsoft: their recent OSs all send out DHCPv6 Solicits at a very early stage of (IPv6) stack initialization (even before sending the router solicitation => at that point there's not even an RA to process/to inspect the flags of). See also https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-windows-10/ best Enno > > Yours, > Naveen. > > On 12 December 2017 at 12:55, Erik Kline wrote: > > > What does it really mean, to "honour the 'M' flag"? Those bits are > > advisory /at best/. > > > > On 12 December 2017 at 16:20, Naveen Kottapalli > > wrote: > > > Hello, > > > > > > In our recent testing, we observed that Windows 10 doesn't honour 'M' > > flag > > > in RA. It's not just Windows 10, same behaviour is observed with latest > > Mac > > > OS as well. Is there any specification reference to support this? > > > > > > Your valuable input is highly appreciated. > > > > > > Yours, > > > Naveen. > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Matthias Luft, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Mon Dec 11 23:47:31 2017 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 625A1129408; Mon, 11 Dec 2017 23:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6KrSuTvi3Lm; Mon, 11 Dec 2017 23:47:29 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322571267BB; Mon, 11 Dec 2017 23:47:29 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DB9EDB2; Tue, 12 Dec 2017 08:47:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1513064846; bh=Rz055voezXYi5Y5PTQ/xNHx8th4t4d7PhonJkc4QEIc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=DlMPJPmfqttgAfldEJnT4aUMo5t/3kisC1B+S1TAmKo0aqd/YZ8eQ9tmCJM1QD6LC fcREBbxPp2LxCKcVtOQDOSOBoJB6LT0YLbS131QdGg4t2ujlMuAkYLl/Y0bo5KyF/o hhdH82Bu++6GyGw6SYEhoHs8dWCNmk3Q5+VGKphM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D734EB1; Tue, 12 Dec 2017 08:47:26 +0100 (CET) Date: Tue, 12 Dec 2017 08:47:26 +0100 (CET) From: Mikael Abrahamsson To: Naveen Kottapalli cc: Erik Kline , v6ops list , 6man WG In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 07:47:30 -0000 On Tue, 12 Dec 2017, Naveen Kottapalli wrote: > I mean that though the 'M' bit is set to 0, client initiated DHCPv6 Solicit. M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. >From earlier discussions, there is nothing saying "you can't do DHCPv6 requests if M=0". So technically these implementations aren't in violation of any standards, the M and O flags are only informational. It would however be interesting to understand the rationale if this change from the OS vendors. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Dec 12 10:36:23 2017 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 E580C127010 for ; Tue, 12 Dec 2017 10:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLNFj25UOt6M for ; Tue, 12 Dec 2017 10:36:19 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470B61205F1 for ; Tue, 12 Dec 2017 10:36:19 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id a90so14860563pfk.1 for ; Tue, 12 Dec 2017 10:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cUChmZm+bebKR8UF94WXokTK/Tupp7PjQE53kBGb8Tg=; b=u2LnD5osjTVIDlDt8CuDfnu0zYNcq5j2oGatTBSfuwF6NiY4UAZ6gF3cz5Q4kUO48s MRMBS3Qd44ktnTdy8cPTGToX/roc0cwcl+BOEbb3DExwYUXZJSp48utzuuke4jQbIobc IfkCSwyxrIWRZ2IqAUMRrsTIZ2RwchjUV+SNpCkoiznvZY/ntPznWzI/jYZ5OZfV1y7I TD43xT3L+UPfMq7VSgj3ACoocY5SyPywcIBQ6Gx0L+2fWuwXw52Gfd24iMpgq4KQXe1C 6ENWwV9+mQ2rO4X6hoD74li9OKzIvPccXkdxhhxDwnIKKfi6wJAQaF3oCuBlxMzTWyCZ iFSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cUChmZm+bebKR8UF94WXokTK/Tupp7PjQE53kBGb8Tg=; b=IQiHNEzMKERIz2Tmq6u30mw+K/flbgLccxdvHL4wS/hvSGjEOm7RqA4s0qDhwTKNsf bgsxHu6VnKmC5RJ4DVg0DfINP2R0a/IANedz6n9PZ1qigpEvEfyPj2Ct2WS27WnDZkwv g3mO4blfSRgt6fa9NxniCgBfJ/em2R0/eNjF/MXBWhErS9fQbUQoS7YklLPXIl1+hc2f ON39qG6MElu9jBOvL/xFo7/ZePQg9VukJa74JtQxXGrLgTZmpEsR+PuHjZmPKAjEeTWn 3nG6lLnY487oBlvHpD87mPMiMYsW3Qy7N23+fnm1VTOWUB9dt3NlAojCqDTjuJWQw7FW lSTw== X-Gm-Message-State: AKGB3mLegAWr2JuFbbBjzU7bV5X3+bxdxIXup/s/Xnl5JhS/ohrC6UdR SiCaTUjczX6+4uGxSnbS2p0SNA== X-Google-Smtp-Source: ACJfBotVliGGsRFGs4/18cuQTV0dZTw4Pza0B5OH4O3nI6v4mgGOcmLT3Ni1I9wOuy+bVTrle3UIbg== X-Received: by 10.159.245.145 with SMTP id a17mr3182487pls.276.1513103778113; Tue, 12 Dec 2017 10:36:18 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e190sm28937741pfe.15.2017.12.12.10.36.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 10:36:17 -0800 (PST) To: v6ops@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 13 Dec 2017 07:36:17 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 18:36:21 -0000 On 12/12/2017 20:47, Mikael Abrahamsson wrote: > On Tue, 12 Dec 2017, Naveen Kottapalli wrote: > >> I mean that though the 'M' bit is set to 0, client initiated DHCPv6 Solicit. > > M 1-bit "Managed address configuration" flag. When > set, it indicates that addresses are available via > Dynamic Host Configuration Protocol [DHCPv6]. > >>From earlier discussions, there is nothing saying "you can't do DHCPv6 > requests if M=0". So technically these implementations aren't in violation > of any standards, the M and O flags are only informational. Indeed. M=1 means "I know DHCPv6 is available." M=0 means "I don't know whether DHCPv6 is available." In the second case, the host might choose to try DHCPv6 anyway; but a host with limited battery power might choose to save some electricity. > It would however be interesting to understand the rationale if this > change from the OS vendors. Is it a change? Brian From nobody Tue Dec 12 10:51:15 2017 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 348DA1294F5; Tue, 12 Dec 2017 10:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWTpbF1A9VKJ; Tue, 12 Dec 2017 10:51:08 -0800 (PST) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44A41286CA; Tue, 12 Dec 2017 10:51:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vBCIp4sC050121; Tue, 12 Dec 2017 10:51:04 -0800 Received: from XCH15-06-04.nw.nos.boeing.com (xch15-06-04.nw.nos.boeing.com [137.137.100.81]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vBCIp13O050009 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 12 Dec 2017 10:51:01 -0800 Received: from XCH15-06-02.nw.nos.boeing.com (137.137.100.78) by XCH15-06-04.nw.nos.boeing.com (137.137.100.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 12 Dec 2017 10:50:50 -0800 Received: from XCH15-06-02.nw.nos.boeing.com ([137.137.100.78]) by XCH15-06-02.nw.nos.boeing.com ([137.137.100.78]) with mapi id 15.00.1347.000; Tue, 12 Dec 2017 10:50:50 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" , "ipv6@ietf.org" Thread-Topic: [v6ops] Windows 10 doesn't honour 'M' flag in RA Thread-Index: AQHTc3ids/3rysN/2UOtzik0uog6BqNADGWA Date: Tue, 12 Dec 2017 18:50:50 +0000 Message-ID: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] x-tm-as-matchedid: 1-140811-150567-701625-704425-700685-705450-700476-705102 -706378-708882-700107-148004-148133-148980-10019-24817-35009-41000-42000-42 003-29961-666801 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 18:51:10 -0000 This is why it would be better to have IPv6 ND and DHCPv6 as a unified stateless/stateful autoconfiguration service. Everything can be done in a single message exchange (RS/RA with DHCPv6 option) instead of requiring multiple message exchanges just for the sake of examining the M/O bits. Thanks - Fred From nobody Tue Dec 12 10:54:23 2017 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 F2253129511 for ; Tue, 12 Dec 2017 10:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWhpo2N-Nglc for ; Tue, 12 Dec 2017 10:54:20 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8412129504 for ; Tue, 12 Dec 2017 10:54:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EwAgCXJDBa/yYyC4ddGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJsUmZ0JweDe5kmmQ6CFQoTEIUYAhqEbkAXAQEBAQEBAQEBA2gdC4J?= =?us-ascii?q?rS1kBAQEBAQEjAj5FERFXARUNAgYgAgQwFREBBBsaigYBD54Nim6CJyECij4BC?= =?us-ascii?q?gEBAQEeBYEPgjgcgguBV4UhgTuBZQGBcIMTMYIyBaMXAod5jyiKLIc+jQ6JVoE?= =?us-ascii?q?7IQI2JYEpbxU6giqEVHgBiTcBgRQBAQE?= X-IPAS-Result: =?us-ascii?q?A2EwAgCXJDBa/yYyC4ddGgEBAQEBAgEBAQEIAQEBAYJsUmZ?= =?us-ascii?q?0JweDe5kmmQ6CFQoTEIUYAhqEbkAXAQEBAQEBAQEBA2gdC4JrS1kBAQEBAQEjA?= =?us-ascii?q?j5FERFXARUNAgYgAgQwFREBBBsaigYBD54Nim6CJyECij4BCgEBAQEeBYEPgjg?= =?us-ascii?q?cgguBV4UhgTuBZQGBcIMTMYIyBaMXAod5jyiKLIc+jQ6JVoE7IQI2JYEpbxU6g?= =?us-ascii?q?iqEVHgBiTcBgRQBAQE?= X-IronPort-AV: E=Sophos;i="5.45,395,1508817600"; d="scan'208";a="226625863" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Dec 2017 13:54:17 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Dec 2017 13:54:17 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0352.000; Tue, 12 Dec 2017 13:54:16 -0500 From: "Mudric, Dusan (Dusan)" To: "v6ops@ietf.org" Thread-Topic: [v6ops] RFC6724 policy table for Multi-Homed Site Thread-Index: AdNzeehU7jpKypsnREKU8Av+2tIjgw== Date: Tue, 12 Dec 2017 18:54:16 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459B4C10E1@AZ-US1EXMB03.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.250.9 dlp-reaction: no-action x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [v6ops] RFC6724 policy table for Multi-Homed Site X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 18:54:22 -0000 SGksDQoNCkhvdyBpcyB0aGlzIGNhbmRpZGF0ZSBwYWlyIHNlbGVjdGVkIGJhc2VkIG9uIHRoZSBw b2xpY3kgdGFibGUgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3MjQjc2VjdGlv bi0xMC41IDoNCg0KIiAgIENhbmRpZGF0ZSBTb3VyY2UgQWRkcmVzc2VzOiAyMDAxOmRiODoxYWFh OjphIG9yIDIwMDE6ZGI4OjcwYWE6OmEgb3INCiAgIGZlODA6OmENCiAgIERlc3RpbmF0aW9uIEFk ZHJlc3MgTGlzdDogMjAwMTpkYjg6MWNjYzo6YyBvciAyMDAxOmRiODo2Y2NjOjpjDQogICBOZXcg UmVzdWx0OiAyMDAxOmRiODo2Y2NjOjpjIChzcmMgMjAwMTpkYjg6NzBhYTo6YSkgdGhlbiAyMDAx OmRiODoNCiAgIDFjY2M6OmMgKHNyYyAyMDAxOmRiODo3MGFhOjphKSAobG9uZ2VzdCBtYXRjaGlu ZyBwcmVmaXgpICINClRoaXMgaXMgMzUgYml0IG1hdGNoLg0KDQpTaG91bGQgbm90IHRoZSBsb25n ZXN0IHByZWZpeCBtYXRjaCBnaXZlOg0KMjAwMTpkYjg6MWNjYzo6YyAoc3JjIDIwMDE6ZGI4OjFh YWE6OmEpLCAzNyBiaXQgbWF0Y2g/DQoNCklmIHRoaXMgaXMgbm90IHRoZSBsb25nZXN0IHByZWZp eCBtYXRjaCwgd2hhdCBzaG91bGQgYmUgaW4gdGhlIHBvbGljeSB0YWJsZSB0byBnaXZlIHRoZSBy ZXN1bHRpbmcgc2VsZWN0aW9uIHRvIFNpdGUgQz8NCg0KVGhhbmtzLA0KRHVzYW4NCg== From nobody Wed Dec 13 01:49:32 2017 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 3C854124B17 for ; Wed, 13 Dec 2017 01:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi1D-wQ-HwhP for ; Wed, 13 Dec 2017 01:49:29 -0800 (PST) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C546B120726 for ; Wed, 13 Dec 2017 01:49:28 -0800 (PST) Received: from 10.236.51.103 (EHLO ZE16MR07.tp.gk.corp.tepenet) ([10.236.51.103]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id IEO40782; Wed, 13 Dec 2017 10:49:24 +0100 (CET) From: Kossut Tomasz - Hurt To: Alexandre Petrescu , james woodyatt CC: "v6ops@ietf.org WG" Thread-Topic: [v6ops] IPv6 and Apple iPhone LTE interface Thread-Index: AQHTb1DmxfmXkBfALUCXKaTL1Np0zKNA9B6A Date: Wed, 13 Dec 2017 09:49:21 +0000 Message-ID: <348e862b15e54ad295da33a8155d22fe@orange.com> References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> <6bed89e7-d0b8-21cd-88f0-f689372e9cf5@gmail.com> <9D3908C3-2665-43E1-AD1C-1C6EB8546C9F@google.com> <4f3b150f-d136-53f8-9151-21ecd5ebf94f@gmail.com> In-Reply-To: <4f3b150f-d136-53f8-9151-21ecd5ebf94f@gmail.com> Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.20.50.38] x-tm-as-product-ver: SMEX-12.0.0.1727-8.200.1013-23526.006 x-tm-as-result: No--12.274600-0.000000-31 x-tm-as-matchedid: 150567-701625-704425-700685-702118-700401-139006-711995-1 06660-706065-712247-139010-700075-709584-701021-700706-700756-703412-121155 -701249-139703-708196-700047-148004-148133-42000-42003-63 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2017.12.13.90617:17:8.129, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __TO_NAME, __TO_NAME_DIFF_FROM_ACC, __HAS_CC_HDR, __CC_NAME, __CC_NAME_DIFF_FROM_ACC, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __HAS_MSGID, __SANE_MSGID, __MSGID_32HEX, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CT_TEXT_PLAIN, __CTE, CTE_BASE64, __MIME_VERSION, WEBMAIL_X_IP_HDR, __ANY_URI, __HTTPS_URI, __URI_WITH_PATH, __FRAUD_BODY_WEBMAIL, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __URI_IN_BODY, __URI_NOT_IMG, __FORWARDED_MSG, __NO_HTML_TAG_RAW, BODY_SIZE_1500_1599, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_P1, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, __FRAUD_WEBMAIL, WEBMAIL_SOURCE, IN_REP_TO, MSG_THREAD, __TO_REAL_NAMES, __CC_REAL_NAMES, LEGITIMATE_SIGNS, __SINGLE_URI_TEXT, SINGLE_URI_IN_BODY, [TRUNCATED] X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0207.5A30F7A4.0177, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0207.5A30F7A4.0177, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1094643e729e7b1348ca616265056e32 Archived-At: Subject: Re: [v6ops] IPv6 and Apple iPhone LTE interface X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 09:49:31 -0000 SGksDQpJUHY2LW9ubHkgUERQIG9uIElwaG9uZXMgcmVxdWlyZXMgRE5TNjQuDQpBbmRyb2lkL3dp bmRvd3NwaG9uZSB3b3JrcyB3aXRoIElwdjYtb25seSBQRFAgd2l0aG91dCBETlM2NCoNCiotIERO UzY0IG9ubHkgZm9yIGlwdjRvbmx5LmFycGEgdG8gbGVhcm4vZ2V0IHBsYXQtcHJlZml4DQpDaGVl cnMsDQp0aw0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMg W21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZHJlIFBl dHJlc2N1DQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNywgMjAxNyAxMjo0NSBQTQ0KVG86IGph bWVzIHdvb2R5YXR0DQpDYzogdjZvcHNAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBbdjZvcHNd IElQdjYgYW5kIEFwcGxlIGlQaG9uZSBMVEUgaW50ZXJmYWNlDQoNCkxlIDA2LzEyLzIwMTcgw6Ag MTk6MjYsIGphbWVzIHdvb2R5YXR0IGEgw6ljcml0IDoNCj4gT24gRGVjIDYsIDIwMTcsIGF0IDAz OjAwLCBBbGV4YW5kcmUgUGV0cmVzY3UgDQo+IDxhbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29t IDxtYWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbT4+DQo+IHdyb3RlOg0KPj4gDQo+ PiBJcyB0aGVyZSBhbiBpUGhvbmUgYXBwIHRoYXQgY291bGQgc2V0IHRoZSBQRFAgdHlwZSB0byAn SVB2NicsIHdpdGhvdXQgDQo+PiBqYWlsYnJlYWtpbmc/DQo+IA0KPiBZb3UgbmVlZCBhIGNhcnJp ZXIgYnVuZGxlIHRvIGNvbmZpZ3VyZSB0aGF0IHNldHRpbmcuDQoNClllcyBJIG5lZWQgaXQuDQoN ClRoYXQgY2FycmllciBkb2VzIG5vdCBvZmZlciBhIGJ1bmRsZSB0byBjb25maWd1cmUgdGhhdCBz ZXR0aW5nIGZvciBpUGhvbmUuICBGb3IgQW5kcm9pZCwgdGhlIGNhcnJpZXIgaW5kaWNhdGVzIHRv IHRoZSB1c2VyIHRoZSB0eXBpY2FsIHN0ZXAtYnktc3RlcCBQYXJhbWV0ZXIgY2hhbmdpbmcgb2Yg dGhlICJBUE4gcHJvdG9jb2wiIGZyb20gSVB2NCB0byBJUHY2Lg0KDQpBbGV4DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxp c3QNCnY2b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzDQo= From nobody Wed Dec 13 03:03:17 2017 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 A1312128B8D; Wed, 13 Dec 2017 03:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSpPtwnwCoJn; Wed, 13 Dec 2017 03:03:08 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38ACB128D3E; Wed, 13 Dec 2017 03:03:08 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id l81so2141003lfl.6; Wed, 13 Dec 2017 03:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z10ESMJzlXIwCWFqezZcz4l4LFKTnSMNYmzTxXdecNo=; b=cUqeZHSY4Iy9T6SyWnxbd1nlFaZkuhMTlH0CssmEWEMt6lgjsLbpIYIBCsHYhuyxQB BKXZ3b5IBrdYwoUfk8YanoxxYxHPlMg81iut3mjbSIbeQda4IGr2MhP2hdUcbyPy7ZLi PAcZVe/e1h7TL1T2thR8TqKFV4KV7n+5Na1fqfSSNj1ccAuqzrBvh2Lo+4oP2aZWGfV3 ma7GUz23chwMhVIwGo0MnVXiyk1gvA5OVgzVh3MU9fpfhFRpbyeaeiievPRQ79Xj2EX7 5xSoLhmv6VkwRG+N+lFDmAgfXQtgNOZwt4NHsvH+IDubE4lylIZkWb/nHD3G3y51xfan 9blA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z10ESMJzlXIwCWFqezZcz4l4LFKTnSMNYmzTxXdecNo=; b=EO577cKJekKp9YNk4rT+5bqaznEnQMt86hhhDUwG0oCFo3f/DJ7+WQHlPPmq12QGjh U6eJ6VpH/9sm1CXvDfZQuMgKZVleacfS50WkT0N4SrmHAJo5R5gqTL5XuGeKP6+izQgB T6tEKTtiC+JK+J/uUZZVvl/QFWPTittfL2SiW9vn31286VPoNoiPY38p82VQvqdSloJU nPF9Hu4hfXJ5arTFiCCb8hAyaUrMmmQkAPGIgfBpn6EVjgM4iChYF4Ofkv5ARLcr3BIn 236ij5Hh8znQgGbz4J5lLusLm/fRjdIPZU2eL+4bGoBvUslJlPpI7/o5Jn2vl13Vb+iQ DvxA== X-Gm-Message-State: AKGB3mILwGuQa+4lTBsfEMMV+XjdbIhCsDZnetwY+gH390C5Y8RcrKQT 8wWS/HIHixGTyZ64oHuJxNNI0Pah9EVCJ6YDHHLWfg== X-Google-Smtp-Source: ACJfBoucSemk0Sf7ORJcjpOW6hjzM0Ogwhfbxy8VOs2Ib+UevD3MvARRG4qXfPO8ntgHGiCJ8MeR4f/5niUy1KNdckI= X-Received: by 10.25.163.17 with SMTP id m17mr1306666lfe.88.1513162986420; Wed, 13 Dec 2017 03:03:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.2.212 with HTTP; Wed, 13 Dec 2017 03:02:45 -0800 (PST) In-Reply-To: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> From: Naveen Kottapalli Date: Wed, 13 Dec 2017 16:32:45 +0530 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="001a114033604b009d056036b659" Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 11:03:12 -0000 --001a114033604b009d056036b659 Content-Type: text/plain; charset="UTF-8" Yes, it would have been the better way. If clients aren't even referring the 'M' bit, what is the use of carrying in RA? Yours, Naveen. On 13 December 2017 at 00:20, Templin, Fred L wrote: > This is why it would be better to have IPv6 ND and DHCPv6 as a unified > stateless/stateful autoconfiguration service. Everything can be done in > a single message exchange (RS/RA with DHCPv6 option) instead of > requiring multiple message exchanges just for the sake of examining > the M/O bits. > > Thanks - Fred > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a114033604b009d056036b659 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, it would have been the better way.=C2=A0 If clients a= ren't even referring the 'M' bit, what is the use of carrying i= n RA?

Yours,
Naveen.
=

On 13 December 2017 at 00:20, Templin, Fred = L <Fred.L.Templin@boeing.com> wrote:
This is why it would be better to have IPv6 ND and DHCPv= 6 as a unified
stateless/stateful autoconfiguration service. Everything can be done in
a single message exchange (RS/RA with DHCPv6 option) instead of
requiring multiple message exchanges just for the sake of examining
the M/O bits.

Thanks - Fred

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

--001a114033604b009d056036b659-- From nobody Wed Dec 13 03:27:00 2017 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 CB13B127A90; Wed, 13 Dec 2017 03:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifMD_67PFNwY; Wed, 13 Dec 2017 03:26:52 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB889127005; Wed, 13 Dec 2017 03:26:52 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 39694B4; Wed, 13 Dec 2017 12:26:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1513164410; bh=qbiiJ2KPdpc+Zmg8C+D3Rvxou9DbGKFANqvJDuNV7cs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=guh5NBitOQoD1JhwosmeQdONkr6PI7tfa8cOcDhxsN7/AHN8bE3AS0PJbV/jYyJLg NiKn2fKdtmcEw8y2lcDyZXadjrYMVSMoVGPuiUVKfAg7Y04n9rsBSCi4iMIHxU/jCm xofwtOu1fsg5dpEk8Gve7nyt/RybvkMIt95pEmg8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 371AEB1; Wed, 13 Dec 2017 12:26:50 +0100 (CET) Date: Wed, 13 Dec 2017 12:26:50 +0100 (CET) From: Mikael Abrahamsson To: Naveen Kottapalli cc: "v6ops@ietf.org" , "ipv6@ietf.org" In-Reply-To: Message-ID: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 11:26:55 -0000 On Wed, 13 Dec 2017, Naveen Kottapalli wrote: > Yes, it would have been the better way. If clients aren't even > referring the 'M' bit, what is the use of carrying in RA? Some operating systems do, some don't. It's a hint. It's up to the implementor to decide what to do if the flag is set or not. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Dec 13 04:11:54 2017 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 7BBF6124F57; Wed, 13 Dec 2017 04:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLeqOzwZVCkO; Wed, 13 Dec 2017 04:11:46 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1059124BFA; Wed, 13 Dec 2017 04:11:45 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id f18so2355285lfg.8; Wed, 13 Dec 2017 04:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wbK9+yFa4I1xuuINEBSWhuEeG9Oi/oMr0g8Ndpvp8IM=; b=vMLmK9VVBLgSts0gxTpd3kqw1L2bKluYqsYbsmKwzbbQNewzdzxM/SY1Nn2p8pLrwi Yh3MbfENLAhP+PsqbBNZsHnW6ry6NPz7QlmNgrxl8DclglVDfI7Xz0zdGbnIxVaxboZa LpaSvaK8xza0hjtjAiuRS1l7WgWPS5JHaFcD0GiGrnJSWdTIdpCWuapHqPgwWORoQ0B6 X0wKSv4l4ZVl/v9rOvs7EghtcD5ZeqpvC+Dh+fB46OMKtimF/+fwKUhz9s0NisAiUpqr bZh0ZO4UW/1BlGWAtoaGzGgP8Wl3JlvLsGk6i9fRKJFlbINifUFsUiFQoQ+0eF+97ztu Wvrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wbK9+yFa4I1xuuINEBSWhuEeG9Oi/oMr0g8Ndpvp8IM=; b=il/4OlyRKonw24fqAkyER1qacpoRPD/C861KjUueysc+5b5FRlfkrehI1uAEF7RXi1 Me7DrMD25O1Hc6aIrgeLvBcoyWOgKe1540PlkgIWCt98XPltuHpt7aqKYrCi6SHCIK6+ 7NIYnWsn4KwIZkAhlEf/f6gwSJ26aL0DSUXMNFmfupiF+ENgN65d/XA+2TkX5Is7bRDF rWMIL51/MReziyc5eCzlk1wJyIYyt/OMZdfMzOEKEu7HmUr2Pu6IaTOh3+i5nXePvuxy ZMJ5MxanMEo/9WGR1kpHJj853MgJMf0crwTA00VBhDLd3zNkbafLswgRP0yULA+AVILa D+OA== X-Gm-Message-State: AKGB3mKBCbI07tyxXnH41dKWWmzEg4qmxhdalkYPg3/nEAgfQpsf7JvM zPNhcwNGbQzJKD+aJNlxYqbM6NdR8udCkWSNZfewIQ== X-Google-Smtp-Source: ACJfBosAjgC+kzsZN0tHWimrafIzJegZexLj1d+v4FSlCqE+GSWGHyp0EURV6W7/KC3vYD3gGZ2GtG0NPuaiMydSUqA= X-Received: by 10.25.167.143 with SMTP id q137mr1284770lfe.124.1513167103729; Wed, 13 Dec 2017 04:11:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.2.212 with HTTP; Wed, 13 Dec 2017 04:11:23 -0800 (PST) In-Reply-To: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> From: Naveen Kottapalli Date: Wed, 13 Dec 2017 17:41:23 +0530 Message-ID: To: Mikael Abrahamsson Cc: "v6ops@ietf.org" , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="001a11410af6b4277a056037abcf" Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 12:11:47 -0000 --001a11410af6b4277a056037abcf Content-Type: text/plain; charset="UTF-8" I got that. But am not sure on what is the use when devices don't bother the value of that bit in RA. Yours, Naveen. On 13 December 2017 at 16:56, Mikael Abrahamsson wrote: > On Wed, 13 Dec 2017, Naveen Kottapalli wrote: > > Yes, it would have been the better way. If clients aren't even referring >> the 'M' bit, what is the use of carrying in RA? >> > > Some operating systems do, some don't. It's a hint. It's up to the > implementor to decide what to do if the flag is set or not. > > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > --001a11410af6b4277a056037abcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I got that.=C2=A0 But am not sure on what is the use when = devices don't bother the value of that bit in RA.

Yours,
Naveen.

On 13 December 2017 at 16:56, Mikael Abraham= sson <swmike@swm.pp.se> wrote:
On Wed, 13 Dec 2017, Naveen Kottapalli wrote:

Yes, it would have been the better way.=C2=A0 If clients aren't even re= ferring the 'M' bit, what is the use of carrying in RA?

 Some operating systems do, some don't. It's a hint. It's up to = the implementor to decide what to do if the flag is set or not.



--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

--001a11410af6b4277a056037abcf-- From nobody Wed Dec 13 04:30:04 2017 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 34AD2126BF3 for ; Wed, 13 Dec 2017 04:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgyDcvmYOEAt for ; Wed, 13 Dec 2017 04:29:55 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17601200B9 for ; Wed, 13 Dec 2017 04:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1513168193; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references; bh=tKTUdb95boJmG9EXZG9TnoLKpYCx3tvW13Dsfr2+izY=; b=foGrwH+rfW/09MGYUs6qeZ0nvIMarTuOh0Y4yal5x9Qb5j3LtZqUqjlIADVqpXJ89J228XxLA9I4QSRHe8nHV9fegplvUPSpLsfXGIX/GBz1n3yMoHM4aURXP3gNLcVLgXF4hB5AV0OAjRjxzrzkiqxG7tVYvZwu5unLf6orUKw= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0088.outbound.protection.outlook.com [94.245.120.88]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-133--ZJ-N3DNPbyMnsXgRmlwWw-1; Wed, 13 Dec 2017 12:29:48 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Wed, 13 Dec 2017 12:29:44 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::757e:c03:9cae:965f]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::757e:c03:9cae:965f%13]) with mapi id 15.20.0323.011; Wed, 13 Dec 2017 12:29:44 +0000 From: Tim Chown To: Naveen Kottapalli CC: Mikael Abrahamsson , "v6ops@ietf.org" , "ipv6@ietf.org" Thread-Topic: [v6ops] Windows 10 doesn't honour 'M' flag in RA Thread-Index: AQHTc3gpBv+D1eZ2VUO2egLF+TEkW6NADVEAgAEPjYCAAAa7AIAADHKAgAAFUwA= Date: Wed, 13 Dec 2017 12:29:44 +0000 Message-ID: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [94.119.96.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 20:clgP9ObbhgyEI4iVV194Ygcrg/UlEAPOCv6X0XFVzSK6G6Rza3u5N/mqozRyfhYR2BPY7InW+9Bm9oFWjEUslRE9DzB+CB4A1Vr0Jd+J0Zg4HncauwY1ZlY987dsW/ad8QSAXgjYJbDvie62zaCNdhO409LWEL1KxBRAniuEUDk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ee36af26-9026-483a-5e52-08d5422530b8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:AM3PR07MB1140; x-ms-traffictypediagnostic: AM3PR07MB1140: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM3PR07MB1140; x-forefront-prvs: 052017CAF1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(252514010)(189003)(199004)(24454002)(7736002)(3846002)(54896002)(966005)(6512007)(72206003)(53936002)(57306001)(39060400002)(8676002)(25786009)(6306002)(68736007)(8936002)(6246003)(4326008)(50226002)(478600001)(66066001)(2900100001)(5250100002)(42882006)(2950100002)(229853002)(6916009)(6116002)(14454004)(102836003)(6486002)(36756003)(81166006)(81156014)(76176011)(236005)(93886005)(97736004)(3660700001)(83716003)(6436002)(106356001)(99286004)(105586002)(54906003)(316002)(786003)(82746002)(6506007)(74482002)(33656002)(5660300001)(2906002)(3280700002)(86362001)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: ee36af26-9026-483a-5e52-08d5422530b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2017 12:29:44.0936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140 X-MC-Unique: -ZJ-N3DNPbyMnsXgRmlwWw-1 Content-Type: multipart/alternative; boundary="_000_F2F313539641467081520DF1B184451Ejiscacuk_" Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 12:29:59 -0000 --_000_F2F313539641467081520DF1B184451Ejiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T24gMTMgRGVjIDIwMTcsIGF0IDEyOjExLCBOYXZlZW4gS290dGFwYWxsaSA8bmF2ZWVuLnNhcm1h QGdtYWlsLmNvbTxtYWlsdG86bmF2ZWVuLnNhcm1hQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpJIGdv dCB0aGF0LiAgQnV0IGFtIG5vdCBzdXJlIG9uIHdoYXQgaXMgdGhlIHVzZSB3aGVuIGRldmljZXMg ZG9uJ3QgYm90aGVyIHRoZSB2YWx1ZSBvZiB0aGF0IGJpdCBpbiBSQS4NCg0KWW91IHdvdWxkbuKA mXQgYmVsaWV2ZSBob3cgbWFueSB0aG91c2FuZCBlbWFpbHMgaGF2ZSBkaXNjdXNzZWQgdGhpcyA6 KQ0KDQpBIOKAmGhpbnTigJkgd2FzIHRoZSBjb25zZW5zdXMuDQoNClRpbQ0KDQoNCllvdXJzLA0K TmF2ZWVuLg0KDQpPbiAxMyBEZWNlbWJlciAyMDE3IGF0IDE2OjU2LCBNaWthZWwgQWJyYWhhbXNz b24gPHN3bWlrZUBzd20ucHAuc2U8bWFpbHRvOnN3bWlrZUBzd20ucHAuc2U+PiB3cm90ZToNCk9u IFdlZCwgMTMgRGVjIDIwMTcsIE5hdmVlbiBLb3R0YXBhbGxpIHdyb3RlOg0KDQpZZXMsIGl0IHdv dWxkIGhhdmUgYmVlbiB0aGUgYmV0dGVyIHdheS4gIElmIGNsaWVudHMgYXJlbid0IGV2ZW4gcmVm ZXJyaW5nIHRoZSAnTScgYml0LCB3aGF0IGlzIHRoZSB1c2Ugb2YgY2FycnlpbmcgaW4gUkE/DQoN ClNvbWUgb3BlcmF0aW5nIHN5c3RlbXMgZG8sIHNvbWUgZG9uJ3QuIEl0J3MgYSBoaW50LiBJdCdz IHVwIHRvIHRoZSBpbXBsZW1lbnRvciB0byBkZWNpZGUgd2hhdCB0byBkbyBpZiB0aGUgZmxhZyBp cyBzZXQgb3Igbm90Lg0KDQoNCg0KLS0NCk1pa2FlbCBBYnJhaGFtc3NvbiAgICBlbWFpbDogc3dt aWtlQHN3bS5wcC5zZTxtYWlsdG86c3dtaWtlQHN3bS5wcC5zZT4NCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCklF VEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9yZzxtYWlsdG86 aXB2NkBpZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== --_000_F2F313539641467081520DF1B184451Ejiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KT24gMTMgRGVjIDIwMTcsIGF0IDEy OjExLCBOYXZlZW4gS290dGFwYWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5hdmVlbi5zYXJtYUBn bWFpbC5jb20iIGNsYXNzPSIiPm5hdmVlbi5zYXJtYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0iIj5JIGdvdCB0aGF0LiZuYnNwOyBCdXQgYW0gbm90IHN1cmUgb24g d2hhdCBpcyB0aGUgdXNlIHdoZW4gZGV2aWNlcyBkb24ndCBib3RoZXIgdGhlIHZhbHVlIG9mIHRo YXQgYml0IGluIFJBLjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KWW91IHdvdWxkbuKAmXQgYmVsaWV2ZSBob3cgbWFueSB0aG91c2FuZCBl bWFpbHMgaGF2ZSBkaXNjdXNzZWQgdGhpcyA6KSAmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2PkEg4oCYaGludOKAmSB3YXMgdGhlIGNvbnNlbnN1cy48L2Rpdj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRpbTwvZGl2Pg0KPGRpdj48YnIgY2xh c3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsZWFyPSJhbGwiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSIgZGF0YS1zbWFydG1haWw9 ImdtYWlsX3NpZ25hdHVyZSI+WW91cnMsPGJyIGNsYXNzPSIiPg0KTmF2ZWVuLjwvZGl2Pg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gMTMgRGVjZW1i ZXIgMjAxNyBhdCAxNjo1NiwgTWlrYWVsIEFicmFoYW1zc29uIDxzcGFuIGRpcj0ibHRyIiBjbGFz cz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86c3dtaWtlQHN3bS5wcC5zZSIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPnN3bWlrZUBzd20ucHAuc2U8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8 c3BhbiBjbGFzcz0iIj5PbiBXZWQsIDEzIERlYyAyMDE3LCBOYXZlZW4gS290dGFwYWxsaSB3cm90 ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NClllcywgaXQgd291bGQgaGF2ZSBiZWVuIHRoZSBiZXR0ZXIg d2F5LiZuYnNwOyBJZiBjbGllbnRzIGFyZW4ndCBldmVuIHJlZmVycmluZyB0aGUgJ00nIGJpdCwg d2hhdCBpcyB0aGUgdXNlIG9mIGNhcnJ5aW5nIGluIFJBPzxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxiciBjbGFzcz0iIj4NCjwvc3Bhbj5Tb21lIG9wZXJhdGluZyBzeXN0ZW1zIGRvLCBz b21lIGRvbid0LiBJdCdzIGEgaGludC4gSXQncyB1cCB0byB0aGUgaW1wbGVtZW50b3IgdG8gZGVj aWRlIHdoYXQgdG8gZG8gaWYgdGhlIGZsYWcgaXMgc2V0IG9yIG5vdC4NCjxkaXYgY2xhc3M9IkhP RW5aYiI+DQo8ZGl2IGNsYXNzPSJoNSI+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KLS0gPGJyIGNsYXNzPSIiPg0KTWlrYWVsIEFicmFoYW1zc29uJm5ic3A7ICZu YnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOnN3bWlrZUBzd20ucHAuc2UiIHRhcmdldD0iX2Js YW5rIiBjbGFzcz0iIj4NCnN3bWlrZUBzd20ucHAuc2U8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIiBjbGFzcz0i Ij5pcHY2QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3Rz OiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8YnIgY2xhc3M9IiI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F2F313539641467081520DF1B184451Ejiscacuk_-- From nobody Wed Dec 13 07:21:10 2017 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 3F1F7127058 for ; Wed, 13 Dec 2017 07:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WleEUcMSi-Mx for ; Wed, 13 Dec 2017 07:21:07 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB31126E7A for ; Wed, 13 Dec 2017 07:21:07 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vBDFL4kB030783; Wed, 13 Dec 2017 16:21:04 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D24152071EB; Wed, 13 Dec 2017 16:21:04 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C32412071BA; Wed, 13 Dec 2017 16:21:04 +0100 (CET) Received: from [132.166.85.129] ([132.166.85.129]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vBDFL2gi012534; Wed, 13 Dec 2017 16:21:04 +0100 To: Kossut Tomasz - Hurt Cc: james woodyatt , "v6ops@ietf.org WG" References: <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> <6bed89e7-d0b8-21cd-88f0-f689372e9cf5@gmail.com> <9D3908C3-2665-43E1-AD1C-1C6EB8546C9F@google.com> <4f3b150f-d136-53f8-9151-21ecd5ebf94f@gmail.com> <348e862b15e54ad295da33a8155d22fe@orange.com> From: Alexandre Petrescu Message-ID: <2e2c0493-6ddc-1b62-93d2-bfcbf38cd3cc@gmail.com> Date: Wed, 13 Dec 2017 16:21:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <348e862b15e54ad295da33a8155d22fe@orange.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6 and Apple iPhone LTE interface X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 15:21:09 -0000 Le 13/12/2017 à 10:49, Kossut Tomasz - Hurt a écrit : > Hi, > IPv6-only PDP on Iphones requires DNS64. A-ha. But is it possible to set the IPv6-only PDP on an iPhone without running a 'carrier bundle'? (then I will see about DNS64.) Alex > Android/windowsphone works with Ipv6-only PDP without DNS64* > *- DNS64 only for ipv4only.arpa to learn/get plat-prefix > Cheers, > tk > > > > > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu > Sent: Thursday, December 7, 2017 12:45 PM > To: james woodyatt > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] IPv6 and Apple iPhone LTE interface > > Le 06/12/2017 à 19:26, james woodyatt a écrit : >> On Dec 6, 2017, at 03:00, Alexandre Petrescu >> > >> wrote: >>> >>> Is there an iPhone app that could set the PDP type to 'IPv6', without >>> jailbreaking? >> >> You need a carrier bundle to configure that setting. > > Yes I need it. > > That carrier does not offer a bundle to configure that setting for iPhone. For Android, the carrier indicates to the user the typical step-by-step Parameter changing of the "APN protocol" from IPv4 to IPv6. > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Dec 13 07:24:31 2017 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 15341126E7A; Wed, 13 Dec 2017 07:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71_iJWycSl0v; Wed, 13 Dec 2017 07:24:26 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668E6126CF6; Wed, 13 Dec 2017 07:24:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vBDFOPti028352; Wed, 13 Dec 2017 08:24:26 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vBDFOJHx027930 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 13 Dec 2017 08:24:19 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 13 Dec 2017 07:24:18 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1347.000; Wed, 13 Dec 2017 07:24:18 -0800 From: "Templin, Fred L" To: Naveen Kottapalli CC: "v6ops@ietf.org" , "ipv6@ietf.org" Thread-Topic: [v6ops] Windows 10 doesn't honour 'M' flag in RA Thread-Index: AQHTc3ids/3rysN/2UOtzik0uog6BqNADGWAgAGWlID//8Bd4A== Date: Wed, 13 Dec 2017 15:24:18 +0000 Message-ID: <97a10ed486fd4f8993cfade81f90c8da@XCH15-06-08.nw.nos.boeing.com> References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_97a10ed486fd4f8993cfade81f90c8daXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 15:24:29 -0000 --_000_97a10ed486fd4f8993cfade81f90c8daXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmF2ZWVuLA0KDQo+IFllcywgaXQgd291bGQgaGF2ZSBiZWVuIHRoZSBiZXR0ZXIgd2F5Lg0K DQpJdOKAmXMgbm90IHRvbyBsYXRlIHRvIHNldCB0aGluZ3MgcmlnaHQuIENvbWJpbmluZyBJUHY2 IE5EIHJvdXRlciBkaXNjb3ZlcnkNCmFuZCBESENQdjYgaW4gYSBzaW5nbGUsIHVuaWZpZWQgc2Vy dmljZSBjb21iaW5lcyB0aGUgYmVzdCBmZWF0dXJlcyBvZg0Kc3RhdGVsZXNzIGFuZCBzdGF0ZWZ1 bCBhdXRvY29uZmlndXJhdGlvbi4gQWxsIGl0IHRha2VzIGlzIGRlZmluaW5nIGEgbmV3DQpJUHY2 IE5EIG1lc3NhZ2Ugb3B0aW9uLg0KDQpQbHVzLCBpdCBpcyBiYWNrd2FyZHMgY29tcGF0aWJsZS4g SWYgdGhlIGhvc3Qgc2VuZHMgYW4gUlMgd2l0aCBhIERIQ1B2Ng0Kb3B0aW9uLCBhbmQgdGhlIHJv dXRlciBkb2VzIG5vdCByZWNvZ25pemUgdGhlIG9wdGlvbiwgdGhlIHJvdXRlciBzZW5kcw0KYmFj ayBhbiBSQSB3aXRoIG5vIERIQ1B2NiBvcHRpb24gYW5kIHRoZSBob3N0IGNhbiBrbm93IHRoYXQg aXQgbmVlZHMNCnRvIGRvIHRoaW5ncyB0aGUgb2xkIHdheSAoaS5lLiwgc2VuZCBESENQdjYgU29s aWNpdCBhZnRlciByZWNlaXZpbmcgdGhlIFJBKS4NCkluIHRoZSBvdGhlciBkaXJlY3Rpb24sIHRo ZSByb3V0ZXIgd2lsbCBuZXZlciBzZW5kIGFuIFJBIHdpdGggdGhlIERIQ1B2Ng0Kb3B0aW9uIGlu Y2x1ZGVkIHVubGVzcyB0aGUgaG9zdCBmaXJzdCBzZW50IGFuIFJTIHdpdGggREhDUHY2IG9wdGlv bi4NCg0KV2l0aCBhIGNvbWJpbmVkIGF1dG9jb25maWd1cmF0aW9uIHNlcnZpY2UgIGxpa2UgdGhp cywgdGhlIGFnZXMtb2xkIGRlYmF0ZQ0KYWJvdXQgU0xBQUMgdnMuIERIQ1B2NiBnb2VzIGF3YXks IGFuZCB3ZSB0cnVseSBnZXQgdGhlIGJlc3Qgb2YgYm90aA0Kd29ybGRzLg0KDQpUaGFua3MgLSBG cmVkDQoNCkZyb206IE5hdmVlbiBLb3R0YXBhbGxpIFttYWlsdG86bmF2ZWVuLnNhcm1hQGdtYWls LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTMsIDIwMTcgMzowMyBBTQ0KVG86IFRl bXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCkNjOiB2Nm9wc0BpZXRm Lm9yZzsgaXB2NkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gV2luZG93cyAxMCBkb2Vz bid0IGhvbm91ciAnTScgZmxhZyBpbiBSQQ0KDQpZZXMsIGl0IHdvdWxkIGhhdmUgYmVlbiB0aGUg YmV0dGVyIHdheS4gIElmIGNsaWVudHMgYXJlbid0IGV2ZW4gcmVmZXJyaW5nIHRoZSAnTScgYml0 LCB3aGF0IGlzIHRoZSB1c2Ugb2YgY2FycnlpbmcgaW4gUkE/DQoNCllvdXJzLA0KTmF2ZWVuLg0K DQpPbiAxMyBEZWNlbWJlciAyMDE3IGF0IDAwOjIwLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiB3cm90 ZToNClRoaXMgaXMgd2h5IGl0IHdvdWxkIGJlIGJldHRlciB0byBoYXZlIElQdjYgTkQgYW5kIERI Q1B2NiBhcyBhIHVuaWZpZWQNCnN0YXRlbGVzcy9zdGF0ZWZ1bCBhdXRvY29uZmlndXJhdGlvbiBz ZXJ2aWNlLiBFdmVyeXRoaW5nIGNhbiBiZSBkb25lIGluDQphIHNpbmdsZSBtZXNzYWdlIGV4Y2hh bmdlIChSUy9SQSB3aXRoIERIQ1B2NiBvcHRpb24pIGluc3RlYWQgb2YNCnJlcXVpcmluZyBtdWx0 aXBsZSBtZXNzYWdlIGV4Y2hhbmdlcyBqdXN0IGZvciB0aGUgc2FrZSBvZiBleGFtaW5pbmcNCnRo ZSBNL08gYml0cy4NCg0KVGhhbmtzIC0gRnJlZA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVURiBJUHY2IHdv cmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYu b3JnPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K --_000_97a10ed486fd4f8993cfade81f90c8daXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIE5hdmVlbiw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+IFllcywgaXQgd291bGQgaGF2 ZSBiZWVuIHRoZSBiZXR0ZXIgd2F5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SXTigJlzIG5vdCB0b28gbGF0ZSB0byBzZXQgdGhpbmdzIHJp Z2h0LiBDb21iaW5pbmcgSVB2NiBORCByb3V0ZXIgZGlzY292ZXJ5PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PmFuZCBESENQdjYgaW4gYSBzaW5nbGUsIHVuaWZpZWQgc2VydmljZSBjb21iaW5lcyB0aGUgYmVz dCBmZWF0dXJlcyBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5zdGF0ZWxlc3MgYW5kIHN0YXRlZnVsIGF1 dG9jb25maWd1cmF0aW9uLiBBbGwgaXQgdGFrZXMgaXMgZGVmaW5pbmcgYSBuZXc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SVB2NiBORCBtZXNzYWdlIG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlBsdXMsIGl0IGlzIGJhY2t3YXJkcyBjb21wYXRpYmxlLiBJZiB0 aGUgaG9zdCBzZW5kcyBhbiBSUyB3aXRoIGEgREhDUHY2PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm9wdGlv biwgYW5kIHRoZSByb3V0ZXIgZG9lcyBub3QgcmVjb2duaXplIHRoZSBvcHRpb24sIHRoZSByb3V0 ZXIgc2VuZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YmFjayBhbiBSQSB3aXRoIG5vIERIQ1B2NiBvcHRp b24gYW5kIHRoZSBob3N0IGNhbiBrbm93IHRoYXQgaXQgbmVlZHM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ dG8gZG8gdGhpbmdzIHRoZSBvbGQgd2F5IChpLmUuLCBzZW5kIERIQ1B2NiBTb2xpY2l0IGFmdGVy IHJlY2VpdmluZyB0aGUgUkEpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiB0aGUgb3RoZXIgZGlyZWN0 aW9uLCB0aGUgcm91dGVyIHdpbGwgbmV2ZXIgc2VuZCBhbiBSQSB3aXRoIHRoZSBESENQdjY8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+b3B0aW9uIGluY2x1ZGVkIHVubGVzcyB0aGUgaG9zdCBmaXJzdCBzZW50 IGFuIFJTIHdpdGggREhDUHY2IG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPldpdGggYSBjb21iaW5lZCBhdXRvY29uZmlndXJhdGlvbiBzZXJ2aWNlICZu YnNwO2xpa2UgdGhpcywgdGhlIGFnZXMtb2xkIGRlYmF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hYm91 dCBTTEFBQyB2cy4gREhDUHY2IGdvZXMgYXdheSwgYW5kIHdlIHRydWx5IGdldCB0aGUgYmVzdCBv ZiBib3RoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPndvcmxkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBOYXZlZW4gS290dGFw YWxsaSBbbWFpbHRvOm5hdmVlbi5zYXJtYUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBEZWNlbWJlciAxMywgMjAxNyAzOjAzIEFNPGJyPg0KPGI+VG86PC9iPiBUZW1w bGluLCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiB2Nm9wc0BpZXRmLm9yZzsgaXB2NkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3Y2b3BzXSBXaW5kb3dzIDEwIGRvZXNuJ3QgaG9ub3VyICdNJyBmbGFnIGluIFJBPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgaXQg d291bGQgaGF2ZSBiZWVuIHRoZSBiZXR0ZXIgd2F5LiZuYnNwOyBJZiBjbGllbnRzIGFyZW4ndCBl dmVuIHJlZmVycmluZyB0aGUgJ00nIGJpdCwgd2hhdCBpcyB0aGUgdXNlIG9mIGNhcnJ5aW5nIGlu IFJBPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPllvdXJzLDxicj4NCk5hdmVlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMyBEZWNlbWJlciAyMDE3IGF0IDAwOjIwLCBUZW1w bGluLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t IiB0YXJnZXQ9Il9ibGFuayI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg aXMgd2h5IGl0IHdvdWxkIGJlIGJldHRlciB0byBoYXZlIElQdjYgTkQgYW5kIERIQ1B2NiBhcyBh IHVuaWZpZWQ8YnI+DQpzdGF0ZWxlc3Mvc3RhdGVmdWwgYXV0b2NvbmZpZ3VyYXRpb24gc2Vydmlj ZS4gRXZlcnl0aGluZyBjYW4gYmUgZG9uZSBpbjxicj4NCmEgc2luZ2xlIG1lc3NhZ2UgZXhjaGFu Z2UgKFJTL1JBIHdpdGggREhDUHY2IG9wdGlvbikgaW5zdGVhZCBvZjxicj4NCnJlcXVpcmluZyBt dWx0aXBsZSBtZXNzYWdlIGV4Y2hhbmdlcyBqdXN0IGZvciB0aGUgc2FrZSBvZiBleGFtaW5pbmc8 YnI+DQp0aGUgTS9PIGJpdHMuPGJyPg0KPGJyPg0KVGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzppcHY2QGlldGYub3JnIj5pcHY2QGlldGYub3JnPC9hPjxicj4NCkFkbWluaXN0cmF0aXZl IFJlcXVlc3RzOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwdjYiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXB2NjwvYT48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_97a10ed486fd4f8993cfade81f90c8daXCH150608nwnosboeingcom_-- From nobody Wed Dec 13 08:03:52 2017 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 74EEB126C0F for ; Wed, 13 Dec 2017 08:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yQ2yT-xbz5A for ; Wed, 13 Dec 2017 08:03:44 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B06712778D for ; Wed, 13 Dec 2017 08:03:44 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id d141so2549501qkc.12 for ; Wed, 13 Dec 2017 08:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pERvFuLpBW3Wk6DO7TxdQYSjbs1MR0yJwwkM0x3wOsk=; b=bW38XI0r+5EEMrsuSbzqaZE7aKBEJhfRZFuIi9X+dPhj9zK/rjPL/FZuAHhkHvDtbg QNcKmd0mvn6ugM+Iz3NPJWilzHNDVrnIVEcUOe/d+cEDSDBo0Rx4KhTijNGEJkykuT9i X/aH9tHv8Z5y+jV1mNwwY+VBvbTC/uzDQq6PLUyIqgEtcsAALutfteMDPsDx+W/aaQVd 2L0eaMH8GgQKdLzVSVCwD0Xs9xpnjvlSTrVz9Akx1He8Qrl/lNKYXdF1Lqlz+ueGPKqU 6MCTmnn73aToK06Ej4Lpm82CUATZlNFRq3nt4/4lY7Qvv/GLBI0xFfRW3ur0l4NEOBYj gGqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pERvFuLpBW3Wk6DO7TxdQYSjbs1MR0yJwwkM0x3wOsk=; b=JcmCegusmGYGNiiO6uNCBABccyld1xBGMwfCzLtyYbs6c3nhwyWcdtHHmqS935R+7R 8n+AScHspoxQJkzetJLrCi7pnPa9FsK/1gKj+HjpAO3cMl4NaZ0oek0MEnWD/qEovwmn 1wWaPom12ABVgsJXkSNVD3Sh9pE+to2IeRYJTMhNvYzeWXBR7w7rRLFzuyk7WDXOrviQ 2ZwDzzFTpBePN8Lqgky7kkmmos9K51vtZQyjoqF08VFQHkSj+Jk6uTGMsy5SDBTpGgX4 D0UNxe82teoZIisaJkha0XA8cjKWf5CtE7vicWQIjB4twVA25XyIbWFcQSAuRprQ02LP tDeA== X-Gm-Message-State: AKGB3mKGAKTyr0nInPw+jVfyXpVQZ0PSqGeZa1+XO8hMvzZo68VP88P0 p74RJ7Chh5J1cd3qmJUwG5wbcg== X-Google-Smtp-Source: ACJfBouaiTTAR8huiWuzq9jHyvTeEkRO2cEUu8WOyFiD9MNYnCF0SIht0dd2T0QCIUImTqafAdk3uw== X-Received: by 10.55.76.209 with SMTP id z200mr11291750qka.183.1513181023198; Wed, 13 Dec 2017 08:03:43 -0800 (PST) Received: from [10.0.30.153] (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id f5sm1264761qte.87.2017.12.13.08.03.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 08:03:41 -0800 (PST) From: Ted Lemon Message-Id: <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7459FA05-3802-4EC1-8F54-A91C47B1A452" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 13 Dec 2017 11:03:39 -0500 In-Reply-To: Cc: Naveen Kottapalli , "v6ops@ietf.org" , "ipv6@ietf.org" To: Tim Chown References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 16:03:46 -0000 --Apple-Mail=_7459FA05-3802-4EC1-8F54-A91C47B1A452 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 13, 2017, at 7:29 AM, Tim Chown wrote: > A =E2=80=98hint=E2=80=99 was the consensus. A 'hint' was the vote. I don't believe that it was a consensus. As = Naveen points out, the current solution is technically invalid. It = would be better not to have the 'M' bit than to have it be a hint. --Apple-Mail=_7459FA05-3802-4EC1-8F54-A91C47B1A452 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 13, 2017, at 7:29 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
A = =E2=80=98hint=E2=80=99 was the consensus.

A 'hint' was the vote.   I don't believe that = it was a consensus.   As Naveen points out, the current solution is = technically invalid.   It would be better not to have the 'M' bit = than to have it be a hint.


= --Apple-Mail=_7459FA05-3802-4EC1-8F54-A91C47B1A452-- From nobody Wed Dec 13 08:46:01 2017 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 8D0B4127077; Wed, 13 Dec 2017 08:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6lLVZhOPCVy; Wed, 13 Dec 2017 08:45:53 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824C1126D0C; Wed, 13 Dec 2017 08:45:53 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id 64so6369596wme.3; Wed, 13 Dec 2017 08:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zBbl1NwMWzear1xG0mC3Sza2wSECM0KOrUOuBCwKTXo=; b=RcDClaBgLfLhyF0hVxBQwg6qIepONHzTvyLYl2BNjPswUxmAmwftJ6vsV8MHOfH7ok 8g6GIWiGj/9c+/tIn3Q/raJdPSrGsMG8L0l3Fbe/qCETwbMywySDOzIwamAvGpGGFkSN hkaX7vrfI+lFFbPjf4oFWZO2E7L8PslbUn6UtAmRRR5OVSYxvdYiPgMwoVBbV0JK/4tW gcg1+6qOwVB0K62AQohAj3vbnDLhPH5yu7RIc7vurXsBoRzyQuScxIzqLYRLNYOj7j7s FrR3gKmG3Xo6ZMPuypXqxoNduE5hoKAWNn8GXP0hL+shPfkPGQ6TjeYQqB8SRYyLV+05 ArEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zBbl1NwMWzear1xG0mC3Sza2wSECM0KOrUOuBCwKTXo=; b=iX/mxIyYjD0WUuPOLsC7wG8GfBOAtteMcO/k+zlVZB1yPNUDWiENO6xNR7AgF/Cuho /xGz4Zjc7UXYxM2WnUSyiN4wVYG7ShY94xB0W+Oj3uwunLBDItt8qYo5KSDxmRdoKJR6 3ihJ80TkoxDfS0VE6V3Zb06deD+rBp4qI1gz2dgCslA4g+NZRkKv0dkD00pd1yCjRSGM 4ucUk0T3Gd7RAezrQqQZF+4a1EaJ+AQfMEsSfpxkTRgB3l7LDCTgVkpjk21phpUfAazZ r0GXXeZORJCr9JMSXmx7rrCW5HPX31jmN8ACR4xeEdaJHK3ufxvkJmsePnhYZQUFOjjH bBfA== X-Gm-Message-State: AKGB3mIk58GQIwDCbUIldMFVM+bXQ2CA1LbfF1pZOV6Lb7LhL4T1jHk5 p5r9YnLMDKQzCasg+3fScHs= X-Google-Smtp-Source: ACJfBovXBg5M48EvTomUa91wagvIDsu9vyeiLUjlB/sYN73z6YdCpV6e/FQ3FP7GGqAzcnTbFy84HA== X-Received: by 10.28.26.139 with SMTP id a133mr2458931wma.90.1513183551972; Wed, 13 Dec 2017 08:45:51 -0800 (PST) Received: from ?IPv6:2601:647:4d01:db10:90c2:513b:e253:d64f? ([2601:647:4d01:db10:90c2:513b:e253:d64f]) by smtp.gmail.com with ESMTPSA id j13sm2269640wre.55.2017.12.13.08.45.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 08:45:51 -0800 (PST) From: Bob Hinden Message-Id: <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C0F48051-A8CD-4208-97DD-296856C70214"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Dec 2017 08:45:46 -0800 In-Reply-To: <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> Cc: Bob Hinden , Tim Chown , "v6ops@ietf.org" , IPv6 List To: Ted Lemon References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 16:45:55 -0000 --Apple-Mail=_C0F48051-A8CD-4208-97DD-296856C70214 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ted, The actual text from Section 4.2. "Router Advertisement Message = Format=E2=80=9D in RFC4861 is: M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information. O 1-bit "Other configuration" flag. When set, it indicates that other configuration information is available via DHCPv6. Examples of such information are DNS-related information or information on other servers within the network. Note: If neither M nor O flags are set, this indicates that no information is available via DHCPv6. I think the protocol specification is clear. Bob > On Dec 13, 2017, at 8:03 AM, Ted Lemon wrote: >=20 > On Dec 13, 2017, at 7:29 AM, Tim Chown wrote: >> A =E2=80=98hint=E2=80=99 was the consensus. >=20 > A 'hint' was the vote. I don't believe that it was a consensus. As = Naveen points out, the current solution is technically invalid. It = would be better not to have the 'M' bit than to have it be a hint. >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_C0F48051-A8CD-4208-97DD-296856C70214 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloxWToACgkQrut0EXfn u6hcNgf+J62GtXZWFlswU45x4g+QAjmSCJTT8CZCGUxpQkDf2JLraiLdJ3gU/gry /BAJgeOZOnODQO19J57KPPvucrqpFeTZSU2GhaWiGX2Musjh5vSTWyB3ittQEjL2 ut86ExXZth89dxuRk6YVFwuaZ2DLpuX8RwdR8wXm4XgDD8nT+DV/kkUVTItFRCIq 0/FHImOPkKIFMqtxLFyxTEqXlMlt04i2XNqmddM2RvlhxhH8KH/rPRmd5szMGUpD KH1D1fEH97vDV4S03LKEEgl0zZQuxpYkmVfgtMJsT/HV/j7Tan5YvNRC2NtMhQ5X fzoXE7S1nP4d+zG85h+FzzTL2MCr9Q== =6rey -----END PGP SIGNATURE----- --Apple-Mail=_C0F48051-A8CD-4208-97DD-296856C70214-- From nobody Wed Dec 13 09:16:22 2017 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 4FFFA1270FC; Wed, 13 Dec 2017 09:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGxiB_DDCBEd; Wed, 13 Dec 2017 09:16:14 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541A612706D; Wed, 13 Dec 2017 09:16:14 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id 74so3532109lfs.0; Wed, 13 Dec 2017 09:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bsinnr+IWesqa8ngIVnJrYgT8LAZcSNegS03WfHJYqM=; b=dnzuxVcywtXnuDF+e2iNV0CuMN7kC4k8UavOLs/HX3eK1TR4Jxahe15yYCb1wuAYFI pvZX3z8rM6RQ+qd+8P+VJBSi8BD17ZIfMZHke/apItIy/d5wgfM9lGPTAMoiLnQbEfAn rSdT1YvcUgdOz2SHJ/MHxD01rO0WT61lzLcrSneG+t0/oTOBHOeS3qyTVT2RyyqbDGyH fwf4sfe2tmN+RTe/O8nULjfJwjObZedWSh0b+rddZCNbwEO6sd3cQWTnIJjLkLnhweCh oiDt2dRLHc8fClmkJlrvXYPdbR6MQQGKuhg1NbCRFBCU0zU+gIIifI0BE789mlrElffH atJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bsinnr+IWesqa8ngIVnJrYgT8LAZcSNegS03WfHJYqM=; b=gfaWvoF0iSKKK5CZFgwzxjYchfnBkBF3+ZGSqW4ni1Xppvx8mwaDTgEh2XaRdmCXeU r3KV6Jht56CGhxzRV/JhQzdqwuhpa2+oLU8F0OGj8ovCeR/RQedyyCZ+v0M/JZqoTlLa LTduyzb9gRjXzO+d7vKDIbq0/48nFJosYKcS+qLiemn8RZymSB65l2NyRRTihmEL0WED zJwhRR6qBgLgO21caf2iHw8e+lpI2LfFdoum5d+NIdnHkRmgV3WZNlBRXPGwjPrBYUCC nj+VB3DaZkN/21O2upFlqwaiAZfnITAQS22UT91sitX/ZOsy0IVhlsZs623eRU1JC02M 4Htg== X-Gm-Message-State: AKGB3mJzB1iabyi9Ys7rUysb0oY/TsMr5eCjGB+l/hLSGRhv0cTS2WsH zrck+K380jesF8T5b1Fuok5M+cyvhoZUvht9z0k= X-Google-Smtp-Source: ACJfBou7vNPeX1kutEa0lZPjhyKA0Mz1eL05EfMrx9Unl1/FgWJIxKr5x+mQ0bBZDya/4kYcuusyoiZ5TrPJBDYNpFM= X-Received: by 10.25.163.17 with SMTP id m17mr2050738lfe.88.1513185372562; Wed, 13 Dec 2017 09:16:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.2.212 with HTTP; Wed, 13 Dec 2017 09:15:51 -0800 (PST) In-Reply-To: <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> From: Naveen Kottapalli Date: Wed, 13 Dec 2017 22:45:51 +0530 Message-ID: To: Bob Hinden Cc: Ted Lemon , IPv6 List , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a114033609c6aeb05603bec9b" Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 17:16:16 -0000 --001a114033609c6aeb05603bec9b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Response inline. Yours, Naveen. On 13 December 2017 at 22:15, Bob Hinden wrote: > Ted, > > The actual text from Section 4.2. "Router Advertisement Message Format=E2= =80=9D in > RFC4861 is: > > M 1-bit "Managed address configuration" flag. When > set, it indicates that addresses are available via > Dynamic Host Configuration Protocol [DHCPv6]. > > Naveen] This statement isn't saying that 'M' bit SHOULD / SHALL be referred to learn or get the addresses via DHCPv6. This is where the point is. If the M flag is set, the O flag is redundant and > can be ignored because DHCPv6 will return all > available configuration information. > > O 1-bit "Other configuration" flag. When set, it > indicates that other configuration information is > available via DHCPv6. Examples of such information > are DNS-related information or information on other > servers within the network. > > Note: If neither M nor O flags are set, this indicates that no > information is available via DHCPv6. > > I think the protocol specification is clear. > > Bob > > > > > > On Dec 13, 2017, at 8:03 AM, Ted Lemon wrote: > > > > On Dec 13, 2017, at 7:29 AM, Tim Chown wrote: > >> A =E2=80=98hint=E2=80=99 was the consensus. > > > > A 'hint' was the vote. I don't believe that it was a consensus. As > Naveen points out, the current solution is technically invalid. It woul= d > be better not to have the 'M' bit than to have it be a hint. > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --001a114033609c6aeb05603bec9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Response inline.

Yours,
Naveen.

On 13 December 2017 at 22:15, Bob Hinden <bob.hinden@gmail.com> wrote:
Ted,

The actual text from Section 4.2. "Router Advertisement Message Format= =E2=80=9D in RFC4861 is:

=C2=A0 =C2=A0 =C2=A0 M=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1-bi= t "Managed address configuration" flag.=C2=A0 When
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0set, it indicates that addresses are available via
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Dynamic Host Configuration Protocol [DHCPv6].

Naveen] This statement isn't saying that &= #39;M' bit SHOULD / SHALL be referred to learn or get the addresses via= DHCPv6.=C2=A0 This is where the point is.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0If the M flag is set, the O flag is redundant and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0can be ignored because DHCPv6 will return all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0available configuration information.

=C2=A0 =C2=A0 =C2=A0 O=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1-bi= t "Other configuration" flag.=C2=A0 When set, it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0indicates that other configuration information is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0available via DHCPv6.=C2=A0 Examples of such information
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0are DNS-related information or information on other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0servers within the network.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Note: If neither M nor O flags are set, this in= dicates that no
=C2=A0 =C2=A0 =C2=A0 =C2=A0 information is available via DHCPv6.

I think the protocol specification is clear.

Bob




> On Dec 13, 2017, at 8:03 AM, Ted Lemon <mellon@fugue.com> wrote:
>
> On Dec 13, 2017, at 7:29 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
>> A =E2=80=98hint=E2=80=99 was the consensus.
>
> A 'hint' was the vote.=C2=A0 =C2=A0I don't believe that it= was a consensus.=C2=A0 =C2=A0As Naveen points out, the current solution is= technically invalid.=C2=A0 =C2=A0It would be better not to have the 'M= ' bit than to have it be a hint.
>
>
> ------------------= --------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> ------------------------------------------------------------= --------


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


--001a114033609c6aeb05603bec9b-- From nobody Wed Dec 13 10:49:36 2017 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 6260612704B; Wed, 13 Dec 2017 10:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54zyrGR2iP01; Wed, 13 Dec 2017 10:49:28 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D451126E01; Wed, 13 Dec 2017 10:49:28 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id j9so1620623pgc.11; Wed, 13 Dec 2017 10:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6nWpVLjd8z7nlJHXrnjMk8EQaFImOsI7XOtHtC84kts=; b=IvYRn+36YcjUnTppb0Cg+cyN2ZQ1KG2M5Qr+A4HURKDWUwdc1lAyDCErFUv1HE9FS9 SDvxfzec1c0/TmMVasSS+kXKJvz+I5q3aqfBnVoKOQua/QpZ6AQLN1ubBw/QjpH71XxU BbXxhs7RErRYaMdYdhd+CN8T+0fja6eV1VQOE913MLTJrkfmD/qDsQ7fu+7QxXBPEPgd tyrCuWSz/bxCgziP6MmPG4hOLuYA7qHVUvYY781rgEde82oUnfJVzccECWIv0viiffDd MFhntQ/AiKDzXhsbeWxqhXCc5RgmLOJPO5pyoL72rL9BfShDyJ8pGcoHiHCmlm/eICa/ emGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=6nWpVLjd8z7nlJHXrnjMk8EQaFImOsI7XOtHtC84kts=; b=lEklZ7jsxqf7pb7i9RJWdP8a+2WfQBaaF2AUlOsCJbrYCl/fUmu2YXWit6Ml8pCrly piP8YVE2GcOOcVZgcB1vlhb9UeiMHhLrAXTPBNkgwdUztPNnL1c5V+MidPuo7im2oXBf Ti+B5tmEsId6kJGH/cYppZCGzM5VrKlYXAtT+viv7DjSBsVFkXETyPGvET7vOU7ZcT95 //TOos99Jf8BAPcWOFHuZ/I/P3vwX04OcKqEcxhLK8sfx3utmr4nVcysNhu2fNz0096e 13EHbQceKIdwKEE4xgk1jbgaBCkpiW+QGt3v0iSG0oLCBlsDG9XeSOwUTJJZ1hulAf+n aYTw== X-Gm-Message-State: AKGB3mL2wCY/RgA2Oh2+yzdkjdsS/Z0yEE0KcNin5r3eiNcn0930UZiz PFO8aYcN+Mr2tIA3eykWqrU= X-Google-Smtp-Source: ACJfBov46Qp7FqORp4iskYiT9ExCrE4WVxjLJeBpqh9fdmtPtfn4bBvBONir/DKKQIkAxdXCU3P2Ug== X-Received: by 10.84.204.8 with SMTP id a8mr6766060ple.399.1513190967573; Wed, 13 Dec 2017 10:49:27 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s11sm3969393pgn.80.2017.12.13.10.49.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 10:49:26 -0800 (PST) To: Naveen Kottapalli , Bob Hinden Cc: IPv6 List , "v6ops@ietf.org" , Ted Lemon References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 14 Dec 2017 07:49:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 18:49:30 -0000 On 14/12/2017 06:15, Naveen Kottapalli wrote: > Response inline. >=20 > Yours, > Naveen. >=20 > On 13 December 2017 at 22:15, Bob Hinden wrote: >=20 >> Ted, >> >> The actual text from Section 4.2. "Router Advertisement Message Format= =E2=80=9D in >> RFC4861 is: >> >> M 1-bit "Managed address configuration" flag. When= >> set, it indicates that addresses are available vi= a >> Dynamic Host Configuration Protocol [DHCPv6]. >> >>=20 > [Naveen] This statement isn't saying that 'M' bit SHOULD / SHALL be > referred to learn or get the addresses via DHCPv6. This is where the p= oint > is. See below for why this cannot be a requirement. > If the M flag is set, the O flag is redundant and >> can be ignored because DHCPv6 will return all >> available configuration information. >> >> O 1-bit "Other configuration" flag. When set, it >> indicates that other configuration information is= >> available via DHCPv6. Examples of such informati= on >> are DNS-related information or information on oth= er >> servers within the network. >> >> Note: If neither M nor O flags are set, this indicates that no= >> information is available via DHCPv6. >> >> I think the protocol specification is clear. Well, the "Note:" does leave an open question. How does the person (or automaton) configuring the router that sends the RA know that no information is available via DHCPv6? It is entirely possible that DHCPv6 is available on another box, and the person configuring the the router doesn't know it. So these flags are intrinsically unreliable and can only be hints; it's *necessary* that hosts are allowed to ignore them and look for DHCPv6 anyway. [BTW I came to this realisation after drafting the text in https://tools.ietf.org/html/draft-hinden-ipv4flag-01#section-4. The logic of the situation is quite similar.] Brian From nobody Wed Dec 13 11:32:34 2017 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 4B7C61275F4; Wed, 13 Dec 2017 11:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ENh10C-2KUU; Wed, 13 Dec 2017 11:32:31 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA07124F57; Wed, 13 Dec 2017 11:32:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5434820090; Wed, 13 Dec 2017 14:35:49 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 164DE814AD; Wed, 13 Dec 2017 14:32:30 -0500 (EST) From: Michael Richardson To: "v6ops\@ietf.org" , IPv6 List In-Reply-To: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 19:32:33 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >>> O 1-bit "Other configuration" flag. When set, it >>> indicates that other configuration information is >>> available via DHCPv6. Examples of such information >>> are DNS-related information or information on other >>> servers within the network. > Well, the "Note:" does leave an open question. How does the person (or > automaton) configuring the router that sends the RA know that no > information is available via DHCPv6? It is entirely possible that > DHCPv6 is available on another box, and the person configuring the > the router doesn't know it. So these flags are intrinsically unreliable > and can only be hints; it's *necessary* that hosts are allowed to > ignore them and look for DHCPv6 anyway. So, maybe what we should be writing is: O 1-bit "Other configuration" flag. When clear it indicates that this router believes that it has all available/valid configuration information. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloxgE0ACgkQgItw+93Q 3WWaTwgAiLUm76e6KmPdxrY1KBOy19jziipePOpmUhPVf7pqagRlKbWDZI85wJBt u11pNT4sQb2alsqusx967xAC5uyG41OWsbbuabjt7rsp/cCl/NLsZqglhPequak8 nWGxvpEhgf8aDIbyuVTmUlkOAyaLtW4MPVizfzllAkQwGE3NylbCzU+ACFoRETVb qYTnW0HLc7BgoaNWrP+oEEZx0ZniOhF0cr2V81TUqliYGhLbk3G+L8b1emhsDjd1 nS/J/Enx3SIA8nFWi7Gs9KzjhB3UP5gEjS8Lleydvz1GuyP7ap2DYHNGZuf/Xkkt w8itgW2dOjgwGIGxw/OmcZIwYM/Ulw== =6U3v -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 13 11:35:52 2017 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 6C3651275F4; Wed, 13 Dec 2017 11:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijbxMTFQ-0jX; Wed, 13 Dec 2017 11:35:44 -0800 (PST) Received: from patsy.thehobsons.co.uk (ruthandcrusoe.plus.com [81.174.150.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CFE127058; Wed, 13 Dec 2017 11:35:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from simons-macbookpro.lan (unknown [80.229.10.150]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 063021BC37; Wed, 13 Dec 2017 19:35:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Wed, 13 Dec 2017 19:34:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> To: "v6ops@ietf.org list" , IPv6 List X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 19:35:46 -0000 Brian E Carpenter wrote: > Well, the "Note:" does leave an open question. How does the person (or > automaton) configuring the router that sends the RA know that no > information is available via DHCPv6? It is entirely possible that > DHCPv6 is available on another box, and the person configuring the > the router doesn't know it. So these flags are intrinsically = unreliable > and can only be hints; it's *necessary* that hosts are allowed to > ignore them and look for DHCPv6 anyway. I keep hearing this argument time and time again, but cannot reconcile = it with any professionally managed network. Are there really = professionally managed networks where the guys responsible for the = routers (intrinsically tied in with the network config) don't talk to = the guys running DHCP servers (intrinsically tied in with the network = config) ? Put another way, are there really networks where two different groups = "do their own thing" without agreeing between themselves how the network = is supposed to work ? From nobody Wed Dec 13 11:41:19 2017 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 2AA87127AD4; Wed, 13 Dec 2017 11:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFTdjv0EChLv; Wed, 13 Dec 2017 11:41:16 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BE5126E7A; Wed, 13 Dec 2017 11:41:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vBDJfFdb040849; Wed, 13 Dec 2017 12:41:15 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vBDJfBDG040804 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 13 Dec 2017 12:41:11 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 13 Dec 2017 11:41:10 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1347.000; Wed, 13 Dec 2017 11:41:10 -0800 From: "Templin, Fred L" To: Simon Hobson , "v6ops@ietf.org list" , IPv6 List Thread-Topic: [v6ops] Windows 10 doesn't honour 'M' flag in RA Thread-Index: AQHTc3ids/3rysN/2UOtzik0uog6BqNADGWAgAGf3HSAAAE2IA== Date: Wed, 13 Dec 2017 19:41:10 +0000 Message-ID: <5a503a3d1fcd43e882c782b6b9031e79@XCH15-06-08.nw.nos.boeing.com> References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 19:41:18 -0000 Hi, > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Simon Hobson > Sent: Wednesday, December 13, 2017 11:35 AM > To: v6ops@ietf.org list ; IPv6 List > Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA >=20 > Brian E Carpenter wrote: >=20 > > Well, the "Note:" does leave an open question. How does the person (or > > automaton) configuring the router that sends the RA know that no > > information is available via DHCPv6? It is entirely possible that > > DHCPv6 is available on another box, and the person configuring the > > the router doesn't know it. So these flags are intrinsically unreliable > > and can only be hints; it's *necessary* that hosts are allowed to > > ignore them and look for DHCPv6 anyway. >=20 > I keep hearing this argument time and time again, but cannot reconcile it= with any professionally managed network. Are there really > professionally managed networks where the guys responsible for the router= s (intrinsically tied in with the network config) don't talk > to the guys running DHCP servers (intrinsically tied in with the network = config) ? > Put another way, are there really networks where two different groups "do= their own thing" without agreeing between themselves > how the network is supposed to work ? A unified SLAAC/DHCPv6 service would reconcile the ambiguity. Thanks - Fred > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Dec 13 12:27:56 2017 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 48F23126FDC for ; Wed, 13 Dec 2017 12:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPJ09hvGzSbf for ; Wed, 13 Dec 2017 12:27:48 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2D9128792 for ; Wed, 13 Dec 2017 12:27:48 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id l24so1938990pfj.6 for ; Wed, 13 Dec 2017 12:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=yrycD/NqndSEpfDnO9jlGvRkPUIoupM1wFMGife/TRA=; b=fI4yxmnsiMLokm/IlYGKbAcKYY2Q5vroZppOXf1gm31KKLusdbokERx9oJVq/5lnql jc+vm5ZnGcwziizZpvFDVdOs9fy/3tYn0csihp9nL632HktEORbNiGbY8EYdYBLOcjGt viB3sZUupQHcd5qfgiu6g3j+F0k/++sUIZGbWQ/3X1TKMYAbB3e1gOxSlQmI3e8f/Ld9 1L+pxUCajvIGd34jG5bKKwmRbLhy5CnEipi2URk3W/Ilm87mhdLoXycoUd3vbGs18tzm AH3VuulBIlQdpo7qeRLFDRGPybQXoFCjZU5osxtfXaY3oWHfOeQsF1eC5AQPUUApfORM /coQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=yrycD/NqndSEpfDnO9jlGvRkPUIoupM1wFMGife/TRA=; b=Z0UqbABHSB3MMt2BoPJMWHw+8FXfohgMEaymWumzKBBrkVeqLZTRVF84ectQEHf3ZP UVIKWAspyqGwxaOff6EsjUxAbw/MJE3YayFqij663VKrY63hgZULSCVcCtzxUf62ccoO nxtCklvYtIeQBAOvpG42PZz8be8EH7EuaeRXx7v1J2lrQ3TDxxUk548JPKKa3BvWL/HC DKZYcmf6DzgHfmQzS0Yx1ZWE3mHSn0vEXMchWZLay3T9ll1vXZOa45b5dwHR43uXYGjB SrlgIOZRwR9c+d/MIvNQ92pV1jV+/MUO9Jk83uR0hB6ns/hIySyspy5Z/LZNPx67Do9m RSBw== X-Gm-Message-State: AKGB3mIFSlXWvhTjItoOtdvjTOejLDmZJu+KHTjh4EyYvvyHB3uXeH5E Ao3lx4THRGh49lXla1qcIzx9CSj7GvM= X-Google-Smtp-Source: ACJfBouiW2lTEcSMxltOExsZcEhzEWKaM0itg+cbPh8YY6OtOxI0K0cTbIzixCHBnZn9hWzaRq8XHQ== X-Received: by 10.98.223.217 with SMTP id d86mr7314737pfl.190.1513196867242; Wed, 13 Dec 2017 12:27:47 -0800 (PST) Received: from ?IPv6:2620::10e7:10:982f:6dc7:6cfc:285? ([2620:0:10e7:10:982f:6dc7:6cfc:285]) by smtp.gmail.com with ESMTPSA id d6sm4014594pgn.69.2017.12.13.12.27.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 12:27:46 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_A2D15CD6-4CBA-4FA9-AA78-4B735D81784E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Dec 2017 12:27:45 -0800 References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> To: "v6ops@ietf.org list" , IPv6 List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 20:27:50 -0000 --Apple-Mail=_A2D15CD6-4CBA-4FA9-AA78-4B735D81784E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 13, 2017, at 11:34, Simon Hobson wrote: > Brian E Carpenter wrote: >=20 >> Well, the "Note:" does leave an open question. How does the person = (or >> automaton) configuring the router that sends the RA know that no >> information is available via DHCPv6? It is entirely possible that >> DHCPv6 is available on another box, and the person configuring the >> the router doesn't know it. So these flags are intrinsically = unreliable >> and can only be hints; it's *necessary* that hosts are allowed to >> ignore them and look for DHCPv6 anyway. >=20 > I keep hearing this argument time and time again, but cannot reconcile = it with any professionally managed network. Are there really = professionally managed networks where the guys responsible for the = routers (intrinsically tied in with the network config) don't talk to = the guys running DHCP servers (intrinsically tied in with the network = config) ? > Put another way, are there really networks where two different groups = "do their own thing" without agreeing between themselves how the network = is supposed to work ? Put another way, "are there really professionally managed networks?=E2=80=9D= Worth noting: the point is that the =E2=80=9CNote:=E2=80=9D in RFC 4861 = cited previously in the thread asserts that M=3D0&O=3D0 is a signal to = all hosts on the link that =E2=80=9Cno information is available via = DHCPv6,=E2=80=9D which is really only true while *all* the routers on = the link are consistently sending that signal. It stops being true as = soon as one or more of the routers on the link contradict the signal, = and it continues to not be true until all the contradicting routers = expire their valid lifetimes. On a =E2=80=9Cprofessionally managed = network,=E2=80=9D there might never be any contradicting routers on the = link at any time, and in that case the Note correctly describes how the = protocol works. In other cases, however, it remains a little less than = clear. So, I ask again: are there really professionally managed networks? --james woodyatt > --Apple-Mail=_A2D15CD6-4CBA-4FA9-AA78-4B735D81784E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Dec 13, 2017, at 11:34, Simon Hobson <linux@thehobsons.co.uk> wrote:
Brian E = Carpenter <brian.e.carpenter@gmail.com> wrote:

Well, the "Note:" does = leave an open question. How does the person (or
automaton) = configuring the router that sends the RA know that no
information is available via DHCPv6? It is entirely possible = that
DHCPv6 is available on another box, and the person = configuring the
the router doesn't know it. So these flags = are intrinsically unreliable
and can only be hints; it's = *necessary* that hosts are allowed to
ignore them and look = for DHCPv6 anyway.

I keep = hearing this argument time and time again, but cannot reconcile it with = any professionally managed network. Are there really professionally = managed networks where the guys responsible for the routers = (intrinsically tied in with the network config) don't talk to the guys = running DHCP servers (intrinsically tied in with the network config) = ?
Put another way, are there really networks where two = different groups "do their own thing" without agreeing between = themselves how the network is supposed to work ?

Put = another way, "are there really professionally managed = networks?=E2=80=9D

Worth noting: the = point is that the =E2=80=9CNote:=E2=80=9D in RFC 4861 cited previously = in the thread asserts that M=3D0&O=3D0 is a signal to all hosts on = the link that =E2=80=9Cno information is available via DHCPv6,=E2=80=9D = which is really only true while *all* the routers on the link are = consistently sending that signal. It stops being true as soon as one or = more of the routers on the link contradict the signal, and it continues = to not be true until all the contradicting routers expire their valid = lifetimes. On a =E2=80=9Cprofessionally managed network,=E2=80=9D there = might never be any contradicting routers on the link at any time, and in = that case the Note correctly describes how the protocol works. In other = cases, however, it remains a little less than clear.

So, I ask again: are there really professionally = managed networks?


--james woodyatt <jhw@google.com>



= --Apple-Mail=_A2D15CD6-4CBA-4FA9-AA78-4B735D81784E-- From nobody Wed Dec 13 12:35:31 2017 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 D547212704B for ; Wed, 13 Dec 2017 12:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJvjKPIGO6Ij for ; Wed, 13 Dec 2017 12:35:26 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12D5126FDC for ; Wed, 13 Dec 2017 12:35:26 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id e14so1825430pgr.9 for ; Wed, 13 Dec 2017 12:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=piChKBby1zZIs0YJmi6ySDQvmTF73NlGNhkCFC3BN2g=; b=HmlLkVoFN9hCdsMqXO3stxdJ0GB7XyDEZlUjVbynLiqa2pbNzUBbGFPoYQTFpbs6d4 pFlZIdE4yBcMcU3OE5DZkRutAgOph+y02b+eqYxIgDqXPkH7Hmb+KdUk+LvqzKL+nCpc Z/ewmPwgUHqyB9aTIR3fAGhgTMtGrF6o/ePsFys3OAtP5CZM02xoDxyG5YoUwNzokxOG jGdoStLC1yGxbLC0W3oIzDC+kj0hoOayDcCt0cmBblDDdJQJfFDj9NBekhWN30BVo8ce eVGwcTldnLhdTwvqFaLojQKzyjS7dPEn/PGnHjDAgcufTmQq1jRVOydxZqII6+XOtyEY vFfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=piChKBby1zZIs0YJmi6ySDQvmTF73NlGNhkCFC3BN2g=; b=RgUJ4C9Hrkv15E4Da8he0Oj2LIFXLYiP2FxhkTaICIH41/JVmueu42r++TduY0ZGQc OLd6Xj+v9Dom5I6iLXR/bobCh/2VZ33lzptiWgSmFcqQQf26akMyvKKHm2UDUGX5Rz5f kL0bcptT/INw4CsqFpfirp37a9j1todZGFWbclrAovydNFxkPCVOF4Q/Dz1jMGr0WTM+ xM9oyKIbCsH/MLaG8toO3lReX7wutIHkG52Z9tJFZQ1pPzEolwuhCnb5i27lwTECkyyM gt1FpTXcIRZS75YdEj9pZPvMW9BgxubQ0bkUASA0mPOwFmFbw39ani+AbeZQAmkGh6Iw lsLw== X-Gm-Message-State: AKGB3mKV3z6IB6zdfiF5UEGcbb/kIm6+7ka6bOMQS2f3hRh0nN1rrzAK o/KTi+ElMbzZEFldh8B48f8DqA== X-Google-Smtp-Source: ACJfBoujPg/5rXtsCUd5kwZS/h7jTPOYhW5cmaKJzwejVpc/3+b5mFpQhgxNgi0GMFY4DEj/k6nzDw== X-Received: by 10.98.18.157 with SMTP id 29mr7257540pfs.84.1513197326023; Wed, 13 Dec 2017 12:35:26 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z2sm4021640pgu.17.2017.12.13.12.35.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 12:35:25 -0800 (PST) To: v6ops@ietf.org References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> <5a503a3d1fcd43e882c782b6b9031e79@XCH15-06-08.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5c4f07c7-db5d-2d78-2af2-c1d410cbb279@gmail.com> Date: Thu, 14 Dec 2017 09:35:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5a503a3d1fcd43e882c782b6b9031e79@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 20:35:29 -0000 On 14/12/2017 08:41, Templin, Fred L wrote: > Hi, > >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Simon Hobson >> Sent: Wednesday, December 13, 2017 11:35 AM >> To: v6ops@ietf.org list ; IPv6 List >> Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA >> >> Brian E Carpenter wrote: >> >>> Well, the "Note:" does leave an open question. How does the person (or >>> automaton) configuring the router that sends the RA know that no >>> information is available via DHCPv6? It is entirely possible that >>> DHCPv6 is available on another box, and the person configuring the >>> the router doesn't know it. So these flags are intrinsically unreliable >>> and can only be hints; it's *necessary* that hosts are allowed to >>> ignore them and look for DHCPv6 anyway. >> >> I keep hearing this argument time and time again, but cannot reconcile it with any professionally managed network. Are there really >> professionally managed networks where the guys responsible for the routers (intrinsically tied in with the network config) don't talk >> to the guys running DHCP servers (intrinsically tied in with the network config) ? >> Put another way, are there really networks where two different groups "do their own thing" without agreeing between themselves >> how the network is supposed to work ? Simon: I hope it's rare. I also hope that autonomic networking will make it even rarer. But it's possible, and there are also unmanaged networks in the world. So I think we have to allow for it in our protocol standards, and host o/s's need to be ready for it. > > A unified SLAAC/DHCPv6 service would reconcile the ambiguity. Same answer. We could imagineer that, but we can't impose it. Brian From nobody Wed Dec 13 13:00:44 2017 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 CA0F9127863 for ; Wed, 13 Dec 2017 13:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj7IojxjU35F for ; Wed, 13 Dec 2017 13:00:36 -0800 (PST) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4674A126E7A for ; Wed, 13 Dec 2017 13:00:36 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id B0576B9 for ; Wed, 13 Dec 2017 21:00:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALgvfyfVgcBg for ; Wed, 13 Dec 2017 15:00:35 -0600 (CST) Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com [209.85.215.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 4DA7419B for ; Wed, 13 Dec 2017 15:00:35 -0600 (CST) Received: by mail-lf0-f71.google.com with SMTP id p18so860818lfp.22 for ; Wed, 13 Dec 2017 13:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+VRS1OPIsSgKBn5I1/sHF5bVCpiJy9bjPuKeeLmaH5I=; b=ozB5GgwvP3flT+723uSkK5kM6WDuu8ga1WTX+9J9EbWKnM5Q0BAw44iDE9hux7peuk ex4zgn5wqK6yhEeMnS7ASvqbG7qGTa+vdeEZGtTAo1TXgTz9GTbPLirweOWUS3ebHSw6 dJ7ATAaLvfVIZ9+1cn5/MG8uM+cj0+13D6AYQx10Dz9Nc7jazYOPdRWxXIJ69pWwLcYn wwH5sMrouOMIEBg2c24vGgBYIWnM/HeCJ9raTAusBnNijtsLY7XUnol0T0BAYFpyb8Pn /OP/N6vqAN6if1dc8mWf68UO6iygnPhVSukJ4OUSPcgmZDGbutJivZBK7uQaW8aAT9Aj 1j1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+VRS1OPIsSgKBn5I1/sHF5bVCpiJy9bjPuKeeLmaH5I=; b=XXge9nmbDlhz630tUW4joYbaoAw1IvottOo46ZjN9RGRBqxJM1MJoXRQH1GjndWuii 74j4kSuedqaMzwzDWBDQ4vDbSBOoxYR4YfcnDXrtorPOuOM6wQUdhkCHCfRpI0ZfPL3W 6d1hTUtU5xaF0QOwVv775R4aq7IFXZcuzFRudNaAchOHB7uxFO1/F67RhOomvkttjnG+ D+N/jMv38Wlw0d7X/Iyo2QPxieIAOkFc67vLRmaNFQypbW+qQ9pw+ju9vewYfllyCSKn hOPBoImrj1oTvg+H1E93HEVuGzzxX6sRPd4/FYHflioM2XZhio/aJabe3OtOXG1tSPVL lHUQ== X-Gm-Message-State: AKGB3mLwmFtY3pNknI9HkKUVOB1PTSWcyO7vfbcTOwRdP3kzr8r/82AU +9FQ1A/Tlv5gE8VSg1VH7uU+oBwZmD/O0FL8gX7NsyiH0NH6D5U6KtX+HMn1iesj/1va3IeyMsV 8Y8owwgIpQJamfpTvVXCMWPIEkw== X-Received: by 10.46.88.77 with SMTP id x13mr229450ljd.80.1513198833424; Wed, 13 Dec 2017 13:00:33 -0800 (PST) X-Google-Smtp-Source: ACJfBosJrZuMgCI67cZOkUQkEwZzstjS4HQGRUzyHui/nJfpvN+J4sqAXMq5J1tnyHLh9dii/A4rAP2/2e1rt6aGD6o= X-Received: by 10.46.88.77 with SMTP id x13mr229439ljd.80.1513198833135; Wed, 13 Dec 2017 13:00:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.216.99 with HTTP; Wed, 13 Dec 2017 13:00:32 -0800 (PST) In-Reply-To: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> From: David Farmer Date: Wed, 13 Dec 2017 15:00:32 -0600 Message-ID: To: Simon Hobson Cc: "v6ops@ietf.org list" , IPv6 List Content-Type: multipart/alternative; boundary="f4030438f0f0ec7f2605603f0e0c" Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 21:00:40 -0000 --f4030438f0f0ec7f2605603f0e0c Content-Type: text/plain; charset="UTF-8" On Wed, Dec 13, 2017 at 1:34 PM, Simon Hobson wrote: > Brian E Carpenter wrote: > > > Well, the "Note:" does leave an open question. How does the person (or > > automaton) configuring the router that sends the RA know that no > > information is available via DHCPv6? It is entirely possible that > > DHCPv6 is available on another box, and the person configuring the > > the router doesn't know it. So these flags are intrinsically unreliable > > and can only be hints; it's *necessary* that hosts are allowed to > > ignore them and look for DHCPv6 anyway. > > I keep hearing this argument time and time again, but cannot reconcile it > with any professionally managed network. Are there really professionally > managed networks where the guys responsible for the routers (intrinsically > tied in with the network config) don't talk to the guys running DHCP > servers (intrinsically tied in with the network config) ? > Put another way, are there really networks where two different groups "do > their own thing" without agreeing between themselves how the network is > supposed to work ? > So when the people running the DHCPv6 servers screw up, and the DHCP server is down, what tells the router tat DHCPv6 isn't available? Nothing, therefore, at best the M and O flags signal an intent not a fact, and should only be considered advisory. So I consider the M an O flags to mean; 1 = there should be a DHCPv6 server, and therefore hosts should keep trying if one doesn't readily answer 0 = there should not be a DHCPv6 server, and therefore hosts should not keep trying if one doesn't readily answer, or hosts might not try at all Furthermore, even if there is no router on the link to advertise an RA, or if the router is misconfigured to set M and O flags = 0, that doesn't mean there isn't a DHCPv6 severer on the link, or available via routed multicast. Its is probably safe to assume there isn't a DHCPv6 relay configured on the router though. This is why several OS send initial DHCPv6 Solicits. But, I would hope if M and O flags = 0, this would not be continued after a couple tries. In other words, if you send a couple solicits and get no answer, you have empirical evidence that the M and O flags = 0 is actually correct, and should then give up. I believe the M and O flag specification in RFC 4861 is technical correct, but is far too subtly written. I would be good when RFC 4861 is next update for this to be more plainly stated. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --f4030438f0f0ec7f2605603f0e0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 13, 2017 at 1:34 PM, Simon Hobson <linux@thehobsons.c= o.uk> wrote:
Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> Well, the "Note:" does leave an open question. How does the = person (or
> automaton) configuring the router that sends the RA know that no
> information is available via DHCPv6? It is entirely possible that
> DHCPv6 is available on another box, and the person configuring the
> the router doesn't know it. So these flags are intrinsically unrel= iable
> and can only be hints; it's *necessary* that hosts are allowed to<= br> > ignore them and look for DHCPv6 anyway.

I keep hearing this argument time and time again, but cannot reconcile it w= ith any professionally managed network. Are there really professionally man= aged networks where the guys responsible for the routers (intrinsically tie= d in with the network config) don't talk to the guys running DHCP serve= rs (intrinsically tied in with the network config) ?
Put another way, are there really networks where two different groups "= ;do their own thing" without agreeing between themselves how the netwo= rk is supposed to work ?

So when the pe= ople running the DHCPv6 servers screw up, and the DHCP server is down, what= tells the router tat DHCPv6 isn't available? Nothing, therefore, at be= st the M and O flags signal an intent not a fact, and should only be consid= ered advisory.=C2=A0 So I consider=C2=A0the M an O flags to mean;

1 =3D there should be a DHCPv6 server, and therefore hosts = should keep trying if one doesn't readily answer
0 =3D there = should not be a DHCPv6 server, and therefore=C2=A0hosts should not keep try= ing if one doesn't readily answer, or hosts might not try at all
<= div>
Furthermore, even if there is no router on the link to a= dvertise an RA, or if the router is misconfigured to set M and O flags =3D = 0, that doesn't mean there isn't a DHCPv6 severer on the link, or a= vailable via routed multicast. Its is probably safe to assume there isn'= ;t a DHCPv6 relay configured on the router though. This is why several OS s= end initial DHCPv6 Solicits. But, I would hope if M and O flags =3D 0, this= would not be continued after a couple tries. In other words, if you send a= couple solicits and get no answer, you have empirical evidence that the M = and O flags =3D 0 is actually correct, and should then give up.
<= br>
I believe the M and O flag specification in=C2=A0RFC 4861=C2=A0is technical correct, but is far= too subtly written. I would be good when=C2=A0RFC 4861 is next update for this to be more plainly=C2=A0stated.

Thanks.
=C2=A0
--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking &am= p; Telecommunication Services
Office of Information Technology
Univer= sity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0= Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
--f4030438f0f0ec7f2605603f0e0c-- From nobody Wed Dec 13 13:43:35 2017 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 E7A7E126D73; Wed, 13 Dec 2017 13:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weEb_le_AROf; Wed, 13 Dec 2017 13:43:32 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F364512704B; Wed, 13 Dec 2017 13:43:31 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id j28so2079970pfk.8; Wed, 13 Dec 2017 13:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YAMLiS5BErtR6umb+60F3azxbZ4FGHRRTmC3Xhd31w4=; b=Tsr7eYjO9PR+gf1lqvjBJe87J/dzPC8e7wGS63Z2rmj+3I8/Pu2W1qKD+RvLTkYmfX pOnaJ8Bs4JN4b/1qGB56IRKeQh/uCctPqzKnJXfxe7ITUk5dIBD3gyliF35duyLgHRHx pd8c986XWnY1N66ETtpH90H4ZnamNqcLLDpI7L/eKGvcFSe1pl8vZqkCdvNxisc+KMNE ZE9KiJFIMy09WAvxz22G1oAhLobvnyvYY44JGIW4NTRiHKfwhPLU2X5YxTEsccQRr63O LUtSqDUeJwkR4etPWo/3TCTbT9nhysei640fMe1UE8MlTc41IwVPe85inC8jcB05YWLr 265w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YAMLiS5BErtR6umb+60F3azxbZ4FGHRRTmC3Xhd31w4=; b=YkM1XsnM3lIUPW0nwPWEjnCJPGlerBhqL6489/3MXJBH9JxHyjNAtQ1T+i8qb+/62Y dilQRu+THct+YaokM9TqLJGqmmivHCXoPz+Bj8t5kiYrUmfVyQFQN/Aof+vNw+fD60rq yhyazMqu8DuOjGzw1VzZaB1PJ1TtM5H1pcIqYWvNukQsm804o3LS+XkHhzBrjy9pqK3b mYy2UsyRhlC6I2d570MzC0UQ8t3vobd5Iw+PkmAsWpQP91iaP+c1YueyNUk7n0wCTDOJ pram8YTwif2rEhslWIBkx33xQwGT8WhrD57sN151tSG0nHgkPV6m2evR2nLDsNRG8fuR 1glQ== X-Gm-Message-State: AKGB3mKksyN1Xx8cJgPkgDHkkN7fFnAZrOr/OsURdPBcDG9fApbHft12 VS/ljO4rxCwbAxr8YjUBYqw= X-Google-Smtp-Source: ACJfBot7pjWOmtYDSCc/N/6KE0gJfhXA0DgKzZlbtsabQVw71di3+UKgv0IqVujdkEveUlmY7V64Jw== X-Received: by 10.99.124.24 with SMTP id x24mr6470695pgc.196.1513201411569; Wed, 13 Dec 2017 13:43:31 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id z23sm4428634pgc.2.2017.12.13.13.43.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 13:43:29 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_098534B7-E197-4DB3-BC1B-1DFB55E961A1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Dec 2017 13:43:27 -0800 In-Reply-To: Cc: Bob Hinden , "v6ops@ietf.org list" , IPv6 List To: james woodyatt References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 21:43:34 -0000 --Apple-Mail=_098534B7-E197-4DB3-BC1B-1DFB55E961A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 James, > On Dec 13, 2017, at 12:27 PM, james woodyatt wrote: >=20 > On Dec 13, 2017, at 11:34, Simon Hobson = wrote: >> Brian E Carpenter wrote: >>=20 >>> Well, the "Note:" does leave an open question. How does the person = (or >>> automaton) configuring the router that sends the RA know that no >>> information is available via DHCPv6? It is entirely possible that >>> DHCPv6 is available on another box, and the person configuring the >>> the router doesn't know it. So these flags are intrinsically = unreliable >>> and can only be hints; it's *necessary* that hosts are allowed to >>> ignore them and look for DHCPv6 anyway. >>=20 >> I keep hearing this argument time and time again, but cannot = reconcile it with any professionally managed network. Are there really = professionally managed networks where the guys responsible for the = routers (intrinsically tied in with the network config) don't talk to = the guys running DHCP servers (intrinsically tied in with the network = config) ? >> Put another way, are there really networks where two different groups = "do their own thing" without agreeing between themselves how the network = is supposed to work ? >=20 > Put another way, "are there really professionally managed networks?=E2=80= =9D >=20 > Worth noting: the point is that the =E2=80=9CNote:=E2=80=9D in RFC = 4861 cited previously in the thread asserts that M=3D0&O=3D0 is a signal = to all hosts on the link that =E2=80=9Cno information is available via = DHCPv6,=E2=80=9D which is really only true while *all* the routers on = the link are consistently sending that signal. It stops being true as = soon as one or more of the routers on the link contradict the signal, = and it continues to not be true until all the contradicting routers = expire their valid lifetimes. On a =E2=80=9Cprofessionally managed = network,=E2=80=9D there might never be any contradicting routers on the = link at any time, and in that case the Note correctly describes how the = protocol works. In other cases, however, it remains a little less than = clear. >=20 > So, I ask again: are there really professionally managed networks? Yes. The common definition of professional is that you get paid to do a = job. How well you do it is another matter :-) To you point, I think there are networks where all of the routers are = configured correctly. Bob --Apple-Mail=_098534B7-E197-4DB3-BC1B-1DFB55E961A1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloxnv8ACgkQrut0EXfn u6gIhQgAjpqM62OLl/Q7lIeAopLA9flw3zgIq0F6/03QqYqat57GGw1Fne1bXMFx Tf66Y/lsavX/9Dbhlnobf6j30cuyNuLvlKtU5DF2SwS+QRlSHh+xYjAfNCKhjbJo BYoCrmzIUzwuuBWjPm9qIQfuu5MCFh6vkVjSCm20NAAtZv0fTsiEvT2iyHSEqcrx cmko0MpEQ0RZu636sxvnBwSDl6VKN2Rk7qCzZU2xEyWF8tXJzQswQD7YK+lA/2Wa ReNSkvOWKw8AqW2yG8W2QrbHoxdjoR/2xuSVtAF7kBEEHzccLXJME1mQiO+9Uxl3 ri8YiOaGlgBlWQPOncza+2zB8h9p2A== =MSZP -----END PGP SIGNATURE----- --Apple-Mail=_098534B7-E197-4DB3-BC1B-1DFB55E961A1-- From nobody Wed Dec 13 14:08:16 2017 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 C2EEB1205F0; Wed, 13 Dec 2017 14:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmeABsHuRs7h; Wed, 13 Dec 2017 14:08:04 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B60B126D85; Wed, 13 Dec 2017 14:08:04 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id vBDM7bdY040152; Wed, 13 Dec 2017 17:08:01 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2eubftt5bb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Dec 2017 17:08:01 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vBDM80oB022136; Wed, 13 Dec 2017 17:08:01 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vBDM7ufx022116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Dec 2017 17:07:59 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 13 Dec 2017 22:07:37 GMT Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 328BE4000341; Wed, 13 Dec 2017 22:07:37 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30484.vci.att.com (Service) with ESMTPS id 19A9C40006FB; Wed, 13 Dec 2017 22:07:37 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.227]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0361.001; Wed, 13 Dec 2017 17:07:36 -0500 From: "STARK, BARBARA H" To: Naveen Kottapalli CC: v6ops list , 6man WG Thread-Topic: Windows 10 doesn't honour 'M' flag in RA Thread-Index: AQHTcxnIMEBQ+YpiC0KlzMNBptkKMaM/UtuWgAKBR0A= Date: Wed, 13 Dec 2017 22:07:36 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.212.84] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-13_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=359 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712130304 Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 22:08:06 -0000 SGkgTmF2ZWVuIChvciBhbnlvbmUgZWxzZSB3aG8gY2FyZXMgdG8gYW5zd2VyKSwNCg0KPiBJbiBv dXIgcmVjZW50IHRlc3RpbmcsIHdlIG9ic2VydmVkIHRoYXQgV2luZG93cyAxMCBkb2Vzbid0IGhv bm91ciAnTScgZmxhZw0KPiBpbiBSQS7CoCBJdCdzIG5vdCBqdXN0IFdpbmRvd3MgMTAsIHNhbWUg YmVoYXZpb3VyIGlzIG9ic2VydmVkIHdpdGggbGF0ZXN0IE1hYw0KPiBPUyBhcyB3ZWxsLsKgIA0K DQpJJ20gY3VyaW91czogV2hhdCBpcyBiZWluZyBoYXJtZWQgYnkgdGhpcyBiZWhhdmlvcj8gSSBj YW4gZGVmaW5pdGVseSBzZWUgYWR2YW50YWdlcyBpbiBXaW5kb3dzIGFuZCBNYWMgT1MgZG9pbmcg aXQgdGhpcyB3YXk7IEknbSBqdXN0IHN0cnVnZ2xpbmcgdG8gdW5kZXJzdGFuZCB0aGUgZGlzYWR2 YW50YWdlcy4gWWVhcnMgYWdvLCB0aGVyZSB3YXMgYSBwcm9ibGVtIGluIHNvbWUgSVNQIG5ldHdv cmtzIHByaW9yIHRvIGZ1bGwgbGF1bmNoIG9mIElQdjYgYW5kIHByaW9yIHRvIHN1cHBvcnQgZm9y IFNPTF9NQVhfUlQgKFJGQyA3MDgzKSBvZiBESENQdjYgc2VydmVycyBiZWluZyBvdmVyd2hlbG1l ZCBieSBTb2xpY2l0IG1lc3NhZ2VzIHRoZXkgd2VyZSBjb25maWd1cmVkIG5vdCB0byByZXNwb25k IHRvIChiZWNhdXNlIElQdjYgd2Fzbid0IGZvcm1hbGx5IHN1cHBvcnRlZCkuIEJ1dCB3aXRoIFNP TF9NQVhfUlQsIHRoYXQgcmVhbGx5IHNob3VsZG4ndCBiZSBhbiBpc3N1ZS4gU28gd2hhdCBpcyBi ZWluZyBicm9rZW4gYnkgdGhpcyBiZWhhdmlvciBub3c/DQoNCkJhcmJhcmENCg== From nobody Wed Dec 13 15:35:41 2017 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 27D30128AA1; Wed, 13 Dec 2017 15:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlqB8omm8Y5o; Wed, 13 Dec 2017 15:35:32 -0800 (PST) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE25C1201F8; Wed, 13 Dec 2017 15:35:31 -0800 (PST) Received: from mail1.ernw.net (unknown [172.31.1.30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id BCACD27304; Thu, 14 Dec 2017 00:35:29 +0100 (CET) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 9068765D5B0; Thu, 14 Dec 2017 00:35:29 +0100 (CET) Received: by ws26.ernw.net (Postfix, from userid 1002) id 5AAA439CB5; Thu, 14 Dec 2017 00:35:29 +0100 (CET) Date: Thu, 14 Dec 2017 00:35:29 +0100 From: Enno Rey To: "STARK, BARBARA H" Cc: Naveen Kottapalli , v6ops list , 6man WG Message-ID: <20171213233529.GA55691@ernw.de> References: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Mutt/1.7.1 (2016-10-04) Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 23:35:35 -0000 Hi, On Wed, Dec 13, 2017 at 10:07:36PM +0000, STARK, BARBARA H wrote: > Hi Naveen (or anyone else who cares to answer), > > > In our recent testing, we observed that Windows 10 doesn't honour 'M' flag > > in RA.?? It's not just Windows 10, same behaviour is observed with latest Mac > > OS as well.?? > > I'm curious: What is being harmed by this behavior? I can definitely see advantages in Windows and Mac OS doing it this way; I'm just struggling to understand the disadvantages. when the router - sends RAs with "O" flag. - is configured as a DHCPv6 server handing out one or several v6 DNS server(s) [which is a very common setup of CPE devices in broadband networks] then the node sending a DHCPv6 SOLICIT (without being "advised" to do so by the "M" flag) will receive (from the DHCPv6 server not being able to serve it's request) a "NoAddrAvail" status code and will hence (in full compliance with RFC 3315 sect. 17.13) ignore the *full* DHCPv6 packet received from the server. This in turns means it will not learn the (v6) DNS server which is clearly not what is intended by that type of setup from the broadband providers. See also: https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-windows-10/ best Enno Years ago, there was a problem in some ISP networks prior to full launch of IPv6 and prior to support for SOL_MAX_RT (RFC 7083) of DHCPv6 servers being overwhelmed by Solicit messages they were configured not to respond to (because IPv6 wasn't formally supported). But with SOL_MAX_RT, that really shouldn't be an issue. So what is being broken by this behavior now? > > Barbara > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Matthias Luft, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Wed Dec 13 18:58:52 2017 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 773DF127078; Wed, 13 Dec 2017 18:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqnuMut3bi9i; Wed, 13 Dec 2017 18:58:44 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3289D124234; Wed, 13 Dec 2017 18:58:43 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 37DDE3B549D; Thu, 14 Dec 2017 02:58:41 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id CD521160041; Thu, 14 Dec 2017 02:58:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 90E59160048; Thu, 14 Dec 2017 02:58:40 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Pgwk3jNcJRV2; Thu, 14 Dec 2017 02:58:40 +0000 (UTC) Received: from jmb.localhost (unknown [73.93.155.16]) by zmx1.isc.org (Postfix) with ESMTPSA id 4F75A160041; Thu, 14 Dec 2017 02:58:40 +0000 (UTC) Date: Wed, 13 Dec 2017 18:58:39 -0800 Message-ID: From: JINMEI Tatuya / =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Naveen Kottapalli Cc: Mikael Abrahamsson , "v6ops@ietf.org" , "ipv6@ietf.org" In-Reply-To: References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 02:58:46 -0000 At Wed, 13 Dec 2017 17:41:23 +0530, Naveen Kottapalli wrote: > I got that. But am not sure on what is the use when devices don't bother > the value of that bit in RA. Effectively nothing. If you look at RFC2461 and RFC2462, you'll find behavior regarding these bits were more normative. For example, Section 5.5.3 of RFC2462 stated: [...] If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host should invoke the stateful address autoconfiguration protocol, requesting both address information and other information. (you should read "the stateless address autoconfiguration protocol" as DHCPv6). But when we tried to update these docs (the result is RFC4861 and RFC4862) we realized that it was not widely implemented and that it would be quite difficult to specify more sensible behavior that met people's varied opinions and preferences. IIRC those include: - some people wanted to be able to run DHCPv6 without bothering RA (technically, RFC2461/2462 didn't prohibit it, but there was a desire of making it clearer) - some people wanted to have a way to signal hosts not to use DHCPv6 (this is probably your interpretation. but even RFC2461/2462 didn't have a clear description of such a way). on a related matter, the meaning of zero-M/O bits wasn't clear (RFC2462 said hosts shouldn't stop DHCPv6 on the bit change from 1 to 0, but it didn't say anything about what it means if the bit is 0 from the beginning). - some people wanted to have a way to turn off running DHCPv6 (the original description of changing M from 1 to 0 didn't work that way) In retrospect, it was probably just a bad idea to try to control this just from these two bits. So there was also an idea of deprecating those bits. But some people didn't like the idea due to compatibility with existing implementations that rely on those bits. So, the current wording of RFC4861 (and the silence about these bits in RFC4862) was a kind of procedural compromise. I suspect no one can give a reasonable technical explanation to "what is the use of these bits?" or "why do we even have these bits if they are useless?". There have been attempts to give clearer semantics to these bits, but none of them has succeeded. That's an unfortunate situation, given that there are actually implementations that still refer to these bits. But, knowing the history I'm pessimistic about any further effort on these bits. My humble suggestion is to just accept the reality and use our time for something else. -- JINMEI, Tatuya From nobody Thu Dec 14 04:07:26 2017 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 9BC43126BF0; Thu, 14 Dec 2017 04:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ013V38jhJK; Thu, 14 Dec 2017 04:07:18 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02771200C5; Thu, 14 Dec 2017 04:07:17 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id u127so2309712lff.5; Thu, 14 Dec 2017 04:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xfIgRAsDB2hEeZlEVRV6MXABz5tgZ7tXU4OZEUc+2SU=; b=HZPdbYSVnW/QSqHIugMQkWVM1ipcn8n4O1m+sHzN++kQNtkKko+orwQAZQ+nv+SwYx IM1NSD3LiLsZfYYNQN7V2OFXNqcL4y3Lmw1j10HSEG+rdcE7+9bZ8Km71ELIaVMukans aw+Y3MnhXAPy0y6WVIH0YNjSaQJYcMJD2DhWcXaz8sDx8xuSR5zRV8HbDYvqGdFyOpGX SJD9EmnpsbVoTBHydU53AokO8Zw2AG22BL5+juItTOX4M8QIArTtMbgPP4o2ZjoWfkii 6O+OC0tuCEzScZng6cYT2iknsqDI4ta3uFHAX+WKc9kSp/FNs24XsatLflcRZfSMkdUm J+uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xfIgRAsDB2hEeZlEVRV6MXABz5tgZ7tXU4OZEUc+2SU=; b=Hm3M6rjml59ADsNXsB2TDvE7ut4L2Qs6+7i8J26hZc+gAdjjq7rg62LqajqNt9pefq D7EPmw3gmrtXUe9+OlUoA4Liskxgo/UbVg98vR84KTgAHewdwi/kQkYHMdUWkmCmQEM/ jXpYV3DlSaHKr1B/TrWvzEwFT0Be3cgukg0Yx4WReniVJYkUWrZ+h6C0qJoO0qKTthjJ kSqwdwdPrh/mU7TPEKM8LfNlOXQRvnwPUZjS+lidcZydg3/RgRJj2qOS0jewksInh2fQ y0GWiWwUiDaCcJ2COGwG4SEJzTrxURe3tY69WNTyVIo2Hm6XARWSijUalZrpnj4VPucD GDPQ== X-Gm-Message-State: AKGB3mICrQ39LOEXZ/y3CtaMl8KUenG/2MnQnL3v3MNXWzwFl1Mo15Vq AUCVZv/w9hcsInLyD0RCVg8Vz5nv8SQu4yqiWS4= X-Google-Smtp-Source: ACJfBoub9Jtzjeng3HtcHYheFKU1+OoTKxZdpWPdI0cKsEwFlTRGMdCmdcTrKSddwqIDeQ4sgL+VdrTAEV/XRatMHPg= X-Received: by 10.46.89.69 with SMTP id n66mr3992804ljb.26.1513253235854; Thu, 14 Dec 2017 04:07:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.2.212 with HTTP; Thu, 14 Dec 2017 04:06:55 -0800 (PST) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Naveen Kottapalli Date: Thu, 14 Dec 2017 17:36:55 +0530 Message-ID: To: "STARK, BARBARA H" Cc: v6ops list , 6man WG Content-Type: multipart/alternative; boundary="94eb2c073aec94136605604bb93b" Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 12:07:20 -0000 --94eb2c073aec94136605604bb93b Content-Type: text/plain; charset="UTF-8" No harm is seen with this behaviour. Just curious on know why the protocols are designed this way where devices doesn't honour the flags sent. Yours, Naveen. On 14 December 2017 at 03:37, STARK, BARBARA H wrote: > Hi Naveen (or anyone else who cares to answer), > > > In our recent testing, we observed that Windows 10 doesn't honour 'M' > flag > > in RA. It's not just Windows 10, same behaviour is observed with latest > Mac > > OS as well. > > I'm curious: What is being harmed by this behavior? I can definitely see > advantages in Windows and Mac OS doing it this way; I'm just struggling to > understand the disadvantages. Years ago, there was a problem in some ISP > networks prior to full launch of IPv6 and prior to support for SOL_MAX_RT > (RFC 7083) of DHCPv6 servers being overwhelmed by Solicit messages they > were configured not to respond to (because IPv6 wasn't formally supported). > But with SOL_MAX_RT, that really shouldn't be an issue. So what is being > broken by this behavior now? > > Barbara > --94eb2c073aec94136605604bb93b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No harm is seen with this behaviour.=C2=A0 Just curious on= know why the protocols are designed this way where devices doesn't hon= our the flags sent.

=
Yours,Naveen.

On 14 December 2017 at 03:37, STARK, BARBARA= H <bs7652@att.com> wrote:
Hi= Naveen (or anyone else who cares to answer),

> In our recent testing, we observed that Windows 10 doesn't honour = 'M' flag
> in RA.=C2=A0 It's not just Windows 10, same behaviour is observed = with latest Mac
> OS as well.=C2=A0

I'm curious: What is being harmed by this behavior? I can defini= tely see advantages in Windows and Mac OS doing it this way; I'm just s= truggling to understand the disadvantages. Years ago, there was a problem i= n some ISP networks prior to full launch of IPv6 and prior to support for S= OL_MAX_RT (RFC 7083) of DHCPv6 servers being overwhelmed by Solicit message= s they were configured not to respond to (because IPv6 wasn't formally = supported). But with SOL_MAX_RT, that really shouldn't be an issue. So = what is being broken by this behavior now?

Barbara

--94eb2c073aec94136605604bb93b-- From nobody Thu Dec 14 06:01:36 2017 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 19B851201F2; Thu, 14 Dec 2017 06:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0dMiZulNt89; Thu, 14 Dec 2017 06:01:28 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E851200CF; Thu, 14 Dec 2017 06:01:27 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 920EF20090; Thu, 14 Dec 2017 09:04:48 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9B3EE81D85; Thu, 14 Dec 2017 09:01:26 -0500 (EST) From: Michael Richardson To: "STARK\, BARBARA H" cc: Naveen Kottapalli , v6ops list , 6man WG In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DCD4719@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 14:01:30 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable STARK, BARBARA H wrote: >> In our recent testing, we observed that Windows 10 doesn't honour 'M' >> flag in RA.=C2=A0 It's not just Windows 10, same behaviour is observ= ed with >> latest Mac OS as well.=C2=A0 > I'm curious: What is being harmed by this behavior? I can definitely I think a concern is that for a network on which there are no legitimate DHCPv6 servers (O=3D0,M=3D0), that the operator of the router(s) sending RAs don't know if the hosts will take the configuration from the RA, or the configuration from the rogue DHCPv6 server. One might think that setting M=3D0 and filtering all RAs from "access" ports that this would protect the network. But it's not the case, you need to filter DHCPv6 as well. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloyhDYACgkQgItw+93Q 3WXxOAf/fXBfvMwh2Dr7L/lejpBhsmVpVFSUvov6TxFeMz0XlwAf1lMWRgbz5g98 amboqfbnWJhQ+oowG9iY3948owOUK63J1gr8dDBtR58se5U4YxcefnZzQwCD8Xqq BzeHwr5M54bQ6n9dcrZA+VCtkRlTmc6WBtVp5kiG9d3eqECIzwAaOtWWXE5VQeY7 3zdCzbNg8X3I3jBNxAOD7gQm3aWRULe3RHfrvjS2JNSvj7qMgCvDqtap3qnWW6ZG InVVYeqhpx0Ga0TF+pTAJWPHziP9PXUdneKu1oqFr7Xr3DzrT91LgWqmJKL1/SNm krd+TjHH+Z18GS8FOxQvMtG8nKMSeg== =+4YH -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 14 09:19:25 2017 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 3C251127871 for ; Thu, 14 Dec 2017 09:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJpoAgEz5h8D for ; Thu, 14 Dec 2017 09:19:22 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6591293DA for ; Thu, 14 Dec 2017 09:19:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vBEHJLXV045214; Thu, 14 Dec 2017 10:19:21 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vBEHJKfI045209 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Thu, 14 Dec 2017 10:19:20 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 14 Dec 2017 09:19:19 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1347.000; Thu, 14 Dec 2017 09:19:20 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org list" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdN0/pQbESM/pUHWTBC3IMugjrlkIw== Date: Thu, 14 Dec 2017 17:19:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 17:19:24 -0000 An updated version of this draft is now available that addresses comments p= osted on the v6ops list. Links to the document and diffs from the previous versio= n appear below, and the document now includes a "Changes" appendix to more easily tr= ack major changes between versions. Please review and send any new comments to the list, and please confirm whe= ther earlier comments have been addressed. Thanks - Fred -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Thursday, December 14, 2017 9:07 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-v6ops-pdhost-17.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv6 Prefix Delegation Models Author : Fred L. Templin Filename : draft-templin-v6ops-pdhost-17.txt Pages : 13 Date : 2017-12-14 Abstract: IPv6 prefixes are typically delegated to requesting routers which then use them to number their downstream-attached links and networks. This document considers prefix delegation models according to whether the requesting router acts as a router on behalf of any downstream networks, as host on behalf of its local applications or as both. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-templin-v6ops-pdhost-17 https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-17 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Dec 14 17:20:59 2017 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 510ED124239 for ; Thu, 14 Dec 2017 17:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udfAys0peR8k for ; Thu, 14 Dec 2017 17:20:56 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37CFA1200F3 for ; Thu, 14 Dec 2017 17:20:56 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id d5so6580895oti.3 for ; Thu, 14 Dec 2017 17:20:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ASLjItBxEI36vjVqQCAaDvHi/1PFJIE/zjo0onaB1Rw=; b=EQEFFvvwd5o29i4qagRnpqb6DusU1nBaT4Fqcfq/zbAc4ZiftLR7dV1QfHdF+e53zH KtkCQYecKBtq0v5g6Lv/TkU9nj5D6A8UFu/ZG/2Mdw04Aq7vLBXoZRPIi4hHpJ0Pw2BB 4d105W5YrmjLVBM5KTaF689eTbaxM2MRdfyi8BPcK2Mf19rrxb0ZqceQPYHNvpcIjTLd rTDLbwe2TuqUsVJ7sGGRXBwdvTkUk84OOfHlTxLgQSaK6dxC0frzsSOYkpFoS1T+tbnj Xoc06Hl//UDOVdq/7eWFFWt54mMdPJnxQfhuvQS0y9xJtCgqfyUSsD4WjAIExLJjVIwx CF3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ASLjItBxEI36vjVqQCAaDvHi/1PFJIE/zjo0onaB1Rw=; b=dgaE7eQOD4Fxx6jIFV+S87QumHLdaCL4TnVCq7TUxNPqJynCgu3kPRvj1HfzZTf+u+ A2jZvBpqs3KP4qAuHs9fAYk5daBD+EUGdf6jGxy6Ev6PoPq3PeifQF3dxWLaicjBlTEs kV1dt7R9odNNUaIYm3g1IWJXMnzlTGQhoJv+rtFwFuqHpQeo8EiEX8aW/TNNyG+asPd2 YILISbXJxyHUD5TDZU0VuZaBJIp90gtBXhMI+hyXl4lYrk20pxuII5Ky1emAGTz1f+nT Y60UtMhbebRoTPZvD0BM7T2+2h/7GFlj3efyXRpAUv+BSct2l77xTeGs9y+Ufaw6o1GX BXug== X-Gm-Message-State: AKGB3mI23omXHuNhWsh8i8Szjjkg0bOWyEQDz7oQV9/LaZ0/lT8HYqjM AArMKykgJrNgIr9RiUcYoMI= X-Google-Smtp-Source: ACJfBov7hC/dHZQHCSUk0Zpxo5VRQ5DdaBCcI03pgnoM5hQ8jvbzQJNz3pvTLLHhG9uv0lrSWlkpng== X-Received: by 10.157.15.186 with SMTP id d55mr7491721otd.262.1513300855613; Thu, 14 Dec 2017 17:20:55 -0800 (PST) Received: from ?IPv6:2600:8802:5600:f7a::100f? ([2600:8802:5600:f7a::100f]) by smtp.gmail.com with ESMTPSA id u32sm2597681oth.53.2017.12.14.17.20.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 17:20:54 -0800 (PST) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_3DC27690-1581-4B9F-AD06-6D53E0BF6E36"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 14 Dec 2017 17:20:51 -0800 In-Reply-To: Cc: "v6ops@ietf.org list" To: Fred Templin References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 01:20:58 -0000 --Apple-Mail=_3DC27690-1581-4B9F-AD06-6D53E0BF6E36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 14, 2017, at 9:19 AM, Templin, Fred L = wrote: > Please review and send any new comments to the list, and please = confirm whether > earlier comments have been addressed. It continue to describe the entity delegating the prefix as a = "Delegating Router 'D'". The IPAM (IP address Management, and by = extension IP Prefix Management) software can be implemented in a = computer sold as a router, but there is no requirement that it be, and = it usually is not. As a matter of fact, if a router is a system that = forwards messages directed to addresses other than its own, in the = context of an application such as a DHCPv6 address/prefix management = process, it is acting as a host, not a router. https://www.google.com/search?q=3Dipam For example, https://en.wikipedia.org/wiki/IP_address_management --Apple-Mail=_3DC27690-1581-4B9F-AD06-6D53E0BF6E36 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlozI3MACgkQEhdRnd2G P+Cp6Q/+N1TcUsB81L49Nj4Byqk6FDFipCoM3s5GszWtwzH3AG8HIZARaTSSR0bi QlEkhS9nebP8RrKZEkzPsFV5SngEQxKvifrrdzUAIrYiihdTDxHLFNFnBMPKUNV1 o7BahGcin+9i/kdvu5uqHEaYKn2H62M4H/OngtJ1bsA8hyj1AKPU3gWjzJz7I/25 StdLwvFMoFyJxCW4wxGU51pvqcyX9V3TCe3tbksloJbwzyoG8zf4nyrKy9IPqNEj U9fNYtqWUHhCuKEOSBvv6+lNALfmkg4gnzbI0a+PfeQQ1q36GY+WyJR6ZRxBZQwR SwEgdbsWHAa4zhQivbcb1EuEcDHgMUm4U6LBULWt2aX2J59dd9uhrG2LzbDv5xc/ WMzsD0sWPpjUTBXgVve+jzGR+tjzH7gYFSkozxn8MjGPfz2+r3+skib3jcYNxzwk YzE6stWsY7O3ko3ycZgZNg2Cs0yy4F4sRATLF434DVB4kSansseVh0RHnNhqPdoE zPbowkMFlXfGFIQ3SNffQ3Ejjg5tsNCpWQctcOg9taMkYsLwu9W5vljIX665Nh4r EOINggnPcEti8WtcoX0xMoUigYY/fF1yMm0rhSSr0HJAKAg4zE0/CjWMPbS4w4G/ YYKgm4t4P7gNjoh3NEMedl6yW7KjqTpM8paQvYzNvXacO9f6Y34= =IUqy -----END PGP SIGNATURE----- --Apple-Mail=_3DC27690-1581-4B9F-AD06-6D53E0BF6E36-- From nobody Fri Dec 15 05:21:57 2017 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 1F2211289B5 for ; Fri, 15 Dec 2017 05:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ9gUd4utpzI for ; Fri, 15 Dec 2017 05:21:54 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A4C127B5A for ; Fri, 15 Dec 2017 05:21:54 -0800 (PST) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id A5A7C2D5219; Fri, 15 Dec 2017 13:21:53 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8CE042012FC4C2; Fri, 15 Dec 2017 14:21:50 +0100 (CET) From: Ole Troan Message-Id: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_7C6D73B5-D8D8-4B7D-881B-DF8A81462BE0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 15 Dec 2017 14:21:49 +0100 In-Reply-To: Cc: Fred Templin , "v6ops@ietf.org list" To: Fred Baker References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 13:21:56 -0000 --Apple-Mail=_7C6D73B5-D8D8-4B7D-881B-DF8A81462BE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> Please review and send any new comments to the list, and please = confirm whether >> earlier comments have been addressed. >=20 > It continue to describe the entity delegating the prefix as a = "Delegating Router 'D'". The IPAM (IP address Management, and by = extension IP Prefix Management) software can be implemented in a = computer sold as a router, but there is no requirement that it be, and = it usually is not. As a matter of fact, if a router is a system that = forwards messages directed to addresses other than its own, in the = context of an application such as a DHCPv6 address/prefix management = process, it is acting as a host, not a router. Prefix delegation, more so than address assignment is coupled with the = routing system. Which is why RFC3633 only described a model where the delegating router = and requesting router was directly connected. Cheers, Ole --Apple-Mail=_7C6D73B5-D8D8-4B7D-881B-DF8A81462BE0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlozzG0ACgkQvtpYqJhC 33buKhAAvfWBpYe3mNlQCIcpPtWnKTXFHtgJU1crUXvWVg1IXDhataSTGK/yPGok tfIoGPuPTWeXhlqJUzjuObMSTpqnFuUWjl11HMtO6vIG/IyB2oeLxqe4O8kyITz+ 9vgkAaaKmyGAJivM1yeY68Qd89IbTT9WTNLEVkLxp4t/8LEys87+zYhbkJlYy25q vQYvrHWAUh3f7lmQJxX5VZ5RAr/cpz09OQk3QI4cyZ6OwJqBwNF0/SQeZM1jCx0F 21POmnO1KQC+RFIvsYxaVD6N+EZ5Af8qQTox7Bk1z3puWMM7I5ZSGwnuCmOfbEnT dLfhjPprZwh2T+V9Aqqm7al/U3/QXsOSsX1T/UbQumJUNWWpdBMM70txpbWKToSX qWacQTwUrW4NLiAc0gVkbBLbZIpcYptMXmwUFxCPC/aDJunKfDcCnTx+ZG+M+Eon 3cC7Qu3tcOOrJhJFv9e5/2RfUta49D9byaspsCtcacexFDC0GSgkKxEBHVIb1N3h iwW/Js5H1ce+AjX3iqJlckV7xXEKGuFs1o0LDSkcBlfHcuzK0zdd3HfJ7lEoLU8D wFuU8gNZ8F8y4Oc8dMmSD6arUgMeCERA7yeVfHp53tfv1N1hRyEDcPO3tj94kNZK gA7rU1Jrjfd5WULeKZni0njjztyFP+zwDGkDN9TR/fd1BeJd4wU= =FWvM -----END PGP SIGNATURE----- --Apple-Mail=_7C6D73B5-D8D8-4B7D-881B-DF8A81462BE0-- From nobody Fri Dec 15 07:15:16 2017 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 7F5A5124205 for ; Fri, 15 Dec 2017 07:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAEvkQGUcdNf for ; Fri, 15 Dec 2017 07:15:09 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C351200CF for ; Fri, 15 Dec 2017 07:15:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vBFFF7Ia043876; Fri, 15 Dec 2017 08:15:08 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vBFFF5Nd043811 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Dec 2017 08:15:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 15 Dec 2017 07:15:04 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1347.000; Fri, 15 Dec 2017 07:15:04 -0800 From: "Templin, Fred L" To: Fred Baker CC: "v6ops@ietf.org list" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdN0/pQbESM/pUHWTBC3IMugjrlkIwAh2vmAAAwwYIA= Date: Fri, 15 Dec 2017 15:15:04 +0000 Message-ID: <067dd11055934a3489e90a12de6d0da6@XCH15-06-08.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 15:15:15 -0000 Hi Fred, > -----Original Message----- > From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > Sent: Thursday, December 14, 2017 5:21 PM > To: Templin, Fred L > Cc: v6ops@ietf.org list > Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >=20 >=20 >=20 > On Dec 14, 2017, at 9:19 AM, Templin, Fred L = wrote: > > Please review and send any new comments to the list, and please confirm= whether > > earlier comments have been addressed. >=20 > It continue to describe the entity delegating the prefix as a "Delegating= Router 'D'". The IPAM (IP address Management, and by > extension IP Prefix Management) software can be implemented in a computer= sold as a router, but there is no requirement that it be, > and it usually is not. As a matter of fact, if a router is a system that = forwards messages directed to addresses other than its own, in the > context of an application such as a DHCPv6 address/prefix management proc= ess, it is acting as a host, not a router. The Delegating Router / Requesting Router relationship is the same as in RFC3633. If the Delegating Router does not implement the actual prefix delegation service locally, then it forwards prefix delegation requests to some other node in the operator's network that provides the service. That node need not be a router (it could be a simple server running in some VM). But, the Delegating Router is still a router. See also Section 14 of RFC3633 for discussion about DHCPv6 relay agents on Delegating Routers. Thanks - Fred > https://www.google.com/search?q=3Dipam > For example, https://en.wikipedia.org/wiki/IP_address_management From nobody Fri Dec 15 07:17:46 2017 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 41FE912922E for ; Fri, 15 Dec 2017 07:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4WTwGVKrfv3 for ; Fri, 15 Dec 2017 07:17:37 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518D7128DF2 for ; Fri, 15 Dec 2017 07:17:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vBFFHauR047714; Fri, 15 Dec 2017 08:17:36 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vBFFHVFf047663 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Dec 2017 08:17:31 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 15 Dec 2017 07:17:30 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1347.000; Fri, 15 Dec 2017 07:17:30 -0800 From: "Templin, Fred L" To: Ole Troan , Fred Baker CC: "v6ops@ietf.org list" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdN0/pQbESM/pUHWTBC3IMugjrlkIwAh2vmAABkt8oAADMukwA== Date: Fri, 15 Dec 2017 15:17:30 +0000 Message-ID: References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> In-Reply-To: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 15:17:39 -0000 > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org] > Sent: Friday, December 15, 2017 5:22 AM > To: Fred Baker > Cc: Templin, Fred L ; v6ops@ietf.org list > Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >=20 > >> Please review and send any new comments to the list, and please confir= m whether > >> earlier comments have been addressed. > > > > It continue to describe the entity delegating the prefix as a "Delegati= ng Router 'D'". The IPAM (IP address Management, and by > extension IP Prefix Management) software can be implemented in a computer= sold as a router, but there is no requirement that it be, > and it usually is not. As a matter of fact, if a router is a system that = forwards messages directed to addresses other than its own, in the > context of an application such as a DHCPv6 address/prefix management proc= ess, it is acting as a host, not a router. >=20 > Prefix delegation, more so than address assignment is coupled with the ro= uting system. > Which is why RFC3633 only described a model where the delegating router a= nd requesting router was directly connected. Correct. And, RFC3633 also correctly explains the case where the Delegating Router employs a DHCPv6 Relay Agent instead of a DHCPv6 Server. Thanks - Fred > Cheers, > Ole From nobody Fri Dec 15 11:07:40 2017 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 CB847126CC7 for ; Fri, 15 Dec 2017 11:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktLS2xCRiwH5 for ; Fri, 15 Dec 2017 11:07:36 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9FD12704A for ; Fri, 15 Dec 2017 11:07:35 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id n6so6781588pfa.4 for ; Fri, 15 Dec 2017 11:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OSkUGuu3vQCClbPplWAh+tt2viPym/GajMjB6vaAf2Q=; b=V1r+YZjH5bXKxZUIEWgnBtHeb4oNvIRQxugbVFPNbVLCtw99jQSOJaNIGwK+MA9ApS lhD5nciD9FNhuODNQUhF+BaL+ssn56Gs9o4CR8XVHir/i9LZ9iehPlbgFiJS7z3pt88V zJSWOIXanZSA3HNw/VNMHtAsWfjLKmvh1Q52nFeYDXMRenYwDSPhMnouh7LlXV9qJxiE ScqFTXxjzYpMP0gDf0l6EixHooE38jv2rV4XzlcsW8o1/F0GIb2L1jOAlu84onxgtCGx T/XKarU72tRsCEq2jTXDjqs5fChUjyGjTqKJL39PHEDe7YqvbaPYWLup/2tR6oAc/dWP 4XIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=OSkUGuu3vQCClbPplWAh+tt2viPym/GajMjB6vaAf2Q=; b=ZxwYbrJ6iOXLxT0j+Mzz4KEGi7rkn0eUfxEa0R4g01+f4xQ+lUk6XMLAEJ8tYRbb6Z HXkSzq6Wm/BGJRY62m/NAAbHZsD+cfE7QbE+Vjy0NWU3awFO48d2q59c0Fj+mLGu3LEd cCTZ3sVwDpUP9Jg7OIs3AieV53JfICu621z+s3bjrvwTWRQY+9yaOvzrl1m82eXnB4D4 xMoDHOBadFSKtu6UodTm2zivUKn6D73RiFiKQHJamfTrV6fsexxChdx9SGqF1mClxFYT PAfnXQE86lTGZ3DfH6F51kD7jEoD4XVkgPKNDtf9QY3uD7mc8dJ9qO9AhvdSeiqi/WW2 fPlQ== X-Gm-Message-State: AKGB3mISWZul+9yD/kUwBq+rP6Xokzh/lbU+fkyo+eRG2AeEqy1IWnNi TlwgBlcw3KZ6InmcYKAGiuJITw== X-Google-Smtp-Source: ACJfBosYnxEwd0OLsTyzcO3nmtvYcT8XgvUOYW0g2BqTpcfp7v9/FLSOJYRDHZCwczbBmdfcKhO5ng== X-Received: by 10.84.206.37 with SMTP id f34mr13896500ple.299.1513364854682; Fri, 15 Dec 2017 11:07:34 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a22sm15383591pfc.47.2017.12.15.11.07.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 11:07:33 -0800 (PST) To: v6ops@ietf.org References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 16 Dec 2017 08:07:41 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 19:07:39 -0000 On 16/12/2017 02:21, Ole Troan wrote: >>> Please review and send any new comments to the list, and please confirm whether >>> earlier comments have been addressed. >> >> It continue to describe the entity delegating the prefix as a "Delegating Router 'D'". The IPAM (IP address Management, and by extension IP Prefix Management) software can be implemented in a computer sold as a router, but there is no requirement that it be, and it usually is not. As a matter of fact, if a router is a system that forwards messages directed to addresses other than its own, in the context of an application such as a DHCPv6 address/prefix management process, it is acting as a host, not a router. > > Prefix delegation, more so than address assignment is coupled with the routing system. > Which is why RFC3633 only described a model where the delegating router and requesting router was directly connected. They're coupled, but it isn't logically required that the entity that gives prefix P to a device is also the upstream router that will include P in an aggregate. I agree that's a natural implementation, but it isn't the only one. IPAMs and their generalisation in CASM, and draft-ietf-anima-prefix-management, are alternatives. So I agree - it is a false assumption that the prefix delegator is a router, and that the delegation mechanism is RFC3633. As far as the draft goes, I'd like to see this qualified: "An example IPv6 PD service is the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633]. An alternative service based solely on IPv6 ND messaging has also been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]." Maybe by adding that other, non-router, mechanisms may exist, such as proprietary IPAMs, draft-ietf-anima-prefix-management and draft-sun-casm-address-pool-management-yang (expired). Brian From nobody Fri Dec 15 11:56:58 2017 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 659B0124F57 for ; Fri, 15 Dec 2017 11:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh1u9Blnr-w7 for ; Fri, 15 Dec 2017 11:56:55 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9B4124D6C for ; Fri, 15 Dec 2017 11:56:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vBFJutRI052853; Fri, 15 Dec 2017 12:56:55 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vBFJuriW052838 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Dec 2017 12:56:53 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 15 Dec 2017 11:56:52 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1347.000; Fri, 15 Dec 2017 11:56:52 -0800 From: "Templin, Fred L" To: Brian E Carpenter , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdN0/pQbESM/pUHWTBC3IMugjrlkIwA2XDjQAAGcjmA= Date: Fri, 15 Dec 2017 19:56:52 +0000 Message-ID: <526ee02aa0ca432c95561595482497cc@XCH15-06-08.nw.nos.boeing.com> References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 19:56:57 -0000 Hi Brian, OK, thanks for explaining and I think I understand. I have a picture in my = mind now that I think would satisfy everyone's concerns. I will try to get a new= draft version out with updated figures and text on Monday. Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Friday, December 15, 2017 11:08 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >=20 > On 16/12/2017 02:21, Ole Troan wrote: > >>> Please review and send any new comments to the list, and please confi= rm whether > >>> earlier comments have been addressed. > >> > >> It continue to describe the entity delegating the prefix as a "Delegat= ing Router 'D'". The IPAM (IP address Management, and by > extension IP Prefix Management) software can be implemented in a computer= sold as a router, but there is no requirement that it be, > and it usually is not. As a matter of fact, if a router is a system that = forwards messages directed to addresses other than its own, in the > context of an application such as a DHCPv6 address/prefix management proc= ess, it is acting as a host, not a router. > > > > Prefix delegation, more so than address assignment is coupled with the = routing system. > > Which is why RFC3633 only described a model where the delegating router= and requesting router was directly connected. >=20 > They're coupled, but it isn't logically required that the entity that giv= es > prefix P to a device is also the upstream router that will include P in a= n > aggregate. I agree that's a natural implementation, but it isn't the only= one. > IPAMs and their generalisation in CASM, and draft-ietf-anima-prefix-manag= ement, > are alternatives. >=20 > So I agree - it is a false assumption that the prefix delegator is > a router, and that the delegation mechanism is RFC3633. >=20 > As far as the draft goes, I'd like to see this qualified: >=20 > "An example IPv6 PD service is the Dynamic Host > Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633]. An > alternative service based solely on IPv6 ND messaging has also > been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]." >=20 > Maybe by adding that other, non-router, mechanisms may exist, > such as proprietary IPAMs, draft-ietf-anima-prefix-management > and draft-sun-casm-address-pool-management-yang (expired). >=20 > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Dec 15 12:20:34 2017 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 BFFE0124F57 for ; Fri, 15 Dec 2017 12:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmPjrc1zgSPo for ; Fri, 15 Dec 2017 12:20:30 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB15C124D6C for ; Fri, 15 Dec 2017 12:20:30 -0800 (PST) Received: from [192.168.10.119] (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 6B6532D51E8; Fri, 15 Dec 2017 20:20:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (15C114) In-Reply-To: Date: Fri, 15 Dec 2017 21:20:26 +0100 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0FF2EE3E-C839-48AC-B169-B39B5E01C95A@employees.org> References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> To: Brian E Carpenter Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 20:20:33 -0000 Brian, Sure, but we have learnt that the matter of route injection is a thorny prob= lem.=20 If you do not topologically restrict the problem, how do you solve it? Among= separate administrative domains.=20 Ole > On 15 Dec 2017, at bu20:07, Brian E Carpenter wrote: >=20 > On 16/12/2017 02:21, Ole Troan wrote: >>>> Please review and send any new comments to the list, and please confirm= whether >>>> earlier comments have been addressed. >>>=20 >>> It continue to describe the entity delegating the prefix as a "Delegatin= g Router 'D'". The IPAM (IP address Management, and by extension IP Prefix M= anagement) software can be implemented in a computer sold as a router, but t= here is no requirement that it be, and it usually is not. As a matter of fac= t, if a router is a system that forwards messages directed to addresses othe= r than its own, in the context of an application such as a DHCPv6 address/pr= efix management process, it is acting as a host, not a router. >>=20 >> Prefix delegation, more so than address assignment is coupled with the ro= uting system. >> Which is why RFC3633 only described a model where the delegating router a= nd requesting router was directly connected. >=20 > They're coupled, but it isn't logically required that the entity that give= s > prefix P to a device is also the upstream router that will include P in an= > aggregate. I agree that's a natural implementation, but it isn't the only o= ne. > IPAMs and their generalisation in CASM, and draft-ietf-anima-prefix-manage= ment, > are alternatives. >=20 > So I agree - it is a false assumption that the prefix delegator is > a router, and that the delegation mechanism is RFC3633. >=20 > As far as the draft goes, I'd like to see this qualified: >=20 > "An example IPv6 PD service is the Dynamic Host > Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633]. An > alternative service based solely on IPv6 ND messaging has also > been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]." >=20 > Maybe by adding that other, non-router, mechanisms may exist, > such as proprietary IPAMs, draft-ietf-anima-prefix-management > and draft-sun-casm-address-pool-management-yang (expired). >=20 > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Dec 15 13:07:00 2017 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 CB790129420 for ; Fri, 15 Dec 2017 13:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u39PzowQimlC for ; Fri, 15 Dec 2017 13:06:58 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C403124F57 for ; Fri, 15 Dec 2017 13:06:58 -0800 (PST) Received: from [192.168.10.119] (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id AE42D2D5241; Fri, 15 Dec 2017 21:06:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (15C114) In-Reply-To: Date: Fri, 15 Dec 2017 22:06:55 +0100 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2B878189-0B59-423E-B5CF-3A50E576F5B5@employees.org> References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> To: Brian E Carpenter Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 21:07:00 -0000 Brian, Sure, but we have learnt that the matter of route injection is a hard proble= m.=20 If you do not topologically restrict the problem, how do you solve it? Among= separate administrative domains.=20 Ole > On 15 Dec 2017, at bu20:07, Brian E Carpenter wrote: >=20 > On 16/12/2017 02:21, Ole Troan wrote: >>>> Please review and send any new comments to the list, and please confirm= whether >>>> earlier comments have been addressed. >>>=20 >>> It continue to describe the entity delegating the prefix as a "Delegatin= g Router 'D'". The IPAM (IP address Management, and by extension IP Prefix M= anagement) software can be implemented in a computer sold as a router, but t= here is no requirement that it be, and it usually is not. As a matter of fac= t, if a router is a system that forwards messages directed to addresses othe= r than its own, in the context of an application such as a DHCPv6 address/pr= efix management process, it is acting as a host, not a router. >>=20 >> Prefix delegation, more so than address assignment is coupled with the ro= uting system. >> Which is why RFC3633 only described a model where the delegating router a= nd requesting router was directly connected. >=20 > They're coupled, but it isn't logically required that the entity that give= s > prefix P to a device is also the upstream router that will include P in an= > aggregate. I agree that's a natural implementation, but it isn't the only o= ne. > IPAMs and their generalisation in CASM, and draft-ietf-anima-prefix-manage= ment, > are alternatives. >=20 > So I agree - it is a false assumption that the prefix delegator is > a router, and that the delegation mechanism is RFC3633. >=20 > As far as the draft goes, I'd like to see this qualified: >=20 > "An example IPv6 PD service is the Dynamic Host > Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633]. An > alternative service based solely on IPv6 ND messaging has also > been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]." >=20 > Maybe by adding that other, non-router, mechanisms may exist, > such as proprietary IPAMs, draft-ietf-anima-prefix-management > and draft-sun-casm-address-pool-management-yang (expired). >=20 > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Dec 15 13:08:43 2017 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 99DA7129420 for ; Fri, 15 Dec 2017 13:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VANxp77lhiNt for ; Fri, 15 Dec 2017 13:08:39 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1B4124F57 for ; Fri, 15 Dec 2017 13:08:39 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id m26so6967183pfj.11 for ; Fri, 15 Dec 2017 13:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/czGOQJ1+SPhOrJQ9SaheuDhlcHCnWP1JG9oZVenq6U=; b=lvfTbDgQibXQcDRrYz8SLt/Wz2k5KfJZU/WmxNht7DY4Zy1/t7JNAG3B8B/RUWNsbS 1eu24pLerGdum5i/x2t1/TKPWhO16fZ3xyJO4PNgOQ33ciS0MkC9RQNZE30kERZ2wFgW BnecExnchnAqunbvGG0Of3n9quF+KjPJyVFfv2tGitp186t6NPUHLNgCD852CkYyfUUF FzFIGQOKNXD7X5SZ5S3adAnVdKlMArI2H7jYeKArqc2+5K46GUdOd/YZ2jrEKYqfMxra rDKnS6pQS76oXTvf768LhkXHBV4/mpVNtnPBHfq5eQi2myu9gL/hMcSqIeyq+4/bcLn+ GHFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/czGOQJ1+SPhOrJQ9SaheuDhlcHCnWP1JG9oZVenq6U=; b=R8Bj+T763iilYqfq7AGfu+29rXS1d5HIGqJaYyf8CMaUup9x/qMSHfwrgf2datTgj0 FRSfbrf4kpM73SrqHqSegdVPPoAp8g2bRbXZsij5B8CCUQOdqWN5iXxwCoIEs/zJ616c ICzq6GCgKosWjf2gP89aTUDy6Q5mj8Go6eU6XS/Ke3MFWpQfPeakFcMHbgUBg13XtaNw gSNr/XEDaEB8v6ZiCBVDPfrt3Zip2hzBNnJ02kXhhctMbCDb/S2quqYiQ7EsOk99KGAY exzAlMjUFIzf0TlKnTBtArAznW3CxNopHPM/bcj8IBENLULTsn5briw90FVTBFDBH8GB t4qw== X-Gm-Message-State: AKGB3mKATKB8md6PWxhEf/SxveHpQEjIKHJqfv5m/CkDNLQQZoaYHJuM qDJfl9+cL+5S7JEY1tYDFNCkLg== X-Google-Smtp-Source: ACJfBou+D9lSk6VkKB+XAuiXwoCRZREG1JBkW6IOxnSDXM4DlZ27J105udCMRE3hKBzIOMBHZfsNzg== X-Received: by 10.84.131.3 with SMTP id 3mr10710242pld.200.1513372118233; Fri, 15 Dec 2017 13:08:38 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j13sm12780811pff.131.2017.12.15.13.08.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 13:08:37 -0800 (PST) To: Ole Troan Cc: v6ops@ietf.org References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> <0FF2EE3E-C839-48AC-B169-B39B5E01C95A@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <26114dec-a4a7-d96d-a925-bef0100d80cf@gmail.com> Date: Sat, 16 Dec 2017 10:08:44 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <0FF2EE3E-C839-48AC-B169-B39B5E01C95A@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 21:08:41 -0000 On 16/12/2017 09:20, Ole Troan wrote: > Brian, > > Sure, but we have learnt that the matter of route injection is a thorny problem. > If you do not topologically restrict the problem, how do you solve it? Among separate administrative domains. Agreed. It can get very tricky. I just prefer the language in the draft not to be restrictive. Brian > > Ole > >> On 15 Dec 2017, at bu20:07, Brian E Carpenter wrote: >> >> On 16/12/2017 02:21, Ole Troan wrote: >>>>> Please review and send any new comments to the list, and please confirm whether >>>>> earlier comments have been addressed. >>>> >>>> It continue to describe the entity delegating the prefix as a "Delegating Router 'D'". The IPAM (IP address Management, and by extension IP Prefix Management) software can be implemented in a computer sold as a router, but there is no requirement that it be, and it usually is not. As a matter of fact, if a router is a system that forwards messages directed to addresses other than its own, in the context of an application such as a DHCPv6 address/prefix management process, it is acting as a host, not a router. >>> >>> Prefix delegation, more so than address assignment is coupled with the routing system. >>> Which is why RFC3633 only described a model where the delegating router and requesting router was directly connected. >> >> They're coupled, but it isn't logically required that the entity that gives >> prefix P to a device is also the upstream router that will include P in an >> aggregate. I agree that's a natural implementation, but it isn't the only one. >> IPAMs and their generalisation in CASM, and draft-ietf-anima-prefix-management, >> are alternatives. >> >> So I agree - it is a false assumption that the prefix delegator is >> a router, and that the delegation mechanism is RFC3633. >> >> As far as the draft goes, I'd like to see this qualified: >> >> "An example IPv6 PD service is the Dynamic Host >> Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633]. An >> alternative service based solely on IPv6 ND messaging has also >> been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]." >> >> Maybe by adding that other, non-router, mechanisms may exist, >> such as proprietary IPAMs, draft-ietf-anima-prefix-management >> and draft-sun-casm-address-pool-management-yang (expired). >> >> Brian >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Fri Dec 15 13:21:07 2017 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 92E26127735 for ; Fri, 15 Dec 2017 13:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFhEht7yLdgK for ; Fri, 15 Dec 2017 13:21:04 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8F0124F57 for ; Fri, 15 Dec 2017 13:21:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vBFLL37q056747; Fri, 15 Dec 2017 14:21:03 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vBFLKx8d056591 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Dec 2017 14:20:59 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 15 Dec 2017 13:20:58 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1347.000; Fri, 15 Dec 2017 13:20:58 -0800 From: "Templin, Fred L" To: Brian E Carpenter , Ole Troan CC: "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdN0/pQbESM/pUHWTBC3IMugjrlkIwA6laMvAAAI0+A= Date: Fri, 15 Dec 2017 21:20:58 +0000 Message-ID: References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> <0FF2EE3E-C839-48AC-B169-B39B5E01C95A@employees.org> <26114dec-a4a7-d96d-a925-bef0100d80cf@gmail.com> In-Reply-To: <26114dec-a4a7-d96d-a925-bef0100d80cf@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 21:21:06 -0000 Hi, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Friday, December 15, 2017 1:09 PM > To: Ole Troan > Cc: v6ops@ietf.org > Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >=20 > On 16/12/2017 09:20, Ole Troan wrote: > > Brian, > > > > Sure, but we have learnt that the matter of route injection is a thorny= problem. Without question, the first-hop router has to do route injection. It also h= as to honor route lifetimes, route revocations and link-layer address changes of the requesting router. I think this latter point is one that may need some further consideration. If the requesting router's link-layer address changes, and the requesting router signals the first-hop router by sending unsolicited NAs, wouldn't it be much easier if the first-hop router were also an active participant in the prefix delegation process? Because, an off-link entity would never see the NAs. =20 > > If you do not topologically restrict the problem, how do you solve it? = Among separate administrative domains. >=20 > Agreed. It can get very tricky. I just prefer the language in the draft > not to be restrictive. I think the language can be relaxed, but I go back to the point about the first-hop router also being an active participant in the PD exchange. AFAICT, the first-hop router is the only node that can both inject the prefix and observe the on-link behavior of the requesting router. Thanks - Fred > Brian >=20 > > > > Ole > > > >> On 15 Dec 2017, at bu20:07, Brian E Carpenter wrote: > >> > >> On 16/12/2017 02:21, Ole Troan wrote: > >>>>> Please review and send any new comments to the list, and please con= firm whether > >>>>> earlier comments have been addressed. > >>>> > >>>> It continue to describe the entity delegating the prefix as a "Deleg= ating Router 'D'". The IPAM (IP address Management, and by > extension IP Prefix Management) software can be implemented in a computer= sold as a router, but there is no requirement that it be, > and it usually is not. As a matter of fact, if a router is a system that = forwards messages directed to addresses other than its own, in the > context of an application such as a DHCPv6 address/prefix management proc= ess, it is acting as a host, not a router. > >>> > >>> Prefix delegation, more so than address assignment is coupled with th= e routing system. > >>> Which is why RFC3633 only described a model where the delegating rout= er and requesting router was directly connected. > >> > >> They're coupled, but it isn't logically required that the entity that = gives > >> prefix P to a device is also the upstream router that will include P i= n an > >> aggregate. I agree that's a natural implementation, but it isn't the o= nly one. > >> IPAMs and their generalisation in CASM, and draft-ietf-anima-prefix-ma= nagement, > >> are alternatives. > >> > >> So I agree - it is a false assumption that the prefix delegator is > >> a router, and that the delegation mechanism is RFC3633. > >> > >> As far as the draft goes, I'd like to see this qualified: > >> > >> "An example IPv6 PD service is the Dynamic Host > >> Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633]. An > >> alternative service based solely on IPv6 ND messaging has also > >> been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]." > >> > >> Maybe by adding that other, non-router, mechanisms may exist, > >> such as proprietary IPAMs, draft-ietf-anima-prefix-management > >> and draft-sun-casm-address-pool-management-yang (expired). > >> > >> Brian > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Dec 15 14:38:14 2017 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 CA9F51241FC for ; Fri, 15 Dec 2017 14:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdPtiUxl4lI2 for ; Fri, 15 Dec 2017 14:38:10 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F9812009C for ; Fri, 15 Dec 2017 14:38:09 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vBFMc6ai035879 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Dec 2017 22:38:07 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local Message-ID: <5A344ECD.7070002@foobar.org> Date: Fri, 15 Dec 2017 22:38:05 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.22 (Macintosh/20171208) MIME-Version: 1.0 To: Simon Hobson CC: "v6ops@ietf.org list" References: <7c3d5bb6f4cf4df98ce53c705816242c@XCH15-06-02.nw.nos.boeing.com> <21FDCF40-8598-4CEE-9778-0E648697A9E9@fugue.com> <0B00C5CB-9806-4215-B616-D9BE51196FAD@gmail.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Windows 10 doesn't honour 'M' flag in RA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 22:38:13 -0000 Simon Hobson wrote: > I keep hearing this argument time and time again, but cannot > reconcile it with any professionally managed network. Are there > really professionally managed networks where the guys responsible for > the routers (intrinsically tied in with the network config) don't > talk to the guys running DHCP servers (intrinsically tied in with the > network config) ? by definition, no, a properly managed network will work most of the time. No doubt a small number of networks exist which are affected by this particular misconfig to the extent that ipv6 doesn't work properly, at which point it's ok to say that it's operator error and calmly declare that is isn't a protocol level issue or something that the ietf needs to get excited about. The amount of time and effort spent debating this particular misconfiguration in v6ops is rather odd, given that it isn't really an issue in the real world. Nick From nobody Fri Dec 15 15:45:09 2017 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 96451126FDC for ; Fri, 15 Dec 2017 15:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbPG_p8FHOmI for ; Fri, 15 Dec 2017 15:45:04 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA671241FC for ; Fri, 15 Dec 2017 15:45:04 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id q13so7276094uaq.8 for ; Fri, 15 Dec 2017 15:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3GLlSfXeEanDyrtrzCAh4DfZQjt7oM9H8ZTjmKnMpt0=; b=K7ZmPaM6ktGW1czrWzgvBjkORHGS/c/ZZcdWfAWqDNpz1EgX0isJX6eZb8casXuwTX e2RYO1XoIoSOa5LB79yCCh3RNCtyX4cw2B5sjZz/ywrhvBA/XfDqKmtOUi6bsIDBntKl Dd+09jh093+ZFoJJyf8dj0AbaiByZnze2qGDVjUfC0ANnTkIL2Soy5qx7mnJrJJc2Rhk qnxbV0hLvJ9od7IyUt24tWWk2Y5O7TVzawxihuMhz3OXIORt+alZC3851wCO9Qskaqk5 dyE2XNMdthxssHerAKVIuI/CXh7JI6VW5ovWgFw81409wz3f6PhtdO+G6/fktRUZSWzu vY5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3GLlSfXeEanDyrtrzCAh4DfZQjt7oM9H8ZTjmKnMpt0=; b=s+1UxouiEtGDs7o2Qxw4qli2Jxxwo6JPwDSBEW0luGg9yxKCEkqc+feXduurPjPkqo 8GcFta8UtpZ+wj1cE35OseY6I4Wqd+ztgIA2kDPE7Nw2ynrnbA5No8DLGz4vyP+AtRef xb+ARVXuxaMngVyXEpMKyLci3e4wbWoR5INUWk0uxeD3gqFFev89B1QynBMoa+viTZgW dWElW82aVnV4uKUK55/Yg3bDILbcqZ1zQ03NU+oj3nw6R6TQ+272BHZ8Svz5fCED1Ut0 xwY7bxxV4VR8JiytFyPsCfjXhQEFGSvaEvvN83Wlo4DjmebEdBDRnROK5cW4Nq7EB7Z6 qRDQ== X-Gm-Message-State: AKGB3mK2fFGx+BfB4TKGwDowXYMlv6+SMPnjWBeDzl2MK7JgPJsg5jAJ EPKourWTBc6NMrNqkQ/MhwHopOJ97oNLH4tBOuo= X-Google-Smtp-Source: ACJfBov3kmXHEgR8y+RZ+IZwK2iIIb+D/iY2/toxtP2CgqwCc/K7kVpVcO3/JTFDjv6u7BkiXKXavYa+L4zmIV9fvNg= X-Received: by 10.159.58.219 with SMTP id q27mr16389161uag.27.1513381503608; Fri, 15 Dec 2017 15:45:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.56.218 with HTTP; Fri, 15 Dec 2017 15:44:33 -0800 (PST) In-Reply-To: References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> <0FF2EE3E-C839-48AC-B169-B39B5E01C95A@employees.org> <26114dec-a4a7-d96d-a925-bef0100d80cf@gmail.com> From: Mark Smith Date: Sat, 16 Dec 2017 10:44:33 +1100 Message-ID: To: "Templin, Fred L" Cc: Brian E Carpenter , Ole Troan , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 23:45:07 -0000 Hi, On 16 December 2017 at 08:20, Templin, Fred L wrote: > Hi, > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: Friday, December 15, 2017 1:09 PM >> To: Ole Troan >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >> >> On 16/12/2017 09:20, Ole Troan wrote: >> > Brian, >> > >> > Sure, but we have learnt that the matter of route injection is a thorny problem. > > Without question, the first-hop router has to do route injection. Actually, I don't think that is true. Some other router in the network running BGP could inject the route into the routing domain, with a BGP route NEXT_HOP attribute for the route set to either a non-Link-Local address of the client host's interface, or the NEXT_HOP attribute for the route set to one of the first-hop router's addresses (likely a loopback interface address ), with that first-hop router then resolving the last hop IPv6 address/link-layer address to reach the host. (I'd be inclined to do the latter to make it easier to identify from the BGP route table NEXT_HOPs where a particular set of host with assigned prefixes are attached, and I think BGP implementations commonly consume less memory when a set of prefixes share the same NEXT_HOP address.) This "route injection" BGP router(s) would need to somehow learn of the host assigned prefixes when they're assigned to then inject the assigned host prefixes. Haven't thought enough about whether it would be worth doing this way or not. It might be operationally better or simpler to have a smaller set of routers do this type of injection on a network rather than having all first hop routers, which could, for example, number in the 1000s, do it. Regards, Mark. > It also has > to honor route lifetimes, route revocations and link-layer address changes > of the requesting router. > > I think this latter point is one that may need some further consideration. > If the requesting router's link-layer address changes, and the requesting > router signals the first-hop router by sending unsolicited NAs, wouldn't > it be much easier if the first-hop router were also an active participant > in the prefix delegation process? Because, an off-link entity would > never see the NAs. > >> > If you do not topologically restrict the problem, how do you solve it? Among separate administrative domains. >> >> Agreed. It can get very tricky. I just prefer the language in the draft >> not to be restrictive. > > I think the language can be relaxed, but I go back to the point about > the first-hop router also being an active participant in the PD exchange. > AFAICT, the first-hop router is the only node that can both inject the > prefix and observe the on-link behavior of the requesting router. > > Thanks - Fred > >> Brian >> >> > >> > Ole >> > >> >> On 15 Dec 2017, at bu20:07, Brian E Carpenter wrote: >> >> >> >> On 16/12/2017 02:21, Ole Troan wrote: >> >>>>> Please review and send any new comments to the list, and please confirm whether >> >>>>> earlier comments have been addressed. >> >>>> >> >>>> It continue to describe the entity delegating the prefix as a "Delegating Router 'D'". The IPAM (IP address Management, and by >> extension IP Prefix Management) software can be implemented in a computer sold as a router, but there is no requirement that it be, >> and it usually is not. As a matter of fact, if a router is a system that forwards messages directed to addresses other than its own, in the >> context of an application such as a DHCPv6 address/prefix management process, it is acting as a host, not a router. >> >>> >> >>> Prefix delegation, more so than address assignment is coupled with the routing system. >> >>> Which is why RFC3633 only described a model where the delegating router and requesting router was directly connected. >> >> >> >> They're coupled, but it isn't logically required that the entity that gives >> >> prefix P to a device is also the upstream router that will include P in an >> >> aggregate. I agree that's a natural implementation, but it isn't the only one. >> >> IPAMs and their generalisation in CASM, and draft-ietf-anima-prefix-management, >> >> are alternatives. >> >> >> >> So I agree - it is a false assumption that the prefix delegator is >> >> a router, and that the delegation mechanism is RFC3633. >> >> >> >> As far as the draft goes, I'd like to see this qualified: >> >> >> >> "An example IPv6 PD service is the Dynamic Host >> >> Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633]. An >> >> alternative service based solely on IPv6 ND messaging has also >> >> been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]." >> >> >> >> Maybe by adding that other, non-router, mechanisms may exist, >> >> such as proprietary IPAMs, draft-ietf-anima-prefix-management >> >> and draft-sun-casm-address-pool-management-yang (expired). >> >> >> >> Brian >> >> >> >> _______________________________________________ >> >> 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 nobody Fri Dec 15 18:38:30 2017 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 E0A2E126B71 for ; Fri, 15 Dec 2017 18:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nplX5PO94WZU for ; Fri, 15 Dec 2017 18:38:26 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37561270A3 for ; Fri, 15 Dec 2017 18:38:26 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id m26so7407819pfj.11 for ; Fri, 15 Dec 2017 18:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VkqgEO8hIA3mHuUcWTBQWw5cW+G4KCIRky45nXTAfcw=; b=OQDYKaQCQc1/fW2ZVgwDlEDn90kF0XnEM7w/HRVFa5atyzLahOWPNqFKyMyFtgJTGM qsq/bfIHfx1LIL8Zf9kmMNhrwV7Jjs9x2VfdjiWt1V+3NiRzbLUOmQMBkzU55drezBpG BwL46xhJnUHST9iwumnmLqZkzaTIfWTsSHIZgHFJnP4AJZGTjqzBxCBGjEXJH/rdOkqv AAKjr9F/KZ7RkFKC1QtRp+fk9CIRCukYP9G/CV1SyN8avEsrEge3SRyTJ9viRqsOWXrx vCdE4tajgjBAVUkDuflcRT98PmDuPAh05dJ77JZIwO+lmx9s0og3ok6Aw5NNJJKayIQJ e8EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=VkqgEO8hIA3mHuUcWTBQWw5cW+G4KCIRky45nXTAfcw=; b=efu2zeA1sPPvueXioRDnf0KIUCG2jPHHk03R7TIAgtkCtkO95ucVL2FIlJ6c8jXkm2 6kbLK680OWYbP6GUrxJfwPO9NwXlZkLolafAuOpTexPJcs2qCd3M8ruZeVycKutAoynt HHZtN3A1NZMkeJLTP53PGWIek3hUFelZFWt5JDGhPKXE1FMoypBgoOer5N7dS+r4ueY7 MS/lzaT5K+nFTRT0FLV5LJDwHbNO43AVk11oxFSObXnRW8/6HoIAh4HA0rMBD1obF17C Fa/FAkFrrxowQDtS6rIjoun6CgYKNC8kLDRIFcGvaQq5g+arbfCCtc6AqJ3YW1H+9dFG 56Sw== X-Gm-Message-State: AKGB3mKTBaU+q42yQkbToBaOY0/qH4hfOXEuWuHVk8WpLxWoZbQIKRno uK85uzVOJhPKRE10AlHaWEBwKw== X-Google-Smtp-Source: ACJfBotl/zlg6h8how8yJtS3tx8M9ZY7AlObZpxoMmDFQ4YLanE3FG80sjTPyIwWgZxuKNIIV1zhKA== X-Received: by 10.99.121.74 with SMTP id u71mr14103575pgc.251.1513391905867; Fri, 15 Dec 2017 18:38:25 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i125sm14031535pfe.151.2017.12.15.18.38.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 18:38:24 -0800 (PST) To: "Templin, Fred L" , Ole Troan Cc: "v6ops@ietf.org" References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> <0FF2EE3E-C839-48AC-B169-B39B5E01C95A@employees.org> <26114dec-a4a7-d96d-a925-bef0100d80cf@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4ffa76dc-ab7e-b683-fbeb-9ac112f8b123@gmail.com> Date: Sat, 16 Dec 2017 15:38:32 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 02:38:29 -0000 On 16/12/2017 10:20, Templin, Fred L wrote: > Hi, > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: Friday, December 15, 2017 1:09 PM >> To: Ole Troan >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >> >> On 16/12/2017 09:20, Ole Troan wrote: >>> Brian, >>> >>> Sure, but we have learnt that the matter of route injection is a thorny problem. > > Without question, the first-hop router has to do route injection. It also has > to honor route lifetimes, route revocations and link-layer address changes > of the requesting router. > > I think this latter point is one that may need some further consideration. > If the requesting router's link-layer address changes, and the requesting > router signals the first-hop router by sending unsolicited NAs, wouldn't > it be much easier if the first-hop router were also an active participant > in the prefix delegation process? Because, an off-link entity would > never see the NAs. > >>> If you do not topologically restrict the problem, how do you solve it? Among separate administrative domains. >> >> Agreed. It can get very tricky. I just prefer the language in the draft >> not to be restrictive. > > I think the language can be relaxed, but I go back to the point about > the first-hop router also being an active participant in the PD exchange. > AFAICT, the first-hop router is the only node that can both inject the > prefix and observe the on-link behavior of the requesting router. Yes, but if it observes one of its downstream routers advertising a new prefix in the IGP, it is not acting as a first hop router; it's simply a peer router. At that point the downstream device is no longer acting only as a host, the upstream device perhaps did not hand out the prefix in question, and the network may not even be hierarchical any more. I realise that's not the scenario you're mainly interested in, but it seems entirely possible. Brian > > Thanks - Fred > >> Brian >> >>> >>> Ole >>> >>>> On 15 Dec 2017, at bu20:07, Brian E Carpenter wrote: >>>> >>>> On 16/12/2017 02:21, Ole Troan wrote: >>>>>>> Please review and send any new comments to the list, and please confirm whether >>>>>>> earlier comments have been addressed. >>>>>> >>>>>> It continue to describe the entity delegating the prefix as a "Delegating Router 'D'". The IPAM (IP address Management, and by >> extension IP Prefix Management) software can be implemented in a computer sold as a router, but there is no requirement that it be, >> and it usually is not. As a matter of fact, if a router is a system that forwards messages directed to addresses other than its own, in the >> context of an application such as a DHCPv6 address/prefix management process, it is acting as a host, not a router. >>>>> >>>>> Prefix delegation, more so than address assignment is coupled with the routing system. >>>>> Which is why RFC3633 only described a model where the delegating router and requesting router was directly connected. >>>> >>>> They're coupled, but it isn't logically required that the entity that gives >>>> prefix P to a device is also the upstream router that will include P in an >>>> aggregate. I agree that's a natural implementation, but it isn't the only one. >>>> IPAMs and their generalisation in CASM, and draft-ietf-anima-prefix-management, >>>> are alternatives. >>>> >>>> So I agree - it is a false assumption that the prefix delegator is >>>> a router, and that the delegation mechanism is RFC3633. >>>> >>>> As far as the draft goes, I'd like to see this qualified: >>>> >>>> "An example IPv6 PD service is the Dynamic Host >>>> Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633]. An >>>> alternative service based solely on IPv6 ND messaging has also >>>> been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]." >>>> >>>> Maybe by adding that other, non-router, mechanisms may exist, >>>> such as proprietary IPAMs, draft-ietf-anima-prefix-management >>>> and draft-sun-casm-address-pool-management-yang (expired). >>>> >>>> Brian >>>> >>>> _______________________________________________ >>>> 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 nobody Fri Dec 15 20:50:37 2017 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 02ED612711B for ; Fri, 15 Dec 2017 20:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIbrbIHJs17W for ; Fri, 15 Dec 2017 20:50:33 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27601126C19 for ; Fri, 15 Dec 2017 20:50:33 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vBG4oVCa015689 for ; Sat, 16 Dec 2017 05:50:31 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 174E72014E8 for ; Sat, 16 Dec 2017 05:50:31 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0C7C2201173 for ; Sat, 16 Dec 2017 05:50:31 +0100 (CET) Received: from [132.166.84.1] ([132.166.84.1]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vBG4oUUl015997 for ; Sat, 16 Dec 2017 05:50:30 +0100 To: v6ops@ietf.org References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> <0FF2EE3E-C839-48AC-B169-B39B5E01C95A@employees.org> <26114dec-a4a7-d96d-a925-bef0100d80cf@gmail.com> From: Alexandre Petrescu Message-ID: <263a3201-fc29-2662-4abd-971272f33e5b@gmail.com> Date: Sat, 16 Dec 2017 05:50:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 04:50:36 -0000 Le 16/12/2017 à 00:44, Mark Smith a écrit : > Hi, > > On 16 December 2017 at 08:20, Templin, Fred L > wrote: >> Hi, >> >>> -----Original Message----- From: v6ops >>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter >>> Sent: Friday, December 15, 2017 1:09 PM To: Ole Troan >>> Cc: v6ops@ietf.org Subject: Re: [v6ops] >>> draft-templin-v6ops-pdhost a working group draft? >>> >>> On 16/12/2017 09:20, Ole Troan wrote: >>>> Brian, >>>> >>>> Sure, but we have learnt that the matter of route injection is >>>> a thorny problem. >> >> Without question, the first-hop router has to do route injection. > > Actually, I don't think that is true. Some other router in the > network running BGP could inject the route into the routing domain, > with a BGP route NEXT_HOP attribute for the route set to either a > non-Link-Local address of the client host's interface, or the > NEXT_HOP attribute for the route set to one of the first-hop router's > addresses (likely a loopback interface address ), with that first-hop > router then resolving the last hop IPv6 address/link-layer address to > reach the host. (I'd be inclined to do the latter to make it easier > to identify from the BGP route table NEXT_HOPs where a particular > set of host with assigned prefixes are attached, and I think BGP > implementations commonly consume less memory when a set of prefixes > share the same NEXT_HOP address.) > > This "route injection" BGP router(s) would need to somehow learn of > the host assigned prefixes when they're assigned to then inject the > assigned host prefixes. But then, how that 'route injection' BGP router learns these prefixes? If the 'route injection' BGP router is the DHCP Relay, then it is very easy: they are processes on the same filesystem and they can coordinate easily. (the DHCP Relay must be the first-hop router from the perspective of the pdhost). > Haven't thought enough about whether it would be worth doing this > way or not. It might be operationally better or simpler to have a > smaller set of routers do this type of injection on a network rather > than having all first hop routers, which could, for example, number > in the 1000s, do it. A question is who triggers the 'route injection' BGP router to inject: is it the Server or the Relay? If it is the Relay, then one may end up with 1000s of Relays not doing route injection, but triggering 1000 messages to the 'route injection' BGP router which in turn would inject routes. (as a side note, in a certain deployment there is no DHCP Relay, and the DHCP Server is a unique and big machine that executes also BGP and does the BGP route injection too upon prefix delegation). Alex > > Regards, Mark. > >> It also has to honor route lifetimes, route revocations and >> link-layer address changes of the requesting router. >> >> I think this latter point is one that may need some further >> consideration. If the requesting router's link-layer address >> changes, and the requesting router signals the first-hop router by >> sending unsolicited NAs, wouldn't it be much easier if the >> first-hop router were also an active participant in the prefix >> delegation process? Because, an off-link entity would never see the >> NAs. >> >>>> If you do not topologically restrict the problem, how do you >>>> solve it? Among separate administrative domains. >>> >>> Agreed. It can get very tricky. I just prefer the language in the >>> draft not to be restrictive. >> >> I think the language can be relaxed, but I go back to the point >> about the first-hop router also being an active participant in the >> PD exchange. AFAICT, the first-hop router is the only node that can >> both inject the prefix and observe the on-link behavior of the >> requesting router. >> >> Thanks - Fred >> >>> Brian >>> >>>> >>>> Ole >>>> >>>>> On 15 Dec 2017, at bu20:07, Brian E Carpenter >>>>> wrote: >>>>> >>>>> On 16/12/2017 02:21, Ole Troan wrote: >>>>>>>> Please review and send any new comments to the list, >>>>>>>> and please confirm whether earlier comments have been >>>>>>>> addressed. >>>>>>> >>>>>>> It continue to describe the entity delegating the prefix >>>>>>> as a "Delegating Router 'D'". The IPAM (IP address >>>>>>> Management, and by >>> extension IP Prefix Management) software can be implemented in a >>> computer sold as a router, but there is no requirement that it >>> be, and it usually is not. As a matter of fact, if a router is a >>> system that forwards messages directed to addresses other than >>> its own, in the context of an application such as a DHCPv6 >>> address/prefix management process, it is acting as a host, not a >>> router. >>>>>> >>>>>> Prefix delegation, more so than address assignment is >>>>>> coupled with the routing system. Which is why RFC3633 only >>>>>> described a model where the delegating router and >>>>>> requesting router was directly connected. >>>>> >>>>> They're coupled, but it isn't logically required that the >>>>> entity that gives prefix P to a device is also the upstream >>>>> router that will include P in an aggregate. I agree that's a >>>>> natural implementation, but it isn't the only one. IPAMs and >>>>> their generalisation in CASM, and >>>>> draft-ietf-anima-prefix-management, are alternatives. >>>>> >>>>> So I agree - it is a false assumption that the prefix >>>>> delegator is a router, and that the delegation mechanism is >>>>> RFC3633. >>>>> >>>>> As far as the draft goes, I'd like to see this qualified: >>>>> >>>>> "An example IPv6 PD service is the Dynamic Host Configuration >>>>> Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633]. An >>>>> alternative service based solely on IPv6 ND messaging has >>>>> also been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]." >>>>> >>>>> Maybe by adding that other, non-router, mechanisms may >>>>> exist, such as proprietary IPAMs, >>>>> draft-ietf-anima-prefix-management and >>>>> draft-sun-casm-address-pool-management-yang (expired). >>>>> >>>>> Brian >>>>> >>>>> _______________________________________________ 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 nobody Sat Dec 16 17:37:36 2017 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 09BD0127286 for ; Sat, 16 Dec 2017 17:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fC1BPqN28_0W for ; Sat, 16 Dec 2017 17:37:32 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9930812702E for ; Sat, 16 Dec 2017 17:37:32 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id d26so8579006uak.1 for ; Sat, 16 Dec 2017 17:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uy9u6VEF3jumPr9KaLMImY/tuLsLnnxuDQ/vGzKJviI=; b=e80U0KfWrjqEd7Z4Qx7FGqN+WoX5ootHFJC+1P2Lw0Q+AXjjxONBfBrDf6zWMO5tZT T+oS7PwfvhiyaPyMtq1V1DzF3C+G5d0gQEeox9MmVjuwHt0drqZqhK411SxREQH5E1OU /z8O5fJVAWp8YG7/Xwzy2ZpWm0fnFEaOvcIHIZ8II+dPXPI5Bnsxl2ZaL/k3rESfafsH JlPr5qyiW8JtH+IXC6gWxa/pXFr0YSVv13p7/3AyDr7suqMIdGT9ht9ABg1iXZH7mq3I AqCJ+tw6kDe7sCdyvmf4yW+IwfGD3EVYcKYHPRnDXY9PfoUWyoG0uAI/x2qV+m3qZG6U curQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uy9u6VEF3jumPr9KaLMImY/tuLsLnnxuDQ/vGzKJviI=; b=oxA6xAZMJl+VohPRC8vi9v6dJx+oyGCCND3SCxnAyni2wOaB7oqhGVrRLjHqn4cyFw y3wXGFgaSUjfVzDuwbXV4qevF0jglYPOp7znMH97U5BApvFF/y0HwCfYqpMW7H/idyHL eICjNvcqsm8R9JVRzO5jxDT+KaxhsyCN0Ytl7E9kPQwDaXXjxnD5mVrnt7njYxE2vbxU gunYILpt5RO8Z0xEYPAH14X8aj1PcljOUSecr5SqJtxdrTLa8OttgHlDLjw9INRnbPZ+ aZ8e/I4xzjxoqctRHugaesqI/nfYVQsKvA4mti5cclL41W7mZLDNcs/h5IJTRAMNOx7I bbGg== X-Gm-Message-State: AKGB3mIeGGj6lahA0/UyyhUy6Onu/q7Dymx9+Zb7GVV/050Gs+/L+ovm ZhbTCMShHpaXPWJe+Qje51Xmo12We3Pdj9H7Wxc= X-Google-Smtp-Source: ACJfBotXpzT2Oyue2+Sa3vZPLpt+0NuWJXNE8boIAa4aliYTvaTvLKyTjk0ptg9122M/rDqzInyzHAkfuuvatPJxbfQ= X-Received: by 10.176.91.20 with SMTP id u20mr18865375uae.182.1513474651519; Sat, 16 Dec 2017 17:37:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.56.218 with HTTP; Sat, 16 Dec 2017 17:37:01 -0800 (PST) In-Reply-To: <263a3201-fc29-2662-4abd-971272f33e5b@gmail.com> References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> <0FF2EE3E-C839-48AC-B169-B39B5E01C95A@employees.org> <26114dec-a4a7-d96d-a925-bef0100d80cf@gmail.com> <263a3201-fc29-2662-4abd-971272f33e5b@gmail.com> From: Mark Smith Date: Sun, 17 Dec 2017 12:37:01 +1100 Message-ID: To: Alexandre Petrescu Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Dec 2017 01:37:35 -0000 On 16 December 2017 at 15:50, Alexandre Petrescu wrote: > > > Le 16/12/2017 =C3=A0 00:44, Mark Smith a =C3=A9crit : >> >> Hi, >> >> On 16 December 2017 at 08:20, Templin, Fred L >> wrote: >>> >>> Hi, >>> >>>> -----Original Message----- From: v6ops >>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: >>>> Friday, December 15, 2017 1:09 PM To: Ole Troan >>>> Cc: v6ops@ietf.org Subject: Re: [v6ops] >>>> draft-templin-v6ops-pdhost a working group draft? >>>> >>>> On 16/12/2017 09:20, Ole Troan wrote: >>>>> >>>>> Brian, >>>>> >>>>> Sure, but we have learnt that the matter of route injection is >>>>> a thorny problem. >>> >>> >>> Without question, the first-hop router has to do route injection. >> >> >> Actually, I don't think that is true. Some other router in the >> network running BGP could inject the route into the routing domain, >> with a BGP route NEXT_HOP attribute for the route set to either a >> non-Link-Local address of the client host's interface, or the >> NEXT_HOP attribute for the route set to one of the first-hop router's >> addresses (likely a loopback interface address ), with that first-hop >> router then resolving the last hop IPv6 address/link-layer address to >> reach the host. (I'd be inclined to do the latter to make it easier >> to identify from the BGP route table NEXT_HOPs where a particular >> set of host with assigned prefixes are attached, and I think BGP >> implementations commonly consume less memory when a set of prefixes >> share the same NEXT_HOP address.) >> >> This "route injection" BGP router(s) would need to somehow learn of the >> host assigned prefixes when they're assigned to then inject the assigned >> host prefixes. > > > But then, how that 'route injection' BGP router learns these prefixes? > If the 'route injection' BGP router is the DHCP Relay, then it is very > easy: they are processes on the same filesystem and they can coordinate > easily. > In some unspecified way. Point I'm making is that it isn't a necessity that the first hop router is the one that injects the route. In a large network running BGP there can be value in more centralising functions such as route advertisement e.g. BGP Route Reflectors. e.g if you have centralised DHCP server infrastructure, a few BGP routers adjacent to the DHCP servers that are injecting routes would reduce the need to have each and every first hop router perform that function. > (the DHCP Relay must be the first-hop router from the perspective of the > pdhost). > >> Haven't thought enough about whether it would be worth doing this >> way or not. It might be operationally better or simpler to have a >> smaller set of routers do this type of injection on a network rather >> than having all first hop routers, which could, for example, number >> in the 1000s, do it. > > > A question is who triggers the 'route injection' BGP router to inject: > is it the Server or the Relay? If it is the Relay, then one may end up > with 1000s of Relays not doing route injection, but triggering 1000 > messages to the 'route injection' BGP router which in turn would inject > routes. > > (as a side note, in a certain deployment there is no DHCP Relay, and the > DHCP Server is a unique and big machine that executes also BGP and does > the BGP route injection too upon prefix delegation). That's a possible model, although I don't like "big machines" because the consequence of their failure as also usually big. It's finding the right balance between highly distributed and highly centralised, weighing up the trade-offs between. > > Alex > >> >> Regards, Mark. >> >>> It also has to honor route lifetimes, route revocations and >>> link-layer address changes of the requesting router. >>> >>> I think this latter point is one that may need some further >>> consideration. If the requesting router's link-layer address >>> changes, and the requesting router signals the first-hop router by >>> sending unsolicited NAs, wouldn't it be much easier if the >>> first-hop router were also an active participant in the prefix >>> delegation process? Because, an off-link entity would never see the >>> NAs. >>> >>>>> If you do not topologically restrict the problem, how do you >>>>> solve it? Among separate administrative domains. >>>> >>>> >>>> Agreed. It can get very tricky. I just prefer the language in the >>>> draft not to be restrictive. >>> >>> >>> I think the language can be relaxed, but I go back to the point >>> about the first-hop router also being an active participant in the >>> PD exchange. AFAICT, the first-hop router is the only node that can >>> both inject the prefix and observe the on-link behavior of the >>> requesting router. >>> >>> Thanks - Fred >>> >>>> Brian >>>> >>>>> >>>>> Ole >>>>> >>>>>> On 15 Dec 2017, at bu20:07, Brian E Carpenter >>>>>> wrote: >>>>>> >>>>>> On 16/12/2017 02:21, Ole Troan wrote: >>>>>>>>> >>>>>>>>> Please review and send any new comments to the list, >>>>>>>>> and please confirm whether earlier comments have been >>>>>>>>> addressed. >>>>>>>> >>>>>>>> >>>>>>>> It continue to describe the entity delegating the prefix >>>>>>>> as a "Delegating Router 'D'". The IPAM (IP address >>>>>>>> Management, and by >>>> >>>> extension IP Prefix Management) software can be implemented in a >>>> computer sold as a router, but there is no requirement that it >>>> be, and it usually is not. As a matter of fact, if a router is a >>>> system that forwards messages directed to addresses other than >>>> its own, in the context of an application such as a DHCPv6 >>>> address/prefix management process, it is acting as a host, not a >>>> router. >>>>>>> >>>>>>> >>>>>>> Prefix delegation, more so than address assignment is >>>>>>> coupled with the routing system. Which is why RFC3633 only >>>>>>> described a model where the delegating router and >>>>>>> requesting router was directly connected. >>>>>> >>>>>> >>>>>> They're coupled, but it isn't logically required that the >>>>>> entity that gives prefix P to a device is also the upstream >>>>>> router that will include P in an aggregate. I agree that's a >>>>>> natural implementation, but it isn't the only one. IPAMs and >>>>>> their generalisation in CASM, and >>>>>> draft-ietf-anima-prefix-management, are alternatives. >>>>>> >>>>>> So I agree - it is a false assumption that the prefix >>>>>> delegator is a router, and that the delegation mechanism is >>>>>> RFC3633. >>>>>> >>>>>> As far as the draft goes, I'd like to see this qualified: >>>>>> >>>>>> "An example IPv6 PD service is the Dynamic Host Configuration >>>>>> Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633]. An alternative servi= ce >>>>>> based solely on IPv6 ND messaging has >>>>>> also been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]." >>>>>> >>>>>> Maybe by adding that other, non-router, mechanisms may >>>>>> exist, such as proprietary IPAMs, >>>>>> draft-ietf-anima-prefix-management and >>>>>> draft-sun-casm-address-pool-management-yang (expired). >>>>>> >>>>>> Brian >>>>>> >>>>>> _______________________________________________ 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 >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Dec 17 02:20:45 2017 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 6199A124B09 for ; Sun, 17 Dec 2017 02:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_nU64TJkWq8 for ; Sun, 17 Dec 2017 02:20:38 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0DF12025C for ; Sun, 17 Dec 2017 02:20:37 -0800 (PST) Received: from [192.168.10.119] (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id E4B652D511D; Sun, 17 Dec 2017 10:20:36 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (15C114) In-Reply-To: Date: Sun, 17 Dec 2017 11:20:33 +0100 Cc: Alexandre Petrescu , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> <0FF2EE3E-C839-48AC-B169-B39B5E01C95A@employees.org> <26114dec-a4a7-d96d-a925-bef0100d80cf@gmail.com> <263a3201-fc29-2662-4abd-971272f33e5b@gmail.com> To: Mark Smith Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Dec 2017 10:20:40 -0000 Mark, > On 17 Dec 2017, at 02:37, Mark Smith wrote: >=20 > On 16 December 2017 at 15:50, Alexandre Petrescu > wrote: >>=20 >>=20 >>> Le 16/12/2017 =C3=A0 00:44, Mark Smith a =C3=A9crit : >>>=20 >>> Hi, >>>=20 >>> On 16 December 2017 at 08:20, Templin, Fred L >>> wrote: >>>>=20 >>>> Hi, >>>>=20 >>>>> -----Original Message----- From: v6ops >>>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: >>>>> Friday, December 15, 2017 1:09 PM To: Ole Troan >>>>> Cc: v6ops@ietf.org Subject: Re: [v6ops] >>>>> draft-templin-v6ops-pdhost a working group draft? >>>>>=20 >>>>>> On 16/12/2017 09:20, Ole Troan wrote: >>>>>>=20 >>>>>> Brian, >>>>>>=20 >>>>>> Sure, but we have learnt that the matter of route injection is >>>>>> a thorny problem. >>>>=20 >>>>=20 >>>> Without question, the first-hop router has to do route injection. >>>=20 >>>=20 >>> Actually, I don't think that is true. Some other router in the >>> network running BGP could inject the route into the routing domain, >>> with a BGP route NEXT_HOP attribute for the route set to either a >>> non-Link-Local address of the client host's interface, or the >>> NEXT_HOP attribute for the route set to one of the first-hop router's >>> addresses (likely a loopback interface address ), with that first-hop >>> router then resolving the last hop IPv6 address/link-layer address to >>> reach the host. (I'd be inclined to do the latter to make it easier >>> to identify from the BGP route table NEXT_HOPs where a particular >>> set of host with assigned prefixes are attached, and I think BGP >>> implementations commonly consume less memory when a set of prefixes >>> share the same NEXT_HOP address.) >>>=20 >>> This "route injection" BGP router(s) would need to somehow learn of the >>> host assigned prefixes when they're assigned to then inject the assigned= >>> host prefixes. >>=20 >>=20 >> But then, how that 'route injection' BGP router learns these prefixes? >> If the 'route injection' BGP router is the DHCP Relay, then it is very >> easy: they are processes on the same filesystem and they can coordinate >> easily. >>=20 >=20 > In some unspecified way. Point I'm making is that it isn't a necessity > that the first hop router is the one that injects the route. In a > large network running BGP there can be value in more centralising > functions such as route advertisement e.g. BGP Route Reflectors. >=20 > e.g if you have centralised DHCP server infrastructure, a few BGP > routers adjacent to the DHCP servers that are injecting routes would > reduce the need to have each and every first hop router perform that > function. If hand waving is all that=E2=80=99s required, sure. :-) - how do you =E2=80=9Cknow=E2=80=9D the next-hop address of first-hop or las= t-hop? - how do you program the fib of the first-hop router? Sure, you can do that with some out-of-band mechanism, but you=E2=80=99re st= ill only hand waving.=20 Cheers=20 Ole >=20 >> (the DHCP Relay must be the first-hop router from the perspective of the >> pdhost). >>=20 >>> Haven't thought enough about whether it would be worth doing this >>> way or not. It might be operationally better or simpler to have a >>> smaller set of routers do this type of injection on a network rather >>> than having all first hop routers, which could, for example, number >>> in the 1000s, do it. >>=20 >>=20 >> A question is who triggers the 'route injection' BGP router to inject: >> is it the Server or the Relay? If it is the Relay, then one may end up >> with 1000s of Relays not doing route injection, but triggering 1000 >> messages to the 'route injection' BGP router which in turn would inject >> routes. >>=20 >> (as a side note, in a certain deployment there is no DHCP Relay, and the >> DHCP Server is a unique and big machine that executes also BGP and does >> the BGP route injection too upon prefix delegation). >=20 > That's a possible model, although I don't like "big machines" because > the consequence of their failure as also usually big. >=20 > It's finding the right balance between highly distributed and highly > centralised, weighing up the trade-offs between. >=20 >=20 >>=20 >> Alex >>=20 >>>=20 >>> Regards, Mark. >>>=20 >>>> It also has to honor route lifetimes, route revocations and >>>> link-layer address changes of the requesting router. >>>>=20 >>>> I think this latter point is one that may need some further >>>> consideration. If the requesting router's link-layer address >>>> changes, and the requesting router signals the first-hop router by >>>> sending unsolicited NAs, wouldn't it be much easier if the >>>> first-hop router were also an active participant in the prefix >>>> delegation process? Because, an off-link entity would never see the >>>> NAs. >>>>=20 >>>>>> If you do not topologically restrict the problem, how do you >>>>>> solve it? Among separate administrative domains. >>>>>=20 >>>>>=20 >>>>> Agreed. It can get very tricky. I just prefer the language in the >>>>> draft not to be restrictive. >>>>=20 >>>>=20 >>>> I think the language can be relaxed, but I go back to the point >>>> about the first-hop router also being an active participant in the >>>> PD exchange. AFAICT, the first-hop router is the only node that can >>>> both inject the prefix and observe the on-link behavior of the >>>> requesting router. >>>>=20 >>>> Thanks - Fred >>>>=20 >>>>> Brian >>>>>=20 >>>>>>=20 >>>>>> Ole >>>>>>=20 >>>>>>> On 15 Dec 2017, at bu20:07, Brian E Carpenter >>>>>>> wrote: >>>>>>>=20 >>>>>>> On 16/12/2017 02:21, Ole Troan wrote: >>>>>>>>>>=20 >>>>>>>>>> Please review and send any new comments to the list, >>>>>>>>>> and please confirm whether earlier comments have been >>>>>>>>>> addressed. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> It continue to describe the entity delegating the prefix >>>>>>>>> as a "Delegating Router 'D'". The IPAM (IP address >>>>>>>>> Management, and by >>>>>=20 >>>>> extension IP Prefix Management) software can be implemented in a >>>>> computer sold as a router, but there is no requirement that it >>>>> be, and it usually is not. As a matter of fact, if a router is a >>>>> system that forwards messages directed to addresses other than >>>>> its own, in the context of an application such as a DHCPv6 >>>>> address/prefix management process, it is acting as a host, not a >>>>> router. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Prefix delegation, more so than address assignment is >>>>>>>> coupled with the routing system. Which is why RFC3633 only >>>>>>>> described a model where the delegating router and >>>>>>>> requesting router was directly connected. >>>>>>>=20 >>>>>>>=20 >>>>>>> They're coupled, but it isn't logically required that the >>>>>>> entity that gives prefix P to a device is also the upstream >>>>>>> router that will include P in an aggregate. I agree that's a >>>>>>> natural implementation, but it isn't the only one. IPAMs and >>>>>>> their generalisation in CASM, and >>>>>>> draft-ietf-anima-prefix-management, are alternatives. >>>>>>>=20 >>>>>>> So I agree - it is a false assumption that the prefix >>>>>>> delegator is a router, and that the delegation mechanism is >>>>>>> RFC3633. >>>>>>>=20 >>>>>>> As far as the draft goes, I'd like to see this qualified: >>>>>>>=20 >>>>>>> "An example IPv6 PD service is the Dynamic Host Configuration >>>>>>> Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633]. An alternative servi= ce >>>>>>> based solely on IPv6 ND messaging has >>>>>>> also been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]." >>>>>>>=20 >>>>>>> Maybe by adding that other, non-router, mechanisms may >>>>>>> exist, such as proprietary IPAMs, >>>>>>> draft-ietf-anima-prefix-management and >>>>>>> draft-sun-casm-address-pool-management-yang (expired). >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> _______________________________________________ v6ops mailing >>>>>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ v6ops mailing >>>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ v6ops mailing list >>>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>=20 >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Dec 18 11:28:36 2017 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 DD067120454 for ; Mon, 18 Dec 2017 11:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.026 X-Spam-Level: * X-Spam-Status: No, score=1.026 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.626, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFVgqmhM9Ne5 for ; Mon, 18 Dec 2017 11:28:33 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A9112D860 for ; Mon, 18 Dec 2017 11:28:33 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id l36so11442355uae.4 for ; Mon, 18 Dec 2017 11:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=T3Kc5b1X6rpLgu0ra9htRT/wKpFpEUAL3CP8FDvC69I=; b=QeclbUermoQurFTdTgrSfqErsB6VvHFbU5masQ7Ab1mexzuIbrVOLjX0EqVUW0zA/k YUskFT8RXnN+Zq4i8arXjGpMPr6W5nGULsuPv8MvW/IwQ+3ba5cJEioypeMRbKIftllk egHrMkVTjQAx10S9pHoIZiZCyVxJ85YLChvuMTu1yMOPizHw0/N1atFcPv/iy4lyiIhD Bl/hqYE8tLeavKEQJcx2Qt+81wDvxOxK7stLyv2bS+QClexfl6lwbu6fG2oHIphxG3en i6qA074VwPR7Doi+Jb+1gytyc/HO9755HwQj/1O2c32r+9fl6lHLdu9OJE7D8g2/fKZH Wh2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=T3Kc5b1X6rpLgu0ra9htRT/wKpFpEUAL3CP8FDvC69I=; b=Z+QmwW80NL3D/RglQyZaAZld8aE65RwdObL8SzRV/48rw1mYHLqlySGUST2brhyDZk ikGEijjYez0pf2InodApAcqUAG4TUS1KR8DSp4vcp4J+bfiVx4buLiLU+klXdDN0vIu1 6RjD9OzipLgKkCAB6OPbE0rmUiQKj7g1VNNeOnSkJQSTgw87HkSeqvD+2TwDzJacl1xA XQbIntiHN7OhfwpxGLawnvEQXlxGBdzK5tXL3lo6zrDdAGgpGSzBshvnIEb3dVDUMo60 QrnIIWOMp+X9BXT+/Em9EcAhYf0rXfcdcmPgf9RJxSMSZj2Hk25ciC4m/8jPkGlFj6sY qULg== X-Gm-Message-State: AKGB3mID5l2EHzB8/Cq52z658btUtClBL5yoJxSurl3gyG67iwi7qKL8 zi6WaR1izm3GnCHoMAouE3joRpJ/P4cQ9cvD0RI= X-Google-Smtp-Source: ACJfBouhgatVrRwJzMjZh6tEXVX2YYyxQfiYx8cQbqgb+efNg8nhXX3k24KLj34r+5IeXMMnrxENZIgcwd97cEyTIxc= X-Received: by 10.176.78.17 with SMTP id g17mr882215uah.169.1513625312044; Mon, 18 Dec 2017 11:28:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.56.218 with HTTP; Mon, 18 Dec 2017 11:28:01 -0800 (PST) In-Reply-To: References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> <0FF2EE3E-C839-48AC-B169-B39B5E01C95A@employees.org> <26114dec-a4a7-d96d-a925-bef0100d80cf@gmail.com> <263a3201-fc29-2662-4abd-971272f33e5b@gmail.com> From: Mark Smith Date: Tue, 19 Dec 2017 06:28:01 +1100 Message-ID: To: Ole Troan Cc: Alexandre Petrescu , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 19:28:35 -0000 Hi Ole, On 17 December 2017 at 21:20, Ole Troan wrote: > Mark, > >>>> This "route injection" BGP router(s) would need to somehow learn of th= e >>>> host assigned prefixes when they're assigned to then inject the assign= ed >>>> host prefixes. >>> >>> >>> But then, how that 'route injection' BGP router learns these prefixes? >>> If the 'route injection' BGP router is the DHCP Relay, then it is very >>> easy: they are processes on the same filesystem and they can coordinate >>> easily. >>> >> >> In some unspecified way. Point I'm making is that it isn't a necessity >> that the first hop router is the one that injects the route. In a >> large network running BGP there can be value in more centralising >> functions such as route advertisement e.g. BGP Route Reflectors. >> >> e.g if you have centralised DHCP server infrastructure, a few BGP >> routers adjacent to the DHCP servers that are injecting routes would >> reduce the need to have each and every first hop router perform that >> function. > > If hand waving is all that=E2=80=99s required, sure. :-) > - how do you =E2=80=9Cknow=E2=80=9D the next-hop address of first-hop or = last-hop? If DHCPv6 is being used with the first hop router as a Relay, then the Relay address could be used as the BGP NEXT_HOP address. Similarly, if RADIUS accounting records assignment of prefixes to hosts, then the RADIUS NAS address could be used as the BGP NEXT_HOP address for the prefix. If the assignment of prefixes is entirely local to the first hop router, with no involvement of or reporting to an external service, then it would be necessary for that first hop router to announce the host prefix. However, in that case there would likely be a pool of prefixes to assign to hosts, known to be assigned to a particular first hop router, so BGP could be used to inject that route somewhere other than at the first hop router. > - how do you program the fib of the first-hop router? In most cases I would expect the first hop router to put the host assigned prefix in its own FIB, as it was involved in assigning it. However, if the first hop link has a GUA or ULA prefix, and the host's address on that link is known externally, as well as the assigned prefix via RADIUS, then BGP could also be used to program the first hop router's FIB - the prefix would be injected with the BGP NEXT_HOP set to the individual hosts' first hop link GUA or ULA address. Some of these examples are convoluted and unlikely to be used. Others could be useful depending on goals or network architecture. I commented really just to show that an absolute statement that the first hop router must announce the host assigned prefix(es) into the routing domain isn't necessarily correct if BGP is being used. Regards, Mark. > > Sure, you can do that with some out-of-band mechanism, but you=E2=80=99re= still only hand waving. > > Cheers > Ole > > >> >>> (the DHCP Relay must be the first-hop router from the perspective of th= e >>> pdhost). >>> >>>> Haven't thought enough about whether it would be worth doing this >>>> way or not. It might be operationally better or simpler to have a >>>> smaller set of routers do this type of injection on a network rather >>>> than having all first hop routers, which could, for example, number >>>> in the 1000s, do it. >>> >>> >>> A question is who triggers the 'route injection' BGP router to inject: >>> is it the Server or the Relay? If it is the Relay, then one may end up >>> with 1000s of Relays not doing route injection, but triggering 1000 >>> messages to the 'route injection' BGP router which in turn would inject >>> routes. >>> >>> (as a side note, in a certain deployment there is no DHCP Relay, and th= e >>> DHCP Server is a unique and big machine that executes also BGP and does >>> the BGP route injection too upon prefix delegation). >> >> That's a possible model, although I don't like "big machines" because >> the consequence of their failure as also usually big. >> >> It's finding the right balance between highly distributed and highly >> centralised, weighing up the trade-offs between. >> >> >>> >>> Alex >>> >>>> >>>> Regards, Mark. >>>> >>>>> It also has to honor route lifetimes, route revocations and >>>>> link-layer address changes of the requesting router. >>>>> >>>>> I think this latter point is one that may need some further >>>>> consideration. If the requesting router's link-layer address >>>>> changes, and the requesting router signals the first-hop router by >>>>> sending unsolicited NAs, wouldn't it be much easier if the >>>>> first-hop router were also an active participant in the prefix >>>>> delegation process? Because, an off-link entity would never see the >>>>> NAs. >>>>> >>>>>>> If you do not topologically restrict the problem, how do you >>>>>>> solve it? Among separate administrative domains. >>>>>> >>>>>> >>>>>> Agreed. It can get very tricky. I just prefer the language in the >>>>>> draft not to be restrictive. >>>>> >>>>> >>>>> I think the language can be relaxed, but I go back to the point >>>>> about the first-hop router also being an active participant in the >>>>> PD exchange. AFAICT, the first-hop router is the only node that can >>>>> both inject the prefix and observe the on-link behavior of the >>>>> requesting router. >>>>> >>>>> Thanks - Fred >>>>> >>>>>> Brian >>>>>> >>>>>>> >>>>>>> Ole >>>>>>> >>>>>>>> On 15 Dec 2017, at bu20:07, Brian E Carpenter >>>>>>>> wrote: >>>>>>>> >>>>>>>> On 16/12/2017 02:21, Ole Troan wrote: >>>>>>>>>>> >>>>>>>>>>> Please review and send any new comments to the list, >>>>>>>>>>> and please confirm whether earlier comments have been >>>>>>>>>>> addressed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It continue to describe the entity delegating the prefix >>>>>>>>>> as a "Delegating Router 'D'". The IPAM (IP address >>>>>>>>>> Management, and by >>>>>> >>>>>> extension IP Prefix Management) software can be implemented in a >>>>>> computer sold as a router, but there is no requirement that it >>>>>> be, and it usually is not. As a matter of fact, if a router is a >>>>>> system that forwards messages directed to addresses other than >>>>>> its own, in the context of an application such as a DHCPv6 >>>>>> address/prefix management process, it is acting as a host, not a >>>>>> router. >>>>>>>>> >>>>>>>>> >>>>>>>>> Prefix delegation, more so than address assignment is >>>>>>>>> coupled with the routing system. Which is why RFC3633 only >>>>>>>>> described a model where the delegating router and >>>>>>>>> requesting router was directly connected. >>>>>>>> >>>>>>>> >>>>>>>> They're coupled, but it isn't logically required that the >>>>>>>> entity that gives prefix P to a device is also the upstream >>>>>>>> router that will include P in an aggregate. I agree that's a >>>>>>>> natural implementation, but it isn't the only one. IPAMs and >>>>>>>> their generalisation in CASM, and >>>>>>>> draft-ietf-anima-prefix-management, are alternatives. >>>>>>>> >>>>>>>> So I agree - it is a false assumption that the prefix >>>>>>>> delegator is a router, and that the delegation mechanism is >>>>>>>> RFC3633. >>>>>>>> >>>>>>>> As far as the draft goes, I'd like to see this qualified: >>>>>>>> >>>>>>>> "An example IPv6 PD service is the Dynamic Host Configuration >>>>>>>> Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633]. An alternative ser= vice >>>>>>>> based solely on IPv6 ND messaging has >>>>>>>> also been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]." >>>>>>>> >>>>>>>> Maybe by adding that other, non-router, mechanisms may >>>>>>>> exist, such as proprietary IPAMs, >>>>>>>> draft-ietf-anima-prefix-management and >>>>>>>> draft-sun-casm-address-pool-management-yang (expired). >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> _______________________________________________ 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 >>>> >>> >>> _______________________________________________ >>> 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 nobody Mon Dec 18 12:04:42 2017 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 371D112422F for ; Mon, 18 Dec 2017 12:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c10qkr1ZuLqV for ; Mon, 18 Dec 2017 12:04:38 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F88124319 for ; Mon, 18 Dec 2017 12:04:38 -0800 (PST) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 60C262D508B; Mon, 18 Dec 2017 20:04:35 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8DACD2013504DC; Mon, 18 Dec 2017 21:04:32 +0100 (CET) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_2CF992FE-3178-42EE-953F-2817D512E6E2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 18 Dec 2017 21:04:31 +0100 In-Reply-To: Cc: Alexandre Petrescu , v6ops list To: Mark Smith References: <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> <0FF2EE3E-C839-48AC-B169-B39B5E01C95A@employees.org> <26114dec-a4a7-d96d-a925-bef0100d80cf@gmail.com> <263a3201-fc29-2662-4abd-971272f33e5b@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 20:04:40 -0000 --Apple-Mail=_2CF992FE-3178-42EE-953F-2817D512E6E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mark, >>>>> This "route injection" BGP router(s) would need to somehow learn = of the >>>>> host assigned prefixes when they're assigned to then inject the = assigned >>>>> host prefixes. >>>>=20 >>>>=20 >>>> But then, how that 'route injection' BGP router learns these = prefixes? >>>> If the 'route injection' BGP router is the DHCP Relay, then it is = very >>>> easy: they are processes on the same filesystem and they can = coordinate >>>> easily. >>>>=20 >>>=20 >>> In some unspecified way. Point I'm making is that it isn't a = necessity >>> that the first hop router is the one that injects the route. In a >>> large network running BGP there can be value in more centralising >>> functions such as route advertisement e.g. BGP Route Reflectors. >>>=20 >>> e.g if you have centralised DHCP server infrastructure, a few BGP >>> routers adjacent to the DHCP servers that are injecting routes would >>> reduce the need to have each and every first hop router perform that >>> function. >>=20 >> If hand waving is all that=E2=80=99s required, sure. :-) >> - how do you =E2=80=9Cknow=E2=80=9D the next-hop address of first-hop = or last-hop? >=20 > If DHCPv6 is being used with the first hop router as a Relay, then the > Relay address could be used as the BGP NEXT_HOP address. Similarly, if > RADIUS accounting records assignment of prefixes to hosts, then the > RADIUS NAS address could be used as the BGP NEXT_HOP address for the > prefix. >=20 > If the assignment of prefixes is entirely local to the first hop > router, with no involvement of or reporting to an external service, > then it would be necessary for that first hop router to announce the > host prefix. However, in that case there would likely be a pool of > prefixes to assign to hosts, known to be assigned to a particular > first hop router, so BGP could be used to inject that route somewhere > other than at the first hop router. >=20 >> - how do you program the fib of the first-hop router? >=20 > In most cases I would expect the first hop router to put the host > assigned prefix in its own FIB, as it was involved in assigning it. >=20 > However, if the first hop link has a GUA or ULA prefix, and the host's > address on that link is known externally, as well as the assigned > prefix via RADIUS, then BGP could also be used to program the first > hop router's FIB - the prefix would be injected with the BGP NEXT_HOP > set to the individual hosts' first hop link GUA or ULA address. >=20 > Some of these examples are convoluted and unlikely to be used. Others > could be useful depending on goals or network architecture. I > commented really just to show that an absolute statement that the > first hop router must announce the host assigned prefix(es) into the > routing domain isn't necessarily correct if BGP is being used. sure, it is possible to imagine solutions where BGP 3rd party next-hop = is useful. but BGP 3rd party next-hop in itself is far from a complete solution, = and as you suggest above it is hard to avoid involvement from the = first-hop router. which was my point in replying to Fred, you cannot just treat PD as a = IPAM solution, at least not unless you are prepared to pull the = "orchestrate/SDN" handwave... ;-) Cheers, Ole --Apple-Mail=_2CF992FE-3178-42EE-953F-2817D512E6E2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlo4H08ACgkQvtpYqJhC 33bO+xAAlDxDJvMEFJCrJVp0CY02BtRcYAVVXszqeeonpzfflGpuxemeKR9lsqE9 UhQC+aZTdL+ISMMEJzs1oA9wYUtybW/RABsKTP0EhsKJm+AGkmBfqZgpL/08v+mP VSf6bhEgC3PFGuEHEt0DjtDpUAZEEvxwvHqJRF5iD3Z24gRUVOmHfSGIEQfKoFja t39G/fNF0VeiQqfhfqaza4u45HkgAH7/i9kno7jIO//4A094AaHc0LxGIBCI1/Yn Mvc7e3WsJwu0Syuk9UCjF7Yt+UrGXnEyQzhW0M6Zu8Re39oP9Q//9biz8zuqlFCz y+AwjNbFEQR3saWduiBLIptpEornGKCC9dOh7k81KM3wQtpA3vYWkF/BkFX5HUxu /SWON+gOsKDmcp6nybnbT8SrzbdbVArzGtlBK3wG9hZf3YEnejjflem7EQ+s5oID iRjf+ue95HxX9ERb8gYeDemj7LAYDAG/NLcsj9A1Ea63DytVjVZF7fKkAqiZBzfZ xdb5PzqA7yhDz2Md0TZ0SVwTQs2no8ToV0wjDDZiPqTX/G7mgxwCSFT/LXKe8rDY aWTTOMHI/TqUHKi/Ca9xYH5lADD182XsML0o2egPVbzei6K/EhSRtI/ituZDbKgr 6LZRjKRXZ965Be3B0M6M6LzhA4jx7jmqLpY0jK1tlRGfljzZeio= =Q/MW -----END PGP SIGNATURE----- --Apple-Mail=_2CF992FE-3178-42EE-953F-2817D512E6E2-- From nobody Tue Dec 19 15:07:31 2017 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 9E4F712D885 for ; Tue, 19 Dec 2017 15:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkNAiBQM2WKj for ; Tue, 19 Dec 2017 15:07:19 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6CA12D943 for ; Tue, 19 Dec 2017 15:07:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vBJN7ISf016749; Tue, 19 Dec 2017 16:07:18 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vBJN7Gid016730 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Tue, 19 Dec 2017 16:07:16 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 15:07:15 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1347.000; Tue, 19 Dec 2017 15:07:15 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdN5HTyrRmwjS1ZdShWOMaQopwcupA== Date: Tue, 19 Dec 2017 23:07:15 +0000 Message-ID: <172cd17ae54a4adba58ffcdfb522fac5@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 23:07:25 -0000 See below for a new draft version that attempts to address the latest serie= s of list comments. Most of the changes are in Section 1 and address the comments ask= ing for more flexible text. However, now the only example Prefix Delegation ser= vice cited is DHCPv6 PD. That seems to be the only common example cited by all o= ther works that concern prefix delegation, plus it is widely deployed and works = great.=20 Comments? Fred -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Tuesday, December 19, 2017 2:56 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-v6ops-pdhost-18.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv6 Prefix Delegation Models Author : Fred L. Templin Filename : draft-templin-v6ops-pdhost-18.txt Pages : 13 Date : 2017-12-19 Abstract: IPv6 prefixes are typically delegated to requesting routers which assign them to their downstream-attached links and networks. This document considers prefix delegation models according to whether the requesting router acts as a router on behalf of any downstream networks, as a host on behalf of its local applications or as both. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-templin-v6ops-pdhost-18 https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-18 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Dec 19 15:42:13 2017 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 40E5C12D72F for ; Tue, 19 Dec 2017 15:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0rW8dYz4E9Y for ; Tue, 19 Dec 2017 15:42:09 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1664124BAC for ; Tue, 19 Dec 2017 15:42:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vBJNg8lb031200; Tue, 19 Dec 2017 16:42:08 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vBJNg2Gr031184 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Tue, 19 Dec 2017 16:42:02 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 19 Dec 2017 15:42:01 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1347.000; Tue, 19 Dec 2017 15:42:02 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: GRASP Thread-Index: AdN5IhZ/InAT2FQPSLSGequLh0yxXQ== Date: Tue, 19 Dec 2017 23:42:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 23:42:11 -0000 Brian - what is this GRASP thing: https://www.ietf.org/id/draft-ietf-anima-grasp-15.txt First of all, it looks like a protocol specification but it is coming from = an operations WG which seems odd to me. How is it that anima can exist as an OPS group and produce standards-track specifications? Second, it looks like it wants to be a link-local discovery protocol that c= an replace existing discovery protocols like DHCPv6, IPv6 ND, etc. Is that the intention - to replace well established protocols with something new? Thanks - Fred From nobody Tue Dec 19 16:02:47 2017 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 8E0D7126B7F for ; Tue, 19 Dec 2017 16:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-6Ghl39GWPM for ; Tue, 19 Dec 2017 16:02:45 -0800 (PST) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4761C124D6C for ; Tue, 19 Dec 2017 16:02:45 -0800 (PST) Received: by mail-pl0-x232.google.com with SMTP id bi12so7961593plb.6 for ; Tue, 19 Dec 2017 16:02:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GIX1stpvWxSUWYxbM349vmUg/4Yut/PaGYFC9UQ0BfY=; b=Rp75iTlD+A335Oz8lc90PB8UpUETxdYWMGNfJlizrF4JehXHio9KWM399MfH1aPyHN kecpNK3ytScEeOzI34Tc0gxU60wIxgD3RpDxdjiOCXiJ1DW6qgrw65we8G3NHLXrFdIc qVDcNHLY34Vw2HYiwr22nipcoGQmQx2fBdPhFsr2aR5h1ynTK5nJ1oD7nw1oIKuA+Ypk vjtS0zyA7EOay5u+VSw1ohSuO2Hga0iPs5Tu4ribV1647/XK2rkZ6h059uiTmbGn2N3r Bg2Lr5Jb1WxT1Vpv6EnC3SuEhX4400kWxfKfxssMLG9fTBaw7CusV4GnL/GbMg3iLfDf Fd0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=GIX1stpvWxSUWYxbM349vmUg/4Yut/PaGYFC9UQ0BfY=; b=pG61CEiFB9f9DGmUM5wZOXRUT2P6QxQzRMpsH7mkdJVZa/oyRBDQwfdZDYEnN7Ji2G jKmRf6sjRHj5Rnq3u03+UE9pr00MPz7ZFd2dn6rCFmQgKTDKxZGZ6CcCM4/E9C+nzQWH u+4oaalwsj8t5YtW9ZxajTpQi2GZCOVJ+LTfqi4zwHZdalBSF2za6QBIPIxRna6We2ZU VNyjVdijHL1sHpbB1xPXFScKbqhPjFPyxVmHVADQUw/YM5630bW6JgKNJwNS04gyTqcB c8ezR8vNP0AK+SpNBtUOTKGdWhp2+b5mzmeQldqZh4nUpGM/1COxrY5P0hjmmkRtgMK/ SvSA== X-Gm-Message-State: AKGB3mKoGhC/hIyJ+3JZWFbTBQk3gpSl1v2f2OPubtdkMRVY5wMgbE8o +0NglQmZrWtU5nwrssYMSTOuGg== X-Google-Smtp-Source: ACJfBouVcZVOOeRB8eIGNlwVLx1mv3ZNq6II0F2yedOrc+lLEdnGrwJ3UV9k/O+ya+oxTdJtmpvRfg== X-Received: by 10.84.169.67 with SMTP id g61mr4883606plb.152.1513728164442; Tue, 19 Dec 2017 16:02:44 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d132sm7350297pfg.118.2017.12.19.16.02.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Dec 2017 16:02:43 -0800 (PST) To: v6ops@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> Date: Wed, 20 Dec 2017 13:02:44 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 00:02:46 -0000 On 20/12/2017 12:42, Templin, Fred L wrote: > Brian - what is this GRASP thing: > > https://www.ietf.org/id/draft-ietf-anima-grasp-15.txt > > First of all, it looks like a protocol specification but it is coming from an > operations WG which seems odd to me. How is it that anima can exist > as an OPS group and produce standards-track specifications? Easily. This was a chartered work item and until recently one of the Internet ADs served as AD for the WG, precisely because we were chartered to do protocol development. > Second, it looks like it wants to be a link-local discovery protocol that can > replace existing discovery protocols like DHCPv6, IPv6 ND, etc. Is that the > intention - to replace well established protocols with something new? No. It isn't competing with ND or DHCPv6 in the least. GRASP Objectives (the atoms of discovery) are higher level objects than anything you would discover with DHCP or ND. There *is* an element of overlap with DNSSD, but we're working to avoid that becoming a tussle (draft-eckert-anima-grasp-dnssd-00). You should start with https://tools.ietf.org/html/draft-ietf-anima-reference-model to get the big picture. Or if you prefer bullet points: https://github.com/becarpenter/graspy/blob/master/AN-overview.pdf Regards Brian From nobody Wed Dec 20 09:29:48 2017 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 6C3461270A3 for ; Wed, 20 Dec 2017 09:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPzmMuEu1bWI for ; Wed, 20 Dec 2017 09:29:45 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82FF1241F3 for ; Wed, 20 Dec 2017 09:29:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vBKHTjOt056692; Wed, 20 Dec 2017 10:29:45 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vBKHTh3O056589 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 20 Dec 2017 10:29:43 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 20 Dec 2017 09:29:42 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1347.000; Wed, 20 Dec 2017 09:29:42 -0800 From: "Templin, Fred L" To: Brian E Carpenter , "v6ops@ietf.org" Thread-Topic: [v6ops] GRASP Thread-Index: AdN5IhZ/InAT2FQPSLSGequLh0yxXQARtPkAABM6xMA= Date: Wed, 20 Dec 2017 17:29:42 +0000 Message-ID: <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> In-Reply-To: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 17:29:47 -0000 Hi Brian, > No. It isn't competing with ND or DHCPv6 in the least. OK, that is great but whenever we talk about prefix delegation you say "go see anima" - so I did. I read draft-ietf-anima-prefix-management which cites both DHCPv6 PD and GRASP, so I took a high-level pass over GRASP and saw that it was specifying a new service discovery protocol which made me wonder whether it was entering into a new tussle space involving DHCPv6 PD and IPv6 ND. If there is in fact no tussle, can we say that IPv6 ND is the mandated neighbor discovery service for IPv6 and that DHCPv6 PD is the mandated prefix delegation service? It would make life much easier to be able to cite IPv6ND and DHCPv6 PD normatively instead of constantly having to take care to cite them only as examples. Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Tuesday, December 19, 2017 4:03 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] GRASP >=20 > On 20/12/2017 12:42, Templin, Fred L wrote: > > Brian - what is this GRASP thing: > > > > https://www.ietf.org/id/draft-ietf-anima-grasp-15.txt > > > > First of all, it looks like a protocol specification but it is coming f= rom an > > operations WG which seems odd to me. How is it that anima can exist > > as an OPS group and produce standards-track specifications? >=20 > Easily. This was a chartered work item and until recently one of the Inte= rnet > ADs served as AD for the WG, precisely because we were chartered to do > protocol development. >=20 > > Second, it looks like it wants to be a link-local discovery protocol th= at can > > replace existing discovery protocols like DHCPv6, IPv6 ND, etc. Is that= the > > intention - to replace well established protocols with something new? >=20 > No. It isn't competing with ND or DHCPv6 in the least. GRASP Objectives (= the > atoms of discovery) are higher level objects than anything you would disc= over > with DHCP or ND. There *is* an element of overlap with DNSSD, but we're > working to avoid that becoming a tussle (draft-eckert-anima-grasp-dnssd-0= 0). >=20 > You should start with https://tools.ietf.org/html/draft-ietf-anima-refere= nce-model > to get the big picture. Or if you prefer bullet points: > https://github.com/becarpenter/graspy/blob/master/AN-overview.pdf >=20 > Regards > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Dec 20 13:13:17 2017 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 4E89D126BF6 for ; Wed, 20 Dec 2017 13:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7T-Qbv-Tbqj for ; Wed, 20 Dec 2017 13:13:14 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA56120046 for ; Wed, 20 Dec 2017 13:13:13 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id vBKL7L2A023061; Wed, 20 Dec 2017 16:13:11 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2eyy998jka-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Dec 2017 16:13:11 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vBKLDA5n023033; Wed, 20 Dec 2017 16:13:10 -0500 Received: from alpi134.aldc.att.com (alpi134.aldc.att.com [130.8.217.4]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vBKLD5bN022980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Dec 2017 16:13:07 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi134.aldc.att.com (RSA Interceptor); Wed, 20 Dec 2017 21:12:48 GMT Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 7797940002BC; Wed, 20 Dec 2017 21:12:48 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30488.vci.att.com (Service) with ESMTPS id 6724240002A1; Wed, 20 Dec 2017 21:12:48 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.227]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0361.001; Wed, 20 Dec 2017 16:12:48 -0500 From: "STARK, BARBARA H" To: "Templin, Fred L" , "v6ops@ietf.org" Thread-Topic: [v6ops] GRASP Thread-Index: AdN5IhZ/InAT2FQPSLSGequLh0yxXQALa6YAACSQnQAAAuiaUA== Date: Wed, 20 Dec 2017 21:12:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.216.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-20_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=412 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712200295 Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 21:13:15 -0000 > ... can we say that ... > DHCPv6 PD is the mandated prefix delegation service? HNCP (RFC 7788) can be used to delegate prefixes inside a home network. I = don't think there's consensus for stateful DHCPv6 server to be mandated for= internal-to-the-home-network use cases. Barbara From nobody Wed Dec 20 13:29:38 2017 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 84F4E1201F2 for ; Wed, 20 Dec 2017 13:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMFHyfqYMzYA for ; Wed, 20 Dec 2017 13:29:35 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0779C1200C5 for ; Wed, 20 Dec 2017 13:29:35 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id j9so12410778pgc.11 for ; Wed, 20 Dec 2017 13:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=UVaCQ5w+pChvlfMzOaxTo4Ch6tzsyJawtyTy8Bpj6iQ=; b=PzDaWyun5DvCYvqoquFiaAsVqt5g7qF1WyesMhfV3vFFDribbbzFKQv3kthGsUw17z pbNlVmdCREjYYe9csqhcGoMVv4wMqB0lYp34nGHd1X7AFDI24o6VjB/NzTpobHSBOyXQ dN9V8JRmuM7+ZgdAaV8eWi+E53LYPN2KUcM5w7+wRwisDBbfNYTlYou4SqyW/nAmVAFF rGcbWEnr3Odtl/uFx/BKl5BfnOzpdJNpAd9/7tK8IAKJfR6qdMvwUGtlzXa92TfYRDbm 0JzywubRG1RusYOrvpr7Da8U8lcadYVH9z5h29uqTaJCSnS4X/2uAIGS9lbKjGBzaSwD wlOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=UVaCQ5w+pChvlfMzOaxTo4Ch6tzsyJawtyTy8Bpj6iQ=; b=lrspX2yV6uzOAYPPkFqZRCoOrZmND676KtSmwuI5RSZFHy/zMxOpUO/iz1HeubV61a 64T+o1yJxm7MgG3xauhcM2LwliBxAJ4gOHK/3Y05EAlrjE5PgvUqJusQ7DBV5XX4cKXo FPtPKpLTv0z7aeTHgKsIsMD9wYDL+Ms/NVtZOehJflz+VaOIuOP0/gVMHZSUHB7TKnb4 WMrNlNyweoyMC8pGhKeNmAcAXcOCjRtyXAhLBM9xWe4nGWPmrw+Ozrag4mPSeAcRCv/+ DzbTqCzEzkDJL+Sb3EEs+JOB1PUJXzcfu3d2RoaLCynp1qrB1xQsSph2AhHywxQLQni6 kH0g== X-Gm-Message-State: AKGB3mJ7vslBeInjiGhhQyrMZRS+FRYQmgYlV4rkbLW11DgUz1S3woNQ T9rJR94de3aPOIMyDUt3z086zDg1ys0= X-Google-Smtp-Source: ACJfBosqCrZHOzoC21l4y4bCb98a27SEEQROIbA26U/jBosJPOFsPxIW7Sch2nWSAoTckZ3G0viTaA== X-Received: by 10.98.41.197 with SMTP id p188mr8249413pfp.9.1513805374062; Wed, 20 Dec 2017 13:29:34 -0800 (PST) Received: from ?IPv6:2620::10e7:10:f9c3:3646:792a:9010? ([2620:0:10e7:10:f9c3:3646:792a:9010]) by smtp.gmail.com with ESMTPSA id c185sm35693759pfb.48.2017.12.20.13.29.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2017 13:29:33 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_AEF5CD24-B08E-444B-AFC1-EE2A9668D789" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 20 Dec 2017 13:29:39 -0800 References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "v6ops@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> Message-Id: <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 21:29:36 -0000 --Apple-Mail=_AEF5CD24-B08E-444B-AFC1-EE2A9668D789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 20, 2017, at 13:12, STARK, BARBARA H wrote: > [Fred Template asks?] >> ... can we say that ...DHCPv6 PD is the mandated prefix delegation = service? >=20 > HNCP (RFC 7788) can be used to delegate prefixes inside a home = network. I don't think there's consensus for stateful DHCPv6 server to = be mandated for internal-to-the-home-network use cases. I don=E2=80=99t think there is consensus to mandate that prefix = delegation of any sort be a feature of non-transit networks. Pretty sure = there is a vocal and powerful faction that will contest against any = effort to mandate any kind of prefix delegation on networks where = general purpose hosts are provided with public Internet connectivity. = Which is why I have finally come around on the need to deploy address = amplifying NAT66 in home networks. --james woodyatt > --Apple-Mail=_AEF5CD24-B08E-444B-AFC1-EE2A9668D789 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Dec 20, 2017, at 13:12, STARK, BARBARA H <bs7652@att.com> = wrote:
[Fred = Template asks?]
... can = we say that ...DHCPv6 PD is the mandated prefix delegation service?

HNCP (RFC 7788) can be used =  to delegate prefixes inside a home network. I don't think there's = consensus for stateful DHCPv6 server to be mandated for = internal-to-the-home-network use cases.

I don=E2=80=99t think there is consensus to = mandate that prefix delegation of any sort be a feature of non-transit = networks. Pretty sure there is a vocal and powerful faction that will = contest against any effort to mandate any kind of prefix delegation on = networks where general purpose hosts are provided with public Internet = connectivity. Which is why I have finally come around on the need to = deploy address amplifying NAT66 in home networks.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_AEF5CD24-B08E-444B-AFC1-EE2A9668D789-- From nobody Wed Dec 20 13:36:04 2017 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 9036D1205F0 for ; Wed, 20 Dec 2017 13:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxlcsG10C5mS for ; Wed, 20 Dec 2017 13:36:00 -0800 (PST) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CADF1200C5 for ; Wed, 20 Dec 2017 13:36:00 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vBKLZwm8002747 for ; Wed, 20 Dec 2017 22:35:58 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 32CE4200CCC for ; Wed, 20 Dec 2017 22:35:58 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 20328200C1E for ; Wed, 20 Dec 2017 22:35:58 +0100 (CET) Received: from [132.166.84.166] ([132.166.84.166]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vBKLZvr2029514 for ; Wed, 20 Dec 2017 22:35:57 +0100 To: v6ops@ietf.org References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Alexandre Petrescu Message-ID: <6a6c63b6-5f7f-ecfd-061c-3f13e4ba12a1@gmail.com> Date: Wed, 20 Dec 2017 22:35:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 21:36:02 -0000 Le 20/12/2017 à 22:12, STARK, BARBARA H a écrit : >> ... can we say that ... >> DHCPv6 PD is the mandated prefix delegation service? > > HNCP (RFC 7788) can be used to delegate prefixes inside a home network. I don't think there's consensus for stateful DHCPv6 server to be mandated for internal-to-the-home-network use cases. HNCP is not deployed in the home network I live in. Where is HNCP deployed? Alex > Barbara > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Dec 20 17:50:35 2017 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 A885B12702E for ; Wed, 20 Dec 2017 17:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceyEPlfHrd_p for ; Wed, 20 Dec 2017 17:50:32 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3522D126D85 for ; Wed, 20 Dec 2017 17:50:32 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id o13so1921176pgp.4 for ; Wed, 20 Dec 2017 17:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+IxlcVM7jxJK9nc7Cu5M3s53HWHthLfUhOxYhh1cWcM=; b=Hq8r+KRHzhKceT2nL1zVNvF0E+TphB5bMHo2kdXlqfdnodGLP34cx4LufJzphMYFt2 ADdkvxmlG2YvFaHNtu2Aq5RIZsk0QUDDxJy1+i7Jl04GzirKoFfzK5r3c4+fQRMyuIEp qjY+hvPgbbuDWjU245RJbn3WdtPqkOo/rqSeKjzAoRsUu2ON0ggk72Oyydpj4E2v1k0X RJZSd5Im0FZRDdw+n2clSKzd0netM8YK0kpAb3rcBgZ3aoetFaxQfHcDM9IGN/7cix0d m9QpEkhm188f8cpeXmoKhPnrvoVIB6VNCH9+C81EZ1S6wlti6R6ElyFDlv/gul80uNs8 PLcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+IxlcVM7jxJK9nc7Cu5M3s53HWHthLfUhOxYhh1cWcM=; b=jEAqu+ynISloRol/HUIqkHWEOL1zFjKjf1GKJxB9OJaJDF2tYJmvyUZElpwS6K/sCy MT2T8zYW8039sTspTcQlsk4mWpjELN1yMT7Kidj2xnpp6H5BVfJUnb0XDuGu85X+x/hx S5bNTROh29kaGz1PfSbcbExRzh8aadFtmFgUvG/7d8CQ5GeWEX4UcCoKWj5jetLwWKZ2 XdXML24sDnbgyqoQFyA52aTklbfCSlDCzUAlHzlkCgP3Me0etNrXUiBhmgzoyOyMdTBI 8eEqQSr/pfCxw7lX1WZOPqeIqCyVgbtQ14XUOb2ETVAA7FJbtvyUyvHXzt2aWmqgtCsQ z5SA== X-Gm-Message-State: AKGB3mJ9f1puv4hjNRksQQecEw6hTntkVaClyz0W5iJEapkdqmVFI4dU 6kwfPjvwTRVvNTlHH8okYwspag== X-Google-Smtp-Source: ACJfBovOJJ2n5kRUObVphY3rnJzHxkQ7rasaYosNSp/6HWZW39szR/KRXa561BkWpXNWsGuCilMo6A== X-Received: by 10.101.98.2 with SMTP id d2mr7890363pgv.287.1513821031430; Wed, 20 Dec 2017 17:50:31 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x3sm31290722pgr.7.2017.12.20.17.50.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2017 17:50:30 -0800 (PST) To: v6ops@ietf.org References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 21 Dec 2017 14:50:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 01:50:33 -0000 On 21/12/2017 10:12, STARK, BARBARA H wrote: >> ... can we say that ... >> DHCPv6 PD is the mandated prefix delegation service? > > HNCP (RFC 7788) can be used to delegate prefixes inside a home network. I don't think there's consensus for stateful DHCPv6 server to be mandated for internal-to-the-home-network use cases. Right, and all IETF standards are voluntary anyway. Mandating anything as the exclusive something is never going to fly. (And as far as the case Fred raised goes, there was very careful chartering language for ANIMA to ensure that we didn't trample on HOMENET; and there's also careful language in draft-ietf-anima-prefix-management to show how it can fit in with DHCPv6-PD. In a nutshell, the autonomic function manages prefixes as a resource pool, handing them out to devices that can then delegate them to non-autonomic devices using PD.) Brian From nobody Thu Dec 21 10:01:13 2017 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 5F38312D967; Thu, 21 Dec 2017 10:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbD4q-FNu0Sd; Thu, 21 Dec 2017 10:01:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B43B12D95A; Thu, 21 Dec 2017 10:00:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 98044B8127F; Thu, 21 Dec 2017 10:00:46 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, v6ops@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20171221180046.98044B8127F@rfc-editor.org> Date: Thu, 21 Dec 2017 10:00:46 -0800 (PST) Archived-At: Subject: [v6ops] =?utf-8?q?RFC_8305_on_Happy_Eyeballs_Version_2=3A_Better_?= =?utf-8?q?Connectivity_Using_Concurrency?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 18:01:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8305 Title: Happy Eyeballs Version 2: Better Connectivity Using Concurrency Author: D. Schinazi, T. Pauly Status: Standards Track Stream: IETF Date: December 2017 Mailbox: dschinazi@apple.com, tpauly@apple.com Pages: 15 Characters: 32917 Obsoletes: RFC 6555 I-D Tag: draft-ietf-v6ops-rfc6555bis-07.txt URL: https://www.rfc-editor.org/info/rfc8305 DOI: 10.17487/RFC8305 Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555. This document is a product of the IPv6 Operations Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Dec 22 19:35:23 2017 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 D1C4C124D85 for ; Fri, 22 Dec 2017 19:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHkvQfXBcOMT for ; Fri, 22 Dec 2017 19:35:20 -0800 (PST) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B351200C5 for ; Fri, 22 Dec 2017 19:35:20 -0800 (PST) Received: by mail-pl0-x233.google.com with SMTP id s3so13918496plp.4 for ; Fri, 22 Dec 2017 19:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1tUsQ2FfhbjshhCgFBCst6c9HCTttGk8xlB/1ZaftQc=; b=LBqb5VmsEFoAfaQpo/yVln3qm+eb2anB2Gp8/GSFB/+mKs4OGNgn7WS0ruRVu/MFPX aUSkychcj8tVflhOuR8YTfjz078kt/ytvlEhELo7Vmm92goUhmSNcrkwrzg3CFr5Eh9Q t3jr5Ypn9b4u0ZBxBifv5ubQpbY2dURq9dxdyYMxU6LOvqga/kR1eja/K7jZyDYpaRKt 3m/luZma1UUAD/yy7uV1xNFbZuTJbbwnlCMB1938vVmfNpSqrXR2poUEdl22HLi11q/y q/GOTiygfZeaj4SLXFO2UY2qAdWcO+ERVkVMTMrKbgQJadRpBBsFbE2fiyxibZT0CODC Fclw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=1tUsQ2FfhbjshhCgFBCst6c9HCTttGk8xlB/1ZaftQc=; b=Aanq+P5y+60bkBNnvDsCVlnS2tapjG1wVrktVrlJKdKrX0Y8utEnlbRO1aUAXKWozs YAR+DfeJoIDPY2kF4Qzx4qKm3/99pgyFeplGjtNDBVwyketj+Iiayf9Ff1KKxDODvEi2 Mxw9M9nZEqaFXk0HTmbTuBW6sJRdPY62V4DxVUDVFS2S+/X0cuZz+v08c6tdo0mELJrk TLAI7DVPkyXprGrzEnzJi5vV1R6U6IeDFlSFzO6aLWuYC8YCsRPOT4BEKoYoTHwZyCwI 6zLpeXGzv31Wk7Il+c4uz2rsjMer1vxlNxMck0kzrnmJvmfo3efcUyt/u9Ouyumh+U2N 95Hg== X-Gm-Message-State: AKGB3mI24CsNIabe4FqDjll1Z+zOm93Ne9+43Er6JJkkZ9li//9IjciR cKzt2I29KiU0ZdajlVYLGT2UvA== X-Google-Smtp-Source: ACJfBovlhF5MuGUtrPb/2sb7ONxcc+HloK5GDTX+v8tbPYq7IGWgPqnxJ++YDGWyE3miZA6FFoilyA== X-Received: by 10.84.236.71 with SMTP id h7mr16282393pln.93.1514000119360; Fri, 22 Dec 2017 19:35:19 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q24sm39674800pgv.27.2017.12.22.19.35.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Dec 2017 19:35:17 -0800 (PST) To: v6ops@ietf.org References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> Date: Sat, 23 Dec 2017 16:35:25 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2017 03:35:22 -0000 On 21/12/2017 10:29, james woodyatt wrote: > On Dec 20, 2017, at 13:12, STARK, BARBARA H wrote: >> [Fred Template asks?] >>> ... can we say that ...DHCPv6 PD is the mandated prefix delegation se= rvice? >> >> HNCP (RFC 7788) can be used to delegate prefixes inside a home networ= k. I don't think there's consensus for stateful DHCPv6 server to be manda= ted for internal-to-the-home-network use cases. >=20 > I don=E2=80=99t think there is consensus to mandate that prefix delegat= ion of any sort be a feature of non-transit networks. Pretty sure there i= s a vocal and powerful faction that will contest against any effort to ma= ndate any kind of prefix delegation on networks where general purpose hos= ts are provided with public Internet connectivity. Which is why I have fi= nally come around on the need to deploy address amplifying NAT66 in home = networks. I don't see that argument for homenets. ISPs don't seem reluctant to hand= out /64, /56 or /48 to paying subscribers. I can see that if you want to= do something fancy while roaming, you might have to deal with a single /= 128. Brian From nobody Sat Dec 23 19:55:32 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 273C31200C1; Sat, 23 Dec 2017 19:55:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: warren@kumari.net, v6ops@ietf.org, v6ops-chairs@ietf.org, fredbaker.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.68.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151408773111.1006.8169683674649384414.idtracker@ietfa.amsl.com> Date: Sat, 23 Dec 2017 19:55:31 -0800 Archived-At: Subject: [v6ops] v6ops - New Meeting Session Request for IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Dec 2017 03:55:31 -0000 A new meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: 6man 6lo 6tisch homenet opsawg anima Second Priority: opsec intarea mtgvenue sunset4 Third Priority: dnsop tsvwg spring rtgwg People who must be present: Fred Baker Ron Bonica Lee Howard Warren Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Dec 27 15:07:06 2017 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 C3ADC12D82F for ; Wed, 27 Dec 2017 15:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h1i9AqS85pe for ; Wed, 27 Dec 2017 15:07:03 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061BF12D82E for ; Wed, 27 Dec 2017 15:07:02 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id r2so3874268pgq.13 for ; Wed, 27 Dec 2017 15:07:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Pl1OrRTsO+DB8ajiSPFdzHwybOTtbIuiI28x8scW1E4=; b=BKU7HlP07cUPoCtb3Rb69Df+iTA5PcsqmLDMjwFQf9hC+8YmWtqBkUTEOgfJv5Nn34 qJVszx02Bn8AVvzuB8tjR44xNp6uVHr5AXdeHv1B9gpO20aBACTXqo2UJ0GtIqm6XYuH reMB0oQM0O1MfdeSj8e4MZHnCde2ngliwHXgblAZ7iegd19ngxOPb82wbBYdBEzVaS/c Jv1N81iPJNFV6iGemHEgfefguo+pGr+rP28WzhxnhChjzzlsQHUCIlQgJLmoTcmh5/GI 9hL8guoJpTyI5o38+BBtb9BY6a05r6kaNhT1O9XJ8qfAKHPJ8qRq8tVH68Tl2IJ7Au0Z TUYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Pl1OrRTsO+DB8ajiSPFdzHwybOTtbIuiI28x8scW1E4=; b=lRZEAhQLOh0MzK+h2qpVjSgSpS8QNlfTUxnpiQdlNN3Vpr+YSnMO7qusmKZXeEG5EM pLdJla4rTQxRkeJhaea1raWjb13KKNikoJVCtitOvh2nXTyhReDs8ShFr9M7PbR6S8Kf dun1862sDsWbHZbyfpPCIw5M4nUw94U7zYBbc0wRYbnvXdjt02j2q3VPY12Sg8gX2dWC 16TLuN3HlRI1EKpuUvSjXuM8vsxOGn8i4lLn4JqxhARgzvrZgl/3/b8NHJ06cOPI7jrH i5H3XRYiK83MoY261kXHEJRHG+n7HX3ahcbbxcJlD0ynR/o3t7jmHIIfSLD7rOQXXUYu vUwA== X-Gm-Message-State: AKGB3mLSSDKc1qehPkaYQTIGU1SHDCm1+GT2LBDDUol+itdt6GZ1IWcS ohJrOHMLhrRD/4Zhu7RfZfOlxA== X-Google-Smtp-Source: ACJfBouTU/KR8M6TbIoEJDQcfnr1z7c5xOeli4VYUctHwPEUUMvd0O0aiz6KHlCIBLdSJXpJ/H6OLA== X-Received: by 10.98.102.219 with SMTP id s88mr30067889pfj.191.1514416022233; Wed, 27 Dec 2017 15:07:02 -0800 (PST) Received: from ?IPv6:2620::10e7:10:21b9:7cc1:f8b8:3dcb? ([2620:0:10e7:10:21b9:7cc1:f8b8:3dcb]) by smtp.gmail.com with ESMTPSA id e7sm73514169pfj.44.2017.12.27.15.07.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Dec 2017 15:07:01 -0800 (PST) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BBF4D075-0387-4020-A001-57AD3B553DC9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 27 Dec 2017 15:07:00 -0800 In-Reply-To: <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> Cc: v6ops@ietf.org To: Brian E Carpenter References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 23:07:05 -0000 --Apple-Mail=_BBF4D075-0387-4020-A001-57AD3B553DC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 22, 2017, at 19:35, Brian E Carpenter = wrote: >=20 > I don't see that argument for homenets. ISPs don't seem reluctant to = hand out /64, /56 or /48 to paying subscribers. I can see that if you = want to do something fancy while roaming, you might have to deal with a = single /128. They are very reluctant to deploy CPE gateways that use any current or = forthcoming protocol to delegate automatically any portion of their = prefix to routers on home network links. In shorter terms, they are = happy to hand out /56 (less so /48) to CPE edge routers owned by paying = customers, but there is no appetite for supporting customers with = interior routers downstream of the CPE edge router. Certainly not in = their provider provisioned CPE gateway devices that are more often than = not bundled in the service agreement and quietly included in the total = charge for access. Oh, they might have plans to use that number space = with some non-standard prefix distribution protocol, but it appears = there is very little appetite for adopting any standard made available = for third parties to use freely. That=E2=80=99s why anybody planning to offer consumers technology = solutions that include IPv6 router functions running on nodes located = behind CPE routers are forced to resort to address amplifying NAT to = operate as a router on the downstream links and a host on the upstream = home network link behind the CPE router. Just as happened with IPv4 for = pretty much the same reasons. I=E2=80=99ve spent the better part of = three years trying to avoid that conclusion, and my experience in V6OPS = and HOMENET has led me to conclude that it was a badly wasted effort. = NAT66 is the wave of the future. --james woodyatt > --Apple-Mail=_BBF4D075-0387-4020-A001-57AD3B553DC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Dec 22, 2017, at 19:35, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

I don't see that = argument for homenets. ISPs don't seem reluctant to hand out /64, /56 or = /48 to paying subscribers. I can see that if you want to do something = fancy while roaming, you might have to deal with a single = /128.

They are very reluctant = to deploy CPE gateways that use any current or forthcoming protocol to = delegate automatically any portion of their prefix to routers on home = network links. In shorter terms, they are happy to hand out /56 (less so = /48) to CPE edge routers owned by paying customers, but there is no = appetite for supporting customers with interior routers downstream of = the CPE edge router. Certainly not in their provider provisioned CPE = gateway devices that are more often than not bundled in the service = agreement and quietly included in the total charge for access. Oh, they = might have plans to use that number space with some non-standard prefix = distribution protocol, but it appears there is very little appetite for = adopting any standard made available for third parties to use = freely.

That=E2=80= =99s why anybody planning to offer consumers technology solutions that = include IPv6 router functions running on nodes located behind CPE = routers are forced to resort to address amplifying NAT to operate as a = router on the downstream links and a host on the upstream home network = link behind the CPE router. Just as happened with IPv4 for pretty much = the same reasons. I=E2=80=99ve spent the better part of three years = trying to avoid that conclusion, and my experience in V6OPS and HOMENET = has led me to conclude that it was a badly wasted effort. NAT66 is the = wave of the future.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_BBF4D075-0387-4020-A001-57AD3B553DC9-- From nobody Sun Dec 31 08:05:41 2017 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 C0616127978 for ; Sun, 31 Dec 2017 08:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tlRLS9YGvA1 for ; Sun, 31 Dec 2017 08:05:36 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25A91200F3 for ; Sun, 31 Dec 2017 08:05:36 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vBVG5Y1L003729 for ; Sun, 31 Dec 2017 17:05:34 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 834432032CA for ; Sun, 31 Dec 2017 17:05:34 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 779FB20177F for ; Sun, 31 Dec 2017 17:05:34 +0100 (CET) Received: from [132.166.84.62] ([132.166.84.62]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vBVG5Xvg031015 for ; Sun, 31 Dec 2017 17:05:34 +0100 To: v6ops@ietf.org References: <268669d2-e36d-9fb1-cf1c-d3be4cb85e51@gmail.com> <8316cc707dd847a8b2d45e4b6b468f36@XCH15-06-08.nw.nos.boeing.com> <2D09D61DDFA73D4C884805CC7865E6114DCDD69B@GAALPA1MSGUSRBF.ITServices.sbc.com> <0EFD6879-B33B-4639-AE77-A90607DD9455@google.com> <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> From: Alexandre Petrescu Message-ID: <9c2fdbe9-6638-ed7c-81ba-487eb6f84885@gmail.com> Date: Sun, 31 Dec 2017 17:05:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <90825185-6fd2-296d-229f-43a79e16bb63@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] GRASP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 16:05:39 -0000 Le 23/12/2017 à 04:35, Brian E Carpenter a écrit : > On 21/12/2017 10:29, james woodyatt wrote: >> On Dec 20, 2017, at 13:12, STARK, BARBARA H >> wrote: >>> [Fred Template asks?] >>>> ... can we say that ...DHCPv6 PD is the mandated prefix >>>> delegation service? >>> >>> HNCP (RFC 7788) can be used to delegate prefixes inside a home >>> network. I don't think there's consensus for stateful DHCPv6 >>> server to be mandated for internal-to-the-home-network use >>> cases. >> >> I don’t think there is consensus to mandate that prefix delegation >> of any sort be a feature of non-transit networks. Pretty sure there >> is a vocal and powerful faction that will contest against any >> effort to mandate any kind of prefix delegation on networks where >> general purpose hosts are provided with public Internet >> connectivity. Which is why I have finally come around on the need >> to deploy address amplifying NAT66 in home networks. > > I don't see that argument for homenets. ISPs don't seem reluctant to > hand out /64, /56 or /48 to paying subscribers. I can see that if you > want to do something fancy while roaming, you might have to deal with > a single /128. I am not sure what did you mean by something fancy? A delegated /56 to a UE can stay stable during on-off and handover events, although I am also curious whether it resists during roaming. Ideally, there would be no need to use /128 instead of /56 in order to be roaming-resistent. Alex