private peering

kasperd

Founder, Netiter ApS
Hero Member

Posts: 677

Re: private peering

« Reply #15 on: June 08, 2012, 05:39:18 pm »

Quote from: broquea on June 08, 2012, 05:23:45 pm

If 6to4 and teredo relays are letting you source HE.NET space and traverse them and returning back down your HE.NET tunnel, THEN THOSE RELAYS ARE IMPROPERLY CONFIGURED.

I believe you are mistaken. As far as I am aware it is perfectly valid according to the standards to announce 2002::/16 and 2001::/32 and relay packets without knowing which source addresses packets will be arriving from. If you believe otherwise, please point to a relevant RFC supporting it.


	Logged

broquea

Senior Network Engineer, SEVEN Networks (AS19733)
Hero Member

Posts: 1371

Re: private peering

« Reply #16 on: June 08, 2012, 05:44:48 pm »

http://tools.ietf.org/html/rfc3704 comes to mind as well as BCP38. Swap out IPv4 for IPv6 regarding this convo.


	Logged

kasperd

Founder, Netiter ApS
Hero Member

Posts: 677

Re: private peering

« Reply #17 on: June 08, 2012, 06:10:00 pm »

I didn't find any mention of 6to4 or Teredo relays in those documents.


	Logged

broquea

Senior Network Engineer, SEVEN Networks (AS19733)
Hero Member

Posts: 1371

Re: private peering

« Reply #18 on: June 08, 2012, 06:40:47 pm »

If you think your asymmetric routing is correct, then when your HE.NET tunnel is down, your routing is broken even more so than just those relays violating the RFC and BCP for proper routing of address space. You want something 6to4 or teredo specific, but this isn't about those particular tunneling protocols themselves, it's about the actual relay router processing the src/dst packets, and not deciding "Hey, I only handle 2002::/16 via this interface, this 2001:470::/32 shouldn't be accepted inbound from it, only 2002::/16."

So I'll put it to you then, show the RFC/BCP that specifically states that either the 6to4 or teredo PROTOCOL calls for an exception and allows the relays/routers to accept packets from any and all source address and fling them out into the internet. I already provided the RFC/BCP for routing policy that clearly explains why you don't accept any IPv4/6 address as source on an interface configured for a specific range.


« Last Edit: June 08, 2012, 08:09:44 pm by broquea »	Logged

mtindle

Administrator
Newbie

Posts: 25

Re: private peering

« Reply #19 on: June 08, 2012, 08:21:31 pm »

Generally we do not want the address space handed out by the tunnel broker to be used in the manner described by the OP. We do appreciate him asking us ahead of time and checking with us since it's an unusual requested use of the address space.

As a rule of thumb, the space handed out is meant to be used for a single network as a stub. When more complicated routing gets introduced, we strongly suggest that the networks involved speak to their RIR to get a delegation directly to them to prevent a lot of trouble down the road. We will even happily setup a BGP session and provide service for their new delegation if they contact ipv6@he.net. This is the preferred method.

For the Teredo / 6to4 discussion; RPF is meant to prevent abuse. While it's perfectly possible to accept traffic from a source "interface" that does not have a return path, in practice it's not a wise thing to do. Our use of RPF on those servers is a direct result of observed abusive traffic.


	Logged

mtindle

Administrator
Newbie

Posts: 25

Re: private peering

« Reply #20 on: June 08, 2012, 08:36:04 pm »

Also like to point out that Teredo and 6to4 are meant to be "last chance" connectivity for IPv6. All up to date OSes are configured to use everything else possible first before attempting connectivity on a 6to4 or Teredo IP. Unless the client is misconfigured or (more likely in our observations) maliciously configured, it should never be sending those packets to a relay if it has a normal globally routable IPv6 address as well.


	Logged

kasperd

Founder, Netiter ApS
Hero Member

Posts: 677

Re: private peering

« Reply #21 on: June 09, 2012, 03:33:23 am »

Quote from: broquea on June 08, 2012, 06:40:47 pm

it's about the actual relay router processing the src/dst packets, and not deciding "Hey, I only handle 2002::/16 via this interface, this 2001:470::/32 shouldn't be accepted inbound from it, only 2002::/16."

Are you talking about the source or the destination address?

