Mailing List Archive

George Bonser wrote:

> I am saying that MTU probing works just fine, even with a
> link in between that has a shorter MTU and doesn't pass
> ICMP.

And I have been saying your statement is unfounded.

> I actually have one of those.

I can't see any.

> It actively probes with packets of varying sizes and learns
> what the path MTU is.

First, it sets eff_pmtu to 1400B. OK?

> It does not rely on ICMP. Again, it actively probes with
> varying sizes of packets until it believes it has
> "converged".

> The initial value for search_high SHOULD be the largest possible
> packet that might be supported by the flow. This may be limited by
> the local interface MTU, by an explicit protocol mechanism such as
> the TCP MSS option,

OK, so, even with local MTU of 7500B and without ICMP PTB, if
local MTU of your peer is 1500B, TCP MSS makes search_high
1500B.

As eff_pmtu of 1400B is close enough to search_high, you are
done.

Eff_pmtu of 1400B will be used forever with no probe packets
sent.

> The timer for Linux is 5 minute by default but you can change it.

Timer timeouts do not affect TCP MSS.

Masataka Ohta

PS

Your lengthy quotation means you don't see the point.

>
>
>> The timer for Linux is 5 minute by default but you can change it.
>
> Timer timeouts do not affect TCP MSS.
>

RFC 2923:
TCP should notice that the connection is timing out. After
several timeouts, TCP should attempt to send smaller packets,
perhaps turning off the DF flag for each packet. If this
succeeds, it should continue to turn off PMTUD for the connection
for some reasonable period of time, after which it should probe
again to try to determine if the path has changed.

It's Informational, not standards track, but the problem -- and the fix
-- have been known for a very long time.


--Steve Bellovin, https://www.cs.columbia.edu/~smb

On Sat, Feb 18, 2012 at 1:19 AM, Bob Vaughan <techie@w6yx.stanford.edu> wrote:
> "Ethernet/Token Ring/Cisco Console/whatever uses an RJ45 connector"
>  RJ45 defines a keyed 8P8C type connector, wired in a specific
>  manner, for a specific 2 wire telco service. Incompatible with the
>  above on several levels.  "RJxx" == specific connector/wiring pattern
>  for specific telco applications. Non-telco uses need not apply.

RJ45 is really an example of what was originally a misconception
became so widespread, so universal, that reality has actually shifted
so the misconception became reality. When was the last time you ever
heard anyone say "8P8C connector?"

Joe public caught on to "RJ45", so now that word means something
different in common usage than what it was specified to be. When
was the last time you heard someone say 8P8C connector in reference to
Ethernet?

Nowadays it is technically ambiguous to say "RJ45"; are you talking about
[a] The original standard, Registered Jack 45, which was a specific
connector together with a specific pinout (which is not Ethernet
over UTP)? Usage of the connector is exceedingly rare, and will
hardly ever be referred to.

Or
[b] "Ethernet" connector; The generic 8P8C connector (which has a
certain resemblance to RJ 45) is specified for use with TIA/EIA 568
compliant cable termination ?


Now instead of [a] being correct and [b] being always the
misconception..... [b] is "correct" in common usage.

And you have to decide based on context of the conversation which
defintion of RJ45 is intended, but [b] will almost always be the
correct definition.

--
-JH

> -----Original Message-----
> From: Masataka Ohta

> First, it sets eff_pmtu to 1400B. OK?

Where did you get 1400 from? Are you talking specifically with the linux implementation?

"As eff_pmtu of 1400B is close enough to search_high, you are done."

I suppose that depends on a specific implementation of "close enough" is. I haven't looked at the specific code linux uses to implement this and "close enough" is fairly subjective and can be interpreted in different ways by different people. But even 1400 on, say, a 1420 MSS ICMP black hole is one heck of a lot better than running no PMTUD at all and running at something under 600 bytes.


> PS
>
> Your lengthy quotation means you don't see the point.

