Subject: [Int-area] IP-capable nodes must support IPv6 - new draft-george-ipv6-required

From: "George, Wes E [NTK]" <[email-masked]>
Date: Fri, 7 Jan 2011 18:52:33 +0000

As a direct result of discussions after Beijing about the hotly-contested 
draft regarding IANA allocating a new shared IPv4 address space, the authors 
of this draft realized that the root problem is actually the lack of IPv6 
support in existing devices, which is adding a barrier to wider deployment in 
many networks. This is being made worse due to two things: lack of interest by 
vendors in back-porting true IPv6 support into devices that are 
software-upgradeable and could otherwise support it, and the fact that some 
vendors are still churning out devices which do not support IPv6 even as we 
stare down the imminent exhaustion of the IANA free IPv4 pool. This draft 
attempts to address this problem by updating the definition of an "IP-capable" 
node to require support for IPv6.

The authors are fully aware that this is not going to solve the problem of 
legacy installed-base, nor is it going to prevent people from continuing to 
release hardware that is IPv4-only. However, we believe that the IETF is 
overdue to acknowledge that IPv6 will be a requirement going forward, and not 
just optional.

We'd appreciate your support in adopting this as an int-area draft, or 
possibly a v6ops draft.

We'd be happy to discuss the draft in either meeting at IETF 80 if the WG 
chair feels that it is appropriate.

Thanks,
Wes George

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Friday, January 07, 2011 1:28 PM
To: George, Wes E [NTK]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification for draft-george-ipv6-required-00

A new version of I-D, draft-george-ipv6-required-00.txt has been successfully 
submitted by Wesley George and posted to the IETF repository.

https://datatracker.ietf.org/doc/draft-george-ipv6-required/

Filename:	 draft-george-ipv6-required
Revision:	 00
Title:		 IPv6 Support Required for all IP-capable nodes
Creation_date:	 2011-01-06
WG ID:		 Independent Submission
Number_of_pages: 7

Abstract:
Given the global lack of available IPv4 space, and limitations in
IPv4 extension and transition technologies, this document deprecates
the concept that an IP-capable node MAY support IPv4 _only_, and
redefines an IP-capable node as one which supports either IPv6 _only_
or IPv4/IPv6 dual-stack.  This document updates RFC1812 and 1122 to
reflect the change in requirements.

The IETF Secretariat.

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 07 Jan 2011 15:11:03 -0500

I agree so strenuously that I half-jokiningly would like to be listed as 
a coauthor, and I bet there are a number of other folks on these lists 
that would feel the same way.  Perhaps a better suggestion would be to 
include an appendix with the name and affiliation of everyone who is 
willing to sign-on to ratify this recommendation.

I've been working with a government client supporting a mandate that 
said that every IP product US DoD buys MUST be IPv6 capable, which 
resulted in significant attention from vendors.  Strong words from above 
definitely trigger action.

I believe a strong statement from IETF at this time is appropriate.  
Take away the excuse that "nothing ever said IPv6 was a MUST".   I'd 
like to see this on the agenda for Intarea or v6ops or both in Prague.

Ed Jankiewicz, speaking without any hats on, except perhaps my IPv6 
propeller beanie.

On 1/7/2011 1:52 PM, George, Wes E [NTK] wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

