IPv6 Multihoming without Network Address Translation
RFC 7157

[Ballot comment]
I don't think the issues of policy collision have been dealt with at all, to the detriment of interoperability. However, I choose to not hold up this document any longer.

[Ballot discuss]
updated for -03-

5) Security Considerations needs to better address a few threats/considerations.

The additional text echoes my earlier questions, but doesn't have any proposed mitigation other than some hand-waving.
What should an operator do to mitigate these problems? There is no guidance.
In some cases, not mitigating the threat in a consistent manner across implementations means implementing this specification could create security holes in a multi-vendor environment.

- administrators of different networks need to control policies (and nodes' behaviors) independently of other administrators. Some administrators control only nodes that are part of their own networks, while others apparently must be authorized to control nodes across administrative boundaries. So per-user authorization to access and modify the policy configuration might be required.

Existing AAA and network management standards might be able to be used to provide access controls. However, to prevent security holes between trust domains, these access controls need to be able to be configured consistently across vendors' equipment and across administrative boundaries.

- If administrators control nodes across administrative boundaries, there need to be access
controls to prevent violating privacy polices, such as making sure the ISP cannot access names
and addresses of a customer's employees, or names of customers, or deduce organizational structure.

- The need to resolve potential conflicts between policies configured by different
administrators is mentioned, but specific
recommendations for resolving policy conflict is not covered. It is left to the
implementation to decide how to resolve the conflicts. If these conflicts are not resolved
consistently by different implementations, that could affect interoperability and
security trust boundaries. So future work should explicitly address the need for consistent
policy resolution to avoid interoperability and security trust boundary issues.
Until that future work is done, this document should say what implementers should do in their implementations, and what operators should do in their deployments to prevent this issue from compromising their networks.

- Integrity checking for messages carrying policies on-the-wire is needed to prevent policy tampering.

The security directorate review comments in
are worth noting.
A lot of the text in the email might be adapted into considerations.
I reproduce the message text here for the editor's consideration as document text:

There is a fundamental question of who should be trusted to distribute policy. How is the trust established, and how can the network element be assured that it can established that trust before the network is fully configured? This might be quite difficult, because there could be more than one policy distributor, each with a slightly different view of the network (imagine P1 that can see external networks A and B, and P2 that can see networks B and C). It seems inevitable that a host will have to be able to merge policies and deal with updates.
Further, a host might have its own policies to merge into the mix. For example, it might require a DNSSEC capable server for queries about network A, but the policy might specify a non-DNSSEC server for that network. Thus, I can see a need for hosts to communicate their security requirements to the policy server.
There are issues about the privacy of the policy itself. Perhaps particular network prefixes reveal business relationships that are confidential. Thus, some policy information might be sent on encrypted channels.
What kind of policy enforcement is necessary? If a host violates the multihoming policy and sends a packet with a source address that is appropriate to network A over the path to network B, should the packet be blocked, redirected, or allowed? What about DNS queries that are sent to a server that is not recommended for the target? Quash, redirect, or allow? What information should go back to the host?
I think that most of these comments apply to any policy server, and I believe that various IETF documents in the past have attempted to define generic security considerations for them.



6) This is an Informational document, why are we using RFC2119 keywords?
(i.e., why are we including the reference to RFC2119 in the text?)
5.3 contains a number of "should" statements. Are these RFC2119 SHOULDs?
If so, they would stand out better if capitalized.

7) new. The new text is apparently written by a non-native-English speaker, and some of the sentences are difficult to parse. Worse, this makes it difficult to interpret the meaning of some sentences to be clear and unambiguous. I recommend the use of active voice to make it clear which actors are expected to perform what actions. I find the following very unclear about who is supposed to trust (authenticate/authorize) whom:
            For policy receiver side, who should be trusted to accept 
            policies is a fundamental issue.  How is the trust established, 
            and how can the network element be assured that it can 
            established that trust before the network is fully configured. 
            If a policy receiver trusts untrusted network, it will cause 
            that distributing unwanted and unauthorized policy that 
            described below.
This text came from questions from a secdir review, and the questions are echoed, but not responded to.

