Subject: [v6ops] Fwd: Last Call: RFC 6346 successful: moving to Proposed Standard

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Dec 2014 08:20:20 -0600

RJ Atkinson has pointed out that the proposal to move A+P from experimental to standard might be of interest to the v6ops working group.   This seems like a reasonable point.   I'm not a chair and not the responsible AD for v6ops, but I certainly would welcome discussion of this on v6ops.   I am on the mailing list, and I think Randy is too, so if this were discussed on v6ops, we would both see and be able to participate in the discussion.   So, by all means, please discuss!

Thanks,

Ted

Begin forwarded message:

> From: The IESG <[email-masked]>
> Subject: Last Call: RFC 6346 successful: moving to Proposed Standard
> Date: December 1, 2014 at 4:38:32 PM CST
> To: IETF-Announce <[email-masked]>
> Reply-To: [email-masked]
> 
> 
> The IESG has received a request from an individual participant to make
> the following status changes:
> 
> - RFC6346 from Experimental to Proposed Standard
>    (The Address plus Port (A+P) Approach to the IPv4 Address Shortage)
> 
> The supporting document for this request can be found here:
> 
> http://datatracker.ietf.org/doc/status-change-address-plus-port-to-proposed/
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2014-12-29. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> The affected document can be obtained via
> http://datatracker.ietf.org/doc/rfc6346/
> 
> IESG discussion of this request can be tracked via
> http://datatracker.ietf.org/doc/status-change-address-plus-port-to-proposed/ballot/
> 
>

---

From: Sander Steffann <[email-masked]>
Date: Wed, 3 Dec 2014 14:15:59 +0100

Hi,

> Op 2 dec. 2014, om 15:20 heeft Ted Lemon <[email-masked]> het volgende geschreven:
> 

Not much discussion from me, it just seems to make sense :)

Cheers,
Sander

---

From: Ray Hunter <[email-masked]>
Date: Wed, 03 Dec 2014 17:11:29 +0100

Sander Steffann wrote:
> Hi,
>
>> Op 2 dec. 2014, om 15:20 heeft Ted Lemon<[email-masked]>  het volgende geschreven:
>>
Why would the IETF want to put an approved "standard track" marking on 
what is a very clever but horrible kludge?

>  Of course, a provider might charge more for giving a
    customer the well-known port range, 0..1024, thus allowing the
    customer to provide externally available services.

Would I be happy as a consumer to have this service sold to me as 
"standard internet" ?

I don't think so.

It works perfectly well as "Experimental" for me.

-- 
Regards,
RayH

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Dec 2014 11:16:33 -0500

> what is a very clever but horrible kludge?

My question exactly.

We need to stop pretending that adding kludge after kludge to IPv4 is in 
any way meeting proposed standard criteria.

Instead of standardizing more and more kludges to IPv4, we should be 
working toward moving IPv4 to Historic.

Keith

---

From: Gert Doering <[email-masked]>
Date: Wed, 3 Dec 2014 17:36:30 +0100

Hi,

> working toward moving IPv4 to Historic.

Wouldn't that break 6to4?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

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

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 03 Dec 2014 17:40:36 +0100

> Wouldn't that break 6to4?

Oeh, that was an open door ;)

Greets,
 Jeroen

---

From: Sander Steffann <[email-masked]>
Date: Wed, 3 Dec 2014 17:57:36 +0100

Hi,

> Why would the IETF want to put an approved "standard track" marking on what is a very clever but horrible kludge?

Because with the IPv4 addresses running out horrible kludges are unfortunately necessary and putting the best of them on standards track is the best available option.

Cheers,
Sander

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Dec 2014 12:01:44 -0500

> Wouldn't that break 6to4?

Yes.   In the best possible way.

Keith

---

From: Ray Hunter <[email-masked]>
Date: Wed, 03 Dec 2014 18:51:17 +0100

> Because with the IPv4 addresses running out horrible kludges are unfortunately necessary and putting the best of them on standards track is the best available option.
What difference would that "Standards Track" stamp make to operations? 
ISPs can already deploy A+P today if they want.

