Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #209975 > unrolled thread

IPv4 v IPv6

Back to article view | Back to linux.debian.user

Contents

  IPv4 v IPv6 mick crane <mick.crane@gmail.com> - 2019-06-17 11:10 +0200
    Re: IPv4 v IPv6 <tomas@tuxteam.de> - 2019-06-17 11:20 +0200
      Re: IPv4 v IPv6 Aidan Gauland <aidalgol@fastmail.net> - 2019-06-17 12:30 +0200
        Re: IPv4 v IPv6 Rob van der Putten <rob@sput.nl> - 2019-06-18 09:30 +0200
    Re: IPv4 v IPv6 Jonathan Dowland <jmtd@debian.org> - 2019-06-17 12:10 +0200
      Re: IPv4 v IPv6 Gene Heskett <gheskett@shentel.net> - 2019-06-17 16:40 +0200
        Re: IPv4 v IPv6 Dan Ritter <dsr@randomstring.org> - 2019-06-17 17:00 +0200
          Re: IPv4 v IPv6 Gene Heskett <gheskett@shentel.net> - 2019-06-17 18:30 +0200
          Re: IPv4 v IPv6 Gene Heskett <gheskett@shentel.net> - 2019-06-17 19:00 +0200
            Re: IPv4 v IPv6 Greg Wooledge <wooledg@eeg.ccf.org> - 2019-06-17 19:10 +0200
              Re: SOLVED was IPv4 v IPv6 discussion that went off the rails. Gene Heskett <gheskett@shentel.net> - 2019-06-18 02:10 +0200
            Re: IPv4 v IPv6 Dan Ritter <dsr@randomstring.org> - 2019-06-17 19:10 +0200
              Re: IPv4 v IPv6 Gene Heskett <gheskett@shentel.net> - 2019-06-17 19:40 +0200
                Re: IPv4 v IPv6 Dan Ritter <dsr@randomstring.org> - 2019-06-17 20:00 +0200
              Re: IPv4 v IPv6 Gene Heskett <gheskett@shentel.net> - 2019-06-17 20:00 +0200
              Re: IPv4 v IPv6 Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-06-18 14:50 +0200
                Re: IPv4 v IPv6 Greg Wooledge <wooledg@eeg.ccf.org> - 2019-06-18 14:50 +0200
                  Re: IPv4 v IPv6 Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-06-18 15:10 +0200
            Re: IPv4 v IPv6 Dennis Wicks <wix@mgssub.com> - 2019-06-27 22:40 +0200
              Re: IPv4 v IPv6 Gene Heskett <gheskett@shentel.net> - 2019-06-27 23:30 +0200
          Re: IPv4 v IPv6 John Hasler <jhasler@newsguy.com> - 2019-06-17 20:30 +0200
            Re: IPv4 v IPv6 Dan Ritter <dsr@randomstring.org> - 2019-06-17 22:10 +0200
              Re: IPv4 v IPv6 Robin Hammond <rdhdroid@gmail.com> - 2019-06-17 22:20 +0200
                Re: IPv4 v IPv6 Andy Smith <andy@strugglers.net> - 2019-06-18 00:50 +0200
                Re: IPv4 v IPv6 John Hasler <jhasler@newsguy.com> - 2019-06-18 04:10 +0200
            Re: IPv4 v IPv6 Gene Heskett <gheskett@shentel.net> - 2019-06-18 02:20 +0200
        Re: IPv4 v IPv6 Reco <recoverym4n@enotuniq.net> - 2019-06-17 17:40 +0200
          Re: IPv4 v IPv6 Richard Hector <richard@walnut.gen.nz> - 2019-06-18 12:00 +0200
            Re: IPv4 v IPv6 Reco <recoverym4n@enotuniq.net> - 2019-06-18 12:40 +0200
              Re: IPv4 v IPv6 Richard Hector <richard@walnut.gen.nz> - 2019-06-18 13:50 +0200
                Re: IPv4 v IPv6 Reco <recoverym4n@enotuniq.net> - 2019-06-18 16:20 +0200
                  Re: IPv4 v IPv6 Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-06-18 16:50 +0200
                    Re: IPv4 v IPv6 Reco <recoverym4n@enotuniq.net> - 2019-06-18 18:20 +0200
                      Re: IPv4 v IPv6 Linux Dave <mckisicd@gmail.com> - 2019-06-20 20:40 +0200
                      Re: IPv4 v IPv6 Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-06-20 20:40 +0200
                        Re: IPv4 v IPv6 Erwan David <erwan@rail.eu.org> - 2019-06-20 20:50 +0200
                          Re: IPv4 v IPv6 Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-06-20 21:00 +0200
                        Re: IPv4 v IPv6 Reco <recoverym4n@enotuniq.net> - 2019-06-20 21:10 +0200
                  Re: IPv4 v IPv6 Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-06-18 17:40 +0200
                    Re: IPv4 v IPv6 Reco <recoverym4n@enotuniq.net> - 2019-06-18 18:30 +0200
                  Re: IPv4 v IPv6 Richard Hector <richard@walnut.gen.nz> - 2019-06-18 18:20 +0200
                    Re: IPv4 v IPv6 Reco <recoverym4n@enotuniq.net> - 2019-06-18 18:30 +0200
        Re: IPv4 v IPv6 David Wright <deblis@lionunicorn.co.uk> - 2019-06-18 18:20 +0200
          Re: IPv4 v IPv6 Richard Hector <richard@walnut.gen.nz> - 2019-06-18 18:30 +0200
            Re: IPv4 v IPv6 Nicholas Geovanis <nickgeovanis@gmail.com> - 2019-06-18 18:40 +0200
            Re: IPv4 v IPv6 David Wright <deblis@lionunicorn.co.uk> - 2019-06-22 05:10 +0200
              Re: IPv4 v IPv6 Richard Hector <richard@walnut.gen.nz> - 2019-06-22 10:50 +0200
                Re: IPv4 v IPv6 David Wright <deblis@lionunicorn.co.uk> - 2019-06-24 20:20 +0200
              Re: IPv4 v IPv6 Andy Smith <andy@strugglers.net> - 2019-06-22 21:40 +0200
                Re: IPv4 v IPv6 Gene Heskett <gheskett@shentel.net> - 2019-06-22 22:50 +0200
                  Re: IPv4 v IPv6 John Hasler <jhasler@newsguy.com> - 2019-06-22 23:40 +0200
                    Re: IPv4 v IPv6 Gene Heskett <gheskett@shentel.net> - 2019-06-23 02:30 +0200
                      Re: IPv4 v IPv6 John Hasler <jhasler@newsguy.com> - 2019-06-23 05:00 +0200
                        Re: IPv4 v IPv6 Gene Heskett <gheskett@shentel.net> - 2019-06-23 08:30 +0200
                          Re: IPv4 v IPv6 Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-06-23 11:20 +0200
                Re: IPv4 v IPv6 Andy Smith <andy@strugglers.net> - 2019-06-26 20:40 +0200
                  Re: IPv4 v IPv6 Michael Stone <mstone@debian.org> - 2019-06-26 21:00 +0200
      Re: IPv4 v IPv6 Richard Hector <richard@walnut.gen.nz> - 2019-06-18 11:50 +0200
        Re: IPv4 v IPv6 Jonathan Dowland <jmtd@debian.org> - 2019-06-21 17:30 +0200
    Re: IPv4 v IPv6 andreimpopescu@gmail.com - 2019-07-02 11:10 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#209995

