Subject: Re: [nat66] Fwd: New Version Notification - draft-mrw-nat66-08.txt

From: "S.P.Zeidler" <[email-masked]>
Date: Wed, 2 Mar 2011 08:28:23 +0100

Hi,

chapter 5, dot 5, >>to "outside" the of it,<< surplus the

in section 5.1 I would not say that the -benefits- are consistent
with the app requirements; the -drawbacks- need to be acceptable for
app requirements instead. How about:

--- snip ---
In light of the above, network planners considering the use of NPTv6	
translation should carefully consider the kinds of applications that	
they will need to run in the future, and determine whether the limitation
on the types of applications that is imposed by using NPTv6 is acceptable,
and will be outweighed by the address stability and provider independence
benefits. It's a trade-off.
--- snip ---

regards,
	spz
-- 
[email-masked] (S.P.Zeidler)

---

From: Fred Baker <[email-masked]>
Date: Wed, 2 Mar 2011 08:23:48 -0800

Thanks for the comment I picked up the first, which is an obvious typo. Your suggested text changes the last sentence of 5.1 and adds "it's a trade-off". I understand you to be trying to say "NPTv6 is likely to prevent you from running certain applications." I'll point out that the use of NAPT has not prevented folks from running applications; it has made it a lot harder, and they have had to work around the NAPT, but it has meant that they move the applications to zones in their network designed to handle them. NPTv6 allows them to do the same within the privately-addressed parts of their network, which seems like a benefit, and in general if they have both the internal and external addresses of peers and are using "Happy Eyeballs" technology (so that they in fact use whatever address works), the user experience will be the same as a network without translation. So I don't agree that it's as much of a barrier as you seem to think it is.

---

From: "S.P.Zeidler" <[email-masked]>
Date: Wed, 2 Mar 2011 21:30:06 +0100

Hi,

> Thanks for the comment I picked up the first, which is an obvious typo. Your suggested text changes the last sentence of 5.1 and adds "it's a trade-off". I understand you to be trying to say "NPTv6…

I seem to have utterly failed to get my point across. Let me try again:

Which applications will have trouble with address stability and
provider independence, thus requiring you to make the benefits of NPTv6
line up with the applications you want to use??

regards,
	spz

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Mar 2011 10:03:10 +1300

On 2011-03-03 09:30, S.P.Zeidler wrote:
...
> line up with the applications you want to use??

The usual ones - those that for whatever reason have explicit
dependency on the IP address of the peer. We've known for 15 years
that this is bad design, but it hasn't stopped us doing it.

    Brian

---

From: "S.P.Zeidler" <[email-masked]>
Date: Wed, 2 Mar 2011 22:49:13 +0100

Thus wrote Brian E Carpenter ([email-masked]):

> dependency on the IP address of the peer.

i.e. they will have trouble with PI addresses also?
because they have a problem with the addresses being stable and provider
independent?

> We've known for 15 years

regards,
	spz

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Mar 2011 11:20:03 +1300

> i.e. they will have trouble with PI addresses also?

No, why?

The FTP PORT command is the oldest instance of the problem, and SIP
has a serious version of the problem. NPTv6 will need application layer
support for cases like these, but since the same support is needed
today for NAT44 and will be needed for NAT64, this doesn't seem to
be a new problem. Section 5 of the draft covers it.

IPsec also has a problem with NPTv6, but I suppose RFC 3948 applies.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 2 Mar 2011 18:09:43 -0500

> that this is bad design, but it hasn't stopped us doing it.

Actually, I'd say that we've known for 15 years that having the network alter IP addresses is a bad design, but it hasn't stopped people from doing it.

Application writers have known for about as long that depending on DNS names to work in every instance, and from every location on the Internet, is a bad design.  The widespread use of NATs, coupled with numerous problems in the way DNS is maintained and deployed, mean that there is no single host name or token that an application instance can reliably use to reach a particular peer.

Keith

---

From: "S.P.Zeidler" <[email-masked]>
Date: Thu, 3 Mar 2011 07:51:33 +0100

> > i.e. they will have trouble with PI addresses also?

I am trying to point out that you (and the draft) are claiming that.

The benefit of NPTv6 is address stability and provider independence.
The benefit of PI is address stability and provider independence.

The cost of the method NPTv6 applies to get that benefit is that the
addresses change in flight. -This- is the issue.

The benefit does not cause any trouble.
The means by which you reach this benefit may.

You see the distinction?

regards,
	spz

---

From: Christian Huitema <[email-masked]>
Date: Thu, 3 Mar 2011 17:24:17 +0000

> The cost of the method NPTv6 applies to get that benefit is that the addresses change in flight. -This- is the issue.

But PI has its own set of costs. There is the impact on the global routing tables, which means PI can only be a solution for a relatively small fraction of the users. And there is the administrative cost of getting a PI address allocated, and then convincing the network providers to advertise it.

You could just as well mention the advantage of provider based addresses -- no address stability, no provider independence, but very low administrative cost, no impact on global routing, and transparency to applications.

I suppose we could summarize all that in a neat table.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Mar 2011 08:48:40 +1300

> The means by which you reach this benefit may.

Of course. PI has the cost of exploding the BGP4 table.
NPTv6 has the cost of destroying address transparency.

Since SHIM6 has neither of these costs, are you surprised
that I prefer it?

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Mar 2011 08:54:39 +1300

> I suppose we could summarize all that in a neat table.

To some extent, that is done in:

H. Naderi and B.E. Carpenter, A Review of IPv6 Multihoming Solutions, Tenth International Conference on Networks ( ICN 2011),
St. Maarten, (January 2011) 145-150.

http://www.cs.auckland.ac.nz/~brian/multi6survey.pdf

(NPTv6 is called NAT66 in the paper, since the renaming came too late.)

---

From: JFC Morfin <[email-masked]>
Date: Thu, 03 Mar 2011 14:10:19 +0100

>The benefit of NPTv6 is address stability and provider independence.

and technology independence for IDv6, i.e. domain centric sub-addressing.

>The benefit of PI is address stability and provider independence.

paid by management rigidity (what about ISP rotation possibility and 
mobility) and machine overload.

>addresses change in flight. -This- is the issue.

Correct. However, (1) this also can be considered as an advantage and 
(2) NPTv6 is not in opposition with IP usage but complemntary.

>The means by which you reach this benefit may.

Correct. But can you practically alocate a PI to each end user? These 
are two visions of the same internet?
jfc

---

From: Tomas Podermanski <[email-masked]>
Date: Fri, 04 Mar 2011 08:10:26 +0100

> Since SHIM6 has neither of these costs, are you surprised
I completely agree with you. SHIM6 is definitely better solution than
MAP66. But the problem is that SHIM66 requires support for both server
and client side. Living in the real world we can not expect that SHIM66
will be widely supported in less than 5 or 10 years. SHIM66 is nice and
great solution but not for today.

