Dual stack IPv6 for IPv4 depletion

joel jaeggli joelja at bogus.com
Fri Jul 17 04:45:22 UTC 2015


On 7/15/15 9:10 AM, John R. Levine wrote:
>>> It would be nice if it were possible to implement BCP 38 in IPv6,
>>> since this
>>> is the reason it isn't in IPv4.
>>
>> There isn't any technical reason that an organization can't fix its edge
>> so it doesn't urinate bad IPv6 traffic all over the Internet.
> 
> In IPv4 systems, the problem is (so I have been told by some largish
> ISPs) that a dual homed customer gets address ranges from ISPs A and B,
> and sends traffic with A addresses to the B interface.  The ISPs have no
> practical way to tell legit dual homed traffic from malicious,
> particularly when there is a chain of resellers in between.  If the ISP
> tells the customer to send the traffic over the right interface, the
> usual response is "if you don't want our business, I'm sure we can find
> another ISP that does."

Strict rpf has the super nice property that if you withdraw you prefix
from a peer, that peer blackholes traffic. there are all sorts of fun
cases like for example MLPE peering on exchange fabrics where you can't
just tag the prefix no export and send it to your neighbor, which means
it's all or nothing.

The exigent reality is that the less control customers have over their
own policy then the easier they are to filter. retail isp customers with
prefixes delegated by their provider, easy so when ISPS practice good
hygiene on their retail side, great.. some dude at an exchange point
direct adjacency or no, quite a bit harder.

> Like I said, it would be nice if ISPs could persuade their v6 customers
> to get their own PI space early on, because if they don't they'll have
> exactly the same problem.
> 
> R's,
> John
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 229 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150716/5f245670/attachment.sig>


More information about the NANOG mailing list