[124649] in North American Network Operators' Group
Re: legacy /8
daemon@ATHENA.MIT.EDU (jim deleskie)
Sat Apr 3 09:58:40 2010
In-Reply-To: <h2i6eb799ab1004030108te9d3b65evf76d1d852c38d4e8@mail.gmail.com>
Date: Sat, 3 Apr 2010 10:57:59 -0300
From: jim deleskie <deleskie@gmail.com>
To: James Hess <mysidia@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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. =A0Increase the MTU a little and whammo! =A0There y=
a go!
>
> It's a good idea. =A0 =A0But, it should be noted the =A0'end result' =A0 =
=A0is
> not the only thing that matters, =A0in regards to internet protocol,
> the =A0 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 =A0is almost everything ---
> stakeholders want no disruption to the stability, or end-to-end
> connectivity of the internet =A0at any point in time -- =A0if every
> network must update software, =A0even in the same decade as each others'
> networks, =A0the =A0protocol change may be as good as dead, =A0 due to th=
e
> relative infrequency of large providers updating equipment.
>
> The lack of a good =A0well-thought-out transition mechanism can in
> effect be a show-stopper =A0for any proposed change to widely-deployed
> existing protocol.
>
>
> IPv6 =A0has 'dual stack'. =A0 =A0It =A0doesn't suffer the 1st problem, bu=
t
> its transition burden _still_ =A0 prevents =A0universal IPv6
> connectivity'. =A0 =A0 ASN routing would probably have a similar fate,
> unless someone came up with a bulletproof easy-as-pie transition
> mechanism =A0(something preferably better than dual stack).
>
>
>
> So, =A0how does a HTTP client indicate in the IP packet, =A0the
> destination ASN =A0obtained from looking up the value of this AA record?
> =A0 =A0And how does that packet get to the web server =A0at another
> provider, =A0when the user's ISP or their ISP's =A0upstream transit
> provider is not =A0"ASN-routing-ready" yet.........
>
> Or do you suggest an internet flag day?
>
> Also, =A0the socket peer of every IP transaction needs to know the
> source ASN, =A0that means if you modify IP packets to add a
> 'destination ASN field', =A0you also need a 'source ASN' =A0field.
>
> Else there will be no way for the server to send return traffic with
> full IP information, or even complete TCP connection handshake
> reliably, =A0especially =A0in =A0multi-homed scenarios.
>
> Another result is if either connection endpoint =A0does not know about
> the new 'ASN packet labelling', =A0 they =A0will =A0be =A0unable to prope=
rly
> label their return traffic =A0 (particularly in the case of =A0multi-home=
d
> networks)... =A0resulting in lack of ability to connect to each other,
> as the return traffic =A0goes somewhere other than where expected
>
> ASN routing would also have some interesting =A0implications for
> multi-homing in general. =A0 =A0Introduces some potentially troubling
> scenarios where a malicious actor might find some advantage in the
> ability to force the ASN destination of arbitrary spoofed packets =A0 to
> something unnatural.
>
>
> --
> -J
>
