Subject: Re: [v6ops] New Version Notification - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt

From: Fred Baker <[email-masked]>
Date: Thu, 17 Nov 2011 22:06:52 +0800

Folks:

Please review http://tinyurl.com/7gw45ma and comment. In view of a US holiday next week, I'll give you through 2 December. The changes have been made in response to IESG "Discuss" comments. The question is whether the working group still agrees with the draft.

Fred

On Nov 15, 2011, at 2:28 PM, [email-masked] wrote:

> New version (-03) has been submitted for draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt.
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
> 
> 
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03
> 
> IETF Secretariat.

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 22 Nov 2011 00:11:26 +0900

Thanks Fred,

As an author of this draft, I'm very happy to see the progress of the draft. Thank you for all of your comments, contributes, and supports.

This draft describes issues of IPv6 multihoming when an operator try it without any kind of IPv6 NAT. Our conclusion is that DHCPv6 is expected as most realistic solution to solve the issues. We also understand that it might not be a perfect solution for that. We're not dreamer, so we have to adopt solution by which the issues can be solved, is available _right now_. It could be helpful current DHCPv6 discussion in the mif and dhc wg to provide an IPv6 multihoming use case.

We, authors of this draft, appreciate if v6ops working group continuously supports the work of this draft.

Best regards,
--satoru

On 2011/11/17, at 23:06, Fred Baker wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Nov 2011 11:25:57 +1300

I still support this draft as modified.

There is a new concern however, namely the strenuous objections that
have been raised recently against draft-ietf-mif-dhcpv6-route-option.
If that document is blocked, this document becomes pointless, or
at least needs major rewriting to explain how RA/RIO (RFC 4191) can
be used despite its problems.

Also, I know this is far too late, but I really didn't like the Abstract
when I read it again. It seems to say the least important thing first and
comes across as negative. I propose a complete rewrite:

This document describes a practical approach to multihoming a small IPv6
user site using readily available solutions that permit address transparency
without sacrificing security. Specifically, such a site requires source
address selection, next-hop resolution and DNS resolution. We analyze the
use cases of multihoming and describe functional requirements and possible
solutions for multihoming for hosts and small IPv6 networks that are unable
to meet minimum IPv6 address allocation criteria. Such sites can only use
address space derived from their multiple providers. We conclude that DHCPv6
based solutions are suitable to meet the multihoming issues described in
this document. In particular, we show that the IPv4 approach to this problem
based on Network Address and Port Translation (NAPT) is unnecessary for IPv6,
although Network Prefix Translation (NPTv6) might be appropriate in some
transitional situations.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Nov 2011 00:34:11 +0000

On Nov 21, 2011, at 5:25 PM, Brian E Carpenter wrote:

Using the DHCPv6 route option, even if it is approved, to solve this problem is unnecessary and, I would claim, harmful.   What you should actually do is clear the A bit on one of the two advertised prefixes, and also set the M bit in the RA message.   Now you can trivially control which hosts use the second prefix, using DHCP, which prevents broken hosts from autoconfiguring addresses on it.

Fundamentally, what this draft seems to be saying is "a plurality of IPv6 implementations are broken.   Some IPv6 implementations are not broken.   Here's how you do multihoming for non-broken hosts without causing broken hosts to *completely* fail."   I do not love this solution.   The right thing to do is to fix the broken hosts.   I'm against changing the IPv6 architecture to deal with this problem.

Since it's possible to write this document without changing the IPv6 architecture, I think that's the right thing to do.

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 22 Nov 2011 10:43:12 +0900

> Using the DHCPv6 route option, even if it is approved, to solve this problem is unnecessary and, I would claim, harmful.   What you should actually do is clear the A bit on one of the two advertise…

This draft mentions not only which prefix hosts use.
Please read the scenarios in the draft.

> Fundamentally, what this draft seems to be saying is "a plurality of IPv6 implementations are broken.   Some IPv6 implementations are not broken.   Here's how you do multihoming for non-broken host…

This draft doesn't mention implementation specific brokenness.
Again, please read the scenarios in the draft.

> Since it's possible to write this document without changing the IPv6 architecture, I think that's the right thing to do.