732-389-1003 or  [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Jan 2011 12:59:17 -0800

IMO, IPv6 support, or IPv6-capable, isn't going to cut it.

The IETF doesn't have an enforcement or validation arm, like 
Underwriter's Lab does, e.g. If it did, the correct recommendation, IMO, 
would be:

- IPv6 MUST be enabled by default
- all advertized/claimed IP capabilities MUST be enabled by default 
using IPv6

I.e., whatever the device supports in IP, it MUST be ready and available 
in a default configuration for IPv6.

Joe

---

From: Fred Baker <[email-masked]>
Date: Fri, 7 Jan 2011 13:09:30 -0800

On Jan 7, 2011, at 12:59 PM, Joe Touch wrote:

> The IETF doesn't have an enforcement or validation arm, like Underwriter's Lab does, e.g. If it did, the correct recommendation, IMO, would be:
> 
> - all advertized/claimed IP capabilities MUST be enabled by default using IPv6
> 
> I.e., whatever the device supports in IP, it MUST be ready and available in a default configuration for IPv6.

I'm very sympathetic to your viewpoint, but on equipment I'm familiar with it poses a few problems. For example, telling me that I have to support IPv6 routing in all my IP routing protocols, and if they run on IP they have to be able to run on IPv6, makes sense. Did you want all of my routing protocols on, on all interfaces, by default? If not, which, and why did you make that choice? Yes, we have IPv6 ACLs. Which ACL did you want on by default? And so on.

And then there is the principle of least surprise. Any idea what happens when one of my customers finds something running on my equipment in his network that he didn't plan on being there? I'll give you a hint: PSIRT winds up making comments...

For hosts, such as Linux/MacOSX/Windows, yes I would recommend that IPv6 be on by default in an RFC-specified configuration. Not sure I want that for the infrastructure.

---

From: Fred Baker <[email-masked]>
Date: Fri, 7 Jan 2011 13:16:02 -0800

It looks like Ed, when he reformatted his reply to remove the draft authors, managed to change [email-masked] to [email-masked]. The old address no longer works...

Anyhow, my comment to Joe's response to Ed's response...

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Fri, 7 Jan 2011 21:19:47 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Joe Touch
> Sent: Friday, January 07, 2011 3:59 PM
> Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new draft-
> george-ipv6-required
> 
> 

[WES] That "default" keyword is one third-rail that I'd rather not touch. I
understand the idea - if the (non-technical) customer must do something to
enable it, it may as well not be there... But ultimately this is meant to be
a generic doc that refers you to other docs that cover the more specifics
about what should and should not be on by default, etc. And those subtending
documents is where specifics like that should be covered.

I'm open to discussion on adding something like your second statement
clarifying that IPv6 support translates to feature parity between IPv4 and
IPv6, but I hesitate to add too much complexity. Propose text?

Wes

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Jan 2011 13:27:45 -0800

> IPv6, but I hesitate to add too much complexity. Propose text?

The basic idea is that:

	- capabilities supported for IPv4 MUST be supported for IPv6
	- defaults enabled for IPv4 MUST be enabled for IPv6
		not sure whether this is "instead of for IPv4",
		or just in addition

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Jan 2011 13:26:17 -0800

On 1/7/2011 1:16 PM, Fred Baker wrote:
> I'm very sympathetic to your viewpoint, but on equipment I'm
> familiar with it poses a few problems. For example, telling me that I
> have to support IPv6 routing in all my IP routing protocols, and if
> they run on IP they have to be able to run on IPv6, makes sense. Did
> you want all of my routing protocols on, on all interfaces, by
> default? If not, which, and why did you make that choice? Yes, we
> have IPv6 ACLs. Which ACL did you want on by default? And so on.

Basically, if it's on by default for IPv4, it MUST be on by default for 
IPv6. I appreciate that not everything is on by default, esp in routers.

> And then there is the principle of least surprise. Any idea what
> happens when one of my customers finds something running on my equipment
> in his network that he didn't plan on being there? I'll give you a hint:
> PSIRT winds up making comments...

See above; the idea is just to bring IPv6 to the level that people
currently enjoy support for Ipv4, not to force them into it per se.

> For hosts, such as Linux/MacOSX/Windows, yes I would recommend that
> IPv6 be on by default in an RFC-specified configuration. Not sure I
> want that for the infrastructure.

At least one significant problem with deployment is IPv6 support for 
network management and monitoring tools. If that's not available from 
the start - when purchased - the equipment is unlikely to ever be used 
for IPv6.

Regardless, I proposed what I think is a more useful metric. Yes, there 
are some nuances (i.e., what does "on by default" mean), but the general 
intent is:

	don't claim a capability works for IP unless it works
	for IPv6 out of the box

Joe

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 07 Jan 2011 13:40:03 -0800

On 1/7/2011 12:59 PM, Joe Touch wrote:
>
> I.e., whatever the device supports in IP, it MUST be ready and 
> available in a default configuration for IPv6.

Like NAT?

Matthew Kaufman

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Jan 2011 13:46:23 -0800

>> available in a default configuration for IPv6.

Well, if you have a device that NATs, and it only supports it for IPv4, 
and that's a behavior you want (for privacy or other reasons), then yes, 
it should support it for IPv6.

Sure, I'd hope that if IPv6 were ubiquitous that less people would 
buy/use NATs, but I don't want the existence of IPv4-only NATs to 
inhibit that ubiquity.

Joe

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 07 Jan 2011 13:51:35 -0800

On 1/7/2011 1:46 PM, Joe Touch wrote:
> Well, if you have a device that NATs, and it only supports it for 
> IPv4, and that's a behavior you want (for privacy or other reasons), 
> then yes, it should support it for IPv6.
>

Ok. So just to verify, if a box that is sold today that does NAT44 
out-of-the-box (I have one here on my desk, does DHCP client on the 
"WAN" port and serves DHCP for RFC1918 space for the "LAN" switch ports 
when first powered up) wants to comply with this it would need to also 
do NAT66 (with DHCPv6 serving ULA space on the "LAN" side, I guess...) 
when initially powered up?

Matthew Kaufman

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Jan 2011 13:54:27 -0800

> when initially powered up?

IMO, yes.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Jan 2011 11:39:43 +1300

>> when initially powered up?

IMO, no. See RFC 4864, draft-ietf-v6ops-cpe-simple-security,
and many related discussions.

    Brian

---

From: Josh Rambo <[email-masked]>
Date: Fri, 7 Jan 2011 17:42:13 -0500

>> when initially powered up?

That seems at odds with the goal of end-to-end transparency on the Internet.
If it boots up with NAT66 out of the box, then it requires user intervention
to remove that NAT66. You'd end up with NAT66 on every residential gateway
in the world.

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Jan 2011 14:42:07 -0800

> and many related discussions.

You're arguing against the need for 6-to-6 NAT. That's not my point at all.

If it works for v6, it needs to work for v6. Period.

Anything less than that *has been* and will continue to be used as a 
reason not to enable v6.

Je

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Jan 2011 14:43:35 -0800

> and many related discussions.

PS - these docs also ignore a valid reason for a NAT - which is to be a 
"single IP address front end to a set of back-end IP-capable devices". 
Such devices are important when a cluster of devices is intended to act 
as a single device on the Internet, and a NAT can be an effective way to 
implement that front-end.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Jan 2011 14:45:07 -0800

On 1/7/2011 2:42 PM, Josh Rambo wrote:
> On Fri, Jan 7, 2011 at 4:54 PM, Joe Touch<[email-masked]>  wrote:
>>
>>

Again, you're arguing against NAT. That's not what I'm suggesting.

If you really can make the case that a capability needs to be enabled 
for IPv4, but should never be enabled for V6, then *maybe* - but, again, 
that *will* be used as an excuse not to adopt the device in a V6 
environment, IMO.

If the box is a NAT, it's a NAT. If that's not what you want to sell, 
then don't include a NAT.

Joe

---

From: Josh Rambo <[email-masked]>
Date: Fri, 7 Jan 2011 17:47:55 -0500

On Fri, Jan 7, 2011 at 5:45 PM, Joe Touch <[email-masked]> wrote:
> If you really can make the case that a capability needs to be enabled for
> IPv4, but should never be enabled for V6, then *maybe* - but, again, that
> *will* be used as an excuse not to adopt the device in a V6 environment,
> IMO.
>
> If the box is a NAT, it's a NAT. If that's not what you want to sell, then
> don't include a NAT.

I'm arguing that there are some features of v4 that are not appropriate to
enable by default in v6. NAT is one of those features. A home, residential
gateway is a gateway. That is it's true purpose. It's not a NAT box, it just
has to perform that function to operate in the limited v4 address space.
So, the true function of a gateway should be to be a gateway, which
doesn't involve a NAT66.
Just because v4 needs it by default doesn't mean v6 does or should.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 7 Jan 2011 16:53:52 -0600

It is imperative that the draft specify what basic IPv6 functionalities
must be supported on every node.  

I agree that there isn't any need for 1:1 mapping of IPv4 and IPv6
functionalities to be supported and/or enabled on the node.

Cheers,
Rajiv

> Behalf Of Josh Rambo
> Sent: Friday, January 07, 2011 5:48 PM
> To: Joe Touch
> Cc: IPv6 Operations; [email-masked]
> Subject: Re: [Int-area] IP-capable nodes must support IPv6 - newdraft-
> george-ipv6-required
> 
> for
> then
> I'm arguing that there are some features of v4 that are not
appropriate
> to
> gateway is a gateway. That is it's true purpose. It's not a NAT box,
it
> just

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Jan 2011 14:55:43 -0800

On 1/7/2011 2:47 PM, Josh Rambo wrote:
> On Fri, Jan 7, 2011 at 5:45 PM, Joe Touch<[email-masked]>  wrote:
>>
>>

That's one viewpoint; in that case, then the NAT would not need to 
support IPv6.

However, some places expect the NAT for various reasons:

	- limits incoming connections
	(disrupting use of home net connections for business uses,
	or as a way to block viruses - not a great way, but it's
	one reason it's on even when not necessary)

	- enables better tracking of customer behavior
	(need to track only one IP address)

	- no need to run DHCP back to the CO
	(no impact on CO DHCP when users add/remove devices
	inside their house)

	- protect intra-house networking
	(again, not the best way to do this, but also can make it
	easier to prevent leakage of LAN-intended protocols into
	the CO, without requiring CO equipment to filter)

> Just because v4 needs it by default doesn't mean v6 does or should.

Understood. Caveats do apply. But the overall point is still valid - in 
general - with few, specific, and *deliberate* exceptions, if it works 
for IPv4, it ought to work for IPv6 too.

Right now, e.g., many devices work fine to transit IPv6, but their net 
mgt needs IPv4. That's insufficient, IMO, to claim "IPv6" on a box.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Jan 2011 14:58:25 -0800

> must be supported on every node.

I'm not sure what that means, though. Nobody would *require* a router to 
support a GUI for management, but, IMO, if the GUI supplied works only 
for IPv4, it's a killer.

Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122, 1123, 
and 1812 (and their supplementary RFCs). But there's a broader issue - 
the point that "if IPv4 is supported better, in any way, than IPv6, on a 
device, then there is incentive to not use IPv6".

Joe

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 7 Jan 2011 17:19:25 -0600

Joe,

> Yes, there ought to be a list of IPv6 requirements, ala RFCs 1122,
> 1123, and 1812 (and their supplementary RFCs). 

Ditto. I am sure that we could come up with few more.

> But there's a broader issue -
> the point that "if IPv4 is supported better, in any way, than IPv6, on
> a device, then there is incentive to not use IPv6".

This broader issue in conjunction with all that exists on an IPv4
gateway may not be needed on an IPv6 gateway, warrants the set of MUST
and SHOULD/MAY IPv6 features. That was the intent of my suggestion.
	
Cheers,
Rajiv

> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, January 07, 2011 5:58 PM
> To: Rajiv Asati (rajiva)
> Cc: Josh Rambo; IPv6 Operations; [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Jan 2011 12:20:39 +1300

> implement that front-end.

Yes, that's the one described in US patent 5371852. I don't think
the IETF has strayed into that territory.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 08 Jan 2011 00:28:43 -0300

> to remove that NAT66. You'd end up with NAT66 on every residential gateway

End-to-end transparency in the sense that every node will be reachable
from every node? -- IMHO, forget about it (see slide 13 of:
http://www.gont.com.ar/talks/lacnog2010/fgont-lacnog2010-ipv6-security.pdf)

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 07 Jan 2011 19:03:39 -0500

there is a list of IPv6 requirements in RFC 4294, although it is only 
Informational, and is currently being replaced by 
draft-6man-node-req-bis (in process).  It was not intended to be an 
absolute statement of the IPv6 requirements, so it may not completely 
satisfy the need for a standards track analog to RFC 1122 et al.

I think we should be careful not to let this degenerate into yet another 
"tastes great/less filling" debate on NAT, but when we aim for IPv6 
parity with IPv4 features we could distinguish between the standards for 
internetworking embodied in IPv4 and the things that were added on in 
non-standard ways.

On 1/7/2011 6:19 PM, Rajiv Asati (rajiva) wrote:
>> 1123,
>> a

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Sat, 08 Jan 2011 19:54:19 +0900

> We'd appreciate your support in adopting this as an int-area draft, or

i support this being adopted some place so it can be discussed and move
forward

randy

---

From: "Lee Howard" <[email-masked]>
Date: Sat, 8 Jan 2011 10:12:23 -0500

> and 1812 (and their supplementary RFCs). 

See rfc4294, IPv6 Node Requirements, and draft-ietf-v6ops-cpe-router, Basic
Requirements for IPv6 Customer Edge Routers, both of which are cited in 
draft-george.
Including requirements by reference is the right way to go, here.
If there are additional requirements, they should be in separate drafts
updating
those requirements documents.

> device, then there is incentive to not use IPv6".

If IPv6 isn't supported at all, it doesn't matter what the incentive is.
I believe there is consensus that NAT66 should not be defined, or
on by default (I don't see it in the BEHAVE charter, for instance).  
Therefore, requiring NAT66 is equivalent to prohibiting IPv6.

Lee

---

From: Fernando Gont <[email-masked]>
Date: Sat, 08 Jan 2011 00:19:02 -0300

> implement that front-end.

... and don't forget about "renumbering".

Thanks,

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 08 Jan 2011 12:37:28 -0800

>> implement that front-end.

Oddly enough load-balancers that support ipv6 support nat66 and nat64...

1 to 1 and 1 to n dnat are basic and essential functions of service
abstraction.

joel

---

From: Mark Smith <[email-masked]>
Date: Sun, 9 Jan 2011 10:39:56 +1030

On Fri, 07 Jan 2011 14:43:35 -0800

> implement that front-end.

It sounds like you're adopting the "Law of the instrument" regarding
NAT -

"It is tempting, if the only tool you have is a hammer, to treat
everything as if it were a nail."

NAT may have been the only tool in IPv4 for these problems,
because there wasn't enough address space to solve them any other way.
That constraint doesn't exist in IPv6, so other solutions which don't
have the limitations NAT creates may now be possible. If you just
blindly assume NAT is the only way to solve these problems, how will
you discover better ones?

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

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Jan 2011 09:30:12 +0100

Le 8 janv. 2011 à 04:28, Fernando Gont a écrit :
> from every node?

The e2e transparency that IPv4 had lost, and IPv6 restores, is ADDRESS transparency: source and destination addresses seen by a destination are the same as those set by the source. 
- This is needed in particular for Header Authentication of IPsec.
- Also, it permits a host to advertise its source address in the DNS and in referrals.

It is preserved between two hosts using ULA's in a common customer site.
It should remain possible between hosts in two independent customer sites.
 
Restricting reachability, where needed, is Firewall's function.
Firewalls DON'T NEED to sacrifice in address transparency do do what they have to do. 

Regards,
RD

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Jan 2011 19:15:35 +1030

On Mon, 10 Jan 2011 09:30:12 +0100

> Restricting reachability, where needed, is Firewall's function.

And can also be a host's decision and function. It actually has to be if
there is no assurance of existence or confidence in the operation of a
network located upstream firewall - and as more and more multi-homed
mobile hosts become popular (a.k.a. smartphones, laptops, tablets,
netbooks - everybody has got at least one of those haven't they?) -
assurance of or confidence in an upstream firewall is naturally going
to become reduced over time.

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 10 Jan 2011 11:33:56 +0100

<>start snip<>
<>end snip<>

I am interested to understand 'how' you want to quantify the IPv6 vs
IPv4 service experience.

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rajiv Asati (rajiva)
Sent: zaterdag 8 januari 2011 0:19
To: Joe Touch
Cc: [email-masked]; IPv6 Operations
Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6
-newdraft-george-ipv6-required

Joe,

	
Cheers,
Rajiv

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Jan 2011 14:17:26 +0100

Le 10 janv. 2011 à 13:04, Carlos Martinez-Cagnazzo a écrit :

> We already have that today with IPv4, not at protocol level, but any
> operating system can operate a packet filter. Having host-based
> firewalls also does not mean that we have to sacrifice address
> transparency.

Right.

> On Mon, Jan 10, 2011 at 6:45 AM, Mark Smith
> <[email-masked]> wrote:
>>> ...
>> network located upstream firewall 

Agreed: hosts already restrict reachability by themselves, and this is a must-have function.
(Note that, this being done by their integrated firewall, it still is a "firewall" function ;-).) 

Regards,
RD

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 10 Jan 2011 15:49:33 +0000

> Behalf Of Rajiv Asati (rajiva)
> Sent: Friday, January 07, 2011 6:19 PM
[WES] I think that those lists already exist for IPv6, but not always in
exactly the same form as the IPv4 specs you reference above. I assume that
the IPv6 specifications aren't listed as updates to the above IPv4 RFCs
because IPv6 was considered optional, not a direct replacement for IPv4. I
wasn't about to go so far as to deprecate the appropriate IPv4 spec in favor
of the IPv6 one... baby steps :-)
Either way, this draft is meant to be a generic update informing those who
are considering putting an IP stack on their device, whether dumb or smart,
simple or complex, that they need to stop considering IPv6 optional. We
intentionally kept it generic so that it could be adopted more quickly - the
sooner we correct the lack of IPv6 support in devices and software, the
better off we are.

That said, it may be helpful to write a draft comparing IPv4 and IPv6 for
feature parity to identify future work items for IETF and point to the
appropriate RFCs where equivalent features exist, but I view that as
complimentary to this draft, not part of it.

I agree that the more specific information about what we mean by "support
IPv6" should be made available, but as references, not text in the draft
itself. 
The draft already references ietf-v6ops-ipv6-cpe-router, and RFC 4294, which
I've been informed will soon be replaced by a BIS version (currently
draft-ietf-6man-node-req-bis). I will update that reference in the next
version of the draft. 
The draft also formally updates 1812 and 1122. I can add 1123 to that list
of updated drafts if there is consensus that it should be added. 
Brian Carpenter also recommended (offlist) that we might want to consider
adding RFC4084 to the update list, specifically, moving "Version" from
section 4 (additional terminology) to section 2 (general terminology). What
are your thoughts on that?

What else is missing as a reference? Keep in mind that the existing
referenced drafts and RFCs have multiple normative and informative
references of their own which we didn't see the need to duplicate here.

Thanks for the support thus far.

Wes George

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 10 Jan 2011 16:29:36 +0000

Shortened the subject line a bit

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Ed Jankiewicz
Sent: Friday, January 07, 2011 3:11 PM
To: [email-masked]; IPv6 Operations
Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new 
draft-george-ipv6-required

>I agree so strenuously that I half-jokiningly would like to be listed as a 
>coauthor, and I bet there are a >number of other folks on these lists that 
>would feel the same way.  Perhaps a better suggestion would be to >include an 
>appendix with the name and affiliation of everyone who is willing to sign-on 
>to ratify this >recommendation.

[WES] If I'm interpreting this right, this would sort of be like a petition 
with lots of signatures, or one of those open letters to the 
$government_functionary signed by lots of "important people" you see published 
in full-page newspaper ads? I assume that this is generally a way of more 
concretely documenting support for this proposal beyond the IETF's standard 
rough consensus in a WG meeting or on-list.
I'm open to this, but is there any precedent for it? Do we want to set a 
precedent that if we *really* mean something, we take steps to more thoroughly 
document that support within a draft? Those in support can already have their 
support immortalized in the pages of the email list archives complete with 
their choice of editorialization...
And regarding affiliation - IETF typically shies away from making a big deal 
of affiliation, since most of its members are not really authorized to 
represent the company that pays the bills in any official public capacity. 
Yes, they are representatives of that company, but they are mostly speaking 
for themselves with the interests of their company informing those comments - 
it's not like there's a way to get every email and comment at the mic approved 
by PR first :-)

An IAB statement of support would perhaps be a good way to add weight to this 
recommendation, but I'm content to start with statements of support for WG 
adoption and advancement to RFC status and see where it goes from there.

Wes George

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Jan 2011 13:51:52 -0300

Hi, Remi,

On 10/01/2011 05:30 a.m., Rémi Després wrote:

>> End-to-end transparency in the sense that every node will be
>> reachable from every node?
> 
> The e2e transparency that IPv4 had lost, and IPv6 restores, is
> ADDRESS transparency: source and destination addresses seen by a
> destination are the same as those set by the source. 

IPv6 restores this to the extent that NAT66 is not deployed. My take is
that NAT66 *will* be deployed. -- So, I don't think you can rely IPv6 on
restoring "address transparency".

> - This is needed
> in particular for Header Authentication of IPsec. 

But you can still use UDP encapsulation.

> - Also, it permits
> a host to advertise its source address in the DNS and in referrals.

Firstly, using network addresses in the application layer is generally a
bad idea, and one would hope that we have already learnt that lesson.

Secondly, for the an address published in the DNS to be useful, it needs
to be reachable (that's why you advertise the address in the DNS after
all, right?). And for it to be reachable, the stateful firewall tht's in
fron of the host (or within the host), needs to have state for that
"incoming connection". -- In general, there won't be such state, *or*
the firewall would need to be smart enough to understand the application
protocol to create such state before it's needed (so, again, forget
about the "dumb network").

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jan 2011 09:47:04 -0800

On 1/8/2011 4:09 PM, Mark Smith wrote:
...
> everything as if it were a nail."

Maslow's law is not the motivation.

I'm simply making a few observations:

1) anything a device supports for IPv4 that it cannot support for IPv6 
will be taken as an excuse not to migrate to IPv6