[Ballot comment]
As we discussed (and I believe agreed) at the IETF meeting in Taipei, the last paragraph of section 1 really needs to be changed to properly address the scope of this document. It is not that you "conclude" that DHCP is the best option here; you are doing a survey of current issues and describe how one widely available technology (DHCP) can be used to address those issues.

[Ballot discuss]
There is no mention of SHIM6 or HIP, both of which are relevant to the goal of supporting multihoming without NAT in IPv6.  If the authors (and presumably the WG?) feel these are inappropriate for the goal, it should really be explained why.  Is there WG consensus on this?

[Ballot discuss]
updated for -01-

1,2,3,4) OK

5) Security Considerations provides details about the threats or mitigation
specific to this specification. This is a significant improvement from -00-.
However, there are still a few threats/considerations that deserve more mention.

- administrators of different networks seem to
need to control policies (and nodes' behaviors) independently of other
administrators. The need to have **access controls** for such cross-administrative
policy access is not discussed.

- administrators must control only nodes that are part of their own networks, or some
administrators must control only nodes that are part of their own networks, while others
are authorized to control nodes across administrative boundaries. So per-user authorization
might be required. Existing AAA and network management standards might be able to provide this.

- If administrators control nodes across administrative boundaries, there need to be access
controls to prevent violating privacy polices, such as making sure the ISP cannot access names
and addresses of employees, or names of customers, or deduce organizational structure.

- The need to resolve potential conflicts between policies configured by different
administrators is now discussed in -01- Security Consideration. But specific
recommendations for resolving policy conflict is not covered. It is left to the
implementation to decide how to resolve the conflicts. If they are not resolved
consistently by different implementations, that could affect interoperability and
security trust boundaries. So future work should explicitly address the need for consistent
policy resolution to avoid interoperability and security trust boundary issues.

- Integrity checking for message carrying policies on-the-wire, to prevent policy tampering.

The security directorate review comments in
are worth noting.
A lot of the text in the email might be adapted into considerations.
I reproduce the message text here for the editor's consideration as document text:

There is a fundamental question of who should be trusted to distribute policy. How is the trust established, and how can the network element be assured that it can established that trust before the network is fully configured? This might be quite difficult, because there could be more than one policy distributor, each with a slightly different view of the network (imagine P1 that can see external networks A and B, and P2 that can see networks B and C). It seems inevitable that a host will have to be able to merge policies and deal with updates.
Further, a host might have its own policies to merge into the mix. For example, it might require a DNSSEC capable server for queries about network A, but the policy might specify a non-DNSSEC server for that network. Thus, I can see a need for hosts to communicate their security requirements to the policy server.
There are issues about the privacy of the policy itself. Perhaps particular network prefixes reveal business relationships that are confidential. Thus, some policy information might be sent on encrypted channels.
What kind of policy enforcement is necessary? If a host violates the multihoming policy and sends a packet with a source address that is appropriate to network A over the path to network B, should the packet be blocked, redirected, or allowed? What about DNS queries that are sent to a server that is not recommended for the target? Quash, redirect, or allow? What information should go back to the host?
I think that most of these comments apply to any policy server, and I believe that various IETF documents in the past have attempted to define generic security considerations for them.



6) This is an Informational document, why are we using RFC2119 keywords?
(i.e., why are we including the reference to RFC2119 in the text?)
5.3 contains a number of "should" statements. Are these RFC2119 SHOULDs?
If so, they would stand out better if capitalized.

[Ballot discuss]
1 - SCTP is mentioned as "application transport level"; do you mean "transport layer for applications that can use SCTP?"  It should be clear that SCTP only works for applications that use it, not host-wide.

2 - There is no mention of SHIM6 or HIP, both of which are relevant to the goal of supporting multihoming without NAT in IPv6.  If the authors (and presumably the WG?) feel these are inappropriate for the goal, it should really be explained why.  Is there WG consensus on this?

3 - Section 3.1, Scenario 1 has: "e.g., broadband service (Internet, VoIP, IPTV, etc.)", but I don't understand how that relates to the figure, should it actually say "e.g. multiple broadband service providers"?  The parts in parenthesis don't make sense to me in how they relate to the figure or rest of the text.  For instance, every VoIP service I've used always worked over the existing broadband provider I had, or was a service from that provider, and did not involve a separate router from the Internet service.