I am wondering where you got this magic 1400 value from. It should basically zero in on a number pretty close to the real path MSS in a few iterations. Maybe that one specific implementation stops at the first successful value, but that isn't the way the recommendation is written.

Did I say it was "perfect"? No, but the notion that PMTUD is "broken" or "doesn't work" isn't exactly true. With the old mechanism, such a connection would simply hang or force people to turn off PMTUD completely. The new mechanism actually seems to perform rather well in the face of an ICMP black hole.

George Bonser wrote:

>> First, it sets eff_pmtu to 1400B. OK?
>
> Where did you get 1400 from?

Read the RFC. PERIOD.

Masataka Ohta

I, in fact, HAVE read the RFC.

The initial value for search_high SHOULD be the largest possible
packet that might be supported by the flow. This may be limited by
the local interface MTU, by an explicit protocol mechanism such as
the TCP MSS option, or by an intrinsic limit such as the size of a
protocol length field.

So the initial probe would be the reported MSS of the remote system in this case 1460 which would fail. I believe you might be getting confused by this paragraph:

The general strategy is for the Packetization Layer to find an
appropriate Path MTU by probing the path with progressively larger
packets. If a probe packet is successfully delivered, then the
effective Path MTU is raised to the probe size.

And believing that as soon as a value is found that passes, the process stops. That isn't the case.

PLPMTUD uses a searching technique to find the Path MTU. Each
conclusive probe narrows the MTU search range, either by raising the
lower limit on a successful probe or lowering the upper limit on a
failed probe, converging toward the true Path MTU. For most
transport layers, the search should be stopped once the range is
narrow enough that the benefit of a larger effective Path MTU is
smaller than the search overhead of finding it.

The issue here is that the judgement of "once the range is narrow enough that the benefit of a larger effective Path MTU is smaller than the search overhead of finding it" and one might well argue that someone decided that the difference between 1400 and 1420 MSS (20 bytes) isn't worth the extra overhead of finding it those 20 bytes. But in the case of a 7500 MTU and a 4500 MTU black hole link in between, it certainly does NOT go to 1400 and stay there.



> -----Original Message-----
> From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp]
> Sent: Monday, February 20, 2012 6:43 PM
> To: George Bonser
> Cc: nanog@nanog.org
> Subject: Re: Common operational misconceptions
>
> George Bonser wrote:
>
> >> First, it sets eff_pmtu to 1400B. OK?
> >
> > Where did you get 1400 from?
>
> Read the RFC. PERIOD.
>
> Masataka Ohta

Steven Bellovin wrote:

>> Timer timeouts do not affect TCP MSS.

> RFC 2923:
> TCP should notice that the connection is timing out. After
> several timeouts, TCP should attempt to send smaller packets,
> perhaps turning off the DF flag for each packet. If this
> succeeds, it should continue to turn off PMTUD for the connection
> for some reasonable period of time, after which it should probe
> again to try to determine if the path has changed.

So?

> It's Informational, not standards track, but the problem
> -- and the fix -- have been known for a very long time.

I'm not sure what, do you think, is the problem, because the
paragraph of RFC2923 you quote has nothing to do with TCP
MSS.

The relevant section of the RFC (relevant to MSS) should be:

The MSS should be determined based on the MTUs of the interfaces on
the system, as outlined in [RFC1122] and [RFC1191].

which means MSS is constant.

Note also that the next paragraph (next to the paragraph you
quote) of the RFC eventually says to use PMTU of 1280B for
IPv6 if there are black holes. It is not a very good thing
to do especially for IP over IP tunnels, because 1280B
packets are always fragmented if they are carried over a
tunnel with MTU of 1280B.

As implosion cause by multicast PMTUD of IPv6 requires ICMP
PTB black holed, you can expect a lot of black holes.

Masataka Ohta

George Bonser wrote:

> I, in fact, HAVE read the RFC.