2) it's better to remove that hurdle than to debate every capability.

3) NATs are useful even where addresses are plentiful

Joe

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 10 Jan 2011 10:05:51 -0800 (PST)

> restoring "address transparency".

+1.

We can only reply on public IPv4 address depletion. Period.

---

From: Ed Jankiewicz <[email-masked]>
Date: Mon, 10 Jan 2011 13:36:24 -0500

upon reflection, I agree that it would be unnecessary and inappropriate 
to generate a petition within IETF.  The process is built on consensus, 
not name-checking.

Suffice it to say I support this work being discussed within Intarea and 
v6ops, including time on the agenda in Prague, and eventual adoption as 
a WG or IAB publication.

I also agree with a previous comment that this draft should be kept very 
simple with a small number of essential references, e.g. to the IPv6 
Node Requirements (as revised).  That is the current best definition of 
what is "required" for IPv6.  If it is insufficient as is, and needs to 
be replaced by a standards track definition, that would take some 
effort, and that can be discussed as well.  I would prefer that we 
publish the current RFC 4294 update draft before we open that can of worms.

The question of parity is very complex and difficult to define.  The 
concerns that some things are not directly comparable, or that there are 
things that have become accepted in IPv4 that some don't want to 
replicate in IPv6, versus the sense that the lack of any feature 
(standard or not) will be a disincentive to IPv6 adoption - it's not 
clear how these can be reconciled.

On 1/10/2011 11:29 AM, George, Wes E [NTK] wrote:
>> coauthor, and I bet there are a>number of other folks on these lists that
>> would feel the same way.  Perhaps a better suggestion would be to>include an
>> to ratify this>recommendation.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 10 Jan 2011 12:48:40 -0600

Hi Gunter,

Good question. Are you intending to suggest that this draft should
consider the IPv6 vs. Ipv4 service experience while making the
recommendation?

Cheers,
Rajiv

> From: Gunter Van de Velde (gvandeve)
> Sent: Monday, January 10, 2011 5:34 AM
> To: Rajiv Asati (rajiva); Joe Touch
> Subject: RE: [v6ops] [Int-area] IP-capable nodes must support IPv6 -
> newdraft-george-ipv6-required
> 
> <>start snip<>
> Subject: Re: [v6ops] [Int-area] IP-capable nodes must support IPv6 -
> newdraft-george-ipv6-required
> 
> Joe,
>

---

From: "Lee Howard" <[email-masked]>
Date: Mon, 10 Jan 2011 13:48:47 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Joe Touch
> 3) NATs are useful even where addresses are plentiful

This sounds like a WG chartering debate, rather than a debate about whether 
all IP-capable devices SHOULD support IPv6.  
It sounds like your support for draft-george-ipv6-required is dependent on 
rechartering BEHAVE, defining NAT66, and updating
draft-ietf-v6ops-cpe-router
to require NAT66.  In other words, you will not support the statement, "IPv6

is required in IP-capable devices" until that statement specifically
includes
feature parity, and explicitly includes NAT66.
Is that right?

Lee

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 10 Jan 2011 12:53:33 -0600

Wes,

> sooner we correct the lack of IPv6 support in devices and software,
the

+1

> complimentary to this draft, not part of it.

That's reasonable as long as we add appropriate references.

> IPv6" should be made available, but as references, not text in the
> draft itself.

+1

> section 4 (additional terminology) to section 2 (general terminology).
> What are your thoughts on that?

+1

> references of their own which we didn't see the need to duplicate
here.

Indeed.

Cheers,
Rajiv

> From: George, Wes E [NTK] [mailto:[email-masked]]
> Sent: Monday, January 10, 2011 10:50 AM
> Subject: RE: [Int-area] IP-capable nodes must support IPv6 -newdraft-
> george-ipv6-required
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jan 2011 11:02:53 -0800

> feature parity, and explicitly includes NAT66.