Normal packets going through a 6to4 relay router has either the source address being a 6to4 address or the destination address, but never both. Routing between 6to4 and non-6to4 hosts is inherently asymmetric. Even if all the relays would route traffic in both directions it is still unlikely that traffic would go through the same relay in both directions, and it is entirely plausible that a relay that would otherwise have routed traffic in both directions just doesn't get to route traffic in more than one direction because it all flows a different way in the other direction.

A relay router can advertise either 2002::/16 or 192.88.99.1/24 or both, and how far the advertisements propagate is a matter of policies. They can be for a single LAN in which case a routing protocol may not even be necessary, or they can be propagated through BGP to the entire world.

When discussing by which rules a 6to4 relay operates we need to be specific about which direction of packets we are talking about, as they are separate issues handled by two different routers. What I am talking about is only the case of a 6in4 router having built in a 6to4 relay responsible for one stub network. Regardless of whether the router has any 6to4 relay capabilities or not, packets are routed to this router in the same way. In the end it is just a question of which source and destination IPv4 address it puts on the protocol 41 packets it is sending.

There may be filtering to ensure that the source IPv6 address is valid for the interface it arrived on. That part is already taken care of, what I am talking about is how the router routes the packets when it has already ensured the source address is valid. The source address may be a 6to4 address, but those packets are completely outside the scope of the terms of usage for the HE tunnel, assuming that they don't go through the tunnel to HE. The source address may be a public IPv6 address assigned by somebody other than HE, those are also outside the scope of the terms, again assuming they don't go through that tunnel.

What is left to discuss is only packets from the LAN where the source IPv6 address is in the range assigned by HE, and the router has already established that the source address is valid. The default route is obviously the one going down the tunnel. The question is, are the terms supposed to forbid having any more specific routes available on this router? And in this case specifically the 2002::/16 route, which a 6to4 relay would have.

If the router does act as 6to4 relay router for the stub network, then packets with destination address in 2002::/16 won't go to HE, rather they will go directly to the IPv4 address corresponding to the destination IPv4 address. And there is really no doubt about where a relay router is supposed to send the packets. The only question is whether HE users are allowed to have a 6to4 relay configured to service their own stub network. I know of multiple HE users, who do.

I think this is not at all what you were talking about. Your statement sounds like something that something which was meant for ingress filtering, while in fact the question was about the routing that happens after any ingress filtering has been applied.

Quote from: mtindle on June 08, 2012, 08:36:04 pm

Avoiding 6to4, yes many systems do. Avoiding Teredo, not so much. 6to4 tends to be more reliable than Teredo, yet systems seem to prefer using Teredo rather than 6to4. Also in case somebody had the crazy idea of running a server on a Teredo address clients given the choice between using their own native IPv6 address or their own Teredo address will tend to use the Teredo address when connecting to said server. That in spite of the fact that Teredo to Teredo communication is what Teredo is worst at doing.


	Logged

broquea

Senior Network Engineer, SEVEN Networks (AS19733)
Hero Member

Posts: 1371

Re: private peering

« Reply #22 on: June 09, 2012, 10:04:51 am »

Quote

Are you talking about the source or the destination address?

I was pretty clear in explaining that this was a matter of IPv6 source addresses being transported over the incorrect path/interface:

Quote

The tunnel-server has RPF upstream of it and will not let improperly sourced IPs get past...If 6to4 and teredo relays are letting you source HE.NET space and traverse them and returning back down your HE.NET tunnel [then the relays are misconfigured]

Quote

Giant wall of text that appears to not be relevant to you stating that 6to4/teredo relays should accept traffic sourced from your HE address space:

Quote

As far as I am aware it is perfectly valid according to the standards to announce 2002::/16 and 2001::/32 and relay packets without knowing which source addresses packets will be arriving from.

BGP announcements are irrelevant to the relay absolutely knowing that on its 6to4 interface, source IPv6 address packets should be from 2002::/16. The RFC/BCP I pointed out is about making certain that there is a proper routing policy in place to stop improperly sourced IPv6 address packets from being retransmitted by the relay.

Now, you had described a setup using HE tunnel + address space and using that tunnel for default route, and then configuring a specific 6to4 route, and a specific teredo route, and that you posed a question about violating tos/aup. My point was that it isn't a tos/aup violation issue but rather neither the 6to4 or teredo relay should be configured to allow that HE IPv6 address sourced packet any father than having received it over either the 6to4 or teredo interface. It should be discarded right there. That relay isn't getting a 6to4 or teredo IPv6 address sourced packet.

