From alberto@it.uc3m.es Tue Mar 6 09:06:51 2012 Return-Path: X-Original-To: shim6@ietfa.amsl.com Delivered-To: shim6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C33921F8714; Tue, 6 Mar 2012 09:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.107 X-Spam-Level: X-Spam-Status: No, score=-6.107 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBllJftbPFNq; Tue, 6 Mar 2012 09:06:44 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE2821F8763; Tue, 6 Mar 2012 09:06:39 -0800 (PST) X-uc3m-safe: yes Received: from BOMBO (unknown [163.117.139.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 4155275ABF1; Tue, 6 Mar 2012 18:06:38 +0100 (CET) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: "'Carsten Bormann'" , "'IETF Apps Discuss'" , , References: In-Reply-To: Date: Tue, 6 Mar 2012 18:06:38 +0100 Message-ID: <00ac01ccfbbb$7e81e580$7b85b080$@it.uc3m.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01CCFBC3.E04B0870" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE8Z7u/F1paD1p9UUiMSbxgp70Ic5d4Qc7Q Content-Language: es X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18758.000 Cc: 'The IESG' Subject: Re: [shim6] APPSDIR review of draft-garcia-shim6-applicability-03 X-BeenThere: shim6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SHIM6 Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:06:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AD_01CCFBC3.E04B0870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Carsten, Thank you very much for your review =20 | -----Mensaje original----- | De: shim6-bounces@ietf.org [mailto:shim6-bounces@ietf.org] En nombre | de Carsten Bormann | Enviado el: mi=E9rcoles, 29 de febrero de 2012 23:13 | Para: IETF Apps Discuss; draft-garcia-shim6-applicability.all@tools.ietf.org; | shim6@ietf.org | CC: The IESG | Asunto: [shim6] APPSDIR review of draft-garcia-shim6-applicability-03 | =20 | I have been selected as the Applications Area Directorate reviewer = for this | draft (for background on APPSDIR, please see | http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ). | =20 | Please resolve these comments along with any other Last Call comments | you may receive. Please wait for direction from your document = shepherd or | AD before posting a new version of the draft. | =20 | Gruesse, Carsten | --------------------------------- | =20 | Document: draft-garcia-shim6-applicability-03.txt | Title: Applicability Statement for the Level 3 Multihoming Shim = Protocol | (Shim6) | Reviewer: Carsten Bormann | IETF Last Call Date: 2012-02-15 | Review Date: 2012-02-29 | =20 | ** Summary: This draft is ready for publication as an Informational | RFC with small changes, but maybe requires a better title. | =20 | Note: I reviewed this with the expectation that the intended audience will | read this *before* looking at RFC5533=965535 in detail. | =20 | ** Major Issues: | =20 | General: | =20 | The document provides useful discussion of considerations around the | usage of Shim6. At the end, it leaves the reader confused: What *is* = the | applicability/area of application of Shim6? =20 =20 I assume this comment relates with the expectations created by the = title, so I comment below. =20 | Who should decide whether | Shim6 is activated for a specific connection? (There is an API in = RFC 6316, | but clearly that is meant for advanced applications.)=20 =20 This issue was partially addressed in the 'Short-Lived Communications' subsection. However, I think the text would improve by placing this in a more prominent place, and by making a clearer statement. I have appended = the following text just to the end of the '2. Deployment Scenarios' section: =20 =93To allow nodes to benefit from the capabilities provided by Shim6 (discussed in Section 5) such as fault tolerance, nodes should be configured to initiate a Shim6 session with any peer node if they have multiple locators to use. Note that this configuration can be performed transparently to the applications, in the sense that applications do not need to be aware of the Shim6 functionality provided by the node; iin particular, nodes are not forced to use the Shim6 API [RFC6316] to benefit from Shim6. The Shim6 session should be created after the two nodes have been communicating for some time, i.e. using the deferred context establishment facility provided by Shim6. Otherwise, the cost of the Shim6 4-way handshake used for establishing the session may exceed the benefits provided for short- lived communications (see Section 5.1.2). More advanced node configuration may involved configuring different delays for initiating the session for different applications, for example, based on a per-port configuration. Nodes being able to use a single locator for the communication should not initiate the creation of a Shim6 context, but should participate if other node initiates it. Note that Shim6-aware applications can overrid this behavior by means of the Shim6 API [RFC6316].=94 =20 By the way, I've also merged the 'Short-lived' and 'Long-lived' = sections, into a single '5.1.2. Short-lived and long-lived communications', which = is referred in the previous paragraph. Does this address your concern? =20 | While the document | successfully relates Shim6 to SCTP and HIP, what about other = approaches to | multi-addressing? =20 In general, all mechanisms which handle different addresses at a higher level than the network-layer may experience unwanted interactions with Shim6. This applies to MPTCP, in addition to SCTP. Although there was a generic comment regarding to this at the end of the SCTP section, I have make this more explicit for MPTCP, by changing the SCTP section to refer = to both SCTP and MPTCP. =20 =937.3. Shim6, SCTP and MPTCP =20 Both the SCTP [RFC4960] and MPTCP [RFC6182] protocols provide a reliable, stream-based communications channel between two hosts which provides a superset of the capabilities of TCP. One notable feature of these two protocols is that they allow the exchange of endpoint addresses between hosts, in order to recover from the failure of a particular endpoint pair, or to benefit from multipath communication in the MPTCP case, in a manner which is conceptually similar to locator selection in Shim6. =20 SCTP and MPTCP are transport-layer protocols, higher in the protocol stack than Shim6, and hence there is no fundamental incompatibility which would prevent a Shim6-capable host from communicating using SCTP or MPTCP. =20 However, since either SCTP or MPTCP, and Shim6 aim to exchange addressing information between hosts in order to meet the same generic goal, it is possible that their simultaneous use might result in unexpected behavior, e.g. lead to race conditions. =20 The capabilities of these transport protocols with respect to path maintenance of a reliable, connection-oriented stream protocol are more extensive than the more general layer-3 locator agility provided by Shim6. Therefore, it is recommended that Shim6 is not used for SCTP or MPTCP sessions, and that path maintenance is provided solely by SCTP or MPTCP. There are at least two ways to enforce this behavior. One option would be to make the stack, and in particular the Shim6 sublayer, aware of the use of SCTP or MPTCP and in this case refrain from creating a Shim6 context. The other option is that the upper transport layer, informs using a Shim6-capable API like the one proposed in [RFC6316] that no Shim6 context must be created for this particular communication. =20 In general, the issues described here may also arise for protocols which handle different addresses for two communicating nodes at a higher level than the network-layer to improve reliability, performance, congestion control, etc.=94 =20 =20 | When is happy-eyeballs enough? =20 Umm. In my opinion, the happy-eyeballs algorithm is not related to = Shim6. Happy-eyeballs deals with dual-stack hosts connecting to servers. As discussed in section =913.1 Protocol Version (IPv4 vs. IPv6)=92, Shim6 = is just defined for IPv6. =20 =20 | When should MPTCP | be used? =20 Now this is included in the new SCTP/MPTCP section commented before. =20 | (The introduction to 7 then goes ahead and destroys any | remaining hope that this document provides the answers -- maybe this | should be split into "Open Issues" and the solid information about = where | Shim6 is not needed.) | =20 | The document may have started out as an applicability statement half = a | decade ago, but maybe renaming it to "Considerations on the = Application of | Shim6" provides a more appropriate title now. | =20 | Again, this is meant as a comment on the expectations raised by the = title | and abstract, not as an attempt to belittle the usefulness of the document's | content. | =20 =20 I think I see your point. For me its ok to change the title to =91Considerations on the Application of the Level 3 Multihoming Shim = Protocol (Shim6)=92 I=92ve also changed the abstract to a less ambitious =93This document discusses some considerations on the applicability of = the Shim6 IPv6 protocol and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6.=94 =20 Regarding to splitting section 7 into something like =91open issues=92, = and =91do not mix=92, this is not evident to me. The =91do not mix=92 is comprised = of just two subsections (=91SCTP/MPTCP=92 and =91HIP=92). Besides, the =91open = issues=92 part is very heterogeneous: there are things we are pretty confident that should work (e.g. =91SEND and Shim6=92), complex interactions (eg. NATs will = work as long as there are no changes in the locators, which leads to a = functionality which is not worse than current IPv6, although not as good as Shim6 = could provide=85), things that may work but they should be tested (MIP, NEMO, firewalls)=85 I prefer the current approach in which each =91Shim6 and other=92 = combination is considered separately, without giving further structure to the section (structure that is difficult for me to find). =20 | ** Minor Issues: | =20 | (1) | I'm not so fond of the DHCP speculation in 3.3. An applicability statement | should talk about what is, not what could be. As of today, DHCP is = not | applicable, and that should be clearly stated. (Work in progress = can, of | course, be pointed to, but it is not clear there is much more than a problem | statement.) =20 OK. I=92ve changed the section to this: =20 =933.3. Address Generation and Configuration =20 The security of the Shim6 protocol is based on the use of CGA and HBA addresses. =20 CGA and HBA generation process can use the information provided by the stateless auto-configuration mechanism defined in [RFC4862] with the additional considerations presented in [RFC3972] and [RFC5535]. =20 Stateful address auto-configuration using DHCP [RFC3315] is not currently supported, because there is no defined mechanism to convey the CGA Parameter Data Structure and other relevant information from the DHCP server to the host. An analysis of the possible interactions between DHCPv6 and Cryptographically Generated Addresses (CGAs) can be found in [I-D.ietf-csi-dhcpv6-cga-ps].=94 =20 =20 | =20 | (2) | This sentence in 3.4 is opaque, unless it is talking about the state = of | implementations (or is this another piece of DHCP speculation?): | =20 | There is no current mechanism designed to allow an administrator to | enforce the configuration of a CGA or an HBA in a host. Ok, I=92ve removed it, since the comment is implicit in the previous = section.=20 =20 | =20 | (3) | Section 3.4, 7.2: The term "hybrid" does not occur in RFC 5535. | Adapt the terminology. OK, I adhere to RFC5535 text. Now the text says: =20 =93 In the case that a Shim6-capable host is using HBAs to protect its locator sets, the host will need to generate an address which is both a valid CGA and a valid HBA, as defined in [RFC5535]=94 =20 | =20 | (4) | Section 5.2: | =20 | One such solution is being developed at the MP-TCP Working Group. | =20 | That is not the name of the WG, and referring to ephemeral IETF WGs = is not | very useful in an archival document such as an RFC. It is probably = most | appropriate to reference RFC 6182. Done =20 | =20 | More generally speaking, one would expect some more guidance when | MPTCP is appropriate and when Shim6 is appropriate. Oddly, RFC 6181 | seems to provide more information about Shim6 on this point than the | present document. Well, I think the inclusion of MPTCP along with SCTP provides much more information.=20 Regarding to the information included in RFC6181, this information has = not much to do with this =91application=92 document: RFC6181 describes the = security threats involving locator agility in MPTCP, which have some relation to those faced by Shim6 (that=92s why Shim6 is referred there). These = threats are related to the design of the protocol, but not to the application of the protocol, since once they have been successfully addressed by the = protocol itself, the managers deploying it do not need to care about anymore. So these issues are covered by the Shim6 specification [RFC5533], but do = not need to be considered here, in the applicability considerations. =20 | =20 | (5) | (On a related note, avoid discussion of the Shim6 WG's charter in = 7.5.) Sure. Changed to =93Shim6 aimed to provide a solution to =85=94 =20 | =20 | ** Nits: | =20 | [I-D.ietf-mif-problem-statement] is now RFC 6418. | =20 | The document will benefit from some micro-editing, e.g. | s/different to/different from/g | s/specific of/specific to/g | s/associated to/associated with/g | s/is developed/has been developed/ | The usage of "suffer" in several places | (in particular, should "These problems are suffered by other = solutions | supporting multihoming such as SCTP [RFC4960] or HIP | [RFC4423]." in section 4 not be "relevant to" instead?) | "Shim6 has no means to enforce neither host nor network = forwarding..." Corrected to =93When a locator has been selected by a host to be used as source address for a Shim6 session, Shim6 has no means to enforce an appropriate path for that source address neither in the host nor in the network.=94 =20 | "does not require also" | s/should be review/should be reviewed/ | "...which security features can expect applications and users of the Shim6 | protocol." | As this is typically done by the RFC editor, I'm not providing a = detailed list | here. | =20 | Section 4: s/not being used/not be used/ | =20 | Define "REAP" (I know, RFC5533 doesn't, either). | =20 | Section 6: This sentence is hard to read: | "As long as the address exchanged, IP_A is the ULID..." =20 All these nits have been corrected. =20 Thanks again, Alberto =20 | =20 | _______________________________________________ | shim6 mailing list | shim6@ietf.org | https://www.ietf.org/mailman/listinfo/shim6 ------=_NextPart_000_00AD_01CCFBC3.E04B0870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Carsten,

Thank you very much for your = review

 

|=A0 = -----Mensaje original-----

|=A0 = De: shim6-bounces@ietf.org = [mailto:shim6-bounces@iet= f.org] En nombre

|=A0 de = Carsten Bormann

|=A0 Enviado el: = mi=E9rcoles, 29 de febrero de 2012 23:13

|=A0 Para: IETF Apps Discuss; = draft-garcia-shim6-applicability.all@tools.ietf.org;

|=A0 shim6@ietf.org

|=A0 CC: The IESG

|=A0 Asunto: [shim6] APPSDIR = review of draft-garcia-shim6-applicability-03

|=A0

|=A0 I have been selected as the = Applications Area Directorate reviewer for this

|=A0 draft (for background on = APPSDIR, please see

|=A0 http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAr= eaDirectorate).

|=A0

|=A0 Please resolve these = comments along with any other Last Call comments

|=A0 you may receive. Please = wait for direction from your document shepherd = or

|=A0 = AD before posting a new version of the draft.

|=A0

|=A0 Gruesse, = Carsten

|=A0 = ---------------------------------

|=A0

|=A0 Document: = draft-garcia-shim6-applicability-03.txt

|=A0 Title: Applicability = Statement for the Level 3 Multihoming Shim = Protocol

|=A0 (Shim6)

|=A0 Reviewer: Carsten = Bormann

|=A0 IETF Last Call Date: = 2012-02-15

|=A0 Review Date: 2012-02-29

|=A0

|=A0 ** Summary: This draft is = ready for publication as an Informational

|=A0=A0=A0=A0 RFC with small = changes, but maybe requires a better title.

|=A0

|=A0 Note: I reviewed this with = the expectation that the intended audience will

|=A0 read this *before* looking = at RFC5533–5535 in detail.

|=A0

|=A0 ** Major = Issues:

|=A0

|=A0 General:

|=A0

|=A0 The document provides = useful discussion of considerations around the

|=A0 usage of Shim6.=A0 At the = end, it leaves the reader confused: What *is* = the

|=A0 = applicability/area of application of Shim6?=A0

 

I assume this comment relates = with the expectations created by the title, so I comment = below.

 

|=A0 Who should decide whether

|=A0 Shim6 is activated for a = specific connection?=A0 (There is an API in RFC = 6316,

|=A0 but clearly that is meant for advanced applications.) =

 

This issue was partially addressed in the 'Short-Lived = Communications' subsection. However, I think the text would improve by = placing this in a more prominent place, and by making a clearer = statement. I have appended the following text just to the end of the '2. = Deployment Scenarios' section:

 

“To allow nodes to benefit = from the capabilities provided by Shim6

=A0=A0 (discussed in Section 5) = such as fault tolerance, nodes should be

=A0=A0 configured to initiate a = Shim6 session with any peer node if they

=A0=A0 have multiple locators to = use.=A0 Note that this configuration can be

=A0=A0 performed transparently = to the applications, in the sense that

=A0=A0 applications do not need = to be aware of the Shim6 functionality

=A0=A0 provided by the node; iin = particular, nodes are not forced to use the

=A0=A0 Shim6 API [RFC6316] to = benefit from Shim6.=A0 The Shim6 session should

=A0=A0 be created after the two = nodes have been communicating for some time,

=A0=A0 i.e. using the deferred = context establishment facility provided by

=A0=A0 Shim6.=A0 Otherwise, the = cost of the Shim6 4-way handshake used for

=A0=A0 establishing the session = may exceed the benefits provided for short-

=A0=A0 lived communications (see = Section 5.1.2).=A0 More advanced node

=A0=A0 configuration may = involved configuring different delays for

=A0=A0 initiating the session = for different applications, for example, based

=A0=A0 on a per-port = configuration.=A0 Nodes being able to use a = single

=A0=A0 locator for the communication should not initiate = the creation of a

=A0=A0 Shim6 context, but should participate if other node = initiates it.

=A0=A0 Note that Shim6-aware applications can overrid this = behavior by means

=A0=A0 of the Shim6 API = [RFC6316].”

 

By the way, I've also merged the 'Short-lived' and = 'Long-lived' sections, into a single '5.1.2. Short-lived and long-lived = communications', which is referred in the previous = paragraph.

Does this address your concern?

 

|=A0 While the = document

|=A0 successfully relates Shim6 to SCTP and HIP, what about = other approaches to

|=A0 multi-addressing?=A0

In general, all mechanisms which = handle different addresses at a higher level than the network-layer may = experience unwanted interactions with Shim6. This applies to MPTCP, in = addition to SCTP. Although there was a generic comment regarding to this = at the end of the SCTP section, I have make this more explicit for = MPTCP, by changing the SCTP section to refer to both SCTP and = MPTCP.

 

“7.3.=A0 Shim6, SCTP and =
MPTCP
 
=A0=A0 Both the SCTP [RFC4960] and =
MPTCP [RFC6182] protocols provide a
=A0=A0 reliable, stream-based =
communications channel between two hosts =
which
=A0=A0 provides a superset of the capabilities of =
TCP.=A0 One notable feature
=A0=A0 of these two protocols is that =
they allow the exchange of endpoint
=A0=A0 addresses between hosts, in =
order to recover from the failure of a
=A0=A0 particular endpoint pair, or =
to benefit from multipath =
communication
=A0=A0 in the MPTCP case, in a manner which is =
conceptually similar to
=A0=A0 locator selection in =
Shim6.
 
=A0=A0 SCTP and MPTCP are =
transport-layer protocols, higher in the =
protocol
=A0=A0 stack than Shim6, and hence there is no =
fundamental incompatibility
=A0=A0 which would prevent a =
Shim6-capable host from communicating =
using
=A0=A0 SCTP or =
MPTCP.
 
=A0=A0 However, since either SCTP or =
MPTCP, and Shim6 aim to exchange
=A0=A0 addressing information between =
hosts in order to meet the same
=A0=A0 generic goal, it is possible =
that their simultaneous use might =
result
=A0=A0 in unexpected behavior, e.g. lead to race =
conditions.
 
=A0=A0 The capabilities of these =
transport protocols with respect to =
path
=A0=A0 maintenance of a reliable, =
connection-oriented stream protocol =
are
=A0=A0 more extensive than the more general =
layer-3 locator agility provided
=A0=A0 by Shim6.=A0 Therefore, it is =
recommended that Shim6 is not used for
=A0=A0 SCTP or MPTCP sessions, and =
that path maintenance is provided =
solely
=A0=A0 by SCTP or MPTCP.=A0 There are at least two =
ways to enforce this
=A0=A0 behavior.=A0 One option would be to make =
the stack, and in particular
=A0=A0 the Shim6 sublayer, aware of =
the use of SCTP or MPTCP and in this
=A0=A0 case refrain from creating a =
Shim6 context.=A0 The other option is =
that
=A0=A0 the upper transport layer, informs using a =
Shim6-capable API like the
=A0=A0 one proposed in [RFC6316] that =
no Shim6 context must be created for
=A0=A0 this particular =
communication.
 
=A0=A0 In general, the issues =
described here may also arise for =
protocols
=A0=A0 which handle different addresses for two =
communicating nodes at a
=A0=A0 higher level than the network-layer to =
improve reliability,
=A0=A0 performance, congestion control, =
etc.”
 

 

|=A0 When is happy-eyeballs enough?=A0 =

Umm. In = my opinion, the happy-eyeballs algorithm is not related to Shim6. = Happy-eyeballs deals with dual-stack hosts connecting to servers. As = discussed in section ‘3.1 Protocol Version (IPv4 vs. IPv6)’, = Shim6 is just defined for IPv6.

 

 

|=A0 When should = MPTCP

|=A0 be used?=A0

Now this is included in the new = SCTP/MPTCP section commented before.

 

|=A0 (The introduction to 7 then = goes ahead and destroys any

|=A0 remaining hope that this = document provides the answers -- maybe this

|=A0 should be split into = "Open Issues" and the solid information about = where

|=A0 Shim6 is not needed.)

|=A0

|=A0 The document may have = started out as an applicability statement half a

|=A0 decade ago, but maybe = renaming it to "Considerations on the Application = of

|=A0 = Shim6" provides a more appropriate title = now.

|=A0

|=A0 Again, this is meant as a comment on the expectations = raised by the title

|=A0 and abstract, not as an attempt to belittle the = usefulness of the document's

|=A0 = content.

|=A0

 

I think I see your point. For me its ok to change the title = to ‘Considerations on the Application of the Level 3 Multihoming = Shim Protocol (Shim6)’

I’ve also changed the = abstract to a less ambitious

“This document discusses = some considerations on the applicability of the Shim6 IPv6 protocol and = associated support protocols and mechanisms to provide site multihoming = capabilities in IPv6.”

 

Regarding to splitting section 7 = into something like ‘open issues’, and ‘do not = mix’, this is not evident to me. The ‘do not mix’ is = comprised of just two subsections (‘SCTP/MPTCP’ and = ‘HIP’). Besides, the ‘open issues’ part is very = heterogeneous: there are things we are pretty confident that should work = (e.g. ‘SEND and Shim6’), complex interactions (eg. NATs will = work as long as there are no changes in the locators, which leads to a = functionality which is not worse than current IPv6, although not as good = as Shim6 could provide…), things that may work but they should be = tested (MIP, NEMO, firewalls)…

I prefer the current approach in = which each ‘Shim6 and other’ combination is considered = separately, without giving further structure to the section (structure = that is difficult for me to find).

 

|=A0 ** Minor = Issues:

|=A0

|=A0 (1)

|=A0 I'm not so fond of the DHCP speculation in 3.3.=A0 An = applicability statement

|=A0 should talk about what is, = not what could be.=A0 As of today, DHCP is not

|=A0 applicable, and that should = be clearly stated.=A0 (Work in progress can, of

|=A0 course, be pointed to, but = it is not clear there is much more than a = problem

|=A0 statement.)

 

OK. I’ve changed the = section to this:

 

“3.3.=A0 Address Generation and =
Configuration
 
=A0=A0 The security of the Shim6 =
protocol is based on the use of CGA and =
HBA
=A0=A0 =
addresses.
 
=A0=A0 CGA and HBA generation process =
can use the information provided by
=A0=A0 the stateless =
auto-configuration mechanism defined in [RFC4862] =
with
=A0=A0 the additional considerations presented in =
[RFC3972] and [RFC5535].
 
=A0=A0 Stateful address =
auto-configuration using DHCP [RFC3315] is =
not
=A0=A0 currently supported, because there is no =
defined mechanism to convey
=A0=A0 the CGA Parameter Data =
Structure and other relevant information =
from
=A0=A0 the DHCP server to the host.=A0 An analysis =
of the possible
=A0=A0 interactions between DHCPv6 and =
Cryptographically Generated Addresses
=A0=A0 (CGAs) can be found in =
[I-D.ietf-csi-dhcpv6-cga-ps].”

 

 

|=A0

|=A0 (2)

|=A0 This sentence in 3.4 is = opaque, unless it is talking about the state of

|=A0 implementations (or is this = another piece of DHCP speculation?):

|=A0

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 There is no current = mechanism designed to allow an administrator to

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 enforce the = configuration of a CGA or an HBA in a host.

Ok, I’ve removed it, since = the comment is implicit in the previous section. =

 

|=A0

|=A0 (3)

|=A0 Section 3.4, 7.2:=A0 The term "hybrid" does = not occur in RFC 5535.

|=A0 Adapt the = terminology.

OK, I adhere to RFC5535 text. Now the text = says:

 

“ In the case that a Shim6-capable host is using HBAs = to

=A0 = protect its locator sets, the host will need to = generate

=A0 an address which is both a valid CGA and a valid HBA, = as defined in [RFC5535]”

 

|=A0

|=A0 (4)

|=A0 Section = 5.2:

|=A0

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 One such solution is = being developed at the MP-TCP Working Group.

|=A0

|=A0 That is not the name of the = WG, and referring to ephemeral IETF WGs is not

|=A0 very useful in an archival = document such as an RFC.=A0 It is probably most

|=A0 appropriate to reference = RFC 6182.

Done

 

|=A0

|=A0 More generally speaking, one would expect some more = guidance when

|=A0 MPTCP is appropriate and when Shim6 is appropriate.=A0 = Oddly, RFC 6181

|=A0 seems to provide more information about Shim6 on this = point than the

|=A0 present document.

Well, I think the inclusion of = MPTCP along with SCTP provides much more information. =

Regarding to the information included in RFC6181, this = information has not much to do with this ‘application’ = document: RFC6181 describes the security threats involving locator = agility in MPTCP, which have some relation to those faced by Shim6 = (that’s why Shim6 is referred there). These threats are related to = the design of the protocol, but not to the application of the protocol, = since once they have been successfully addressed by the protocol itself, = the managers deploying it do not need to care about anymore. So these = issues are covered by the Shim6 specification [RFC5533], but do not need = to be considered here, in the applicability = considerations.

 

|=A0

|=A0 (5)

|=A0 (On a related note, avoid discussion of the Shim6 WG's = charter in 7.5.)

Sure. Changed to

“Shim6 aimed to provide a = solution to …”

 

|=A0

|=A0 ** = Nits:

|=A0

|=A0 [I-D.ietf-mif-problem-statement] is now RFC = 6418.

|=A0

|=A0 The document will benefit from some micro-editing, = e.g.

|=A0 s/different to/different = from/g

|=A0 s/specific of/specific to/g

|=A0 s/associated to/associated = with/g

|=A0 s/is developed/has been = developed/

|=A0 The usage of "suffer" in several = places

|=A0 (in particular, should "These problems are = suffered by other solutions

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 supporting = multihoming such as SCTP [RFC4960] or HIP

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [RFC4423]." = in section 4 not be "relevant to" = instead?)

|=A0 "Shim6 has no means to enforce neither host nor = network forwarding..."

Corrected to “When a = locator has been selected by a host to be used as source address for a = Shim6 session, Shim6 has no means to enforce an appropriate path for = that source address neither in the host nor in the = network.”

 

|=A0 "does not require = also"

|=A0 s/should be review/should be = reviewed/

|=A0 "...which security features can expect = applications and users of the Shim6

|=A0 = protocol."

|=A0 As this is typically done by the RFC editor, I'm not = providing a detailed list

|=A0 = here.

|=A0

|=A0 Section 4: s/not being used/not be = used/

|=A0

|=A0 Define "REAP" (I know, RFC5533 doesn't, = either).

|=A0

|=A0 Section 6: This sentence is hard to = read:

|=A0 "As long as the address exchanged, IP_A is the = ULID..."

 

All these nits have been corrected.

 

Thanks = again,

Alberto

 

|=A0

|=A0 = _______________________________________________

|=A0 shim6 mailing = list

|=A0 shim6@ietf.org

|=A0 https://www.ietf.org/mailman/listinfo/shim6

------=_NextPart_000_00AD_01CCFBC3.E04B0870--