Amen!
There are some folks (like me) who advocate a DHCPv6 that can convey
a default gateway AND the ability to turn off RA's entirely. That
is make it work like IPv4.
I'd also love to turn off stateless autoconfig altogether and not be coerced
to assign /64s to single LANs, which I am becoming convinced that it was a
poor decision on the IETFs part.
Stateless autoconfig works very well, It would be just perfect if the
network boundary was configurable (like say /64 if you really want it, or
/80 - /96 for the rest of us)
cheers
Carlos
Stateless autoconfig works very well, It would be just perfect if the
network boundary was configurable (like say /64 if you really want it,
or
/80 - /96 for the rest of us)
Why do you feel it's a poor decision to assign /64's to individual LANs?
Best Regards,
Nathan Eisenberg
Amen!
There are some folks (like me) who advocate a DHCPv6 that can convey
a default gateway AND the ability to turn off RA's entirely. That
is make it work like IPv4.
I'd also love to turn off stateless autoconfig altogether and not be coerced
to assign /64s to single LANs, which I am becoming convinced that it was a
poor decision on the IETFs part.
Nah... The /64 thing is fine. If they hadn't done that, we likely would have only
a 64-bit address space total. 64-bit lans with 64-bit routing identifiers are
fine.
What would be nice would be if we changed the semantics a bit and made
it 16+48+64 where the first 16 of the dest+source could be re-assembled
into the destination ASN for the packet and the remaining 48 identified
a particular subnet globally with 64 for the host. Unfortunately, that ship
has probably sailed.
Stateless autoconfig works very well, It would be just perfect if the
network boundary was configurable (like say /64 if you really want it, or
/80 - /96 for the rest of us)
There really is no need for anything smaller than /64. What, exactly, do you
think you gain from a smaller netmask?
Owen
What would be nice would be if we changed the semantics a bit and made
it 16+48+64 where the first 16 of the dest+source could be
re-assembled
into the destination ASN for the packet and the remaining 48
identified
a particular subnet globally with 64 for the host. Unfortunately, that
ship
has probably sailed.
Well, since ASNs are now 32-bit, yeah.
What would be nice would be if we changed the semantics a bit and made
it 16+48+64 where the first 16 of the dest+source could be
re-assembled
into the destination ASN for the packet and the remaining 48
identified
a particular subnet globally with 64 for the host. Unfortunately, that
ship
has probably sailed.
On the other hand, it probably would have been easier (and more widely
adopted already) to simply go to an "internet of internets" model where
you break the planet up into 32-bit regions, each with their own 32-bit
"internets" and just use what amounts to IPIP tunneling between them and
enlarge the standard MTU from 1500 to accommodate that without further
packet fragmentation.
And speaking of changing MTU, is there any reason why private exchanges
shouldn't support jumbo frames? Is there any reason nowadays that things
that are ethernet end to end can't be MTU 9000 instead of 1500? It
certainly would improve performance and reduce the packets/sec and
increase performance on latent links. Why are we still using 1500 MTU
when peering? Is there any gear at peering points that DOESN'T support
jumbo frames these days?
In a message written on Sat, Oct 23, 2010 at 05:23:14PM -0700, Owen DeLong wrote:
>> There are some folks (like me) who advocate a DHCPv6 that can convey
>> a default gateway AND the ability to turn off RA's entirely. That
>> is make it work like IPv4.
>>
> I'd also love to turn off stateless autoconfig altogether and not be coerced
> to assign /64s to single LANs, which I am becoming convinced that it was a
> poor decision on the IETFs part.
>
Nah... The /64 thing is fine. If they hadn't done that, we likely would have only
a 64-bit address space total. 64-bit lans with 64-bit routing identifiers are
fine.
I think the 64-bit boundry is fine (from a DHCP perspective). I
do think if we're going to update the DHCP spec it should support
a netmask option, just because leaving it out is short sighted to
the future, but I would use it with /64's today.
There really is no need for anything smaller than /64. What, exactly, do you
think you gain from a smaller netmask?
There is a slippery slope here, if users make do with smaller
providers may give out smaller blocks, and so on.
That said, if a provider does hand out a /64, I would very much
like technology to make 16 bits of subnet + 48 bits of host, with
EUI-48 used directly for autoconf as an option. Particularly when
we talk about 6rd and other things that use a lot of space this
option would be huge. Users would still get 16 bits of subnet, and
host space so big they could never fill it.
In a message written on Sat, Oct 23, 2010 at 05:23:14PM -0700, Owen DeLong wrote:
There are some folks (like me) who advocate a DHCPv6 that can convey
a default gateway AND the ability to turn off RA's entirely. That
is make it work like IPv4.
I'd also love to turn off stateless autoconfig altogether and not be coerced
to assign /64s to single LANs, which I am becoming convinced that it was a
poor decision on the IETFs part.
Nah... The /64 thing is fine. If they hadn't done that, we likely would have only
a 64-bit address space total. 64-bit lans with 64-bit routing identifiers are
fine.
I think the 64-bit boundry is fine (from a DHCP perspective). I
do think if we're going to update the DHCP spec it should support
a netmask option, just because leaving it out is short sighted to
the future, but I would use it with /64's today.
My understanding was DHCPv6 did support prefixes other than /64.
There really is no need for anything smaller than /64. What, exactly, do you
think you gain from a smaller netmask?
There is a slippery slope here, if users make do with smaller
providers may give out smaller blocks, and so on.
Yeah, that could be worse than neutral. Still there's no gain to smaller
than /64, only loss...
That said, if a provider does hand out a /64, I would very much
like technology to make 16 bits of subnet + 48 bits of host, with
EUI-48 used directly for autoconf as an option. Particularly when
we talk about 6rd and other things that use a lot of space this
option would be huge. Users would still get 16 bits of subnet, and
host space so big they could never fill it.
I think that ship has pretty well sailed, but, it might be a good future
workaround if providers start doing stupid pet tricks like assigning
single /64s to end customers.
Owen
Probably no reason at all, though probably little perceived benefit. 1492 is common enough that google/youtube already runs lower MTU's just to avoid common broken PPPoE setups (which often could run higher MTU, but weren't configured that way).
Not uncommon for cell companies to request 1600 MTU or more for their layer 2 transport, which one vendor had to custom patch 1648 into their gear to even support that much. Of course, it will be lowered by a variety of tags/tunnels/etc by the time it gets to the cell phone. It cracks me up that SONET interfaces default 4470, and ethernet still defaults to 1500. I've yet to see an MTU option in standard circuit setup forms, which would indicate to me that asking for a higher MTU might get me one extra link before dropping back to 1500ish.
Jack
In a message written on Sun, Oct 24, 2010 at 11:09:28AM -0500, Jack Bates wrote:
variety of tags/tunnels/etc by the time it gets to the cell phone. It
cracks me up that SONET interfaces default 4470, and ethernet still
defaults to 1500. I've yet to see an MTU option in standard circuit
setup forms, which would indicate to me that asking for a higher MTU
might get me one extra link before dropping back to 1500ish.
I've had pretty good luck asking for higher MTU's on both customer
and peering links. I'd say about an 80% success rate for dedicated
GigE's. It's generally not on the forms though, and sometimes you
get what I consider weird responses. For instance I know several
providers who won't going higher than 4470 on ethernet.
If more folks asked for higher MTUs it might become part of the standard
forms...
Probably no reason at all, though probably little perceived benefit.
1492 is common enough that google/youtube already runs lower MTU's
just
to avoid common broken PPPoE setups (which often could run higher MTU,
but weren't configured that way).
I run into that already with people doing various things inside their
net (MPLS, GRE, IPIP?) that shorten the effective MTU but they block the
ICMP unreachable packets and break PMTU discovery. That blanket
blocking of ICMP unreachable type 3 code 4 is evil, in my opinion.
If your traffic passes through a Cisco ASA series device (and maybe
other vendors, too) your MTU is effectively 1380 anyway as that is the
maximum MSS that it advertises (or can even be configured to advertise)
when it establishes an outbound connection and in some versions of its
code will drop a packet from an endpoint that doesn't honor the
advertised MSS.
It is a real performance killer across the Internet in my opinion and
better performance could be had, particularly for long distance links
where you are limited by the number of "in flight" packets if those
packets could be bigger. The problem is that even if you have two end
points that are jumbo capable, the networks in the path don't seem to
support >1500 MTU. If everyone configured their peering and internal
gear to support a 9216 byte frame size and set their MTUs to 9000, that
change would be transparent to the connections flowing though it and
people who wanted to send larger frames could do so without impacting
anyone using a shorter size.
I've had pretty good luck asking for higher MTU's on both customer and
peering links. I'd say about an 80% success rate for dedicated
GigE's.
It's generally not on the forms though, and sometimes you get what I
consider weird responses. For instance I know several providers who
won't going higher than 4470 on ethernet.
If more folks asked for higher MTUs it might become part of the
standard forms...
That is what I am thinking as well. For example, in the past week I
have seen someone here asking about data center locations and mentioned
data replication between them. If you are on both coasts of the US and
are backing up or otherwise replicating data between the two, even going
to a MTU of 3000 is a measurable win depending on the amount of data you
are moving and the protocols you are using. Load on routers and even
hosts is generally caused by packets per second, not bits per second.
If you cut the number of packets in half you reduce the load on every
single piece of gear in the path. Gee, I wonder how much energy
consumption that would save on a global basis if everyone did that.
Coming across Phil Dykstra's paper from 1999 is what got me thinking
about it (well, that and moving a lot of data between Europe and the
West coast of the US).
http://sd.wareonearth.com/~phil/jumbo.html
http://staff.psc.edu/mathis/MTU/
Coming across Phil Dykstra's paper from 1999 is what got me thinking
about it (well, that and moving a lot of data between Europe and the
West coast of the US).
http://sd.wareonearth.com/~phil/jumbo.html
http://staff.psc.edu/mathis/MTU/
Found more good information here:
http://noc.net.internet2.edu/i2network/maps--documentation/policy-statem
ents.html#Jumbo%20Frames
It might not be a bad idea to take some of what is learned on Inet2 and
backport it to the 'net where possible. I also discovered that Linux
will do RFC4821 PMTU discovery if you set
/proc/sys/net/ipv4/tcp_mtu_probing to the proper value. It is turned off
by default.
Solaris is on by default it appears.
In message <4BC01459-B53A-4B2C-B75B-47D89550DFC5@delong.com>, Owen DeLong write
s:
=20
In message <E22A56B3-68F1-4A75-A091-E416800C485B@delong.com>, Owen =
DeLong write
s:
=20
Which is part one of the three things that have to happen to make =
ULA
really bad for the internet.
=20
Part 2 will be when the first provider accepts a large sum of money =
to
route it within their public network between multiple sites owned =
by
the same customer.
=20
=20
That same customer is also going to have enough global address
space to be able to reach other global destinations, at least enough
space for all nodes that are permitted to access the Internet, if =
not
more. Proper global address space ensures that if a global =
destination
is reachable, then there is a high probability of successfully =
reaching
it. The scope of external ULA reachability, regardless of how much
money is thrown at the problem, isn't going to be as good as proper
global addresses.
=20
_IF_ they implement as intended and as documented. As you've
noted there's a lot of confusion and a lot of people not reading the
documents, latching onto ULA and deciding ti's good.
=20
It's not a big leap for some company to do a huge ULA deployment
saying "this will never connect to the intarweb thingy" and 5-10 =
years
later not want to redeploy all their addressing, so, they start =
throwing
money at getting providers to do what they shouldn't instead of
readdressing their networks.
=20
IPv4 think.
=20
You don't re-address you add a new address to every node. IPv6 is
designed for multiple addresses.
=20
That's a form of re-addressing. It's not removing the old addresses, =
but,
it is a major undertaking just the same in a large deployment.
I don't see any major difference in the amount of work required to
go from disconnected ULA to ULA + PA/PI or ULA + NAT compared to
disconnected PI to connected PI. Whether the machines have one or
two address is inconsequential in the grand scheme of things.
If it's all SLAAC, you're right. Most people have some servers and
some other machines that get static addresses. In those cases, those
machines have to be touched to facilitate the transition if you start with
ULA. If you start with GUA, then, it's just a matter of changing the firewall
policies and the router filters, and, possibly some routes.
For private site interconnect, I'd think it more likely that the
provider would isolate the customers traffic and ULA address space =
via
something like a VPN service e.g. MPLS, IPsec.
=20
One would hope, but, I bet laziness and misunderstanding trumps
reason and adherence to RFCs over the long term. Since ULA
won't get hard-coded into routers as unroutable (it can't),
=20
Actually it can be. You just need a easy switch to turn it off. The
router can even work itself out many times. Configure multiple =
interfaces
from the same ULA /48 and you pass traffic for the /48 between those
interfaces. You also pass routes for that /48 via those interfaces.
=20
If you have an easy switch to turn it off, it will get used, thus =
meaning that
it isn't hard coded, it's just default.
On by default will create a effective deterrent.
We can agree to disagree about that. However, there's enough code out
there already that isn't on by default that I think that ship has sailed.
Owen
"If Woody had gone straight to a ULA prefix, this would never have happened..."
If a site is numbering their internal IPv4 stuff to avoid having to renumber
on a provider change, then why would they number their IPv6 stuff from
provider space rather than ULA space?
And remember - (a) IPv6 allows machine to easily support multiple addresses and
(b) if you have a provider address and a ULA, changing providers only means
renumbering a *partial* renumber of the hosts that require external visibility
- your internal hosts can continue talking to each other on a ULA as if nothing
happened.
Sure beats the mayhem if your company buys an organization and the 1918
spaces the 2 groups use overlap... Yee-hah. 
With v6, while changing prefixes is easy for some gear, other gear is
not so easy. If you number your entire network in Provider A's space,
you might have more trouble renumbering into Provider B's space because
now you have to change your DHCP ranges, probably visit printers, fax
machines, wireless gateways, etc. and renumber those, etc. And some
production boxes that you might have in the office data center are
probably best left at a static IP address, particularly if they are
fronted by a load balancer where their IP is manually configured.
"If Woody had gone straight to a ULA prefix, this would never have happened..."
Or better yet, if Woody had gone straight to PI, he wouldn't have this problem,
either.
If a site is numbering their internal IPv4 stuff to avoid having to renumber
on a provider change, then why would they number their IPv6 stuff from
provider space rather than ULA space?
Which gains what vs. PI?
And remember - (a) IPv6 allows machine to easily support multiple addresses and
(b) if you have a provider address and a ULA, changing providers only means
renumbering a *partial* renumber of the hosts that require external visibility
- your internal hosts can continue talking to each other on a ULA as if nothing
happened.
If you have PI space, changing providers can be even easier and you can leave
multiple providers running in parallel.
Owen
ula really never should an option... except for a short lived lab,
nothing permanent.
Or better yet, if Woody had gone straight to PI, he wouldn't have this problem,
either.
And he can justify PI when he first deploys IPv6 with a single provider under which policy? (Assume he is in the ARIN region and that his IPv4 space is currently provider-assigned from a couple of different providers and he's using NAT to do his IPv4 failover management)
1. Quite possibly does not qualify for an IPv4 assigned under the current IPv4 policy (certainly not in a few more months, when *nobody* will qualify except for some transition-space requests)
2. Definitely can't show efficient utilization of all direct IPv4 assignments, as he has none.
3. He's not a community network.
So he can't go "straight to PI". He either needs to go PA with the first provider, then through renumbering pain (which he knows all too well about from IPv4, and none of the problems like "change the address of the intranet wiki server in the internal DNS servers" change with IPv6), or use something internal like ULA for things he doesn't want to renumber.
If a site is numbering their internal IPv4 stuff to avoid having to renumber
on a provider change, then why would they number their IPv6 stuff from
provider space rather than ULA space?
Which gains what vs. PI?
Nothing, but PI isn't available to him. See above.
And remember - (a) IPv6 allows machine to easily support multiple addresses and
(b) if you have a provider address and a ULA, changing providers only means
renumbering a *partial* renumber of the hosts that require external visibility
- your internal hosts can continue talking to each other on a ULA as if nothing
happened.
If you have PI space, changing providers can be even easier and you can leave
multiple providers running in parallel.
That's a big IF, given the above. He doesn't qualify for PI space, thanks to ARIN policies set by people who want routing tables to stay as small as possible, so PI space to be as difficult as possible to obtain for people like him.
Matthew Kaufman
If you have PI space, changing providers can be even easier and you can
leave
multiple providers running in parallel.
That's a big IF, given the above. He doesn't qualify for PI space, thanks to
ARIN policies set by people who want routing tables to stay as small as
possible, so PI space to be as difficult as possible to obtain for people
like him.
Would it help if ARIN's policies were changed to allow anyone and everyone
to obtain PI space directly from them (for the appropriate fee, of course), and
then it was left up to the operating community to decide whether or not to
route the smaller chunks of space?
Right now, we're trying to keep the two communities somewhat in alignment,
so that when people obtain IP space, they have a relatively good feeling about
it being routed correctly. If we let the ARIN policies stray too far
from what the
router operators can/will accept, we're going to end up with an ugly, fragmented
internet in which organizations are given PI GUA space, only to
discover it's not
actually useful for reaching large swaths of the internet.
I'd hazard a guess that people would consider that to be a worse scenario
than the one in which we limit who can get PI space so that there's a reasonably
good probability that when the space is issued and announced via BGP, it will be
reachable from most of the rest of the internet...that is to say, our
current modus
operandi.
Matthew Kaufman
Matt
ula really never should an option... except for a short lived lab,
nothing permanent.
I have a few candidate networks for it. Mostly networks used for
clustering or database access where they are just a flat LAN with no
"gateway". No layer 3 gets routed off that subnet and the only things
talking on it are directly attached to it.
Would it help if ARIN's policies were changed to allow anyone and
everyone
to obtain PI space directly from them (for the appropriate fee, of
course), and
then it was left up to the operating community to decide whether or
not
to
route the smaller chunks of space?
I would probably support something like that with a few caveats. One
being that we try to keep things as aggregated as possible. If someone
grows out of a /48, they get say, a /46 and don't get additional
discontiguous /48 nets. Also, we should wait a while to do that. Once a
significant portion of traffic has moved to v6, people might want to
make decisions to mitigate routing table bloat with v4. Once v6 traffic
exceeds v4 traffic, some of those decisions become easier to make
(accept v4 routes from peers and shove any other traffic out to transit
with a default, for example, rather than take full v4 routes from
multiple transit peers.). I might be willing to accept some sub-optimal
routing for v4 once v6 exceeds v4. Maybe others would be willing to, as
well.