Subject: Re: [nat66] NAT66 / IPv6 NAT and assumption of /48

From: Rémi Després <[email-masked]>
Date: Wed, 01 Apr 2009 15:03:18 +0200

Margaret Wasserman  -  le (m/j/a) 3/31/09 7:52 PM:
> 
> On Mar 31, 2009, at 1:44 PM, Rémi Després wrote:
>>
>> If the transport protocol is neither UDP nor TCP, is it not true that 
>> doing or not doing further address modification after prefix 
>> replacement (for UDP/TCP checksums to be unchanged) has no effect on 
>> whatever encrypt/protect mechanism this transport might introduce?
> 
> It is altogether possible to create a transport that doesn't do anything 
> to checksum, encrypt or protect the IP address that appear in the IP 
> header.  SCTP is one example, as I understand it.

Sure, I do share this understanding.

But this was not the point. (I don't see why performing UDP checksum 
adjustment in the UDP header rather than in the IP layer would have any 
adverse effect on SCTP, or on any other non UDP/TCP transport.)

Regards,

RD

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Apr 2009 08:48:41 -0700

And they would have no customers, and they would complain that IPv6  
didn't buy them anything.

Yes, there are idiots in the world.

On Mar 30, 2009, at 7:04 AM, Wes Beebee (wbeebee) wrote:

> ... And ISP's could just say "we're only handing out one /128" because
> we're expecting you to deploy NAPT66 - and there are plenty of vendors
> willing to sell NAPT66 boxes...
>
> - Wes
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Keith Moore
> Sent: Monday, March 30, 2009 3:43 AM
> To: Mark Townsley (townsley)
> Cc: Margaret Wasserman; [email-masked]; [email-masked]
> Subject: Re: [nat66] NAT66 / IPv6 NAT and assumption of /48
>
> Mark Townsley wrote:
>
>> This is all really just crystal-ball gazing, but if one of the  
>> reasons
>
>> we are going to build NAT66 openly in the IETF is to avoid vendors
>> building it themselves, I find it hard to believe that targeting /48
>> only will suffice. Certainly, if /48 service (along with a  
>> "compatible
>
>> with IETF NAT66" bullet-point in the SLA) comes at a premium in terms
>> of monthly service fees vs., say, a /56 or otherwise,  then you've
>> given an incentive to small router vendors to build something that
>> allows one to get all the advantages of /48-type service with a /56
> service contract.
>> Voila, the vendor gets to reap the difference between the service  
>> fees
>
>> for /48 vs. /56... Much like they did for a /32 vs. /30 (or "multiple
>> IP" service) in IPv4.... see where I'm going with this?
>
> It seems like one of the consequences of IETF defining NAT66 might  
> then
> be that it pushes us further down the "slippery slope" toward  
> widespread
> NAT in IPv6.  It's one thing if it turns out being used by medium  
> sized
> enterprises, quite another if it turns out appearing in every consumer
> IPv6 router.  I'm actually much less concerned about the  
> consequences of
> NAT66 in medium enterprises (who can presumably make a technical
> evaluation of the pros and cons of NAT for their particular business
> needs and then choose whether to solve their say multihoming problem
> with NAT or by some other means) than for home users (who are forced  
> to
> use NAT in IPv4 in part because a single address is all most can
> afford).
>
> What I'd really hate would be for the existence of NAT in IPv6 and in
> home routers to be used by ISPs as an excuse to dole out only /64s or
> longer prefixes.
>
>> Point is, once the genie is out of the bottle, I don't think it is
>> realistic to think that we can keep it backed into a /48 corner.
>> Special-casing /48 may be worthwhile, but we need to somehow address
>> the rest. Going "halfway" here could well be a classic worst of both
>> worlds situation (i.e, we should either define NAT66 in full, or not
> at all).
>
> I really think it depends on what problems NAT66 is expected to solve.
> There's a bit of the "Maslow's hammer" mentality about NAT these  
> days -
> NAT is such a familiar tool that people tend to see lots of different
> problems as address translation problems rather than say, tunneling
> problems.
>
> As I tried to say in SF, we really need to decide which use cases of
> NAT66 are justified (from an engineering perspective) and make sure  
> that
> the solution we develop in IETF actually addresses those cases.   
> Unless
> we do that, we run a real risk of (a) developing a solution to one or
> more non-problems, while (b) failing to develop solutions to bona fide
> problems, with (c) the unintended consequence of promoting wider use  
> of
> NAT in IPv6 than is needed.
>
> For instance, I'm pretty much convinced that the value from the degree
> of topology hiding that can be accomplished by NAT66 is so small that
> it's not worth the cost to deploy it.  There might be people who think
> otherwise, but that doesn't compel IETF to spend its resources solving
> their non-problem - especially when doing so legitimizes the idea of
> IPv6 NAT in the public mindset.  (as certain members of the trade  
> press
> would love to crow about...)
>
> If we were to determine (for example) that the only valid use case we
> could find for NAT was for address independence, we could develop a
> solution for just that case.  And we could call it something besides
> NAT.
>
> Keith
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Apr 2009 08:51:22 -0700

On Mar 30, 2009, at 7:37 AM, Roland Bless wrote:

> I really fear

As near as I can tell, that is the substance of the debate here. There  
are some of us who are trying to do something to make routing scale  
(although the AD tells us that we are not allowed to discuss that) and  
make business/business operations work well, and there are a large  
number of us that are distributing fear, uncertainty, and doubt.

I hate FUD when a sales person uses it, and I hate it more when it  
pretends to be a technical argument.

---

From: Roland Bless <[email-masked]>
Date: Wed, 01 Apr 2009 19:12:43 +0200

Hi Fred,

> pretends to be a technical argument.

I think it's fair enough to discuss about implications that
a new technology or mechanism may have. Sure, it's hypothetical,
but we can already learn from history and judge some decisions
in the past as a mistake from a today's point of view.
Yes, I think that there are operational problems to be solved
for IPv6 since obviously not all requirements can be met right
now, so we must do something about it. I'm convinced that
NAT66 has obviously many advantages over the current v4 NAPT,
however, I'm not yet convinced that it's the right tool to
address the unsolved problems (are they even totally clear?).
NAT66 breaks end-to-end connectivity for some applications
and probably doesn't address the (poorly understood?)
"topology hiding" feature. Don't you think that people will just use
an available NAT66 box, because that's what they are used to have
for IPv4, esp. even when they don't need it actually? Would it be
worth the "cost" in the end?

Regards,
 Roland

---

From: Keith Moore <[email-masked]>
Date: Wed, 01 Apr 2009 13:35:09 -0400

> pretends to be a technical argument.

"fear" is a pretty vague word, with lots of possible meanings, and
people tend to use it pretty casually.

I don't think it's useful to dismiss everyone else's technical concerns
about what "might" happen in some scenario or other as nothing more than
FUD.  Or at least if one does that, he invites having his own concerns
being labeled the same way.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 1 Apr 2009 14:33:55 -0400

I've heard IPv6 described as a major forklift upgrade with a minor
engineering benefit over IPv4 (larger addresses).  At first, I started
arguing with them about the advancements that IPv6 has made.  What I
didn't realize until recently is that that wasn't a complaint, but a
*goal* by some Service Providers with a lot invested in the current IPv4
infrastructure and an aversion to change.

- Wes

-----Original Message-----
From: Fred Baker (fred) 
Sent: Wednesday, April 01, 2009 11:49 AM
To: Wes Beebee (wbeebee)
Cc: Keith Moore; Mark Townsley (townsley); Margaret Wasserman;
[email-masked]; [email-masked]
Subject: Re: [nat66] NAT66 / IPv6 NAT and assumption of /48

> then be that it pushes us further down the "slippery slope" toward 
> widespread NAT in IPv6.  It's one thing if it turns out being used by 
> medium sized enterprises, quite another if it turns out appearing in 
> every consumer
> IPv6 router.  I'm actually much less concerned about the consequences 
> of
> to use NAT in IPv4 in part because a single address is all most can 
> afford).
>
> There's a bit of the "Maslow's hammer" mentality about NAT these days 
> - NAT is such a familiar tool that people tend to see lots of 
> different problems as address translation problems rather than say, 
> tunneling problems.
>

> of NAT in IPv6 than is needed.
>

> press would love to crow about...)
>

---

From: Mark Townsley <[email-masked]>
Date: Wed, 01 Apr 2009 21:27:47 +0200

Wes Beebee (wbeebee) wrote:
> engineering benefit over IPv4 (larger addresses).  
IPv6 doesn't have to be a forklift.