An "Experimental" protocol has a very low requirement for WG review 
before publication.

Changing A+P to "Standards Track" is a very big step IMHO, especially 
considering what A+P breaks, and would likely be a drag on future 
protocol developments.

When do you think we can expect the first "No, you can't publish that 
because it will break A+P, which is Standards Track" comment?

-- 
Regards,
RayH

---

From: Sander Steffann <[email-masked]>
Date: Wed, 3 Dec 2014 19:42:20 +0100

Hi,

> Changing A+P to "Standards Track" is a very big step IMHO, especially considering what A+P breaks, and would likely be a drag on future protocol developments.

For IPv4 development: yep.

There are not enough IPv4 addresses so they have to be shared. Using NAT in ISP networks for address sharing needs lots of state. A+P gives us the option to do that in a stateless way, which is good for scalability and stability.

If A+P is the best we can do for IPv4 at this time then that's what we need to design for. I don't like it either and I long for the day that we can run IPv6-only and get rid of IPv4. Until then I think this is the best way forward.

> When do you think we can expect the first "No, you can't publish that because it will break A+P, which is Standards Track" comment?

When it's necessary :(
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Dec 2014 08:37:02 +1300

On 04/12/2014 06:51, Ray Hunter wrote:
> Sander Steffann wrote:
>> Hi,
>>
>>> Why would the IETF want to put an approved "standard track" marking
>>> on what is a very clever but horrible kludge?
>>
>> Because with the IPv4 addresses running out horrible kludges are
>> unfortunately necessary and putting the best of them on standards
>> track is the best available option.
>>
>> Cheers,
>> Sander
>>
>>

I'm with Ray on this. We've done our duty by documenting this kludge
and tagging it as 'experimental'. I didn't object too much to that,
since there are operators who have been forced into this solution by
circumstances. But we shouldn't be upgrading it so that it could be
understood to be a recommended practice.

I also have a technical question. The RFC says, on the subject of
user logging:

"  A+P offers a better set of trade-offs.  All that needs to be logged
   is the allocation of a range of port numbers to a customer.  By
   design, this will be done rarely, improving scalability."

With the growth in legally mandated logging around the world, what is
the practical experience on this? Has A+P logging proved to be scalable
at reasonable cost, or has it become a burden?

Which raises a wider question. The writeup simply asserts that "several
mechanisms for deploying A+P have been documented and implemented, and
are now seeing commercial deployment." I think we need a much more
substantive report on the experiment than that. For example, there were
concerns that users who need hundreds of open ports (BitTorrent users,
for example) would be penalised by A+P. Any data on that?

    Brian

---

From: Sander Steffann <[email-masked]>
Date: Wed, 3 Dec 2014 20:58:16 +0100

Hi,

> understood to be a recommended practice.

Do then what *is* the recommended practice to deal with a shortage of IPv4 addresses for ISPs? Big NAT boxes? We can't pretend the problem doesn't exist...

> at reasonable cost, or has it become a burden?

A+P logging is doable. NAT transaction living is a huge burden. Besides that: it might be legal to log the assigned A+P port range and it might not be legal to log NAT transactions (privacy issues). The Netherlands is a jurisdiction where this is the case. I checked that with the local regulator and law enforcement a few years ago.

> for example) would be penalised by A+P. Any data on that?

Well, connections are 4-tuples so usually this depends on if the client's NAT implementation will reuse a port number our not. Technically it can be solved.

CGN implementations have the same issue. The number of available address and port combinations is much larger, but so is the number of sessions. If each NAT session requires a unique local 2-tuple instead of a unique full 4-tuple then that will be a limiting factor...

Cheers,
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Dec 2014 11:24:28 +1300

Sander,

> Do then what *is* the recommended practice to deal with a shortage of IPv4 addresses for ISPs? Big NAT boxes? We can't pretend the problem doesn't exist...

