[Starlink] Measuring the Satellite Links of a LEO Network

[Starlink] Measuring the Satellite Links of a LEO Network

[J Pan]

http://pan.uvic.ca/webb/viewtopic.php?p=124670#p124670 to appear at
ieee icc 2024. feedback welcome, especially during the camera-ready
stage this week. thanks!  -j
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

Re: [Starlink] Measuring the Satellite Links of a LEO Network

[Alexandre Petrescu]

this is an issue for 6MAN WG at IETF, but this is the text with the 
issue in the paper:

> From the user device or customer router at 192.168.1.1,
> we can reach its GS gateway at 100.64.0.1 (or equivalently
> fe80::200:5eff:fe00:101 for IPv6)

That IPv6 link-local address has an 'ff:fe' in it; the prefix is 'fe80' 
and the rest is an 'Interface ID', in RFC parlance.

That IID should be more random in its appearance.  It is called an 
'opaque' IID, and specified in RFC 7217 "Stable and Opaque IIDs with 
SLAAC" of year 2014.

That IPv6 address corresponds to earlier forms of these IIDs (RFC2464 of 
year 1998); they had that IID to be derived from a 48bit MAC address and 
inserted an 'ff:fe' string in it to become 64bit.

Most embedded linux platforms (v2.x kernels?) still use that ff:fe.  
Migrating these kernels is sometimes very difficult.  One might not want 
to migrate an kernel to a bloated and slower v3 or higher just for that 
little 'ff:fe'.  Maybe one wants to migrate just its IPv6 stack, but 
it's not easy.

The reason of making this IID more opaque is to resist scanning 
attacks.  A scanning attack is when a user might have somehow an 
illegitimate starlink terminal and tries to connect to the legitimate 
starlink network.  Part of that trying is to know the IP address of the 
next hop.  With IPv6 it comes down to testing all these addresses.  If 
they have a constant 'ff:fe' in them, it is easier to find them by brute 
force than if they were opaque.  It is also true that if in IPv4 that 
next hop is always the same then the easiest attack is to simply use 
IPv4 instead of IPv6.  But this 'opaqueness' of the IID in the IPv6 ll 
address might still be needed when IPv4 is get rid of.

This could be discussed at IETF, could be suggested to starlink to 
upgrade, etc.

Alex

Le 12/02/2024 à 07:59, J Pan via Starlink a écrit :
> http://pan.uvic.ca/webb/viewtopic.php?p=124670#p124670 to appear at
> ieee icc 2024. feedback welcome, especially during the camera-ready
> stage this week. thanks!  -j
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Measuring the Satellite Links of a LEO Network

[J Pan]

yes, the mac for fe80::200:5eff:fe00:101 is 00:00:5e:00:01:01 (a
virtual mac used by the virtual router redundancy protocol commonly
used by service providers in point-of-presence?)
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan

On Mon, Feb 12, 2024 at 6:14 AM Alexandre Petrescu via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> this is an issue for 6MAN WG at IETF, but this is the text with the
> issue in the paper:
>
> > From the user device or customer router at 192.168.1.1,
> > we can reach its GS gateway at 100.64.0.1 (or equivalently
> > fe80::200:5eff:fe00:101 for IPv6)
>
> That IPv6 link-local address has an 'ff:fe' in it; the prefix is 'fe80'
> and the rest is an 'Interface ID', in RFC parlance.
>
> That IID should be more random in its appearance.  It is called an
> 'opaque' IID, and specified in RFC 7217 "Stable and Opaque IIDs with
> SLAAC" of year 2014.
>
> That IPv6 address corresponds to earlier forms of these IIDs (RFC2464 of
> year 1998); they had that IID to be derived from a 48bit MAC address and
> inserted an 'ff:fe' string in it to become 64bit.
>
> Most embedded linux platforms (v2.x kernels?) still use that ff:fe.
> Migrating these kernels is sometimes very difficult.  One might not want
> to migrate an kernel to a bloated and slower v3 or higher just for that
> little 'ff:fe'.  Maybe one wants to migrate just its IPv6 stack, but
> it's not easy.
>
> The reason of making this IID more opaque is to resist scanning
> attacks.  A scanning attack is when a user might have somehow an
> illegitimate starlink terminal and tries to connect to the legitimate
> starlink network.  Part of that trying is to know the IP address of the
> next hop.  With IPv6 it comes down to testing all these addresses.  If
> they have a constant 'ff:fe' in them, it is easier to find them by brute
> force than if they were opaque.  It is also true that if in IPv4 that
> next hop is always the same then the easiest attack is to simply use
> IPv4 instead of IPv6.  But this 'opaqueness' of the IID in the IPv6 ll
> address might still be needed when IPv4 is get rid of.
>
> This could be discussed at IETF, could be suggested to starlink to
> upgrade, etc.
>
> Alex
>
> Le 12/02/2024 à 07:59, J Pan via Starlink a écrit :
> > http://pan.uvic.ca/webb/viewtopic.php?p=124670#p124670 to appear at
> > ieee icc 2024. feedback welcome, especially during the camera-ready
> > stage this week. thanks!  -j
> > --
> > J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Measuring the Satellite Links of a LEO Network