That said, this thread is sufficiently off-topic from NAT66 that it 
should be put to rest or taken elsewhere.

- Mark
> At first, I started

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 2 Apr 2009 14:27:29 -0400

Just joined....

Margaret Wasserman wrote:
> For homes? Or larger enterprises?
>
> My original 6AI BOF request suggested multiple work items, two of 
> which were:
>
> (1) An information (or BCP?) document on how to build a home gateway 
> for IPv6 that includes a firewall (for simple security) and prefix 
> delegation, etc. for easy configuration, but no NAT functionality.
>
> (2) NAT66 to provide address independence for enterprises.
>
> Do we think that home users (regular home users, not us) actually need 
> address independence, or they would be happy to get their addresses 
> from their ISP via PD and to be renumbered when/if needed?

DMZ configuration is not uncommon for home users with separate rfc1918
networks. There are a number of drivers toward something larger than
/64. But even though I have a /48 in my home, something smaller than
/56, and more likely /62 will work for homes and small business offices
(think medical and HIPPA compliance).

>
> If we view NAT66 as applicable to home networks, I agree that we will 
> need to handle prefixes longer than /48. However, I expect that most 
> enterprises will get /48 or larger.
>
> Margaret
>
>
> On Mar 28, 2009, at 11:29 PM, Mark Townsley wrote:
>
>>
>> My ISP currently hands out a /60 via 6rd (space gets a little tight 
>> with the embedded IPv4 address). The BBF is settling on /56 as its 
>> recommended prefix size for residential customers. I've seen /64's 
>> out there as well (and stomped on them as quickly as possible, but 
>> can only do so much).
>>
>> I have to agree that we must expect that variable prefix sizes to 
>> sites will be a reality.
>>
>> - Mark
>>
>> [email-masked] wrote:
>>> >From my perspective the NAT solution that might be specified within 
>>> 6AI should be able to deal also with prefixes shorter, equal or 
>>> _longer_ than a /48 since there might be ISPs giving out such longer 
>>> prefixes to their customers.
>>> (A reason for that are the changed RIR policies that allow the ISPs 
>>> freely to decide if they want to give a /48, a /56 or even a /61 to 
>>> its customers.)
>>>
>>> Removing the /48 assumption will have major impact e.g. on Margarets 
>>> draft.
>>>
>>> br olaf

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 2 Apr 2009 14:27:55 -0400

Mark Townsley wrote:
> I'm in contact with a lot of broadband providers deploying and 
> thinking about deploying IPv6, and have never seen one seriously 
> consider /128. /64, yes. /60 certainly. But never /128.

What about hotels?

Though I think /64 with only one 64 suffix per room (from someone that 
regularly plugs in two different laptops in my hotel rooms, one at a time).

