[sunset4] WG Adoption call for draft-chen-sunset4-nat64-port-allocation

[George, Wes]

This will start the two week adoption call for draft-chen-sunset4-nat64-port-allocation. This is the draft that previously was known as draft-chen-sunset4-cng-port-allocation but was renamed once the IPR-encumbered text was removed.

http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/

Please send support for adoption to the list, as well as any comments to improve the draft. This is a current charter milestone for the WG.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

[Fan, Peng]

Support for adoption.

---------- Forwarded message ----------
From: "George, Wes" <***@twcable.com>
Date: Tue, 21 Apr 2015 13:46:47 -0400
Subject: [sunset4] WG Adoption call for draft-chen-sunset4-nat64-port-allocation
To: "***@ietf.org" <***@ietf.org>

This will start the two week adoption call for draft-chen-sunset4-nat64-port-allocation. This is the draft that previously was known as draft-chen-sunset4-cng-port-allocation but was renamed once the IPR-encumbered text was removed.

http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/

Please send support for adoption to the list, as well as any comments to improve the draft. This is a current charter milestone for the WG.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

[JF Tremblay]

Post by George, Wes
This will start the two week adoption call for draft-chen-sunset4-nat64-port-allocation. This is the draft that previously was known as draft-chen-sunset4-cng-port-allocation but was renamed once the IPR-encumbered text was removed.
http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/ <http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/>
Please send support for adoption to the list, as well as any comments to improve the draft. This is a current charter milestone for the WG.

I’ve found the information presented in this document to be useful for deployers of NAT64s and support its adoption.

My general feeling of the document, however, is that many topics are described very verbosely, sometimes in a confusing manner. It would be great to use more to-the-point language and descriptions. Having a clear and focused document on port {block,range} allocations techniques, sizes and pitfalls would help the reader. Describing the vocabulary, design goals and tradeoffs would also be useful.


I had the following comments regarding the content:

2.2.2 "Preassigned port ranges occupy memory even when there are unused ports."
Really? A range with two port numbers is negligible quantity compared to a five-tuple or other data.

2.4.1 "The storage of log information may pose a challenge to operators, since it requires additional resources and data inspection processes to identify users."
The data inspection remark here does not make sense. The NAT might correlate source addresses to user information if it has it available, but it won’t inspect. The NAT does not store either.

2.4.1 In the result table, the dynamic port-range allocation is dependant of the range size and timing, that should be mentioned. (what values where used to get to this result?)

2.4.2: "The user's behavior normally correlates with system performance.”
Did you mean s/behavior/experience/ ? Otherwise I can’t grok this. Even with that change, I’m sure if this sentence is useful.

2.4.2: I’m not sure the reference to RFC6191 makes that much sense. RFC6191 describes host behavior for incoming connections, while the goal here is to safely optimize re-use of outgoing NAT ports.
As a side note, it might be useful to discuss the merits and problems relating to TIME-WAIT assassination here.

2.4.3: Why not cover port block randomization here as well?

3.2 The whole section about block timers is quite hard to follow. A block may have an additional timer applied after all ports are free. Having a clear definition here would help more than discussions around it.

3.2 6th paragraph suggests a very dangerous idea, that is to re-use ports in the latest block as soon as possible. This has the potential of bringing problems with rapid port re-use in blocks with very few available ports. This also slows down block re-allocation and reduces port usage overall, because of the typical port usage patterns (which is spiky in nature rather than linear).

3.3 The recommendations on source port logging are superfluous in this document. RFC6302 is well enough imo.

Things I didn’t see in this document that an implementer may be looking for:
- Port allocation design goals.
- Clear definitions of port range allocation terms (including timers)
- Address stickiness concept definition
- Possible ratios of users per address and tradeoffs.
- The idea of a refresh log (in addition to start-end logs, for long-lived blocks)
- Discussion on logging stability, timestamping, reliability.
- Discussion on port usage patterns and re-usage algorithms

JF

[GangChen]

Thank you for the comments. I'd seen it's great useful to improve the
draft quality.
Please see my reply inline.

Post by George, Wes
This will start the two week adoption call for
draft-chen-sunset4-nat64-port-allocation. This is the draft that
previously was known as draft-chen-sunset4-cng-port-allocation but was
renamed once the IPR-encumbered text was removed.
http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/
<http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/>
Please send support for adoption to the list, as well as any comments to
improve the draft. This is a current charter milestone for the WG.

