Using Conditional Router Advertisements for Enterprise Multihoming
draft-ietf-v6ops-conditional-ras-08

As discussed on telechat, if ietf-rtgwg-enterprise-pa-multihoming enters RFC Editor queue before draft-ietf-v6ops-conditional-ras is published as an RFC, we might ask for this to be held, and the reference to ietf-rtgwg-enterprise-pa-multihoming to be replaced with the RFC.

[Ballot comment]
* Section 3.1.1.

I think a reference to RFC3704 (specifically written for describing ingress filtering for multihomed networks) might be a good addition here to RFC2827

* Sections 3.2.1., 3.2.2. etc.

=> I think it is important to specify (at least the bounds of) the valid lifetimes here as well. e.g. when the preferred lifetime is getting set to zero it is important to specify that the valid lifetime is set to a non zero value so that the host will form an address at all (even though it will not be used when there are preferred addresses). This is important to reduce the potential packet losses when the preferred uplink goes down.

* Section 3.2.2.

I think there is some text missing here about VRRP priorities here. There seems to be an assumption in the draft that the uplink A failure will lead to R1 becoming backup ("If ISP_A uplink is down, then R1 becomes a backup.") and this is not obvious at all. There needs to be a priority change with interface tracking if this has to happen and the backup has to take over as the master.