You don't, at all.

> The initial value for search_high SHOULD be the largest possible
> packet that might be supported by the flow. This may be limited by
> the local interface MTU, by an explicit protocol mechanism such as
> the TCP MSS option, or by an intrinsic limit such as the size of a
> protocol length field.

It is a section on "search_high", while your question in your
previous mail was on "eff_pmtu":

>> First, it sets eff_pmtu to 1400B. OK?
> Where did you get 1400 from?

Note that rest of your mail also contains a lot of
misunderstandings on the RFC. But, as you don't read
the RFC, collecting them is a waste of time.

Read the RFC thoroughly again and again, 10 times a day
for 30 days. Then, I may reply your further questions if
asked off list.

PERIOD.

Masataka Ohta

On Feb 20, 2012, at 10:27 PM, Masataka Ohta wrote:

> Steven Bellovin wrote:
>
>>> Timer timeouts do not affect TCP MSS.
>
>> RFC 2923:
>> TCP should notice that the connection is timing out. After
>> several timeouts, TCP should attempt to send smaller packets,
>> perhaps turning off the DF flag for each packet. If this
>> succeeds, it should continue to turn off PMTUD for the connection
>> for some reasonable period of time, after which it should probe
>> again to try to determine if the path has changed.
>
> So?
>
>> It's Informational, not standards track, but the problem
>> -- and the fix -- have been known for a very long time.
>
> I'm not sure what, do you think, is the problem, because the
> paragraph of RFC2923 you quote has nothing to do with TCP
> MSS.

Sure it does. That's in 2.1; the start of it discusses PMTUD
failing for various reasons including firewalls.
>
> The relevant section of the RFC (relevant to MSS) should be:
>
> The MSS should be determined based on the MTUs of the interfaces on
> the system, as outlined in [RFC1122] and [RFC1191].
>
> which means MSS is constant.

The text I quoted says, in so many words, "send smaller packets".
I don't know how it's possible to be more explicit than that.
>
> Note also that the next paragraph (next to the paragraph you
> quote) of the RFC eventually says to use PMTU of 1280B for
> IPv6 if there are black holes. It is not a very good thing
> to do especially for IP over IP tunnels, because 1280B
> packets are always fragmented if they are carried over a
> tunnel with MTU of 1280B.

Please cite in context. The text I quoted says that one option
is to try turning off DF; the next paragraph notes that you can't
do that on v6. It also doesn't say to to use PMTU of 1280, it
says that that's a good fallback, and notes that v6 support requires
that. Although it doesn't say so, I'll note that IP in IP makes the
outer IP effectively a link layer for the inner IP; as such, it has
to preserve all of the relevant properties including a link MTU of
1280. If that doesn't work -- though it most likely will, since
the most common hardware MTU is from the ancient 1500 byte Ethernet
size -- the outer IP endpoint has to deal with it appropriately,
such as by intentional fragmentation. just as is done for IP over
ATM with its 53-byte cell size (RFC 2225).
>
> As implosion cause by multicast PMTUD of IPv6 requires ICMP
> PTB black holed, you can expect a lot of black holes.
>
> Masataka Ohta
>


--Steve Bellovin, https://www.cs.columbia.edu/~smb

Steven Bellovin wrote:

>> I'm not sure what, do you think, is the problem, because the
>> paragraph of RFC2923 you quote has nothing to do with TCP
>> MSS.
>
> Sure it does. That's in 2.1; the start of it discusses PMTUD
> failing for various reasons including firewalls.

Firewalls?

Though I have never assumed existence of firewalls, if you are
saying IPv6 will be even less operational because of firewalls,
I have no counter argument.

> The text I quoted says, in so many words, "send smaller packets".
> I don't know how it's possible to be more explicit than that.

No disagreement.

I have been keep saying that IPv6 can't depend on PMTUD and
must send packets of 1280B or less.