MAP66 is a pragmatic solution that can work today (working
implementation of map66 exists - http://map66.sourceforge.net/). Beleive
me, there is really huge demand from enterprise to have solution like
MAP66. MAP66 is easy to understand, easy to implement, follows habits
that people are used to using in IPv4 world and can work immediately.

>From application perspective, address rewriting used by MAP66 is not a
new issue. The technique is used by enterprise to mapping public
addresses to DMZ for many ears. Almost all application had to deal with
it somehow.

Tomas

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 04 Mar 2011 15:53:14 +0800

Hi Fred,

I haven't read this draft, in fact, I'm reading RFC3002.

In section 4.3.4, it reads,

   It was recommended that an effort be made to eliminate any
   requirement for NAT in an IPv6 Internet.  The IAB believes that the
   IPv6 address space is large enough to preclude any requirement for
   private address allocation [55] or address translation due to address
   space shortage [15].  Therefore, accomplishing this should primarily
   require installing and enforcing proper address allocation policy on
   registry and service providers.  It was recommended to establish
   policies requiring service providers to allocate a sufficient
   quantity of global addresses for a sites use.  The feeling was that
   NAT should be easily eliminated provided efficient strategies are
   defined to address renumbering [17,62] and mobility [37] issues.

My questions here are,

Is the requirement for NAT in IPv6 Internet avoidless?
Cann't we (service provider) find appropriate policy or strategies to
address this problem?
Or the Internet situation has changed?

Thanks!
Xiangsong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fred Baker
> Sent: Tuesday, March 01, 2011 6:39 AM
> To: NAT66 HappyFunBall
> Subject: [nat66] Fwd: New Version Notification - draft-mrw-nat66-08.txt
> 
> 
> 
> Begin forwarded message:
> 
> > From: [email-masked]
> > Date: February 28, 2011 2:30:03 PM PST
> > To: [email-masked], [email-masked],
> [email-masked], [email-masked]
> > Subject: New Version Notification - draft-mrw-nat66-08.txt
> >
> > New version (-08) has been submitted for draft-mrw-nat66-08.txt.
> > http://www.ietf.org/internet-drafts/draft-mrw-nat66-08.txt
> >
> >
> > Diff from previous version:
> > http://tools.ietf.org/rfcdiff?url2=draft-mrw-nat66-08
> >
> > IETF Secretariat.
> 
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

---

From: JFC Morfin <[email-masked]>
Date: Fri, 04 Mar 2011 10:55:31 +0100

Dear Xiangsong Cui,

The change in terminology from NAT66 to NPTv6 is the correct 
acknowledgment of your remark. IDNA2008 served as a first example of 
the way the Internet technology is able to support a very large 
diversity in uncoupling the necessary stability, robustness, 
simplicity of the inside network itself and the diversity, versality 
and extremely large size of the outside usage. This uncoupling 
necessitates an Internet Use Interface (IUI) between the inside 
network and outside users. This is provided by IDNA2008 in naming, 
this is provided by NPTv6 in numbering. This calls for the IUI to be 
installed at the ISP or preferably on the userside.

Now, what is of interest and was discussed through my appeals to IESG 
and IAB and their response last year irt. naming [but actually 
uncoupling and the acknowledgment of the principle of subsidiarity in 
the Internet architecturer in addidition to adaptation ability 
(principle of permanent change, RFC 1958) and simplicity (RFC 3439)], 
is that the IUI is also seen from the user side. This IUI's target is 
to provude stability, mobility, specificity to the people centric 
digital ecosystem experience: this is not limited to interfacing the 
Internet and even to the  Internet technology. In that perspective it 
becomes an Intelligent User Interface, abiding by the fundamental 
Internet principle of a dump network and intelligent fringes.

On the naming side, the equivalent to the NPT is the ML-DNS I work 
on, which is to accept any language orthotypography on an exqual 
footing and any naming or addressing plan (classes), while respecting 
and protecting IDNA2008 on the inside Internet side. In the NPTv6 
case the user's IDv6 (i.e. the IID) is protected and can be used as 
encapsualted in any kind of header, starting with the IPv6 prefix, 
but also a domain name, or another technology address system, or even 
a different Internet addressing plans.

This means that for the emerging IUse community (Intelligent use of 
the world digital ecosystem) IDv6 can be used right now by its own 
right, even under IPv4 and provide by its IUse documentation a strong 
incentive to switch to IPv6. Another interesting advantage for 
small/medium users is that the IPSec support can be used at smart 
plugs at the fringes of personal domain zones throughout the network.

Best
jfc

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 04 Mar 2011 22:17:50 +0800

Dear JFC,

Many thanks for your detailed explanation!

But I still don't understand that, in my understanding, network prefix is a part of IPv6 network address, so the network prefix translation is actually a "partial" network address translation, right?

Best Regards
Xiangsong

----- 原邮件 -----
发件人: JFC Morfin <[email-masked]>
日期: 星期五, 三月 4日, 2011 下午6:12
主题: Re: [nat66] Fwd: New Version Notification -  draft-mrw-nat66-08.txt
收件人: Xiangsong Cui <[email-masked]>, 'Fred Baker' <[email-masked]>, 'NAT66 HappyFunBall' <[email-masked]>

> >    private address allocation [55] or address translation due to 
> address>    space shortage [15].  Therefore, accomplishing this 
> should primarily

---

From: "S.P.Zeidler" <[email-masked]>
Date: Fri, 4 Mar 2011 15:47:18 +0100

> Since SHIM6 has neither of these costs, are you surprised

The context of my remark (and what I was trying very hard to get across)
was "the wording you use is misleading or confusing".

"the benefits of XXX" is not the same as "the entire set of features
including cost of XXX" with XXX equal just about anything, by no means
limited to NPTv6, or politics, or the weather, or the Easter Bunny.

I would say that your preferences regarding the contents described are
not relevant to the question whether the description as such is parseable
correctly or not.

(Aaaargh!)

regards,
	spz

---

From: Fred Baker <[email-masked]>
Date: Fri, 4 Mar 2011 09:13:51 -0800

> Is the requirement for NAT in IPv6 Internet avoidless?

Well, if you do read the spec, you'll find that the issue it addresses is address independence for the edge network. There are three ways an edge network can get its addresses: it can get a private address of some form and have that translated upstream (some variation on translation), it can get its address from the upstream (PA addressing, the premise behind shim6), or it can get a global address independent of its upstream (PI).

> Cann't we (service provider) find appropriate policy or strategies to address this problem?

Well, I will argue that we indeed have. We have all three of those options on the table, plus what I call "exchange-based multihoming" and Steve Deering in Stockholm 1995 called "Metropolitan Addressing".

You might take a look at 

http://www.ietf.org/rfc/rfc3582.txt
3582 Goals for IPv6 Site-Multihoming Architectures. J. Abley, B.
     Black, V. Gill. August 2003. (Format: TXT=17045 bytes) (Status:
     INFORMATIONAL)

At IETF-67, in 2006, Vince Fuller and I spoke to v6ops about multihoming, looking at the requirements for multihoming. Vince, who has  background with BARRNET, spoke from an operational perspective and used the slides at http://www.ietf.org/proceedings/67/slides/v6ops-13.pdf. His point could be summarized as "GSE: Just do it, let the applications figure out what they're going to do as a result".

I started from RFC 3582, and looked at the implications of the various choices. RFC 3582 could be described as "we have PI addressing and we really like the features it gives us, but it has a scaling issue; whatever you do, make sure it works as well as PI addressing". I have had some disputes on some of the evaluations I made re shim6; the folks who like it don't like what I said, and I did make an error on session cutover. But you might want to look at: http://www.ietf.org/proceedings/67/slides/v6ops-4/sld1.htm

Having looked at that, look also at http://www.ietf.org/proceedings/73/slides/behave-14.pdf, which is Margaret and my slides from IETF 73 Behave; you may also want to review the minutes of that meeting, and perhaps the other internet draft I posted for context - http://tools.ietf.org/id/draft-baker-v6ops-b2b-private-routing. It repeats some of the same material from IETF 67, but drops exchange-based multihoming and goes into GSE.

Let me walk through the possible solutions and the pain points.

The one we probably know best is provider-independent addressing, because we talk about it. If I'm a company like Cisco, which has offices around the world, a dozen or more access portals where we communicate with twice that many ISPs as "our service provider", and 100,000 employees, it's pretty easy to describe ourselves as having an "internal ISP" (our IT department), and are a network comparable to a large ISP in our own right. We need our own prefix from a routing perspective and an address management perspective. Globally, that gives us good routing, relatively simple network management, yadda yadda yadda. How does that relate to Jari Arkko's home, which is multihomed (two ISPs)? If we're talking about multihoming for the typical Internet edge network, which is probably a company of 50 people, we're talking about enumerating the edges of the network in our route table - order of 10^7 prefixes in the route table by 2025, per Marshal Eubanks' study for NANOG. That translates to memory, power, cooling, issues around rerouting on failure or recovery, and so on. By the way, it's what everyone says they want.

A variation on PI addressing is what Randy described on v6ops a few days ago: he has several ISPs, derives his prefix from one, and advertises that address space into his other ISPs. From one perspective, that is in fact PA addressing - the prefix was allocated by one of his upstreams. However, to his other ISPs, it is identical to PI - it's not their prefix, they have no way to aggregate it, and if they want to provide him with full service they have to also advertise that to their peers and upstreams. And to top it off, his primary ISP has to advertise the prefix upstream itself, defensively, as otherwise all traffic will go through their competitors. I call that "PA like PI", and treat it as a variation on PI. The outcome is essentially the same - we enumerate the edge, with direct impacts on hardware costs, operational costs, and so on.

The other one we know well involves some variation on network address translation. To the transit backbone, we no longer have to enumerate the edges; we are enumerating the points of attachment, dramatically reducing the route table to the size we see today in the IPv4 network and nominally to a prefix for each ISP in the world - on the order of 5,000-10,000 routes. From the user's perspective, as with PI addressing, he doesn't have to think very hard about his upstream's addressing. The issues are in the application: this is Keith's cue to comment. With the kind of thing we have done in IPv4/IPv4 NAT, the vast majority of the edge network is simply incapable of offering services to anyone outside it. With NPTv6, which is prefix translation and is transparent between the inside and outside network apart from the fact of having different addresses inside and outside, systems "inside" can offer services to systems "outside", but it takes some changes in thinking. 

One that we think we know well but IMHO haven't thought through from the Enterprise perspective adequately is shim6. The premise is that the ISP allocates a prefix to each of its customers, and the customers distribute a /64 to each of its LANs from each of those prefixes. Effect on applications - they see end to end addressing, and just work, and the proposed host changes, if anyone actually implemented them (nobody has to my knowledge), means that you can change the address of a session without thinking too hard. Effect on the transit backbone - wonderful. Effect on the enterprise network administrator - good grief. shim6 is DOA because they simply aren't willing to do it.

One that we don't talk about is Steve's Metropolitan Addressing, what I call exchange-based addressing. The premise here is that instead of putting a prefix on an ISP, put a prefix on an address exchange. The reason I don't like the word "Metropolitan" is that it makes it sound geographic or associated with a governmental unit; I'll argue that it is best associated with an Internet Exchange, whoever you choose to run that exchange. Net effect for the access service provider is a larger route table, as he now as a prefix for a /56 or /60 for each customer; in the larger network, it behaves a lot like PA, which is to say order of 10^4 routes. For the customer, the prefix is fungible - it moves between service providers and directly supports multihoming. The biggest impact I hear from service providers is that it inverts their transit contracts - in effect, instead of the receiver's address determining its routing (it goes to his ISP, which may be very large), the sender's does (it uses *his* ISP to get to the city-or-whatever, and then hops to the receiver's ISP).  Say that, and ISPs tend to get real uninterested.

I'm not in favor of 10^7 routes in the backbone. I am in favor of end to end transparency at the application layer. I'm in favor of any solution that minimizes capital and operational complexity and expense. No solution on the table is pain-free; to my mind, prefix translation is the least pain, cost, and complexity among the available options.

If you have another option, I'm listening.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 4 Mar 2011 17:58:19 +0000

There is actually much to be said for the idea of "let the applications figure out what they're going to do as a result." Something like the end-to-end argument. We don't want to force the network to do heroic feats if the problem could be solved simply in an end-to-end manner. It seems that "PI everywhere" belongs in the "heroic feats" category.

There is indeed evidence that the problem can be solved end-to-end. This is why we developed STUN, TURN, ICE. These solutions are not perfect, and they don't cover TCP very well. (I know TURN does cover TCP, but at the cost of a TCP relay, i.e., not very well.) If the end to end groups knew for sure that "this is the deal," applications and transport protocols would surely evolve.

There are however two big limitations to solutions like STUN, TURN or ICE. First, it is entirely possible to engineer a middle-box that breaks them, by making the mappings hard to discover. Second, if the mappings are volatile and short lived, the end to end systems are forced into a pattern of frequent polling which drains the batteries of mobile devices. If the NPT spec addresses these limitations, we may well have  a deal. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Friday, March 04, 2011 9:14 AM
To: Xiangsong Cui
Cc: 'NAT66 HappyFunBall'
Subject: Re: [nat66] Fwd: New Version Notification - draft-mrw-nat66-08.txt

You might take a look at 

The one we probably know best is provider-independent addressing, because we talk about it. If I'm a company like Cisco, which has offices around the world, a dozen or more access portals where we communicate with twice that many ISPs as "our service provider", and 100,000 employees, it's pretty easy to describe ourselves as having an "internal ISP" (our IT department), and are a network comparable to a large ISP in our own right. We need our own prefix from a routing perspective and an address management perspective. Globally, that gives us good routing, relatively simple network management, yadda yadda yadda. How does that relate to Jari Arkko's home, which is multihomed (two ISPs)? If we're talking about multihoming for the typical Internet edge network, which is probably a company of 50 people, we're talking about enumerating the edges of the network in our route table - order of 10^7 prefixes in the route table by 2025, per Marshal Eubanks' study for NANOG. That translat  es to memory, power, cooling, issues around rerouting on failure or recovery, and so on. By the way, it's what everyone says they want.

---

From: Keith Moore <[email-masked]>
Date: Fri, 4 Mar 2011 13:21:54 -0500

> There is actually much to be said for the idea of "let the applications figure out what they're going to do as a result." Something like the end-to-end argument. We don't want to force the network…

I'm sort of all right with that idea, provided (a) you give the applications enough information so that they can figure it out without having to have their own dedicated infrastructure, and (b) the solution for the application isn't overly complex, and doesn't significantly impair performance or reliability.

nptv6 by itself, as currently defined, falls a bit short of that.  At least one missing piece is the lack of a built-in mechanism to allow an application on the "inside" of the NPTv6 to discover its "outside" address.

Though I agree with Fred about many of the cost-benefit tradeoffs (and will reply to his recent message in more detail when I have a bit of time).  

> There is indeed evidence that the problem can be solved end-to-end. This is why we developed STUN, TURN, ICE. These solutions are not perfect, and they don't cover TCP very well. (I know TURN does…

STUN, TURN, ICE are not e2e solutions.  They require support from the "middle".   Any solution that requires a 3rd party server to sit in public address space and mediate between the endpoints (even if just to establish a connection) imposes a high barrier to deployment of new applications.

> There are however two big limitations to solutions like STUN, TURN or ICE. First, it is entirely possible to engineer a middle-box that breaks them, by making the mappings hard to discover.

From my perspective, breaking things is exactly what the vast majority of middle boxes do.  Frankly, I don't know how to engineer any protocol that a middle box can't break.  The only question is how obvious they make the breakage.  Usually what middle boxes do is break things without being obvious that they're at fault.  That's why they're such a big problem.

> Second, if the mappings are volatile and short lived, the end to end systems are forced into a pattern of frequent polling which drains the batteries of mobile devices.

This is definitely a limitation.

Keith

---

From: Fred Baker <[email-masked]>
Date: Fri, 4 Mar 2011 10:28:44 -0800

> There are however two big limitations to solutions like STUN, TURN or ICE. First, it is entirely possible to engineer a middle-box that breaks them, by making the mappings hard to discover. Second,…

NPTv6 provides a stable mapping as long as the internal address remains constant - it has an internal prefix and an external prefix, and does a reproducible mapping between the two. There is a question with privacy addressing - if the host interface changes its address, and especially if it changes it frequently, the peer will need to keep track of that, and there is a question of how DNS knows what the current address is. But the network isn't changing the address, the host is.

---

From: Keith Moore <[email-masked]>
Date: Fri, 4 Mar 2011 13:39:15 -0500

> NPTv6 provides a stable mapping as long as the internal address remains constant - it has an internal prefix and an external prefix, and does a reproducible mapping between the two. There is a ques…

I've always assumed that privacy addresses were meant to be ephemeral.   Otherwise, there's no point to them.

Keith

---

From: james woodyatt <[email-masked]>
Date: Fri, 04 Mar 2011 11:00:05 -0800

On Mar 4, 2011, at 9:13 AM, Fred Baker wrote:
> 
> [...] From the user's perspective, as with PI addressing, he doesn't have to think very hard about his upstream's addressing. The issues are in the application: this is Keith's cue to comment.

"This is a cue for comment from not just Keith Moore, but everyone in the application engineering community whose oxen will be gored by operators treating them as an externality."

Fixed that for you.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Fred Baker <[email-masked]>
Date: Fri, 4 Mar 2011 11:23:12 -0800

> nptv6 by itself, as currently defined, falls a bit short of that.  At least one missing piece is the lack of a built-in mechanism to allow an application on the "inside" of the NPTv6 to discover it…

There I agree and disagree. I agree that NPTv6 does not itself provide that information; I think it is out of scope for the draft. There are a couple of ways that the function could be created, and you have dismissed each of my suggestions. So from my perspective, the ball is in your court to suggest a solution that is acceptable for applications and works in the context.

> STUN, TURN, ICE are not e2e solutions.  They require support from the "middle".   Any solution that requires a 3rd party server to sit in public address space and mediate between the endpoints (eve…

Maybe we're not solving the same problem. Help me out here.

When you talk about an "end to end solution", the picture that comes to my mind is that a peer in a random other part of the network tells me what my address is. The question that immediately comes to my mind is "how did I find his address?" Chicken, meet egg. He needs a solution that will enable me to find him without my first knowing his address. If that's not what you mean, I need to understand what you mean.

I know you don't like DNS. I don't either; I think we need a directory-based solution. Until you or someone else proposes a DNS replacement, DNS is what we have. So for name translation to addresses, I think in terms of DNS.

NPTv6 presumes that the DNS somehow knows what prefixes are in use in a domain. That might be human: when the network administrator adds an AAAA record to DNS, he includes such a record for each of the addresses that the interface might have. That's equally true for shim6 and other solutions; if I have N addresses, I need N AAAA records associated with my name, one for each prefix. There are several possible ways to do this, but I would expect that the simplest and most reliable mechanism is a tool; the administrator supplies the name, one of the addresses, and whatever other information is required, the DNS management tool looks up the various prefixes, and creates AAAA records for each address. In a static world (IPv6 address derives from MAC address or is manually assigned), job done.

Now, not all systems need names. This is a digression, but an important one given the opening sentence of the next paragraph. On Cisco's network, my laptop has a name right now that is associated with its address - stealth-10-32-244-219.cisco.com. The derivation is obvious - they gave me a /29 for my office and statically built a name for the purposes of reverse DNS. Reverse DNS in an IPv6 world that contains laptops is an "interesting" proposition; I would suggest that the DNS server ping the host in question and respond in one of two ways depending on the reply; it can reply "no such address" if there is no reply, or respond with a name if there is. If it has a name in its database (www.example.com), it should reply with that; if not, it should generate some temporary name and respond with it. Not that anyone would ever use that name to access my laptop (if they're going to, they need a more permanent name), but it serves reverse DNS's purposes.

If you are using privacy addressing or moving a laptop around, AND the interface in question has a permanent name (not a bad idea for ddos protection, for example), I think the solution is Dynamic DNS. A host announces to DNS that it now has a new address to associate with its name (and says a DNS lifetime later that DNS should forget its old address), DNS applies the same transform to the record it was given, and now knows all of the relevant addresses.

If an application on one host wants to refer to an application on a different host, it could include the DNS name of the other system in its referral record; I'm told that CERNET did a detailed study to see how many referrals did that, and found that the number that didn't was a vanishingly small percentage. If they really want to include an address, the referring host can look up the DNS record itself and as a result know the addresses. There is a question of the lifetime, but it's not impossible to deal with. Similarly if a host needs to know all of its own addresses; if DNS knows them, it can ask DNS a few milliseconds after it has sent the DDNS update.

If a host needs to know all of its external addresses and doesn't want to use DNS, or would like to know among the possible options which addresses to recommend, I would suggest something akin to STUN but a little different. Have the NPTv6 translators join a site-local multicast group "All NPTv6 Translators", and enable the translator to reply to an appropriate ICMP message "what's my address" with a list of zero or more translated addresses - if one system embodies translation into two ISPs, it would respond with one ICMP that contains two external addresses, for example. If a system is trying to make a recommendation, it might send the request and collect the first N responses or the responses that arrive within a stated interval, and inform Dynamic DNS of those addresses.

As to how DNS knows what addresses to give in a response, I can think of three algorithms quickly:
    - There is one DNS database containing both internal and external
      addresses. When asked about a name, it gives all the addresses
      it has; the application decides which of them it will use.
    - There are two DNS databases, one containing both internal
      addresses and one containing external addresses. DHCP tells
      local systems to access the internal server; all others ask
      the external server. The servers, however, are identical to
      the first case; when asked a question, they give the answer
      they know.
    - Whether there are one or two databases is irrelevant; the DNS
      server looks at the source address on a DNS request and either
      by filtering records or by inspecting the right database
      replies to any request that comes to it in a manner
      indistinguishable from the second case.

The first two are well-known and widely-deployed - simple DNS, and a split DNS. I have no idea whether the third exists or whether there is a market for it. Bottom line, I don't see a problem between internal and external addresses that we don't already know how to solve. We may not like the solution, but that doesn't mean a solution doesn't exist.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 05 Mar 2011 08:27:19 +1300

Tomas,

Thanks. Does this exactly implement draft-mrw-nat66-09.txt?

It would be better to refer to NPTv6 not NAT66, I think.

Regards
   Brian Carpenter

---

From: Fred Baker <[email-masked]>
Date: Fri, 4 Mar 2011 11:32:17 -0800

:-)

Is I tried to point out in my longer email, the question isn't whether an ox gets gored. It's "whose ox", and "at what cost".

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 05 Mar 2011 08:35:45 +1300

Isn't this discussion getting out of scope here and into scope
for draft-carpenter-referral-ps?

The [email-masked] list is alive and well for discussion of
the referral problem, which is common to many scenarios, not just NPTv6.

Regards
   Brian

---

From: Fred Baker <[email-masked]>
Date: Fri, 4 Mar 2011 11:37:36 -0800

> I've always assumed that privacy addresses were meant to be ephemeral.   Otherwise, there's no point to them.

Ephemeral, yes. On what timeframe - Christian, my understanding is that Windows changes them daily. Correct?

There are a couple of other timing alternatives. One is to create a new address for every TCP session. If you think that's a good idea - and it does have its merits - I'll encourage you to think through the implications of Duplicate Address Detection. I think you'll find hosts need to have a pool of vetted addresses in their pockets in order to do things like web access.

A better alternative might be to change the address once a minute or once an hour. The value of doing so would be to side-step an attack without betraying to the attacker that you know you're under attack.

Another alternative would be to change addresses at some nominal rate (such as daily) but feel free to change addresses if you perceive yourself to be under attack.

---

From: Fred Baker <[email-masked]>
Date: Fri, 4 Mar 2011 11:46:58 -0800

> the referral problem, which is common to many scenarios, not just NPTv6.

I have no problem with moving the discussion there. Understand, however, that this is not limited to referrals, and is Keith's primary concern with NPTv6. It's relevant here because for Keith it is a requirement on NPTv6.

---

From: Fred Baker <[email-masked]>
Date: Fri, 4 Mar 2011 11:59:11 -0800

> When you talk about an "end to end solution", the picture that comes to my mind is that a peer in a random other part of the network tells me what my address is. The question that immediately comes…

The other way I can understand "end to end solution" is "a solution that presents the same address to both/all peers of a session". If that's what you mean, then you have discounted all options that include translation. If the topic under discussion is a translation solution, what you would therefore be saying is "I don't want to play". That's your option, but you just removed yourself from the conversation.

---

From: JFC Morfin <[email-masked]>
Date: Fri, 04 Mar 2011 21:00:14 +0100

At 15:17 04/03/2011, Xiangsong Cui wrote:
>But I still don't understand that, in my understanding, network 
>prefix is a part of IPv6 network address, so the network prefix 
>translation is actually a "partial" network address translation, right?

Dear Xiangsong,

on the IETF side, i.e. managing the inside internet you are right 
(128 bits addresses). On the user side things are flexible. This only 
beg you to differentiate the IPv6 inside Internet protocol from the 
IPv6 network addressing scheme.

Actually an IPv6 address is made of two parts:

- an IPv6 network address (header) which is allocated by the ISP: 
this is the actual IPv6 address.
- a payload to deliver a user internal network address of any 
technology at that IP address. The IETF calls it IID. IUsers call it 
IDv6 to differentiate it from other IIDs from other technologies or 
protocol environment (starting with IPv4), adressing plans, existing 
ones or future ones to come.

NPTv6 inserts the correct IPv6 header ahead of IDv6 so the whole 
address can cross the Internet in using the IPv6 protocol and reach 
the other end. There, the IPv6 header (address) may be removed if the 
local network is only using its IDv6. This for exemple permits a user 
system to be connected to the internet through different ISPs or 
different channels: same IDv6, different IPv6.

Having kept the IPv6 as a single 128 bits address is the reason why 
IPv6 did not take off until now. There is no particular interest to 
the IUser to invest in a rigid application to application IPv6 dump 
proposition. On the countrary, there is a big  IUser interest in 
IDv6, that can be also used easily under IPv4 (for example in using 
IDv6s under alphadigital DN label form) and other technologies and 
"externets" (what the DNS identfies as a class and the addressing was 
unable to support).

However, please keep in mind that this "big" interest is still 
numerically reduced in people because the IUse community is only 
emerging. Also the IUI has been identified as not being part as such 
of the IETF scope (IAB/IESG), so we have everything to build to 
support a new network stratum including the presentation layer but 
also other new layers (extended network model) able to dialog with 
other technologies. IESG qualified this as "research", this is true 
but an IUI architecture like InterPlus (Pluggable layers on the User 
side) may qualify as an "emergency" solution for some existing global needs.

jfc

>Best Regards
>Xiangsong
>
>
>----- Ô­ÓÊ¼þ -----
>·¢¼þÈË: JFC Morfin <[email-masked]>
>ÈÕÆÚ: ÐÇÆÚÎå, ÈýÔÂ 4ÈÕ, 2011 ÏÂÎç6:12
>Ö÷Ìâ: Re: [nat66] Fwd: New Version Notification -  draft-mrw-nat66-08.txt
>ÊÕ¼þÈË: Xiangsong Cui <[email-masked]>, 'Fred Baker' 
><[email-masked]>, 'NAT66 HappyFunBall' <[email-masked]>
>
> > Dear Xiangsong Cui,
> >

---

From: Keith Moore <[email-masked]>
Date: Fri, 4 Mar 2011 16:00:26 -0500

> There I agree and disagree. I agree that NPTv6 does not itself provide that information; I think it is out of scope for the draft. There are a couple of ways that the function could be created, and…

I agree, in a sense, that it's out of scope for the NPTv6 specification - because such a mechanism needs to be applicable to all NATs (not just NPTv6) that find their way in between any application using IPv6 and its peer.

However, it's not out of scope for the box that implements NPTv6.  IMO it's an absolute requirement for such a box.

A detailed proposal will take time, not only to write the proposal but also to compare with other, similar ongoing work (such as PCP).  

> When you talk about an "end to end solution", the picture that comes to my mind is that a peer in a random other part of the network tells me what my address is. The question that immediately comes…

The general case is that A wishes to inform B, that B can reach some potential peer C using some address or set of addresses.  They wish to do so without external assistance - without needing to involve a 4th party that is known to be in a non-NATted realm.  Assume that A and B already know how to talk to each other, and A knows a way to talk to C.

Note that each of A, B, and C can potentially be in its own realm distinct from the others.   So there are at least 5 different cases against which any potential solution must be analyzed:  
A, B, and C are all in the same realm
A is in one realm; B and C are both in a different realm
B is in one realm; A and C are both in a different realm
C is in one realm; A and B are both in a different realm
each of A, B, and C is in its own realm
(Actually it can get a bit more complicated than that as one realm can encompass another.  But this only matters if the proposed solution depends on realms either being the same or disjoint.)

The simple solution looks like this:

each of A, B, and C has a public, globally scoped address
they always include those addresses in referrals (perhaps in addition to ULIAs)
when trying to reach a peer, applications always try using the public, globally scoped address of a peer (perhaps while also trying to use a "better" address for some meaning of "better")

This implies that applications have to have a way to find out their external addresses.   That doesn't seem like it should be such a big deal, but it often is.

(The above statement are also true if you substitute "DNS name(s)" for "address(es)".   I don't actually think of one of these solutions as being right and the other wrong - I think that the choice of whether to use addresses vs. DNS names in referrals is essentially a question of whether you prefer to use a token that's fast but perhaps has an ephemeral binding to the destination, vs. a token that's slower and more prone to misconfiguration but perhaps less ephemeral.  And of course you can always try both, perhaps concurrently.)

> I know you don't like DNS. I don't either; I think we need a directory-based solution. Until you or someone else proposes a DNS replacement, DNS is what we have. So for name translation to addresse…

Saying "you don't like DNS" makes it sound like my personal preference.   I'd be happy to use it if it worked well.   The truth is that (even without having to deal with multiple realms) DNS doesn't work well enough in practice for applications to rely on it.  It works if you're trying to look up the address of a public server, because those servers are relatively few in number, they often support essential services like email and/or web presence, and network administrators tend to find out fairly quickly if the DNS isn't set up well enough to suit that small number of essential applications.  (Though it's amazing how often enterprise network administrators can be blissfully unaware that they don't have their MX records set up correctly.... because nobody outside their enterprise can send them mail to tell them.)  But DNS doesn't work well enough to allow arbitrary hosts to communicate with one another, even if they have permission to do so.

Even if DNS were perfectly maintained, always in sync with reality, servers always up and reachable, etc., DNS would not solve the referral problem.  It would just move it, and add complexity.   Just like application instances don't have a reliable way of knowing what IP address(es) can be used to reach them from anywhere, they don't have a reliable way of knowing what DNS name can be used to reach them either.  PTR lookup does not work, not only because the host might be behind some sort of NAT (and using address space for which ip6.arpa and/or in-addr.arpa are not populated), but more importantly, because it's very frequently the case that a host moves from one ISP to another and doesn't have a stable DNS name.)

> NPTv6 presumes that the DNS somehow knows what prefixes are in use in a domain. That might be human: when the network administrator adds an AAAA record to DNS, he includes such a record for each of the addresses that the interface might have. That's equally true for shim6 and other solutions; if I have N addresses, I need N AAAA records associated with my name, one for each prefix.

That's ok, I'm not a big fan of shim6 either :)

