Mailing List Archive

On Wed, 2005-04-20 at 11:01 +0100, Cameron Gray wrote:
> OK,
>
> I'm starting to see MHAP as one giant leap backwards. It simply appears
> to be public -> public NAT for multi-homed /48s.

If you s/MHAP/shim6/ (MHAP proposal does not really exist any more) and
indeed that is what it is. Basically a double NAT with public, globally
unique, address space on both sides of the NAT, which takes care of the
problem with the current RFC1918+NAT problem, the biggest of which is
not the NAT it self but the non-uniqueness of the addresses. The double
NAT takes care that apps can still use the public address inside the
protocol, eg as with ftp or h323 and it won't be hurt by the shim.

> It doesn't help for
> example with DNS where you want multipath over x providers.

Most likely shim6 will depend on some sort of directory and this
directory will not be able to live easily inside a shim area.

Fun part is that people will most likely want rapid updates for their
shim6-mappings, at a certain point one will then simply have an overlay
BGP network with all the routes in it too. One can drop the ASPATH
partially then though, one only needs it to check for loops.

> Current best practise says only announce /32 to backbones (correct???).
> Wouldn't this prove simpler (granted a larger table) to allow up to /48s?

The only reason for 'allowing' upto /48's would be that if these would
be "PI IPv6 blocks" that they at least do not consume that much address
space. For the rest there is not a real reason for a /32 or a /48.

Most ISP's actually allow /48's to come through as can be verified
easily by looking at GRH.

Greets,
Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050420/93741bc9/attachment.bin

Jeroen Massar wrote:
> If you s/MHAP/shim6/ (MHAP proposal does not really exist any more) and
> indeed that is what it is. Basically a double NAT with public, globally
> unique, address space on both sides of the NAT, which takes care of the
> problem with the current RFC1918+NAT problem, the biggest of which is
> not the NAT it self but the non-uniqueness of the addresses. The double
> NAT takes care that apps can still use the public address inside the
> protocol, eg as with ftp or h323 and it won't be hurt by the shim.

OK, I wasn't looking at specific application compatibility yet, simply
loosing the Multi-Path benefits we have with the current IPv4 consensus.

> Most likely shim6 will depend on some sort of directory and this
> directory will not be able to live easily inside a shim area.
>
> Fun part is that people will most likely want rapid updates for their
> shim6-mappings, at a certain point one will then simply have an overlay
> BGP network with all the routes in it too. One can drop the ASPATH
> partially then though, one only needs it to check for loops.

Sorry, I don't follow the overlay part... SHIM6 with a directory would
cause a lookup dictating where each "real" address should be pointed
now, but as you say updates to this must be instant and automatic.

Who gets to run these, ICANN? RIPE/ARIN/APNIC/AFNIC, et al.? The ISPs
I'm worried about won't accept that kind of encroachment onto their
routing policy. The What-Ifs are pretty much endless if they are not in
control of that critical part of the new infrastructure.

I would see that the border for ASx would have to network xxxx::xxxx/48
both ranges, but only one would be accepted?!?

> The only reason for 'allowing' upto /48's would be that if these would
> be "PI IPv6 blocks" that they at least do not consume that much address
> space. For the rest there is not a real reason for a /32 or a /48.
>
> Most ISP's actually allow /48's to come through as can be verified
> easily by looking at GRH.

Example; I'm working with a small-mid sized hosting provider; not large
enough to even contemplate becoming an LIR for a /32 v6 assignment and
definately not going to issue 200 /48s in 2 years.

We've had UK6X deny announcement to the backbone as its longer than a
/32. As far as they are concerned either a) they must get a /32 and
flaunt RIPE NCC policies or b) be allowed to multi home on the /48 they
can get from one upstream. If neither of these options prove fruitful
they will simply ignore IPv6 because it's a step backwards.

If PI for IPv6 cannot be replicated takeup will be majorly hampered in
my opinion as many smaller ISPs will lose what they consider their
multihoming option.
--

Best regards,

Cameron Gray
Director, Netegral Limited
www.netegral.co.uk | cgray@netegral.co.uk
0871 277 NTGL (6845)

