Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

joel jaeggli <joelja@bogus.com> Mon, 30 April 2018 07:18 UTC

Return-Path: <joelja@bogus.com>
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 653DC126CD8 for <v6ops@ietfa.amsl.com>; Mon, 30 Apr 2018 00:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.357
X-Spam-Level:
X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_HI=-5] 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 L--wvJ_ny6rv for <v6ops@ietfa.amsl.com>; Mon, 30 Apr 2018 00:18:48 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D2E124319 for <v6ops@ietf.org>; Mon, 30 Apr 2018 00:18:48 -0700 (PDT)
Received: from mb.local ([IPv6:2600:380:523c:c820:950c:e6a2:4ee1:9b85]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w3U7IJiD064952 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 30 Apr 2018 07:18:33 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2600:380:523c:c820:950c:e6a2:4ee1:9b85] claimed to be mb.local
To: Ole Troan <otroan@employees.org>, V6 Ops List <v6ops@ietf.org>
References: <3A083AA8-41D3-4BF8-BE31-5071975B6F98@gmail.com> <CAHL_VyC1xUDDqZRz1r--u8nyuLaZRnsT0ZR7hzOw4HWUkgwPXg@mail.gmail.com> <52D64464-A1BB-4FFA-AA79-28B8953E3B93@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DD7F981@GAALPA1MSGUSRBF.ITServices.sbc.com> <ECDF4B32-1A4E-49A9-9255-091F2FEA78AF@gmail.com> <CAHL_VyBnRkmpNDcwqTTxu8DnUGFAdKgL+PB1pt9yFLQ==cM0aA@mail.gmail.com> <D8000940-273D-4C25-8B71-F75833B74462@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF126EC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <694A1FF1-CA8C-42CC-87F3-789EA71807AE@employees.org>
From: joel jaeggli <joelja@bogus.com>
Openpgp: preference=signencrypt
Autocrypt: addr=joelja@bogus.com; prefer-encrypt=mutual; keydata= xsDiBD832SIRBADVEfzsfIX+fuN2XUPyyEXP4Mq8dqpjmcy+XTIHzZLVKzxmP+17zJYTj9MR dMA5vuZRsRpzFoeDMOJyHVVyaQeSwEApO3FJOej+CNAXpaTLYgobL1XcsQXMTbeNT5x9ZK+R ZQtoC8Vunv6UTygY+kHUHvNijhVtJtCcAW0NE2fiWwCgjKPAldaGNbPg6SKvSTFipsPPqoUE ALKjZApjCG/3Yi4kHgzCQw65mfE9u8O7bZcrvmzzRgmwShyQjrRNgxhwl2q9+e8Uo6kuk56q 0Q4On6y873W6EtBRYLTU5MiIK3mspi5YYpIi/F2XTkcW6Dx/C/ZQQ8WddAyX6QLAXHYMus86 x7tzjGM3HVlvJpWTb4CqcDOcvZakA/9aJhMEffleJx+6xrjZTUYvAQDYUSRWNmc+ehyAuh/B KH0DKqhkLlm0SBdsnKvQHXbdjhu9m9K4E6aR/s117QK60jZo1XNrVKJ1oM3X+2DNmDBl/K33 e/tPSC8byvD77doezHvWvE5n50KIEZezVgMkYWDSPWb0nefdXLY5+rgfms0fSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPsJjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAk3mKPcCGQEACgkQ8AA1q7Z/VrJ6vgCfYITQSd0+WXcYjEoj8+tNys5egPcAn3OUUHVt JElVkSSARJ4XWjRYqKiazsNNBD8320MQEACTNxol/GIZW4CGUnyIlr+13Dqx8aHZfbd96UQE Ys9mZkBxwP2V7D00tOETcY5apr9tr9oHf5p4xA2l2oE8KR4xbF6+0XIpeYzRcl5d0iUaSMwm HcX3J/+XyZegJqTG7zMEK72c1tPVrra9DRNZP+rhKFLJJornDiQJFQVhtQE37WA1kmC6rlyR KHA2RMYS3IugAgJfuy5pZn/5jKCv+ZxIv7tnk7GUQWwfPdr4PokPCBxSXUYch98Rcq3dbCio 8FPmrfI6K2Z9NMa/gXGpF3ynmxDJLY31aPgbUiv9VllZoeMkotbXHW1zrsXte/1MEgFrlkiQ WDJ/dHjlCdlFASfaPvVXxdiUgH7LV3cW+BOY2z4VVwhYM6/kTDoLKWZ3opBeN9KcAHPRFCkA fxwAu8PNgi74lMjcFzu66U8vVM37YqSYpXsi+mlwZDhzCJ8qm9FDwaH2bB1LJ7m41F098B29 SRG3s/XXgTCSt0js/yUp9EXRPQpME99GvwiBNFN9p9e45ZqS85Wll6GqHh+Jyvq0ODWH6XOz uop3UUqw6I2Q8rG7e/uxKWcFnt1q48uhdTHA0TfnYC5HpHf/tAuR+ui6s16xrENgFgeeu4b/ q/jA4N1ZuJU7IbnO5f28YTlJOef/HywY3OXBsrdhEXKLIc5xRj6NC4WphyQ9MQrx8cS1bwAD BQ//WNM1WUlr6tIn8/7SIqqHRg3UmzVNu4u+r9rK9LJkYRLA4xKb/TrqDhP9oyO7Oz2S5CsF wjiPc1vzGzfRgIOArPJrejM4BzHQ03tl1qb/5YNDaB1QzfPv6dT9OkhMMuth0tcmH5sjfbiF Nc41aKU5w4FFkTv3XmrXciz4+PWbAYGB7pYbhGmsx//9C2bS56Bu1QkFeSCzN5AvWAmJfyPU yMXFKDe21DlImMdkrn/K838Lm8o0CLOKbJBX8K0pE4rGEf20FLfmHx/bLZRcWhTm8cB/vHNd 8GhwFlvHylj6+5QtR0Tc0hBcOG8SZktjE/hEiYi+dAZCrwT9i8Hjulnx/vu+Knt40+5CB2hk L1VQwdGWLYO4FGqWwwv0Y8XhWOudLYCZQWrgOsIzYezahC5b9iobFx8dgAElXNPTxI/dymrI d/6foyBrGnzzOnV/gfWfQp7N1rbrh0mQXRhwwwQIjlmbUyz8fTlaTcAo8ocXTVUb6WY7U5nr ufzKsFceR/olFnvZKKhbGVG6VvqNLS1r5lcRR1J7GVZM+Sb2ZNKgnwiUf8yxKfWg84NUPt/b etviJ73LVPdjV1PNZgcxfPRO3XL6Y9FaBP9oB4f58ujuhzOLUt+6I0KuzY8H5RBBaIrJJptl DEOnxFn1J7Q0uxQ2BzqfZdKTwJS4OCjm+OsLd8HCRgQYEQIABgUCPzfbQwAKCRDwADWrtn9W soUzAJ4zatxnKYcGdyoFojBc1Y2jqaHZsQCbB25DmeFRx14xxuxdAXb0wsKf35w=
Message-ID: <89fe7fb6-4618-7e92-691b-8639af9c2747@bogus.com>
Date: Sun, 29 Apr 2018 15:03:28 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <694A1FF1-CA8C-42CC-87F3-789EA71807AE@employees.org>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="daZLHkhzffuN6X3yrTDZ72K6ehfWTd2m6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7OyGPm1uUIgUSCyyGzisEYf_lGs>
Subject: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2018 07:18:50 -0000