[Alexandre Petrescu]

Le 13/02/2024 à 18:12, J Pan a écrit :
> yes, the mac for fe80::200:5eff:fe00:101 is 00:00:5e:00:01:01 (a
> virtual mac used by the virtual router redundancy protocol commonly
> used by service providers in point-of-presence?)

Do you mean that VRRP requires the use of that MAC address?

In that case, the VRRP spec (RFC) should be clear that the IPv6 address 
_must not_ use that MAC address to form a link-local address, and rather 
use opaque IIDs.

I mean, where the the VRRP RFC5798 tells

OLD:

> IPv6 routers running VRRP MUST create their Interface Identifiers in
>     the normal manner (e.g., "Transmission of IPv6 Packets over Ethernet
>     Networks" [RFC2464  <https://www.rfc-editor.org/rfc/rfc2464>]).

it should tell

NEW:

> IPv6 routers running VRRP MUST create their Interface Identifiers in
>     the normal manner, that is RFC7217 "A Method for Generating Semantically Opaque Interface Identifiers
>           with IPv6 Stateless Address Autoconfiguration (SLAAC)" (it includes link-local address formation).

Hopefully starlink agrees with it and implements it before we blink :-)

Alex

> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>
> On Mon, Feb 12, 2024 at 6:14 AM Alexandre Petrescu via Starlink
> <starlink@lists.bufferbloat.net> wrote:
>> this is an issue for 6MAN WG at IETF, but this is the text with the
>> issue in the paper:
>>
>>>  From the user device or customer router at 192.168.1.1,
>>> we can reach its GS gateway at 100.64.0.1 (or equivalently
>>> fe80::200:5eff:fe00:101 for IPv6)
>> That IPv6 link-local address has an 'ff:fe' in it; the prefix is 'fe80'
>> and the rest is an 'Interface ID', in RFC parlance.
>>
>> That IID should be more random in its appearance.  It is called an
>> 'opaque' IID, and specified in RFC 7217 "Stable and Opaque IIDs with
>> SLAAC" of year 2014.
>>
>> That IPv6 address corresponds to earlier forms of these IIDs (RFC2464 of
>> year 1998); they had that IID to be derived from a 48bit MAC address and
>> inserted an 'ff:fe' string in it to become 64bit.
>>
>> Most embedded linux platforms (v2.x kernels?) still use that ff:fe.
>> Migrating these kernels is sometimes very difficult.  One might not want
>> to migrate an kernel to a bloated and slower v3 or higher just for that
>> little 'ff:fe'.  Maybe one wants to migrate just its IPv6 stack, but
>> it's not easy.
>>
>> The reason of making this IID more opaque is to resist scanning
>> attacks.  A scanning attack is when a user might have somehow an
>> illegitimate starlink terminal and tries to connect to the legitimate
>> starlink network.  Part of that trying is to know the IP address of the
>> next hop.  With IPv6 it comes down to testing all these addresses.  If
>> they have a constant 'ff:fe' in them, it is easier to find them by brute
>> force than if they were opaque.  It is also true that if in IPv4 that
>> next hop is always the same then the easiest attack is to simply use
>> IPv4 instead of IPv6.  But this 'opaqueness' of the IID in the IPv6 ll
>> address might still be needed when IPv4 is get rid of.
>>
>> This could be discussed at IETF, could be suggested to starlink to
>> upgrade, etc.
>>
>> Alex
>>
>> Le 12/02/2024 à 07:59, J Pan via Starlink a écrit :
>>> http://pan.uvic.ca/webb/viewtopic.php?p=124670#p124670 to appear at
>>> ieee icc 2024. feedback welcome, especially during the camera-ready
>>> stage this week. thanks!  -j
>>> --
>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Measuring the Satellite Links of a LEO Network