On Wed, 2005-04-20 at 11:41 +0100, Cameron Gray wrote:
> Jeroen Massar wrote:
> > If you s/MHAP/shim6/ (MHAP proposal does not really exist any more) and
> > indeed that is what it is. Basically a double NAT with public, globally
> > unique, address space on both sides of the NAT, which takes care of the
> > problem with the current RFC1918+NAT problem, the biggest of which is
> > not the NAT it self but the non-uniqueness of the addresses. The double
> > NAT takes care that apps can still use the public address inside the
> > protocol, eg as with ftp or h323 and it won't be hurt by the shim.
>
> OK, I wasn't looking at specific application compatibility yet, simply
> loosing the Multi-Path benefits we have with the current IPv4 consensus.

"Multi-Path benefits" ? You have multiple paths to your destination:

Just in case some wonder what shim6 is supposed to do:
8<------------------------------
shim6 idea
~~~~~~~~~~

Original: 2001:db8::1 -> 3ffe:ffff::1
[ shim6 translates it ]
On wire : 2002:a0a:a0a::1 -> 3ffe:ffff::1

Packet arrives at target as: 2002:a0a:a0a::1 -> 3ffe:ffff::1
But this box knows it is shim6 (extra header or whatever)
and translates it back:
[ shim6 translates it (back) ]
Received: 2001:db8::1 -> 3ffe:ffff::1

Thus the packet is 100% the same as when it was sent, does not matter if there are
IP's embedded etc...
------------------------------>8

The border router can also pick any of the other 'on the wire source
IP's', or in case of shim6, every other /48.

Basically, while on the wire you swap out the first /48 bits to the ones
of your upstream and that is it. For outgoing packets this is merely
done to allow the upstream to do source address filtering as they are
supposed to be doing.

> > Most likely shim6 will depend on some sort of directory and this
> > directory will not be able to live easily inside a shim area.
> >
> > Fun part is that people will most likely want rapid updates for their
> > shim6-mappings, at a certain point one will then simply have an overlay
> > BGP network with all the routes in it too. One can drop the ASPATH
> > partially then though, one only needs it to check for loops.
>
> Sorry, I don't follow the overlay part... SHIM6 with a directory would
> cause a lookup dictating where each "real" address should be pointed
> now, but as you say updates to this must be instant and automatic.
>
> Who gets to run these, ICANN? RIPE/ARIN/APNIC/AFNIC, et al.? The ISPs
> I'm worried about won't accept that kind of encroachment onto their
> routing policy. The What-Ifs are pretty much endless if they are not in
> control of that critical part of the new infrastructure.

What do any of those organizations have to do currently with BGP?

The RIR's give out address space, they do not impose any routing
restrictions. Filter is done by ISP's/transits etc, not by the RIR's.

> I would see that the border for ASx would have to network xxxx::xxxx/48
> both ranges, but only one would be accepted?!?

No, why should it? The 'globally unique address space' is behind the
borders of the multihomed network and as such the /48 is not globally
routed at all, though you can always leak it to friendly people.

> > The only reason for 'allowing' upto /48's would be that if these would
> > be "PI IPv6 blocks" that they at least do not consume that much address
> > space. For the rest there is not a real reason for a /32 or a /48.
> >
> > Most ISP's actually allow /48's to come through as can be verified
> > easily by looking at GRH.
>
> Example; I'm working with a small-mid sized hosting provider; not large
> enough to even contemplate becoming an LIR for a /32 v6 assignment and
> definately not going to issue 200 /48s in 2 years.
>
> We've had UK6X deny announcement to the backbone as its longer than a
> /32.

Give them more money to announce it. But since when did IX's become
transits? Or did they made a mistake when naming their organization?

> As far as they are concerned either a) they must get a /32 and
> flaunt RIPE NCC policies

If they are an ISP and providing address space to you and have a plan
for 200 others then this is not an issue at all with current policies.

> or b) be allowed to multi home on the /48 they
> can get from one upstream. If neither of these options prove fruitful
> they will simply ignore IPv6 because it's a step backwards.

UK6X is afaik an IX, not an ISP.

> If PI for IPv6 cannot be replicated takeup will be majorly hampered in
> my opinion as many smaller ISPs will lose what they consider their
> multihoming option.

Fun question I always have: how many seperate&redundant physical paths
do those 'multihomed' organizations have?

The only real reason for having your own /48, which IMHO is quite valid
is having it because of renumbering hassle as that is the real pain.