I’ve found the information presented in this document to be useful for
deployers of NAT64s and support its adoption.
My general feeling of the document, however, is that many topics are
described very verbosely, sometimes in a confusing manner. It would be great
to use more to-the-point language and descriptions. Having a clear and
focused document on port {block,range} allocations techniques, sizes and
pitfalls would help the reader. Describing the vocabulary, design goals and
tradeoffs would also be useful.

Great. You just hit the point.
That is also my thinking how to improve the draft description.

2.2.2 "Preassigned port ranges occupy memory even when there are unused ports."
Really? A range with two port numbers is negligible quantity compared to a
five-tuple or other data.

I guess it may not only port information matter. One implementation I
can see is it will also create mapping table when it reserves a port
range.

2.4.1 "The storage of log information may pose a challenge to operators,
since it requires additional resources and data inspection processes to
identify users."
The data inspection remark here does not make sense. The NAT might correlate
source addresses to user information if it has it available, but it won’t
inspect. The NAT does not store either.

the issue is a NAT may don't know what source address should be correlated.
Therefore, the NAT have to store entire information preparing the searching.
For your information, the NAT should store at least three-months log
in our networks.

2.4.1 In the result table, the dynamic port-range allocation is dependant of
the range size and timing, that should be mentioned. (what values where used
to get to this result?)

great. I will add in the next version.

2.4.2: "The user's behavior normally correlates with system performance.”
Did you mean s/behavior/experience/ ? Otherwise I can’t grok this. Even with
that change, I’m sure if this sentence is useful.

The sentence is not useful. I like the proposal that just directly
going to the point . I will change the description.

2.4.2: I’m not sure the reference to RFC6191 makes that much sense. RFC6191
describes host behavior for incoming connections, while the goal here is to
safely optimize re-use of outgoing NAT ports.
As a side note, it might be useful to discuss the merits and problems
relating to TIME-WAIT assassination here.

Got your point. It will be clear.

2.4.3: Why not cover port block randomization here as well?

Good to know more if you point me a reference of "port block randomization".

3.2 The whole section about block timers is quite hard to follow. A block
may have an additional timer applied after all ports are free. Having a
clear definition here would help more than discussions around it.
3.2 6th paragraph suggests a very dangerous idea, that is to re-use ports in
the latest block as soon as possible. This has the potential of bringing
problems with rapid port re-use in blocks with very few available ports.
This also slows down block re-allocation and reduces port usage overall,
because of the typical port usage patterns (which is spiky in nature rather
than linear).
3.3 The recommendations on source port logging are superfluous in this
document. RFC6302 is well enough imo.

Those three questions I would leave to my co-authors for more feedback.

- Port allocation design goals.
- Clear definitions of port range allocation terms (including timers)
- Address stickiness concept definition
- Possible ratios of users per address and tradeoffs.
- The idea of a refresh log (in addition to start-end logs, for long-lived blocks)
- Discussion on logging stability, timestamping, reliability.
- Discussion on port usage patterns and re-usage algorithms

That is a good suggestion. Those information may implicitly described
in the document.
Again, I agree you general comments of " to-the-point language and
descriptions."
It hopefully will be clear when we improve the description.

Best Regards

Gang

JF

[JF Tremblay]

Inline.

Post by GangChen
Thank you for the comments. I'd seen it's great useful to improve the
draft quality.
Please see my reply inline.

Post by JF Tremblay
2.4.1 "The storage of log information may pose a challenge to operators,
since it requires additional resources and data inspection processes to
identify users."
The data inspection remark here does not make sense. The NAT might correlate
source addresses to user information if it has it available, but it won’t
inspect. The NAT does not store either.

the issue is a NAT may don't know what source address should be correlated.
Therefore, the NAT have to store entire information preparing the searching.
For your information, the NAT should store at least three-months log
in our networks.

In my opinion:
- NATs do not / should not store logs. This is done by an external server (syslog or other).
- NATs do not correlate source addresses to users, unless it already has that information available. This can be done offline by a server with much more ressources.

This could be guidance to put in this document, if not mentioned elsewhere. (but I thought that was quite obvious)

Post by GangChen

Post by JF Tremblay
2.4.3: Why not cover port block randomization here as well?

Good to know more if you point me a reference of "port block randomization”.

There isn’t a reference. I might have coined the term a couple of years back, not sure. This is basically the act of randomizing the assignments of blocks instead or in conjunction with port randomization within the block.
This could be a concept defined and discussed in this document.

