James, I agree with you concern, and as someone else said the devil is in the details, you points are something that would need to be looked at if enough people though we should move forward and look at an idea like this, which I think we should, but not sure if enough traffic to start down that road yet. If we do though, this is the kind of input we'd need. -jim On Sat, Apr 3, 2010 at 5:08 AM, James Hess <mysidia@gmail.com> wrote:
On Fri, Apr 2, 2010 at 9:17 PM, jim deleskie <deleskie@gmail.com> wrote:
not, but I've been asking people last few months why we don't just do something like this. don't even need to get rid of BGP, just add some [snip] On Fri, Apr 2, 2010 at 11:13 PM, George Bonser <gbonser@seven.com> wrote: [snip]>> and there ya go. Oh, and probably create an AA RR in DNS that is in
ASN:x.x.x.x format. Increase the MTU a little and whammo! There ya go!
It's a good idea. But, it should be noted the 'end result' is not the only thing that matters, in regards to internet protocol, the transition mechanism you need to change and convince the community to change from using an old protocol and old methods to using a new protocol and new practices is almost everything --- stakeholders want no disruption to the stability, or end-to-end connectivity of the internet at any point in time -- if every network must update software, even in the same decade as each others' networks, the protocol change may be as good as dead, due to the relative infrequency of large providers updating equipment.
The lack of a good well-thought-out transition mechanism can in effect be a show-stopper for any proposed change to widely-deployed existing protocol.
IPv6 has 'dual stack'. It doesn't suffer the 1st problem, but its transition burden _still_ prevents universal IPv6 connectivity'. ASN routing would probably have a similar fate, unless someone came up with a bulletproof easy-as-pie transition mechanism (something preferably better than dual stack).
So, how does a HTTP client indicate in the IP packet, the destination ASN obtained from looking up the value of this AA record? And how does that packet get to the web server at another provider, when the user's ISP or their ISP's upstream transit provider is not "ASN-routing-ready" yet.........
Or do you suggest an internet flag day?
Also, the socket peer of every IP transaction needs to know the source ASN, that means if you modify IP packets to add a 'destination ASN field', you also need a 'source ASN' field.
Else there will be no way for the server to send return traffic with full IP information, or even complete TCP connection handshake reliably, especially in multi-homed scenarios.
Another result is if either connection endpoint does not know about the new 'ASN packet labelling', they will be unable to properly label their return traffic (particularly in the case of multi-homed networks)... resulting in lack of ability to connect to each other, as the return traffic goes somewhere other than where expected
ASN routing would also have some interesting implications for multi-homing in general. Introduces some potentially troubling scenarios where a malicious actor might find some advantage in the ability to force the ASN destination of arbitrary spoofed packets to something unnatural.
-- -J