Btw isn't address policy discussion supposed to be going on on the RIPE
address-wg and ARIN ppml lists? :)

Greets,
Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050420/46b1ec9d/attachment.bin

> But since when did IX's become transits? Or did they made
> a mistake when naming their organization?

> UK6X is afaik an IX, not an ISP.

Those two kinds of entities are not always 100% distinct. An LIR IX provides some services that are usually provided by an ISP.

--
Jonathan Stevens
UK6x.com

On Wed, 2005-04-20 at 13:55 +0100, jonathan.2.stevens@bt.com wrote:
> > But since when did IX's become transits? Or did they made
> > a mistake when naming their organization?
>
> > UK6X is afaik an IX, not an ISP.
>
> Those two kinds of entities are not always 100% distinct.
> An LIR IX provides some services that are usually provided by an ISP.

Either you are an IX and you fall in RIPE land under RIPE-282.
Or you are a transit/ISP and you fall under RIPE-267.

Take your pick. As far as I read it now you are an ISP, not an IX.

Greets,
Jeroen

(PS: address-policy-wg@ripe.net anyone? :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050420/6add5ba5/attachment.bin

On Wed, 20 April 2005 15:05:34 +0200, Jeroen Massar wrote:
> Take your pick. As far as I read it now you are an ISP, not an IX.

why not both?

we connect to their switch network natively, all fine with
that, and we additionally peer with one connected party,
which is AS 1752, which happens to be run by the same ppl.

-ako

Jeroen Massar wrote:
>
> (PS: address-policy-wg@ripe.net anyone? :)
>

Well my original question was routing policy more than anything...

I don't see why seperate /48s can't have seperate origins in much the
same way that IPv4 works and IPv6 works for /32s.

Other than the large(r) routing table.

Is this the only reason?
--

Best regards,

Cameron Gray
Director, Netegral Limited
www.netegral.co.uk | cgray@netegral.co.uk
0871 277 NTGL (6845)

On Wed, 2005-04-20 at 14:07 +0100, Cameron Gray wrote:
> Jeroen Massar wrote:
> >
> > (PS: address-policy-wg@ripe.net anyone? :)
> >
>
> Well my original question was routing policy more than anything...
>
> I don't see why seperate /48s can't have seperate origins in much the
> same way that IPv4 works and IPv6 works for /32s.
>
> Other than the large(r) routing table.
>
> Is this the only reason?

Routing table is not a big problem here though.
We will run out of ASN's before that.

If every ASN would announce a prefix, there would be 60k prefixes in the
IPv6 table, which is not a lot. Would maybe be easier to just give every
ASN a prefix then too btw, saves on RIR work ;)

The problem here is that we will have to move to a 32bit ASN space.
Upgrade BGP etc (though there are tricks for this).

In any case, IMHO if an organization needs globally unique IPv6 address
space, they should be able to get one, but the RIR's should allocate
them from a single block (eg a /20).

ASN landrush will be there before there will be IPv6 address depletion.
But this is more a 'problem' of BGP using "only" a 16bit number.

Either way it goes there will at a certain point in time with the
current way of allocations be a long table which contains all the
prefixes that are available around this globe.

Greets,
Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050420/5fcc573c/attachment-0001.bin

On Wed, 2005-04-20 at 15:06 +0200, Alexander Koch wrote:
> On Wed, 20 April 2005 15:05:34 +0200, Jeroen Massar wrote:
> > Take your pick. As far as I read it now you are an ISP, not an IX.
>
> why not both?
>
> we connect to their switch network natively, all fine with
> that, and we additionally peer with one connected party,
> which is AS 1752, which happens to be run by the same ppl.

As they are the same people, why not use the space from the ISP for the
'services' of the IX then? And of course one could also use it for the
interconnect of the IX if you want.

Greets,
Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050420/3bdd55c7/attachment.bin

Cameron Gray wrote:
> Jeroen Massar wrote:
>
>>
>> (PS: address-policy-wg@ripe.net anyone? :)
>>
>
> Well my original question was routing policy more than anything...
>
> I don't see why seperate /48s can't have seperate origins in much the
> same way that IPv4 works and IPv6 works for /32s.
>
> Other than the large(r) routing table.
>
> Is this the only reason?

Bear in mind that each /32 is potentially 65536 /48 prefixes if allowed
to send all their /48's. People struggle enough already with only
~156000 prefixes in ipv4 land.