I personally have been investing effort in this problem since 1992, and
have co-authored a number of RFCs since then. I suppose the recommended
practice is (a) support customers primarily with IPv6 and (b) use
the kludge of your choice to provide access to legacy IPv4-only sites.
RFC 6877 seems to be growing fast, for example. Or you could use the
approach described in RFC 6264 (and as far as I can see, you could
embed RFC 6436 in that).

We are stuck with kludges until the IPv4-only sites go away, but
IMHO we should be encouraging kludges that bring IPv6 into play.

> A+P logging is doable. NAT transaction living is a huge burden. Besides that: it might be legal to log the assigned A+P port range and it might not be legal to log NAT transactions (privacy issues)…

Yes, transaction logging is obviously unreasonable, but I was asking
for actual experience with A+P logging.

> Well, connections are 4-tuples so usually this depends on if the client's NAT implementation will reuse a port number our not. Technically it can be solved.

Actual data were presented showing clients opening hundreds of
simultaneous ports on their CPE. I'm asking whether that has
been experimentally proved to work with A+P boxes.

> CGN implementations have the same issue. The number of available address and port combinations is much larger, but so is the number of sessions. If each NAT session requires a unique local 2-tuple…

Yes, but I'm not asking about CGN.

   Brian

---

From: Owen DeLong <[email-masked]>
Date: Wed, 3 Dec 2014 17:48:27 -0800

> On Dec 3, 2014, at 8:16 AM, Keith Moore <[email-masked]> wrote:
> 
> We need to stop pretending that adding kludge after kludge to IPv4 is in any way meeting proposed standard criteria.
> 
> Instead of standardizing more and more kludges to IPv4, we should be working toward moving IPv4 to Historic.
> 
> Keith

Agreed, but I think that work is in v4sunset rather than v6ops.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 3 Dec 2014 17:52:19 -0800

> On Dec 3, 2014, at 8:57 AM, Sander Steffann <[email-masked]> wrote:
> 
> Hi,
> 

No, pointing out that the increasing pain you are feeling using IPv4 is an increasing reason to move to IPv6 belongs on the standards track.

Pretending that the best of the worst, the cream of the crap of increasingly painful kludges should be standardized just fuels the mistaken impression that IPv6 can be further procrastinated.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 3 Dec 2014 17:59:44 -0800

I think the need for A+P is adequately addressed in its current state. I do not think moving it to proposed standard is a good idea.

Owen

> On Dec 3, 2014, at 10:42 AM, Sander Steffann <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 Dec 2014 14:10:37 +0900

> IMHO we should be encouraging kludges that bring IPv6 into play.

you may want to actually read 6346, say 3.1.7, 4.1, ...  

and, in fact, 6346 was written specifically to offer alternatives to
cgn, e.g. see 1.1.

randy

---

From: Sander Steffann <[email-masked]>
Date: Thu, 4 Dec 2014 10:02:35 +0100

Hi Brian,

> have co-authored a number of RFCs since then.

I know. Sorry, didn't mean to imply that you didn't know what you were talking about our something like that.

> I suppose the recommended

The RFC recommends that: A+P-in-IPv6. All the other RFCs you mention require a stateful central device. I think that that's a bad practice, even if widely deployed.

> for actual experience with A+P logging.

I don't have any. What exactly do you want to log anyway? There isn't that much to log from a stateless device except how the stateless mapping algorithm is configured...

> Yes, but I'm not asking about CGN.

Sorry, I think you're asking the wrong questions then :)  The problem areas you point out are real, but not specific to A+P.

We know we can't find a perfect solution to the IPv4 address shortage problem so of course A+P had its problems. We should compare them to the problems of the alternatives to determine if A+P is the best we can do and deserves to be on the standards track.

Cheers,
Sander

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 Dec 2014 18:53:12 +0900

> The RFC recommends that: A+P-in-IPv6. All the other RFCs you mention
> require a stateful central device. I think that that's a bad practice,
> even if widely deployed.
> ...
> We know we can't find a perfect solution to the IPv4 address shortage
> problem so of course A+P had its problems. We should compare them to
> the problems of the alternatives to determine if A+P is the best we
> can do and deserves to be on the standards track.