Quote

There may be filtering to ensure that the source IPv6 address is valid for the interface it arrived on. That part is already taken care of

There should be, but when you talked about you sourcing from HE IPv6 address space and sending out along your specific 6to4 route and that being valid, you are contradicting yourself.

Quote

The question is, are the terms supposed to forbid having any more specific routes available on this router? And in this case specifically the 2002::/16 route, which a 6to4 relay would have.

The terms absolutely won't forbid you from configuring specific routes to remote destinations, that is silly, no one would expect that. However if you are going to communicate with 6to4 hosts from your HE IPv6 address space, the interface that traffic should go out is your HE tunnel, not a 6to4 interface or static route to ::192.88.99.1 configured on the router (because that relay should be filtering IPv6 source addresses on its 6to4 interface, my entire point).

Quote

...the question was about the routing that happens after any ingress filtering has been applied.

You source a packet from an address in 2001:470::/32 destined for something in 2002::/16 and send it out to the 6to4 relay via the specific 6to4 route you said you created --> relay gets the packet, strips the encapsulation (assuming your static route was to ::192.88.99.1), sees that it isn't sourced from 2002::/16 and applies ingress filtering --> this is what happens after that ingress filtering: nothing, packet discarded, wasn't sourced from 2002::/16.


« Last Edit: June 09, 2012, 10:41:21 am by broquea »	Logged

kasperd

Founder, Netiter ApS
Hero Member

Posts: 677

Re: private peering

« Reply #23 on: June 09, 2012, 11:54:31 am »

Quote from: broquea on June 09, 2012, 10:04:51 am

BGP announcements are irrelevant

Agreed. In my case there wouldn't even be any BGP announcements.

Quote from: broquea on June 09, 2012, 10:04:51 am

the relay absolutely knowing that on its 6to4 interface, source IPv6 address packets should be from 2002::/16.

None of what I wrote was concerned with such packets. You keep talking about something else than me. I don't know how to explain that I am talking about packets going in the other direction. I have explained that a few different ways already, but I don't seem to be getting that point through.

Quote from: broquea on June 09, 2012, 10:04:51 am

The RFC/BCP I pointed out is about making certain that there is a proper routing policy in place to stop improperly sourced IPv6 address packets from being retransmitted by the relay.

By now you have convinced me that the document is not relevant to what I was asking about.

Quote from: broquea on June 09, 2012, 10:04:51 am

you talked about you sourcing from HE IPv6 address space and sending out along your specific 6to4 route and that being valid, you are contradicting yourself.

No. You are making some incorrect assumptions about what I am trying to say, and then say I am contradicting myself, once I say something different from what you assumed.

Packet in question is sent from an HE IPv6 address to a 6to4 address. There is nothing in the terms that forbids using an HE IPv6 address from communicating with 6to4 addresses. Now the question is how that packet gets routed to the destination. The router will check the source address and find that it arrived from the LAN and has a source address within the range assigned by HE to this network, thus the source address is valid.

Next the router checks the destination address of the packet against its routing table, and in this case match a route to 2002::/16, which causes the router to act as 6to4 relay and extract the IPv4 address from the destination address and send the IPv6 packet to that IPv4 address.

Quote from: broquea on June 09, 2012, 10:04:51 am

The terms absolutely won't forbid you from configuring specific routes to remote destinations, that is silly, no one would expect that.

I was expecting this to be permitted by the terms. And I was considering this to be obvious enough that I shouldn't even have to read the terms to know if it is permitted. However I did ask, and you said there was supposed to be filters preventing it.

Quote from: broquea on June 09, 2012, 10:04:51 am

However if you are going to communicate with 6to4 hosts from your HE IPv6 address space, the interface that traffic should go out is your HE tunnel, not a 6to4 interface or static route to ::192.88.99.1 configured on the router (because that relay should be filtering IPv6 source addresses on its 6to4 interface, my entire point).

Sending such packets to 192.88.99.1 would be pointless. Sending such packets through the tunnel is what is most routers would do. However there is another option, which is for the router to send it directly to the IPv4 address extracted from the destination IPv6 address. I believe such functionality is standard in some routers, at least I have seen multiple HE users with a router, which would behave like that.

Quote from: broquea on June 09, 2012, 10:04:51 am

assuming your static route was to ::192.88.99.1