An idea might be to have a specific /32 prefix that the RIR's can
allocate/assign "PI" space from. Whether or not they will do this and
reasons for/against it is most likely covered by another mailing list.


Thanks,

--

Daniel Austin,
Managing Director,
Kewlio.net Limited.
<daniel@kewlio.net>

Daniel Austin wrote:
> Bear in mind that each /32 is potentially 65536 /48 prefixes if allowed
> to send all their /48's. People struggle enough already with only
> ~156000 prefixes in ipv4 land.

Agreed, but (in my mind, usual disclaimer) aggregation in IPv6 is far
easier?!!!!

Unlike now where 20% (at my last look, again disclaimer) of the prefixes
could be aggregated. Even with "PI" recipients it should only add 1 to
the table, not all the /64s (analoguous to ISPx announcing all the /24s
in a /19).

> An idea might be to have a specific /32 prefix that the RIR's can
> allocate/assign "PI" space from. Whether or not they will do this and
> reasons for/against it is most likely covered by another mailing list.

Agreed, except they (well RIPE certainly) have stated there will be no
PI space. Even LIRs that cannot plan to issue 200 /64s have to get
space from a LIR that can.

--

Best regards,

Cameron Gray
Director, Netegral Limited
www.netegral.co.uk | cgray@netegral.co.uk
0871 277 NTGL (6845)

On Wed, 2005-04-20 at 14:39 +0100, Cameron Gray wrote:
> Daniel Austin wrote:
> > Bear in mind that each /32 is potentially 65536 /48 prefixes if allowed
> > to send all their /48's. People struggle enough already with only
> > ~156000 prefixes in ipv4 land.

32bits * 156.000 = 4 992 000
128bits * 65.000 = 8 320 000 (not assuming private ASN's etc)

At least when you count the bits. Ask the routing vendors if they like
it or not ;)

Biggest question: what do you say to ASN applicant ~70.000 ?

> Agreed, but (in my mind, usual disclaimer) aggregation in IPv6 is far
> easier?!!!!
>
> Unlike now where 20% (at my last look, again disclaimer) of the prefixes
> could be aggregated. Even with "PI" recipients it should only add 1 to
> the table, not all the /64s (analoguous to ISPx announcing all the /24s
> in a /19).

Remember that the RIR's gave those organizations the blocks sized
per /19 and they still announce it per /24. Guess oh guess why and guess
what happens.

> > An idea might be to have a specific /32 prefix that the RIR's can
> > allocate/assign "PI" space from. Whether or not they will do this and
> > reasons for/against it is most likely covered by another mailing list.
>
> Agreed, except they (well RIPE certainly) have stated there will be no
> PI space. Even LIRs that cannot plan to issue 200 /64s have to get
> space from a LIR that can.

200 /48's. Also "RIPE" is the people and as RIPE NCC doesn't make the
rules for RIPE, what you say here is impossible.

If the RIPE membership (not the NCC who actually almost have no 'vote')
make a proposal and this proposal gets accepted by the RIPE membership
then this is what RIPE is going to do because their membership tells
them. Apparently there are either too many ISP's who want to keep the
ropes in their hands (which is what every big ISP wants to because they
need revenue) or there are not enough people who want IPv6-PI.

Greets,
Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050420/ba5d78be/attachment.bin

> If the RIPE membership (not the NCC who actually almost have no 'vote')
> make a proposal and this proposal gets accepted by the RIPE membership
> then this is what RIPE is going to do because their membership tells
> them. Apparently there are either too many ISP's who want to keep the
> ropes in their hands (which is what every big ISP wants to because they
> need revenue) or there are not enough people who want IPv6-PI.
>
> Greets,
> Jeroen

I disagree, I think that these policy decisions have come before many of
the ISPs have even considered branching into IPv6.

--

Best regards,

Cameron Gray
Director, Netegral Limited
www.netegral.co.uk | cgray@netegral.co.uk
0871 277 NTGL (6845)

Hi Jeroen,

El 20/04/2005, a las 12:29, Jeroen Massar escribi?:

> On Wed, 2005-04-20 at 11:01 +0100, Cameron Gray wrote:
>> OK,
>>
>> I'm starting to see MHAP as one giant leap backwards. It simply
>> appears
>> to be public -> public NAT for multi-homed /48s.
>
> If you s/MHAP/shim6/ (MHAP proposal does not really exist any more) and
> indeed that is what it is. Basically a double NAT with public, globally
> unique, address space on both sides of the NAT, which takes care of the
> problem with the current RFC1918+NAT problem, the biggest of which is
> not the NAT it self but the non-uniqueness of the addresses. The double
> NAT takes care that apps can still use the public address inside the
> protocol, eg as with ftp or h323 and it won't be hurt by the shim.
>

agree

>> It doesn't help for
>> example with DNS where you want multipath over x providers.
>
> Most likely shim6 will depend on some sort of directory and this
> directory will not be able to live easily inside a shim area.
>

i fail to see what directory are you talking about here...
I mean AFAIU, shim will use the DNS to obtain addresses, just as it is
done today, no changes to that, or are you thinking about other
directory service?

> Fun part is that people will most likely want rapid updates for their
> shim6-mappings, at a certain point one will then simply have an overlay
> BGP network with all the routes in it too. One can drop the ASPATH
> partially then though, one only needs it to check for loops.
>

I fail to understand what are considering here... The changes in the
locator set of a shim context will be done through the shim protocol
between the end nodes involved in the communication, right? so, what is
BGP and overlay come into this?

Regards, marcelo


>> Current best practise says only announce /32 to backbones
>> (correct???).
>> Wouldn't this prove simpler (granted a larger table) to allow up to
>> /48s?
>
> The only reason for 'allowing' upto /48's would be that if these would
> be "PI IPv6 blocks" that they at least do not consume that much address
> space. For the rest there is not a real reason for a /32 or a /48.
>
> Most ISP's actually allow /48's to come through as can be verified
> easily by looking at GRH.
>
> Greets,
> Jeroen
>

Hi,

Thus wrote Cameron Gray (cgray@netegral.co.uk):

> Current best practise says only announce /32 to backbones (correct???).
> Wouldn't this prove simpler (granted a larger table) to allow up to /48s?

While I'm in favour of a "sump" of PI /48 that also should be announcable
in BGP, I'd recomment to not allow any old /48 to be announced, because
that will make the users of aggregatable address space want to own and
keep the space in spite of change of provider, which will give all kinds of
hassles trying to get them to stop.

regards,
Petra Zeidler
--
(Not officially speaking for AS1273)

Hi,

On Wed, Apr 20, 2005 at 02:55:52PM +0100, Cameron Gray wrote:
> I disagree, I think that these policy decisions have come before many of
> the ISPs have even considered branching into IPv6.

You're more then welcome to voice your opinion on the RIPE address-policy
working group mailing list.

There is an ongoing discussion *right now* to abandon the 200-customer
rule, but unfortunately, none of the people that regularily complain about
the rule are there to shout "YES! DO AWAY WITH IT!" - instead the discussion
went into a big fight between the "everything must be liberated" and the
"but not in my routing table!" camps...

Gert Doering
-- NetMaster
--
Total number of prefixes smaller than registry allocations: 71007 (66629)

SpaceNet AG Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0
D- 80807 Muenchen Fax : +49-89-32356-234

On Wed, 2005-04-20 at 16:50 +0200, marcelo bagnulo braun wrote:

<SNIP>

> >> It doesn't help for
> >> example with DNS where you want multipath over x providers.
> >
> > Most likely shim6 will depend on some sort of directory and this
> > directory will not be able to live easily inside a shim area.
> >
>
> i fail to see what directory are you talking about here...
> I mean AFAIU, shim will use the DNS to obtain addresses, just as it is
> done today, no changes to that, or are you thinking about other
> directory service?

DNS can be seen as a 'directory of DNS labels'. Just like the phonebook
is one for telephone numbers, yellowpages for people etc.

It can be DNS, but it can also be something else. As such you will not
be able to multihome your directory server easily as then you will have
cyclic dependency. (Beth: "where is Anna?", "Ask Anna where Anna is")

> > Fun part is that people will most likely want rapid updates for their
> > shim6-mappings, at a certain point one will then simply have an overlay
> > BGP network with all the routes in it too. One can drop the ASPATH
> > partially then though, one only needs it to check for loops.
> >
>
> I fail to understand what are considering here... The changes in the
> locator set of a shim context will be done through the shim protocol
> between the end nodes involved in the communication, right? so, what is
> BGP and overlay come into this?