https://mailarchive.ietf.org/arch/msg/ietf/e7zp6v0ihm2_F47bQO5GpDu708Y

---

From: Sander Steffann <[email-masked]>
Date: Thu, 4 Dec 2014 11:07:32 +0100

Hi Randy,

> https://mailarchive.ietf.org/arch/msg/ietf/e7zp6v0ihm2_F47bQO5GpDu708Y

Ah, that's where that deja-vu came from. Thanks for the pointer.

Cheers,
Sander

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 4 Dec 2014 21:15:14 +0900

> https://mailarchive.ietf.org/arch/msg/ietf/e7zp6v0ihm2_F47bQO5GpDu708Y

I thought A+P basically ended up becoming MAP. Do I misunderstand?

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 Dec 2014 21:17:58 +0900

> I thought A+P basically ended up becoming MAP. Do I misunderstand?

you are talking about ipv6 transition mechanisms, right?  there can
never be enough of them.  :)

map-?, 4rd, 6rd (but inversely), ...  are a+p varieties.  the list goes
on.

randy

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 4 Dec 2014 21:25:47 +0900

> map-?, 4rd, 6rd (but inversely), ...  are a+p varieties.  the list goes

Right. So yes, A+P was successful, and spawned a series of transition
mechanisms. Whether that means we need to issue a new Proposed Standard RFC
I don't know. It doesn't really contain anything to standardize, right?

---

From: Sander Steffann <[email-masked]>
Date: Thu, 4 Dec 2014 14:03:54 +0100

Hi Lorenzo,

> I thought A+P basically ended up becoming MAP. Do I misunderstand? 

MAP is indeed the most common implementation of the A+P architecture. For many practical purposes they are kind of equivalent these days.

Cheers,
Sander

---

From: Randy Bush <[email-masked]>
Date: Fri, 05 Dec 2014 03:36:47 +0900

> mechanisms. Whether that means we need to issue a new Proposed
> Standard RFC I don't know.