I'm not sure what the IPv6 architecture you assume. We don't say that RA is not necessary, but we say DHCPv6 is most realistic to solve multihoming issue without any kind of IPv6 NAT. Do you say that without changing the IPv6 architecture means IPv6 NAT is the right thing to do?

cheers,
--satoru

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Nov 2011 03:42:06 +0000

> Please read the scenarios in the draft.

I did, but the third scenario is just a MIF scenario, not a multihoming scenario.   It's part of the MIF problem statement.

> Again, please read the scenarios in the draft.

It's true that the draft doesn't call it brokenness, but what it talks about _is_ brokenness, whether it's called that or not.

> I'm not sure what the IPv6 architecture you assume. We don't say that RA is not necessary, but we say DHCPv6 is most realistic to solve multihoming issue without any kind of IPv6 NAT. Do you say th…

No, that is not my position at all.   My position is that none of the scenarios you've described require a DHCPv6 route option to fix.   Indeed, the DHCPv6 route option is the wrong solution in all three scenarios: it perpetuates brokenness instead of fixing the very real problems you've described.

These are exactly the same problem scenarios that I talked about in my presentation in the DHC working group meeting.   There is wide agreement that these scenarios are a problem.   The MIF working group was chartered to fix at least scenario 3, and scenario 1 is in the problem statement as well.   Scenario 2 is the "really ugly problem" I described in my presentation in the DHC working group.

These problems are solvable, and I think the MIF working group is capable of solving them (although Scenario 2 will require some help from 6man).   I don't think we should be throwing out wholesale pieces of the internet architecture (specifically, RA) to solve this problem.   Or perhaps I should say that if we are considering doing that, we should admit that that's what we're considering.

I'm agnostic—it's pretty obvious to me that we can solve this with some backwards-compatible changes to RA.  So even though I personally would have preferred to use DHCP to solve this entire set of problems, since we didn't do that, I think we should just fix RA.

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 22 Nov 2011 22:00:36 +0900

> No, that is not my position at all.   My position is that none of the scenarios you've described require a DHCPv6 route option to fix.   Indeed, the DHCPv6 route option is the wrong solution in all…

While a customer site is multihoming and operators need to advertise its routing information, BGP might be an appropriate solution but it's obviously too much. RA with RIO should work, but it's too much to configure all hosts individually by RA with the current operational experience. 

> These are exactly the same problem scenarios that I talked about in my presentation in the DHC working group meeting.   There is wide agreement that these scenarios are a problem.   The MIF working…

Ok, you can see these three scenarios in our draft are in a problem. I suppose that you have an idea to solve that without DHCPv6. But I didn't attend last dhc meeting so I appreciate if you share your presentation since I couldn't find your slides on the ietf web site.

> These problems are solvable, and I think the MIF working group is capable of solving them (although Scenario 2 will require some help from 6man).   I don't think we should be throwing out wholesale…

I understand that. I don't say that we should be throwing RA out. However, I say that route option for DHCPv6 is needed for operator's reality.

> I'm agnostic—it's pretty obvious to me that we can solve this with some backwards-compatible changes to RA.  So even though I personally would have preferred to use DHCP to solve this entire set of…

If it is possible to change RA with backword-compatible, I think that it should be nice. Unfortunately, it hasn't been done so far vice versa. 

cheers,
--satoru

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Nov 2011 15:23:35 +0000

On Nov 22, 2011, at 4:21 AM, Mr.R.A.Hunter wrote:
When you write "trivially control", what's the refresh/flush mechanism to inform end nodes of a (link) status change?

The point of my message was simply to point out that if you want to control the end nodes using DHCPv6, you can just as well do it with stateful DHCPv6 as with a DHCPv6 route option.   Your point about the DHCP server not knowing the local state of the network is of course completely true, and yet another reason not to use the route option.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Nov 2011 10:04:37 +1300

Ted,

On 2011-11-22 16:42, Ted Lemon wrote:
...
> I'm agnostic—it's pretty obvious to me that we can solve this with some backwards-compatible changes to RA.  So even though I personally would have preferred to use DHCP to solve this entire set of…

Which draft(s) describe those changes?

Given that the IETF Last Call on this draft ended 2011-06-21,
there's been plenty of time to document the alternatives.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Nov 2011 21:45:35 +0000

On Nov 22, 2011, at 4:04 PM, Brian E Carpenter wrote:
Given that the IETF Last Call on this draft ended 2011-06-21,
there's been plenty of time to document the alternatives.

