Scott Leibrand wrote: > Templin, Fred L wrote: >>> Which won't work, as ULA-C's are not in the routing tables, they >>> won't pass >>> uRPF checks and thus those packets of yours will get dropped to the >>> floor. >>> >>> When you got gear you are going to attach to the internet request a >>> PI or a >>> PA block and use a global unicast address. >> >> Which Internet? The existing IPv4 one, or a future IPv6 one?
That common thing that is commonly present in ISP tables. Now if ULA-C becomes part of that, then it is not 'local' anymore of course and we just have another form of PI. > Or, to ask the question another way, does it make sense to use uRPF to > drop packets sourced from ULA-C blocks? I refer you to BCP38 for a LOT of reasons on why to enable uRPF checks. One of those is the most common one: spoofing. > Our current implementations of loose uRPF are rooted in IPv4 justifications, > most notably that private IP space (RFC 1918) is non-unique, so we have no > idea where the packet came from, so we might as well drop it. And do you have any idea at all where ULA-C packets come from? Can you send return packets to them? Remember, that ULA addresses should not be present at all on that generic thing that people call the Internet. Or is spoofing again very happily allowed. Also please take into consideration the recent quibble over RH0. Networks which do proper uRPF checks didn't have any problems with these packets as those packets would never be able to pingpong on those networks simply because of a wrong source address. > I'm not sure that applies in > the IPv6 world, where an ICMP packet can be sourced from ULA-C space or > non-routed PI space and can have perfectly valid DNS and whois > information associated with its source address. Since when do routers look in DNS and whois? If they would do that we would have id/loc, now that would be great. Scott Leibrand wrote: >> Leo Vegoda wrote: >> Is this not already possible with a /48 PI assignment from ARIN? > > Yes, but only if you "qualify for an IPv4 assignment or allocation from > ARIN under the IPv4 policy currently in effect." That currently means > you must either be a large network (qualifying for a /20), or you must > be large enough to run BGP, be multi-homed, and be large enough to > justify a /22. Then change the RIR policy, don't go invent some strange address type that will only cause problems in the end and will just be a surrogate PI space. RIR's should be giving out address space on the justification of NEED by the requesting organization, not by the need to control routing entries because some ISP's are scared of having to upgrade their routers. If that latter group is scared, filter out the PI blocks and everything you don't want to see and let those folks pay you for a slot in your routing tables. Anything that is going to be connected one way or the other today, tomorrow or possibly somewhere in the future to that that called 'the Internet' aka the stuff using global unicast space should steer far and clear from ULA. Greets, Jeroen
signature.asc
Description: OpenPGP digital signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