> There are several possible ways to do this, but I would expect that the simplest and most reliable mechanism is a tool; the administrator supplies the name, one of the addresses, and whatever other information is required, the DNS management tool looks up the various prefixes, and creates AAAA records for each address. In a static world (IPv6 address derives from MAC address or is manually assigned), job done.

Yes, that's what I anticipated when I argued, back in the late 1990s, to get rid of A6 records and associated cruft.  Let the DNS server essentially implement prefix macros that can expand to multiple AAAA and/or PTR records, just don't make those macros explicit DNS records.  (This does, however, beg the question of how a host should use Dynamic DNS to update its own RRs if it doesn't know all of its own addresses.)

> Now, not all systems need names. This is a digression, but an important one given the opening sentence of the next paragraph. On Cisco's network, my laptop has a name right now that is associated w…

It's true that not all systems need to be reachable by other hosts, but the vast majority do under at least some circumstances.   If you want to insist that "reaching" a system should always start with a DNS lookup, this implies that (nearly) all systems do need DNS names.  Of course it's quite often the case that they don't have them, and if they do, the names are often meaningless and not actually bound to the host at all, but only to an IP address.  That's a big part of the problem with relying on DNS names for referrals.

(DNS results should NEVER depend on whether a host is reachable by ping from the DNS server, and a DNS server should NEVER respond with NXDOMAIN when the domain normally exists but there don't happen to be any valid records matching QTYPE.  The proper response in the latter case is to return no error, with zero records.)

> If you are using privacy addressing or moving a laptop around, AND the interface in question has a permanent name (not a bad idea for ddos protection, for example), I think the solution is Dynamic…

Not only do I use Dynamic DNS myself, I actually implemented my own client for it.  When I did, I noticed that my ISP at the time had imposed a DNS interception proxy that kept the update records from getting to the server specified in the IP destination address header.  The interception proxy would reply but the request never got to the authoritative server for the zone.   Eventually I reconfigured the DNS server and the client to use a different port.  That worked fine for me but I'm not sure how well that will work in general.    

Before I wrote my own Dynamic DNS client, I looked around at existing DNS update service providers and didn't find a single one that used the Dynamic DNS protocol.  They all used HTTP, and from what I recall, they were mostly pretty lame.  E.g. they had a way to update your A record but not other records - maybe not even AAAA.

Another problem is that a lot of people think that it's the job of the DHCP server to update the DNS, so you get situations where the DHCP server and the host argue about what the host's resource records should be. 

So yeah, Dynamic DNS nice if/when you finally get it working.   But I think there might be some significant barriers to widespread adoption of Dynamic DNS for this purpose. 

Also I'll note that Dynamic DNS rarely helps you get the "reverse DNS" lookup right.   In the very common case where you get your address from your ISP, you generally don't get the ability to update the PTR records associated with that address.  So whatever name results from a PTR lookup won't help a peer get back to your host in the future after your laptop has moved and/or your ISP has assigned a different address.  I don't see that as a huge loss, but it does mean that doing a PTR lookup on your own IP address doesn't reliably give you a DNS name that's useful in referrals.

> If an application on one host wants to refer to an application on a different host, it could include the DNS name of the other system in its referral record; I'm told that CERNET did a detailed study to see how many referrals did that, and found that the number that didn't was a vanishingly small percentage.

I can believe that most referrals include some DNS name, because applications doing referrals have a strong incentive to provide every name or address that might conceivably work.  A more relevant question is how many of those DNS names would actually work if/when used.  Of course the particulars matter - what applications they were looking at, and what environments they were looking in.

> If they really want to include an address, the referring host can look up the DNS record itself and as a result know the addresses.

No it can't.  Because the host doesn't reliably know its own name.  Or more precisely, the host doesn't know which name(s) in DNS can reliably be depended on to reflect its current addresses, and there's no reliable way of finding out.    Neither DHCP nor PPP nor host APIs (e.g. gethostname()) can be trusted to return suitable DNS names. 

Ideally, a host's DNS name(s) should be properties of the host to which they're assigned, and the host should know its own name(s) except for those cases where the hosts really are intended to be anonymous.    But in many cases cases, hosts are given names which have only a vague relationship with their DNS names, or which aren't reflected in DNS at all.  

> There is a question of the lifetime, but it's not impossible to deal with. Similarly if a host needs to know all of its own addresses; if DNS knows them, it can ask DNS a few milliseconds after it has sent the DDNS update.

see above.

> If a host needs to know all of its external addresses and doesn't want to use DNS, or would like to know among the possible options which addresses to recommend, I would suggest something akin to S…

Something like that is worth investigating.    One potential problem is that "site" boundaries can be fuzzy.  But in general, I think that such a facility is needed, and this seems like something that would be a good fit for ICMPv6/ND/RD.

> The first two are well-known and widely-deployed - simple DNS, and a split DNS. I have no idea whether the third exists or whether there is a market for it. Bottom line, I don't see a problem betwe…

I've always been dubious of split DNS.  DNS wasn't designed to be used in that way, and there's nothing about the DNS protocol or DNS implementations that constrains DNS queries to be made from the same locations that are using the results of those queries - quite the contrary, actually.  I realize that split DNS works fine for many enterprise networks that impose a lot of control over their hosts and the applications that they happen to run, but that doesn't mean that it works well in general.  IMO, DNS servers should always return the same response to any particular query, regardless of where the query is coming from.

More generally, I don't think that it's DNS's job to try to second guess what the host or application needs.   Something like happy eyeballs is better suited for letting applications figure out which addresses to use.  )Though there are plenty of problems with that too if the number of addresses associated with a host gets very large, and there are several reasons why this might happen.)

Still, I won't pretend that we can eradicate Split DNS.  I just don't think that the network architecture should depend on it.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 4 Mar 2011 16:09:20 -0500

> Another alternative would be to change addresses at some nominal rate (such as daily) but feel free to change addresses if you perceive yourself to be under attack.

I agree that hosts that use privacy addresses need to keep a pool of vetted addresses.

I think that a privacy address should last at least as long as any TCP session that uses it, though they need to be deprecated after awhile so that new sessions don't use them.

I like the idea of deprecating privacy addresses at regular intervals.  Having a mechanism to deprecate them more frequently if under attack might also be useful.  The question that comes to my mind is "how to securely signal hosts that they're under such attack, and need to do this?"

Keith

---

From: Fred Baker <[email-masked]>
Date: Fri, 4 Mar 2011 13:24:35 -0800

I'm not going to try, at least in this email, to address each of your points. Here are a few comments, however.

On Mar 4, 2011, at 1:00 PM, Keith Moore wrote:
> Saying "you don't like DNS" makes it sound like my personal preference.

That wasn't my intention. My intention was to say that it's what we have on the table. Another solution would be equally acceptable to me.

> It's true that not all systems need to be reachable by other hosts, but the vast majority do under at least some circumstances.

let me try again to tease apart the bits I was trying to tease apart.

Consider my laptop or my telephone. Unless I happen to have Skype running, it is purely a client; I could offer services (a peer-to-peer service is a service; it's just that client and server are interchangeable and may be doing both jobs simultaneously on different sessions), but I don't. From that perspective, the only reason my laptop needs a name is because other applications use reverse DNS to determine what that name is.

That doesn't mean that it doesn't need reachability. If I send a SYN from my laptop, I jolly well expect a SYN-ACK. Said message isn't coming if there is no reachability.

> If you want to insist that "reaching" a system should always start with a DNS lookup, this implies that (nearly) all systems do need DNS names.

Actually, no. But any system I want to send a SYN to does, because otherwise I need some other way of determining its address. When we go that route - well, please read RFC 4192. That's what makes renumbering hard.

> (DNS results should NEVER depend on whether a host is reachable by ping from the DNS server, and a DNS server should NEVER respond with NXDOMAIN when the domain normally exists but there don't happ…

I'm not a DNS guru :-)

> Still, I won't pretend that we can eradicate Split DNS.  I just don't think that the network architecture should depend on it.

The fact that I gave you three options, one or maybe two of which were split DNS but one was DNS as it stands along with draft-wing-v6ops-happy-eyeballs-ipv6 (which we need anyway) should tell you that the solution is not dependent on split DNS.

---

From: Fred Baker <[email-masked]>
Date: Fri, 4 Mar 2011 13:28:44 -0800

On Mar 4, 2011, at 1:09 PM, Keith Moore wrote:

> The question that comes to my mind is "how to securely signal hosts that they're under such attack, and need to do this?"

I'm sure there's a venue for that question...

But I think I might be inclined to have the OS detect the fact itself, at least in some percentage of the cases. If I am receiving a large number of messages to which I am replying with an ICMP "huh?", or that I have a large number of TCP sessions that are attempting to communicate using but am in retransmission timeouts or dropping the sessions entirely are examples of "it's not supposed to work that way" that might lead me to the conclusion that I am under attack.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 4 Mar 2011 21:29:28 +0000

> Ephemeral, yes. On what timeframe - Christian, my understanding is that Windows changes them daily. Correct?

By default, privacy addresses generated in Windows 7 (and Vista) are valid for 7 days and "preferred" for 1 day, i.e. a new privacy address is generated every day, but ongoing connections can keep using it for a week. System administrators can change these parameters, and can also decide whether privacy addresses are generated or not.

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Fri, 4 Mar 2011 18:44:19 -0500

> That wasn't my intention. My intention was to say that it's what we have on the table. Another solution would be equally acceptable to me.

I don't think it's an either-or.  I want DNS to work well.  I also want IP addressing to work well.   But if we're going to have NATs in IPv6, it strikes me as much easier to do NAT right this time and provide support _in the NAT_ that applications need to deal with the loss of e2e address transparency, than to try to retrofit a vast DNS deployment and change an immense amount of DNS-related mindshare in order to get DNS to do what apps need.   But DNS needs to be cleaned up anyway.  It's just that it will take 20 years to do it, if we can do it.

> Consider my laptop or my telephone. Unless I happen to have Skype running, it is purely a client; I could offer services (a peer-to-peer service is a service; it's just that client and server are i…

As it happens, I regularly ssh into my laptop from elsewhere using IPv6.   Soon I expect to be doing it from my phone.   Especially given that the vast majority of Internet hosts will soon be mobile hosts of some kind or another, I don't see why such hosts should be limited to running apps that don't need to accept inbound traffic.  There are too many apps for which some form of asynchronous inbound notification is useful.  Polling a central server for such notifications is expensive, both in terms of power requirements for mobile hosts and the cost to run those central servers. 

> Actually, no. But any system I want to send a SYN to does, because otherwise I need some other way of determining its address. When we go that route - well, please read RFC 4192. That's what makes…

Doesn't follow.   There are lots of ways to determine a host's address other than a DNS lookup.  (though I certainly agree that renumbering is hard.) 

Keith

---

From: Fred Baker <[email-masked]>
Date: Fri, 4 Mar 2011 15:52:30 -0800

On Mar 4, 2011, at 3:44 PM, Keith Moore wrote:

> As it happens, I regularly ssh into my laptop from elsewhere using IPv6.   Soon I expect to be doing it from my phone.   Especially given that the vast majority of Internet hosts will soon be mobile hosts of some kind or another, I don't see why such hosts should be limited to running apps that don't need to accept inbound traffic. 

What in all this prevents them from doing so?

You appear to keep, in your thinking, equating NPTv6 with NAT44. They are actually different, and have different effects. There is no reason whatsoever that an IPv6 host behind an NPTv6 translator can't offer services. To offer a service, with or without NPTv6, it will have to keep DNS (and any other name service it is using) informed of its current address. In the case that NPTv6 is in use, that service will have to be a little smarter, interpolating from that what other addresses might be relevant.

---

From: Keith Moore <[email-masked]>
Date: Fri, 4 Mar 2011 20:15:57 -0500

> You appear to keep, in your thinking, equating NPTv6 with NAT44. They are actually different, and have different effects. There is no reason whatsoever that an IPv6 host behind an NPTv6 translator…

How is my laptop, when it does the DNS dynamic update, supposed to know that it has an external address, and what that address is, so it can include an AAAA record for it?

Keith

---

From: Fred Baker <[email-masked]>
Date: Fri, 4 Mar 2011 17:29:31 -0800

> How is my laptop, when it does the DNS dynamic update, supposed to know that it has an external address, and what that address is, so it can include an AAAA record for it?

I spent a lot of time on that in an earlier email, one you chose to not respond to. There are two ways: 

(a) it reports the address it knows, and the DNS server infers the other addresses, or
(b) it sends an ICMP request to a multicast address, collects zero or more responses, and reports what it collects.

I personally prefer (a); we don't have to change your laptop. That said, I could use (b) to optimize; if I accept the first response that comes within a second or (if it is non-null) the set of responses that come within 100 ms (picking numbers out of the air, if you don't like them pick other numbers), and I have a network like Cisco's in which DMZs might be several hundred milliseconds apart, then I only select addresses that I would actually like a peer to use.

---

From: Keith Moore <[email-masked]>
Date: Fri, 4 Mar 2011 20:42:16 -0500

On Mar 4, 2011, at 8:29 PM, Fred Baker wrote:

> I spent a lot of time on that in an earlier email, one you chose to not respond to.

Oh, sorry.  I did see that message.  But sometimes I spend hours composing message responses, so longer messages take longer to respond to.  And sometimes it's hard to know what context 

> There are two ways: 

I like (b).  It works with DNS update (assuming that can be made to work) but it's not limited to DNS - any application that does referrals can use it.   It can be implemented in the host, and separately, in the application - without their interfering with each other.  It makes it possible to ship apps that do the right thing in a variety of environments.  Let's design it in detail.

As for (a) I don't think that a DNS server should infer that just because an update request comes in from a different address than specified in the AAAA record, that it should add an additional AAAA record based on the source address of the request.  Partly because the server has no reason to believe that the host actually wants that address advertised, and partly because it appears that some CPEs intercept DNS queries and proxy DNS updates.  (The data sheet for the new DSL modem that my current ISP just sent me touts this feature without explaining it, which makes me think that it might be a common feature.)

Keith

---

From: JFC Morfin <[email-masked]>
Date: Mon, 07 Mar 2011 01:50:40 +0100

At 00:52 05/03/2011, Fred Baker wrote:
>You appear to keep, in your thinking, equating NPTv6 with NAT44. 
>They are actually different, and have different effects. There is no 
>reason whatsoever that an IPv6 host behind an NPTv6 translator can't 
>offer services. To offer a service, with or without NPTv6, it will 
>have to keep DNS (and any other name service it is using) informed 
>of its current address. In the case that NPTv6 is in use, that 
>service will have to be a little smarter, interpolating from that 
>what other addresses might be relevant.

Actually, from a IUse point of view the NPTv6 will only be an IPv6 
oriented MAP-NPT function (Multi-Adressing-Plan Network Prefix 
Translator). What is of interest to the user is IDv6 (or any large 
enough sub-addressing system) that can be prefixed (what ever the 
prefix) to be routed to the other end in order to be intelligibly 
used on the other fringe. There can be many additional fringe to 
fringe services and even IDv6 massaging. Depending on the GRIDv6 
(Global Region IDv6, i.e. belonging to standardized sub-addressing plans).

jfc

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 07 Mar 2011 10:48:59 +0800

Hi Fred,

Thank you very much for you kind clarification.

Sorry I haven't read through the materials you provided, I think I have
understand your use case and I do have some ideas in my head, hope to hear
your comments.

Your scenario seems you have your own private prefix (or the prefix assigned
by service provider A), and want to utilize this prefix to go through
another network (e.g., service provider B).

The first option in my head is tunnel.
I think we can get some experience for IPv6 transition. The IETF recommend
is, when the communicating nodes are in same address space (e.g., both in
IPv4) and communication goes through another address space (e.g., IPv6),
please go to tunnel; if the communicating nodes are in different address
space (e.g., one is IPv4 and the other is IPv6), please go to translation.
Is this right?
Well let's go BACK to your case, you are do communicating using your private
network prefix (I would like to take it as a manner of address space) and
the communicating traffic goes through the network with another network
prefix (i.e., the network with another address space), why not try tunnel?
The tunnel endpoints may lie on your CE routers. I assume you do have your
own CE routers, because you are doing "internal ISP".
Another reason I prefer tunnel is security, I guess your IT department also
has this requirement, and tunnel can protect your traffic well.

My second option is mobility-like solution.
I would like to re-mention section 4.3.4 of RFC3002. It says:
   "The feeling was that
   NAT should be easily eliminated provided efficient strategies are
   defined to address renumbering [17,62] and mobility [37] issues."
I think mobility-like solution is worth a try.
You may need deploy some special CE routers (I also take NAT66 routers as
special router). The special router can do some mobility management
function. Mobile IP specification [RFC3775] has already provided similar
mechanism. In this approach, the address with your private prefix may be
taken as home address and your CE router convert it to the address with
prefix of ISP (the cloud network you are going through). Your transmitting
CE router includes the home address (with your own network prefix) in the
packets as Home Address Option, and your receiving CE router can get back
the original address from the Home Address Option and forwards the packets
to the destination host as their original bits.
There are also some trouble in this approach, for example, on the
destination side, the routing address (i.e., the destination address)
issues. This approach can only address the difference prefix of sender side,
but not the receiver side. But, we can use route optimization (there are
many extensions in MEXT and NETEXT) between CE routers. I admit this is
perhaps not a very good solution, but I think we can find solution to
address the troubles.

What do you think about these ideas?

Best regards,
Xiangsong

> From: Fred Baker [mailto:[email-masked]]
> Sent: Saturday, March 05, 2011 1:14 AM
> To: Xiangsong Cui
> Cc: 'NAT66 HappyFunBall'
> Well, if you do read the spec, you'll find that the issue it addresses is
address
> independence for the edge network. There are three ways an edge network
> can get its addresses: it can get a private address of some form and have
that
> translated upstream (some variation on translation), it can get its
address from
> the upstream (PA addressing, the premise behind shim6), or it can get a
global
> address independent of its upstream (PI).
> 
address
> this problem?
> Well, I will argue that we indeed have. We have all three of those options
on
> the table, plus what I call "exchange-based multihoming" and Steve Deering
in
> Stockholm 1995 called "Metropolitan Addressing".
> 
> You might take a look at
> 
> At IETF-67, in 2006, Vince Fuller and I spoke to v6ops about multihoming,
> looking at the requirements for multihoming. Vince, who has  background
> with BARRNET, spoke from an operational perspective and used the slides at
> http://www.ietf.org/proceedings/67/slides/v6ops-13.pdf. His point could be
> summarized as "GSE: Just do it, let the applications figure out what
they're
> going to do as a result".
> 
> I started from RFC 3582, and looked at the implications of the various
choices.
> RFC 3582 could be described as "we have PI addressing and we really like
the
> features it gives us, but it has a scaling issue; whatever you do, make
sure it
> works as well as PI addressing". I have had some disputes on some of the
> evaluations I made re shim6; the folks who like it don't like what I said,
and I did
> make an error on session cutover. But you might want to look at:
> http://www.ietf.org/proceedings/67/slides/v6ops-4/sld1.htm
> 
> Having looked at that, look also at
> http://www.ietf.org/proceedings/73/slides/behave-14.pdf, which is Margaret
> and my slides from IETF 73 Behave; you may also want to review the minutes
of
> that meeting, and perhaps the other internet draft I posted for context -
> http://tools.ietf.org/id/draft-baker-v6ops-b2b-private-routing. It repeats
some
> of the same material from IETF 67, but drops exchange-based multihoming
and
> goes into GSE.
> The one we probably know best is provider-independent addressing, because
> we talk about it. If I'm a company like Cisco, which has offices around
the world,
> a dozen or more access portals where we communicate with twice that many
> ISPs as "our service provider", and 100,000 employees, it's pretty easy to
> describe ourselves as having an "internal ISP" (our IT department), and
are a
> network comparable to a large ISP in our own right. We need our own prefix
> from a routing perspective and an address management perspective.
Globally,
> that gives us good routing, relatively simple network management, yadda
> yadda yadda. How does that relate to Jari Arkko's home, which is
multihomed
> (two ISPs)? If we're talking about multihoming for the typical Internet
edge
> network, which is probably a company of 50 people, we're talking about
> enumerating the edges of the network in our route table - order of 10^7
> prefixes in the route table by 2025, per Marshal Eubanks' study for NANOG.
> That translates to memory, power, cooling, issues around rerouting on
failure
> or recovery, and so on. By the way, it's what everyone says they want.
> 
> A variation on PI addressing is what Randy described on v6ops a few days
ago:
> he has several ISPs, derives his prefix from one, and advertises that
address
> space into his other ISPs. From one perspective, that is in fact PA
addressing -
> the prefix was allocated by one of his upstreams. However, to his other
ISPs, it
> is identical to PI - it's not their prefix, they have no way to aggregate
it, and if
> they want to provide him with full service they have to also advertise
that to
> their peers and upstreams. And to top it off, his primary ISP has to
advertise
> the prefix upstream itself, defensively, as otherwise all traffic will go
through
> their competitors. I call that "PA like PI", and treat it as a variation
on PI. The
> outcome is essentially the same - we enumerate the edge, with direct
impacts
> on hardware costs, operational costs, and so on.
> 
> The other one we know well involves some variation on network address
> translation. To the transit backbone, we no longer have to enumerate the
> edges; we are enumerating the points of attachment, dramatically reducing
> the route table to the size we see today in the IPv4 network and nominally
to a
> prefix for each ISP in the world - on the order of 5,000-10,000 routes.
>From the
> user's perspective, as with PI addressing, he doesn't have to think very
hard
> about his upstream's addressing. The issues are in the application: this
is
> Keith's cue to comment. With the kind of thing we have done in IPv4/IPv4
NAT,
> the vast majority of the edge network is simply incapable of offering
services to
> anyone outside it. With NPTv6, which is prefix translation and is
transparent
> between the inside and outside network apart from the fact of having
different
> addresses inside and outside, systems "inside" can offer services to
systems
> "outside", but it takes some changes in thinking.
> 
> One that we think we know well but IMHO haven't thought through from the
> Enterprise perspective adequately is shim6. The premise is that the ISP
> allocates a prefix to each of its customers, and the customers distribute
a /64
> to each of its LANs from each of those prefixes. Effect on applications -
they see
> end to end addressing, and just work, and the proposed host changes, if
> anyone actually implemented them (nobody has to my knowledge), means that
> you can change the address of a session without thinking too hard. Effect
on
> the transit backbone - wonderful. Effect on the enterprise network
> administrator - good grief. shim6 is DOA because they simply aren't
willing to
> do it.
> 
> One that we don't talk about is Steve's Metropolitan Addressing, what I
call
> exchange-based addressing. The premise here is that instead of putting a
> prefix on an ISP, put a prefix on an address exchange. The reason I don't
like the
> word "Metropolitan" is that it makes it sound geographic or associated
with a
> governmental unit; I'll argue that it is best associated with an Internet
> Exchange, whoever you choose to run that exchange. Net effect for the
access
> service provider is a larger route table, as he now as a prefix for a /56
or /60 for
> each customer; in the larger network, it behaves a lot like PA, which is
to say
> order of 10^4 routes. For the customer, the prefix is fungible - it moves
> between service providers and directly supports multihoming. The biggest
> impact I hear from service providers is that it inverts their transit
contracts - in
> effect, instead of the receiver's address determining its routing (it goes
to his
> ISP, which may be very large), the sender's does (it uses *his* ISP to get
to the
> city-or-whatever, and then hops to the receiver's ISP).  Say that, and
ISPs tend
> to get real uninterested.
> 
> I'm not in favor of 10^7 routes in the backbone. I am in favor of end to
end
> transparency at the application layer. I'm in favor of any solution that
> minimizes capital and operational complexity and expense. No solution on
the
> table is pain-free; to my mind, prefix translation is the least pain,
cost, and
> complexity among the available options.
>

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 07 Mar 2011 12:08:07 +0800

> different channels: same IDv6, different IPv6.

It seems to me that you are taking IPv6 address as "ID + locator", prefix is
the location and IID is the Identifier.
However, the traditional IPv6 address is "ID&locator", the IPv6 address
provides not only the location but also the Identifier.

> "externets" (what the DNS identfies as a class and the addressing was

I'm not sure, but I don't think IDv6 would accelerate IPv6 development.
In my impression, the slow IPv6 transition is because there are too many
NAT64 NATs, so the participants have no strong motivation to develop IPv6.
Now your bring NPT66 (another manner of NAT, as you said "an IPv6 network
address (header) which is allocated by the ISP: this is the actual IPv6
address", this box is an actual address translation device) or splitting
IPv6 ("ID&Locator" => "ID + Locator"), are they really beneficial to pure
IPv6?

Thanks and regards,
Xiangsong

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 07 Mar 2011 13:02:50 +0800

> NAT64 NATs, so the participants have no strong motivation to develop IPv6.

Sorry, it should be NAT44 in my previous message.

Xiangsong

---

From: Tomas Podermanski <[email-masked]>
Date: Mon, 07 Mar 2011 14:41:48 +0100

Brian,
    the current version of map66 implements only
draft-mrw-behave-nat66-02 (as you can see
http://map66.svn.sourceforge.net/viewvc/map66/README.txt?revision=55&view=markup)
. Unfortunately the project haven't been touched for more than 4 months.
I Don't know if the author have any plans to maintain the project in the
future. That is the reason why we are thinking of reimplementing the
code. We have several customers that are very interested in NPTv6 and
map66 is only implementation we have found so far.

Regards
    Tomas

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Mar 2011 18:22:38 +0100

> Since SHIM6 has neither of these costs, are you surprised

SHIM6 is a solution, but AFAIK it needs that hosts know:
- their global addresses
- means to force outgoing paths that go via the right CPE's (an ingress-filtering constraint) 

In a site using ULAs and having several links, a complement is therefore needed. 
SAM is an approach for this (ref. draft-despres-softwire-sam-01 - sec. 3.3), and AFAIK the only documented one so far.
Would you agree on this?

RD

---

From: Fred Baker <[email-masked]>
Date: Tue, 8 Mar 2011 09:29:33 -0800

I believe that's off-topic on this list.

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Mar 2011 18:43:11 +0100

> I believe that's off-topic on this list.

Hopefully, there will be a place and a time to discuss that, but fair enough.
(An private answer from Brian would be nice to have though.)

Regards,
RD

---

From: Fred Baker <[email-masked]>
Date: Tue, 8 Mar 2011 10:15:57 -0800

> the location and IID is the Identifier.

GSE, and its descendants 8+8, ILNP, and NPTv6, all consider the prefix to be the locator and the IID the identifier. That, btw, is the origin of the term "Interface Identifier" in RFC 4291, and the logic that led us to allocating /64s to LANs - along with the fact that MAC addresses in some LANs are longer than 48 bits.

> NAT64 NATs, so the participants have no strong motivation to develop IPv6.

I would disagree with that; the development of an IPv6 Internet has been hampered primarily by the lack of pressing need for one. As we run out of IPv4 address space, businesses that depend on periodic allocations of new address space have been taking pretty strong steps to deploy IPv6.

---

From: JFC Morfin <[email-masked]>
Date: Tue, 08 Mar 2011 21:50:35 +0100

At 19:15 08/03/2011, Fred Baker wrote:
>As we run out of IPv4 address space, businesses that depend on 
>periodic allocations of new address space have been taking pretty 
>strong steps to deploy IPv6.

Correct. But we ran short of IID (IDv6 in a multitechnology context) 
a very ago, what led to http.1.1.

Would the users have been taught about IDv6 first and IPv6 in 
continuation, the network would be IPv6 for a long. If I am correct 
64 bits corresponds to 13 alphadecimals. Deciding that IPv6 and 
IDv6/IID had to be written in hexa by engineers and not in names by 
marketers was the kill of any user IPv6 demand. By simple lack of 
awareness. IID/IDv6 has nothing to specifically with the IPv6 
protocol. Most of the Web sites use shorter than 13 alphadecimal 
sub-hosts names, hence are IDv6 but ignoring it. Too bad. When I 
converted the international network to X.121 in the 80s. we used 
numeric names under Tymnet protocol and converted them at the X.25/75 
gateway. The network was much smaller but the number of countries and 
aithorities over one hundred. The same for private nets. It took less 
than one year for international and for domestic for two very 
part-time of us on the issue.

jfc

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Mar 2011 08:07:01 +1100

In message <[email-masked]>, =?iso-8859-1?Q?R=E9m
i_Despr=E9s?= writes:
> 
> Le 3 mars 2011 =E0 20:48, Brian E Carpenter a =E9crit :
> > ...
> > =
> - means to force outgoing paths that go via the right CPE's (an ingress-fil=
> tering constraint) =

Having a per announced prefix default route would definitely help here,
for SLAAC at least.  If a router annouces a prefix then it is a candidate
for the default for packets sourced from the addresses within that prefix.

> In a site using ULAs and having several links, a complement is therefore ne=
> eded. =
> 
> SAM is an approach for this (ref. draft-despres-softwire-sam-01 - sec. 3.3)=
> , and AFAIK the only documented one so far.
> Would you agree on this?
> 
> RD
> 
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]