It's George Bonser, not me, who said there were other ways.

> Please cite in context. The text I quoted says that one option
> is to try turning off DF; the next paragraph notes that you can't
> do that on v6.

I thought the context is whether IPv6 is operational or not.

Or, is it whether PMTUDv4 operational or not?

Or, is your problem completely different from the above two?

Your clarification is helpful

Masataka Ohta

On Monday, February 20, 2012 09:07:20 PM Jimmy Hess wrote:
> RJ45 is really an example of what was originally a misconception
> became so widespread, so universal, that reality has actually shifted
> so the misconception became reality. When was the last time you ever
> heard anyone say "8P8C connector?"

And then there's the 10C variant used on some serial port interfaces (like those from Equinox).....

'8 pin modular plug' is reasonable, though, and is what I'll typically say, with the modifier 'for stranded' or 'for solid' conductors, as it does make a difference. I haven't said 'RJ45 plug' in years.

Yeah, it's a bummer that the keyed RJ45 plug got genericized to the unkeyed variant; at least the unkeyed plug used for TIA568A/B will work in a true RJ45 jack.....

Lamar Owen <lowen@pari.edu> wrote:
>
> On Monday, February 20, 2012 09:07:20 PM Jimmy Hess wrote:
> > RJ45 is really an example of what was originally a misconception
> > became so widespread, so universal, that reality has actually shifted
> > so the misconception became reality. When was the last time you ever
> > heard anyone say "8P8C connector?"
>
> And then there's the 10C variant used on some serial port interfaces (like
> those from Equinox).....

At least "RJ45-X" is still unambiguus. <wry grin>

Op 15-2-2012 21:47, John Kristoff schreef:
> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers. Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John
>
Haven't seen this one yet:

"TCP/IP is based on the osi model."

Erik van Westen.

----- Original Message -----
> From: "Jimmy Hess" <mysidia@gmail.com>

> RJ45 is really an example of what was originally a misconception
> became so widespread, so universal, that reality has actually shifted
> so the misconception became reality. When was the last time you ever
> heard anyone say "8P8C connector?"
>
> Joe public caught on to "RJ45", so now that word means something
> different in common usage than what it was specified to be. When
> was the last time you heard someone say 8P8C connector in reference to
> Ethernet?

WADR: horseshit.

I, in fact, just wrote a cabling RFQ yesterday for a new building, and
*I* write "8P8C male modular connector". So, in short: if you *actually
need to be saying it*, you actually need to be saying it correctly, because
you're talking to people who know the difference.

They won't say anything, mind you, and you'll get what you want; they'll
just think you're a clueless dilettante.

Cheers,
-- jr 'yes, I'm a prescriptivist[1]' a

[1] The *point* of language is communication; this is impossible if
words "mean what people want them to mean, no more, no less".
--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

Blocking incoming spam is worth spending $ on for software, 3rd party
filtering services, or dedicated spam filtering hardare. Blocking
outgoing spam? Huh?

----------------------------------------------------------------------
Jon Lewis, MCP :) | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

On Thu, Feb 16, 2012 at 4:46 AM, Michael Sinatra
<michael@rancid.berkeley.edu> wrote:
> ULA is the IPv6 equivalent of RFC1918

Michael, could you explain this a bit more? In the sense that :

a. Anyone can use ULA pretty much as they wish without having to go to
their ISP or RIR - same for RFC1918
b. In order to get to the public Internet, with ULA addressing, some
kind of translation is required - same for RFC1918
c. Without centralised registration, two different networks could end
up using same ULA space - same for RFC1918

There are certainly not identical but I'd think loosely equivalent.
What am I missing?

>



--
Mukom Akong [Tamon]
______________

“We don't LIVE in order to BREATH. Similarly WORKING in order to make
MONEY puts us on a one way street to irrelevance.“