[Ballot comment]
I'll echo Mirja and Spencer's question about the "empty" security considerations.  (I actually don't much
care for the "This memo introduces no new security considerations" formulation in general, unless it's
literally the only content of the section -- it's either followed by new security considerations, in which
it's just wrong, or followed by calling out specific portions of the referenced security considerations that
are particularly relevant.  In the latter case, it seems useful to provide more of a lead-in like "The general
security considerations of [X] and[Y] apply, and in particular [...]".)

Unfortunately, I don't seem to be in a good position to comment on actual additions to the security considerations
section, since I don't have a clear picture of what the proposal in this document actually changes when compared
to current/normal practices.  This is presumably just a matter of my lacking the appropriate background knowledge
for the routing bits, but in a scenario like Figure 3, with distinct edge and first-hop routers, what kind of RAs would the
first-hop routers normally be sending?  Would they be announcing the routes in question here just without the
PIO markings, or not advertising anything at all, or something else?

Other than that, thanks for the well-written document!

[Ballot comment]
I, too, was confused about the references to ietf-rtgwg-enterprise-pa-multihoming in the abstract, so would support the fixes previously suggested. Furthermore, the places where that document is named should be replaced with direct citations to it, which can then be updated to point to the corresponding RFC if it gets published in time or if it gets converted to a normative reference. Using 'the "ietf-rtgwg-enterprise-pa-multihoming" draft' is not going to age well since it won't always be a draft.

In Section 5.1, I wonder if it's worth pointing out that by supporting enterprise multihoming the techniques described in this document can provide a privacy benefit to users, since remote peers view their traffic as having multiple source addresses?

[Ballot comment]
Thanks to everyone who worked on this document. I have one substantive comment
and a handful of editorial suggestions.

---------------------------------------------------------------------------

§3.3.1:

>  It should be noted that in IPv4 multihoming with NAT, when the egress
>  interface is chosen without taking packet source address into account
>  (as internal hosts usually have addresses from [RFC1918] space),
>  sessions can not be preserved after an uplink recovery.

This isn't necessarily true. For example, if the NAT is tracking which
ISP-facing interface is associated with a given established session, the
sessions will survive restoration of an uplink.  I have exactly such an IPv4
multi-homing configuration working on my home network (with RFC 1918 addresses
assigned to all local devices), and will happily share details of my
configuration with interested parties.

I propose striking this paragraph from the document.

---------------------------------------------------------------------------

§1:

>  general multihoming scenario for enterprise networks and proposes
>  solution which relies heavily on the rule 5.5 of the default address

Nit: "...proposes a solution..."

---------------------------------------------------------------------------

§3.2.6:

>  (as there is no preferred addresses available) and the source address

Nit: "...as there are no..."

---------------------------------------------------------------------------

§3.3:

>  into account any other uplinks properties (such as latencyetc), so

Nit: "...latency, etc.), so..."

---------------------------------------------------------------------------

§3.3.1:

>  interrupted as there is no egress path for those packets and there is
>  not return path from the Internet to the correspodning prefix.  In

Nit: "...there is no return path..."

Nit: "...corresponding..."

---------------------------------------------------------------------------

[Ballot comment]
Thanks to everyone who worked on this document. I have one substantive comment
and a handful of editorial suggestions.

---------------------------------------------------------------------------

§3.3.1:

>  It should be noted that in IPv4 multihoming with NAT, when the egress
>  interface is chosen without taking packet source address into account
>  (as internal hosts usually have addresses from [RFC1918] space),
>  sessions can not be preserved after an uplink recovery.

This isn't necessarily true. For example, if the NAT is performing connection
tracking and recording which ISP-facing interface is associated with a given
established session, the sessions will survive restoration of an uplink.
I have exactly such an IPv4 multi-homing configuration working on my home
network (with RFC 1918 addresses assigned to all local devices), and will
happily share details of my configuration with interested parties.

I propose striking this paragraph from the document.

---------------------------------------------------------------------------

§1:

>  general multihoming scenario for enterprise networks and proposes
>  solution which relies heavily on the rule 5.5 of the default address

Nit: "...proposes a solution..."

---------------------------------------------------------------------------

§3.2.6:

>  (as there is no preferred addresses available) and the source address

Nit: "...as there are no..."

---------------------------------------------------------------------------

§3.3:

>  into account any other uplinks properties (such as latencyetc), so

Nit: "...latency, etc.), so..."

---------------------------------------------------------------------------

§3.3.1:

>  interrupted as there is no egress path for those packets and there is
>  not return path from the Internet to the correspodning prefix.  In

Nit: "...there is no return path..."

Nit: "...corresponding..."

---------------------------------------------------------------------------

[Ballot comment]
Agree with Spencer - I needed to reread the abstract and intro several times to understand the relationship
of this document with rtgwg's. As Spencer noted, I think the first sentence throws the reader off. Suggest
deleting it so as to be more direct.

Same as Spencer - "area" had me wondering if there was/had been such an IETF area, suggest:
in the Source Address Dependent Routing (SADR) area/s/on Source Address Dependent Routing (SADR)

[ Edits by Warren Kumari marked with [WK]]
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Informational.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes using IPv6's RA capabilities to enable simple multihoming for networks connected to two or more upstream Internet Service Providers (ISPs). This document describes tying the advertisement of avaialble address space through the RA to hosts in a network in response to the availability of upstream connectivity, including sample policies.

Working Group Summary:

The v6ops working group discussed this draft extensively, and the authors made several changes to account for working group input. The document did not raise any controversy,; the authors addresses all the comments quickly.

Document Quality:

There are a number of nits to be addressed, according to the id-nits tool. The overall quality of the document is good; the writing style is easily readable, and the explanations are clear. There was no MIB doctor or other outside review required.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Russ White is the document shepherd. The responsible Area Director is [WK]: Warren Kumari.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Other than the nits mentioned above, this document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I reviewed the text of the document, examined the WG discussion on the mailing list archive, verified the referenced documents, and ran the document through the id-nits tool. Other than the id-nits issues, this document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are none that I am aware of.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

[WK]: Yes, all authors have confirmed:
https://mailarchive.ietf.org/arch/msg/v6ops/KZvakIi1t3o56H38h2iLiqp39D8
https://mailarchive.ietf.org/arch/msg/v6ops/BUMmLrjR1pLPR93y3ofc0X50-Sk

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

[WK]: No IPR Disclosures filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Examining the list, it appears there is a solid concensus among the working group in support of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. . Boilerplate checks are not enough; this check needs to be thorough.

The document has some nits according to the id-nit tool. Specifically, the abstract contains a reference which should be "straight text," and there are a number of unused references. There are some other minor nits, specifically in a number of lines which exceed 72 characters, but these appear to be related to figures would be difficult to reformat and remain meaningful.

The document appears to be missing the RFC2119 boilerplate for MUST and SHOULD statements. There are five MUST statements in the document; the authors should either convert these statements to lower case, or include the boilerplate.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

This document does not appear to need any of the mentioned formal reviews.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

There are no new requirements for IANA mentioned in the document. The IANA section of the document accurately reflects this.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are none.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

The only check required for this document was the id-nits check, with results as described above.

[Ballot comment]
I echo Mirja's thanks for a well-written document (and her curiosity about the near-null Security Considerations - there's at least one recommendation in this document, so it seems possible that some security consideration is worth mentioning). But I think I understand this topic, and now I think I understand it much better. Thanks for that.