[Alexandre Petrescu]

or maybe the VRRP people dont want that address to be opaque at all, I 
dont know.


Le 13/02/2024 à 18:39, Alexandre Petrescu via Starlink a écrit :
>
> Le 13/02/2024 à 18:12, J Pan a écrit :
>> yes, the mac for fe80::200:5eff:fe00:101 is 00:00:5e:00:01:01 (a
>> virtual mac used by the virtual router redundancy protocol commonly
>> used by service providers in point-of-presence?)
>
> Do you mean that VRRP requires the use of that MAC address?
>
> In that case, the VRRP spec (RFC) should be clear that the IPv6 
> address _must not_ use that MAC address to form a link-local address, 
> and rather use opaque IIDs.
>
> I mean, where the the VRRP RFC5798 tells
>
> OLD:
>
>> IPv6 routers running VRRP MUST create their Interface Identifiers in
>>     the normal manner (e.g., "Transmission of IPv6 Packets over Ethernet
>>     Networks" [RFC2464 <https://www.rfc-editor.org/rfc/rfc2464>]).
>
> it should tell
>
> NEW:
>
>> IPv6 routers running VRRP MUST create their Interface Identifiers in
>>     the normal manner, that is RFC7217 "A Method for Generating 
>> Semantically Opaque Interface Identifiers
>>           with IPv6 Stateless Address Autoconfiguration (SLAAC)" (it 
>> includes link-local address formation).
>
> Hopefully starlink agrees with it and implements it before we blink :-)
>
> Alex
>
>> -- 
>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, 
>> Web.UVic.CA/~pan
>>
>> On Mon, Feb 12, 2024 at 6:14 AM Alexandre Petrescu via Starlink
>> <starlink@lists.bufferbloat.net> wrote:
>>> this is an issue for 6MAN WG at IETF, but this is the text with the
>>> issue in the paper:
>>>
>>>>  From the user device or customer router at 192.168.1.1,
>>>> we can reach its GS gateway at 100.64.0.1 (or equivalently
>>>> fe80::200:5eff:fe00:101 for IPv6)
>>> That IPv6 link-local address has an 'ff:fe' in it; the prefix is 'fe80'
>>> and the rest is an 'Interface ID', in RFC parlance.
>>>
>>> That IID should be more random in its appearance.  It is called an
>>> 'opaque' IID, and specified in RFC 7217 "Stable and Opaque IIDs with
>>> SLAAC" of year 2014.
>>>
>>> That IPv6 address corresponds to earlier forms of these IIDs 
>>> (RFC2464 of
>>> year 1998); they had that IID to be derived from a 48bit MAC address 
>>> and
>>> inserted an 'ff:fe' string in it to become 64bit.
>>>
>>> Most embedded linux platforms (v2.x kernels?) still use that ff:fe.
>>> Migrating these kernels is sometimes very difficult.  One might not 
>>> want
>>> to migrate an kernel to a bloated and slower v3 or higher just for that
>>> little 'ff:fe'.  Maybe one wants to migrate just its IPv6 stack, but
>>> it's not easy.
>>>
>>> The reason of making this IID more opaque is to resist scanning
>>> attacks.  A scanning attack is when a user might have somehow an
>>> illegitimate starlink terminal and tries to connect to the legitimate
>>> starlink network.  Part of that trying is to know the IP address of the
>>> next hop.  With IPv6 it comes down to testing all these addresses.  If
>>> they have a constant 'ff:fe' in them, it is easier to find them by 
>>> brute
>>> force than if they were opaque.  It is also true that if in IPv4 that
>>> next hop is always the same then the easiest attack is to simply use
>>> IPv4 instead of IPv6.  But this 'opaqueness' of the IID in the IPv6 ll
>>> address might still be needed when IPv4 is get rid of.
>>>
>>> This could be discussed at IETF, could be suggested to starlink to
>>> upgrade, etc.
>>>
>>> Alex
>>>
>>> Le 12/02/2024 à 07:59, J Pan via Starlink a écrit :
>>>> http://pan.uvic.ca/webb/viewtopic.php?p=124670#p124670 to appear at
>>>> ieee icc 2024. feedback welcome, especially during the camera-ready
>>>> stage this week. thanks!  -j
>>>> -- 
>>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, 
>>>> Web.UVic.CA/~pan
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Measuring the Satellite Links of a LEO Network