Gene Heskett wrote: 
> But that opens yet another container of worms. If I arbitrarily assign 
> ipv6 local addresses, and later, ipv6 shows up at my side of the router, 
> what if I have an address clash with someone on a satellite circuit in 
> Ulan Bator.  How is that resolved, by unroutable address blocks such as 
> 192.168.xx.xx is now?

In addition to the points made by others, the IPv6 address space is so
large that were you to assign a random IPv6 address to every computer in
existence (including all the embedded systems) the probability of a
collision would be negligible.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#210005

John Hasler wrote: 
> Gene Heskett wrote: 
> > But that opens yet another container of worms. If I arbitrarily assign 
> > ipv6 local addresses, and later, ipv6 shows up at my side of the router, 
> > what if I have an address clash with someone on a satellite circuit in 
> > Ulan Bator.  How is that resolved, by unroutable address blocks such as 
> > 192.168.xx.xx is now?
> 
> In addition to the points made by others, the IPv6 address space is so
> large that were you to assign a random IPv6 address to every computer in
> existence (including all the embedded systems) the probability of a
> collision would be negligible.

... but only if you were really being random. Humans are
terrible at doing that unaided.

-dsr-

[toc] | [prev] | [next] | [standalone]

#210006

[Multipart message — attachments visible in raw view] — view raw