On 4/26/18 23:34, Ole Troan wrote:
> 
>> As you are on it, and given the IETF recommendation in RFC6888:
>>
>>   REQ-9:  A CGN MUST implement a protocol giving subscribers explicit
>>      control over NAT mappings.  That protocol SHOULD be the Port
>>      Control Protocol [RFC6887].
>>
>> which would apply also to the PLAT, I suggest you add an item in the 464lat section to support RFC6970.
> 
> I think that requirement needs to be reality checked.
> Has any of the operators of CGNs deployed PCP? Would they allow customers to control NAT mappings at all? Or would that just be a different subscription plan?
> For the other IPv4aaS mechanisms it isn't even an option...
> 
> From my perspective PCP from customers to control CGNs is not going to be deployed. I'd be happy to hear otherwise.

Accumulating state in the form of instructions from customers for of
durable port bindings is expensive forwarding state to accumulate,  It
is also expensive in the form of control-plane signalling. both of these
are DOS risks. I would think that they have similar shortcomings
respecting state as for example do multicast shared trees and would
likewise be viewed as an undesirable cost.

Joel

> Ole
> 
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET MARTINEZ
>>> Envoyé : jeudi 26 avril 2018 21:41
>>> À : V6 Ops List
>>> Objet : Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
>>>
>>> Hi Richard,
>>>
>>> As I've moved sections 3 & 4 to the end of the document as annexes, I've
>>> added a new small section for UPnP with your text. I think this also helps to
>>> clarify one of the issues raised by Lee.
>>>
>>> I'm working on all this changes with my co-authors, and if we are good with
>>> them, we probably will submit the new version in a couple of days or so.
>>>
>>> Thanks!
>>>
>>> Regards,
>>> Jordi
>>>
>>>
>>> -----Mensaje original-----
>>> De: v6ops <v6ops-bounces@ietf.org> en nombre de Richard Patterson
>>> <richard@helix.net.nz>
>>> Fecha: miércoles, 25 de abril de 2018, 11:16
>>> Para: V6 Ops List <v6ops@ietf.org>
>>> Asunto: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
>>>
>>>    Section 4 only briefly touches on UPnP, I'd like to propose that we
>>>    make a recommendation around its behaviour if it is enabled.
>>>
>>>    UPnP MAY be enabled on the IPv6 transition CE, for stateless
>>>    mechanisms that forward unsolicited inbound packets through to the CE.
>>>    If UPnP is enabled, the agent MUST reject any port mapping requests
>>>    for ports outside of the range(s) allocated to the IPv6 transition CE.
>>>
>>>    UPnP SHOULD be disabled for stateful mechanisms that do not forward
>>>    unsolicited inbound packets to the CE, unless implemented in
>>>    conjunction with a method to control the external port mapping, such
>>>    as IGD-PCP IWF [RFC6970].
>>>
>>>    -Richard
>>>
>>>
>>>    On 25 April 2018 at 01:38, Fred Baker <fredbaker.ietf@gmail.com> wrote:
>>>>
>>>>
>>>>> On Apr 24, 2018, at 12:13 PM, STARK, BARBARA H <bs7652@att.com> wrote:
>>>>>
>>>>> But that doesn't mean I believe the draft has exactly the right set of
>>> features included. My understanding of "adoption" is that it is still
>>> possible post-adoption to discuss whether specific features / requirements do
>>> or don't belong. If the precise set of features and requirements must be
>>> agreed upon prior to adoption, then I would not be in support of adoption.
>>> Hopefully we aren't setting the bar that high?
>>>>
>>>> I understand "adoption as a working group draft" to mean that the
>>> working group has agreed to work on the draft. There are some working groups
>>> that seem to confuse "adoption as a work group draft" with "agreement to send
>>> it to the IESG"; I don't, but expect conversation in between those two
>>> events.
>>>>
>>>> That said, I'd like to believe that the draft is pretty close, and that
>>> changes that need to be made to it will have text offered by the people that
>>> want them. So - keep your cards and letters coming...
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>>
>>>
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.consulintel.es
>>> The IPv6 Company
>>>
>>> This electronic message contains information which may be privileged or
>>> confidential. The information is intended to be for the exclusive use of the
>>> individual(s) named above and further non-explicilty authorized disclosure,
>>> copying, distribution or use of the contents of this information, even if
>>> partially, including attached files, is strictly prohibited and will be
>>> considered a criminal offense. If you are not the intended recipient be aware
>>> that any disclosure, copying, distribution or use of the contents of this
>>> information, even if partially, including attached files, is strictly
>>> prohibited, will be considered a criminal offense, so you must reply to the
>>> original sender to inform about this communication and delete it.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>