4 - Scenario 2 lists VPN as an example, but this would usually have Router 2 and Network 2 on the right side of Network 1 connected to the host or gateway via a tunnel, so I don't understand this example, even though the scenario itself makes sense, the example seems either poor or poorly described (overly terse).  This doesn't seem to illustrate anything to do with how VPN works.

[Ballot comment]
in section 3, figure 2 now shows "hosts" while figure 3 and 4 show a singular "host"; I assume this should have been made plural throughout

[Ballot discuss]
2- The mention of SCTP multihoming in the introduction is not quite correctly used here, since it only works for applications that are built on top of SCTP, and only provides limited functionality for those specific applications within an SCTP association, not host-level or interface-level functions as can be provided below in the network layer.

1 - SCTP is mentioned as "application transport level"; do you mean "transport layer for applications that can use SCTP?"

2 - There is no mention of SHIM6 or HIP, both of which are relevant to the goal of supporting multihoming without NAT in IPv6.  If the authors (and presumably the WG?) feel these are inappropriate for the goal, it should really be explained why.  Is there WG consensus on this?

3 - Section 3.1, Scenario 1 has: "e.g., broadband service (Internet, VoIP, IPTV, etc.)", but I don't understand how that relates to the figure, should it actually say "e.g. multiple broadband service providers"?  The parts in parenthesis don't make sense to me in how they relate to the figure or rest of the text.  For instance, every VoIP service I've used always worked over the existing broadband provider I had, or was a service from that provider, and did not involve a separate router from the Internet service.

4 - Scenario 2 lists VPN as an example, but this would usually have Router 2 and Network 2 on the right side of Network 1 connected to the host or gateway via a tunnel, so I don't understand this example, even though the scenario itself makes sense, the example seems either poor or poorly described (overly terse).  This doesn't seem to illustrate anything to do with how VPN works.

[Ballot comment]
These recommendations from Joe Touch and Rich Woundy would improve the readability of the document:

(From Joe Touch)
"The same situation that depends on NAT technique may be brought to the IPv6 world."
might be better as:
""Some of the same reasons for IPv4 NATs may be applicable to IPv6."

E.g., larger address space isn't a reason, but address hiding, address
independence, and service isolation may be. It might even be useful to
include a brief such list.

(From TSVDIR review by Rich Woundy)
> Can you do a tsvdir review of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat?

Here are my high level comments on this internet draft.

- The document covers host and gateway requirements, but omits any service provider requirements (eg DHCPv6 option support).
- The security considerations are weak (eg "evil policy") and should be more detailed.
- The source address selection drafts are dead or expired, which does not provide confidence that anyone is working on one of the key solutions advocated by this draft.
- Someone should review the entire document for English grammar, especially section 1.

But if these issues were resolved, this would be a good draft that solves important IPv6 deployment issues.

Detailed comments.

Section 1.

>NAT based multihoming is easily deployable and already deployed technique.

"an already deployed technique"

>The same situation that depends on NAT technique may be brought to the IPv6 world.

Maybe should say "The same situations that require the NAT technique to be used in the IPv4 world may be applicable to the IPv6 world?"

> Whenever a host or small network (which does not meet minimum IPv6 allocation criteria) is connected to multiple upstream networks IPv6 address is assigned by each respective service provider...

"an IPv6 address is assigned"

> resulting in hosts with more than one active IPv6 addresses.

"one active IPv6 address"

> As each service provided is allocated...

"service provider"

> So, the goals for IPv6 multihoming definced in [RFC3582] do not exactly match the goals of us.

"defined in" and "match the goals of this document"

> If multiple routers exist on a single link the host must appropriately select next-hop for each connected network.

"must select the appropriate next-hop"

> it is conceivable that the packets that have inappropriate source address...

"have an inappropriate source address"

> A DNS query sent to an arbitrary upstream resolver may result in incorrect or poisoned responses

Add a period to the end of the sentence.