>>> This is all really just crystal-ball gazing, but if one of the reasons
>>>     
>>
>>  
>>> only will suffice. Certainly, if /48 service (along with a "compatible
>>>     
>>
>>  
>>> with IETF NAT66" bullet-point in the SLA) comes at a premium in 
>>> terms of monthly service fees vs., say, a /56 or otherwise,  then 
>>> you've given an incentive to small router vendors to build something 
>>> that allows one to get all the advantages of /48-type service with a 
>>> /56
>>>     
>> service contract.
>>  
>>> Voila, the vendor gets to reap the difference between the service fees
>>>     
>>
>>  
>>> for /48 vs. /56... Much like they did for a /32 vs. /30 (or 
>>> "multiple IP" service) in IPv4.... see where I'm going with this?
>>>     
>>
>> It seems like one of the consequences of IETF defining NAT66 might then
>> be that it pushes us further down the "slippery slope" toward widespread
>> NAT in IPv6.  It's one thing if it turns out being used by medium sized
>> IPv6 router.  I'm actually much less concerned about the consequences of
>> with NAT or by some other means) than for home users (who are forced to
>> There's a bit of the "Maslow's hammer" mentality about NAT these days -
>> NAT66 are justified (from an engineering perspective) and make sure that
>> the solution we develop in IETF actually addresses those cases.  Unless
>> problems, with (c) the unintended consequence of promoting wider use of
>> IPv6 NAT in the public mindset.  (as certain members of the trade press

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 2 Apr 2009 14:32:57 -0400

Margaret Wasserman wrote:
> It sounds like we are fairly certain that homes and some small 
> businesses will be given prefixes longer than /48 by their providers.  
> Are we also convinced that those small networks will require the 
> address independence feature provided by NAT66?  I guess this question 
> boils down to whether we expect two (or more) hosts within a small 
> network to communicate directly with each other using global IPv6 
> addresses.

It is called a large portion of today's gaming community that are doing 
this today thanks to Teredo.

Wouldn't sundowning Teredo be of value?

>
> If we do need to address prefixes of longer than /48 in NAT66, that is 
> fairly easy to do.  We just need to pick which sacrifices we are 
> willing to make.  I can think of two choices:
>
> (1) Add the checksum correction to a 2byte portion of the lower 64 
> bits when the prefix is longer than /48, thus modifying the IID.  This 
> wouldn't be compatible with (currently unspecified) mechanisms that 
> require a constant IID, but we would already have that problem with 
> nodes that generate privacy addresses.
>
> or
>
> (2) Fix the UDP or TCP checksum instead of performing the checksum 
> correction algorithm when the prefix is longer than /48.  The cost 
> here is that we lose the ability to encrypt/protect the transport 
> layer headers.  In NAT66, we could explicitly make this correction for 
> UDP/TCP only, passing through other transport layers unmodified, which 
> might help to reduce the impact on new innovations at the transport 
> layer.
>
> Margaret
>
>
> On Mar 30, 2009, at 12:17 PM, Mark Townsley wrote:
>
>>
>> My experience is that those brand new to IPv6 (and who don't do some 
>> reading up front) first think of offering a /128, but are quickly 
>> convinced that /64 is the real minimum (which is why I said I had 
>> never seen one "seriously" consider a /128). Then, after some time, 
>> they can be convinced to move the line up to a /56, but it takes a 
>> second push - one that's a little bit harder than the first. Going 
>> further, to a /48, is often a tough sell for residential.
>>
>> That's my experience at least, YMMV. I've never actually seen a 
>> residential /128 service, though I have seen /64, /60, /56 and /48.
>>
>> - Mark
>>
>> Marc Blanchet wrote:
>>> Mark Townsley a écrit :
>>>
>>>> thinking
>>>> about deploying IPv6, and have never seen one seriously consider /128.
>>>> /64, yes. /60 certainly. But never /128.
>>>>
>>>
>>> I'm too "in contact with a lot of broadband providers deploying and
>>> thinking about deploying IPv6".
>>>
>>> and some were first thinking to give a /128 as the "basic service", 
>>> even
>>> after some education on how "IPv6 works"... The possible arrival of
>>> 6ai/nat66 has already bring back this notion of /128, since it "just
>>> maps" with their current v4 deployment/billing/OSS/...
>>>
>>> note that I don't think /128+nat66-6ai is a good idea, but I would
>>> certainly be careful claiming that it would not happen or it is not on
>>> the design table.
>>>
>>> Marc.
>>>
>>>
>>>> - Mark
>>>>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 2 Apr 2009 16:25:35 -0400

Tony Hain wrote:
> In any case, the 66nat effort is a solution looking for a problem, but if it
> does exist it should be based on technical rather than policy issues. 

Can we develop a list of techincal issues that are drivers for IPv6NATs?

Address Independence
    and multihoming?
Topology hiding
Address Amplification
    Is this tied into prefix allocations or is this a separate one?

And what else?

Then we define what each means and offer solutions today for them.

BTW, I am working on a non-NAT proposal for topology hiding (not
discussing what your internal network structure is).  There is a general
solution and specific solution paths with existing host technology.  Do
have some serious issues to munch on still.  It might also address
address amplification, but am not sure.

---

From: Fred Baker <[email-masked]>
Date: Thu, 2 Apr 2009 13:36:15 -0700

>   Is this tied into prefix allocations or is this a separate one?

The business/business matter might be an example of topology hiding,  
but I think it is a sufficiently special case that it bears calling out.

> discussing what your internal network structure is).

In that context, you imght want to review
     http://tools.ietf.org/html/draft-baker-v6ops-b2b-private-routing
and http://www.ietf.org/rfc/rfc4864.txt

In the former case, I will argue that a DMZ router, perhaps virtual,  
that has exactly two /128 ULA static routes, one in each direction,  
goes a long way in the intended direction. My IT department basically  
told me it wasn't going to happen, however. They are comfortable with  
NAT, and after we give them the product they request they will  
consider moving the affected services to IPv6.

---

From: Dave Thaler <[email-masked]>
Date: Thu, 2 Apr 2009 17:44:37 -0700

> Of Robert Moskowitz
> Sent: Thursday, April 02, 2009 1:26 PM
> To: [email-masked]
> Subject: [nat66] Designing NATs out of the IPv6 deployments
>
>
> Tony Hain wrote:

See RFC 4864.

-Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Apr 2009 14:01:53 +1300

> businesses will be given prefixes longer than /48 by their providers. 

Yes. It's running code.

> Are we also convinced that those small networks will require the address
> independence feature provided by NAT66?  I guess this question boils
> down to whether we expect two (or more) hosts within a small network to
> communicate directly with each other using global IPv6 addresses.

Well, I've been told often enough that small sites will sooner or later
want all the features available to big sites. It's crystal-ball gazing
of course, but anything else seems like a risky assumption. So /64
seems necessary to support.

Where we should stop, IMHO, is in offering any comfort to ISPs that
want to try to get away with /128.

   Brian

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 2 Apr 2009 21:18:35 -0400

Dave Thaler wrote:
>>> In any case, the 66nat effort is a solution looking for a problem,
>>>       
>> but if it
>>     

Would that be only sec 6?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Apr 2009 14:34:14 +1300

Bob,

On 2009-04-03 14:18, Robert Moskowitz wrote:

<snip>

> Would that be only sec 6?

That was the intention of the authors of 4864, but we might have missed
something.

However, address amplification is *not* on my list. We really need ISPs
to give (well, actually rent out) short enough prefixes that this
excuse for NAT utterly vanishes.

    Brian

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 2 Apr 2009 22:41:57 -0400

> excuse for NAT utterly vanishes.

Well if you're goal is to design NATs out of the IPv6 deployments and 
you recognize the root driver for address amplification, then your goal 
is to remove that driver so there will not be a need for address 
amplification driving a NAT market.

Did I express that well enough? Remember, I look at my wording through 
my dyslexic eyes....

Anyway, so we have to ensure that address prefixs are 'right sized'. 
Does this mean nothing larger than /62? /60? That we issue a BCP to 
boycott any ISP issuing /64s or single addresses (hotel rooms?)?

 From what I am hearing, Address amplification is a problem that drives 
NAT and a problem that can 'easily' be mitigated.

---

From: Rémi Després <[email-masked]>
Date: Fri, 03 Apr 2009 12:22:26 +0200

> Can we develop a list of techincal issues that are drivers for IPv6NATs?

draft-despres-sam-02 has a list
      2.1.  Private addressing (easy renumbering)  . . . . . . . . . .  4
      2.2.  Basic firewall (by default, no incoming connections) . . .  4
      2.3.  Site multihoming (automatic fallback)  . . . . . . . . . .  4
      2.4.  Privacy protection . . . . . . . . . . . . . . . . . . . .  4
      2.5.  Host-rooted subnets  . . . . . . . . . . . . . . . . . . .  5

It contains a brief explanation of what each item means, and propposes a 
technical solution for each of them.

It is I believe a contribution in the direction you are looking for.

Regards,

RD

---

From: Gert Doering <[email-masked]>
Date: Mon, 6 Apr 2009 19:16:38 +0200

Hi,

> regularly plugs in two different laptops in my hotel rooms, one at a time).

This "hotel" argument is showing up regularily in this discussion, and is
confusing me.

Why do you expect dedicated routed subnets per room?

My naive approach to "hotels" would have been "one flat /64, autoconfig,
captive portal".  How does the "one /64 per room" model work?

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Fred Baker <[email-masked]>
Date: Wed, 8 Apr 2009 12:40:53 -0700

well, tell me this. Have you ever stayed in a hotel that had more than  
one router? I have.

Yes, I would tend to expect a /64 per room, and controlled information  
flow by whatever implementation (typical broadband model, firewall  
model, whatever) between rooms. Ditto in an apartment complex - I  
would not expect that every apartment is a host, I would assume that  
an apartment is the equivalent of any other home. http://www.ietf.org/rfc/rfc5375.txt 
  would suggest that one wants to provide a /60 or /56 to a home -  
more than one subnet in any event.