[In Search of Excellence & Perfection] - http://perfexcellence.org
[Moments of TechXcellence] - http://techexcellence.net
[ICT Business Integration] - http://ibiztech.wordpress.com
[About Me] - http://about.me/perfexcellence

On 03/03/12 00:33, Mukom Akong T. wrote:
> On Thu, Feb 16, 2012 at 4:46 AM, Michael Sinatra
> <michael@rancid.berkeley.edu> wrote:
>> ULA is the IPv6 equivalent of RFC1918
>
> Michael, could you explain this a bit more? In the sense that :
>
> a. Anyone can use ULA pretty much as they wish without having to go to
> their ISP or RIR - same for RFC1918
> b. In order to get to the public Internet, with ULA addressing, some
> kind of translation is required - same for RFC1918

Actually, (b) isn't quite correct, especially depending on how you
define "the public Internet." If you define it as "the DFZ," then we're
*probably* okay. If you define it as "any commercial ISP and/or any
inter-AS traffic," then it's not so clear. To plagiarize myself in a
previous private response to someone else:

ULAs allow for native routing across a commercial ISP backbone to
support "extranets" (ugh, I hate that word)--essentially to allow an
enterprise to use a regular ISP (or ISPs) to carry ULA traffic between
sites. RFC 1918 requires that all privately-addressed traffic be
encapsulated if it is routed into another AS.

The consequence is that any AS can filter all RFC 1918 routes *and*
traffic at its border(s) and ISPs can (and SHOULD) refuse to route
unencapsulated RFC 1918-addressed traffic between ASes. ULAs may
require holes to be poked in any blanket filter. I see that as a
significant difference because you can no longer "guarantee"
non-routability of the space, which is what people tend to count on.

(We hope this won't happen, but it's not explicitly prevented by RFC
4193 as it is by RFC 1918. And see Ted Hardie's "rant" on the subject
at NANOG 40 for an argument that it might:
www.nanog.org/meetings/nanog40/presentations/ula-nanog.pdf)

My own view on this is that it's likely that ULA will stay out of the
DFZ (due to the now-widespread availability of IPv6 PI), but that you
may not be able to count on security (i.e. *traffic*) filters being
magically in place everywhere as one does for RFC 1918. (Again, that's
probably a misconception of RFC 1918, but there is still a big
difference in the potential for the consistent violation of the "magic
filter" assumption for ULA.)


> c. Without centralised registration, two different networks could end
> up using same ULA space - same for RFC1918

Yeah, but there's an orders-of-magnitude difference in the ability to
generate a reasonable expectation of uniqueness. Look at common RFC1918
usage--it often falls into 192.168.0.0/23 (e.g. most CPE NAT devices) or
10.0.0.0/23. Larger users tend to be all over net 10, which makes
merging networks a lot harder. It's much more likely that such mergers
will work better with ULA.

The large ULA space had put pressure on the standards community to
define something like ULA-C, but PI IPv6 has relieved that pressure.
However, the fact that ULA-C-like-things were ever proposed illustrates
the differences between ULA and RFC 1918 space.

> There are certainly not identical but I'd think loosely equivalent.
> What am I missing?

There's also a third difference that interacts with the typical
misconception that RFC 1918 implies or somehow specifies NAT (which I
think I mentioned elsewhere). When people think that RFC 1918 == NAT,
they get really surprised that there's no stateful NAT in IPv6. Given
the address space of IPv6, stateless prefix translation could go a long
way toward giving one the same functionality, but people tend to want
NAT to perform the stateful overloading of public IP addresses. So
there are really three misconceptions at work here:

RFC 1918 implies NAT
NAT is defined as stateful overloading of a small pool of public IP
addresses to support lots of private IP addresses. (Stateless NAT? Whut??)
ULAs are the same as RFC 1918 addresses

I realize that last one is cheating a bit because it it requires three
misconceptions to create the resultant confusion about there not being
stateful NAT66, but it *does* exist in the wild.

michael