![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> From: Daniel Senie <dts at senie.com> > Phil Karn wrote: ... > > Being forced to tunnel not only increases the size of each packet, but > > also entails suboptimum routing and reliance on yet more network > > elements. I use the new Linux policy routing mechanisms to tunnel > > only those packets that have to be tunneled, which helps. But it would > > sure be nice if I didn't have to tunnel my outbound packets at all. > > Sorry. You're at the point where technology meets policy. Fact is, your > host identifier in the IP stack is the source IP address. Enforcing the > validity of that identifier has become necessary. The correct "solution" here is for Phil to communicate with his provider who presently does ingress filtering and notify them that he is sourcing packets from a particular set of source addresses (because of tunneling), and request they add these to the ingress filter list. I think we recognize this may be politically infeasable for many people to do, because tunneling is often used to circumvent administrative restrictions, but that really is a different degree of the problem. More generally: It seems to me that there has been a lot of wasted discussion on this list on this topic. I think it is a well-accepted conclusion within the provider community that ingress filtering is a necessary thing (perhaps a "necessary evil" to some, perhaps a "good" to others). In the vast majority of cases, the router CPU resource consumption issues are not relevent, either. If people within the IETF feel differently, they should realize that they are currently against recently-accepted-operational-practice. I don't think everyone who has to date spoken is aware of that. --jhawk
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.