headers
S.P.Zeidler | 1 Feb 2009 13:33
Picon

Re: How to choose IPv6 addresses for customer links?

Thus wrote Jeroen Massar (jeroen <at> unfix.org):

> Martin List-Petersen wrote:
> > Martin Horneffer wrote:
> > [SNIP]
> >> Would that be a sensible addressing scheme? Or would a customer insist
> >> to get a completely independet /64 for the link addresses?
> > 
> > SixXS uses the approach commonly of assigning the link-addresses out of
> > a seperate /48 in the PoP. One /40 per PoP.

[some good technical points]

> Btw, you should have already done all of this when REQUESTING your
> prefix from RIPE. Numberplans are important to them, they should also be
> important to you.

I wouldn't exactly call it wrong to check ones plans against other
peoples experience every once in a while. Best practise does change over
time.

That said: an address plan I was involved with in the past asked for
leased lines to be numbered with a /64 from the specific PoPs /48,
expecting a router on the other side, and throwing a full /48 to the
customer. That makes routing easier if the customer has site resilient
links, too.

For datacenter connections it also fed /64 from the datacenter /48
and only gave /48 if the customer had a router installed. It's expected
that the customer would rarely exhaust a /64 in a flat network ;-P
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan White | 2 Feb 2009 04:51
Gravatar

Re: How to choose IPv6 addresses for customer links?

Steve Bertrand wrote:
> ...and, if you assign a /64 global between eBGP peers (as opposed to
> anything longer), BGP will automagically configure the next-hop to the
> link-local:
>
> B>* 2001:478:235::/48 [20/0] via fe80::d8ea:2f09, gif1, 06:07:43
>
> ...as opposed to this route, where a /128 global PtP is in place:
>
> B>* 2001:478:178::/48 [20/0] via 2001:4978:1:600::1, gif0, 06:08:14
>
> What I haven't tested, but plan on doing so, is whether my theory that
> moving the IPv6 peering address from one source interface to another
> will not disrupt this link-local next-hop.
>
> You (Dan) are going to like BGP. I have had much fortune finding people
> to help me out with it, particularly in the v6 context. If you ever need
> any help testing a setup in the global context, email me off-list. So
> long as it's low-bandwidth, I'll do anything I can to pass along
> knowledge I've gained from others (including sessions (non-transit),
> VMs, test routers etc). When I help others learn, I'm either reinforcing
> knowledge, or having to research the unknown.
>
>   

Thanks Steve, I appreciate all the pointers in the right direction.

What is the benefit of using BGP in a scenario like this (ethernet link 
to customer)? Would OSPF6 or RIPNG make more sense since shouldn't need 
to know their address?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ricardo Patara | 2 Feb 2009 19:56
Favicon

mtu

Hi,
Just wondering if some of you are using this technique to avoid  
problems from someone else accessing your website, for instance.

We have our site with ipv6 for a while now, and have received  
complaints and we had opportunity to face the same problem several  
times.

This happens when trying to access the site via a tunnel connection.  
The browser simply gives a timeout.
We think this is related to pmtu and sites filtering icmp6.

One of the solutions was to lower down the MTU at the site server.
The question is, if this is the solution you did in case you also  
faced this problem.
I tried to contact someone from google, but with no success.

I mention google as we always try ipv6.google.com when having this  
type of problem just to make sure there is nothing "completely" wrong  
the network setup.

thanks
--
   Ricardo Patara
Permalink | Reply | 13 comments |
headers
Erik Kline | 2 Feb 2009 19:59
Picon
Favicon

Re: mtu

You tried to contact us?  I must have missed that email, sorry.

We set the MTU to 1280 near the server.  We've not had any reported
MTU problems (knock on wood), to the best of my knowledge.

FWIW:  http://ispcolumn.isoc.org/2009-01/mtu6.html