I do have some minor comments, but they are non-blocking, so do the right thing.

This text toward the bottom of the abstract

  this document
  adopts the approach proposed in the "ietf-rtgwg-enterprise-pa-
  multihoming" draft to provide a solution for a limited number of
  common use cases.

is pretty easy to miss. If the reader misses it, the first sentence is kind of misleading - it just says

  This document discusses the most common scenarios of connecting an
  enterprise network to multiple ISPs using an address space assigned
  by an ISP.

Perhaps it's worth pointing that out in the first sentence, rather than towards the end of the abstract?

I've been on the IESG far too long, but I have tried repeatedly to read

  While some work is being done in the Source Address Dependent Routing
  (SADR) area (such as [I-D.ietf-rtgwg-dst-src-routing]),

without thinking "but SADR isn't an (IETF) area?!?", and I can't do it. If

  While some work is being done on Source Address Dependent Routing
  (SADR) (such as [I-D.ietf-rtgwg-dst-src-routing]),

that would stop startling at least one reader ...

In 3.2.5.  Topologies with Dedicated Border Routers

  For simplicity, all topologies above show the ISP uplinks terminated
  on the first-hop routers.  Obviously, the proposed approach can be
  used in more complex topologies when dedicated devices are used for
  terminating ISP uplinks.  In that case VRRP mastership or interface
  status can not be used as a trigger for conditional RAs and route
  presence as described above should be used instead.

"as described above" might be easier to navigate if it was "as described above in Section 3.1.2" - it's a six-page jump, if I'm tracking this cross reference correctly, and if I'm not, an explicit section reference would be even more appreciated.

I'm not sure that

  It should be noted that the proposed approach is not a silver bullet
  for all possible multihoming scenarios.

"silver bullet" is clear for readers from cultural contexts that don't include werewolves or vampires ... but do the right thing, of course.

It's a nit, but "such as latencyetc".

It's a nit, but "correspodning".

[Ballot comment]
Thanks for the well-written document. Please find some comments below:

1) The shepherd write-up says "The responsible Area Director is Ron Bonica." and questions 7 and 8 say "TBD" and the RFC8174 biolerplate is missing...

2) It seems that ietf-rtgwg-enterprise-pa-multihoming should maybe be a normative reference (and that the abstract should be updated with the respective RFC number as soon as ietf-rtgwg-enterprise-pa-multihoming is published). Any even if it is not a normative reference, should those docs be published together in order to refer to the RFC in the abstract (instead of an draft)?

3) Would it makes sense to also discuss what to do when one ISP is down but packets from that address space are received at the border router? Should those packet be forwarded to that ISP anyway or dropped? Or should they be forwarded to the other ISP with or without address translation?

4) It doesn’t seem right to me that the security consideration section is empty.

5) Lines are too long and therefore cropped in sec 3.2.1 and 3.2.2.

[Ballot comment]
Thanks for the well-written document. Please find some comments below:

1) The shepherd write-up says "The responsible Area Director is Ron Bonica." and questions 7 and 8 say "TBD" and the RFC8174 biolerplate is missing...

2) It seems that ietf-rtgwg-enterprise-pa-multihoming should maybe be a normative reference (and that the abstract should be updated with the respective RFC number as soon as ietf-rtgwg-enterprise-pa-multihoming is published). Any even if it is not a normative reference, should those docs be published together in order to refer to the RFC in the abstract (instead of an draft)?