The shim protocol will be just like running automatic BGP between 2
peers. But I'll first have to see the proposal of such a protocol.
In the mean time I already a have a version of the shim which can be
feed using a userspace daemon which mappings it is supposed to have.
The source of the daemon is undetermined though but that is why it has
an open API.

overlay -> because you would get a 'core' network which does not see the
shim6 /48's, and this networks gets overlayed over the existing network.
(Which many people won't like and won't favor and thus won't accept)

Greets,
Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050420/2b7bbdd4/attachment-0001.bin

El 20/04/2005, a las 17:14, Jeroen Massar escribi?:

> On Wed, 2005-04-20 at 16:50 +0200, marcelo bagnulo braun wrote:
>
> <SNIP>
>
>>>> It doesn't help for
>>>> example with DNS where you want multipath over x providers.
>>>
>>> Most likely shim6 will depend on some sort of directory and this
>>> directory will not be able to live easily inside a shim area.
>>>
>>
>> i fail to see what directory are you talking about here...
>> I mean AFAIU, shim will use the DNS to obtain addresses, just as it is
>> done today, no changes to that, or are you thinking about other
>> directory service?
>
> DNS can be seen as a 'directory of DNS labels'. Just like the phonebook
> is one for telephone numbers, yellowpages for people etc.
>
> It can be DNS, but it can also be something else. As such you will not
> be able to multihome your directory server easily as then you will have
> cyclic dependency. (Beth: "where is Anna?", "Ask Anna where Anna is")
>

agree
but i guess that DNS servers won't be using shim to obtain multihoming
support, but they will use the DNS protocol redundancy features instead
(multiple records with the different addresses available for the
server) (besides, doesn't make much sense to run a 4 way handshake to
exchange a single packet DNS query i guess)

>>> Fun part is that people will most likely want rapid updates for their
>>> shim6-mappings, at a certain point one will then simply have an
>>> overlay
>>> BGP network with all the routes in it too. One can drop the ASPATH
>>> partially then though, one only needs it to check for loops.
>>>
>>
>> I fail to understand what are considering here... The changes in the
>> locator set of a shim context will be done through the shim protocol
>> between the end nodes involved in the communication, right? so, what
>> is
>> BGP and overlay come into this?
>
> The shim protocol will be just like running automatic BGP between 2
> peers.

that may be a bit of an overkill for a view :-)
I guess it will be much simpler than BGP, but who knows

