From nobody Wed May 7 06:33:22 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F381A0305 for ; Wed, 7 May 2014 06:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 fVEqplm41eaf for ; Wed, 7 May 2014 06:33:19 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id E226C1A0072 for ; Wed, 7 May 2014 06:33:18 -0700 (PDT) Received: from dhcp-10-61-108-210.cisco.com (173-38-208-170.cisco.com [173.38.208.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 8797860C6; Wed, 7 May 2014 06:33:10 -0700 (PDT) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_576933E8-A5E9-4678-861F-851DC8DA5C81"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 7 May 2014 15:32:59 +0200 Message-Id: <5A97FAD4-3E5B-436F-84C8-D0DC2FDA5E20@employees.org> To: ipsec-chairs@tools.ietf.org, svan@elvis.ru, kathleen.moriarty.ietf@gmail.com Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/u_8KP7thztJ0wVYsuB45LUvOCiE Cc: Brian Haberman , int-dir@ietf.org Subject: [Int-dir] int-dir review of draft-ietf-ipsecme-ikev2-fragmentation X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 13:33:21 -0000 --Apple-Mail=_576933E8-A5E9-4678-861F-851DC8DA5C81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii chairs, authors, Brian asked me as part of the int-directorate to review this document. Joe Touch had some good comments on this from the transport perspective. (http://www.ietf.org/mail-archive/web/ipsec/current/msg08653.html) Architecturally this opens up a larger debate. Any UDP application = protocol that depends on IP fragmentation and doesn't do segmentation = itself must be changed... if the premise is correct that IP = fragmentation cannot work correctly. there are a few approaches open to us: - consider this a bug in the network, and require that to be fixed - start work on a replacement of UDP that supports segmentation, SCTP? - fix the applications. I think this document solves a real problem. as a general recommendation = I think the document should not re-specify Path MTU discovery. it should = use RFC1981 and make application specific considerations referencing = RFC4821 (section 9, section 10.4) I would recommend against recursive fragmentation. I would also question the need to do path MTU discovery for a protocol = that only does a few message exchanges? at least the document should = clearly point out that there are three options for implementations of = this: - implementations that do not do PMTUD and does use the minimum message = sizes (576/1280) - implementations that depend on PMTUD (1191/1981) with a fallback to = minimum - implementations that use PMTUD/PLMTUD (1191/1981/4821) with = application probes=20 comments (marked @@) ---------------------------------- 1. Introduction: @@ it would be good if the document made it clear that for IPv4 these = NAT devices are broken (ref RFCXXX), and that for IPv6 throwing away = fragments is an operational choice, and it is as far as I know no = evidence that this happens on the open Internet. (it certainly happens = on network borders, e.g. in front of services, where the operator has = control and is confident no services using fragmentation exists). The problem is that some network devices, specifically some NAT boxes, don't allow IP fragments to pass through. This apparently blocks IKE communication and, therefore, prevents peers from establishing IPsec SA. This problem is valid for both IPv4 and IPv6 [FRAGDROP]. @@ the document would benefit from a few more definite articles. (and = language review in general). nothing that reduces understandability = though. e.g. "Initiator may first try to send unfragmented message and resend it fragmented only if it didn't receive response after several retransmissions, or it may always send messages fragmented (but see Section 3), or it may fragment only large messages and messages causing large responses." 2.4 Using IKE fragmentation @@ this seems a little at odds with a section full of 2119 language. "In general the following guidelines are applicable for Initiator:" "In general the following guidelines are applicable for Responder:" @@ vague. replace with recommendation to base the decision on the link = and path MTU? o Initiator MAY fragment outgoing message if it has some knowledge (possibly from lower layer or from configuration) that either request or response message will be fragmented by IP level or if unfragmented message was sent and no response was received after several retransmissions. o Responder MAY respond to unfragmented message with fragmented response if it has some knowledge (possibly from lower layer or from configuration) that response message will be fragmented by IP level. @@ this section is does not define "fragmentation threshold" 2.5. Fragmenting Message @@ could "fragment number" and "total fragments" be single octets? 2.5.1 @@ I'm not sure text like... adds value. "Sender MAY use other values if they are appropriate." 2.5.2 @@ I hope "refragment" doesn't mean that the individual fragments are = fragmented again? but rather that the original message is fragmented = into a set of smaller fragments? "While doing probes, node MUST start from larger values and refragment message with next smaller value if it doesn't receive response in a reasonable time after several retransmissions. " @@ please give better advice. "reasonable time" is hard to implement. "doesn't receive response in a reasonable time after" @@ should also reference RFC1981 @@ oh, so it is recursive fragmentation. that makes me somewhat = uncomfortable. "In case of PMTU discovery Total Fragments field is used to distinguish between different sets of fragments, i.e. the sets that were obtained by fragmenting original message using different fragmentation thresholds. As sender will start from larger fragments and then make them smaller, the value in Total Fragments field will increase with each new try. When selecting next smaller value of fragmentation threshold, sender MUST ensure that the value in Total Fragments field is really increased. This requirement should not become a problem for the sender, as PMTU discovery in IKE is supposed to be coarse-grained, so difference between previous and next fragmentation thresholds will be significant anyway. The necessity to distinguish between the sets is vital for receiver as receiving any valid fragment from newer set will mean that it have to start reassembling over and not to mix fragments from different sets." section 2.6 @@ section 2.5 states that the EFP MUST be the last payload message, but = section 2.6 specifies that it may not be the first. inconsistency? The Encrypted Fragment Payload, similarly to the Encrypted Payload, if present in a message, MUST be the last payload in the message. Note, that it is possible for this payload to be not the first (and the = only) payload in the message (see Section 2.5.3).=20 @@ please recommend a default timeout interval. If receiver doesn't get all IKE Fragment Messages needed to reassemble original Message for some Exchange within a timeout interval, it acts according with Section 2.1 of [RFC5996], i.e. retransmits the fragmented request Message (in case of Initiator) or deems Exchange to have failed.=20 --Apple-Mail=_576933E8-A5E9-4678-861F-851DC8DA5C81 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTajYLAAoJEFuJXizso86g6G0H/iHyUJwvk5wurkMJy+lgn14B UtGVmNpgio9uUukFCJZZ7Lgom2Strw4pIedMv2+/xV1dTYx8+fvR8bT/xcpDU/7p pGSA5gLcype1JW6FFPLZ+woPxWvgQlnsIIW4AcA3pz7dMd4bXA49qUgbJDy203Kg 0IIyRShscrRrLfDx9Vbe7jgnYyAUCdRP5vbO+l2sGVij9e92ndUYdXUt/ftLaemQ yqPzdyqF/fus8TIijyNjxEmL1E2CKYGqtEoDi6tQRQQlCiRPBCPnJCzOfjpp7qzI lTzLBBALD2oEY141mHMDe8rz/CjwX/YrAsHxvNXGJ9y77PfV2JXurFPLbOm9Yns= =sXht -----END PGP SIGNATURE----- --Apple-Mail=_576933E8-A5E9-4678-861F-851DC8DA5C81-- From nobody Wed May 7 23:41:35 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F36B1A05C3 for ; Wed, 7 May 2014 23:41:27 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 L2g1F73xW5py for ; Wed, 7 May 2014 23:41:19 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 07EA91A0657 for ; Wed, 7 May 2014 23:41:16 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 10so2859455lbg.2 for ; Wed, 07 May 2014 23:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NpMHSIXXMsfyKghrs3vp/YFCsi42YC2zUvwV7okYT/k=; b=PKZKWgD/wTn8rWiBSf/XL+3FOzl38yYaGvi6YZotcybpFHYF2lyXa5TNFGl5JVLPp7 yrxUxjQbgTKTZnswdI7aqjKxORbxInYFksrDg71Fv1FlptIrJXkIh0PxVMCyPuaKN6A1 p7DdG+WwySeUV0cRHnU4UH+KslmDjJxDx7N0Ayn3B5vKcqrVaDu8Ozu+EPwgbIUBdheg iL4/No+JGgFBx7X7+ZzxFBBa/htfJ4mxxxAUuCgzdG/01uw+Ac5O41lKinr38VNeFtKz yk6wXxH9yaWYcv6QJSsJv8ZqHplDTdEvvgreFH46lf3z1zsAo7hbviUpS1FZnU6adSRf J8dg== X-Received: by 10.112.180.225 with SMTP id dr1mr670739lbc.51.1399531271833; Wed, 07 May 2014 23:41:11 -0700 (PDT) Received: from [10.17.0.95] ([83.150.126.201]) by mx.google.com with ESMTPSA id q4sm97945lbh.20.2014.05.07.23.41.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 23:41:11 -0700 (PDT) Message-ID: <536B2706.4050002@gmail.com> Date: Thu, 08 May 2014 09:41:10 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: int-dir@ietf.org References: <535932BA.6010102@innovationslab.net> In-Reply-To: <535932BA.6010102@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/olYBuJi0BD6WjFSWhiQyeMJvkVY Cc: Brian Haberman Subject: Re: [Int-dir] Request for fragmentation help X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 06:41:27 -0000 Hi, I just want to point out that RADEXT is doing somewhat similar solution for a specific use case when shuffling around large chunks of authorization data. See http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-06 RADIUS' problem is the statement in the original specs to limit the packet size to 4K although the packet encoding would allow 64K packets. The above I-D is a "hack" to be compatible with deployed proxies etc that pedantically follow the 4K rule. - Jouni 4/24/2014 6:50 PM, Brian Haberman kirjoitti: > All, > We have a document that tries to develop a mechanism for > fragmenting IKEv2 messages at the application layer. There have been a > number of concerns raised and the shepherding AD is looking for help. > Is there anyone interested in helping the author/WG tighten up this > document from the fragmentation aspect? > > The document is draft-ietf-ipsecme-ikev2-fragmentation. Any > volunteers? > > Regards, > Brian > > > > _______________________________________________ > Int-dir mailing list > Int-dir@ietf.org > https://www.ietf.org/mailman/listinfo/int-dir > From nobody Thu May 8 06:06:06 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E391A064B for ; Thu, 8 May 2014 05:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.743 X-Spam-Level: X-Spam-Status: No, score=-98.743 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RP_MATCHES_RCVD=-0.651, STOX_REPLY_TYPE=0.439, USER_IN_WHITELIST=-100] autolearn=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 3afZYS_sNKSS for ; Thu, 8 May 2014 05:59:10 -0700 (PDT) Received: from bull.elvis.ru (bull.elvis.ru [93.188.44.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7621F1A064A for ; Thu, 8 May 2014 05:59:09 -0700 (PDT) Received: from robin.office.elvis.ru ([10.111.1.40]) by bull.elvis.ru with esmtp (Exim 4.76) (envelope-from ) id 1WiNue-0003Mw-CN; Thu, 08 May 2014 16:59:00 +0400 Received: from buildpc (10.111.10.31) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.3.174.1; Thu, 8 May 2014 16:59:00 +0400 Message-ID: <1D14A92EE52B4AD7B21ACAA590F8279F@buildpc> From: Valery Smyslov To: Ole Troan , , References: <5A97FAD4-3E5B-436F-84C8-D0DC2FDA5E20@employees.org> Date: Thu, 8 May 2014 16:59:06 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/Ed2n4tsYf_8GDtCKezoYGZYa_dk X-Mailman-Approved-At: Thu, 08 May 2014 06:06:03 -0700 Cc: Brian Haberman , int-dir@ietf.org Subject: Re: [Int-dir] int-dir review of draft-ietf-ipsecme-ikev2-fragmentation X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 12:59:14 -0000 Hi Ole, thank you for your review. Please, find my comments inline. > chairs, authors, > > Brian asked me as part of the int-directorate to review this document. > > > Joe Touch had some good comments on this from the transport perspective. > (http://www.ietf.org/mail-archive/web/ipsec/current/msg08653.html) > > Architecturally this opens up a larger debate. Any UDP application > protocol that depends > on IP fragmentation and doesn't do segmentation itself must be changed... > if the premise is > correct that IP fragmentation cannot work correctly. > > there are a few approaches open to us: > - consider this a bug in the network, and require that to be fixed > - start work on a replacement of UDP that supports segmentation, SCTP? > - fix the applications. > > I think this document solves a real problem. as a general recommendation I > think the document > should not re-specify Path MTU discovery. it should use RFC1981 and make > application specific > considerations referencing RFC4821 (section 9, section 10.4) > > I would recommend against recursive fragmentation. Sorry, I don't understabd what do you mean by "recursive fragmentation". If you refer to fragmenting fragments, than there is no such thing. > I would also question the need to do path MTU discovery for a protocol > that only does a few > message exchanges? at least the document should clearly point out that > there are three options > for implementations of this: > - implementations that do not do PMTUD and does use the minimum message > sizes (576/1280) > - implementations that depend on PMTUD (1191/1981) with a fallback to > minimum > - implementations that use PMTUD/PLMTUD (1191/1981/4821) with application > probes I completely agree with you here. Actually, the document tries to make exactly the same point: In most cases PMTU discovery will not be needed, as using values, recommended in section Section 2.5.1, should suffice, so there is no requirement to support PMTU discovery in IKE. However it is RECOMMENDED to be supported, especially in environments where PMTU size are smaller, than those listed in Section 2.5.1, for example due to the presence of intermediate tunnels. (note that in previous version of the draft PMTUD was marked as "MAY", but it was pointed out during IESG evaluation that "MAY" doesn't mean anything and I changed it to "RECOMMENDED", but tried to clear indicate that it is not required to implement). What about possible ways to perform PMTU discovery. Classical PMTUD (1191/1981) have some issues with connectionless protocols. Both RFCs mention, that with UDP it is often hard to get ICMP information from the kernel to the application (in Sections 5.2 and 6.2 respectively). Note also, that ICMP may be blocked or just dropped by broken network devices (as they often drop IP fragments), so it is unreliable to rely on it. Nevertheless the draft states, that if PMTU information is available, it SHOULD be used (in SEction 2.5.1). I think I can make this more explicit. And regarding PLMTUD (4821) - in fact the draft doesn't (re)invent its own way to perform PMTU discovery, actually it uses 4821 approach, wich is modified so that probing is done downward instead of upward. The reason for this modification is that probing upward with IKE is equivalent to not doing PLMTUD at all. The peculiarity of IKE is that during lifetime of IKE SA each peer sends very few large messages (if no EAP authentication is involved, then there will be one large message from each peer) and all of them are sent in the beginning of IKE SA lifetime, during SA establishment. All other messages, that are sent over IKE SA are typically less that 500 bytes (there may be few exceptions). So, if one use RFC4821 algorithm, then it starts probing from the smallest allowed MTU size. I assume here, that probing is done using application probes, as recommended in Section 10.4, and IKE Fragmentation is used to construct probes of various sizes (so, you just fragment outgoing message into IKE Fragments of desired size and send all of them, waiting for response). As you start probing from smallest fragmens, the very first probe succeeds and the IKE exchange also succeeds (it is IKE_AUTH exchange - the first and almost often the only exchange that sends large messages). As it succeds, IKE SA is established and during it lifetime there will be no large messages anymore (probably with a few exceptions), so there is no point in doind PMTUD anymore as small messages won't be fragmented anyway. As result - performing unmodified PLMTUD from 4821 in case of IKE is roughly equivavlent to not performing it at all and always using the smallest allowed MTU size. To make PLMTUD work in case of IKE the draft suggests that probing should be done downward, as they are done in classic PMTUD (1191/1981). So, we first try to fragment outgoing message into the largest allowed MTU size (link MTU) and wait for response. If no response is received after few retransmissions we assume that fragments are too large and refragment original message with smaller message size. And so on untill we get the response. If application is capable of receiving ICMP information from kernel, this approach becomes classic PMTUD, if it cannot (or if ICMP doesn't reach sender), then it takes longer, but still it works. So, I think the implementers should be given 2 options: - do not do PMTUD and does use the minimum message sizes - doing combination of PLMTUD with probing downward and PMTUD (1191/1981) (they can be combined). Doing PLMTUD with probing upward (as in 4821) is almost equivalent to the first option. > comments (marked @@) > ---------------------------------- > > > 1. Introduction: > @@ it would be good if the document made it clear that for IPv4 these NAT > devices are broken > (ref RFCXXX), and that for IPv6 throwing away fragments is an operational > choice, and it is as far > as I know no evidence that this happens on the open Internet. (it > certainly happens on network borders, > e.g. in front of services, where the operator has control and is confident > no services using fragmentation exists). > > The problem is that some network devices, > specifically some NAT boxes, don't allow IP fragments to pass > through. This apparently blocks IKE communication and, therefore, > prevents peers from establishing IPsec SA. This problem is valid for > both IPv4 and IPv6 [FRAGDROP]. How about the following text: The problem is that some network devices, specifically some NAT boxes, don't allow IP fragments to pass through. This apparently blocks IKE communication and, therefore, prevents peers from establishing IPsec SA. This problem is valid for both IPv4 and IPv6 and may be caused either by deficiency of devices [RFCXXX] or by operational choice [FRAGDROP]. And could you please recommend what RFC can be referenced as RFCXXXX? I failed to find appropriate reference. > @@ the document would benefit from a few more definite articles. (and > language review in general). > nothing that reduces understandability though. > > e.g. "Initiator may first try to send > unfragmented message and resend it fragmented only if it didn't > receive response after several retransmissions, or it may always send > messages fragmented (but see Section 3), or it may fragment only > large messages and messages causing large responses." I'm not completely sure what do you mean by "definite articles", but how about the following: Initiator may use various policies regarding using fragmentation. It may first try to send unfragmented message and fragment it only if it didn't receive response after several retransmissions. Another option is to always fragment outgoing messages (but see Section 3). Or it may fragment only large messages and messages causing large responses. > 2.4 Using IKE fragmentation > > @@ this seems a little at odds with a section full of 2119 language. > "In general the following guidelines are applicable for Initiator:" > "In general the following guidelines are applicable for Responder:" Mmm, how to make guidlines without using RFC2119 words? > @@ vague. replace with recommendation to base the decision on the link and > path MTU? OK, this is reasonable. > o Initiator MAY fragment outgoing message if it has some knowledge > (possibly from lower layer or from configuration) that either > request or response message will be fragmented by IP level or if > unfragmented message was sent and no response was received after > several retransmissions. > > o Responder MAY respond to unfragmented message with fragmented > response if it has some knowledge (possibly from lower layer or > from configuration) that response message will be fragmented by IP > level. > > @@ this section is does not define "fragmentation threshold" Good catch, thank you. I'll fix it. > 2.5. Fragmenting Message > > @@ could "fragment number" and "total fragments" be single octets? I agree that in most real life use cases 8 bits will suffice. However, the size of Length field in IKE header is 32 bits, so in theory IKE messages may be up to 4Gb in size. Currently the size of IKE message is limited to 64Kb by UDP transport, but this may change in future, and I didn't want to introduce potential bottleneck here. Note also, that making these fields 16 bits long preserves 32-bit alignment of payload data, that may be benefitical for implementation. > 2.5.1 > > @@ I'm not sure text like... adds value. > > "Sender MAY use other values if they are > appropriate." The idea is not to limit implementers with the recommended values listed above if implementation is intended to work in environment where these values are not applicable (for example, some networks with extremely low MTU - below 576 bytes). > 2.5.2 > > @@ I hope "refragment" doesn't mean that the individual fragments are > fragmented again? > but rather that the original message is fragmented into a set of smaller > fragments? > > "While doing probes, node MUST start from > larger values and refragment message with next smaller value if it > doesn't receive response in a reasonable time after several > retransmissions. " The latter: original message is fragmented into a set of smaller fragments. I can made this more explicit: While doing probes, node MUST start from larger values and refragment original message with next smaller value if it doesn't receive response in a reasonable time after several retransmissions. > @@ please give better advice. "reasonable time" is hard to implement. > "doesn't receive response in a reasonable time after" This value are related to IKE retransmission timer. And RFC5996 deliberately rejects to give any specific value for it (Section 2.4): The number of retries and length of timeouts are not covered in this specification because they do not affect interoperability. It is suggested that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up on an SA, but different environments may require different rules. To be a good network citizen, retransmission times MUST increase exponentially to avoid flooding the network and making an existing congestion situation worse. I do not think that this document should give any specific value either, but probably I need to explain this better, as well as relation to the RFC5996 timers. > @@ should also reference RFC1981 OK. > @@ oh, so it is recursive fragmentation. that makes me somewhat > uncomfortable. > > "In case of PMTU discovery Total Fragments field is used to > distinguish between different sets of fragments, i.e. the sets that > were obtained by fragmenting original message using different > fragmentation thresholds. As sender will start from larger fragments > and then make them smaller, the value in Total Fragments field will > increase with each new try. When selecting next smaller value of > fragmentation threshold, sender MUST ensure that the value in Total > Fragments field is really increased. This requirement should not > become a problem for the sender, as PMTU discovery in IKE is supposed > to be coarse-grained, so difference between previous and next > fragmentation thresholds will be significant anyway. The necessity > to distinguish between the sets is vital for receiver as receiving > any valid fragment from newer set will mean that it have to start > reassembling over and not to mix fragments from different sets." Sorry, I don't see here "recursive fragmentation". Here is an explanation of PLMTUD probing with searching downward. Fragmented messages are never fragmented again. Recursive (nested) fragmentation is not used, moreover it is impossible with this specification. > section 2.6 > > @@ section 2.5 states that the EFP MUST be the last payload message, but > section 2.6 > specifies that it may not be the first. inconsistency? > > The Encrypted Fragment Payload, similarly to the Encrypted Payload, > if present in a message, MUST be the last payload in the message. > > Note, that it is possible for this payload to be not the first (and the > only) payload in the message (see > Section 2.5.3). No inconsistency here. EFP MUST be the last payload in message - that's true. Currently in all cases it is also the first and the only payload in message. But IKE allows message construction when there are other payloads preceeding Encrypted Payload (and, therefore, Encrypted Fragment Payload) if message is intended to be only partialy encrypted. In this case EFP won't be the first and the only payload, but still will be the last. Currently no such mixture messages are defined in IKE and its extensions, but they are not prohibited and may be defined in future IKE extensions. > @@ please recommend a default timeout interval. > If receiver doesn't get all IKE Fragment Messages needed to > reassemble original Message for some Exchange within a timeout > interval, it acts according with Section 2.1 of [RFC5996], i.e. > retransmits the fragmented request Message (in case of Initiator) or > deems Exchange to have failed. Timeout interval here is the same as timeout for initiator from section 2.4 of RFC5996. And again I don't think this document should specify it as it is not specified in RFC5996. However, better explanation of what this timeout is should have been done. I think I can address most of your comments in new version of the document in a few days. However, tomorrow is a state holiday here, so it won't be probably before Tuesday. Thank you, Valery Smyslov. From nobody Thu May 15 10:57:09 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF851A0371 for ; Thu, 15 May 2014 09:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.381 X-Spam-Level: X-Spam-Status: No, score=-97.381 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_SUMOF=1, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=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 xMMknMR6Af2Y for ; Thu, 15 May 2014 09:10:25 -0700 (PDT) Received: from bull.elvis.ru (bull.elvis.ru [93.188.44.194]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207101A0573 for ; Thu, 15 May 2014 09:10:23 -0700 (PDT) Received: from robin.office.elvis.ru ([10.111.1.40]) by bull.elvis.ru with esmtp (Exim 4.76) (envelope-from ) id 1WkyES-0008B1-6r; Thu, 15 May 2014 20:10:08 +0400 Received: from buildpc (10.111.10.31) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.3.174.1; Thu, 15 May 2014 20:10:07 +0400 Message-ID: <775A362ED0B84EEB8A00553C1485144B@buildpc> From: Valery Smyslov To: Ole Troan , , References: <5A97FAD4-3E5B-436F-84C8-D0DC2FDA5E20@employees.org> Date: Thu, 15 May 2014 20:10:14 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0146_01CF7079.AEBB2DD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/ErSRGPMqUovjCj3TgTokKvYypms X-Mailman-Approved-At: Thu, 15 May 2014 10:57:07 -0700 Cc: Brian Haberman , int-dir@ietf.org Subject: Re: [Int-dir] int-dir review of draft-ietf-ipsecme-ikev2-fragmentation X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 16:10:31 -0000 ------=_NextPart_000_0146_01CF7079.AEBB2DD0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Ole, please find attached new (not yet published) version of draft-ietf-ipsecme-ikev2-fragmentation. I tried to address your concerns. Could you please tell whether you still have issues with the document or not. Regards, Valery. ----- Original Message ----- From: "Ole Troan" To: ; ; Cc: "Brian Haberman" ; Sent: Wednesday, May 07, 2014 5:32 PM Subject: int-dir review of draft-ietf-ipsecme-ikev2-fragmentation ------=_NextPart_000_0146_01CF7079.AEBB2DD0 Content-Type: text/plain; format=flowed; name="draft-ietf-ipsecme-ikev2-fragmentation-08.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ipsecme-ikev2-fragmentation-08.txt" Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS Intended status: Standards Track May 15, 2014 Expires: November 16, 2014 IKEv2 Fragmentation draft-ietf-ipsecme-ikev2-fragmentation-08 Abstract This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 16, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Smyslov Expires November 16, 2014 [Page 1] =0C Internet-Draft IKEv2 Fragmentation May 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 2. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Using IKE Fragmentation . . . . . . . . . . . . . . . . . 6 2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 7 2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 9 2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 10 2.5.3. Fragmenting Messages containing unprotected Payloads . . . . . . . . . . . . . . . . . . . . . . . 11 2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 12 2.6.1. Replay Detection and Retransmissions . . . . . . . . . 13 3. Interaction with other IKE extensions . . . . . . . . . . . . 15 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 22 Appendix B. Correlation between IP Datagram size and Encrypted Payload content size . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 Smyslov Expires November 16, 2014 [Page 2] =0C Internet-Draft IKEv2 Fragmentation May 2014 1. Introduction The Internet Key Exchange Protocol version 2 (IKEv2), specified in [IKEv2], uses UDP as a transport for its messages. Most IKEv2 messages are relatively small, usually below several hundred bytes. Noticeable exception is IKE_AUTH exchange, which requires fairly large messages, up to several kbytes, especially when certificates are transferred. When IKE message size exceeds path MTU, it gets fragmented by IP level. The problem is that some network devices, specifically some NAT boxes, don't allow IP fragments to pass through. This apparently blocks IKE communication and, therefore, prevents peers from establishing IPsec SA. Section 2 of [IKEv2] discusses the impact of IP fragmentation on IKEv2 and acknowledges this problem. Widespread deployment of Carrier-Grade NATs (CGN) introduces new challenges. RFC6888 [RFC6888] describes requirements for CGNs. It states, that CGNs must comply with Section 11 of RFC4787 [RFC4787], which requires NAT to support receiving IP fragments (REQ-14). In real life fulfillment of this requirement creates an additional burden in terms of memory, especially for high-capacity devices, used in CGNs. It was found by people deploying IKE, that more and more ISPs use equipment that drop IP fragments, violating that requirement. This problem is valid for both IPv4 and IPv6 and may be caused either by deficiency of devices or by operational choice [FRAGDROP]. The solution to the problem described in this document is to perform fragmentation of large messages by IKEv2 itself, replacing them by series of smaller messages. In this case the resulting IP Datagrams will be small enough so that no fragmentation on IP level will take place. The primary goal of this solution is to allow IKEv2 to operate in environments, that may block IP fragments. This goal doesn't assumes that IP fragmentation should be avoided completely, but only if it interferes with IKE operation. However this solution may be used to avoid IP fragmentation in all situations when it is applicable, that may be beneficial for IKEv2 in general. Security Considerations Section of [IKEv2] mentions exhausting of the IP reassembly buffers as one of possible attacks on the protocol. In the paper [DOSUDPPROT] several aspects of attacks on IKE using IP fragmentation are discussed, and one of defenses it proposes is to perform IKE fragmentation, similar to the solution, described in this document. Smyslov Expires November 16, 2014 [Page 3] =0C Internet-Draft IKEv2 Fragmentation May 2014 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Smyslov Expires November 16, 2014 [Page 4] =0C Internet-Draft IKEv2 Fragmentation May 2014 2. Protocol details 2.1. Overview The idea of the protocol is to split large IKEv2 message into a set of smaller ones, called IKE Fragment Messages. Fragmentation takes place before the original message is encrypted and authenticated, so that each IKE Fragment Message receives individual protection. On the receiving side IKE Fragment Messages are collected, verified, decrypted and merged together to get the original message before encryption. For design rationale see Appendix A. 2.2. Limitations As IKE Fragment Messages are cryptographically protected, SK_a and SK_e must already be calculated. In general, it means that original message can be fragmented if and only if it contains Encrypted Payload. This implies that messages of the IKE_SA_INIT Exchange cannot be fragmented. In most cases this is not a problem, since IKE_SA_INIT messages are usually small enough to avoid IP fragmentation. But in some cases (advertising a badly structured long list of algorithms, using large MODP Groups, etc.) these messages may become fairly large and get fragmented by IP level. In this case the described solution won't help. Among existing IKEv2 extensions, messages of IKE_SESSION_RESUME Exchange, defined in [RFC5723], cannot be fragmented either. See Section 3 for details. Another limitation is that the minimal size of IP Datagram bearing IKE Fragment Message is about 100 bytes depending on the algorithms employed. According to [RFC0791] the minimum IP Datagram size that is guaranteed not to be further fragmented is 68 bytes. So, even the smallest IKE Fragment Messages could be fragmented by IP level in some circumstances. But such extremely small PMTU sizes are very rare in real life. 2.3. Negotiation Initiator indicates its support for the IKE Fragmentation and willingness to use it by including Notification Payload of type IKEV2_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If Responder also supports this extension and is willing to use it, it includes this notification in response message. Smyslov Expires November 16, 2014 [Page 5] =0C Internet-Draft IKEv2 Fragmentation May 2014 Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni, [N(IKEV2_FRAGMENTATION_SUPPORTED)] --> <-- HDR, SAr1, KEr, Nr, [CERTREQ], [N(IKEV2_FRAGMENTATION_SUPPORTED)] The Notify payload is formatted as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protocol ID(=3D0)| SPI Size (=3D0) | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Protocol ID (1 octet) MUST be 0. o SPI Size (1 octet) MUST be 0, meaning no SPI is present. o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned for IKEV2_FRAGMENTATION_SUPPORTED by IANA. This Notification contains no data. 2.4. Using IKE Fragmentation IKE Fragmentation MUST NOT be used unless both peers have indicated support for it. After IKE Fragmentation is negotiated, it is up to the Initiator of each Exchange to decide whether to use it or not. The Responder usually replies in the same form as the request message, but other considerations might override this. The Initiator may employ various policies regarding the use of IKE Fragmentation. It may first try to send an unfragmented message and resend it as fragmented only if no complete response is received even after several retransmissions. Alternatively, it may choose always to send fragmented messages (but see Section 3), or it may fragment only large messages and messages that are expected to result in large responses. The following general guidelines apply: o If either peer has information that a part of the transaction is likely to be fragmented at the IP layer, causing interference with the IKE exchange, that peer SHOULD use IKE Fragmentation. This Smyslov Expires November 16, 2014 [Page 6] =0C Internet-Draft IKEv2 Fragmentation May 2014 information may be passed from a lower layer, provided by configuration, or derived through heuristics. Examples of heuristics are the lack of a complete response after several retransmissions for the Initiator, and receiving repeated retransmissions of the request for the Responder. o If either peer knows that IKE Fragmentation has been used in a previous exchange in the context of the current IKE SA, that peer SHOULD continue the use of IKE Fragmentation for the messages that are larger than the current fragmentation threshold (see Section 2.5.1). o IKE Fragmentation SHOULD NOT be used in cases where IP-layer fragmentation of both the request and response messages is unlikely. For example, there is no point in fragmenting Liveness Check messages. o If none of the above apply, the Responder SHOULD respond in the same form (fragmented or not) as the request message it is responding to. Note that the other guidelines might override this because of information or heuristics available to the Responder. In most cases IKE Fragmentation will be used in the IKE_AUTH Exchange, especially if certificates are employed. 2.5. Fragmenting Message Message to be fragmented MUST contain Encrypted Payload. For the purpose of IKE Fragment Messages construction original (unencrypted) content of Encrypted Payload is split into chunks. The content is treated as a binary blob and is split regardless of inner Payloads boundaries. Each of resulting chunks is treated as an original content of Encrypted Fragment Payload and is then encrypted and authenticated. Thus, the Encrypted Fragment Payload contains a chunk of the original content of Encrypted Payload in encrypted form. The cryptographic processing of Encrypted Fragment Payload is identical to Section 3.14 of [IKEv2], as well as documents updating it for particular algorithms or modes, such as [RFC5282]. The Encrypted Fragment Payload, similarly to the Encrypted Payload, if present in a message, MUST be the last payload in the message. The Encrypted Fragment Payload is denoted SKF{...} and its payload type is XXX (TBA by IANA). This payload is also called the "Encrypted and Authenticated Fragment" payload. Smyslov Expires November 16, 2014 [Page 7] =0C Internet-Draft IKEv2 Fragmentation May 2014 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment Number | Total Fragments | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initialization Vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Encrypted content ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (0-255 octets) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | Pad Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Integrity Checksum Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Encrypted Fragment Payload o Next Payload (1 octet) - in the very first fragment (with Fragment Number equal to 1) this field MUST be set to Payload Type of the first inner Payload (similarly to the Encrypted Payload). In the rest fragments MUST be set to zero. o Fragment Number (2 octets) - current fragment number starting from 1. This field MUST be less than or equal to the next field, Total Fragments. This field MUST NOT be zero. o Total Fragments (2 octets) - number of fragments original message was divided into. This field MUST NOT be zero. With PMTU discovery this field plays additional role. See Section 2.5.2 for details. The other fields are identical to those specified in Section 3.14 of [IKEv2]. When prepending IKE Header to the IKE fragment message it MUST be taken intact from the original message, except for Length and Next Payload fields. Length field is adjusted to reflect the length of the constructed message and Next Payload field is set to be the payload type of the first Payload in constructed message (in most cases it will be Encrypted Fragment Payload). After prepending IKE Header and all Payloads that possibly precede Encrypted Payload in original message (if any, see Section 2.5.3), the resulting messages are sent to the peer. Below is an example of fragmenting a message. Smyslov Expires November 16, 2014 [Page 8] =0C Internet-Draft IKEv2 Fragmentation May 2014 HDR(MID=3Dn), SK(NextPld=3DPLD1) {PLD1 ... PLDN} Original Message HDR(MID=3Dn), SKF(NextPld=3DPLD1, Frag#=3D1, TotalFrags=3Dm) {...}, HDR(MID=3Dn), SKF(NextPld=3D0, Frag#=3D2, TotalFrags=3Dm) {...}, ... HDR(MID=3Dn), SKF(NextPld=3D0, Frag#=3Dm, TotalFrags=3Dm) {...} IKE Fragment Messages 2.5.1. Selecting Fragment Size When splitting content of Encrypted Payload into chunks sender SHOULD choose their size so, that resulting IP Datagrams be smaller than some fragmentation threshold. Implementation may calculate fragmentation threshold using various sources of information. If sender has information about PMTU size it SHOULD use it. Successful completion of previous exchanges (including those exchanges, that cannot employ IKE Fragmentation, e.g. IKE_SA_INIT) MAY be an indication, that fragmentation threshold can be set to the size of the largest of already sent messages. If Responder in the Exchange has received fragmented request, it is RECOMMENDED that it uses maximum size of received IKE Fragment Message IP Datagrams as threshold when constructing fragmented response. Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use value 1280 bytes as a maximum IP Datagram size ([RFC2460]). For messages to be sent over IPv4 it is RECOMMENDED to use value 576 bytes as a maximum IP Datagram size. Presence of tunnels on the path may reduce these values. Implementation may use other values if they are appropriate in current environment. According to [RFC0791] the minimum IPv4 datagram size that is guaranteed not to be further fragmented is 68 bytes, but it is generally impossible to use such small value for solution, described in this document. Using 576 bytes is a compromise - the value is large enough for the presented solution and small enough to avoid IP fragmentation in most situations. Several other UDP-based protocol assume the value 576 bytes as a safe low limit for IP datagrams size (Syslog, DNS, etc.). See Appendix B for correlation between IP Datagram size and Encrypted Payload content size. Smyslov Expires November 16, 2014 [Page 9] =0C Internet-Draft IKEv2 Fragmentation May 2014 2.5.2. PMTU Discovery The amount of traffic that IKE endpoint produces during lifetime of IKE SA is fairly modest - usually it is below one hundred kBytes within a period of several hours. Most of this traffic consists of relatively short messages - usually below several hundred bytes. In most cases the only time when IKE endpoints exchange messages of several kBytes is IKE SA establishment and often each endpoint sends exactly one such message. These characteristics of IKE make it unattractive for using PMTU discovery. There is no requirement to implement PMTU discovery in IKE, because in most cases using the values recommended in Section 2.5.1 as fragmentation threshold will be sufficient. Using these values could lead to suboptimal fragmentation, but it is acceptable given the amount of traffic IKE produces. Implementation may support PMTU discovery if it has good reasons to do it (for example if it is intended to be used in environments with possible MTU sizes less that values listed in Section 2.5.1 or if it uses IKE SA to transfer data and doesn't want to waste network resources). PMTU discovery in IKE follows recommendations given in Section 10.4 of [RFC4821] with one difference, induced by the specialties of IKE listed above. The difference is that search is performed largest value downward, while in [RFC4821] search is performed starting from the smallest supported value upward. The reason for this change is that IKE usually sends large messages only when IKE SA is being established and in many cases there is only one such message. With probing upward this message will be fragmented using the smallest threshold, and usually all other messages are small enough to avoid IP fragmentation, so there is no need to probe more. It is the Initiator of exchange, who performs PMTU discovery. If PMTU discovery is supported, it may be performed in every exchange, that uses IKE Fragmentation. PMTU discovery is done by probing several values of fragmentation threshold. While doing probes, node MUST start from larger values and refragment original message using next smaller value of fragmentation threshold if it doesn't receive response in a reasonable time after several retransmissions. The exact number of retransmissions and length of timeouts are not covered in this specification because they do not affect interoperability. However, the timeout interval is supposed to be relatively short, so that unsuccessful probes not delay IKE operations too much. The value of several seconds for one probe seems appropriate, but different environments may require different rules. When starting new probe node MUST reset its retransmission timers so, that if it employs exponential back-off, the timers start over. After reaching the smallest allowed value for fragmentation Smyslov Expires November 16, 2014 [Page 10] =0C Internet-Draft IKEv2 Fragmentation May 2014 threshold implementation MUST continue probing until either exchange completes or times out using timeout interval from Section 2.4 of [IKEv2]. PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is expected, that node will try only few fragmentation thresholds, in order to minimize delays. It may also utilize classic PMTU discovery methods, described in [RFC1191] and [RFC1981]. In particular, if implementation is capable to receive ICMP error messages and if it receives Packet Too Big error in response to the probe, and it contains smaller value, than current fragmentation threshold, then Initiator SHOULD stop retransmitting and SHOULD select new value for fragmentation threshold that is less or equal to the value from the ICMP message and satisfies the requirements listed below. In case of PMTU discovery Total Fragments field is used to distinguish between different sets of fragments, i.e. the sets that were obtained by fragmenting original message using different fragmentation thresholds. As sender will start from larger fragments and then make them smaller, the value in Total Fragments field will increase with each new probe. When selecting next smaller value for fragmentation threshold, sender MUST ensure that the value in Total Fragments field is really increased. This requirement should not be a problem for the sender, as PMTU discovery in IKE is supposed to be coarse-grained, so difference between previous and next fragmentation thresholds will be significant anyway. The necessity to distinguish between the sets is vital for receiver as receiving any valid fragment from newer set will mean that it have to start reassembling over and not to mix fragments from different sets. 2.5.3. Fragmenting Messages containing unprotected Payloads Currently there are no IKEv2 Exchanges that define messages, containing both unprotected payloads and payloads, protected by Encrypted Payload. However IKEv2 doesn't prohibit such construction. If some future IKEv2 extension defines such a message and it needs to be fragmented, all unprotected payloads MUST be placed in the first fragment (with Fragment Number field equal to 1), along with Encrypted Fragment Payload, which MUST be present in every IKE Fragment Message and be the last payload in it. Below is an example of fragmenting message, containing both protected and unprotected Payloads. HDR(MID=3Dn), PLD0, SK(NextPld=3DPLD1) {PLD1 ... PLDN} Original Message Smyslov Expires November 16, 2014 [Page 11] =0C Internet-Draft IKEv2 Fragmentation May 2014 HDR(MID=3Dn), PLD0, SKF(NextPld=3DPLD1, Frag#=3D1, TotalFrags=3Dm) = {...}, HDR(MID=3Dn), SKF(NextPld=3D0, Frag#=3D2, TotalFrags=3Dm) {...}, ... HDR(MID=3Dn), SKF(NextPld=3D0, Frag#=3Dm, TotalFrags=3Dm) {...} IKE Fragment Messages Note that the size of each IP Datagram bearing IKE Fragment Messages should not exceed fragmentation threshold, including the first one, that contains unprotected Payloads. This will reduce the size of Encrypted Fragment Payload content in the first IKE Fragment Message to accommodate all unprotected Payloads. In extreme case Encrypted Fragment Payload will contain no data, but it still must be present in the message, because only its presence allows receiver to determine that sender have used IKE Fragmentation. 2.6. Receiving IKE Fragment Message Receiver identifies IKE Fragment Message by the presence of Encrypted Fragment Payload in it. In most cases it will be the first and the only payload in the message, however this may not be true for some hypothetical IKE exchanges (see Section 2.5.3) Upon receiving IKE Fragment Message the following actions are performed: o Check message validity - in particular, check whether values of Fragment Number and Total Fragments in Encrypted Fragment Payload are valid. The following tests need to be performed. * check that Fragment Number and Total Fragments fields are non- zero * check that Fragment Number field is less than or equal to Total Fragments field * if reassembling has already started, check that Total Fragments field is equal to or greater than Total Fragments field in fragments that have already been stored in reassembling queue If any of this tests fails message MUST be silently discarded. o Check, that this IKE Fragment Message is new for the receiver and not a replay. If IKE Fragment message with the same Message ID, same Fragment Number and same Total Fragments fields was already received and successfully processed, this message is considered a replay and MUST be silently discarded. Smyslov Expires November 16, 2014 [Page 12] =0C Internet-Draft IKEv2 Fragmentation May 2014 o Verify IKE Fragment Message authenticity by checking ICV in Encrypted Fragment Payload. If ICV check fails message MUST be silently discarded. o If reassembling isn't finished yet and Total Fragments field in received fragment is greater than this field in fragments, that are in reassembling queue, receiver MUST discard all received fragments and start reassembling over with just received IKE Fragment Message. o Store message in the reassembling queue waiting for the rest of fragments to arrive. When all IKE Fragment Messages (as indicated in the Total Fragments field) are received, decrypted content of all Encrypted Fragment Payloads is merged together to form content of original Encrypted Payload, and, therefore, along with IKE Header and unprotected Payloads (if any), original message. Then it is processed as if it was received, verified and decrypted as regular IKE message. If receiver doesn't get all IKE fragments needed to reassemble original Message within a timeout interval, it MUST discard all received so far IKE Fragment Messages for the Exchange. Next actions depend on the role of receiver in the Exchange. o The Initiator acts as described in Section 2.1 of [IKEv2]. It either retransmits the fragmented request Message or deems IKE SA to have failed and deletes it. The number of retransmits and length of timeouts for the Initiator are not covered in this specification as they are assumed to be the same as in regular IKEv2 exchange (without IKE Fragmentation), which are discussed in Section 2.4 of [IKEv2]. o The Responder in this case acts as if no request message was received. In particular, it MUST NOT treat inability to reassemble request as an IKE SA failure and delete it. The reassembling timeout for Responder is RECOMMENDED to be equal to the time interval that implementation waits before completely giving up when acting as Initiator of exchange. Section 2.4 of [IKEv2] gives recommendations for selecting this interval. Implementation may use shorter timeout to conserve memory usage. 2.6.1. Replay Detection and Retransmissions According to [IKEv2] IKEv2 must reject message with the same Message ID as it has seen before (taking into consideration Response bit). This logic has already been updated by [RFC6311], which deliberately allows any number of messages with zero Message ID. This document Smyslov Expires November 16, 2014 [Page 13] =0C Internet-Draft IKEv2 Fragmentation May 2014 also updates this logic. If message contains Encrypted Fragment Payload, the values of Fragment Number and Total Fragments fields from this payload MUST be used along with Message ID to detect retransmissions and replays. Receiving retransmitted fragment of request by Responder MUST trigger retransmission of response only if Fragment Number field is 1 and MUST be ignored otherwise. If Initiator has received some (but not all) of response fragments, it MAY retransmit only the first of request fragments (namely with Fragment Number field equal to 1). Smyslov Expires November 16, 2014 [Page 14] =0C Internet-Draft IKEv2 Fragmentation May 2014 3. Interaction with other IKE extensions IKE Fragmentation is compatible with most of IKE extensions, such as IKE Session Resumption [RFC5723], Quick Crash Detection Method [RFC6290] and so on. It neither affect their operation, nor is affected by them. It is believed that IKE Fragmentation will also be compatible with future IKE extensions, if they follow general principles of formatting, sending and receiving IKE messages, described in [IKEv2]. When IKE Fragmentation is used with IKE Session Resumption [RFC5723], messages of IKE_SESSION_RESUME Exchange cannot be fragmented as they don't contain Encrypted Payload. These messages may be large due to the ticket size. To avoid IP Fragmentation in this situation it is recommended to use smaller tickets, e.g. by utilizing "ticket by reference" approach instead of "ticket by value". One exception that requires a special care is [RFC6311] - Protocol Support for High Availability of IKEv2/IPsec. As it deliberately allows any number of synchronization Exchanges to have the same Message ID, namely zero, standard IKEv2 replay detection logic, based on checking Message ID is not applicable for such messages, and receiver has to check message content to detect replays. When implementing IKE Fragmentation along with [RFC6311], IKE Message ID Synchronization messages MUST NOT be sent fragmented to simplify receiver's task of detecting replays. Fortunately, these messages are small and there is no point in fragmenting them anyway. Smyslov Expires November 16, 2014 [Page 15] =0C Internet-Draft IKEv2 Fragmentation May 2014 4. Transport Considerations With IKE Fragmentation if any single IKE Fragment Message get lost, receiver becomes unable to reassemble original Message. So, in general, using IKE Fragmentation implies higher probability for the Message not to be delivered to the peer. Although in most network environments the difference will be insignificant, on some lossy networks it may become noticeable. When using IKE Fragmentation implementations MAY use longer timeouts and do more retransmits before considering peer dead. Note that Fragment Messages are not individually acknowledged. The response Fragment Messages are sent back all together only when all fragments of request are received, the original request Message is reassembled and successfully processed. Smyslov Expires November 16, 2014 [Page 16] =0C Internet-Draft IKEv2 Fragmentation May 2014 5. Security Considerations Most of the security considerations for IKE Fragmentation are the same as those for the base IKEv2 protocol described in [IKEv2]. This extension introduces Encrypted Fragment Payload to protect content of IKE Message Fragment. This allows receiver to individually check authenticity of fragments, thus protecting peers from DoS attack. Security Considerations Section of [IKEv2] mentions possible attack on IKE by exhausting of the IP reassembly buffers. The mechanism, described in this document, allows IKE to avoid IP fragmentation and therefore increases its robustness to DoS attacks. The following attack is possible with IKE Fragmentation. An attacker can initiate IKE_SA_INIT exchange, complete it, compute SK_a and SK_e and then send a large, but still incomplete, set of IKE_AUTH fragments. These fragments will pass the ICV check and will be stored in reassembly buffers, but as the set is incomplete, the reassembling will never succeed and eventually will time out. If the set is large, this attack could potentially exhaust the receiver's memory resources. To mitigate the impact of this attack, it is RECOMMENDED that receiver limits the number of fragments it stores in reassembling queue so that the sum of the sizes of Encrypted Fragment Payload contents (after decryption) for fragments that are already placed into reassembling queue be less than some value that is reasonable for the implementation. If the peer sends so many fragments, that the above condition is not met, the receiver can consider this situation to be either attack or as broken sender implementation. In either case, the receiver SHOULD drop the connection and discard all the received fragments. This value can be predefined, can be a configurable option, or can be calculated dynamically depending on receiver's memory load. In any case, the value SHOULD NOT exceed 64 Kbytes (the maximum size of UDP datagram) because any IKE message before fragmentation must be shorter than that. Smyslov Expires November 16, 2014 [Page 17] =0C Internet-Draft IKEv2 Fragmentation May 2014 6. IANA Considerations This document defines new Payload in the "IKEv2 Payload Types" registry: Encrypted and Authenticated Fragment SKF This document also defines new Notify Message Types in the "Notify Message Types - Status Types" registry: IKEV2_FRAGMENTATION_SUPPORTED Smyslov Expires November 16, 2014 [Page 18] =0C Internet-Draft IKEv2 Fragmentation May 2014 7. Acknowledgements The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters, Yaron Sheffer, Joe Touch, Derek Atkins, Ole Troan and others for their reviews and valuable comments. Thanks to Paul Hoffman and Barry Leiba for improving text clarity. Smyslov Expires November 16, 2014 [Page 19] =0C Internet-Draft IKEv2 Fragmentation May 2014 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [IKEv2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-03 (work in progress), April 2014. [RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D. Zhang, "Protocol Support for High Availability of IKEv2/ IPsec", RFC 6311, July 2011. 8.2. Informative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008. [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010. [RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick Crash Detection Method for the Internet Key Exchange Smyslov Expires November 16, 2014 [Page 20] =0C Internet-Draft IKEv2 Fragmentation May 2014 Protocol (IKE)", RFC 6290, June 2011. [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013. [FRAGDROP] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, M., and T. Taylor, "Why Operators Filter Fragments and What It Implies", draft-taylor-v6ops-fragdrop-02 (work in progress), December 2013. [DOSUDPPROT] Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS protection for UDP-based protocols", ACM Conference on Computer and Communications Security, October 2003. Smyslov Expires November 16, 2014 [Page 21] =0C Internet-Draft IKEv2 Fragmentation May 2014 Appendix A. Design rationale The simplest approach to the IKE fragmentation would have been to fragment message that is fully formed and ready to be sent. But if message got fragmented after being encrypted and authenticated, this could open a possibility for a simple Denial of Service attack. The attacker could infrequently emit forged but valid looking fragments into the network, and some of these fragments would be fetched by receiver into the reassembling queue. Receiver could not distinguish forged fragments from valid ones and could only determine that some of received fragments were forged when the whole message got reassembled and check for its authenticity failed. To prevent this kind of attack and also to reduce vulnerability to some other kinds of DoS attacks it was decided to make fragmentation before applying cryptographic protection to the message. In this case each Fragment Message becomes individually encrypted and authenticated, that allows receiver to determine forged fragments and not to store them in the reassembling queue. Smyslov Expires November 16, 2014 [Page 22] =0C Internet-Draft IKEv2 Fragmentation May 2014 Appendix B. Correlation between IP Datagram size and Encrypted Payload content size For IPv4 Encrypted Payload content size is less than IP Datagram size by the sum of the following values: o IPv4 header size (typically 20 bytes, up to 60 if IP options are present) o UDP header size (8 bytes) o non-ESP marker size (4 bytes if present) o IKE Header size (28 bytes) o Encrypted Payload header size (4 bytes) o IV size (varying) o padding and its size (at least 1 byte) o ICV size (varying) The sum may be estimated as 61..105 bytes + IV + ICV + padding. For IPv6 Encrypted Payload content size is less than IP Datagram size by the sum of the following values: o IPv6 header size (40 bytes) o IPv6 extension headers (optional, size varies) o UDP header size (8 bytes) o non-ESP marker size (4 bytes if present) o IKE Header size (28 bytes) o Encrypted Payload header size (4 bytes) o IV size (varying) o padding and its size (at least 1 byte) o ICV size (varying) If no extension header is present, the sum may be estimated as 81..85 bytes + IV + ICV + padding. If extension headers are present, the Smyslov Expires November 16, 2014 [Page 23] =0C Internet-Draft IKEv2 Fragmentation May 2014 payload content size is further reduced by the sum of the size of the extension headers. The length of each extension header can be calculated as 8 * (Hdr Ext Len) bytes except for the fragment header which is always 8 bytes in length. Smyslov Expires November 16, 2014 [Page 24] =0C Internet-Draft IKEv2 Fragmentation May 2014 Author's Address Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation Phone: +7 495 276 0211 Email: svan@elvis.ru Smyslov Expires November 16, 2014 [Page 25] =0C ------=_NextPart_000_0146_01CF7079.AEBB2DD0-- From nobody Thu May 29 02:34:42 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3291A03E3 for ; Thu, 29 May 2014 02:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 TdnPx6kUs-WJ for ; Thu, 29 May 2014 02:34:39 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06F21A0273 for ; Thu, 29 May 2014 02:34:39 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 13B811B81DD for ; Thu, 29 May 2014 02:34:36 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 091CF19005C for ; Thu, 29 May 2014 02:34:36 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 02:34:29 -0700 From: Ted Lemon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 May 2014 05:34:28 -0400 References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> To: Message-ID: <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/JGf0QbDRno007kPpSVbRa-DrzBk Subject: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 09:34:41 -0000 I know there are several people on the internet area directorate who are = knowledgable about LLNs. Can you take a look at this message and = respond particularly to question 1? You can respond to me rather than = to the list if you prefer not to get involved in the ensuing flame war. Thanks! Begin forwarded message: > From: "Liubing (Leo)" > Subject: [v6ops] ULA #3 NPTv6 Use Case > Date: May 29, 2014 at 4:28:50 AM GMT-4 > To: v6ops WG > Cc: "v6ops-chairs@tools.ietf.org" >=20 > Hi, All >=20 > We're going to update the ULA draft. Before making a new version, I = think it would be helpful to confirm/discuss several important topics = which were discussed in last IETF meeting.=20 >=20 > I'd like to discuss the topics in different mail threads respectively. > (Current draft link: = http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02) > = **************************************************************************= **** >=20 > #3 NPTv6 Use Case >=20 > In current draft Section 3.2.1, there is an NPTv6 use case: > "In some very constrained situations(for example, in the sensors), = the > network needs ULA as the on-demand and stable addressing which > doesn't need much code to support address assignment mechanisms like > DHCP or full ND (Note: surely it needs SLAAC). If the network also > needs to connect to the outside, then there can be an NPTv6 gateway > which is not subject to extreme resource constraints. Especially = when > a lightweight isolated network needs to add Internet connectivity, > this is quite a straightforward and efficient way." >=20 > This use case is not based on real experience, but an assumption that = supporting multiple prefixes might be a heavy burden for some = resource-constrained nodes such as sensors. Because it needs to store = multiple addresses and dealing with the address selection problem. >=20 > Question 1: > In last IETF meeting, Lorenzo questioned this assumption whether it is = reasonable. I'd like to hear opinions from you on this issue. If it's = unreasonable, we'll move the use case out of the draft. >=20 > Question 2: > Besides the resource-constrained use case. There is another case which = was raised by Alex and has been talked a lot in 6man two months ago: one = node is assigned a /64, and it is the gateway of multi-subnets. This = might probably happen in the 3GPP terminals. 3GPP R11 supports DHCP-PD, = but former specifications only support /64. Current networks just = haven't implemented R11.=20 > Besides DHCP-PD, another solution for the multi-subnets is bridging = them at L2. But it is not feasible in some situations. For example, In a = vehicle there might be numerous incompatible L2s. >=20 > I think it is a reasonable use case to be documented. >=20 > Question 3: > This question is derived from Question 2. Current draft only refers = NPTv6, but might been other IPv6 NAT implementations available in the = vehicle/IoT networks. Shall we expand the "ULA+NPTv6" case to a generic = "ULA+IPv6 NAT" ? (Note: NPTv6 is the only standardized IPv6 NAT = mechanism so far) . >=20 > Regards, > Bing >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu May 29 06:03:05 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECB91A08FB for ; Thu, 29 May 2014 06:03:03 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 VNH6KJNv_DYy for ; Thu, 29 May 2014 06:03:00 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEC61A08EE for ; Thu, 29 May 2014 06:03:00 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so810414qgd.15 for ; Thu, 29 May 2014 06:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RGeSQpsD03+oHAEZMCugQTBLgu0RcBcW49EpZw50qZA=; b=ZB9BzMuikSK62X7ZXnwvhMUhdfinwBsNnNOTvvogtFO2tL9nBRk+7wjYumsgW6rGbN KoqurgjZ5yEYSfsT4iROUHvz0I0tmjUm1+HfbHoa0I5ITIH2HQm0hSys72hzRhFcHhgT 8Hof9HJD6ufH/HOn8W69qiVY6zVO5BXziwSPWBi8XSTiKt6mjhIdEImJufOfdg5momKf udLac0hWLvAV7fH+rCygk0RKrZuSzfDN+zC95P+YEgMNN6xBVesZbzuqj/MAaz1JenIl Ek/qaSGkRuujv08VeIMw+ANn/4sX5JoHW9CnByGrf39xBEejyMtuuIGwuo0fQgPuWRto jNAA== X-Received: by 10.140.98.234 with SMTP id o97mr9472110qge.35.1401368576295; Thu, 29 May 2014 06:02:56 -0700 (PDT) Received: from [10.86.252.71] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id a42sm338872qge.35.2014.05.29.06.02.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 06:02:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ralph Droms In-Reply-To: <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> Date: Thu, 29 May 2014 09:02:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> To: Lemon Ted X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/_NBxlrCO3HIEIlGtaOMyzukrKQM Cc: int-dir@ietf.org Subject: Re: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:03:03 -0000 Off the top of my head reaction. On May 29, 2014, at 5:34 AM 5/29/14, Ted Lemon = wrote: > I know there are several people on the internet area directorate who = are knowledgable about LLNs. Can you take a look at this message and = respond particularly to question 1? You can respond to me rather than = to the list if you prefer not to get involved in the ensuing flame war. >=20 > Thanks! >=20 > Begin forwarded message: >=20 >> From: "Liubing (Leo)" >> Subject: [v6ops] ULA #3 NPTv6 Use Case >> Date: May 29, 2014 at 4:28:50 AM GMT-4 >> To: v6ops WG >> Cc: "v6ops-chairs@tools.ietf.org" >>=20 >> Hi, All >>=20 >> We're going to update the ULA draft. Before making a new version, I = think it would be helpful to confirm/discuss several important topics = which were discussed in last IETF meeting.=20 >>=20 >> I'd like to discuss the topics in different mail threads = respectively. >> (Current draft link: = http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02) >> = **************************************************************************= **** >>=20 >> #3 NPTv6 Use Case >>=20 >> In current draft Section 3.2.1, there is an NPTv6 use case: >> "In some very constrained situations(for example, in the sensors), = the >> network needs ULA as the on-demand and stable addressing which >> doesn't need much code to support address assignment mechanisms like >> DHCP or full ND (Note: surely it needs SLAAC). I honestly don't see the relationship between ULA and DHCP/full ND. Use = of a ULA *might* avoid "re-prefixing" (a subset of renumbering), but is, = as far as I can tell, orthogonal to the assignment of addresses *within* = a ULA or global prefix. I think what they really mean is "re-prefixing", which the use of a ULA = can avoid. >> If the network also >> needs to connect to the outside, then there can be an NPTv6 gateway >> which is not subject to extreme resource constraints. Especially when >> a lightweight isolated network needs to add Internet connectivity, >> this is quite a straightforward and efficient way." >>=20 >> This use case is not based on real experience, but an assumption that = supporting multiple prefixes might be a heavy burden for some = resource-constrained nodes such as sensors. Because it needs to store = multiple addresses and dealing with the address selection problem. >>=20 >> Question 1: >> In last IETF meeting, Lorenzo questioned this assumption whether it = is reasonable. I'd like to hear opinions from you on this issue. If it's = unreasonable, we'll move the use case out of the draft. I don't know of any real-world specifications (my in-depth experience is = in ZigBee-IP and Wi-SUN FAN) that specify the use of ULAs to avoid the = stack complexity of dealing with multiple prefixes. If I recall = correctly (and the Wi-SUN FAN spec is still under development), those = specs support the use of ULAs for disconnected operation and security = through address isolation but not in combination with NPTv6 for = simplicity. Having worked through parts an implementation for a = constrained device, multiple prefixes don't seem to be a major source of = complexity. That is, the stack certainly needs extra code and data = space to deal with multiple prefixes. However, that extra complexity is = dwarfed by, say, RPL. >> Question 2: >> Besides the resource-constrained use case. There is another case = which was raised by Alex and has been talked a lot in 6man two months = ago: one node is assigned a /64, and it is the gateway of multi-subnets. = This might probably happen in the 3GPP terminals. 3GPP R11 supports = DHCP-PD, but former specifications only support /64. Current networks = just haven't implemented R11.=20 >> Besides DHCP-PD, another solution for the multi-subnets is bridging = them at L2. But it is not feasible in some situations. For example, In a = vehicle there might be numerous incompatible L2s. >>=20 >> I think it is a reasonable use case to be documented. Is this scenario correct? Is there a version of 3GPP that assigns a = single /64, perhaps shared by the upstream link and anything downstream = of the 3GPP device? I think the scenario needs to be checked for = correctness. In any event, I could imagine use of a ULA downstream from the = hypothetical device that has a single /64 for local networks. I don't = know if that use case is officially specified anywhere. >>=20 >> Question 3: >> This question is derived from Question 2. Current draft only refers = NPTv6, but might been other IPv6 NAT implementations available in the = vehicle/IoT networks. Shall we expand the "ULA+NPTv6" case to a generic = "ULA+IPv6 NAT" ? (Note: NPTv6 is the only standardized IPv6 NAT = mechanism so far) . No. Under no circumstances should the IETF document anything regarding = IPv6 NAT, beyond NPTv6. - Ralph >>=20 >> Regards, >> Bing >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > Int-dir mailing list > Int-dir@ietf.org > https://www.ietf.org/mailman/listinfo/int-dir From nobody Thu May 29 06:13:57 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039D01A08F6 for ; Thu, 29 May 2014 06:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 cMUFJqeHkb6e for ; Thu, 29 May 2014 06:13:52 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078B81A08EB for ; Thu, 29 May 2014 06:13:51 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 727391B81EF for ; Thu, 29 May 2014 06:13:47 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 0084419005C; Thu, 29 May 2014 06:13:47 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 06:13:47 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Thu, 29 May 2014 09:13:45 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> To: Ralph Droms X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/w3oSGSBNB8U76ZB8yZMuovWZojk Cc: int-dir@ietf.org Subject: Re: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:13:55 -0000 On May 29, 2014, at 9:02 AM, Ralph Droms wrote: > I don't know of any real-world specifications (my in-depth experience = is in ZigBee-IP and Wi-SUN FAN) that specify the use of ULAs to avoid = the stack complexity of dealing with multiple prefixes. If I recall = correctly (and the Wi-SUN FAN spec is still under development), those = specs support the use of ULAs for disconnected operation and security = through address isolation but not in combination with NPTv6 for = simplicity. Having worked through parts an implementation for a = constrained device, multiple prefixes don't seem to be a major source of = complexity. That is, the stack certainly needs extra code and data = space to deal with multiple prefixes. However, that extra complexity is = dwarfed by, say, RPL. OK, thanks. This is very helpful. From nobody Thu May 29 11:37:24 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143F31A049E for ; Thu, 29 May 2014 11:37:23 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 2LIrYzjZ1lCU for ; Thu, 29 May 2014 11:37:21 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD06B1A01B6 for ; Thu, 29 May 2014 11:37:21 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rp16so792938pbb.6 for ; Thu, 29 May 2014 11:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0j2sWLAePhvqcWwRd8gupOZqxMD8PQcMM/iJTiY9IEk=; b=KKW/U0sHc680cq5m43J46OqfyiTiMq14TW1XgEa6B5H9nvbJnVboonX7+i73CYntl8 wp/5zIr1VpNWBX/EsEY/yjF2/+IVCWmkvicWVmrGUFr5PpeJVYe6fvIJHobCHwncUEmk XZ5AddUYmX2UDfht/8BafafI0i9feDCx6ylq2aExE95fvMxXAQ25LYqjDnpW+OhKuAPF Z5ugf+vIhC+qVYa9S0/5pkXWVKwzF6cJLK2M4ocpv7vbI7DCUBE6l7sbBf022iB/sl8X 0R1PBASsAgHg3je+s7okm4DPtf5I1V0XXx7ug7258o/9ybxACdJOhrdjuUMHcL5tsbfI BfJQ== X-Received: by 10.68.134.198 with SMTP id pm6mr11272667pbb.9.1401388637772; Thu, 29 May 2014 11:37:17 -0700 (PDT) Received: from [10.16.10.192] ([216.31.219.19]) by mx.google.com with ESMTPSA id xz7sm6710158pac.3.2014.05.29.11.37.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 11:37:16 -0700 (PDT) Message-ID: <53877E5B.2020602@gmail.com> Date: Thu, 29 May 2014 21:37:15 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ralph Droms , Lemon Ted References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/5bJ8gDmbfPzDOSI3yePO5tAgIAw Cc: int-dir@ietf.org Subject: Re: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 18:37:23 -0000 >>> Question 2: >>> Besides the resource-constrained use case. There is another case which was raised by Alex >>> and has been talked a lot in 6man two months ago: one node is assigned a /64, and it is the >>> gateway of multi-subnets. This might probably happen in the 3GPP terminals. 3GPP R11 supports >>> DHCP-PD, but former specifications only support /64. Current networks just haven't implemented >>> R11. Besides DHCP-PD, another solution for the multi-subnets is bridging them at L2. But it >>> is not feasible in some situations. For example, In a vehicle there might be numerous >>> incompatible L2s. >>> >>> I think it is a reasonable use case to be documented. > > Is this scenario correct? Is there a version of 3GPP that assigns a single /64, perhaps > shared by the upstream link and anything downstream of the 3GPP device? I think the scenario > needs to be checked for correctness. All releases of 3GPP assign a single /64 to the mobile handlset (per PDN Connection - theoretically a device may have max 11 /64s assigned this way). The sharing of that same prefix to downstream LAN(s) is _not_ in any spec but definitely doable as an implementation hack in the mobile handset without breaking things. There is actually a draft that sidetracks this: draft-ietf-v6ops-64share-10 DHCPv6-PD is, btw, rel-10 feature, not rel-11. - Jouni From nobody Thu May 29 12:12:03 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633321A01D5 for ; Thu, 29 May 2014 12:12:01 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 NbrYhrQtnDsR for ; Thu, 29 May 2014 12:11:59 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780F31A017E for ; Thu, 29 May 2014 12:11:59 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id q107so2321617qgd.24 for ; Thu, 29 May 2014 12:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+Xl0rhHRhQ3UTGgLur4+6TdBx9i3569FfjkaD0/ZJWY=; b=afzW/UayZ6OVgkJs0Wh1zaGBLpKqo2axESoVyGncGAiSqC3CYRfZM99Sakk+29tr/f rZLJMsxv9ctvw1kBhKGQmlCOvbbTgNxjs+kxD5mP/yBNEMNSnTuo7i/x2H6P8gWhzdGU QrdIHGkACh9kqSU7F/anN8Nk8iGXUrdFu5iQYuK5xqP+bHVQbJ76LricN8ha6L5dmNcS hV7wc0SfX2YOj5PKMlhM2cNmrOBYXJbKPY3uplIE5+nfq40XG794txMcrh92MUs8+p/C YY7LDkMrzp8p3FMt5ANwqophyg2iMlWz4vCqZ/0hziRIMDVRCQTClEdUEfRmztMBS4cs 1z6w== X-Received: by 10.140.91.161 with SMTP id z30mr12410120qgd.65.1401390715025; Thu, 29 May 2014 12:11:55 -0700 (PDT) Received: from bxb-vpn3-994.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id a13sm912857qgf.38.2014.05.29.12.11.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 12:11:52 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ralph Droms In-Reply-To: <53877E5B.2020602@gmail.com> Date: Thu, 29 May 2014 15:11:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> <53877E5B.2020602@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/AHcURKkkTr_sr7XTjHboaVgHPy4 Cc: Lemon Ted , int-dir@ietf.org Subject: Re: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 19:12:01 -0000 On May 29, 2014, at 2:37 PM 5/29/14, Jouni Korhonen = wrote: >>>> Question 2: >>>> Besides the resource-constrained use case. There is another case = which was raised by Alex >>>> and has been talked a lot in 6man two months ago: one node is = assigned a /64, and it is the >>>> gateway of multi-subnets. This might probably happen in the 3GPP = terminals. 3GPP R11 supports >>>> DHCP-PD, but former specifications only support /64. Current = networks just haven't implemented >>>> R11. Besides DHCP-PD, another solution for the multi-subnets is = bridging them at L2. But it >>>> is not feasible in some situations. For example, In a vehicle there = might be numerous >>>> incompatible L2s. >>>>=20 >>>> I think it is a reasonable use case to be documented. >>=20 >> Is this scenario correct? Is there a version of 3GPP that assigns a = single /64, perhaps > > shared by the upstream link and anything downstream of the 3GPP = device? I think the scenario > > needs to be checked for correctness. >=20 > All releases of 3GPP assign a single /64 to the mobile handlset (per = PDN Connection - theoretically a device may have max 11 /64s assigned = this way). The sharing of that same prefix to downstream LAN(s) is _not_ = in any spec but definitely doable as an implementation hack in the = mobile handset without breaking things. >=20 > There is actually a draft that sidetracks this: = draft-ietf-v6ops-64share-10 >=20 > DHCPv6-PD is, btw, rel-10 feature, not rel-11. OK, thanks. And, to be clear, looking ahead to question 3 ... subnetted ULA+NPTv6 = does *not* apply in the 3GPP-/64 case, right? NPTv6 doesn't allow = multiple ULA /64s to be mapped into a single GUA /64? - Ralph >=20 > - Jouni From nobody Thu May 29 13:06:26 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E491A0644 for ; Thu, 29 May 2014 13:06:24 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 im727tEAu1XX for ; Thu, 29 May 2014 13:06:23 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F791A0666 for ; Thu, 29 May 2014 13:06:07 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id w10so108768pde.0 for ; Thu, 29 May 2014 13:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fPCV6kwf3auCEwNXCk0Q5EGYc5MxpADcMAWqGpVUym0=; b=tNP51l0aVJ17lM/7vNLwE+uTwBTDjFIgA/HUTDHlXMe5g9Vvr7gzwvRoXY0KpDiCng 4ZUQKhJDUlNLpsakwmXxz9EAivaAqSqkvbOtF2QPrtk7aB+9c6Rt6ASRdvmfCHNtZatH 5eF3wzZw0Oi7GGgBcoVyhFqsAKynI82uJyRG2e5j05KiPUwGvJE1eDglCee8sfFGzjbm 7zpajPKR6IAgYA9jXC70bObvFwa0VpIxMf7NNEFLUux6t62CocXhApwv1PyEy9D3VMcT HSscF7ZxBmg4M36mzxHHIgbJnCeQ+WE/KPiRlj1/T9XBfsT1PqIfTRRMC7XBDJ0DqblG qQTw== X-Received: by 10.66.226.172 with SMTP id rt12mr11748232pac.101.1401393962299; Thu, 29 May 2014 13:06:02 -0700 (PDT) Received: from [10.16.10.192] ([216.31.219.19]) by mx.google.com with ESMTPSA id zv3sm7526552pab.20.2014.05.29.13.06.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 13:06:01 -0700 (PDT) Message-ID: <53879327.40401@gmail.com> Date: Thu, 29 May 2014 23:05:59 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Ralph Droms References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> <53877E5B.2020602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/4Fjeq7XMF4vM0is74WJ8KA6nX9o Cc: Lemon Ted , int-dir@ietf.org Subject: Re: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:06:24 -0000 5/29/2014 10:11 PM, Ralph Droms kirjoitti: > > On May 29, 2014, at 2:37 PM 5/29/14, Jouni Korhonen wrote: > >>>>> Question 2: >>>>> Besides the resource-constrained use case. There is another case which was raised by Alex >>>>> and has been talked a lot in 6man two months ago: one node is assigned a /64, and it is the >>>>> gateway of multi-subnets. This might probably happen in the 3GPP terminals. 3GPP R11 supports >>>>> DHCP-PD, but former specifications only support /64. Current networks just haven't implemented >>>>> R11. Besides DHCP-PD, another solution for the multi-subnets is bridging them at L2. But it >>>>> is not feasible in some situations. For example, In a vehicle there might be numerous >>>>> incompatible L2s. >>>>> >>>>> I think it is a reasonable use case to be documented. >>> >>> Is this scenario correct? Is there a version of 3GPP that assigns a single /64, perhaps >>> shared by the upstream link and anything downstream of the 3GPP device? I think the scenario >>> needs to be checked for correctness. >> >> All releases of 3GPP assign a single /64 to the mobile handlset (per PDN Connection - theoretically a device may have max 11 /64s assigned this way). The sharing of that same prefix to downstream LAN(s) is _not_ in any spec but definitely doable as an implementation hack in the mobile handset without breaking things. >> >> There is actually a draft that sidetracks this: draft-ietf-v6ops-64share-10 >> >> DHCPv6-PD is, btw, rel-10 feature, not rel-11. > > OK, thanks. > > And, to be clear, looking ahead to question 3 ... subnetted ULA+NPTv6 does *not* > apply in the 3GPP-/64 case, right? NPTv6 doesn't allow multiple ULA /64s to be > mapped into a single GUA /64? Correct. - Jouni > > - Ralph > >> >> - Jouni > From nobody Fri May 30 01:39:11 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2725B1A078D for ; Fri, 30 May 2014 01:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 e59qpLTlGM9L for ; Fri, 30 May 2014 01:39:06 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED131A0747 for ; Fri, 30 May 2014 01:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5062; q=dns/txt; s=iport; t=1401439142; x=1402648742; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7kxoo5Ac+hpiGdg0dBW507lJdgcOcCZCTZeou6msFHk=; b=OWaF2UlJr0WAyz+Rw9w7QNx9NzqHLsXTw5nPkM1EpzRiPg/xQv9sJsHq CsNZ0v6Uw4BAypRsQyQZC0EK59s9pxYON4rFryTIA+TTKTUww7XQ2YKQv 2AvaBP1EyU3iYJNKlXi6ezKox18jQJRD40tDychxTfQvzAC2tlFnKLmLs s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALxCiFOtJV2U/2dsb2JhbABQCYMHUli7AYc5AYEFFnSCJQEBAQMBAQEBNzEDGwIBCCIUECcLJQIEARIIE4gfCA3WbhMEjXcqOIMrgRUErSaDOIIv X-IronPort-AV: E=Sophos;i="4.98,939,1392163200"; d="scan'208";a="48592663" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP; 30 May 2014 08:39:01 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4U8d1K3011078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 08:39:01 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.133]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 30 May 2014 03:39:01 -0500 From: "Pascal Thubert (pthubert)" To: Ted Lemon , "int-dir@ietf.org" Thread-Topic: [Int-dir] Request for review from LLN experts Thread-Index: AQHPeyE4VSL7cS+oR0OXdI/XNhc1qJtYxA5Q Date: Fri, 30 May 2014 08:39:00 +0000 Deferred-Delivery: Fri, 30 May 2014 08:38:00 +0000 Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> In-Reply-To: <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/vt28uhclye7m2xXgidzFEFWRltQ Subject: Re: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 08:39:08 -0000 Hi Ted and all: > > > > #3 NPTv6 Use Case > > > > In current draft Section 3.2.1, there is an NPTv6 use case: > > "In some very constrained situations(for example, in the sensors), the > > network needs ULA as the on-demand and stable addressing which > > doesn't need much code to support address assignment mechanisms like > > DHCP or full ND (Note: surely it needs SLAAC). If the network also > > needs to connect to the outside, then there can be an NPTv6 gateway > > which is not subject to extreme resource constraints. Especially when > > a lightweight isolated network needs to add Internet connectivity, > > this is quite a straightforward and efficient way." > > > > This use case is not based on real experience, but an assumption that > supporting multiple prefixes might be a heavy burden for some resource- > constrained nodes such as sensors. Because it needs to store multiple > addresses and dealing with the address selection problem. > > > > Question 1: > > In last IETF meeting, Lorenzo questioned this assumption whether it is > reasonable. I'd like to hear opinions from you on this issue. If it's > unreasonable, we'll move the use case out of the draft. [PT] In the IPv6 LLN standard work that I am most familiar with (ISA100.11a= , IEC 62734, 6TiSCH), there is no specific recommendation of using ULA. In = fact, ISA100 does not enforce that the IPv6 address is a valid IPv6 address= . There prefix that the device use in a 6LoWPAN network is somewhat abstract = in that they do not show up in the compressed packet but in some hash somew= here. It is passed in the RA and could be easily refreshed in that it only impact= s the piece that computes the pseudo headers. e.g. IEC 62734 extends the concept of UDP checksum (which can compressed in= 6LoWPAN) for its Message Integrity Check and that includes the UDP pseudo = header. In other words there was some proposal in the past (I think that was Lauren= t Toutain) that suggested that the prefix is actually decided by the border= router for packets leaving the LLN. OTOH the lack of a good identity system lead to the widespread use of the I= Pv6 address of the device as app level identifier for the device. This make= s renumbering quite cumbersome. So the need for stable addressing in existi= ng standards is certain. Unsure what on-demand means here but as we extend = the current (fully managed) Industrial LLN operations to more a autonomic b= ehaviour (RPL, draft-pritikin-) addressing will have to be fully automated= .=20 =20 > > > > Question 2: > > Besides the resource-constrained use case. There is another case which > was raised by Alex and has been talked a lot in 6man two months ago: one > node is assigned a /64, and it is the gateway of multi-subnets. This migh= t > probably happen in the 3GPP terminals. 3GPP R11 supports DHCP-PD, but > former specifications only support /64. Current networks just haven't > implemented R11. > > Besides DHCP-PD, another solution for the multi-subnets is bridging the= m > at L2. But it is not feasible in some situations. For example, In a vehic= le there > might be numerous incompatible L2s. > > > > I think it is a reasonable use case to be documented. > > [PT] This might be related Network Address Protection / multihoming cases w= hich uses MIP or LISP inside the private network as opposed to outside: 1) a ULA only network is deployed inside the network=20 2) each border router owns a /64 and acts as MIP HA 3) a device that need to reach the outside or be reachable via a border rou= ter obtains a Home Address from that BR 4) the device uses its ULA-based address as careof address and a MIP tunnel= is used inside the multihomed network to the BR / HA=20 5) In case of a loss of an ISP, the MIP tunnels dies and the nodes register= to an alternate, thus obtaining transport through the alt ISP Note that I know of some IPR about this technique. > > Question 3: > > This question is derived from Question 2. Current draft only refers NPT= v6, > but might been other IPv6 NAT implementations available in the vehicle/Io= T > networks. Shall we expand the "ULA+NPTv6" case to a generic "ULA+IPv6 > NAT" ? (Note: NPTv6 is the only standardized IPv6 NAT mechanism so far) = . > > [PT] Looks like a bad idea for reason of scale. Note that more often than = not there will be a local termination of the transport for data massaging, = so the communication to the outside (SCADA...) usually does not rely on the= device's IPv6 address.=20 All in all, ULA is certainly very suitable in an LLN and a ML subnet that f= ederates a number of such. Cheers, Pascal > > Regards, > > Bing > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > Int-dir mailing list > Int-dir@ietf.org > https://www.ietf.org/mailman/listinfo/int-dir From nobody Fri May 30 03:50:01 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476CF1A087E for ; Fri, 30 May 2014 03:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 4vDqv8hlJEkb for ; Fri, 30 May 2014 03:49:58 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A1F1A089D for ; Fri, 30 May 2014 03:49:57 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B26AF1B81EB for ; Fri, 30 May 2014 03:49:53 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 68ABB19005C; Fri, 30 May 2014 03:49:53 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 30 May 2014 03:49:53 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Fri, 30 May 2014 11:49:50 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: <24CB8C4B-3592-45B8-AA5F-BDFD409E23E7@nominum.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/sic-2Dvj3U3PajPlpUnqGIo50EY Cc: "int-dir@ietf.org" Subject: Re: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 10:49:59 -0000 On May 30, 2014, at 9:39 AM, Pascal Thubert (pthubert) = wrote: > All in all, ULA is certainly very suitable in an LLN and a ML subnet = that federates a number of such. Thanks--your perspective on this was quite a bit different from the = others, and therefore particularly helpful. You didn't really speak to = the multiple address issue--does it make sense for a 6lowpan node to = have multiple addresses, or is the expectation that the gateway between = the 6lowpan network and the rest of the world will be doing translation = anyway, and hence it can deal with that complexity? From nobody Fri May 30 06:45:11 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958BD1A08F7 for ; Fri, 30 May 2014 06:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 CV3fgOppD0JQ for ; Fri, 30 May 2014 06:45:07 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C261A08F3 for ; Fri, 30 May 2014 06:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1126; q=dns/txt; s=iport; t=1401457503; x=1402667103; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kHuAqf1LuVcPVn5tO5Lg3mW8wv4u7q81NhTklO+RNVw=; b=f0vCQKxhruFHDHNrGdXt3WYwH0K3M4FL5uCRNdylSrd3C/SAFG9ZW2kw MrlLM2JIlyeqBR4SMz7iGtzr26W0lDslXw5+ElSkzl3/+r4tOc+W6oVc2 8pUZO0uwW6t/EZhbSxoHE5FghLcSduj2V3dZMdPWTXeGgELL/Nrticg+u E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAHKKiFOtJA2M/2dsb2JhbABZgweBKsI6AYEJFnSCJQEBAQQ6MQ4MBAIBCBEEAQEBChQJBzIUCQgCBA4FCIg61w4XjiExBwaDJYEVAQOtJoM4gi8 X-IronPort-AV: E=Sophos;i="4.98,941,1392163200"; d="scan'208";a="329175724" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP; 30 May 2014 13:45:02 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4UDj1H1029827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 13:45:02 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.133]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 30 May 2014 08:45:01 -0500 From: "Pascal Thubert (pthubert)" To: Ted Lemon Thread-Topic: [Int-dir] Request for review from LLN experts Thread-Index: AQHPeyE4VSL7cS+oR0OXdI/XNhc1qJtYxA5QgACDQwD//9zIIA== Date: Fri, 30 May 2014 13:45:01 +0000 Deferred-Delivery: Fri, 30 May 2014 13:45:00 +0000 Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> <24CB8C4B-3592-45B8-AA5F-BDFD409E23E7@nominum.com> In-Reply-To: <24CB8C4B-3592-45B8-AA5F-BDFD409E23E7@nominum.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/NTx36VpIBgfDdHZ3BtooVuAeqgc Cc: "int-dir@ietf.org" Subject: Re: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 13:45:08 -0000 In the discussions I had earlier, Ted, it was not expected that the device = would have multiple addresses nor would renew them anytime soon... And yes, the idea that the gateway would take care of issues is appealing. Cheers, Pascal > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: vendredi 30 mai 2014 12:50 > To: Pascal Thubert (pthubert) > Cc: int-dir@ietf.org > Subject: Re: [Int-dir] Request for review from LLN experts >=20 > On May 30, 2014, at 9:39 AM, Pascal Thubert (pthubert) > wrote: > > All in all, ULA is certainly very suitable in an LLN and a ML subnet th= at > federates a number of such. >=20 > Thanks--your perspective on this was quite a bit different from the other= s, > and therefore particularly helpful. You didn't really speak to the mult= iple > address issue--does it make sense for a 6lowpan node to have multiple > addresses, or is the expectation that the gateway between the 6lowpan > network and the rest of the world will be doing translation anyway, and > hence it can deal with that complexity? From nobody Fri May 30 06:50:38 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5FB1A08F3 for ; Fri, 30 May 2014 06:50:32 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham 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 T8OvGVHkAgRz for ; Fri, 30 May 2014 06:50:30 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F171A08FA for ; Fri, 30 May 2014 06:50:29 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q108so5233604qgd.19 for ; Fri, 30 May 2014 06:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KFRBBqvKUfi2vaKEZkEcHyLYeGEmmli8wOE3A8804RM=; b=RRgAF51dNIU9vJTplnlbL1xM7ENM5eIMWMYtKF+ObltaAVz/y/Mu9/AE22ngDa6ldM v1pzDgCebK4VXYkkdB1rt86enzXsprisj4pmjGfTLF28BgWu72qNdwlIH3gRBi2dBbaQ 8tUaFHzx8DyB7m5aBV/4kzYQud1q8q535RVEzTLCavk5mhKgNBKi2RHuIYpLas7380Nw d+wdXfSKwBSAPXXvQ1glLW4zwoPUyD1K87FiqYUYnri9kTz+HMkbuh1wg58a6TQEhQ/x BkIK3MgmnVeW9K/Bq9Efr5DCIgFYvv3EjGFQoiJnrRPMsNlbsHBjZc05mgK3230WtrwT HEjQ== X-Received: by 10.140.21.239 with SMTP id 102mr20303742qgl.31.1401457825375; Fri, 30 May 2014 06:50:25 -0700 (PDT) Received: from [10.86.247.101] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id w8sm6307036qag.30.2014.05.30.06.50.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 06:50:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ralph Droms In-Reply-To: Date: Fri, 30 May 2014 09:50:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1E38411B-61D8-40CE-9181-56C2AB4E3ECA@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> <24CB8C4B-3592-45B8-AA5F-BDFD409E23E7@nominum.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/RSBBGZBxsLkmBrP_EOrpQu2_O2E Cc: Lemon Ted , "int-dir@ietf.org" Subject: Re: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 13:50:32 -0000 On May 30, 2014, at 9:45 AM 5/30/14, Pascal Thubert (pthubert) = wrote: > In the discussions I had earlier, Ted, it was not expected that the = device would have multiple addresses nor would renew them anytime = soon... > And yes, the idea that the gateway would take care of issues is = appealing. Pascal - do you know of any specific protocols or specifications where = this behavior (in which the gateway uses NPTv6 to translate between a = ULA prefix in the LLN and an external GUA) is explicitly defined or = required today? Or is it hypothetical? - Ralph >=20 > Cheers, >=20 > Pascal >=20 >=20 >> -----Original Message----- >> From: Ted Lemon [mailto:ted.lemon@nominum.com] >> Sent: vendredi 30 mai 2014 12:50 >> To: Pascal Thubert (pthubert) >> Cc: int-dir@ietf.org >> Subject: Re: [Int-dir] Request for review from LLN experts >>=20 >> On May 30, 2014, at 9:39 AM, Pascal Thubert (pthubert) >> wrote: >>> All in all, ULA is certainly very suitable in an LLN and a ML subnet = that >> federates a number of such. >>=20 >> Thanks--your perspective on this was quite a bit different from the = others, >> and therefore particularly helpful. You didn't really speak to the = multiple >> address issue--does it make sense for a 6lowpan node to have multiple >> addresses, or is the expectation that the gateway between the 6lowpan >> network and the rest of the world will be doing translation anyway, = and >> hence it can deal with that complexity? >=20 > _______________________________________________ > Int-dir mailing list > Int-dir@ietf.org > https://www.ietf.org/mailman/listinfo/int-dir From nobody Fri May 30 07:25:08 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A338B1A08FB for ; Fri, 30 May 2014 07:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 rOL11YYVwIxo for ; Fri, 30 May 2014 07:25:06 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0221A08CF for ; Fri, 30 May 2014 07:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2691; q=dns/txt; s=iport; t=1401459902; x=1402669502; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=p6BiTLRzPnm44do4k8wkLTselHo3FbGpLdO5/fwv/ks=; b=ceF7fYdwIFkhO8uLdLqPZ67lNNRzND/R2o50eUNjl8P4JyiwRWVr5Kuu wHdDNq5VIb11XCfYi32IQ5s2d2XLVZ4PBlJBuS/lPFli3HmhCILJUpslJ 3d0wiw6izkfdF5+hMPIjXnNyioEkiFs6rjDtx5CR1tfFZB2G2eeAkM8Kd E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAJqTiFOtJA2G/2dsb2JhbABZgwdSWLsChzkBgQkWdIIlAQEBBAEBATcxAwsMBAIBCA4DBAEBAQoUCQchBgsUCQgCBA4FCIgmAxEN0FgNhhMTBIw8gWUxBwaDJYEVBJgHjzGFc4M4gi8 X-IronPort-AV: E=Sophos;i="4.98,941,1392163200"; d="scan'208";a="329185396" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP; 30 May 2014 14:25:01 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4UEP1fd023606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 14:25:01 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.133]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 30 May 2014 09:25:01 -0500 From: "Pascal Thubert (pthubert)" To: Ralph Droms Thread-Topic: [Int-dir] Request for review from LLN experts Thread-Index: AQHPeyE4VSL7cS+oR0OXdI/XNhc1qJtYxA5QgACDQwD//9zIIIAAVacA//+0YnA= Date: Fri, 30 May 2014 14:25:00 +0000 Deferred-Delivery: Fri, 30 May 2014 14:25:00 +0000 Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> <24CB8C4B-3592-45B8-AA5F-BDFD409E23E7@nominum.com> <1E38411B-61D8-40CE-9181-56C2AB4E3ECA@gmail.com> In-Reply-To: <1E38411B-61D8-40CE-9181-56C2AB4E3ECA@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/fC10XQ5MOfZp35pKzzXRhGYmNoo Cc: Lemon Ted , "int-dir@ietf.org" Subject: Re: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:25:07 -0000 Hi Ralph: " it was not expected that the device would have multiple addresses nor wou= ld renew them anytime soon..." comes from actual standards work, and is cer= tain is those standards. " the idea that the gateway would take care of issues is appealing" is just= an idea (hypothetical), that extends the design that gateways do take care= of all the issues for the devices, and that it would be good that the gate= way falls from L5 to L3.=20 Also, I noticed that usually there is a local transport end point in the vi= cinity (a fog server) so the devices themselves are not expected to reach f= ar into the Internet.=20 Cheers, Pascal > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: vendredi 30 mai 2014 15:50 > To: Pascal Thubert (pthubert) > Cc: Lemon Ted; int-dir@ietf.org > Subject: Re: [Int-dir] Request for review from LLN experts >=20 >=20 > On May 30, 2014, at 9:45 AM 5/30/14, Pascal Thubert (pthubert) > wrote: >=20 > > In the discussions I had earlier, Ted, it was not expected that the dev= ice > would have multiple addresses nor would renew them anytime soon... > > And yes, the idea that the gateway would take care of issues is appeali= ng. >=20 > Pascal - do you know of any specific protocols or specifications where th= is > behavior (in which the gateway uses NPTv6 to translate between a ULA > prefix in the LLN and an external GUA) is explicitly defined or required > today? Or is it hypothetical? >=20 > - Ralph >=20 > > > > Cheers, > > > > Pascal > > > > > >> -----Original Message----- > >> From: Ted Lemon [mailto:ted.lemon@nominum.com] > >> Sent: vendredi 30 mai 2014 12:50 > >> To: Pascal Thubert (pthubert) > >> Cc: int-dir@ietf.org > >> Subject: Re: [Int-dir] Request for review from LLN experts > >> > >> On May 30, 2014, at 9:39 AM, Pascal Thubert (pthubert) > >> wrote: > >>> All in all, ULA is certainly very suitable in an LLN and a ML subnet > >>> that > >> federates a number of such. > >> > >> Thanks--your perspective on this was quite a bit different from the > others, > >> and therefore particularly helpful. You didn't really speak to the m= ultiple > >> address issue--does it make sense for a 6lowpan node to have multiple > >> addresses, or is the expectation that the gateway between the 6lowpan > >> network and the rest of the world will be doing translation anyway, > >> and hence it can deal with that complexity? > > > > _______________________________________________ > > Int-dir mailing list > > Int-dir@ietf.org > > https://www.ietf.org/mailman/listinfo/int-dir From nobody Fri May 30 08:21:37 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2641A0930 for ; Fri, 30 May 2014 08:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=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 M1J9N4CnrdZH for ; Fri, 30 May 2014 08:21:32 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13A51A0924 for ; Fri, 30 May 2014 08:21:31 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id a108so5643781qge.36 for ; Fri, 30 May 2014 08:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lIDKVdM0MFet6XtvBi8r5jA8Nk2hapsp3g/i6QmuEjY=; b=xnVoW/WvORPtSL9smpJxYl9JDOhEUagsntjbms1Y/LjL6VMnyIVKnjAIXUtmLVizIM nfBIQL+4A6n4sa4Q+m/LV6dqz5sscjYOcAM2SFDzNYDsdgyRyZFkjh7X2pM16msitwc+ JfyNT/QmldIDjB4oazBW6WJIRpdwjZPdT1BOnGiWog+YtcEkYIOyXzbmpLv3PStRLAts cANhBGcCr2hk522arzEwl930pI8CZ6fus1lwbCzd6PoEXkPOC7NH64KcrLcpho5CMHtq qinTseOWPyT+Y/J96X2/xTe+hTZG4XNjUCqk0QAl7R37wGL3rI64mh6c1bUQmtbJnS/E UwPg== X-Received: by 10.140.98.234 with SMTP id o97mr21106957qge.35.1401463287070; Fri, 30 May 2014 08:21:27 -0700 (PDT) Received: from bxb-vpn3-370.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id r4sm6659635qat.16.2014.05.30.08.21.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 08:21:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ralph Droms In-Reply-To: Date: Fri, 30 May 2014 11:21:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7966B0C9-34C8-4464-B3A7-665F7FDB892A@gmail.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> <24CB8C4B-3592-45B8-AA5F-BDFD409E23E7@nominum.com> <1E38411B-61D8-40CE-9181-56C2AB4E3ECA@gmail.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/Cq6xAZS_IYfSmid0xxh8JG5kmIA Cc: Lemon Ted , "int-dir@ietf.org" Subject: Re: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 15:21:33 -0000 On May 30, 2014, at 10:25 AM 5/30/14, Pascal Thubert (pthubert) = wrote: > Hi Ralph: >=20 > " it was not expected that the device would have multiple addresses = nor would renew them anytime soon..." comes from actual standards work, = and is certain is those standards. Pascal, I'd like to pull on this thread a little because I think it's = important for this use case to know which are currently spec'ed use = cases and which are hypothetical. The Wi-SUN FAN spec requires each = node to manage at least two prefixes, to allow for two LBRs improving = availability. My recollection is that the Z-IP spec expects nodes to = manage multiple prefixes (I can look back in the text to confirm). Are = there other specs that specifically consider nodes that can only manage = one prefix to be compliant with the spec? > " the idea that the gateway would take care of issues is appealing" is = just an idea (hypothetical), that extends the design that gateways do = take care of all the issues for the devices, and that it would be good = that the gateway falls from L5 to L3.=20 Pulling on this thread as well, and looking specifically at the question = Ted asked about multiple prefixes, I'm wondering how the use of a ULA = would allow an LLN to operate more easily on a single prefix? I'm = assuming I have it right that NPTv6 does not enable one-to-many prefix = translation. The one use case I can think of is an LLN that uses two = GUAs for make-before-break re-prefixing. In the case of a ULA+NPTv6, a = simple change in the NPTv6 translation table would implement the = re-prefixing. Avoiding re-prefixing with a ULA might save operational = overhead and disruption, but I'd like to hear more about how using a = single prefix would reduce the code and data overhead. >=20 > Also, I noticed that usually there is a local transport end point in = the vicinity (a fog server) so the devices themselves are not expected = to reach far into the Internet.=20 >=20 > Cheers, >=20 > Pascal >=20 >=20 >> -----Original Message----- >> From: Ralph Droms [mailto:rdroms.ietf@gmail.com] >> Sent: vendredi 30 mai 2014 15:50 >> To: Pascal Thubert (pthubert) >> Cc: Lemon Ted; int-dir@ietf.org >> Subject: Re: [Int-dir] Request for review from LLN experts >>=20 >>=20 >> On May 30, 2014, at 9:45 AM 5/30/14, Pascal Thubert (pthubert) >> wrote: >>=20 >>> In the discussions I had earlier, Ted, it was not expected that the = device >> would have multiple addresses nor would renew them anytime soon... >>> And yes, the idea that the gateway would take care of issues is = appealing. >>=20 >> Pascal - do you know of any specific protocols or specifications = where this >> behavior (in which the gateway uses NPTv6 to translate between a ULA >> prefix in the LLN and an external GUA) is explicitly defined or = required >> today? Or is it hypothetical? >>=20 >> - Ralph >>=20 >>>=20 >>> Cheers, >>>=20 >>> Pascal >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Ted Lemon [mailto:ted.lemon@nominum.com] >>>> Sent: vendredi 30 mai 2014 12:50 >>>> To: Pascal Thubert (pthubert) >>>> Cc: int-dir@ietf.org >>>> Subject: Re: [Int-dir] Request for review from LLN experts >>>>=20 >>>> On May 30, 2014, at 9:39 AM, Pascal Thubert (pthubert) >>>> wrote: >>>>> All in all, ULA is certainly very suitable in an LLN and a ML = subnet >>>>> that >>>> federates a number of such. >>>>=20 >>>> Thanks--your perspective on this was quite a bit different from the >> others, >>>> and therefore particularly helpful. You didn't really speak to = the multiple >>>> address issue--does it make sense for a 6lowpan node to have = multiple >>>> addresses, or is the expectation that the gateway between the = 6lowpan >>>> network and the rest of the world will be doing translation anyway, >>>> and hence it can deal with that complexity? >>>=20 >>> _______________________________________________ >>> Int-dir mailing list >>> Int-dir@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-dir >=20 From nobody Fri May 30 09:20:11 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C981A6F41 for ; Fri, 30 May 2014 09:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 QYqAw0Pc29nQ for ; Fri, 30 May 2014 09:20:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4731A09FD for ; Fri, 30 May 2014 09:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6970; q=dns/txt; s=iport; t=1401466804; x=1402676404; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=01Kte0Mt2t+qX9CB2zUQtN8eRTLsgu98F6VjqXJz4Ro=; b=F9l+KwmFZ0XiEwPHQVTSyV5lhw9c5sc+zJ+dlpualTe5gOCwhEzzmAjN n5yYFIV/c5sTzLU9z3TfFaOWp0GYl0SaFETYW722mU9SjlHy3Y68g9J86 1zwN85hXM78qSuLD7FmOTmkphHOdwzdQQSnkNnrV/hnlImuxY6MEJxxvP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAM2uiFOtJV2c/2dsb2JhbABZgwdSWLsDhzkBgQkWdIIlAQEBBAEBATcxAwsMBAIBCA4DBAEBAQoUCQchBgsUCQgCBA4FCIgmAxEN0GANhgITBIw8gWUxBwaDJYEVBJU0glOPMYVzgziCLw X-IronPort-AV: E=Sophos;i="4.98,941,1392163200"; d="scan'208";a="329304175" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 30 May 2014 16:20:03 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4UGK2lC029557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 16:20:02 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.133]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 30 May 2014 11:20:02 -0500 From: "Pascal Thubert (pthubert)" To: Ralph Droms Thread-Topic: [Int-dir] Request for review from LLN experts Thread-Index: AQHPeyE4VSL7cS+oR0OXdI/XNhc1qJtYxA5QgACDQwD//9zIIIAAVacA//+0YnCAAGUNAP//tbUA Date: Fri, 30 May 2014 16:20:02 +0000 Deferred-Delivery: Fri, 30 May 2014 16:20:00 +0000 Message-ID: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> <24CB8C4B-3592-45B8-AA5F-BDFD409E23E7@nominum.com> <1E38411B-61D8-40CE-9181-56C2AB4E3ECA@gmail.com> <7966B0C9-34C8-4464-B3A7-665F7FDB892A@gmail.com> In-Reply-To: <7966B0C9-34C8-4464-B3A7-665F7FDB892A@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/Ri2YoAriALc-UmrwwCLKiSFySr0 Cc: Lemon Ted , "int-dir@ietf.org" Subject: Re: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 16:20:10 -0000 Hi Ralph: Please see inline: Cheers, Pascal > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: vendredi 30 mai 2014 17:21 > To: Pascal Thubert (pthubert) > Cc: Lemon Ted; int-dir@ietf.org > Subject: Re: [Int-dir] Request for review from LLN experts >=20 >=20 > On May 30, 2014, at 10:25 AM 5/30/14, Pascal Thubert (pthubert) > wrote: >=20 > > Hi Ralph: > > > > " it was not expected that the device would have multiple addresses nor > would renew them anytime soon..." comes from actual standards work, and > is certain is those standards. >=20 > Pascal, I'd like to pull on this thread a little because I think it's imp= ortant for > this use case to know which are currently spec'ed use cases and which are > hypothetical. The Wi-SUN FAN spec requires each node to manage at least > two prefixes, to allow for two LBRs improving availability. My recollect= ion is > that the Z-IP spec expects nodes to manage multiple prefixes (I can look = back > in the text to confirm). Are there other specs that specifically conside= r > nodes that can only manage one prefix to be compliant with the spec? >=20 [PT]=20 ISA100.11a relies on the backbone router functionality to cover that reliab= ility issue. In that model all the RPL roots are part of a same multilink s= ubnet federated by an IPv6 backbone. 6TiSCH is inheriting that model. There= is no need for 2 prefixes, and you can have more than 2 exits for your mes= h. People at ISA100 were concerned with the size of a single IPv6 address; eac= h device has a link local and a global but really the link local only appea= rs in the compressed form in the join packet, and there is not much state a= ssociated to it in the device but the MAC address itself... In fact, the ISA100 model exploits duocast where a second backbone router c= lose to the first one can promiscuously hear the frame and send a copy over= the backbone.=20 > > " the idea that the gateway would take care of issues is appealing" is = just > an idea (hypothetical), that extends the design that gateways do take car= e of > all the issues for the devices, and that it would be good that the gatewa= y > falls from L5 to L3. >=20 > Pulling on this thread as well, and looking specifically at the question = Ted > asked about multiple prefixes, I'm wondering how the use of a ULA would > allow an LLN to operate more easily on a single prefix? I'm assuming I h= ave > it right that NPTv6 does not enable one-to-many prefix translation. The = one > use case I can think of is an LLN that uses two GUAs for make-before-brea= k > re-prefixing. In the case of a ULA+NPTv6, a simple change in the NPTv6 > translation table would implement the re-prefixing. Avoiding re-prefixin= g > with a ULA might save operational overhead and disruption, but I'd like t= o > hear more about how using a single prefix would reduce the code and data > overhead. >=20 [PT] My expectation is that a device rarely needs to talk outside the ULA d= omain.=20 If it does, there are models such as the NAP model that I indicated earlier= in that thread where the device can get an external (home) address but tha= t address would not need to be routed inside the LLN. And yes in such cases= the device needs multiple addresses, the ULA that is routed inside the LLN= and one or more GUA that are visible externally. NPTv6 will not work for I= SA100 devices because the NPT device cannot fix the ISA100 (DTLS like) Mess= age Integrity Check. The MIC incorporates the UDP header and the UDP pseudo= header in the dataset that is signed with a transport layer session key. The only thing that bars the LLN from having no real prefix at all is the U= DP checksum or equivalent MIC signature that has to be performed by the dev= ice. Otherwise we'd end up with a similar result as with NAP. The device co= uld have a null prefix or a well-known ULA prefix and let the NPT/HA border= router decide what the external prefix is. In that case the renumbering on= ly happens at the border router anyway, either as a decaps or as a translat= ion.=20 2 different border routers could mean multihoming, which can be done more o= r less cleanly and disruptively WRT to active sessions. With traditional Co= AP, there is no such thing so the loss would be minimal. With Observe, thin= gs could become rough but the fault is on observe which is too far in its c= urrent incarnation from the REST of CoAP. Cheers, Pascal > > > > Also, I noticed that usually there is a local transport end point in th= e > vicinity (a fog server) so the devices themselves are not expected to rea= ch far > into the Internet. > > > > Cheers, > > > > Pascal > > > > > >> -----Original Message----- > >> From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > >> Sent: vendredi 30 mai 2014 15:50 > >> To: Pascal Thubert (pthubert) > >> Cc: Lemon Ted; int-dir@ietf.org > >> Subject: Re: [Int-dir] Request for review from LLN experts > >> > >> > >> On May 30, 2014, at 9:45 AM 5/30/14, Pascal Thubert (pthubert) > >> wrote: > >> > >>> In the discussions I had earlier, Ted, it was not expected that the > >>> device > >> would have multiple addresses nor would renew them anytime soon... > >>> And yes, the idea that the gateway would take care of issues is > appealing. > >> > >> Pascal - do you know of any specific protocols or specifications > >> where this behavior (in which the gateway uses NPTv6 to translate > >> between a ULA prefix in the LLN and an external GUA) is explicitly > >> defined or required today? Or is it hypothetical? > >> > >> - Ralph > >> > >>> > >>> Cheers, > >>> > >>> Pascal > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ted Lemon [mailto:ted.lemon@nominum.com] > >>>> Sent: vendredi 30 mai 2014 12:50 > >>>> To: Pascal Thubert (pthubert) > >>>> Cc: int-dir@ietf.org > >>>> Subject: Re: [Int-dir] Request for review from LLN experts > >>>> > >>>> On May 30, 2014, at 9:39 AM, Pascal Thubert (pthubert) > >>>> wrote: > >>>>> All in all, ULA is certainly very suitable in an LLN and a ML > >>>>> subnet that > >>>> federates a number of such. > >>>> > >>>> Thanks--your perspective on this was quite a bit different from the > >> others, > >>>> and therefore particularly helpful. You didn't really speak to the > multiple > >>>> address issue--does it make sense for a 6lowpan node to have > >>>> multiple addresses, or is the expectation that the gateway between > >>>> the 6lowpan network and the rest of the world will be doing > >>>> translation anyway, and hence it can deal with that complexity? > >>> > >>> _______________________________________________ > >>> Int-dir mailing list > >>> Int-dir@ietf.org > >>> https://www.ietf.org/mailman/listinfo/int-dir > > From nobody Fri May 30 11:24:07 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57B11A043F for ; Fri, 30 May 2014 11:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=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 fhJyBgPI0yry for ; Fri, 30 May 2014 11:24:02 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7851A036A for ; Fri, 30 May 2014 11:24:02 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id z60so6334794qgd.4 for ; Fri, 30 May 2014 11:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=MH1M4/cO/FYgP7iIKW44vQizsMBN4hTPPhy9ULMTHUc=; b=C6SwjDFw1YzW65y8tcXvQi2Bm7XTBt0DkkPpDJhkOuxbK4YQk2hGdAZZbryvRCu1Ya tEUK2i4P81MmMGJFCdc9B7mj151FoATbagA2Oih+/EN8KC71svTVnpoYZO3MsGJEgk3U 0JTMBnwMCUr0MdWn6hNomr9/0hQsGfOFuIcmojcFo5lfhvQJA6pvI0wt/UF2zyKBqaeM QD+2VE9FPdDgG0cNqMOSFTClvivvSa+Gd7/JsU2TpAxyxK0TbTCwjxDFJq3b5Bv26nKr emKoQgkG/lhVOPKMC57E6zmlDL6RyiweHraiulIrvqGywxSNZq5XfVE6okuMqFgV5/PH 7YQg== X-Received: by 10.224.96.131 with SMTP id h3mr10985640qan.85.1401474237381; Fri, 30 May 2014 11:23:57 -0700 (PDT) Received: from [10.80.53.116] (mobile-198-228-204-115.mycingular.net. [198.228.204.115]) by mx.google.com with ESMTPSA id j3sm7358487qaf.6.2014.05.30.11.23.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 11:23:55 -0700 (PDT) References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B7847@nkgeml506-mbx.china.huawei.com> <4658DDAD-51F2-4D7E-8DC3-60DF1653CBBB@nominum.com> <24CB8C4B-3592-45B8-AA5F-BDFD409E23E7@nominum.com> <1E38411B-61D8-40CE-9181-56C2AB4E3ECA@gmail.com> <7966B0C9-34C8-4464-B3A7-665F7FDB892A@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D201) From: Ralph Droms Date: Fri, 30 May 2014 14:23:53 -0400 To: "Pascal Thubert (pthubert)" Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/zCwakGkpydf3J1SP2HBdXBZ6QkY Cc: Lemon Ted , "int-dir@ietf.org" Subject: Re: [Int-dir] Request for review from LLN experts X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 18:24:04 -0000 Thanks for the clarifications, Pascal. - Ralph > On May 30, 2014, at 12:20 PM, "Pascal Thubert (pthubert)" wrote: >=20 > Hi Ralph: >=20 > Please see inline: >=20 > Cheers, >=20 > Pascal >=20 >=20 >> -----Original Message----- >> From: Ralph Droms [mailto:rdroms.ietf@gmail.com] >> Sent: vendredi 30 mai 2014 17:21 >> To: Pascal Thubert (pthubert) >> Cc: Lemon Ted; int-dir@ietf.org >> Subject: Re: [Int-dir] Request for review from LLN experts >>=20 >>=20 >> On May 30, 2014, at 10:25 AM 5/30/14, Pascal Thubert (pthubert) >> wrote: >>=20 >>> Hi Ralph: >>>=20 >>> " it was not expected that the device would have multiple addresses nor >> would renew them anytime soon..." comes from actual standards work, and >> is certain is those standards. >>=20 >> Pascal, I'd like to pull on this thread a little because I think it's imp= ortant for >> this use case to know which are currently spec'ed use cases and which are= >> hypothetical. The Wi-SUN FAN spec requires each node to manage at least >> two prefixes, to allow for two LBRs improving availability. My recollect= ion is >> that the Z-IP spec expects nodes to manage multiple prefixes (I can look b= ack >> in the text to confirm). Are there other specs that specifically conside= r >> nodes that can only manage one prefix to be compliant with the spec? > [PT]=20 > ISA100.11a relies on the backbone router functionality to cover that relia= bility issue. In that model all the RPL roots are part of a same multilink s= ubnet federated by an IPv6 backbone. 6TiSCH is inheriting that model. There i= s no need for 2 prefixes, and you can have more than 2 exits for your mesh. >=20 > People at ISA100 were concerned with the size of a single IPv6 address; ea= ch device has a link local and a global but really the link local only appea= rs in the compressed form in the join packet, and there is not much state as= sociated to it in the device but the MAC address itself... >=20 > In fact, the ISA100 model exploits duocast where a second backbone router c= lose to the first one can promiscuously hear the frame and send a copy over t= he backbone.=20 >=20 >>> " the idea that the gateway would take care of issues is appealing" is j= ust >> an idea (hypothetical), that extends the design that gateways do take car= e of >> all the issues for the devices, and that it would be good that the gatewa= y >> falls from L5 to L3. >>=20 >> Pulling on this thread as well, and looking specifically at the question T= ed >> asked about multiple prefixes, I'm wondering how the use of a ULA would >> allow an LLN to operate more easily on a single prefix? I'm assuming I h= ave >> it right that NPTv6 does not enable one-to-many prefix translation. The o= ne >> use case I can think of is an LLN that uses two GUAs for make-before-brea= k >> re-prefixing. In the case of a ULA+NPTv6, a simple change in the NPTv6 >> translation table would implement the re-prefixing. Avoiding re-prefixin= g >> with a ULA might save operational overhead and disruption, but I'd like t= o >> hear more about how using a single prefix would reduce the code and data >> overhead. > [PT] My expectation is that a device rarely needs to talk outside the ULA d= omain.=20 >=20 > If it does, there are models such as the NAP model that I indicated earlie= r in that thread where the device can get an external (home) address but tha= t address would not need to be routed inside the LLN. And yes in such cases t= he device needs multiple addresses, the ULA that is routed inside the LLN an= d one or more GUA that are visible externally. NPTv6 will not work for ISA10= 0 devices because the NPT device cannot fix the ISA100 (DTLS like) Message I= ntegrity Check. The MIC incorporates the UDP header and the UDP pseudo heade= r in the dataset that is signed with a transport layer session key. >=20 > The only thing that bars the LLN from having no real prefix at all is the U= DP checksum or equivalent MIC signature that has to be performed by the devi= ce. Otherwise we'd end up with a similar result as with NAP. The device coul= d have a null prefix or a well-known ULA prefix and let the NPT/HA border ro= uter decide what the external prefix is. In that case the renumbering only h= appens at the border router anyway, either as a decaps or as a translation.=20= >=20 > 2 different border routers could mean multihoming, which can be done more o= r less cleanly and disruptively WRT to active sessions. With traditional CoA= P, there is no such thing so the loss would be minimal. With Observe, things= could become rough but the fault is on observe which is too far in its curr= ent incarnation from the REST of CoAP. >=20 > Cheers, >=20 > Pascal >>>=20 >>> Also, I noticed that usually there is a local transport end point in the= >> vicinity (a fog server) so the devices themselves are not expected to rea= ch far >> into the Internet. >>>=20 >>> Cheers, >>>=20 >>> Pascal >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Ralph Droms [mailto:rdroms.ietf@gmail.com] >>>> Sent: vendredi 30 mai 2014 15:50 >>>> To: Pascal Thubert (pthubert) >>>> Cc: Lemon Ted; int-dir@ietf.org >>>> Subject: Re: [Int-dir] Request for review from LLN experts >>>>=20 >>>>=20 >>>> On May 30, 2014, at 9:45 AM 5/30/14, Pascal Thubert (pthubert) >>>> wrote: >>>>=20 >>>>> In the discussions I had earlier, Ted, it was not expected that the >>>>> device >>>> would have multiple addresses nor would renew them anytime soon... >>>>> And yes, the idea that the gateway would take care of issues is >> appealing. >>>>=20 >>>> Pascal - do you know of any specific protocols or specifications >>>> where this behavior (in which the gateway uses NPTv6 to translate >>>> between a ULA prefix in the LLN and an external GUA) is explicitly >>>> defined or required today? Or is it hypothetical? >>>>=20 >>>> - Ralph >>>>=20 >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Pascal >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Ted Lemon [mailto:ted.lemon@nominum.com] >>>>>> Sent: vendredi 30 mai 2014 12:50 >>>>>> To: Pascal Thubert (pthubert) >>>>>> Cc: int-dir@ietf.org >>>>>> Subject: Re: [Int-dir] Request for review from LLN experts >>>>>>=20 >>>>>> On May 30, 2014, at 9:39 AM, Pascal Thubert (pthubert) >>>>>> wrote: >>>>>>> All in all, ULA is certainly very suitable in an LLN and a ML >>>>>>> subnet that >>>>>> federates a number of such. >>>>>>=20 >>>>>> Thanks--your perspective on this was quite a bit different from the >>>> others, >>>>>> and therefore particularly helpful. You didn't really speak to the >> multiple >>>>>> address issue--does it make sense for a 6lowpan node to have >>>>>> multiple addresses, or is the expectation that the gateway between >>>>>> the 6lowpan network and the rest of the world will be doing >>>>>> translation anyway, and hence it can deal with that complexity? >>>>>=20 >>>>> _______________________________________________ >>>>> Int-dir mailing list >>>>> Int-dir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/int-dir >=20