The size of such a routing table gives me nightmares ! Thank goodness you
have to advertise networks of a reasonably sized prefix length!

On Mon, 17 Jun 2019 at 16:07, Dan Ritter <dsr@randomstring.org> wrote:

> John Hasler wrote:
> > Gene Heskett wrote:
> > > But that opens yet another container of worms. If I arbitrarily assign
> > > ipv6 local addresses, and later, ipv6 shows up at my side of the
> router,
> > > what if I have an address clash with someone on a satellite circuit in
> > > Ulan Bator.  How is that resolved, by unroutable address blocks such
> as
> > > 192.168.xx.xx is now?
> >
> > In addition to the points made by others, the IPv6 address space is so
> > large that were you to assign a random IPv6 address to every computer in
> > existence (including all the embedded systems) the probability of a
> > collision would be negligible.
>
> ... but only if you were really being random. Humans are
> terrible at doing that unaided.
>
> -dsr-
>
>

[toc] | [prev] | [next] | [standalone]

#210012

Hello,

On Mon, Jun 17, 2019 at 04:11:32PM -0400, Robin Hammond wrote:
> The size of such a routing table gives me nightmares ! Thank goodness you
> have to advertise networks of a reasonably sized prefix length!

I wouldn't worry too much about the number of v6 routes. In terms of
addressing and routing policy, this second go with v6 has afforded
some chances to correct mistaken assumptions made with v4 that later
became impossible to undo.

I would worry more about the number of v4 routes. As v4 runs out
globally (already has in some regions), there is increased pressure
to carve up allocations so that they can be traded. For example, if
you look at an arbitrary v4 auction site:

    https://auctions.ipv4.global/

(I picked this from a web search and have no information about it,
so it's not an endorsement)

You see that an ARIN /24 (256 addresses) currently goes for around
$5.6k. Let's say you have a /21 but you're only using the bottom
half. At the moment your route in the global routing table is a
single /21 route. But hey, people want to buy IPs, and you have 8
/24s in your /21. You're only using 4 of them (the bottom half as I
say). So you auction the top 4 off to 4 different buyers. Now the
global routing table needs one /22, for your bottom half, and then
four /24s, so it grew by 500%.

It is not yet quite that bad because a /24 is really still a bit too
small to route. Some providers may not accept the announcement. But
as the availability goes down and the prices go up, people are going
to want to route /24s routinely.

That is on top of the number of orgs who got an allocation that
proved to be too small so they went back for an extra one, thus
doubling the number of routes.

Meanwhile in IPv6 land, Regional Internet Registries tried really
hard to give out allocations so big that very few applicants should
ever need to come back for a second one (and thereby introduce
another global route).

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#210021

I wrote:
> In addition to the points made by others, the IPv6 address space is so
> large that were you to assign a random IPv6 address to every computer in
> existence (including all the embedded systems) the probability of a
> collision would be negligible.

dsr writes:
> ... but only if you were really being random. Humans are
> terrible at doing that unaided.

An address selected by a human isn't random.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#210015

On Monday 17 June 2019 02:24:47 pm John Hasler wrote:

> Gene Heskett wrote:
> > But that opens yet another container of worms. If I arbitrarily
> > assign ipv6 local addresses, and later, ipv6 shows up at my side of
> > the router, what if I have an address clash with someone on a
> > satellite circuit in Ulan Bator.  How is that resolved, by
> > unroutable address blocks such as 192.168.xx.xx is now?
>
> In addition to the points made by others, the IPv6 address space is so
> large that were you to assign a random IPv6 address to every computer
> in existence (including all the embedded systems) the probability of a
> collision would be negligible.

I pretty well had that figured out John, but Murphy rents a room here, 
owes me years of rent too, and the SOB even drinks my last beer from 
time to time.  IOW, if its going to happen to anybody, I'm in the first 
20 feet of the head of the line. :-)

Thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#209984

	Hi.

On Mon, Jun 17, 2019 at 10:38:27AM -0400, Gene Heskett wrote:
> But that opens yet another container of worms. If I arbitrarily assign 
> ipv6 local addresses, and later, ipv6 shows up at my side of the router, 
> what if I have an address clash with someone on a satellite circuit in 
> Ulan Bator.  How is that resolved, by unroutable address blocks such as 
> 192.168.xx.xx is now?

More or less yes. It's called ULA (Unique Local Address) in IPv6 lingua.
If you're using anything from fd00:/8 - you're safe.


> What I've read so far has not addressed this serious security concern.
> Or even mentioned it.

I fail to see any security issue here. Availability - sure.


> If in the future all addressing is by dhcpd6,

Nobody does that, unless you're Amazon. It's either static, or RA.


> how do the other machines on my local net, advertise their presence to the 
> other machines on my local net.

IPv4 way of doing it is called ARP.
IPv6 way of doing it is called ICMPv6 types 135 and 136.

Both are limited to a single network segment (in a L2 sense of the word)
by design, so the outside world is not aware of this.

Reco

[toc] | [prev] | [next] | [standalone]

#210030

[Multipart message — attachments visible in raw view] — view raw

On 18/06/19 3:38 AM, Reco wrote:
> 	Hi.
> 
> On Mon, Jun 17, 2019 at 10:38:27AM -0400, Gene Heskett wrote:
>> But that opens yet another container of worms. If I arbitrarily assign 
>> ipv6 local addresses, and later, ipv6 shows up at my side of the router, 
>> what if I have an address clash with someone on a satellite circuit in 
>> Ulan Bator.  How is that resolved, by unroutable address blocks such as 
>> 192.168.xx.xx is now?
> 
> More or less yes. It's called ULA (Unique Local Address) in IPv6 lingua.
> If you're using anything from fd00:/8 - you're safe.

As long as you choose them randomly. If you decide to use fd00::/64, or
something else predictable, you may run into conflicts ... but only if
you connect directly to their network. Better safe than sorry though.
The main reason I'm using v6 is that 2 networks I'm running a VPN
between both chose 192.168.1.0/24, and I can't change either ...

There are online random ULA generators - but I'm not convinced one of
them didn't give me the same block twice, or whether it was my own error.

Richard

[toc] | [prev] | [next] | [standalone]

#210031

	Hi.

On Tue, Jun 18, 2019 at 09:56:17PM +1200, Richard Hector wrote:
> On 18/06/19 3:38 AM, Reco wrote:
> > 	Hi.
> > 
> > On Mon, Jun 17, 2019 at 10:38:27AM -0400, Gene Heskett wrote:
> >> But that opens yet another container of worms. If I arbitrarily assign 
> >> ipv6 local addresses, and later, ipv6 shows up at my side of the router, 
> >> what if I have an address clash with someone on a satellite circuit in 
> >> Ulan Bator.  How is that resolved, by unroutable address blocks such as 
> >> 192.168.xx.xx is now?
> > 
> > More or less yes. It's called ULA (Unique Local Address) in IPv6 lingua.
> > If you're using anything from fd00:/8 - you're safe.
> 
> As long as you choose them randomly. If you decide to use fd00::/64, or
> something else predictable, you may run into conflicts ... but only if
> you connect directly to their network.

No sensibly configured router will allow forwarding ULAs to the
internet.  A scenario you're describing is therefore impossible unless
one adds NAT66 or some kind of VPN to it. In the former case
predictability of site addresses do not matter, in the latter it's
solvable with the appropriate amount of custom routes.