2009/2/2 Ricardo Patara <patara <at> lacnic.net>:
> Hi,
> Just wondering if some of you are using this technique to avoid problems
> from someone else accessing your website, for instance.
>
> We have our site with ipv6 for a while now, and have received complaints and
> we had opportunity to face the same problem several times.
>
> This happens when trying to access the site via a tunnel connection. The
> browser simply gives a timeout.
> We think this is related to pmtu and sites filtering icmp6.
>
> One of the solutions was to lower down the MTU at the site server.
> The question is, if this is the solution you did in case you also faced this
> problem.
> I tried to contact someone from google, but with no success.
>
> I mention google as we always try ipv6.google.com when having this type of
> problem just to make sure there is nothing "completely" wrong the network
> setup.
>
> thanks
> --
(Continue reading)

Permalink | Reply | 12 comments |
headers
Ricardo Patara | 2 Feb 2009 22:06
Favicon

Re: mtu

Hello Erik,
Actually I tried to send an email to point of contact associated with  
the IP block :)
Then I search for some google folks email address with no success.  
Thanks for your promptly answer and attention on this.

In our case, in order to test if the MTU was the problem, we lowered  
it to 1480. But maybe it should be something around the number you  
mentioned.

Just for curiosity, did google tried to contact upstream providers or  
peering to find out if there was any icmp6 filtering in some of the  
paths?

thanks again.
--
   Ricardo Patara

Em 02/02/2009, às 16:59, Erik Kline escreveu:

> You tried to contact us?  I must have missed that email, sorry.
>
> We set the MTU to 1280 near the server.  We've not had any reported
> MTU problems (knock on wood), to the best of my knowledge.
>
> FWIW:  http://ispcolumn.isoc.org/2009-01/mtu6.html
>
> 2009/2/2 Ricardo Patara <patara <at> lacnic.net>:
>> Hi,
>> Just wondering if some of you are using this technique to avoid
(Continue reading)

Permalink | Reply | 2 comments |
headers
Geoff Huston | 2 Feb 2009 22:13
Favicon

Re: mtu

I had found a problem with the RFC Editor web site that prompted me to
look at PMTU behavior and write the article that Erik references. The
somewhat annoying aspect of this problem is that both the server and the
client  can be fully IPv6 "compliant" and doing absolutely nothing wrong
IPv6-wise, and still the client can get a white screen "hang".

What I find (as described in that article) was an initial TCP  
handshake with a
MSS of 1440 was being used, while the true path MTU was 1480 bytes,
or a TCP MSS of 1420. What I also found was that a change in end-to-end
path resolved the issue for me.

It seems that the most pragmatic advice is to use a lower-than-1500 MTU
from the outset for IPv6 servers. More details of what I found are at
http://ispcolumn.isoc.org/2009-01/mtu6.html