/JF

[Huangjing (A)]

Hi, JF,

See inline

James

-----Original Message-----
Sent: Monday, May 04, 2015 10:30 PM
To: GangChen
Subject: Re: [sunset4] WG Adoption call for
draft-chen-sunset4-nat64-port-allocation
Inline.

Post by GangChen
Thank you for the comments. I'd seen it's great useful to improve the
draft quality.
Please see my reply inline.
2015-05-02 4:36 GMT+08:00, JF Tremblay

Post by JF Tremblay
2.4.1 "The storage of log information may pose a challenge to
operators, since it requires additional resources and data inspection
processes to identify users."
The data inspection remark here does not make sense. The NAT might
correlate source addresses to user information if it has it
available, but it won’t inspect. The NAT does not store either.

the issue is a NAT may don't know what source address should be correlated.
Therefore, the NAT have to store entire information preparing the searching.
For your information, the NAT should store at least three-months log
in our networks.

- NATs do not / should not store logs. This is done by an external server (syslog
or other).
- NATs do not correlate source addresses to users, unless it already has that
information available. This can be done offline by a server with much more
ressources.

Agree, log processing is out of the scope of NAT.

This could be guidance to put in this document, if not mentioned elsewhere.
(but I thought that was quite obvious)

Post by GangChen

Post by JF Tremblay
2.4.3: Why not cover port block randomization here as well?

Good to know more if you point me a reference of "port block

randomization”.
There isn’t a reference. I might have coined the term a couple of years back,
not sure. This is basically the act of randomizing the assignments of blocks
instead or in conjunction with port randomization within the block.
This could be a concept defined and discussed in this document.

I think you are talking about the port block randomization algorithms similar to those defined in RFC6431.
Will add some analysis and reference

/JF
_______________________________________________
sunset4 mailing list
https://www.ietf.org/mailman/listinfo/sunset4

[JF Tremblay]

Post by Huangjing (A)

Post by GangChen

Post by GangChen
Good to know more if you point me a reference of "port block

randomization”.
There isn’t a reference. I might have coined the term a couple of years back,
not sure. This is basically the act of randomizing the assignments of blocks
instead or in conjunction with port randomization within the block.
This could be a concept defined and discussed in this document.

I think you are talking about the port block randomization algorithms similar to those defined in RFC6431.
Will add some analysis and reference

Thanks for the reference, James. Interesting. I had in mind a non-cryptographically random set of port, which doesn’t seem to be handled in RFC6431. That would basically be a continuous set of ports where the first port is assigned randomly or semi-randomly (could be on block boundary for example). This concept could be defined and discussed in this document, but it’s just a minor point for discussion/improvement.

JF

[Mukom Akong T.]

I've read it and support adoption as well. I also agree with JF's point
that the NAT doesn't do logging and inspection. While that is an important
consideration deployment, I think section 2.4.1 should explicitly state
that such logging and inspection are done on another system, not the NAT64
one.

Regards

On Tue, May 5, 2015 at 4:11 PM, JF Tremblay <

Post by JF Tremblay

Post by Huangjing (A)

Post by GangChen
Good to know more if you point me a reference of "port block

randomization”.
There isn’t a reference. I might have coined the term a couple of years

back,

Post by Huangjing (A)

not sure. This is basically the act of randomizing the assignments of

blocks

Post by Huangjing (A)

instead or in conjunction with port randomization within the block.
This could be a concept defined and discussed in this document.

I think you are talking about the port block randomization algorithms

similar to those defined in RFC6431.

Post by Huangjing (A)
Will add some analysis and reference

Thanks for the reference, James. Interesting. I had in mind a
non-cryptographically random set of port, which doesn’t seem to be handled
in RFC6431. That would basically be a continuous set of ports where the
first port is assigned randomly or semi-randomly (could be on block
boundary for example). This concept could be defined and discussed in this
document, but it’s just a minor point for discussion/improvement.
JF
_______________________________________________
sunset4 mailing list
https://www.ietf.org/mailman/listinfo/sunset4

[GangChen]

Hello Mukom and JF,

Thank you for the review and support.
The point of NAT logging is well understood.
We will explicitly state that in the next version.

Best Regards

Gang