> Better safe than sorry though.

As long as it works for you - sure.


> The main reason I'm using v6 is that 2 networks I'm running a VPN
> between both chose 192.168.1.0/24, and I can't change either ...

So? If your VPN is running in L3 mode it's still possible to add some
kludges to IPv4 routing. If your VPN passes L2 - you're doing it
terribly wrong.


> There are online random ULA generators - but I'm not convinced one of
> them didn't give me the same block twice, or whether it was my own error.

Never used one. IPv6 /8 block consists of 2^56 unique /64 subnets.
Surely it's possible to choose several unique /64 subnets by using, say,
ipv6calc.

Reco

[toc] | [prev] | [next] | [standalone]

#210034

[Multipart message — attachments visible in raw view] — view raw

On 18/06/19 10:32 PM, Reco wrote:
> 	Hi.
> 
> On Tue, Jun 18, 2019 at 09:56:17PM +1200, Richard Hector wrote:
>> On 18/06/19 3:38 AM, Reco wrote:
>>> 	Hi.
>>>
>>> On Mon, Jun 17, 2019 at 10:38:27AM -0400, Gene Heskett wrote:
>>>> But that opens yet another container of worms. If I arbitrarily assign 
>>>> ipv6 local addresses, and later, ipv6 shows up at my side of the router, 
>>>> what if I have an address clash with someone on a satellite circuit in 
>>>> Ulan Bator.  How is that resolved, by unroutable address blocks such as 
>>>> 192.168.xx.xx is now?
>>>
>>> More or less yes. It's called ULA (Unique Local Address) in IPv6 lingua.
>>> If you're using anything from fd00:/8 - you're safe.
>>
>> As long as you choose them randomly. If you decide to use fd00::/64, or
>> something else predictable, you may run into conflicts ... but only if
>> you connect directly to their network.
> 
> No sensibly configured router will allow forwarding ULAs to the
> internet.  A scenario you're describing is therefore impossible unless
> one adds NAT66 or some kind of VPN to it. In the former case
> predictability of site addresses do not matter, in the latter it's
> solvable with the appropriate amount of custom routes.

Custom routes? When routing between 2 networks using the same range,
either with a VPN or some kind of direct connection? It's going to need
some evil double NAT sorcery, especially if the same actual addresses
are in use on both.

>> Better safe than sorry though.
> 
> As long as it works for you - sure.
> 
> 
>> The main reason I'm using v6 is that 2 networks I'm running a VPN
>> between both chose 192.168.1.0/24, and I can't change either ...
> 
> So? If your VPN is running in L3 mode it's still possible to add some
> kludges to IPv4 routing. If your VPN passes L2 - you're doing it
> terribly wrong.

Yes, I'm routing. Not sure what kludges you're proposing to let a
machine at one end talk to a machine at the other which it thinks is on
the same network.

Adding v6 at both ends with properly unique ranges seemed much the saner
option. Educational, as well :-)

>> There are online random ULA generators - but I'm not convinced one of
>> them didn't give me the same block twice, or whether it was my own error.
> 
> Never used one. IPv6 /8 block consists of 2^56 unique /64 subnets.
> Surely it's possible to choose several unique /64 subnets by using, say,
> ipv6calc.

Yes, but there is a recommendation to use random ones, and even a
suggestion of how to do it, in RFC 4193. I'd rather do that than find a
reason I hadn't thought of later which breaks things.

Richard

[toc] | [prev] | [next] | [standalone]

#210045

	Hi.