> A possible consequence of assigning a host multiple identical-scoped addresses...

"identically-scoped"

Section 3.3.

> making it essential for the host to correctly resolve these three criteria before sourcing the first packet.

"resolve these three items..."

Section 4.2.

This section is entitled "Policy providing", which feels like a very awkward term. Have you considered "Policy distribution" or something similar?

I think there may be a few missing requirements for "providing mechanisms". For one, administrators of different networks seem to need to control policies (and nodes' behaviors) independently of other administrators. For another, administrators must control only nodes that are part of their own networks.

Section 5.

General comment. This draft puts requirements on the host (O/S), home gateway and ISP. Any one missing piece will break this solution. This all-or-broken approach makes this solution unlikely to be successful for some time because we can't have an incremental approach. That said, if we have all the pieces, this "should" work.

Section 5.1.

> Scenario 1: "Host" needs to support the solution for this problem
> Scenario 2: "Host" needs to support the solution for this problem

Missing periods. Also note that the service providers (ie ISP and enterprise / VPN) must also support this solution (ietf-6man-addr-select-opt).

Section 5.2.

> Scenario 1: "Host" needs to support the solution for this problem
> Scenario 2: "GW rtr" needs to support the solution for this problem
> Scenario 3: "Host" needs to support the solution for this problem

Missing periods. Also note that the service providers (ie ISP and enterprise / VPN) must also support this solution (ietf-mif-dhcpv6-router-option).

Section 5.3.

> [I-D.ietf-mif-dns-server-selection] proposes a solution for DNS server selection policy providing solution with a DHCPv6 option.

Perhaps it would be simpler to say "[I-D.ietf-mif-dns-server-selection] proposes a solution for distributing DNS server selection policy using a DHCPv6 option."

> Scenario 1: "Host" needs to support the solution for this problem
> Scenario 2: "GW rtr" needs to support the solution for this problem
> Scenario 3: "Host" needs to support the solution for this problem

Missing periods. Also note that the service providers (ie ISP and enterprise / VPN) must also support this solution (ietf-mif-dns-server-selection).

Section 6.1.

> the staticness of the assumed target network environment.

"static nature of the assumed target..."

Section 6.2.

> The DHCPv6 mechanism does not have these difficulties and has the advantages of its relaying functionality.

"has the advantage..."

> The alternative of a policy-based approach is documented in [I-D.ietf-mif-dns-server-selection],where several pairs of DNS

", where..."

Section 7.2.

> 7.2.  Co-exisitence consideration

"Co-existence"

> An idea to achieve this is that GW-rtr identifies the hosts, and then assigns single prefix to non-MHMP hosts and assigns multiple prefix to MHMP hosts.

"a single prefix" and "multiple prefixes".

> In this case, GW-rtr can perform IPv6 NAT only for the traffic from MHMP hosts if its source address is not appropriate.

The MHMP hosts follow the recommendations of this draft, so they don't need IPv6 NAT by definition. Shouldn't this sentence refer to "traffic from non-MHMP hosts"?

> Another idea is that GW-rtr assigns multiple prefix to the both hosts

"multiple prefixes to both hosts"

> In this case, non-MHMP host can access the service through the NAT box.

"the non-MHMP host"

Section 8.

> A policy receiver may receive an evil policy from a policy distributor.

The wording of the Security Considerations section indicate to me that there was no security review of this document. What makes a policy "evil"? Is it because some third party is pretending to be the administrator in distributing policies (ie you need authentication)? Is it because some third party changed the policies in transit, or the policies were corrupted in transit (ie you need integrity checking)?

The authors should take into consideration these security directorate review comments: .

Incidentally, what happens when there are policy conflicts between independent administrators? Who wins?

> A policy distributor should expect some hosts in his network do not follow the distributed policy.

Maybe be even stronger: "will not follow". How can this situation be detected and remediated?

Section 11.1.

> [I-D.ietf-6man-addr-select-opt]
> Matsumoto, A., Fujisaki, T., and J. Kato, "Distributing
> Address Selection Policy using DHCPv6",
> draft-ietf-6man-addr-select-opt-00 (work in progress),
> December 2010.

This normative reference is 'expired'
(http://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/).

> [I-D.ietf-6man-addr-select-sol]
> Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution
> approaches for address-selection problems",
> draft-ietf-6man-addr-select-sol-03 (work in progress),
> March 2010.

This normative reference is 'dead' (http://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-sol/).

That tells me that both normative references to the preferred source address selection solution are invalid. So do we have a solution to one of the key issues raised by this internet-draft???

From Dave Harrington:
s/offering a renaissance/, offering a renaissance/
otherwise it appears the "requirement for NAT" offers the renaissance, rather than the "without ... NAT" offering the renaissance. It would be much clearer if this were two sentences. and it could be reworded to be technically much clearer than "renaissance".
I agree that an English speaker should go through this document to clarify the English, which uses a lot of phrases and clauses without neccesarily clarifying them by using appropriate punctuation. The RFC Editor will catch many of them, but many of these small changes might impact the representation of WG consensus, and the only real check that the RFC Editor changes are correct happen in AUTH48 by the same authors who didn't write clear text in the first place, presumably because sections were written by editors for whom English is not their native tongue.
Acronyms are used without references on first use; for example uRPF
in 3.2, scenario 2,
"This gateway router would receive prefix delegations from each independent service provider network and a different set of DNS resolvers." This sentence construction makes it unclear whether the "different set of DNS resolvers" means a set for each provider, or a customer DNS resolver that resolves for both networks. The following sentence doesn't really clarify the scenario. This would be clearer if the sentence was structured as "This gateway router would receive prefix delegations and a set of DNS resolvers from each independent service provider network." (which I assume is what you mean to say).
It would probabyl be helpful if you actually labeled the DNS provider in the scenario diagram.
in the problem statement, scenario 3 bullet 2. Is this a description of a problem? Am I missing what the problem is when "an approrpiate source address will be selected"?
in 4.1, it took me a while to understand the point you wanted to make. There is discussion of a developer "being tempted to assume". So I expected the requirement to address the temptation issue, and whether the developer's assumptions were right or wrong. I think this requirement would be clearer if you didn't express it as "tempted to assume", but rather that end-to-end transparency is required so developers **do not need to** work with complex mechanisms to work around  e2e impediments, as is common in a NAT'd IPv4 environment.
in 4.2, I think the "make nodes behave differently" is too abstract; I think you need some real examples here.
4.3 seems to light; are there any industry numbers available that could help to quantify the scale?

[Ballot discuss]
1) This normative reference is 'expired'
(http://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt/).

2) This normative reference is 'IESG dead' (http://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-sol/).

3) Without these expired drafts, the proposal would be incomplete.

4) - The document covers host and gateway requirements, but omits any service provider requirements (eg DHCPv6 option support). A lack of service provider support for the necesary operational infrastructure could prevent deployments from working properly.

This draft puts requirements on the host (O/S), home gateway and ISP. Any one missing piece will break this solution. This all-or-broken approach makes this solution unlikely to be successful for some time because we can't have an incremental approach.

5) Security Considerations provides no details about the threats or mitigation specific to this specification.  The reference to [RFC4218] does not cover any vulnerabilities introduced by the solutions proposed here, nor how to mitigate those new vulnerabilities.