3)Would it makes sense to also discuss what to do when one ISP is down but packets from that address space are received at the border router? Should those packet be forwarded to that ISP anyway or dropped? Or should they be forwarded to the other ISP with or without address translation?

4) It doesn’t seem right to me that the security consideration section is empty.

5) Lines are too long and therefore cropped in sec 3.2.1 and 3.2.2.

[Ballot comment]
1) The shepherd write-up says "The responsible Area Director is Ron Bonica." and questions 7 and 8 say "TBD" and the RFC8174 biolerplate is missing...

2) It seems that ietf-rtgwg-enterprise-pa-multihoming should be a normative reference (and that the abstract should be updated with the respective RFC number as soon as ietf-rtgwg-enterprise-pa-multihoming is published).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-v6ops-conditional-ras-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-05-21):

From: The IESG
To: IETF-Announce
CC: v6ops@ietf.org, russ@riw.us, v6ops-chairs@ietf.org, draft-ietf-v6ops-conditional-ras@ietf.org, Russ White , warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Using Conditional Router Advertisements for Enterprise Multihoming) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document: - 'Using Conditional Router Advertisements
for Enterprise Multihoming'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-05-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document discusses the most common scenarios of connecting an
  enterprise network to multiple ISPs using an address space assigned
  by an ISP.  The problem of enterprise multihoming without address
  translation of any form has not been solved yet as it requires both
  the network to select the correct egress ISP based on the packet
  source address and hosts to select the correct source address based
  on the desired egress ISP for that traffic.  The "ietf-rtgwg-
  enterprise-pa-multihoming" document proposes a solution to this
  problem by introducing a new routing functionality (Source Address
  Dependent Routing) to solve the uplink selection issue and using
  Router Advertisements to influence the host source address selection.
  While the above-mentioned document focuses on solving the general
  problem and on covering various complex use cases, this document
  describes how the solution proposed in the "ietf-rtgwg-enterprise-pa-
  multihoming" draft can be adopted for a limited number of common use
  cases.  In particular, the focus is on scenarios where an enterprise
  network has two Internet uplinks used either in primary/backup mode
  or simultaneously and hosts in that network might not yet properly
  support multihoming as described in RFC8028.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Informational.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes using IPv6's RA capabilities to enable simple multihoming for networks connected to two or more upstream Internet Service Providers (ISPs). This document describes tying the advertisement of avaialble address space through the RA to hosts in a network in response to the availability of upstream connectivity, including sample policies.

Working Group Summary:

The v6ops working group discussed this draft extensively, and the authors made several changes to account for working group input. The document did not raise any controversy,; the authors addresses all the comments quickly.

Document Quality:

There are a number of nits to be addressed, according to the id-nits tool. The overall quality of the document is good; the writing style is easily readable, and the explanations are clear. There was no MIB doctor or other outside review required.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Russ White is the document shepherd. The responsible Area Director is Ron Bonica.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Other than the nits mentioned above, this document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I reviewed the text of the document, examined the WG discussion on the mailing list archive, verified the referenced documents, and ran the document through the id-nits tool. Other than the id-nits issues, this document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

There are none that I am aware of.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

TBD

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

TBD

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Examining the list, it appears there is a solid concensus among the working group in support of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. . Boilerplate checks are not enough; this check needs to be thorough.

The document has some nits according to the id-nit tool. Specifically, the abstract contains a reference which should be "straight text," and there are a number of unused references. There are some other minor nits, specifically in a number of lines which exceed 72 characters, but these appear to be related to figures would be difficult to reformat and remain meaningful.

The document appears to be missing the RFC2119 boilerplate for MUST and SHOULD statements. There are five MUST statements in the document; the authors should either convert these statements to lower case, or include the boilerplate.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

This document does not appear to need any of the mentioned formal reviews.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

There are no new requirements for IANA mentioned in the document. The IANA section of the document accurately reflects this.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are none.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

The only check required for this document was the id-nits check, with results as described above.