When something gets through IETF last call without objections being raised, you can't claim that as a triumphant validation of what it says.   The fact is that there are so many documents going through last call at this point, and being worked on, that no sane person can keep up with them all.   I wasn't even aware of this one until it came up  in Taiwan.

The fact is that we didn't properly solve the multihoming problem either in RA or in DHCP.   Whether this document actually becomes an RFC or not, we need to actually solve the problem it tries to address, because it certainly doesn't solve the problem.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Nov 2011 13:27:56 +1300

Ted,

Understood, and I was very late tuning into MIF and HOMENET.
However, we now have what I consider a serious situation: this
draft is in the final stage of IESG review, but to make any
sense it relies on two MIF documents being approved of which at
least one is contentious. Even though this is an Informational
document, it will look pretty silly if two of its main
dependencies do not get published.

Regards
   Brian Carpenter

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 22 Nov 2011 19:48:58 -0500

Are the references normative? It sounds like they should be.

If so, the problem solves itself. Even if the IESG approves the multihoming document, all it can do is languish on the RFC editor's queue until the referenced documents are published.

                                              Ron

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, November 22, 2011 7:28 PM
> To: Ted Lemon
> Cc: Satoru Matsushima; [email-masked] WG; Wesley Eddy; Pete Resnick;
> <[email-masked]>;
> [email-masked] Harrington; Ronald Bonica
> Subject: AD alert: New Version Notification - draft-ietf-v6ops-ipv6-
> multihoming-without-ipv6nat-03.txt
> 
> Ted,
> 
> > When something gets through IETF last call without objections being
> raised, you can't claim that as a triumphant validation of what it
> says.   The fact is that there are so many documents going through last
> call at this point, and being worked on, that no sane person can keep
> up with them all.   I wasn't even aware of this one until it came up
> in Taiwan.
> >
> > The fact is that we didn't properly solve the multihoming problem
> either in RA or in DHCP.   Whether this document actually becomes an
> RFC or not, we need to actually solve the problem it tries to address,
> because it certainly doesn't solve the problem.
> 
> >
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Nov 2011 14:10:26 +1300

They are normative, and I believe appropriately so. Indeed
that prevents a purely formal problem - but the real problem
remains until we resolve the discussion around whether
draft-ietf-mif-dhcpv6-route-option is standardised. If not,
it's back to the drawing board as far as I can see.

Regards
   Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Nov 2011 02:48:31 +0000

> it's back to the drawing board as far as I can see.

I really don't see the rush.  If we conclude that the route option should move forward, this draft gets published; if not, it gets updated. I presume that the authors don't agree with me that this isn't the right solution to the multihoming problem, but it seems like a worthwhile topic to discuss, since we certainly agree that there is a problem, and I think have in common a motivation to fix it.

---

From: "Mr.R.A.Hunter" <[email-masked]>
Date: Tue, 22 Nov 2011 10:21:12 +0100

When you write "trivially control", what's the refresh/flush mechanism 
to inform end nodes of a (link) status change?

Setting low values for DHCPv6 lifetimes so each host individually and 
regularly pulls the new DHCP settings via renew and rebind messages?
DHCPv6 reconfigure message via a push to each host individually via unicast?
RA PIO valid lifetime = 0?

In my customers, it's highly likely that there'll be a pair of 
enterprise-wide centrally-managed highly-available DHCPv6 servers 
located off-site in a central data centre, contacted via a DHCPv6 relay 
agent configured on the local site router. I'm not sure how that 
off-site DHCPv6 server will know of local link status changes, or 
whether it will be reachable whilst links are bouncing. I'm also not 
sure it will be practicable to install local DHCPv6 servers per site 
(with central content admin). Generally speaking, there are no servers 
or technical administrators left on remote sites.

Thanks
RayH

Ted Lemon wrote:
>> <snip>
> Using the DHCPv6 route option, even if it is approved, to solve this 
> problem is unnecessary and, I would claim, harmful.   What you should 
> actually do is clear the A bit on one of the two advertised prefixes, 
> and also set the M bit in the RA message.   Now you can trivially 
> control which hosts use the second prefix, using DHCP, which prevents 
> broken hosts from autoconfiguring addresses on it.
>
> <snip>
>