Post by Mukom Akong T.
I've read it and support adoption as well. I also agree with JF's point
that the NAT doesn't do logging and inspection. While that is an important
consideration deployment, I think section 2.4.1 should explicitly state
that such logging and inspection are done on another system, not the NAT64
one.
Regards
On Tue, May 5, 2015 at 4:11 PM, JF Tremblay <

Post by JF Tremblay

Post by Huangjing (A)

Post by GangChen

Post by GangChen
Good to know more if you point me a reference of "port block

randomization”.
There isn’t a reference. I might have coined the term a couple of
years

back,

Post by Huangjing (A)

Post by GangChen
not sure. This is basically the act of randomizing the assignments of

blocks

Post by Huangjing (A)

Post by GangChen
instead or in conjunction with port randomization within the block.
This could be a concept defined and discussed in this document.

I think you are talking about the port block randomization algorithms

similar to those defined in RFC6431.

Post by Huangjing (A)
Will add some analysis and reference

Thanks for the reference, James. Interesting. I had in mind a
non-cryptographically random set of port, which doesn’t seem to be
handled
in RFC6431. That would basically be a continuous set of ports where the
first port is assigned randomly or semi-randomly (could be on block
boundary for example). This concept could be defined and discussed in this
document, but it’s just a minor point for discussion/improvement.
JF
_______________________________________________
sunset4 mailing list
https://www.ietf.org/mailman/listinfo/sunset4

--
Mukom Akong T.
------------------------------------------------------------------------------------------------------------------------------------------
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------

[Huangjing (A)]

Hi, JF,

Thanks for the information!

James

-----Original Message-----
Sent: Tuesday, May 05, 2015 8:11 PM
To: Huangjing (A)
Subject: Re: [sunset4] WG Adoption call for
draft-chen-sunset4-nat64-port-allocation

Post by Huangjing (A)

Post by GangChen

Post by GangChen
Good to know more if you point me a reference of "port block

randomization”.
There isn’t a reference. I might have coined the term a couple of
years back, not sure. This is basically the act of randomizing the
assignments of blocks instead or in conjunction with port randomization

within the block.

Post by Huangjing (A)

Post by GangChen
This could be a concept defined and discussed in this document.

I think you are talking about the port block randomization algorithms similar

to those defined in RFC6431.

Post by Huangjing (A)
Will add some analysis and reference

Thanks for the reference, James. Interesting. I had in mind a
non-cryptographically random set of port, which doesn’t seem to be handled in
RFC6431. That would basically be a continuous set of ports where the first port
is assigned randomly or semi-randomly (could be on block boundary for
example). This concept could be defined and discussed in this document, but
it’s just a minor point for discussion/improvement.
JF

[Lee Howard]

Post by JF Tremblay
Inline.

Post by GangChen
Thank you for the comments. I'd seen it's great useful to improve the
draft quality.
Please see my reply inline.
2015-05-02 4:36 GMT+08:00, JF Tremblay

Post by JF Tremblay
2.4.1 "The storage of log information may pose a challenge to operators,
since it requires additional resources and data inspection processes to
identify users."
The data inspection remark here does not make sense. The NAT might correlate
source addresses to user information if it has it available, but it
won¹t
inspect. The NAT does not store either.

the issue is a NAT may don't know what source address should be correlated.
Therefore, the NAT have to store entire information preparing the searching.
For your information, the NAT should store at least three-months log
in our networks.

- NATs do not / should not store logs. This is done by an external server (syslog or other).

True; the operators of NATs store logs.

Post by JF Tremblay
- NATs do not correlate source addresses to users, unless it already has
that information available. This can be done offline by a server with
much more ressources.

Also true. As guidance to the operator of a NAT, though, this is useful
guidance.

Lee

Post by JF Tremblay
/JF

[George, Wes]

We have seen no opposition to adopting this document as a WG document. Authors, when you have a version ready that incorporates the recent feedback, please post it as as draft-ietf-sunset4-nat64-port-allocation

Thanks,

Wes


From: <George>, "George, Wes" <***@twcable.com<mailto:***@twcable.com>>
Date: Tuesday, April 21, 2015 at 1:46 PM
To: "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: WG Adoption call for draft-chen-sunset4-nat64-port-allocation

This will start the two week adoption call for draft-chen-sunset4-nat64-port-allocation. This is the draft that previously was known as draft-chen-sunset4-cng-port-allocation but was renamed once the IPR-encumbered text was removed.

http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/

Please send support for adoption to the list, as well as any comments to improve the draft. This is a current charter milestone for the WG.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.