On Tue, Jun 18, 2019 at 11:47:08PM +1200, Richard Hector wrote:
> On 18/06/19 10:32 PM, Reco wrote:
> > 	Hi.
> > 
> > On Tue, Jun 18, 2019 at 09:56:17PM +1200, Richard Hector wrote:
> >> On 18/06/19 3:38 AM, Reco wrote:
> >>> 	Hi.
> >>>
> >>> On Mon, Jun 17, 2019 at 10:38:27AM -0400, Gene Heskett wrote:
> >>>> But that opens yet another container of worms. If I arbitrarily assign 
> >>>> ipv6 local addresses, and later, ipv6 shows up at my side of the router, 
> >>>> what if I have an address clash with someone on a satellite circuit in 
> >>>> Ulan Bator.  How is that resolved, by unroutable address blocks such as 
> >>>> 192.168.xx.xx is now?
> >>>
> >>> More or less yes. It's called ULA (Unique Local Address) in IPv6 lingua.
> >>> If you're using anything from fd00:/8 - you're safe.
> >>
> >> As long as you choose them randomly. If you decide to use fd00::/64, or
> >> something else predictable, you may run into conflicts ... but only if
> >> you connect directly to their network.
> > 
> > No sensibly configured router will allow forwarding ULAs to the
> > internet.  A scenario you're describing is therefore impossible unless
> > one adds NAT66 or some kind of VPN to it. In the former case
> > predictability of site addresses do not matter, in the latter it's
> > solvable with the appropriate amount of custom routes.
> 
> Custom routes? When routing between 2 networks using the same range,
> either with a VPN or some kind of direct connection? It's going to need
> some evil double NAT sorcery, especially if the same actual addresses
> are in use on both.

As long as:

a) It's L3 VPN, so ARP is not a concern.
b) There are no duplicate IPs on both sites combined.

The problem can be 'solved' by announcing specific IP routes to each and
every host on both sites. Yes, it's gross.


> >> The main reason I'm using v6 is that 2 networks I'm running a VPN
> >> between both chose 192.168.1.0/24, and I can't change either ...
> > 
> > So? If your VPN is running in L3 mode it's still possible to add some
> > kludges to IPv4 routing. If your VPN passes L2 - you're doing it
> > terribly wrong.
> 
> Yes, I'm routing. Not sure what kludges you're proposing to let a
> machine at one end talk to a machine at the other which it thinks is on
> the same network.

See above, it ain't pretty.


> Adding v6 at both ends with properly unique ranges seemed much the saner
> option. Educational, as well :-)

I totally agree here.


> >> There are online random ULA generators - but I'm not convinced one of
> >> them didn't give me the same block twice, or whether it was my own error.
> > 
> > Never used one. IPv6 /8 block consists of 2^56 unique /64 subnets.
> > Surely it's possible to choose several unique /64 subnets by using, say,
> > ipv6calc.
> 
> Yes, but there is a recommendation to use random ones, and even a
> suggestion of how to do it, in RFC 4193.

But this RFC's "random" cannot mean "I start each day with selecting
new, custom /64 IPv6 ULA prefix for my site". ipv6calc fills this
nicely, try it some day.

Reco

[toc] | [prev] | [next] | [standalone]

#210046

Le 18/06/2019 à 16:11, Reco a écrit :
>>
>> Custom routes? When routing between 2 networks using the same range,
>> either with a VPN or some kind of direct connection? It's going to need
>> some evil double NAT sorcery, especially if the same actual addresses
>> are in use on both.
> 
> As long as:
> 
> a) It's L3 VPN, so ARP is not a concern.
> b) There are no duplicate IPs on both sites combined.
> 
> The problem can be 'solved' by announcing specific IP routes to each and
> every host on both sites. Yes, it's gross.

Not all hosts accept route announcements (using which protocol ?). You 
may have better luck with ARP proxying on the routers (yet another kludge).

[toc] | [prev] | [next] | [standalone]

#210055

On Tue, Jun 18, 2019 at 04:45:59PM +0200, Pascal Hambourg wrote:
> Le 18/06/2019 à 16:11, Reco a écrit :
> > > 
> > > Custom routes? When routing between 2 networks using the same range,
> > > either with a VPN or some kind of direct connection? It's going to need
> > > some evil double NAT sorcery, especially if the same actual addresses
> > > are in use on both.
> > 
> > As long as:
> > 
> > a) It's L3 VPN, so ARP is not a concern.
> > b) There are no duplicate IPs on both sites combined.
> > 
> > The problem can be 'solved' by announcing specific IP routes to each and
> > every host on both sites. Yes, it's gross.
> 
> Not all hosts accept route announcements (using which protocol ?).