I support the idea that new devices should be IPv6 capable.

I recognize the irrelevance of such an assertion. IMO, if we can't 
assert that "new devices need to support IPv6 as much as they support 
IPv4", there's simply no point. We'll be where we are now. Many 
organizations won't buy a device without the IPV6 label, but since most 
such devices have services that won't run on v6, v6 isn't enabled.

I.e., what's the point, unless we say "support IPv6 at least as well as 
IPv4"?

Joe

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Jan 2011 07:13:29 +1030

On Mon, 10 Jan 2011 13:51:52 -0300
Fernando Gont <[email-masked]> wrote:

> that NAT66 *will* be deployed. 

How do you know? What evidence do you have?

>-- So, I don't think you can rely IPv6 on

UDP encapsulation of IPsec is a work around, specifically to get around
the problems of lack of IPv4 address transparency i.e. NAT. It isn't an
acceptable answer when NAT doesn't need to exist.

---

From: "Lee Howard" <[email-masked]>
Date: Mon, 10 Jan 2011 15:49:51 -0500

> such devices have services that won't run on v6, v6 isn't enabled.

This document is targeted at node implementors, not deployers.
If specific operators have a need for specific features, they may specify
those features to their vendors, or bring them to the IETF for
definition.   IPv6 is not operator-specific, though; all new implementations
must support IPv6.

> I.e., what's the point, unless we say "support IPv6 at least as well as

I could live with that statement.  What I can't accept is that IPv6 must
not be required until everything in IPv6 works the same as in IPv4.
Does this language cover the case where a vendor can't implement a
feature because the IETF hasn't defined it yet?
     It is expected that many existing devices and implementations will
      not be able to support IPv6 for one or more valid technical
      reasons, but for maximum flexibility and compatibility, a best
      effort SHOULD be made to update existing hardware and software to
      enable IPv6 support.

If that language doesn't work, but you agree with the intended
statement in the draft, can you propose language that does not
make the draft dependent on publication of a NAT66 RFC?

Lee

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Jan 2011 17:50:39 -0300

> How do you know? What evidence do you have?

Talking to vendors, some operators, etc.

Google for "ipv6 nat" or the like, and you'll see some of the people
that are publicly interested in this feature.

> acceptable answer when NAT doesn't need to exist.

You're assuming that the only motivation to have NATs is address
exhaustion -- but IMO, it isn't.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Jan 2011 07:45:11 +1030

On Fri, 7 Jan 2011 18:52:33 +0000

> node to require support for IPv6.

I don't think I really agree with the root cause. IPv6 doesn't exist in
equipment because customers, or representatives of customers (e.g ISPs
for CPE) haven't made it a "must have", and refused to buy the equipment
when it doesn't support IPv6. Making it a requirement in an IETF
document still won't make it happen unless customers demand compliance
with that IETF document. They haven't done that with the group of IPv6
RFCs, so I don't see why a single RFC going to be any different.

My recent experience has been that a CPE vendor, once they know that
you require IPv6 support, starts caring not about whether to implement
it or not, but what specific requirements you have. For example, our
recent focus has just been basic IPv6 connectivity i.e. so the CPE can
connect customers to the IPv6 Internet. Out of the blue, the vendor
asked us if we considered SIP over IPv6 for the ATA inside the CPE to
be a must have or not. They wouldn't be thinking about that level
of feature implementation detail if we hadn't made "IPv6" a
fundamental requirement. I've also seen rapid improvement in an IPv6
implementation over a six week period once the vendor realised that
they were going to miss out on 100s if not 1000s of CPE sales. (It's
very impressive when you report a bug on one day and you've got
firmware fresh out of the compiler a day or two later that addresses
it).

> overdue to acknowledge that IPv6 will be a requirement going forward, and not 

I think a different and better approach would be to officially deprecate
IPv4, declaring it obsolete. That doesn't mean people can't use it,
but it is the IETF saying that it is past it's used-by date, and people
should be using IPv6 in preference. I think if the
inventors/maintainers of IPv4 were to say people should try to avoid
using IPv4, people will pay more attention than continuing to think
that it is fine to use IPv4, and IPv6 is an optional feature they can
compromise on if they need to. There is a bit of psychology in that -
people generally don't like choosing to use obsolete technologies
(social proof), and also place significant value on when somebody says
"I invented it, but don't use it anymore, you'll have
problems." (authority)

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jan 2011 10:45:36 +1300

> restoring "address transparency".

IPv4 intrinsically destroys address transparency by not having enough
addresses.

The good news is that IPv6 doesn't have this property. So although some
vendors and users will ignore this good news for reasons of their own,
e2e address+port transparency remains available and will in due time be
seen as desirable. Patience is needed, though; it will probably be many
years before this perception filters through everywhere and NAT66
becomes a curiosity of history.

     Brian

---

From: [email-masked]
Date: Mon, 10 Jan 2011 22:47:35 +0100 (CET)

> exhaustion -- but IMO, it isn't.

Provider independence is a huge motivation. People have it with IPv4
and NAT today, at least to some degree - and don't see why they should
be tied to a specific provider's PA space, *or* have to jump through
hoops, to get IPv6 PI space. Thus the desire for IPv6 stateless NAT.

[If you don't think IPv6 PI space requires jumping through hoops -
consider http://www.ripe.net/ripe/policies/proposals/2006-01.html
which is the RIPE requirements for PI space. Note that I'm *not*
saying these requirements are bad - I'm just saying they are more
than a lot of companies, used to IPv4 NAT, will be willing to deal
with...]

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Jan 2011 08:20:23 +1030

On Mon, 10 Jan 2011 15:49:51 -0500

> not be required until everything in IPv6 works the same as in IPv4.

I agree, and I think the following post a few months ago was very
insightful regarding requiring complete IPv4/IPv6 parity -

http://lists.cluenet.de/pipermail/ipv6-ops/2010-June/003650.html

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jan 2011 14:01:28 -0800

Hi, Lee,

On 1/10/2011 12:49 PM, Lee Howard wrote:
...
> not be required until everything in IPv6 works the same as in IPv4.

AOK; I don't want to get hung up on specifics.

Again, the point is that "support IPv6 at least as well as IPv4" is 
better than "support IPv6".

> feature because the IETF hasn't defined it yet?

Well, if there are such features, then they're clearly going to be an 
issue. That needs to be fixed.

Sure, you can't expect an implementation to support IPv6 for protocols 
that have no IPv6 variant yet. That means we have work to do before we 
ought to be jumping up and down expecting everyone to use IPv6, though.

>        effort SHOULD be made to update existing hardware and software to

I don't like this language. It was true for Windows and MacOS previous 
to the 2005 IPv6 IETF test, and we saw how that worked out (not).

IMO, you shouldn't be able to claim IPv6 just by "best effort". There is 
no SHOULD, enable or support. There is only "do". I.e., either a system 
supports IPv6 - for all IP communications - or not.

That might be sufficient, if you want different language:

	"A system that supports IPv6 MUST support IPv6 for all
	IP communications in the absence of any other version of IP
	communications (including IPv4). That system MUST provide
	IPv6 communications services to the same or greater
	extent than are available for IPv4."

and
	"All new systems SHOULD support IPv6 as per above.
	All existing systems SHOULD support IPv6 as per above
	as soon as possible"

> make the draft dependent on publication of a NAT66 RFC?

That's one you want to exclude. I'm sure there are others that other 
people want to exclude. Any that are excluded *will* (IMO) be an excuse 
for not using IPv6.

I would prefer to ensure that IPv6 has the same or greater services than 
IPv4, and separately state that:

	"Note that not all IPv4 services are recommended or even defined
	in an IPv6-only environment. To the extent that such services
	are not meaningful (e.g., NAT66 solely for address space
	extension), they are not required by the above."

Joe

---

From: "Lee Howard" <[email-masked]>
Date: Mon, 10 Jan 2011 19:43:41 -0500

> issue. That needs to be fixed.

Well, again in the case of NAT66 (which you haven't argued is a bad
example), it isn't needed in the home gateway.  Can we not require IPv6
in the home gateway, because NAT66 is not supported?

> ought to be jumping up and down expecting everyone to use IPv6, though.

You argued that NAT66 was required for presenting a cluster a single
address (like a load balancer), just like in IPv4.  Can you point me to the
RFC defining that behavior?

> 	extent than are available for IPv4."

We could take this off-list if we're getting too detailed in wordsmithing.
Is this not the equivalent of, "IP networking implementations 
MUST NOT require IPv4 for proper and complete function."?
If an implementation is missing required functionality, then it 
does not have "proper and complete function."
If it's missing unrequired functionality, there's no reason to require
it.

> 	All existing systems SHOULD support IPv6 as per above

Not MUST for new systems?

> people want to exclude. Any that are excluded *will* (IMO) be an excuse

Yes, people can find excuses.  Ignorance can be fixed
(only stupidity is forever).
For clueful people to withhold support for IPv6 because ignorant
people think they want ponies doesn't make sense to me.

> 	extension), they are not required by the above."

Sounds like a disclaimer.  Maybe more wordsmithing, but on this
one I understand the intent.

Lee

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jan 2011 16:49:30 -0800

> RFC defining that behavior?

That's what it does. Any of the NAT doc defines that behavior.

...
> MUST NOT require IPv4 for proper and complete function."?

That's better.

> If it's missing unrequired functionality, there's no reason to require

Agreed. The definition of complete would then be in the eye of the 
beholder (or consumer)...

> Not MUST for new systems?

Sure, if you prefer.

...
> one I understand the intent.

You might not need that given the variant you suggested; there's enough 
wiggle room in "proper" and "complete" being something undefined by the 
IETF anyway.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jan 2011 14:47:50 +1300

> That's what it does. Any of the NAT doc defines that behavior.

I don't think so, if you're trying to load-balance traffic to and
from Port 80. Stateful NAPT can't do this.

And as I already said, such usage is patented.
https://datatracker.ietf.org/ipr/208/

    Brian