> But I'll first have to see the proposal of such a protocol.
> In the mean time I already a have a version of the shim which can be
> feed using a userspace daemon which mappings it is supposed to have.
> The source of the daemon is undetermined though but that is why it has
> an open API.
>
> overlay -> because you would get a 'core' network which does not see
> the
> shim6 /48's, and this networks gets overlayed over the existing
> network.
> (Which many people won't like and won't favor and thus won't accept)
>

agree

regards, marcelo


> Greets,
> Jeroen
>

On Wed, 2005-04-20 at 17:31 +0200, marcelo bagnulo braun wrote:
> El 20/04/2005, a las 17:14, Jeroen Massar escribi?:

> agree
> but i guess that DNS servers won't be using shim to obtain multihoming
> support, but they will use the DNS protocol redundancy features instead
> (multiple records with the different addresses available for the
> server) (besides, doesn't make much sense to run a 4 way handshake to
> exchange a single packet DNS query i guess)

The whole goal of multihoming is being independent of upstream address
space isn't it ?

Scenario, we are example.com and have 2 upstreams, thus 2x /48 and those
are 2001:db8::/32 from the IPv6-Doc prefix and 3ffe:ffff::/48 out of the
6bone test/play/doc prefix. We have our example.com domain, where our
web&smtp&etc-server resides at our shim6'd addresses. We can't shim6 our
DNS/shim6-directory server because of cyclic redundancy, thus we have in
DNS:

ns1.example.com AAAA 2001:0db8::53
ns1.example.com AAAA 3ffe:ffff::53

It is 6/6/6 and major ISP's filter out 3ffe::/16. Thus one out of two
first-query attempts go into oblivion and that is only for contacting
DNS. When we want to update* the above we need to contact the registrar
etc. Fortunately for some domains there is a 5 minute or so time, but
then still you have cached entries etc.

If people would rely on DNS to be so quick, then they could also do that
for everything else, webservers etc.

Not even mentioning outsourced DNS servers, or having customers hardcode
the DNS servers, eg ns1.example.org AAAA 2001:0db8::53, CNAMEs are not
allowed and they love their own name.

Greets,
Jeroen

* = Can't we organize a 'kick the .org/.com/.net registrars' event so
that they will start accepting AAAA entries for NS's?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050420/23bcbd8d/attachment.bin

El 20/04/2005, a las 17:56, Jeroen Massar escribi?:

> On Wed, 2005-04-20 at 17:31 +0200, marcelo bagnulo braun wrote:
>> El 20/04/2005, a las 17:14, Jeroen Massar escribi?:
>
>> agree
>> but i guess that DNS servers won't be using shim to obtain multihoming
>> support, but they will use the DNS protocol redundancy features
>> instead
>> (multiple records with the different addresses available for the
>> server) (besides, doesn't make much sense to run a 4 way handshake to
>> exchange a single packet DNS query i guess)
>
> The whole goal of multihoming is being independent of upstream address
> space isn't it ?
>

not really, at least that is not what is included in the RFC 3582.
The goals of multihoming are basically redundancy and traffic
engineering mainly... (most of all redundancy w.r.t different types of
outages)

PI is a different issue, i guess


> Scenario, we are example.com and have 2 upstreams, thus 2x /48 and
> those
> are 2001:db8::/32 from the IPv6-Doc prefix and 3ffe:ffff::/48 out of
> the
> 6bone test/play/doc prefix. We have our example.com domain, where our
> web&smtp&etc-server resides at our shim6'd addresses.

sorry, what is a shim6 address?
As i understand it, any prefix can be used in shim...

> We can't shim6 our
> DNS/shim6-directory server because of cyclic redundancy, thus we have
> in
> DNS:
>
> ns1.example.com AAAA 2001:0db8::53
> ns1.example.com AAAA 3ffe:ffff::53
>

agree
but i fail to see the reasoning below... perhaps is that we do not have
the same idea about what is the shim, perhaps?

regards, marcelo

> It is 6/6/6 and major ISP's filter out 3ffe::/16. Thus one out of two
> first-query attempts go into oblivion and that is only for contacting
> DNS. When we want to update* the above we need to contact the registrar
> etc. Fortunately for some domains there is a 5 minute or so time, but
> then still you have cached entries etc.
>
> If people would rely on DNS to be so quick, then they could also do
> that
> for everything else, webservers etc.
>
> Not even mentioning outsourced DNS servers, or having customers
> hardcode
> the DNS servers, eg ns1.example.org AAAA 2001:0db8::53, CNAMEs are not
> allowed and they love their own name.
>
> Greets,
> Jeroen
>
> * = Can't we organize a 'kick the .org/.com/.net registrars' event so
> that they will start accepting AAAA entries for NS's?
>

--On Wednesday, April 20, 2005 5:56 PM +0200 Jeroen Massar
<jeroen@unfix.org> wrote:


> The whole goal of multihoming is being independent of upstream address
> space isn't it ?

Speaking from the point of view of a web hosting operator. Not entirely,
no. We multi-home for redundancy purposes *AND* for PI space. Without PI
space you are locked into keeping one provider, in order to keep your
address space and avoid renumbering. From what I've seen IPv6 still hasn't
done anything to really address the renumbering issue, and it will always
exist. There's not much of a way around it. It will always be there.
Routing hardware, likewise, has become more powerful and better able to
handle larger tables. However I'm very cheesed off that I have trouble
getting a /22, where there are places that do *NOTHING* with a /19. And
some of these are newer allocations even. I see SPAM gangs getting more
space than we could manage to justify to ARIN, RIPE, or anyone. Anyway
that's unrelated.

> Scenario, we are example.com and have 2 upstreams, thus 2x /48 and those
> are 2001:db8::/32 from the IPv6-Doc prefix and 3ffe:ffff::/48 out of the
> 6bone test/play/doc prefix. We have our example.com domain, where our
> web&smtp&etc-server resides at our shim6'd addresses. We can't shim6 our
> DNS/shim6-directory server because of cyclic redundancy, thus we have in
> DNS:
>
> ns1.example.com AAAA 2001:0db8::53
> ns1.example.com AAAA 3ffe:ffff::53
>
> It is 6/6/6 and major ISP's filter out 3ffe::/16. Thus one out of two
> first-query attempts go into oblivion and that is only for contacting
> DNS. When we want to update* the above we need to contact the registrar
> etc. Fortunately for some domains there is a 5 minute or so time, but
> then still you have cached entries etc.
>
> If people would rely on DNS to be so quick, then they could also do that
> for everything else, webservers etc.

But you can't. MS (Win2K and later) caches for about 30 minutes and *THEN*
obeys TTLs. So even if you get your NS recs fixed, there's still
significant outage *PLUS* someone has to be awake and notice it! That's,
imho, sub optimal at best. And really not at all desireable.

As it sits, IPv6 isn't usable in several situations because of lack of any
sort of PI space and lack of a cohesive multi-homing system like IPv4. I
understand the goals of setting up/cleaning up hierarchy, but the 'net
doesn't bend to that, at all. I'm sure I'm probably missing some other key
points or information and will undoubtedly need to don my asbestos suit but
that's my point of view sitting here as a web hosting provider with about
5k domains.

> Not even mentioning outsourced DNS servers, or having customers hardcode
> the DNS servers, eg ns1.example.org AAAA 2001:0db8::53, CNAMEs are not
> allowed and they love their own name.



>
> Greets,
> Jeroen
>
> * = Can't we organize a 'kick the .org/.com/.net registrars' event so
> that they will start accepting AAAA entries for NS's?
>



--
Undocumented Features quote of the moment...
"It's not the one bullet with your name on it that you
have to worry about; it's the twenty thousand-odd rounds
labeled `occupant.'"
--Murphy's Laws of Combat

Michael Loftis wrote:
>
>
> --On Wednesday, April 20, 2005 5:56 PM +0200 Jeroen Massar
> <jeroen@unfix.org> wrote:
>
>
>> The whole goal of multihoming is being independent of upstream address
>> space isn't it ?
>
>
> Speaking from the point of view of a web hosting operator. Not
> entirely, no. We multi-home for redundancy purposes *AND* for PI
> space. Without PI space you are locked into keeping one provider, in
> order to keep your address space and avoid renumbering. From what I've
> seen IPv6 still hasn't done anything to really address the renumbering
> issue, and it will always exist. There's not much of a way around it.
> It will always be there. Routing hardware, likewise, has become more
> powerful and better able to handle larger tables. However I'm very
> cheesed off that I have trouble getting a /22, where there are places
> that do *NOTHING* with a /19. And some of these are newer allocations
> even.

Well at least I've proved to myself that I'm not the only one stuck in
this quagmire.

I've joined in the discussion on address-policy-wg at RIPE, so we'll see
what happens.

--

Best regards,

Cameron Gray
Director, Netegral Limited
www.netegral.co.uk | cgray@netegral.co.uk
0871 277 NTGL (6845)

--On Wednesday, April 20, 2005 18:33 +0100 Cameron Gray
<cgray@netegral.co.uk> wrote:

> Well at least I've proved to myself that I'm not the only one stuck in
> this quagmire.

No, you're not. Until IPv6 gains multi-homing and PI space it can't
replace IPv4. The internet is not hierarchical. Never really has been,
and it's even less so now in this age. A number of sites I maintain
multi-home only for redundancy, but having even five minutes of outage to
propagate DNS changes is completely unacceptable, so they advertise space
via both uplinks. The other issue is that all in-progress connections are
broken if you change endpoint addresses (for whatever reason) on a live
site. This might not be a big deal for a number of different types of
things but think of a large IRC server eh? (yeah yeah I know, let the
kiddies reconnect, but there are legitimate uses for IRC).

> I've joined in the discussion on address-policy-wg at RIPE, so we'll see

I'm not sure what to do myself. I also don't have time to do it really.
and I don't fully understand all of the options being presented to the IPv6
WGs and standards bodies. I'm very concerned that my concerns will end up
in a minority in the standards bodies and thus not necessarily be
fully...er, mind the pun as it's not really intended... addressed.


--
GPG/PGP --> 0xE736BD7E 5144 6A2D 977A 6651 DFBE 1462 E351 88B9 E736 BD7E