Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: ipv6

ipv6 next-hop link-local

 

 

First page Previous page 1 2 Next page Last page  View All nsp ipv6 RSS feed   Index | Next | Previous | View Threaded


gert at space

Feb 20, 2011, 1:36 AM

Post #26 of 39 (1990 views)
Permalink
Re: ipv6 next-hop link-local [In reply to]

Hi,

On Sun, Feb 20, 2011 at 10:35:50AM +1030, Mark Smith wrote:
> > There's a fair bit of operational experience on the routing side of things
> > (the IXPs we're connected to have offered IPv6 roughly since 2001).
>
> I just wonder if those sorts of deployments have followed "IPv4
> thinking". I think "IPv4 thinking" is "this is how we can do it and do
> do it in IPv4, so we'll do it the same way in IPv6, because IPv6 is
> similar enough to IPv4."

Well, partly it's "IPv4 thinking", of course. OTOH, in certain areas,
"IPv4 thinking" has gained 15+ years of experience in doing things since
IPv6 was designed, and just because it's IPv4, it doesn't have to be
"wrong".

Specifically the topic at hand, using link-locals at an IXP, has some
benefits - and at the same time, serious operational drawbacks, like
"monitoring your eBGP peers in your NMS by IPv6 address" - now which
of the two IXPs I'm connected to is the fe80::ab:cd neighbour that just
went down?

I've seen so much operational problems due to, well, inexperienced
router operators (or just "fat fingers") that anything that requires
extra thinking or has the potential for extra breakage is something
I see with certain doubts.

[..]
> I get concerned about people lobbying for removal of IPv6 features when
> they seem to be doing it from an "IPv4 thinking" perspective.

I'm actually not lobbying to take away the configuration option of
consciously using link-local addresses - give people enough rope, etc. -
(and I earn my living by fixing other people's networks).

What I'm lobbying for is what Juniper already does: on an eBGP session
that's established between global addresses, do not install the link-local
next-hop in the FIB, but use the global next-hop.

Specifically, always use the scope of the eBGP endpoint address to
decide upon the scope of the next-hop being used.

Using link-local next-hops on an eBGP session established between
directly connected neighbours on an IXP using global addresses for
the endpoints has a strong smell of "too much IPv6 thinking" to me,
bringing extra pitfalls with no benefits that I can see (maybe I'm
overlooking something).

Gert Doering
-- NetMaster
--
did you enable IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279


nanog at 85d5b20a518b8f6864949bd940457dc124746ddc

Feb 20, 2011, 3:12 AM

Post #27 of 39 (2001 views)
Permalink
Re: ipv6 next-hop link-local [In reply to]

Hi,

On Sun, 20 Feb 2011 10:36:13 +0100
Gert Doering <gert [at] space> wrote:

> Hi,
>
> On Sun, Feb 20, 2011 at 10:35:50AM +1030, Mark Smith wrote:
> > > There's a fair bit of operational experience on the routing side of things
> > > (the IXPs we're connected to have offered IPv6 roughly since 2001).
> >
> > I just wonder if those sorts of deployments have followed "IPv4
> > thinking". I think "IPv4 thinking" is "this is how we can do it and do
> > do it in IPv4, so we'll do it the same way in IPv6, because IPv6 is
> > similar enough to IPv4."
>
> Well, partly it's "IPv4 thinking", of course. OTOH, in certain areas,
> "IPv4 thinking" has gained 15+ years of experience in doing things since
> IPv6 was designed, and just because it's IPv4, it doesn't have to be
> "wrong".
>

I never said it was "wrong". What "IPv4 thinking" does is
constraining peoples' view point, such that they potentially miss out
on benefits and opportunities that are only possible with IPv6. I'd
like them to realise that there are possibly more options available to
solve a problem than just the set that they're familiar with from
their IPv4 experience and history.

> Specifically the topic at hand, using link-locals at an IXP, has some
> benefits - and at the same time, serious operational drawbacks, like
> "monitoring your eBGP peers in your NMS by IPv6 address" - now which
> of the two IXPs I'm connected to is the fe80::ab:cd neighbour that just
> went down?
>

How about the one with the failed eBGP session, detected via SNMP BGP
MIB session state change or BGP session state change syslogs? I'm
presuming you'd already be monitoring BGP session state in this sort of
scenario.

> I've seen so much operational problems due to, well, inexperienced
> router operators (or just "fat fingers") that anything that requires
> extra thinking or has the potential for extra breakage is something
> I see with certain doubts.
>

I don't really accept that because a task can't be achieved
perfectly by 100% of people it is an unreasonable and unacceptable
task. People need to put effort into understanding IPv6 properly,
otherwise they'll make naive mistakes, with costs such as easily
avoidable service outages.

> [..]
> > I get concerned about people lobbying for removal of IPv6 features when
> > they seem to be doing it from an "IPv4 thinking" perspective.
>
> I'm actually not lobbying to take away the configuration option of
> consciously using link-local addresses - give people enough rope, etc. -
> (and I earn my living by fixing other people's networks).
>
> What I'm lobbying for is what Juniper already does: on an eBGP session
> that's established between global addresses, do not install the link-local
> next-hop in the FIB, but use the global next-hop.
>
> Specifically, always use the scope of the eBGP endpoint address to
> decide upon the scope of the next-hop being used.
>

I think I'd prefer to see the exact value of the NEXT_HOP attribute the
peer supplied used in the RIB, be it a link local or a global address
(leaving that as the peer's decision), with the underlying FIB
mechanisms (e.g. CEF) then being used to resolve that down to a FIB
entry specifying an outbound interface and possibly a link layer
destination. The NEXT_HOP value doesn't have to be the same as either
the link local or global address of the BGP peer announcing it - it can
be used to announce routes on behalf of another router. I'm sure you're
probably aware that is how route-servers in multilateral IXes avoid
being in the traffic forwarding path between peers.

> Using link-local next-hops on an eBGP session established between
> directly connected neighbours on an IXP using global addresses for
> the endpoints has a strong smell of "too much IPv6 thinking" to me,
> bringing extra pitfalls with no benefits that I can see (maybe I'm
> overlooking something).
>

I'm actually thinking that using link locals as your eBGP end-points is
where the benefits are. It minimises the attack surface for attacks
like these -

http://tools.ietf.org/search/rfc4953#section-2.2

Regards,
Mark.


gert at space

Feb 20, 2011, 3:56 AM

Post #28 of 39 (2041 views)
Permalink
Re: ipv6 next-hop link-local [In reply to]

Hi,

On Sun, Feb 20, 2011 at 09:42:50PM +1030, Mark Smith wrote:
> > What I'm lobbying for is what Juniper already does: on an eBGP session
> > that's established between global addresses, do not install the link-local
> > next-hop in the FIB, but use the global next-hop.
>
> I think I'd prefer to see the exact value of the NEXT_HOP attribute the
> peer supplied used in the RIB, be it a link local or a global address
> (leaving that as the peer's decision), with the underlying FIB
> mechanisms (e.g. CEF) then being used to resolve that down to a FIB
> entry specifying an outbound interface and possibly a link layer
> destination.

Well, the problem is that there's *two* next hop values in the BGP
update, and the receiving peer gets to choose one. Juniper uses the
global address, Cisco uses the link-local - and the latter behaviour is not
providing any benefits (that I could see), but is creating a new failure
mode (which I consider non-useful).

Here's an example from a production IXP:

Cisco#sh bgp ipv6 2001:470::/32
BGP routing table entry for 2001:470::/32, version 11816664
Paths: (9 available, best #9, table Default)
...
6939
2001:7F8::1B1B:0:1 (FE80::20C:DBFF:FEFC:7F92) from 2001:7F8::1B1B:0:1 (216.218.252.174)
Origin IGP, metric 1, localpref 100, valid, external, best
Community: 5539:100
6939, (received-only)
2001:7F8::1B1B:0:1 (FE80::20C:DBFF:FEFC:7F92) from 2001:7F8::1B1B:0:1 (216.218.252.174)
Origin IGP, metric 1, localpref 100, valid, external
...

(before and after inbound route-map application, "soft in" enabled)

Cisco#sh ipv route 2001:470::1
Routing entry for 2001:470::/32
Known via "bgp 5539", distance 20, metric 1, type external
Route count is 1/1, share count 0
Routing paths:
FE80::20C:DBFF:FEFC:7F92, GigabitEthernet1/1
MPLS label: none
Last updated 7w0d ago

Cisco-F-III#sh ipv6 cef 2001:470::1
2001:470::/32
nexthop FE80::20C:DBFF:FEFC:7F92 GigabitEthernet1/1



> The NEXT_HOP value doesn't have to be the same as either
> the link local or global address of the BGP peer announcing it - it can
> be used to announce routes on behalf of another router. I'm sure you're
> probably aware that is how route-servers in multilateral IXes avoid
> being in the traffic forwarding path between peers.

I am aware of that, and I can read the output of "show bgp" commands :-)

The route-server on this IXP is announcing 3rd-party next-hops, but will
not be "best path" for us if a direct eBGP session exists to a given
peer AS. It's showing the same effects, though.


[..]
> I'm actually thinking that using link locals as your eBGP end-points is
> where the benefits are. It minimises the attack surface for attacks
> like these -
>
> http://tools.ietf.org/search/rfc4953#section-2.2

And it brings lots of new operational issues, like in "oh, I've seen
a SNMP trap that fe80::aa:bb just went down". Now - which exchange
point was that on? Which router, which city, which interface? Of course
this could all be solved by enhancing software and processes - but with
the same amount of effort, you could just roll out GTSM and MD5 everywhere,
and still have proper mapping of "ah, this address is on IXP <foo> and
belongs to peer <bar>". Like, with DNS, and such.

But this is a completely different issue - if people want to do so, I wish
them fun. We looked at this option some 10 years ago and decided that this
is not something we find particularily useful, so we're not doing it.

Gert Doering
-- NetMaster
--
did you enable IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279


gbonser at seven

Feb 20, 2011, 3:17 PM

Post #29 of 39 (1991 views)
Permalink
RE: ipv6 next-hop link-local [In reply to]

> Specifically the topic at hand, using link-locals at an IXP, has some
> benefits - and at the same time, serious operational drawbacks, like
> "monitoring your eBGP peers in your NMS by IPv6 address" - now which
of
> the two IXPs I'm connected to is the fe80::ab:cd neighbour that just
> went down?

And that is really the problem. Link locals can get very confusing when
a machine, even a host, has several interfaces. If I have several vlan
interfaces on a host and I have a packet to send to fe80::ab:cd ... on
which interface will I find that neighbor?

Looking right now at a box in a data center. Two different vlan
interfaces on the same box. One is:

inet6 addr: fe80::221:28ff:fe57:3412/64

and the other is:

inet6 addr: fe80::221:28ff:fe57:3412/64

Same netmask, same IP address, two different networks. On which one
will I find fe80:ab:cd? I need to do ND on all of them until I find it,
I suppose.

I have some machines with a half-dozen interfaces on them. If I tried
to use link-locals only, the kernel would probably be in Keystone Kops
mode trying to figure out where to send stuff.

If I were making the rules, link local would only mean "I don't have
enough information to build a 'real' IP address so I am using this
placeholder in the meantime. Once a "real" address is configured, the
link-local would be dropped.

Bottom line is that link local is fine where you have one interface. It
gets to be a pain when you have many.


swmike at swm

Feb 20, 2011, 5:10 PM

Post #30 of 39 (2005 views)
Permalink
RE: ipv6 next-hop link-local [In reply to]

On Sun, 20 Feb 2011, George Bonser wrote:

> Same netmask, same IP address, two different networks. On which one
> will I find fe80:ab:cd? I need to do ND on all of them until I find it,
> I suppose.

No.

Let me illustrate how it works:

swmike [at] uplif:~$ ip -6 n l
fe80::230:a3ff:fe75:c838 dev eth0 lladdr 00:30:a3:75:c8:38 router REACHABLE
<rest snipped>

swmike [at] uplif:~$ ping6 fe80::230:a3ff:fe75:c838%eth0
PING fe80::230:a3ff:fe75:c838%eth0(fe80::230:a3ff:fe75:c838) 56 data bytes
64 bytes from fe80::230:a3ff:fe75:c838: icmp_seq=1 ttl=64 time=0.415 ms
64 bytes from fe80::230:a3ff:fe75:c838: icmp_seq=2 ttl=64 time=0.346 ms
^C
--- fe80::230:a3ff:fe75:c838%eth0 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.346/0.380/0.415/0.039 ms

swmike [at] uplif:~$ ping6 fe80::230:a3ff:fe75:c838
connect: Invalid argument

Link Local is Link Local, you have to tell it what link it is before you
can use it. The Interface identifier is an integral part of the LL
address.

--
Mikael Abrahamsson email: swmike [at] swm


spz at serpens

Feb 21, 2011, 12:05 AM

Post #31 of 39 (1994 views)
Permalink
Re: ipv6 next-hop link-local [In reply to]

Hi,

Thus wrote George Bonser (gbonser [at] seven):

> Looking right now at a box in a data center. Two different vlan
> interfaces on the same box. One is:
>
> inet6 addr: fe80::221:28ff:fe57:3412/64
>
> and the other is:
>
> inet6 addr: fe80::221:28ff:fe57:3412/64

Speaking at least for the KAME stack, that is a red herring, because a
linklocal address always has a scope which tells it which interface
it refers to.

So you don't have fe80::221:28ff:fe57:3412/64 and
fe80::221:28ff:fe57:3412/64, but fe80::221:28ff:fe57:3412%if1/64 and
fe80::221:28ff:fe57:3412%if2/64.

> Same netmask, same IP address, two different networks. On which one
> will I find fe80:ab:cd? I need to do ND on all of them until I find it,
> I suppose.

Not much different from "where is the MAC address I see acting up
located". If you are instead intending to set up communications with
another machine via linklocal, you presumably know which network it is on
beforehand. Remember that a linklocal address is only addressable with
scope.

> If I were making the rules, link local would only mean "I don't have
> enough information to build a 'real' IP address so I am using this
> placeholder in the meantime. Once a "real" address is configured, the
> link-local would be dropped.

I've used linklocal for eg NFS and the 'will not cross routers' feature
was quite welcome as a built-in security mechanism. Thus, I disagree.

regards,
spz
--
spz [at] serpens (S.P.Zeidler)


gbonser at seven

Feb 21, 2011, 12:30 AM

Post #32 of 39 (1985 views)
Permalink
RE: ipv6 next-hop link-local [In reply to]

>
> I've used linklocal for eg NFS and the 'will not cross routers'
feature
> was quite welcome as a built-in security mechanism. Thus, I disagree.
>
> regards,
> spz
> --
> spz [at] serpens (S.P.Zeidler)

So you must already know where the destination is in order to use it.
Ok, and I am still learning more about v6 each day. But it would seen
that as a next hop for a dynamic routing protocol such as BGP, it would
be of little utility, particularly once one gets one or more hops away
from that link local NH.


nanog at 85d5b20a518b8f6864949bd940457dc124746ddc

Feb 21, 2011, 12:50 AM

Post #33 of 39 (1988 views)
Permalink
Re: ipv6 next-hop link-local [In reply to]

Hi,

On Sun, 20 Feb 2011 15:17:01 -0800
"George Bonser" <gbonser [at] seven> wrote:

> > Specifically the topic at hand, using link-locals at an IXP, has some
> > benefits - and at the same time, serious operational drawbacks, like
> > "monitoring your eBGP peers in your NMS by IPv6 address" - now which
> of
> > the two IXPs I'm connected to is the fe80::ab:cd neighbour that just
> > went down?
>
> And that is really the problem. Link locals can get very confusing when
> a machine, even a host, has several interfaces. If I have several vlan
> interfaces on a host and I have a packet to send to fe80::ab:cd ... on
> which interface will I find that neighbor?
>
> Looking right now at a box in a data center. Two different vlan
> interfaces on the same box. One is:
>
> inet6 addr: fe80::221:28ff:fe57:3412/64
>
> and the other is:
>
> inet6 addr: fe80::221:28ff:fe57:3412/64
>
> Same netmask, same IP address, two different networks. On which one
> will I find fe80:ab:cd? I need to do ND on all of them until I find it,
> I suppose.
>
> I have some machines with a half-dozen interfaces on them. If I tried
> to use link-locals only, the kernel would probably be in Keystone Kops
> mode trying to figure out where to send stuff.
>

In that case you (or the application) need to specify the interface.
For link local unicast or multicast traffic, the ifindex of the
interface to use is supplied in the sin6_scope_id field of the
sockaddr_in6 structure, passed to connect() or bind().

I do agree though, the ambiguity of link locals can be an issue, and
that is the trade off with using them. So the benefits of link locals
are (a) they're always there, regardless of whether global or ULA
addresses are also available or being deprecated, (b) they have a well
known prefix distinct from other types of addresses, and (c) they're not
reachable from off-link destinations. The drawback is their ambiguity on
multi-homed hosts or routers.

Fundamentally, for non-link local addresses, the subnet number is used
to distinguish the outbound/inbound interface when the prefix is the
same. I've thought it could be useful to have link locals with
properties similar to ULAs - there is a randomly selected link-local
subnet/link identifier (probably using all of the bits between
fe80::/10 and /64, with all zeros reserved for existing link local
interoperability), chosen by the first node attached to the link. When
subsequent nodes attach to the link they query see if a link-local
subnet has already been chosen, and use that for their link-local
addresses. If not, they choose one. This first attached node is the
"link local subnet seed node", similar to how Appletalk seed routers
worked. The valid and preferred lifetimes of these unique link locals
would be quite large (the default RFC4861 lifetimes of 1 week and 4
weeks might be fine), and if the original seed node disappeared,
another one could take over as the seed for the chosen subnet number. I
think this would be a reasonable way to get rid of the ambiguity issue,
while still retaining the other link local benefits.

Regards,
Mark.


> If I were making the rules, link local would only mean "I don't have
> enough information to build a 'real' IP address so I am using this
> placeholder in the meantime. Once a "real" address is configured, the
> link-local would be dropped.
>
> Bottom line is that link local is fine where you have one interface. It
> gets to be a pain when you have many.
>
>


spz at serpens

Feb 21, 2011, 2:02 AM

Post #34 of 39 (1975 views)
Permalink
Re: ipv6 next-hop link-local [In reply to]

Thus wrote Mark Smith (nanog [at] 85d5b20a518b8f6864949bd940457dc124746ddc):

> For link local unicast or multicast traffic, the ifindex of the
> interface to use is supplied in the sin6_scope_id field of the
> sockaddr_in6 structure, passed to connect() or bind().

.. and if it's not specified it will have a strong tendency (depending on
the struct memory having being cleared or not) to be 0 and thus loopback,
which is both a safe fallback and a bofhly punishment for the sin of
omission :-P

> I do agree though, the ambiguity of link locals can be an issue, and
> that is the trade off with using them. So the benefits of link locals
> are (a) they're always there, regardless of whether global or ULA
> addresses are also available or being deprecated, (b) they have a well
> known prefix distinct from other types of addresses, and (c) they're not
> reachable from off-link destinations. The drawback is their ambiguity on
> multi-homed hosts or routers.

And c) (non-reachability from off-link) too. It Depends (tm).

Intuition says to use routable addresses for routing unless I would pick
unnumbered, but I'll need to let that percolate a bit for the whys and
their applicability.

> Fundamentally, for non-link local addresses, the subnet number is used
> to distinguish the outbound/inbound interface when the prefix is the
> same. I've thought it could be useful to have link locals with
> properties similar to ULAs -
[...]

This is either not stateless, or you have trouble after all your systems
have been off (UPS outage, anyone?), and I fail to see an advantage
over ULA.

regards,
spz
--
spz [at] serpens (S.P.Zeidler)


nanog at 85d5b20a518b8f6864949bd940457dc124746ddc

Feb 21, 2011, 2:48 AM

Post #35 of 39 (1969 views)
Permalink
Re: ipv6 next-hop link-local [In reply to]

On Mon, 21 Feb 2011 11:02:28 +0100
"S.P.Zeidler" <spz [at] serpens> wrote:

> Thus wrote Mark Smith (nanog [at] 85d5b20a518b8f6864949bd940457dc124746ddc):
>
> > For link local unicast or multicast traffic, the ifindex of the
> > interface to use is supplied in the sin6_scope_id field of the
> > sockaddr_in6 structure, passed to connect() or bind().
>
> .. and if it's not specified it will have a strong tendency (depending on
> the struct memory having being cleared or not) to be 0 and thus loopback,
> which is both a safe fallback and a bofhly punishment for the sin of
> omission :-P
>
> > I do agree though, the ambiguity of link locals can be an issue, and
> > that is the trade off with using them. So the benefits of link locals
> > are (a) they're always there, regardless of whether global or ULA
> > addresses are also available or being deprecated, (b) they have a well
> > known prefix distinct from other types of addresses, and (c) they're not
> > reachable from off-link destinations. The drawback is their ambiguity on
> > multi-homed hosts or routers.
>
> And c) (non-reachability from off-link) too. It Depends (tm).
>
> Intuition says to use routable addresses for routing unless I would pick
> unnumbered, but I'll need to let that percolate a bit for the whys and
> their applicability.
>
> > Fundamentally, for non-link local addresses, the subnet number is used
> > to distinguish the outbound/inbound interface when the prefix is the
> > same. I've thought it could be useful to have link locals with
> > properties similar to ULAs -
> [...]
>
> This is either not stateless, or you have trouble after all your systems
> have been off (UPS outage, anyone?),

Just need to define a tie breaking algorithm to select the new seed to
then choose the new subnet id. Highest or lowest IID would probably do
after DAD has been completed. I think most of the "packet functionality"
exists in RAs - PIOs for SLAAC can be announced by an RA without the
device issuing an RA being considered a default router, by setting the
router lifetime in the RA to zero.

> and I fail to see an advantage
> over ULA.
>


ULAs would go close, and I've thought about using them in this
manner, however I think there would be a few advantages in these
"unique link locals" using a different prefix to the ULA one. Existing
link-locals have all the necessary properties, except the uniqueness
of subnet identifier.

> regards,
> spz
> --
> spz [at] serpens (S.P.Zeidler)


ignatios at theory

Feb 22, 2011, 10:58 PM

Post #36 of 39 (1937 views)
Permalink
Re: ipv6 next-hop link-local [In reply to]

On Mon, Feb 21, 2011 at 12:30:52AM -0800, George Bonser wrote:
> So you must already know where the destination is in order to use it.
> Ok, and I am still learning more about v6 each day. But it would seen
> that as a next hop for a dynamic routing protocol such as BGP, it would
> be of little utility, particularly once one gets one or more hops away
> from that link local NH.

That, of course. It is only useful per-link.

-is


spz at serpens

Feb 22, 2011, 11:40 PM

Post #37 of 39 (1918 views)
Permalink
Re: ipv6 next-hop link-local [In reply to]

Thus wrote Mark Smith (nanog [at] 85d5b20a518b8f6864949bd940457dc124746ddc):

> On Mon, 21 Feb 2011 11:02:28 +0100
> "S.P.Zeidler" <spz [at] serpens> wrote:
>
> > This is either not stateless, or you have trouble after all your systems
> > have been off (UPS outage, anyone?),
>
> Just need to define a tie breaking algorithm to select the new seed to
> then choose the new subnet id. Highest or lowest IID would probably do
> after DAD has been completed. I think most of the "packet functionality"
> exists in RAs - PIOs for SLAAC can be announced by an RA without the
> device issuing an RA being considered a default router, by setting the
> router lifetime in the RA to zero.

So you have a unique local prefix, for what exactly?
Since you will come up with something totally different after a power
outage, when you need extra hassles least, you cannot use it to
identify a fileserver, appserver, etc; basically, you can not -use-
these addresses for anything that is not based on dynamic polling.

regards,
spz
--
spz [at] serpens (S.P.Zeidler)


nanog at 85d5b20a518b8f6864949bd940457dc124746ddc

Feb 23, 2011, 1:13 AM

Post #38 of 39 (1937 views)
Permalink
Re: ipv6 next-hop link-local [In reply to]

On Wed, 23 Feb 2011 08:40:48 +0100
"S.P.Zeidler" <spz [at] serpens> wrote:

> Thus wrote Mark Smith (nanog [at] 85d5b20a518b8f6864949bd940457dc124746ddc):
>
> > On Mon, 21 Feb 2011 11:02:28 +0100
> > "S.P.Zeidler" <spz [at] serpens> wrote:
> >
> > > This is either not stateless, or you have trouble after all your systems
> > > have been off (UPS outage, anyone?),
> >
> > Just need to define a tie breaking algorithm to select the new seed to
> > then choose the new subnet id. Highest or lowest IID would probably do
> > after DAD has been completed. I think most of the "packet functionality"
> > exists in RAs - PIOs for SLAAC can be announced by an RA without the
> > device issuing an RA being considered a default router, by setting the
> > router lifetime in the RA to zero.
>
> So you have a unique local prefix, for what exactly?

For the same purposes as link locals are or can be used for today, with
the difference being that the inbound/outbound interface doesn't have
to be specified, as the ambiguity of which interface the address
exists on has been eliminated.

> Since you will come up with something totally different after a power
> outage, when you need extra hassles least, you cannot use it to
> identify a fileserver, appserver, etc; basically, you can not -use-
> these addresses for anything that is not based on dynamic polling.
>

Dynamic or Multicast DNS (a.k.a. Bonjour, Avahi etc.) would provide name
resolution for them if you where using them for more general
applications communication. It would be possible to make generating and
configuring the unique link local subnet ID manual, however I think
it'd be worth making it automated and agreed, so that IPv6 on the local
link autoconfigures itself (to easily facilitate the the IPv6 "dentist's
office" scenario).

They'd be functionally like ULAs, except that they wouldn't be routable
off-link (a useful security property), and have a separately designated
prefix so that if necessary they can be identified in places where the
identifying the type of prefix and it's reachability is useful or
necessary.

Regards,
Mark.


spz at serpens

Feb 27, 2011, 12:20 AM

Post #39 of 39 (1865 views)
Permalink
Re: ipv6 next-hop link-local [In reply to]

Thus wrote Mark Smith (nanog [at] 85d5b20a518b8f6864949bd940457dc124746ddc):

> On Wed, 23 Feb 2011 08:40:48 +0100
> "S.P.Zeidler" <spz [at] serpens> wrote:
>
> > So you have a unique local prefix, for what exactly?
>
> For the same purposes as link locals are or can be used for today, with
> the difference being that the inbound/outbound interface doesn't have
> to be specified, as the ambiguity of which interface the address
> exists on has been eliminated.

ie manually configured peer addresses for high security impact uses?

Obviously not, because "changeable" and "manually configured" don't
co-exist well.

> > Since you will come up with something totally different after a power
> > outage, when you need extra hassles least, you cannot use it to
> > identify a fileserver, appserver, etc; basically, you can not -use-
> > these addresses for anything that is not based on dynamic polling.
>
> Dynamic or Multicast DNS (a.k.a. Bonjour, Avahi etc.) would provide name
> resolution for them if you where using them for more general
> applications communication. It would be possible to make generating and
> configuring the unique link local subnet ID manual, however I think
> it'd be worth making it automated and agreed, so that IPv6 on the local
> link autoconfigures itself (to easily facilitate the the IPv6 "dentist's
> office" scenario).
>
> They'd be functionally like ULAs, except that they wouldn't be routable
> off-link (a useful security property), and have a separately designated
> prefix so that if necessary they can be identified in places where the
> identifying the type of prefix and it's reachability is useful or
> necessary.

So you have basically a zeroconf situation, but with hosts with multiple
network interfaces onto distinct security zone networks, and you combine
security measures at network prefix level with dynamic prefixes.

These combinations do not strike me as particularily .. wise.

If you do not have scope, how do you know you're not putting access to the
patient database (staying with the dentists office, here) onto the wlan
that's open so waiting patients can keep themselves amused?

regards,
spz
--
spz [at] serpens (S.P.Zeidler)

First page Previous page 1 2 Next page Last page  View All nsp ipv6 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.