That assumption is incorrect. I don't know what would happen to the packet if I did send it like that. Rather the router would either be able to extract the IPv4 address of the final destination and send it directly there, which is what a 6to4 relay router will do with such a packet, or I could route it to another node that I control (using 6in4 or native connectivity) and have that node figure out the destination IPv4 address.


	Logged

broquea

Senior Network Engineer, SEVEN Networks (AS19733)
Hero Member

Posts: 1371

Re: private peering

« Reply #24 on: June 09, 2012, 12:54:05 pm »

Quote

Next the router checks the destination address of the packet against its routing table, and in this case match a route to 2002::/16, which causes the router to act as 6to4 relay and extract the IPv4 address from the destination address and send the IPv6 packet to that IPv4 address.

No, sorry, a router doesn't just decide to suddenly become a 6to4 relay. You either have specifically configured a router to be a 6to4 relay, or it routes the packets to the nearest node announcing 2002::/16 over native IPv6. Having deployed actual production 6to4/teredo relays used by folks everywhere, I can promise you nothing just magically happens on the router. It needs to be configured to perform the task.

It would be awesome if all this started off with a less vague notion of "HE tunnel + 6to4 specific route + teredo specific route", and had actual example routing statements and configurations. I think the convo would have ended like 9 posts ago


« Last Edit: June 09, 2012, 12:58:23 pm by broquea »	Logged

kasperd

Founder, Netiter ApS
Hero Member

Posts: 677

Re: private peering

« Reply #25 on: June 09, 2012, 01:56:29 pm »

Quote from: broquea on June 09, 2012, 12:54:05 pm

No, sorry, a router doesn't just decide to suddenly become a 6to4 relay. You either have specifically configured a router to be a 6to4 relay

For a 6in4 endpoint it is a trivial task to act as 6to4 relay for any packets it would have routed through the tunnel. If the tunnel endpoint is implemented in C, it can be done with just two lines of code:

Code:

if ((IPv6_header[24] == 0x20)&&(IPv6_header[25] == 2)) {
memcpy(IPv4_header+16, IPv6_header+26, 4);
}

I don't know which products on the market would do so by default. I know of people who have used such a setup with HE, but I don't know whether those people had to configure it manually, or if they were using a router that did it automatically. I have send a message to one of those users asking how much work it was to set up the 6to4 relay.

Quote from: broquea on June 09, 2012, 12:54:05 pm

or it routes the packets to the nearest node announcing 2002::/16 over native IPv6.

But that doesn't have to mean through the tunnel to HE. There could be a 6to4 relay located on the same LAN. Though if you do want to have a 6to4 relay on the same LAN, it makes more sense to let the 6in4 gateway be the 6to4 relay as well.

Quote from: broquea on June 09, 2012, 12:54:05 pm

Having deployed actual production 6to4/teredo relays used by folks everywhere, I can promise you nothing just magically happens on the router. It needs to be configured to perform the task.

I don't think you have worked with every single kind of CPE equipment that HE users might use as their 6in4 tunnel endpoint, so I'd say you cannot know if there are some of them which will do so automatically when configured to work as 6in4 endpoint.

Of course a router that is not a 6in4 endpoint may not even have IPv4 connectivity, and obviously such a router shouldn't act as 6to4 relay automatically. But I can promise you, there are routers around that magically does things with 6in4 packets, which makes no sense. My ISP actually has one that under some circumstances will decapsulate the 6in4 packets I send to HE such that the packets will enter the IPv6 network in a different location from what was expected and take an entirely different route, which may never touch the HE network. Luckily this has never happened to the return traffic, otherwise the packets would have entered a routing loop on the way to me.

Quote from: broquea on June 09, 2012, 12:54:05 pm

It would be awesome if all this started off with a less vague notion of "HE tunnel + 6to4 specific route + teredo specific route", and had actual example routing statements and configurations.

I don't think it would have helped much to show you a configuration file for an IPv6 stack that you have never seen. Instead I explained exactly what it would do.

I said the route to 2002::/16 would send it to the appropriate IPv4 address. I thought everybody on this forum would know that means using the third through the sixth octet of the destination IPv6 address as the destination IPv4 address.

I also said the route to 2001::/32 would route the traffic to my own Teredo relay. That's just an instance of miredo configured to work as relay. I didn't think it was important to state that it is a miredo instance, but I can post the configuration for that if it is any help to the discussion.


	Logged

Pages: 1 [2]

« previous next »