---

From: Fred Baker <[email-masked]>
Date: Mon, 10 Jan 2011 21:15:01 -0800

> RFC defining that behavior?

I can show you an internet draft. It doesn't use a single address; it is prefix translation. But it does have the unfortunate term "nat66" in its moniker.

http://tools.ietf.org/html/draft-mrw-nat66
  "IPv6-to-IPv6 Network Prefix Translation", Margaret Wasserman, Fred
  Baker, 4-Jan-11

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Jan 2011 19:28:41 +1030

Hi Lee,

On Mon, 10 Jan 2011 19:59:33 -0500
"Howard, Lee" <[email-masked]> wrote:

> > From: Mark Smith [mailto:[email-masked]]
> > Sent: Monday, January 10, 2011 4:15 PM
> > when it doesn't support IPv6. 
> 
> What about ISPs who don't buy CPE? 
> Retail stores in the U.S. make a lot of money selling gateways to retail
> customers.  Consumers get more choice of what gateway they want to
> buy.  Surely we don't expect consumers to provide CPE requirements?
> That's why we wrote cpe-router.

I'm all for that draft, and want to see it published as soon as it can
be. The shame if it is though that it wasn't written and published 5 or
more years ago. Right when we need to be deploying (or trying to
convince customers to buy and deploy) IPv6 capable residential CPE at a
rapid pace, only months before IANA run out of IPv4 addresses, and
probably no more than 12 to 18 months before ISPs run out of IPv4
addresses, very little of it exists. LSN/CGN might stretch the
deployment period we have available, but I think it is going to get
really ugly operationally behind the scenes at ISPs.

> > IPv4, declaring it obsolete. 
> 
> I've been thinking about writing that draft (it sounds really good on the
> last day of IETF, over beers).  
> 
> After the recent thread on "Old transport-layer protocols to Historic"
> I'm confused about what the right word would be.  The list of 
> dependent RFCs would be long, and it might make an interesting career
> for someone to submit new drafts to obsolete all of the then-deprecated
> drafts.
> 
> But I'll write it if you want.
> 

I think there would be a lot of symbolic value in it. If people
don't have an interest in the details, symbolic gestures,
without resorting to FUD, can be effective in influencing people's
buying choices.

Regards,
Mark.

---

From: Rémi Després <[email-masked]>
Date: Tue, 11 Jan 2011 11:54:22 +0100

Le 10 janv. 2011 à 17:51, Fernando Gont a écrit :
> ... My take is that NAT66 *will* be deployed.

For clarification, which NAT66 do you have in mind?
- stateful NAPTv6?
- stateless NPTv6?
- both?

> restoring "address transparency".

IMHO, at least some customers will insist on having address transparency.
These customers will need ways to avoid NAT66's (but, of course, without having to sacrifice any FW function for this).

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 11 Jan 2011 12:17:57 +0100

Le 10 janv. 2011 à 22:47, [email-masked] a écrit :

> Provider independence is a huge motivation.

Agreed.

That's why, IMHO, it should be more useful to look for solutions that combine provider independence with address transparency, than accepting without effort to sacrifice address transparency for provider independence.

Although I know some readers don't like my repeating that I worked on such a solution, this is IMHO relevant to the point being discussed.
Ref: www.ietf.org/id/draft-despres-softwire-sam-01, in particular sec. 3.3.
(As this draft is about to expire, I should work in some future on a revised version.) 

Regards,
RD

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 11 Jan 2011 14:37:31 +0000

> > From: Mark Smith
> > for CPE) haven't made it a "must have", and refused to buy the
> > equipment when it doesn't support IPv6.
>
> From: Howard, Lee [mailto:[email-masked]]

[WES] Let's not forget that this is not just about residential gateways. We
have TVs that connect to one or more streaming-video and social media
services, appliances that talk either to the smart grid, or your home energy
monitor, or a website, or all of the above; nevermind things like gaming
consoles, standalone streaming media boxes, eReaders with Wifi... should I
go on? 
If you could find someone at $consumer_electronics_manufacturer of any of
the above products that we could provide those requirements to (who would
actually...you know... listen to us and do something about it), I know of
several representatives from large cable companies that represent a large
fraction of their consumer base who would *love* to make IPv6 a must-have
and explain to them how badly their product might potentially function
behind NAT444. ARIN has been trying at places like CES, and ISOC has also
tried to reach out to representatives of these industries, both with what I
would consider to be only marginal success thus far.
> 
> > I think a different and better approach would be to officially
> > deprecate IPv4, declaring it obsolete.
> 
> I've been thinking about writing that draft (it sounds really good on
> the last day of IETF, over beers).
> 
> I'm confused about what the right word would be.
  
[WES] We started out that way with this draft, actually. But as Lee says, we
couldn't determine whether deprecate or historic was the right choice, and
we realized that honestly it's not that simple. I expect that we'll get much
wider support for "IPv6 is required for devices that want to call themselves
IP-capable" than for IPv4 deprecation when IPv4 is still the dominant
protocol in use. This is at least partially because there are plenty of
places where IPv4 will *never* go away or won't go away until the device
using it is retired, where it is functioning acceptably and there is no
issue with a lack of IPv4 addresses because that application isn't growing.
Will those IPv4-only networks start becoming islands connected by IPv6 with
ALG at some point? Likely, but if they're completely closed networks, we
probably can't say that IPv4 isn't acceptable. My view is that the
deprecation/historic discussion is one to have once we've reached critical
mass on IPv6, or at least when we've exhausted the RIR free pools.

Either way, this is a multistep process. The first step is to make sure that
those manufacturers who don't have a clueful and influential customer
providing them requirements understand that they need to stop grunting out
widgets that don't understand IPv6, and to help apply pressure to those who
are on the fence. We aren't going to be able to force them to do anything,
only provide guidance, but I would hope that the IETF has some influence
here. However, I imagine your average consumer is going to be a lot angrier
when we tell them that the shiny new internet-connected device that they
just got for $winter_gift-giving_holiday 2010 is basically obsolete, or at
best functioning in a degraded fashion, due to a problem that we've known
about for many years. The vendor of said device shares some blame for being
short-sighted, greedy or both, especially if they don't update their
software-updatable devices with an IPv6 stack, but I still don't know how
IETF is going to answer the question as to why we didn't require IPv6
sooner.

Wes George

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Jan 2011 09:30:54 +1300

> That's why, IMHO, it should be more useful to look for solutions that combine provider independence with address transparency, than accepting without effort to sacrifice address transparency for pr…

Indeed; we already have one of those standardised, which also has the property
of protecting BGP4 scalability: RFC 5533, RFC 5534 and RFC 5535.

The LISP WG is standardising another solution with those properties,
that doesn't even require the user site to operate multiple prefixes.

   Brian

---

From: Rémi Després <[email-masked]>
Date: Wed, 12 Jan 2011 11:18:55 +0100

Brian,

Here is a good opportunity to clarify an important point, on which I hope we can converge.

The problem I worked on is how to combine:
- "e2e address transparency" (hosts know their own global addresses, and use them)
- "PI site routing"  (e.g., in IPv6, ULA-only intra-site routing to avoid renumbering problems)
- "Multi-CPE Multihoming" (the most complete multihoming model).
- "Per-site incremental deployment" (a site can use the solution independently from what is done anywhere else).

- LISP is off-scope because it doesn't permit per-site incremental deployment.

This problem has two complementary sub-problems:
. "Source-address selection" (how does a host select a particular e2e source address for an outgoing packet)?
. "Outgoing-CPE control" (the source address being selected, how to ensure that the packet goes via the right CPE)?
- Solutions for "source-address selection" do exist (SHIM6, SCTP, draft-ietf-v6ops-multihoming-without-nat66).
- AFAIK, a solution for "outgoing-CPE control" in the above context still has to be specified 

The key I briefly described for this "outgoing-CPE selection", in sec 3.3 of draft-despres-softwire-sam-01), is that:
- For customer-site traversal, hosts encapsulate e2e packets in local packets (IPv6/IPv6).
- Hosts address these local packets to the right CPE's by using a correspondence list between local CPE addresses and global IPv6 prefixes.

Unless this is proved to be useless, I plan to pursue in this direction, with whoever is interested in making positive contributions. 

Best regards,
RD

Le 11 janv. 2011 à 21:30, Brian E Carpenter a écrit :
>> ... it should be more useful to look for solutions that combine provider independence with address transparency, than accepting without effort to sacrifice address transparency for provider independence.
> 

(RFC 5533 and RFC 5534 are about SHIM6, and RFC 5535 is about securing multihoming address sets. None of these addresses the "outgoing-CPE control" issue).

---

From: Alberto García <[email-masked]>
Date: Wed, 12 Jan 2011 11:52:27 +0100