[Alexandre Petrescu]

Le 13/02/2024 à 18:12, J Pan a écrit :
> yes, the mac for fe80::200:5eff:fe00:101 is 00:00:5e:00:01:01 (a
> virtual mac used by the virtual router redundancy protocol commonly
> used by service providers in point-of-presence?)

maybe they should rather use the IPv6 anycast concept?

Alex

> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>
> On Mon, Feb 12, 2024 at 6:14 AM Alexandre Petrescu via Starlink
> <starlink@lists.bufferbloat.net> wrote:
>> this is an issue for 6MAN WG at IETF, but this is the text with the
>> issue in the paper:
>>
>>>  From the user device or customer router at 192.168.1.1,
>>> we can reach its GS gateway at 100.64.0.1 (or equivalently
>>> fe80::200:5eff:fe00:101 for IPv6)
>> That IPv6 link-local address has an 'ff:fe' in it; the prefix is 'fe80'
>> and the rest is an 'Interface ID', in RFC parlance.
>>
>> That IID should be more random in its appearance.  It is called an
>> 'opaque' IID, and specified in RFC 7217 "Stable and Opaque IIDs with
>> SLAAC" of year 2014.
>>
>> That IPv6 address corresponds to earlier forms of these IIDs (RFC2464 of
>> year 1998); they had that IID to be derived from a 48bit MAC address and
>> inserted an 'ff:fe' string in it to become 64bit.
>>
>> Most embedded linux platforms (v2.x kernels?) still use that ff:fe.
>> Migrating these kernels is sometimes very difficult.  One might not want
>> to migrate an kernel to a bloated and slower v3 or higher just for that
>> little 'ff:fe'.  Maybe one wants to migrate just its IPv6 stack, but
>> it's not easy.
>>
>> The reason of making this IID more opaque is to resist scanning
>> attacks.  A scanning attack is when a user might have somehow an
>> illegitimate starlink terminal and tries to connect to the legitimate
>> starlink network.  Part of that trying is to know the IP address of the
>> next hop.  With IPv6 it comes down to testing all these addresses.  If
>> they have a constant 'ff:fe' in them, it is easier to find them by brute
>> force than if they were opaque.  It is also true that if in IPv4 that
>> next hop is always the same then the easiest attack is to simply use
>> IPv4 instead of IPv6.  But this 'opaqueness' of the IID in the IPv6 ll
>> address might still be needed when IPv4 is get rid of.
>>
>> This could be discussed at IETF, could be suggested to starlink to
>> upgrade, etc.
>>
>> Alex
>>
>> Le 12/02/2024 à 07:59, J Pan via Starlink a écrit :
>>> http://pan.uvic.ca/webb/viewtopic.php?p=124670#p124670 to appear at
>>> ieee icc 2024. feedback welcome, especially during the camera-ready
>>> stage this week. thanks!  -j
>>> --
>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Measuring the Satellite Links of a LEO Network

[Alexandre Petrescu]

sorry, it could be that I have it on the wrong side.

If VRRP and starlink like to have that IPv6 LL address with ff:fe 
inside, and always constant, so be it.  There might be some reasons for 
it to be that way.

Alex

