legacy /8

Sat Apr 3 08:08:00 UTC 2010

On Fri, Apr 2, 2010 at 9:17 PM, jim deleskie <deleskie at 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 at 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