I recommend including a quick summary of the threats for IPv6 multihoming here, then a discussion of how the proposed solutions mitigate the threats, and introduce new vulnerabilities.

A few specific issues, for example:
administrators of different networks seem to need to control policies (and nodes' behaviors) independently of other administrators. The need to have access controls for such adninistrative access is not discussed in the security considerations.

The need to resolve potential conflicts between policies configured by different administrators is not really addressed in the security considerations. How will policy conflicts be resolved? If they are not resolved consistently by different implementations, that could affect interoperability and security trust boundaries.


6) 5.3 contains a number of "should" statements. Are these RFC2119 SHOULDs? That is why we have the RFC2119 text in section 2, right?
If so, they would stand out better if capitalized.
If so, why is this an Informational document?
If this is an Informational document, why are we using SHOULDs?

[Ballot discuss]
I support Wes's DISCUSS. This document is very thin when it comes to examining technologies available to hosts having to deal with multihoming. Indeed, in addition to SCTP, HIP and SHIM6, the document also ignores MPTCP. But overall, the document does a lot of "handwaving" when it comes to issues of how applications deal with a multihomed environment. The document ignores the requirement of legacy apps that IP addresses remain stable over long periods of time (because once address selection is done for an app, connections will be torn down if that address changes). It refers to different DNS resolvers, but waits until section 6 to even mention that the reason that any of this makes a difference is because of broken split-horizon implementations, and even there only vaguely mentions split-horizon. This document does not seem to have had enough review.