DHCP seems to be the most straightforward way of doing this.
Installing, say, quagga in each client host seems to be an overkill :)


> You may have better luck with ARP proxying on the routers (yet another kludge).

That'll do it too.

Reco

[toc] | [prev] | [next] | [standalone]

#210153

[Multipart message — attachments visible in raw view] — view raw

Please remove me from this email chain.

On Thu, Jun 20, 2019 at 2:33 PM Pascal Hambourg <pascal@plouf.fr.eu.org>
wrote:

> Le 18/06/2019 à 18:19, Reco a écrit :
> > On Tue, Jun 18, 2019 at 04:45:59PM +0200, Pascal Hambourg wrote:
> >> Le 18/06/2019 à 16:11, Reco a écrit :
> >>>
> >>> The problem can be 'solved' by announcing specific IP routes to each
> and
> >>> every host on both sites. Yes, it's gross.
> >>
> >> Not all hosts accept route announcements (using which protocol ?).
> >
> > DHCP seems to be the most straightforward way of doing this.
>
> DHCP provides two options to advertise static routes.
>
> The old "static-routes" option assumes classfull routing and does not
> advertise a netmask or prefix length. It is derived by the client from
> the address class :
> class A -> /8
> class B -> /16
> class C -> /24
> If the actual netmask does not match the classful one, the option is
> unusable.
>
> The newer "classless-static-routes" option advertises the netmask (or
> prefix length, not sure), but is not supported by all DHCP clients and
> servers. IIRC, the ISC DHCP client and server do not natively support
> it, you have to define it as a custom option.
>
>

-- 
David McKisick

[toc] | [prev] | [next] | [standalone]

#210154

Le 18/06/2019 à 18:19, Reco a écrit :
> On Tue, Jun 18, 2019 at 04:45:59PM +0200, Pascal Hambourg wrote:
>> Le 18/06/2019 à 16:11, Reco a écrit :
>>>
>>> The problem can be 'solved' by announcing specific IP routes to each and
>>> every host on both sites. Yes, it's gross.
>>
>> Not all hosts accept route announcements (using which protocol ?).
> 
> DHCP seems to be the most straightforward way of doing this.

DHCP provides two options to advertise static routes.

The old "static-routes" option assumes classfull routing and does not 
advertise a netmask or prefix length. It is derived by the client from 
the address class :
class A -> /8
class B -> /16
class C -> /24
If the actual netmask does not match the classful one, the option is 
unusable.

The newer "classless-static-routes" option advertises the netmask (or 
prefix length, not sure), but is not supported by all DHCP clients and 
servers. IIRC, the ISC DHCP client and server do not natively support 
it, you have to define it as a custom option.

[toc] | [prev] | [next] | [standalone]

#210157

Le 20/06/2019 à 20:33, Pascal Hambourg a écrit :
> Le 18/06/2019 à 18:19, Reco a écrit :
>> On Tue, Jun 18, 2019 at 04:45:59PM +0200, Pascal Hambourg wrote:
>>> Le 18/06/2019 à 16:11, Reco a écrit :
>>>>
>>>> The problem can be 'solved' by announcing specific IP routes to
>>>> each and
>>>> every host on both sites. Yes, it's gross.
>>>
>>> Not all hosts accept route announcements (using which protocol ?).
>>
>> DHCP seems to be the most straightforward way of doing this.
>
> DHCP provides two options to advertise static routes.
>
> The old "static-routes" option assumes classfull routing and does not
> advertise a netmask or prefix length. It is derived by the client from
> the address class :
> class A -> /8
> class B -> /16
> class C -> /24
> If the actual netmask does not match the classful one, the option is
> unusable.
>
> The newer "classless-static-routes" option advertises the netmask (or
> prefix length, not sure), but is not supported by all DHCP clients and
> servers. IIRC, the ISC DHCP client and server do not natively support
> it, you have to define it as a custom option.
>
>
When you know that classless routing is older than classes were when
CIDR appeared...