no one is proposing a new ps.  6346 was mis-classified due to an iesg
member's politics of denial of the shared address approach, including
sabatoging two shara bofs (s'holm and hiroshima).  this merely tries
to correct this historical error.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Dec 2014 08:32:58 +1300

> you may want to actually read 6346, say 3.1.7, 4.1, ...  

I apologise, I had indeed forgotten the SMAP stuff. Probably the last
time I actually read the whole thing was when draft-ymbk-aplusp was
in Last Call.

> and, in fact, 6346 was written specifically to offer alternatives to

Sure. I understand that.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Dec 2014 08:45:48 +1300

On 04/12/2014 22:02, Sander Steffann wrote:
> The RFC recommends that: A+P-in-IPv6. 

Yes, Randy has set me straight on that.

> All the other RFCs you mention require a stateful central device. I think that that's a bad practice, even if widely deployed.

We agree on that.
> I don't have any. What exactly do you want to log anyway? There isn't that much to log from a stateless device except how the stateless mapping algorithm is configured...

Well, if you are under a legal mandate to log who is using which IP
address at any given time, with A+P you also have to log who is using
each port range. No choice about that, whether the underlying mechanism
is stateful or not. The question is whether that aggravates the scaling
problem (compared to CGN or XLAT464 or other approaches).

> Sorry, I think you're asking the wrong questions then :)  The problem areas you point out are real, but not specific to A+P.

Right, but today's question is whether A+P is appropriate for the
standards track. (Like there was a question whether RFC 4787/6888
were appropriate for BCP.) We disagree on the answer...

   Brian

---

From: Tom Taylor <[email-masked]>
Date: Thu, 04 Dec 2014 15:32:49 -0500

...

> problem (compared to CGN or XLAT464 or other approaches).
...
draft-ietf-behave-syslog-nat-logging is basically theoretical, but it 
does give information on logging volumes. Look particularly at the 
Applicability section.

There is also information in draft-chen-sunset4-cgn-port-allocation and 
draft-donley-behave-deterministic-cgn.

Tom Taylor

---

From: Sander Steffann <[email-masked]>
Date: Thu, 4 Dec 2014 21:51:52 +0100

Hi Brian,

> problem (compared to CGN or XLAT464 or other approaches).

I don't think I understand your question.

Best-case re logging the CGN (thinking of NAT444/NAT64/DS-Lite based. 464XLAT is built on top of NAT64) is when the CGN implements per-client port ranges so that only the assignment of ports to users needs to be logged. Worst case for logging is full dynamic NAT where every transaction needs to be logged. How could logging A+P port ranges be worse than any of that?

Cheers,
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Dec 2014 10:52:23 +1300

> Best-case re logging the CGN (thinking of NAT444/NAT64/DS-Lite based. 464XLAT is built on top of NAT64) is when the CGN implements per-client port ranges so that only the assignment of ports to use…

That makes sense and is consistent with the discussion in
http://tools.ietf.org/html/rfc6346#section-6. But I think
you're missing my question, which is about *practical
experience*. Moving a document from Experimental to the
standards track is a moment when we can legitimately ask
what the practical results of the experiment were.
http://tools.ietf.org/html/rfc7127#section-3.1
certainly allows the IESG to consider this aspect.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Dec 2014 10:56:09 +1300

On 05/12/2014 09:32, Tom Taylor wrote:
>>>>> A+P logging is doable. NAT transaction living is a huge burden.
>>>>> Besides that: it might be legal to log the assigned A+P port range
>>>>> and it might not be legal to log NAT transactions (privacy issues).
>>>>> The Netherlands is a jurisdiction where this is the case. I checked
>>>>> that with the local regulator and law enforcement a few years ago.
>>> I don't have any. What exactly do you want to log anyway? There isn't
>>> that much to log from a stateless device except how the stateless
>>> mapping algorithm is configured...
>>

Thanks Tom. So for a CGN, the order of magnitude is "150,000 call detail
records per second, varying in length from 500 to 1500 bytes."
Equivalent data for A+P would be very informative.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Dec 2014 11:07:35 +1300

> MAP is indeed the most common implementation of the A+P architecture. For many practical purposes they are kind of equivalent these days.

One more thought. I don't see RFC 6346 in the downref registry, which
presumably means than none of the subsequent standards track documents
have needed it as a normative reference. So I wonder if it actually needs
to be on the standards track at all. If it was moved to Informational,
with very light editing, that would remove the Experimental tag that
Randy objects to. We have a long tradition of Informational documents
that record known practice or serve as background for standards.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Dec 2014 17:33:17 -0500

On 12/04/2014 05:07 PM, Brian E Carpenter wrote:
> have needed it as a normative reference. So I wonder if it actually 
> needs to be on the standards track at all. If it was moved to 
> Informational, with very light editing, that would remove the 
> Experimental tag that Randy objects to. We have a long tradition of 
> Informational documents that record known practice or serve as 
> background for standards.
I would be a lot more comfortable with that.

Keith

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 5 Dec 2014 11:19:45 +0900

> that record known practice or serve as background for standards.

Randy, would that work for you?

---

From: Andrew Yourtchenko <[email-masked]>
Date: Sun, 7 Dec 2014 09:37:42 +0000

Brian,

Inline ...

>> On 04 Dec 2014, at 21:56, Brian E Carpenter <[email-masked]> wrote:
>> 

For MAP, the exact answer is "zero assuming the current configuration and IPv6 assignment are logged elsewhere", because one can always algorithmically find the IPv4 addresses and port range from allocated IPv6 prefix and domain config.

http://6lab.cisco.com/map/MAPnew.php?eyJydWxlcyI6W1siVGVzdCIsIjIwMDE6ZGI4OmZmZmY6ZjAwMC81MiIsIjE5Mi4wLjIuMC8zMSIsOCw2LDBdXSwibWFwdHlwZSI6IlQiLCJkbXJiciI6IjIwMDE6REI4OkNBRkU6Q0FGRTo6LzY0In0=

 if you like to see this process in action (you will see a mock config using 2 IPv4 addresses for domain).

--a