[Ballot comment]
1- the abbreviation ASP is used without explanation

2- In the third paragraph of the introduction that says "... more than one active IPv6 addresses", it should be more clear that the multiple addresses are actually multiple global scope addresses with different prefixes, since all IPv6 hosts have multiple addresses even with only one provider.  The "For example" sentence is also strange in this paragraph since it points to a situation not with multiple link providers but with a single link provider and an additional address from another network connected via a tunnel which is a different use case than multihoming via multiple link providers.

[Ballot discuss]
1- Section 6 and 7 are outside of the Abstract's stated scope and are a little confusing because they don't seem to very clearly or directly give any conclusion about these approaches with regard to the stated requirements.  If this is really supposed to be a problem statement and requirements document, then these sections either don't belong, or at least need to be better described with regards to the stated requirements.

2- The mention of SCTP multihoming in the introduction is not quite correctly used here, since it only works for applications that are built on top of SCTP, and only provides limited functionality for those specific applications within an SCTP association, not host-level or interface-level functions as can be provided below in the network layer.

3 - Strangely, there is no mention of SHIM6 or HIP, both of which would be more appropriate than SCTP to bring into the discussion.  There's only a very passing reference to SHIM6 and no discussion of a technical shortcoming or comparison of the resulting requirements that this document develops.

4 - One point of confusion in all of the scenarios in section 3 is why there is only a single host, rather than a small network as was described in the introduction.  In a small network, is it expected that all hosts are on a link, or do they have independent links to the routers in some of the scenarios?  This is not clear.

5- Section 3.1, Scenario 1 lists broadband service as an example.  I may just be uninformed, but I've used several broadband service providers and never had such a setup with multiple routers connected to a single host on the same link.  Is this really a good example of how this scenario would occur in real life?

6 - Scenario 2 lists VPN as an example, but this would usually have Router 2 and Network 2 on the right side of Network 1 connected to the host or gateway via a tunnel, so I don't understand this example, even though the scenario itself makes sense, the example seems either poor or poorly described (overly terse).

[Ballot discuss]
Section 6 and 7 are outside of the Abstract's stated scope and are a little confusing because they don't seem to very clearly or directly give any conclusion about these approaches with regard to the stated requirements.  If this is really supposed to be a problem statement and requirements document, then these sections either don't belong, or at least need to be better described with regards to the stated requirements.

The mention of SCTP multihoming in the introduction is not quite correctly used here, since it only works for applications that are built on top of SCTP, and only provides limited functionality for those specific applications within an SCTP association, not host-level or interface-level functions as can be provided below in the network layer.

Strangely, there is no mention of SHIM6 or HIP, both of which would be more appropriate than SCTP to bring into the discussion.

In the third paragraph of the introduction that says "... more than one active IPv6 addresses", it should be more clear that the multiple addresses are actually multiple global scope addresses with different prefixes, since all IPv6 hosts have multiple addresses even with only one provider.  The "For example" sentence is also strange in this paragraph since it points to a situation not with multiple link providers but with a single link provider and an additional address from another network connected via a tunnel which is a different use case than multihoming via multiple link providers.

One point of confusion in all of the scenarios in section 3 is why there is only a single host, rather than a small network as was described in the introduction.  In a small network, is it expected that all hosts are on a link, or do they have independent links to the routers in some of the scenarios?  This is not clear.

Section 3.1, Scenario 1 lists broadband service as an example.  I may just be uninformed, but I've used several broadband service providers and never had such a setup with multiple routers connected to a single host on the same link.  Is this really a good example of how this scenario would occur in real life?