Given that the IPv6 spec requires all network elements to cope with a
1280 octet IPv6 packet without fragmentation Google's approach here
appears to be a "safe" one in terms of maximizing the prospects of a
successful connection. (www.ripe.net uses a similar reduced IPv6 MTU  
size, as does
www.apnic.net - I have not done any exhaustive survey here, but the  
problems
with the original rfc-editor server prompted me to look around a bit  
to see what
others did with their initial MTU.

On 03/02/2009, at 5:59 AM, Erik Kline wrote:

> You tried to contact us?  I must have missed that email, sorry.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Geoff Huston | 2 Feb 2009 22:19
Favicon

Re: mtu

1480 still appears to be a little too high if you want to be  
conservative. A teredo packet requires a 40 octet header, not 20  
becuase of the UDP packet.

Google offer an initial TCP mss of 1212 (which corresponds to an IPv6  
packet of 1272 octects - I'm not sure why they left 'headroom' of 8  
octets here - maybe some TCP option? Or allowing for an MPLS header?  
Or ...?

I've seen 1300 octets and 1400 octets being used.

but I'd offer the view that 1480 is pushing it close.

But perhaps there is another way of looking at this. Ricardo, why do  
you want to keep the MTU as large as you can? What issues do you think  
you will encounter for your web pages with a MTU of, say, 1300 octets,  
as compared to using 1480 octets?

  Geoff

On 03/02/2009, at 8:06 AM, Ricardo Patara wrote:

> Hello Erik,
> Actually I tried to send an email to point of contact associated  
> with the IP block :)
> Then I search for some google folks email address with no success.  
> Thanks for your promptly answer and attention on this.
>
> In our case, in order to test if the MTU was the problem, we lowered  
> it to 1480. But maybe it should be something around the number you
(Continue reading)

Permalink | Reply | 1 comment |
headers
Erik Kline | 2 Feb 2009 22:43
Picon
Favicon

Re: mtu

Ricardo,

Without being too explicit, let me just toss out ~4 categories of IPv6
brokenness we've seen in various network devices/scenarios:

(1)  Just no IPv6 implementation whatsoever

Pretty self-explanatory.  (My mom's home gateway falls into this
category.  Poor mom.)

(2) No or low quality or quantity of testing

Sometimes devices/code will actually have basically working IPv6
implementations but because of various constraints they have not had
sufficient real world testing.  If you're lucky you find these in your
testing sandbox.  Otherwise you probably only see the brokenness when
live traffic starts to pass through it.

(3) IPv6 != IPv4 with bigger addresses

This is particularly annoying.  Some implementations fail to notice
the subtle differences, like that Path MTU is required to work, or you
might have to (gasp!) process an IPv6 extension header, etc.  Some
implementations appear to understand that these differences exist but
don't implement them properly anyway.  These could fall in category
#2, so maybe this is really #2.5 in stead of #3.

(4) Misconfiguration

This is the category to which I think folks refer most often, namely
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernhard Schmidt | 3 Feb 2009 00:13
Picon

Re: mtu

On Tue, Feb 03, 2009 at 08:13:04AM +1100, Geoff Huston wrote:

Hello Geoff,

> It seems that the most pragmatic advice is to use a lower-than-1500 MTU
> from the outset for IPv6 servers. More details of what I found are at
> http://ispcolumn.isoc.org/2009-01/mtu6.html

Great summary, thanks a lot for this excellent article!

However, I cannot agree with your conclusion. On the one hand we see a
lot of people, especially in the research networks lobbying for networks
that are transparent for 4470 byte or ~9000 byte frames to reduce
overhead and increase (host) throughput with >>GE rates, and on the
other hand we cannot even get 1500 byte reliably and propose to set the
MTU of servers (all servers?) to a lower value? That can't be right.

We need to rat out those issues before it's too late. We have been
running our webservers (http://www.lrz.de, granted it's not really high
profile) v6-enabled with MTU 1500 for three years now, same for MX and
other services. We have some thousand clients all running on MTU 1500
links (and thus sending out MSS 1440 and relying on IPv6 pMTU discovery)
and have not heard complaints. If you are repeatedly having issues chances
are high that the problem is close to your own network, which might make
debugging and contacting the appropriate parties a bit easier.

The most common issues are IPv6 tunnels on interprovider links. Most
implementations (including Cisco and Juniper) set the IPv6 MTU of the
tunnel to the IPv4 MTU (to the tunnel destination) minus 20/24 bytes of
overhead. Which is a good default when you have the standard 1500 byte
(Continue reading)

Permalink | Reply | 7 comments |
headers
Daniel Roesen | 3 Feb 2009 00:47
Picon

Re: mtu

On Tue, Feb 03, 2009 at 12:13:55AM +0100, Bernhard Schmidt wrote:
> The most common issues are IPv6 tunnels on interprovider links.

Indeed, this is in line with my observations over the years.

> Most implementations (including Cisco and Juniper) set the IPv6 MTU of the
> tunnel to the IPv4 MTU (to the tunnel destination) minus 20/24 bytes of
> overhead.

Cisco IOS and Juniper JUNOS derrive the tunnel payload MTU from the
physical egress interface MTU the tunnel traverses over at any given
moment in time.

So it's best practise to always nail your tunnel MTU to the proper value
according to what you can guarrantee between the tunnel end points.

For IOS:

interface Tunnel1
 tunnel mode gre ip (default)
 ipv6 mtu 1476
interface Tunnel2
 tunnel mode ipv6ip
 ipv6 mtu 1480

For JUNOS:

interfaces {
    // GRE
    gr-0/0/0 {
(Continue reading)

Permalink | Reply | 1 comment |

Gmane