[toc] | [prev] | [next] | [standalone]

#210161

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jun 20, 2019 at 1:44 PM Erwan David <erwan@rail.eu.org> wrote:

>
> When you know that classless routing is older than classes were when
> CIDR appeared...
>

...then you stop worrying whether or not you can grok IPV6  :-D
Or you post questions about esoteric protocols just to stump the
younger whippersnappers: Like my blurt about TCAM a couple postings back....
Peace, love 73 de NickGeo

[toc] | [prev] | [next] | [standalone]

#210163

	Hi.

On Thu, Jun 20, 2019 at 08:33:07PM +0200, Pascal Hambourg wrote:
> Le 18/06/2019 à 18:19, Reco a écrit :
> > On Tue, Jun 18, 2019 at 04:45:59PM +0200, Pascal Hambourg wrote:
> > > Le 18/06/2019 à 16:11, Reco a écrit :
> > > > 
> > > > The problem can be 'solved' by announcing specific IP routes to each and
> > > > every host on both sites. Yes, it's gross.
> > > 
> > > Not all hosts accept route announcements (using which protocol ?).
> > 
> > DHCP seems to be the most straightforward way of doing this.
> 
> DHCP provides two options to advertise static routes.
> 
> The old "static-routes" option assumes classfull routing and does not advertise a netmask or prefix length. It is derived by the client from the address class
> :

Agreed.


> The newer "classless-static-routes" option advertises the netmask (or prefix length, not sure), but is not supported by all DHCP clients and servers.
> IIRC, the ISC DHCP client and server do not natively support it, you have to define it as a custom option.

It's not a DHCP server unless ISC made it.
With this in mind, something like this:

option rfc3442-classless-static-routes code 121 = array of integer 8;
option rfc3442-classless-static-routes 32, 192, 168, 0, 1, 192, 168, 0, 2;

Should announce this route:

192.168.0.1/32 via 192.168.0.2

Imperfect OSes might require adding option 249 in a similar way.
But users of such OSes should suffer anyway, so I won't bother with the
example.

Reco

[toc] | [prev] | [next] | [standalone]

#210049

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jun 18, 2019 at 9:11 AM Reco <recoverym4n@enotuniq.net> wrote:

>         Hi.
>

Guten Morgen,


> But this RFC's "random" cannot mean "I start each day with selecting
> new, custom /64 IPv6 ULA prefix for my site". ipv6calc fills this
> nicely, try it some day.
>

By RFC 4193, it must/should be pseudo-random generated. The key must/should
be an NTP-generated 64-bit date/time concatenated with the local MAC
address. "It is important that all sites generating Global IDs use a
functionally similar algorithm to ensure there is a high probability of
uniqueness....This algorithm will result in a Global ID that is reasonably
unique and can be used to create a locally assigned Local IPv6 address
prefix". (RFC 4193)
https://www.rfc-editor.org/rfc/rfc4193.html

Not exactly elegant.


Reco
>
>

[toc] | [prev] | [next] | [standalone]

#210060

	Hi.

On Tue, Jun 18, 2019 at 10:32:23AM -0500, Nicholas Geovanis wrote:
> Guten Morgen,
> 
> 
> > But this RFC's "random" cannot mean "I start each day with selecting
> > new, custom /64 IPv6 ULA prefix for my site". ipv6calc fills this
> > nicely, try it some day.
> >
> 
> By RFC 4193, it must/should be pseudo-random generated. The key must/should
> be an NTP-generated 64-bit date/time concatenated with the local MAC
> address. "It is important that all sites generating Global IDs use a
> functionally similar algorithm to ensure there is a high probability of
> uniqueness....This algorithm will result in a Global ID that is reasonably
> unique and can be used to create a locally assigned Local IPv6 address
> prefix". (RFC 4193)
> https://www.rfc-editor.org/rfc/rfc4193.html
> 
> Not exactly elegant.

Oh, I'll take ipv6calc approach over *that* each time I have to try it.

Reco

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web