Scenario 2 lists VPN as an example, but this would usually have Router 2 and Network 2 on the right side of Network 1 connected to the host or gateway via a tunnel, so I don't understand this example.

[Ballot discuss]
The mention of SCTP multihoming in the introduction is not quite correctly used here, since it only works for applications that are built on top of SCTP, and only provides limited functionality for those specific applications within an SCTP association, not host-level or interface-level functions as can be provided below in the network layer.

[Ballot comment]
Please note the secdir review from Hilarie Orman, [1]
I think the points made there are worth noting in the
security considerations section. There is text in the
review that could almost be cut and pasted for that.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg02739.html

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (IPv6 Multihoming without Network Address Translation) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'IPv6 Multihoming without Network Address Translation'
  as an
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 2011-06-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


Network Address and Port Translation (NAPT) works well for conserving
global addresses and addressing multihoming requirements, because an
IPv4 NAPT router implements three functions: source address
selection, next-hop resolution and optionally DNS resolution.  For
IPv6 hosts one approach could be the use of IPv6 NAT.  However, NAT
should be avoided, if at all possible, to permit transparent host-to-
host connectivity.  In this document, we analyze the use cases of
multihoming.  We also describe functional requirements for
multihoming without the use of NAT in IPv6 for hosts and small IPv6
networks that would otherwise be unable to meet minimum IPv6
allocation criteria.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/


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

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document shepherd is Fred Baker. Yes, I believe that it is ready for IESG consideration.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document originated from a service provider's statement that it wanted to multi-home all of its residential customers and therefore needed a multihoming solution that addressed specific problems. For the most part, it has served as a focused problem statement for MIF and other working groups. As such, it has been reviewed not only by people in v6ops, but also people in MIF.

Consistent with v6ops' charter, for a while the authors and chairs were content to let it live as an internet draft and die when the job was done. However, the working group wound up deciding that it captured some important parts of the problem and deserved archival storage. Hence, we're suggesting publication as an RFC.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I do not believe that it needs further review. It contains no formal language specifications, makes no specific security recommendations, and adds no new operational issues that have not come up in the shim6 or similar discussions.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of?

No

(1.e) 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?

I believe that the working group generally understands and agrees with the document. I have heard no statements of dissent.

(1.f) 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
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the
Internet-Drafts Checklist

and
http://tools.ietf.org/tools/idnits/
). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The draft meets all points, with one exception. The current draft of this document was posted on 29 March, and one of the documents it refers to (http://tools.ietf.org/html/draft-ietf-mif-dns-server-selection) was reposted (from -01 to -02) on 12 April. That shows as an out of date reference. That can be picked up by the RFC Editor or in the process of addressing an IESG or IETF Last Call comment; I don't see the point of worrying about it just now.

(1.h) Has the document split its references into normative and
informative?

Yes it has.

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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].



(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

This document has no IANA actions, and says as much.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no such sections.

(1.k) 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

Network Address and Port Translation (NAPT) works well for conserving
global addresses and addressing multihoming requirements, because an
IPv4 NAPT router implements three functions: source address
selection, next-hop resolution and optionally DNS resolution. For
IPv6 hosts one approach could be the use of IPv6 NAT. However, NAT
should be avoided, if at all possible, to permit transparent host-to-
host connectivity. In this document, we analyze the use cases of
multihoming. We also describe functional requirements for
multihoming without the use of NAPT in IPv6 for hosts and small IPv6
networks that would otherwise be unable to meet minimum IPv6
allocation criteria.

Working Group Summary

This was originally posted in May 2010 discussed at IETF-78 in Maastricht, and reported on in IETF-79 at Beijing. The working group requested that it become a working group draft; it was originally posted as draft-ietf-v6ops-multihoming-without-nat66 in December 2010, and reposted as draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat in March 2011.

It has in essence been a requirement document feeding into 6MAN and MIF. Related work in those working groups has been proceeding to bring the issues to closure.

Document Quality

The document describes a network paradigm being used by certain networks in Japan, and describes the issues that prevent them from deployment. As such, its intent and result has been to focus action on the resolution of those problems.