Hi,
The requirements you state remind me the Proxy Shim6 proposal
(http://tools.ietf.org/id/draft-bagnulo-pshim6-02.txt). There is also a
paper on the subject at
http://e-archivo.uc3m.es/bitstream/10016/2846/1/P-SHIM6.pdf
The abstract of the paper says:
"The P-SHIM6 architecture provides ISP independence to IPv6 sites without
compromising scalability. This architecture is based on a middle-box, the
P-SHIM6, which manages the SHIM6 protocol exchange on behalf of the nodes of
a site, which are configured  with provider independent addresses. Incoming
and outgoing packets are processed by the P-SHIM6 box, which can assign
different locators to a given communication, either when it is started, or
dynamically after the communication has been established. As a consequence,
changes required for provider portability are minimized, and fine-grained
Traffic Engineering can be enforced at the P-SHIM6 box, in addition to the
fault tolerance support provided by SHIM6."

Regards,
Alberto

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En
|  nombre de Rémi Després
|  Enviado el: miércoles, 12 de enero de 2011 11:19
|  Para: Brian E Carpenter
|  CC: Internet Area
|  Asunto: [Int-area] e2e Address transparency - PI site routing - Multi-CPE
|  multihoming
|  
|  Brian,
|  
|  Here is a good opportunity to clarify an important point, on which I hope
we
|  can converge.
|  
|  The problem I worked on is how to combine:
|  - "e2e address transparency" (hosts know their own global addresses, and
|  use them)
|  - "PI site routing"  (e.g., in IPv6, ULA-only intra-site routing to avoid
|  renumbering problems)
|  - "Multi-CPE Multihoming" (the most complete multihoming model).
|  - "Per-site incremental deployment" (a site can use the solution
|  independently from what is done anywhere else).
|  
|  - LISP is off-scope because it doesn't permit per-site incremental
|  deployment.
|  
|  This problem has two complementary sub-problems:
|  . "Source-address selection" (how does a host select a particular e2e
source
|  address for an outgoing packet)?
|  . "Outgoing-CPE control" (the source address being selected, how to
ensure
|  that the packet goes via the right CPE)?
|  - Solutions for "source-address selection" do exist (SHIM6, SCTP,
draft-ietf-
|  v6ops-multihoming-without-nat66).
|  - AFAIK, a solution for "outgoing-CPE control" in the above context still
has
|  to be specified
|  
|  The key I briefly described for this "outgoing-CPE selection", in sec 3.3
of
|  draft-despres-softwire-sam-01), is that:
|  - For customer-site traversal, hosts encapsulate e2e packets in local
packets
|  (IPv6/IPv6).
|  - Hosts address these local packets to the right CPE's by using a
|  correspondence list between local CPE addresses and global IPv6 prefixes.
|  
|  Unless this is proved to be useless, I plan to pursue in this direction,
with
|  whoever is interested in making positive contributions.
|  
|  Best regards,
|  RD
|  
|  
|  
|  Le 11 janv. 2011 à 21:30, Brian E Carpenter a écrit :
|  >> ... it should be more useful to look for solutions that combine
provider
|  independence with address transparency, than accepting without effort to
|  sacrifice address transparency for provider independence.
|  >
|  > Indeed; we already have one of those standardised, which also has the
|  > property of protecting BGP4 scalability: RFC 5533, RFC 5534 and RFC
5535.
|  
|  (RFC 5533 and RFC 5534 are about SHIM6, and RFC 5535 is about securing
|  multihoming address sets. None of these addresses the "outgoing-CPE
|  control" issue).
|  
|  
|  _______________________________________________
|  Int-area mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/int-area

---

From: Rémi Després <[email-masked]>
Date: Wed, 12 Jan 2011 17:20:38 +0100

Alberto,

Thank you for this interesting reference I hadn't noticed.

It did share the objective of combining of "PI site routing" with "Multi-CPE multihoming", but was NOT concerned with "e2e address transparency".

Besides:  
- It needed a middle-box between all hosts and CPE's
- It needed a new DNS RR type.
Both have to be avoided in the solution I look for.

Kind regards,
RD

Le 12 janv. 2011 à 11:52, Alberto García a écrit :

> compromising scalability.

> This architecture is based on a middle-box, the

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Jan 2011 10:23:53 +1300

I hate to have to say this, but the reason that NAT44 became popular for
quite a number of large (typically multinational) enterprise networks
was as the easiest solution to the multi-exit problem. These companies
didn't regard NAT as a security feature; they had firewalls for that.
And they didn't *want* to lose address transparency; that was considered
an acceptable side-effect of gaining a solution to the multi-exit
multi-homing problem.

Also look in your time machine for
"Ingress filtering compatibility for IPv6 multihomed sites"
draft-huitema-multi6-ingress-filtering-00

Regards
   Brian Carpenter

---

From: Rémi Després <[email-masked]>
Date: Thu, 13 Jan 2011 09:41:40 +0100

Thank you, Brian, for this other interesting reference I hadn't noticed.

Le 12 janv. 2011 à 22:23, Brian E Carpenter a écrit :

> was as the easiest solution to the multi-exit problem.

I agree, but, in my understanding:
- only for outgoing connectivity
- without TCP continuity in case of failure an ISP access being used.
=> incompatible with SHIM6 or SCTP, whose functions include incoming connectivity and TCP continuity.

> These companies

That's why, IMHO, an IPv6 solution that avoids this side-effect is worth working on.

Regards,
RD

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Jan 2011 10:18:43 +0100

> - LISP is off-scope because it doesn't permit per-site incremental deployment.

Really?!  I think you ought to tell that to the sites that deployed it.

---

From: Rémi Després <[email-masked]>
Date: Thu, 13 Jan 2011 11:21:06 +0100

> Really?!  I think you ought to tell that to the sites that deployed it.

Let me be more precise on what I meant:

I know that "incremental deployability" is among LISP goals.
But the one I called "per-site", is such that a SINGLE customer site that uses the solution has immediately its benefits, independently of what others do.

For this, tunnels of the approach I propose are *within* customer sites, while those of LISP are across the Internet core, and need coordination across it. 
LISP benefits exist between two sites ONLY if both have LISP-capable tunnel routers on their paths to the Internet core.

With this clarification, do we understand each other?

Regards,
RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 13 Jan 2011 09:00:15 -0800

I haven't been following this closely, but it seems that
IRON should also be included in the discussion. It is IMHO
better than LISP in many ways, and provides benefits whether
both sites are IRON-capable or only one site is IRON-capable.

Fred
[email-masked] 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rémi Després
> Sent: Thursday, January 13, 2011 2:21 AM
> To: Eliot Lear
> Cc: Internet Area
> Subject: Re: [Int-area] e2e Address transparency - PI site 
> routing -Multi-CPE multihoming
> 
> 
> But the one I called "per-site", is such that a SINGLE 
> customer site that uses the solution has immediately its 
> benefits, independently of what others do.
> 
> For this, tunnels of the approach I propose are *within* 
> customer sites, while those of LISP are across the Internet 
> core, and need coordination across it. 
> LISP benefits exist between two sites ONLY if both have 
> LISP-capable tunnel routers on their paths to the Internet core.
>

---

From: "Howard, Lee" <[email-masked]>
Date: Mon, 10 Jan 2011 19:59:33 -0500

Lee

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 11 Jan 2011 08:15:01 -0800

> mass on IPv6, or at least when we've exhausted the RIR free pools.

+1 for having something to reference in time for rir exhaust.

The people living in a hole will really start panicking at that point and
having clear guidance that ipv4 is dead will really help in creating order
from the impending chaos.

Cb

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Jan 2011 08:18:17 +1300

> - only for outgoing connectivity

Yes, i.e. connections initiated from the inside. Such companies
normally have their public-facing servers outside the main border,
in a "demilitarized zone".

> - without TCP continuity in case of failure an ISP access being used.

Correct. This was IMHO the big requirement introduced by RFC 3582.
I thought it was a mistake at the time, but I was only the WG Chair
and the consensus was to make it a requirement.

> => incompatible with SHIM6 or SCTP, whose functions include incoming connectivity and TCP continuity.

The incompatibility is exactly as discussed in the Huitema draft I
mentioned, and possibly solved by proxy shim6.

> That's why, IMHO, an IPv6 solution that avoids this side-effect is worth working on.

Yes.

    Brian

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 16 Jan 2011 12:24:58 +0100

On 1/10/11 7:36 PM, Ed Jankiewicz wrote:
> The question of parity is very complex and difficult to define. 

more to the point consensus on what constitutes  is a discussion that's
pretty easy to rathole. A statement that is simplistic and open to
interpretation may not achieve all that you want at the same time the
resulting statement may be more readily achievable and we have documents
like for example the cpe drafts to addresses.

Idealy this document is:

1. discussed now both here and the int-area.
2. presented in prague
3. accepted as a wg document where we deem appropiate
4. last called

> The
>> Behalf

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 16 Jan 2011 13:37:07 +0100

> that are publicly interested in this feature.

It's a basic and necessary feature of ipv6-supporting loadbalancer devices.

Given that header rewriting, and state-tracking are basic firewall
functions for v4 and v6 you really aren't very far conceptually or
implementation-wise from a nat66 feature.

The question is what's it a point solution for. If the problem is, "you
gave me one ip address and i need more than that" something is badly wrong.

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Jan 2011 07:22:58 +1030

On Sun, 16 Jan 2011 13:37:07 +0100

> It's a basic and necessary feature of ipv6-supporting loadbalancer devices.

I don't think that is necessarily the case either. A group of hosts
with the same downstream address (the global one announced in DNS), and
a router-type device (i.e. isn't assigned the global address announced
in DNS) spreading traffic across them such that the same session landed
on the same downstream host would provide "load balancing" without NAT -
effectively a more advanced version of anycast where all hosts are
active, and there is more intelligence in the selection of to which
anycast host the traffic is sent by the upstream router, spreading the
load.

---

From: Rémi Després <[email-masked]>
Date: Mon, 17 Jan 2011 17:25:44 +0100

Le 17 janv. 2011 à 15:39, Jack Bates a écrit :

> On 1/16/2011 2:52 PM, Mark Smith wrote:
> Current methods commonly used are NAT and DSR. v6 implementations of traditional devices have been using NAT only, and still working on DSR support. A quick search shows IPVS (linux) for IPv6 with both NAT and DR support.
> 
> By strictest definition, NAT66 has been implemented and deployed already.

For clarification, could you be more specific:
- NAT66 according to which specification?
- where (for example)?

> 
> It is not so much NAT66 which is the danger, but where it is deployed. Having NAT66 in CPE for residential users would be extremely bad.

Full agreement.

> Special use cases, or environments where the breaking of communications (certain corporate firewalls), should be considered completely acceptable. IPv6 gives us the ability to not REQUIRE NAT66, but

> it does not remove the market demand for NAT66,

This demand you see may not remain when:
- It is better understood that:
 . Firewalls can filter restrict reachability as efficiently without NATs as with them.
 . Privacy can be achieved by other means than NATs and can be lost even across NATs.
 . More complete multihoming support is made available without NATs than feasible across NATs 

BTW, is this demand you see for (stateful) NAPTv6 or for (stateless) NPTv6 (being noted that the latter doesn't improve privacy)?

Regards,
RD   

> though it does lessen it.
> 
> 
> Jack
>

---

From: Jack Bates <[email-masked]>
Date: Mon, 17 Jan 2011 08:39:27 -0600

> anycast host the traffic is sent by the upstream router, spreading the

Current methods commonly used are NAT and DSR. v6 implementations of 
traditional devices have been using NAT only, and still working on DSR 
support. A quick search shows IPVS (linux) for IPv6 with both NAT and DR 
support.

It is not so much NAT66 which is the danger, but where it is deployed. 
Having NAT66 in CPE for residential users would be extremely bad. 
Special use cases, or environments where the breaking of communications 
(certain corporate firewalls), should be considered completely 
acceptable. IPv6 gives us the ability to not REQUIRE NAT66, but it does 
not remove the market demand for NAT66, though it does lessen it.

Jack

---

From: Jack Bates <[email-masked]>
Date: Mon, 17 Jan 2011 10:49:43 -0600

> - NAT66 according to which specification?

I thought this was answered. It's deployed by load balancers which use NAT.

>   . More complete multihoming support is made available without NATs than feasible across NATs

I agree, but I suspect the demand will remain for a long time, though at 
a much smaller market pressure than we've had in v4. Operations 
community still argues over NAPT uses within a firewall over state-only 
firewalls. Discussion with a variety of corporate admins has also shown 
a split between those who welcome global addressing internally (open 
educational networks) and those who wish to continue utilizing NAPT 
(draconian corporate admins).

> BTW, is this demand you see for (stateful) NAPTv6 or for (stateless) NPTv6 (being noted that the latter doesn't improve privacy)?

NAPTv6 in corporate and load balancers.

Jack Bates

---

From: Rémi Després <[email-masked]>
Date: Mon, 17 Jan 2011 18:27:01 +0100

> I thought this was answered. It's deployed by load balancers which use NAT.

- An informational document on such a deployment would IMHO be useful.
- From your answer below, one can derive that the NAT66 spec you refer to is NAPTv6 (for which there is so far no draft), and not draft-mrw-nat66 (the only draft so far that specifies a NAT66).

> NAPTv6 in corporate and load balancers.

Thanks.
IMHO, a lot of confusion will be avoided if "NAPTv6" is used rather than "NAT66" when what is meant is NAPTv6.

Regards,
RD

---

From: Fred Baker <[email-masked]>
Date: Mon, 17 Jan 2011 09:54:26 -0800

> - An informational document on such a deployment would IMHO be useful.

There's not much to write. It is pretty much standard practice. 

Case 1: it's literally a NAT; it redirects TCP sessions sent to a common address to one of a number of servers. How it measures server load varies; the server may inform it of what it considers its load to be (a server with a few CPUs might get "loaded" more quickly than one with many CPUs), the NAT box may try to keep a roughly equal number of TCP sessions to each of several servers, or the NAT box might try to maintain roughly equal traffic flow from each of several servers, redirecting new sessions to whichever server currently has the lowest load. 

Case 2: It's an application layer gateway that uses NAT technology to accomplish its goals. The most common case is HTTP. The ALG may operate by maintaining a pool of open TCP sessions with each of a set of (or several discrete sets of) servers, or it may open up new sessions as needed. In any event, it terminates an incoming HTTP session and goes through an on/off pattern - it collects a "GET", determines which server to send that to, obtains (opens or allocates) a TCP session to the server, forwards the "GET" to the server, and uses NAT techniques to maintain traffic flow between the server and the client. When the server terminates the session, it does *not* pass that along; it instead awaits the next GET. Note that different GET targets may be sent to different servers or pools of servers.

> - From your answer below, one can derive that the NAT66 spec you refer to is NAPTv6 (for which there is so far no draft), and not draft-mrw-nat66 (the only draft so far that specifies a NAT66).

It could be, but it doesn't have to be. It is solving a different problem. It is doing data center load balancing, which 6man is very carefully avoiding looking at in its load balancing draft.

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 Jan 2011 06:52:15 +1030

On Mon, 17 Jan 2011 08:39:27 -0600

> support. A quick search shows IPVS (linux) for IPv6 with both NAT and DR 

I think that is unfortunate and a missed opportunity. However, I
suspect these people haven't been on the other side of those sorts of
devices very often, trying to troubleshoot problems through
them. They might then appreciate how useful end-to-end transparency
between the actual communicating end-nodes is after trying to do that a
dozen or so times.

---

From: Rémi Després <[email-masked]>
Date: Tue, 18 Jan 2011 11:50:55 +0100

Fred.
That's very much clarifying.
Thank you.

More comments in line.

Le 17 janv. 2011 à 18:54, Fred Baker a écrit :
> On Jan 17, 2011, at 9:27 AM, Rémi Després wrote :
> ...

It's now clear that:
(a) These scenarios differ from classical NAT scenarios (incoming connections are THE subject, rather than having to be blocked). 
(b) These NATs, to exercise their load-balancing function, do 1:n mappings. 

> It could be, but it doesn't have to be.

In my understanding, because NAT mappings of *web-server load balancing* need to be 1:n (point (b) above), this excludes in IPv6 that the NAT be an NPTv6. (NPTv6 is inherently 1:1.)
Contrary to what I wrote, this point isn't a matter of preference. It's simply a technical obligation.

> It is solving a different problem.
> It is doing data center load balancing, which 6man is very carefully avoiding looking at in its load balancing draft.

That's, I guess, where I was confused.

The conclusion then seems to be that:
- So far, the *data-center load balancing* application isn't described in any RFC, or even in any draft, but does exist and, in IPv6, uses some NAT66.
- For this application, which inherently needs 1:n mappings, the NAT66 cannot be NPTv6.
- If tunneling between the load balancer and servers would be used instead of NAT66, load balancing would be achieved without sacrificing e2e address transparency but this isn't the deployed approach.

Regards,
RD

---

From: Mark Smith <[email-masked]>
Date: Tue, 18 Jan 2011 23:03:57 +1030

On Tue, 18 Jan 2011 11:50:55 +0100
Rémi Després <[email-masked]> wrote:

> In my understanding, because NAT mappings of *web-server load balancing* need to be 1:n

I don't think NAPT is necessary to achieve that. 

The fundamental goal of (web-)server "load balancing" is to represent
externally a number of internal hosts as though they were a
single host with a single address. Anycast achieves sharing a single
address among multiple hosts, with the difference being that
the load is sent to the host that the routing protocol determines is
closest to the traffic source. "load balancing" can be achieved with a
few fairly minor architectural modifications - place all the hosts
effectively equidistant from the client(s), and have an upstream
forwarding device (likely the hop directly before the hosts) use
candidate destination host load as the metric to select one of the paths
towards one of the hosts for new connections, and ensure all latter
traffic for the same session/connection follows the same path towards
the same previously selected host.

This isn't functionally much different to per-session packet load
balancing routers perform today when there are multiple FIB entries for
the same destination out different interfaces.

> (point (b) above), this excludes in IPv6 that the NAT be an NPTv6.
> (NPTv6 is inherently 1:1.)

I don't think tunnelling is necessary between the load balancer and the
servers. All that is required is to be able to have the upstream
forwarding device uniquely distinguish between the hosts despite them
sharing the same IP address. Separate outbound interfaces directly
attached to hosts, or separate destination link layer addresses that
aren't determined via resolution of the load balanced anycast address
would be adequate. (Tunnels is really just a form of the separate
outbound interface method.)

One method to achieve the separate destination link layer address
method would be to have the load balanced anycast address
configured on a loopback interface within the servers, and have the
servers forward traffic between their external interface and the
loopback (and make sure proxy-arp is off). The upstream load balancing
forwarding device would use (load-balancing) routes with the hosts'
external interface addresses as the next hops.

Regards,
Mark.

---

From: Jack Bates <[email-masked]>
Date: Tue, 18 Jan 2011 07:36:23 -0600

> I don't think NAPT is necessary to achieve that.
It's not. There is also DSR (Direct Server Return). However, neither is 
technically address transparent, as anycasting is anything but 
transparent in this case.
> and ensure all latter
With some applications, it's also necessary to forward all traffic from 
the original sender towards the same selected host. This is usually 
optimized by only considering hosts with existing open mappings, so it 
doesn't utilize more memory than your method. One common application 
which needs this is imap. Depending on the web application and cross 
server session management, it also may require it.

> external interface addresses as the next hops.

There is no arp in v6. However, you've described DSR as it currently is.

Jack (no coffee yet, so while it makes sense to me, forgive any mistakes)

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Jan 2011 10:18:00 -0800

> (a) These scenarios differ from classical NAT scenarios (incoming connections are THE subject, rather than having to be blocked). 

Well, they differ from NAT scenarios that the IETF has considered. I would object to the assertion that what you're calling a "traditional NAT" has as its primary function to block sessions. A Network Address Translator, in any usage, has as it primary function the translation of network layer addresses. What you're pointing out is that any stateful NAT (as opposed to that described in SIIT for example) has a "translated from" and a "translated to" side and an algorithm by which it creates its translation state. What you're calling a "traditional NAT" translates "from" in "inside" domain and doesn't change the "outside" destination address. A load balancer - which is in no sense a new use of NAT technology, its just one the IETF hasn't focused on - translates "from" the great wide world, and the algorithm by which it creates translation state is more complex.

> (b) These NATs, to exercise their load-balancing function, do 1:n mappings. 

That is certainly one way to do it. What I have tried to point out is that there is a class of widely-used products that do.

---

From: Mark Smith <[email-masked]>
Date: Wed, 19 Jan 2011 07:25:36 +1030

Hi Jack,

On Tue, 18 Jan 2011 07:36:23 -0600

> transparent in this case.

The e2e transparency being talked about is that packets travel between
the communication end-points without the end-point identifiers or the
payloads being modified i.e. at the layer 3 devices between the
end-points packets are conventionally forwarded rather than being both
modified and forwarded.

There are issues with anycast, mainly because anycast doesn't
absolutely uniquely identify one (or both) of the communication
end-points. That is no worse than NAT based load balancing. What is
better with "anycast LB" is that there is no interference with the
packets as they traverse the network. That interference has been the
origin of some of the faults I've had to troubleshoot involving NAT
based load balancers.

My fundamental personal preference would be for people to deploy proper
clustered operating systems (i.e. single system image) for their
applications such that the server is truely one single system and
end-point from the network's point of view, and there is no need to
resort to networking tricks within the network to try to simulate that
for external clients. That would mean no NAT and no anycast. I realise
that may be an ideal, however the closer to that ideal the solutions
are the less complexity and unconventional behaviour I as a networking
person has to deal with. 

> There is no arp in v6.

Sure - proxy-arp was rush used word, I should have used proxy-neighbor
discovery.

> However, you've described DSR as it currently is.
> 

If DSR is what is described at this web page, then not quite -

http://lbwiki.com/index.php/DSR

If the load balancer acts more like a router, and the router above it
announces the best path towards the anycast LB address, then there is
no need for the anycast LB address to be configured on the load
balancing router itself. That might sound like a me being pedantic
about the difference, however routers already forward packets in the
way I'm describing (the difference is the policy applied to forwarding
decisions), and therefore makes the networking component simper and more
conventional.

Regards,
Mark.

---

From: Jack Bates <[email-masked]>
Date: Tue, 18 Jan 2011 15:16:30 -0600

> are the less complexity and unconventional behaviour I as a networking

While I agree, I've yet to see a cost effective clustering mechanism for 
proper load distribution for simple things such as http/smtp/imap. This 
may be my own ignorance of current clustering functionality.

> decisions), and therefore makes the networking component simper and more

I believe you are talking about my original mechanism for load 
balancing, which was to utilize routing protocols on the servers to 
announce to the router that a server was available. In general 
principle, it was effective, but only on a per flow basis (standard flow 
based balancing of routers insured that a connection held to a single 
server so long as it was active). I didn't see any options in current 
routers to support utilizing a single path for all packets from a source 
(required for when current state is only stored on one server and not 
shared by all servers). This last part was the deciding point for me to 
shift to DSR with a specialized load balancer.

That being said, there are several things that NAT can do, which DSR 
cannot. This is one reason NAT is still often deployed over DSR in load 
balancing hardware. This has been magnified with the introduction of 
IPv6 to large scale production networks, where there is a need to run 
mixed environments supporting v6->v6 v6->v4 v4->v6 v4->v4 depending on 
the systems supported and the IP protocols used both public and internal.

Jack

---

From: Erik Kline <[email-masked]>
Date: Wed, 19 Jan 2011 09:47:16 +0900

> I believe you are talking about my original mechanism for load balancing,
> which was to utilize routing protocols on the servers to announce to the
> router that a server was available. In general principle, it was effective,
> but only on a per flow basis (standard flow based balancing of routers
> insured that a connection held to a single server so long as it was active).
> I didn't see any options in current routers to support utilizing a single
> path for all packets from a source (required for when current state is only
> stored on one server and not shared by all servers). This last part was the
> deciding point for me to shift to DSR with a specialized load balancer.

Depending on the architecture, ECMP may help.

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Jan 2011 20:04:48 -0800

On Jan 18, 2011, at 1:16 PM, Jack Bates wrote:

> I didn't see any options in current routers to support utilizing a single path for all packets from a source (required for when current state is only stored on one server and not shared by all servers). 

This confuses me. Let me give you two references, both found via Google.

http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-routing-vol1/html/ip-config11.html
search for the word "hash".
"Hashed - uses hashing of source and destination addresses to determine which of the available paths in the ECMP set to use"

http://www.cisco.com/en/US/tech/tk827/tk831/technologies_tech_note09186a0080094806.shtml
(for some reason, if you look at Google you would think we only do this for IBGP or only for multicast; it applies to all routing protocols as it is an attribute of CEF)
"The session-to-path assignment is done using a hash function that takes the source and destination IP addresses and, in recent releases of Cisco IOS, a unique hash ID that randomizes the assignment across the end-to-end path."

I imagine you could find similar statements from any IP router vendor out there.

If your destination address (the address of the system you are routing towards) is constant (the sessions are all with the same server address), then any hash of the source and destination address should come up with the same number for all sessions from any given source address. Barring a change in routing, that would send them all down the same path.

Did I miss something?

---

From: Erik Kline <[email-masked]>
Date: Wed, 19 Jan 2011 13:11:46 +0900

> If your destination address (the address of the system you are routing towards) is constant (the sessions are all with the same server address), then any hash of the source and destination address…

There are load balancing systems that (IIRC) work pretty much exactly this way.

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Jan 2011 21:05:21 -0800

> There are load balancing systems that (IIRC) work pretty much exactly this way.

Um. Yes. That's what these web pages describe...

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 18 Jan 2011 21:23:08 -0800

On 1/18/11 8:04 PM, Fred Baker wrote:
>> I didn't see any options in current routers to support utilizing a
>> single path for all packets from a source (required for when
>> current state is only stored on one server and not shared by all
>> servers).

stateless layer 3 load balancer is what one is is looking for. in a
former life we used one (built on an off the self l3 ethernet switch
asic as the front-end for a cluster of firewalls).

one such example of a product specfically for this purpose is:

http://www.bladenetwork.net/iFlow.html

> "Hashed - uses hashing of source and destination addresses to
> determine which of the available paths in the ECMP set to use"
> 
(for some reason, if you look at Google you would think we only do this
for IBGP or only for multicast; it applies to all routing protocols as
it is an attribute of CEF)
> "The session-to-path assignment is done using a hash function that
> takes the source and destination IP addresses and, in recent releases
> of Cisco IOS, a unique hash ID that randomizes the assignment across
> the end-to-end path."
> 
> If your destination address (the address of the system you are
> routing towards) is constant (the sessions are all with the same
> server address), then any hash of the source and destination address
> should come up with the same number for all sessions from any given
> source address. Barring a change in routing, that would send them all
> down the same path.
> 
> Did I miss something? 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 19 Jan 2011 13:41:47 +0100

Le 18 janv. 2011 à 19:18, Fred Baker a écrit :

> Well, they differ from NAT scenarios that the IETF has considered.

OK

> I would object to the assertion that what you're calling a "traditional NAT" has as its primary function to block sessions.

I didn't say is was their "primary" function, only that they had this function.
=> no reason to object (we agree).

> A Network Address Translator, in any usage, has as it primary function the translation of network layer addresses.

> What you're pointing out is that any stateful NAT (as opposed to that described in SIIT for example) has a "translated from" and a "translated to" side and an algorithm by which it creates its translation state.

If "translation from" is synonymous with "mappings initiated by outgoing connections", we agree.

> What you're calling a "traditional NAT" translates "from" in "inside" domain and doesn't change the "outside" destination address.

I only meant that traditional NAT's initiate their mappings with outgoing connections, .

> A load balancer - which is in no sense a new use of NAT technology,

Not "new", I agree, but still different from IETF documented uses of NATs.
Again, thanks for having clarified that "data-center load balancing" was THE scenario being discussed on this thread.

> its just one the IETF hasn't focused on - translates "from" the great wide world, and the algorithm by which it creates translation state is more complex.

OK

> That is certainly one way to do it. What I have tried to point out is that there is a class of widely-used products that do.

The point I made (important IMHO) is that, for data-center load balancing, NPTv6 isn't applicable because its mappings are 1:1 while the application requires 1:n.

Can we agree on this too?

Regards,
RD

---

From: Jack Bates <[email-masked]>
Date: Wed, 19 Jan 2011 09:09:45 -0600

> This confuses me. Let me give you two references, both found via Google.

<sniper juniper e-series and cisco IOS references>

> If your destination address (the address of the system you are routing towards) is constant (the sessions are all with the same server address), then any hash of the source and destination address…

My erroneous use of the word "current" and vendor neutrality.

My routers don't always use sourceIP/destIP as the only pieces of a 
hash. Even the cisco page mentions inclusion of a session ID and today 
supports 3 algorithms at the global level for cef load-sharing. We 
checked traffic decisions in the production network at the time we were 
looking for a solution and had various behaviors and few knobs. We 
deemed using routing tricks to be too unreliable and dangerous in the 
face of having to upgrade code regularly for better IPv6 support.

Today, I utilize on a per service basis multiple policies. There are 
cases where I do not want a source address locked to a single server. 
The load balancer allows a much granular configuration over routing tricks.

<snipped long response of other benefits of load balancers over using 
routing tricks that don't apply to your specific question>

Jack

---

From: Mark Smith <[email-masked]>
Date: Thu, 20 Jan 2011 07:31:31 +1030

On Wed, 19 Jan 2011 09:09:45 -0600

> The load balancer allows a much granular configuration over routing tricks.

When I mentioned what current routers are capable of doing regarding
sessions, I was thinking about hashing. However, that was more of an
example to show that routers are already capable of sending traffic
with the same destination over more than one route in a session aware
manner.

I think though that the drawback of a simple hash is that it isn't load
sensitive. So a forwarding method that actively chooses a destination
server based on load is needed, and then subsequently all packets with
the same source address and port need to be sent to the same selected
server. I've realised that is describing policy routing/forwarding,
where the source address and port as well as the destination address is
used as a fib entry selector - when ever a new connection comes in, and
a server is selected, then a policy route is installed to forward all
subsequent traffic to the same server. I was hoping that it might be
possible to avoid having to look at the traffic stream after that, and
let the policy route take care of it, however those policy routes need
to be removed when the session is finished, and I think the only way to
know when remove them correctly would be to watch for e.g. TCP
FIN/ACKs. 

Regards,
Mark.