Le 13/02/2024 à 18:44, Alexandre Petrescu via Starlink a écrit :
>
> Le 13/02/2024 à 18:12, J Pan a écrit :
>> yes, the mac for fe80::200:5eff:fe00:101 is 00:00:5e:00:01:01 (a
>> virtual mac used by the virtual router redundancy protocol commonly
>> used by service providers in point-of-presence?)
>
> maybe they should rather use the IPv6 anycast concept?
>
> Alex
>
>> -- 
>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, 
>> Web.UVic.CA/~pan
>>
>> On Mon, Feb 12, 2024 at 6:14 AM Alexandre Petrescu via Starlink
>> <starlink@lists.bufferbloat.net> wrote:
>>> this is an issue for 6MAN WG at IETF, but this is the text with the
>>> issue in the paper:
>>>
>>>>  From the user device or customer router at 192.168.1.1,
>>>> we can reach its GS gateway at 100.64.0.1 (or equivalently
>>>> fe80::200:5eff:fe00:101 for IPv6)
>>> That IPv6 link-local address has an 'ff:fe' in it; the prefix is 'fe80'
>>> and the rest is an 'Interface ID', in RFC parlance.
>>>
>>> That IID should be more random in its appearance.  It is called an
>>> 'opaque' IID, and specified in RFC 7217 "Stable and Opaque IIDs with
>>> SLAAC" of year 2014.
>>>
>>> That IPv6 address corresponds to earlier forms of these IIDs 
>>> (RFC2464 of
>>> year 1998); they had that IID to be derived from a 48bit MAC address 
>>> and
>>> inserted an 'ff:fe' string in it to become 64bit.
>>>
>>> Most embedded linux platforms (v2.x kernels?) still use that ff:fe.
>>> Migrating these kernels is sometimes very difficult.  One might not 
>>> want
>>> to migrate an kernel to a bloated and slower v3 or higher just for that
>>> little 'ff:fe'.  Maybe one wants to migrate just its IPv6 stack, but
>>> it's not easy.
>>>
>>> The reason of making this IID more opaque is to resist scanning
>>> attacks.  A scanning attack is when a user might have somehow an
>>> illegitimate starlink terminal and tries to connect to the legitimate
>>> starlink network.  Part of that trying is to know the IP address of the
>>> next hop.  With IPv6 it comes down to testing all these addresses.  If
>>> they have a constant 'ff:fe' in them, it is easier to find them by 
>>> brute
>>> force than if they were opaque.  It is also true that if in IPv4 that
>>> next hop is always the same then the easiest attack is to simply use
>>> IPv4 instead of IPv6.  But this 'opaqueness' of the IID in the IPv6 ll
>>> address might still be needed when IPv4 is get rid of.
>>>
>>> This could be discussed at IETF, could be suggested to starlink to
>>> upgrade, etc.
>>>
>>> Alex
>>>
>>> Le 12/02/2024 à 07:59, J Pan via Starlink a écrit :
>>>> http://pan.uvic.ca/webb/viewtopic.php?p=124670#p124670 to appear at
>>>> ieee icc 2024. feedback welcome, especially during the camera-ready
>>>> stage this week. thanks!  -j
>>>> -- 
>>>> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, 
>>>> Web.UVic.CA/~pan
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] Measuring the Satellite Links of a LEO Network

[Gert Doering]

Hi,

On Tue, Feb 13, 2024 at 07:11:16PM +0100, Alexandre Petrescu via Starlink wrote:
> sorry, it could be that I have it on the wrong side.
> 
> If VRRP and starlink like to have that IPv6 LL address with ff:fe inside,
> and always constant, so be it.  There might be some reasons for it to be that
> way.

It's not unusual to standardize IPv6 gateway addresses to have always
well-known fe80:: addresses (like, fe80::1).

There is nothing for an adversary to be gained here.  If you are on-link,
you know, and if you are not, anything fe80:: is of no use to you.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer,
                                           Ingo Lalla, Karin Schuler
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

Re: [Starlink] Measuring the Satellite Links of a LEO Network

[Alexandre Petrescu]

Le 03/03/2024 à 11:23, Gert Doering via Starlink a écrit :
> Hi,
>
> On Tue, Feb 13, 2024 at 07:11:16PM +0100, Alexandre Petrescu via Starlink wrote:
>> sorry, it could be that I have it on the wrong side.
>>
>> If VRRP and starlink like to have that IPv6 LL address with ff:fe inside,
>> and always constant, so be it.  There might be some reasons for it to be that
>> way.
> It's not unusual to standardize IPv6 gateway addresses to have always
> well-known fe80:: addresses (like, fe80::1).

I am not sure fe80::1 as a default route is standardized in an RFC, so 
to say?

I can agree though it is often used in practice.

> There is nothing for an adversary to be gained here.  If you are on-link,
> you know, and if you are not, anything fe80:: is of no use to you.

Yes, I agree.

Just that some times one can get on-link because one legitimately has 
the credentials, yet one does not know the default route, because it 
does not come from an RA but from a link-layer message exchange which 
might be difficult (impossible some times) to capture.

I am not saying it is good or bad, just I detail the perspective, for 
the sake of discussion.

Alex

>
> Gert Doering
>          -- NetMaster