RE: BCP38 For BGP Customers

[Ryan Hamel]

RPKI and IRR should be part of the prefix-list generation process, from there 
setup rpf-check with a fail-filter pointing to an ACL that allows source 
traffic matching the prefix-list and drops the rest. Although at that point you 
can just apply said ACL to the L3 interfaces supplying the BGP handoff.

 

Ryan

 

From: NANOG  On Behalf Of Mike Hammett
Sent: Monday, November 7, 2022 3:17 PM
To: Charles Rumford 
Cc: nanog@nanog.org
Subject: Re: BCP38 For BGP Customers

 

This may not exist yet, but what about a uRPF-like feature that uses RPKI, IRR, 
etc. instead of current BGP feed?

 

 



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

 

  _  

From: "Charles Rumford via NANOG" mailto:nanog@nanog.org> >
To: nanog@nanog.org  
Sent: Monday, November 7, 2022 10:47:54 AM
Subject: BCP38 For BGP Customers

Hello -

I'm are currently working on getting BCP38 filtering in place for our BGP 
customers. My current plan is to use the Juniper uRPF feature to filter out 
spoofed traffic based on the routing table. The mentality would be: "If you 
don't send us the prefix, then we don't accept the traffic". This has raised 
some issues amongst our network engineers regarding multi-homed customers.

One of the issues raised was if a multi-homed BGP customer revoked a prefix 
from 
one of their peerings, but continued sending us traffic on the link then we 
would drop the traffic.

I would like to hear what others are doing for BCP38 deployments for BGP 
customers. Are you taking the stance of "if you don't send us the prefix, then 
we don't accept the traffic"? Are you putting in some kind of fall back filter 
in based on something like IRR data?

Thanks!

-- 
Charles Rumford (he/his/him)
Network Engineer | Deft
1-312-268-9342 | charl...@deft.com  
deft.com

 

Re: BCP38 For BGP Customers

[Mike Hammett]

This may not exist yet, but what about a uRPF-like feature that uses RPKI, IRR, 
etc. instead of current BGP feed? 







- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Charles Rumford via NANOG"  
To: nanog@nanog.org 
Sent: Monday, November 7, 2022 10:47:54 AM 
Subject: BCP38 For BGP Customers 

Hello - 

I'm are currently working on getting BCP38 filtering in place for our BGP 
customers. My current plan is to use the Juniper uRPF feature to filter out 
spoofed traffic based on the routing table. The mentality would be: "If you 
don't send us the prefix, then we don't accept the traffic". This has raised 
some issues amongst our network engineers regarding multi-homed customers. 

One of the issues raised was if a multi-homed BGP customer revoked a prefix 
from 
one of their peerings, but continued sending us traffic on the link then we 
would drop the traffic. 

I would like to hear what others are doing for BCP38 deployments for BGP 
customers. Are you taking the stance of "if you don't send us the prefix, then 
we don't accept the traffic"? Are you putting in some kind of fall back filter 
in based on something like IRR data? 

Thanks! 

-- 
Charles Rumford (he/his/him) 
Network Engineer | Deft 
1-312-268-9342 | charl...@deft.com 
deft.com 

Re: BCP38 For BGP Customers

[William Herrin]

On Mon, Nov 7, 2022 at 12:30 PM Tony Wicks  wrote:
> use prefix lists to prevent your customer networks being received
> anywhere but directly from your customers to prevent them using
> your capacity without paying for it however.

Hi Tony,

Do not do this either as it will render your entire network
unreachable to your customer during an outage of their direct circuit.
Multihomed means you may legitimately receive their prefix
announcement from both their direct link and from your upstream
transit provider.

You CAN, tag announcements received directly from your customers with
a BGP community and then filter routes without that tag when offering
the announcement to your upstream transits. That will have the effect
you're looking for - preventing inappropriate free transit. This is
rarely necessary - unless your network is unusually complex the
additional AS path length of a rebroadcast announcement will generally
prevent such transrouting.

The problem tends to creep in when you have both reciprocal peers and
customers and then a customer's route announcement appears via the
peer. You have to make sure the announcement from the peer is neither
capable of being rebroadcast upstream nor capable of beating the
direct announcement when the direct announcement is present. That
takes some subtle work with BGP communities and route filtering. How
subtle? The routes from the peer may be more specific than the direct
routes.

Regards,
Bill Herrin




-- 
For hire. https://bill.herrin.us/resume/

Re: Why do ROV-ASes announce some invalid route?

[Randy Bush]

aside from technical reasons for an ROV-supporting AS (RAS) to announce
an ROV invalid prefix, there is an administrative one.  the RAS's
customers *pay* RAS to announce the customers' prefixes.  so RAS is
configured to propagate their customers' announcements without dropping
invalids.

randy

RE: BCP38 For BGP Customers

[Tony Wicks]

>For large BGP customers who service many BGP downstreams, the bottom line is 
>that BCP 38 cannot be reasonably implemented. It's one of the weaknesses in 
>the system.

Yes, from personal experience BCP 38 should never be implemented buy a transit 
provider as it will inevitably cause breakage on multi-homed downstream 
customers for little to no gain and a lot of customer anger. It should be 
implemented at the customer edge AS, so for a wholesale transit provider is 
more of a customer education situation.  By all means use prefix lists to 
prevent your customer networks being received anywhere but directly from your 
customers to prevent them using your capacity without paying for it however.

Re: BCP38 For BGP Customers

[William Herrin]

On Mon, Nov 7, 2022 at 8:47 AM Charles Rumford via NANOG
 wrote:
> I'm are currently working on getting BCP38 filtering in place for our BGP
> customers. My current plan is to use the Juniper uRPF feature to filter out
> spoofed traffic based on the routing table. The mentality would be: "If you
> don't send us the prefix, then we don't accept the traffic". This has raised
> some issues amongst our network engineers regarding multi-homed customers.

As it should. This plan will break asymmetric routing which is an
ordinary part of multihoming. Moreover, it would not actually
accomplish BCP 38 since the customer would be able to falsify route
announcements. So, basically a complete fail.

For a small BGP customer who has no downstreams of his own, implement
static filters based on the address ranges you have personally
authenticated as belonging to the customer. PERSONALLY AUTHENTICATED.
This means a manual process. The customer will have to
administratively inform you when those address ranges change.

For large BGP customers who service many BGP downstreams, the bottom
line is that BCP 38 cannot be reasonably implemented. It's one of the
weaknesses in the system.

Regards,
Bill Herrin



-- 
For hire. https://bill.herrin.us/resume/

Re: Geo-IP Sling.com and/or Dish Network Contact.

[Josh Luthman]

Did you update the block with those services listed in the link?  They
usually update ~weekly and of course there's a delay to the providers as
well.

On Fri, Nov 4, 2022 at 5:35 PM Jared Mauch  wrote:

> Anyone figure this out? Have a new block that works with everything else
> it seems but them and about to tell this customer to switch from their
> service.
>
> Or if someone knows why 23.138.114.0/24 would be geolocated outside
> US/Michigan would be great to know.
>
> Thanks!
>
> Sent via RFC1925 compliant device
>
> On May 11, 2022, at 10:35 AM, Josh Luthman 
> wrote:
>
> 
> Dish/Sling isn't on here but check this list:
>
> https://thebrotherswisp.com/index.php/geo-and-vpn/
>
> On Tue, May 10, 2022 at 5:18 PM Nicholas Warren 
> wrote:
>
>> Does anyone know how to get ahold of Sling.com or Dish to update location
>> information on IPv4 addresses?
>>
>> I don’t know if meta discussion is allowed on-list, but maybe geolocation
>> contacts could be listed on the community site? 
>>
>> - Nich Warren
>>
>

Random Early Detect and streaming video

[Graham Johnston]

I've been involved in service provider networks, small retail ISPs, for 20+
years now. Largely though, we've never needed complex QoS, as at
$OLD_DAY_JOB, we had been consistently positioned to avoid regular link
congestion by having sufficient capacity. In the few instances when we've
had link congestion, egress priority queuing met our needs. With a new
organization there is a set of circumstances that have resulted in a long
standing business decision to apply some rate-limiting/traffic management
during times of higher utilization to a subset of traffic. This traffic
happens to be ABR streaming video traffic. The thought was that a little
bit of packet loss that comes from RED or WRED could largely be absorbed in
the ABR playback client's innate behavior, and yes, possibly a drop in
video profile. These are acceptable business outcomes in this case. The
question I have for the smart people of this list is, given the specific
application that is receiving this treatment, is there any reason to apply
a RED behavior any appreciable amount before the bandwidth limit for this
application? It makes sense to me for interactive TCP traffic where you
want to apply some artificial control to the TCP window, but I *feel* like
ABR streaming video was designed to expect congestion, at least as the edge
of the customers home, and combine that with the buffering and we should
adjust the drop profile to kick in at a higher percentage. Today we use 70%
to start triggering the drop behavior, but my head tells me it should be
higher. The reason I am saying this is that we are dropping packets ahead
of full link congestion, yes that is what RED was designed to do, but I
surmise that we are making this application worse than is actually intended.

Hopefully my targeted vagurey has still left enough context intact to
receive some useful commentary back.

Thanks

Re: BCP38 For BGP Customers

[Chris Adams]

Once upon a time, Charles Rumford  said:
> I would like to hear what others are doing for BCP38 deployments for
> BGP customers. Are you taking the stance of "if you don't send us
> the prefix, then we don't accept the traffic"? Are you putting in
> some kind of fall back filter in based on something like IRR data?

In the case of Juniper, you can use the same prefix-list in your BGP
policy (you are applying a filter to your customers' BGP announcements,
right?) and the uRPF exception list.

-- 
Chris Adams 

Re: BCP38 For BGP Customers

[Tom Beecher]

>
> Are you taking the stance of "if you don't send us the prefix, then
> we don't accept the traffic"?
>

If you were one of my upstreams, and you implemented that, you would very
quickly no longer be one of my upstreams.



On Mon, Nov 7, 2022 at 2:22 PM Charles Rumford via NANOG 
wrote:

> Hello -
>
> I'm are currently working on getting BCP38 filtering in place for our BGP
> customers. My current plan is to use the Juniper uRPF feature to filter
> out
> spoofed traffic based on the routing table. The mentality would be: "If
> you
> don't send us the prefix, then we don't accept the traffic". This has
> raised
> some issues amongst our network engineers regarding multi-homed customers.
>
> One of the issues raised was if a multi-homed BGP customer revoked a
> prefix from
> one of their peerings, but continued sending us traffic on the link then
> we
> would drop the traffic.
>
> I would like to hear what others are doing for BCP38 deployments for BGP
> customers. Are you taking the stance of "if you don't send us the prefix,
> then
> we don't accept the traffic"? Are you putting in some kind of fall back
> filter
> in based on something like IRR data?
>
> Thanks!
>
> --
> Charles Rumford (he/his/him)
> Network Engineer | Deft
> 1-312-268-9342 | charl...@deft.com
> deft.com
>

Re: BCP38 For BGP Customers

[Matt Harris]

Hey Charles,
My recommendation would not be to run uRPF facing a BGP customer.

That said, you have two issues to address here: one is the acceptance of
prefix advertisements, and the other is the acceptance of traffic.

uRPF does nothing to help with the former, and the gold standard there is
generally considered to be RPKI. IRR based filtering is another reasonable
way to filter prefix advertisements you receive, and several well-known
IX's and transit providers for example do just this.

The latter, acceptance of traffic, is a broader challenge. In essence, you
don't really have a good way to know what traffic is legitimate and what
isn't. My advice would be simply to watch for things you don't expect, log
them when they occur in significant quantity, and manually review incidents
that are unexpected to understand why. If you cannot understand why, then
you can work with the client sending the traffic to try to understand it,
or block that specific traffic from that specific client. uRPF on a client
circuit raises exactly the issues you've already raised. Many clients, even
smaller ones, who choose to run BGP sessions with transit providers will
wish to be able to employ common TE practices, and by deploying uRPF, you
may very well be creating a nasty situation for them which potentially is
also difficult for smaller shops without high end tooling in place to
diagnose easily.

- mdh


On Mon, Nov 7, 2022 at 1:22 PM Charles Rumford via NANOG 
wrote:

> Hello -
>
> I'm are currently working on getting BCP38 filtering in place for our BGP
> customers. My current plan is to use the Juniper uRPF feature to filter
> out
> spoofed traffic based on the routing table. The mentality would be: "If
> you
> don't send us the prefix, then we don't accept the traffic". This has
> raised
> some issues amongst our network engineers regarding multi-homed customers.
>
> One of the issues raised was if a multi-homed BGP customer revoked a
> prefix from
> one of their peerings, but continued sending us traffic on the link then
> we
> would drop the traffic.
>
> I would like to hear what others are doing for BCP38 deployments for BGP
> customers. Are you taking the stance of "if you don't send us the prefix,
> then
> we don't accept the traffic"? Are you putting in some kind of fall back
> filter
> in based on something like IRR data?
>
> Thanks!
>
> --
> Charles Rumford (he/his/him)
> Network Engineer | Deft
> 1-312-268-9342 | charl...@deft.com
> deft.com
>

Matt Harris
VP OF INFRASTRUCTURE
Follow us on LinkedIn!
matt.har...@netfire.net
816-256-5446
www.netfire.com

BCP38 For BGP Customers

[Charles Rumford via NANOG]

Hello -

I'm are currently working on getting BCP38 filtering in place for our BGP 
customers. My current plan is to use the Juniper uRPF feature to filter out 
spoofed traffic based on the routing table. The mentality would be: "If you 
don't send us the prefix, then we don't accept the traffic". This has raised 
some issues amongst our network engineers regarding multi-homed customers.


One of the issues raised was if a multi-homed BGP customer revoked a prefix from 
one of their peerings, but continued sending us traffic on the link then we 
would drop the traffic.


I would like to hear what others are doing for BCP38 deployments for BGP 
customers. Are you taking the stance of "if you don't send us the prefix, then 
we don't accept the traffic"? Are you putting in some kind of fall back filter 
in based on something like IRR data?


Thanks!

--
Charles Rumford (he/his/him)
Network Engineer | Deft
1-312-268-9342 | charl...@deft.com
deft.com

Re: Why do ROV-ASes announce some invalid route?

[Job Snijders via NANOG]

Dear 孙乐童,

On Mon, Nov 07, 2022 at 08:40:57PM +0800, 孙乐童 wrote:
> We learned from Cloudflare's https://isbgpsafeyet.com/ that some ASes
> have deployed RPKI Origin Validation (ROV). However, we downloaded BGP
> collection data from RouteViews and RipeRis platforms and found that
> some ROV-ASes can announce some invalid routes. For example, from RIB
> data at 2022-10-31 00:00:00, 13 out of 17 ASes which declared to
> deploy ROV announced invalid routes, and we list the number of related
> prefixes for each AS below.
>
> [snip]
> 
> As a comparison, we count the invalid routes the non-ROV ASes (also
> declared in https://isbgpsafeyet.com/) announces, as below:
> 
> We can see that ROV ASes announced apparently fewer invalid routes
> compared to the non-ROV ASes, though they did not filter all the
> invalids. 
>
> [snip]
> 
> Can anyone help us to correctly interpret this case? Thank you very much.

You ask great questions! I hope an answer to your questions can be found
in a message I sent a year ago:

https://mailman.nanog.org/pipermail/nanog/2021-April/213346.html

The summary: in any sufficiently large network, chances are not 100% of
all equipment supports RPKI-based BGP Route Origin Validation; in such
cases a handful of invalid routes may still percolate through the
system. Another contributing factor might be certain types of software
upgrades; where ROV temporarily is disabled on one or more devices. Or
perhaps an ISP made a handful of exceptions for test/beacon invalid
routes to propagate.

Kind regards,

Job 

Re: Jon Postel Re: 202210301538.AYC

[Joel Jaeggli]

some minor observations from the vantage point of a former AD inline.

On 11/2/22 17:48, Donald Eastlake wrote:

On Mon, Oct 31, 2022 at 12:03 PM Vasilenko Eduard
 wrote:

It is believed by many that 2 terms should be the maximum for one position of 
any chair (if it is a democracy).

Although this isn't a written guideline, many people believe that the
first 2 years in an Area Director position are sort of a probationary
period and as long as the AD does adequately, they should normally be
continued for a 2nd term, if they want it. Being continued for a 3rd
or later term should only be for superior performance and in the
absence of an apparently stronger alternative. Note the following


In my observed experience, it pretty much falls to a incumbent AD, to 
recruit alternatives, assuming they are doing a tolerable job of 
addressing the needs of their working groups. having done my 2 terms I 
found the role to be more one of middle management then of leadership, 
with the possible exception  of organizing and promoting new work 
organization around BOFs and working group formation.


ADs are highly dependent on WG chairs and senior individual contributors 
when it comes to advancing any particular activity.



-- Having served in one capacity or another on six Nomcoms over the
30 year history of the Nomcom system and I can assure you that there
are always at least 1 or 2 positions for which the Nomcom, after the
normal nomination period, has only zero or one possibilities to choose
between and it is common for NomCom to have to engage in substantial
recruiting (aka "arm twisting") to get more nominees from which to
choose. I just checked the NomCom pages and right now there are three
positions where, for the 2022-2024 term, the current NomCom has only
one person who has been nominated and agreed to run. So it isn't like
they have a vast pool of willing people to choose between.
-- Most former Area Directors say that there is a substantial
learning curve and it takes about a year before you are fully
effective as an Area Director. So, if ADs were limited to 1 term of 2
years, the IESG would only be 50 to 75% effective. With 2 terms of 2
years, it is more like 75 to 88% effective.


Also, serving as an AD is significantly detrimental to one's  own work 
in the IETF, both from a time perspective and respecting any chair, or 
other positions in one's area that you would give up in the process. As 
a volunteer activity there is a significant community service aspect too 
it. Unless your career goals involve a sympathetic employer and a goal 
of joining and staying in internet governance long term ADship has a 
significant impact on your ability to contribute to the IETF. I did my 4 
years, that was enough.




Furthermore, most Areas of the IETF have two co-ADs who tend to
moderate each other and many decisions are made by the IESG, which
consists of all the ADs, which is a further moderating effect.


It is evidently not the case for IETF - people stay in power for decades. It is 
just a fact that is not possible to dispute.
Yes, Nomcom is the mechanism for AD and above. I do not want to sort out how 
exactly it is performed.

Well, the NomCom system is well documented in a number of RFCs.

The most powerful single position in the IETF is the IETF Chair. As
you can see from the attached image only one person has served as IETF
Chair for as long as 8 years but as soon as the nomcom system was
started, they were replaced. After that, only one other person served
as long as 6 years, which was Russ Housley who I think was a
particularly good IETF Chair. All others have been limited to 2 or 4
years (1 or 2 terms). It would take a lot more work to do a similar
analysis for AD positions but I believe you would find that the length
of time in office for ADs was longer in the early days of the IETF and
is now rarely over 6 years.

In an earlier message, you said something about people retaining
positions due to networking with other people. Well, I would say that
is characteristic of all human organizations (unless you go with
strict Sortition). See my RFC 4144 "How to Gain Prominence and
Influence in Standards Organizations".


The IETF as a whole has activities (Working Groups) whose productivity 
on a given topic is largely driven by a small number of  individual 
contributors, these folks are entirely self-selected (authors, editors, 
collaborators, implentors). While there is not doubt quite a bit of 
survivor bias, networking and well as the capacity to be present (in 
person, remote) are necessary and rather expensive parts of advancing 
given pieces of work.






By the way, WG chairs have been put aside from any election mechanisms.

Yes, there are people who have served as co-Chair of an IETF Working
Group for long periods of time and there is currently no specific term
of office for a WG Chair. But these days most IETF WGs have two
co-Chairs, which has a moderating influence. Furthermore, Area

Why do ROV-ASes announce some invalid route?

[孙乐童]

We learned from Cloudflare's https://isbgpsafeyet.com/ that some ASes have 
deployed RPKI Origin Validation (ROV). However, we downloaded BGP collection 
data from RouteViews and RipeRis platforms and found that some ROV-ASes can 
announce some invalid routes. For example, from RIB data at 2022-10-31 
00:00:00, 13 out of 17 ASes which declared to deploy ROV announced invalid 
routes, and we list the number of related prefixes for each AS below.
ASN  33561299174291469393257645334919002551179221333516509
pref#723314361152731625617105


As a comparison, we count the invalid routes the non-ROV ASes (also declared in 
https://isbgpsafeyet.com/) announces, as below:
ASN67626461127312956123892048570174739009
pref#59760358711161162559492380


We can see that ROV ASes announced apparently fewer invalid routes compared to 
the non-ROV ASes, though they did not filter all the invalids. 
AS6939 announced apparently more invalid routes compared with other ROV-ASes. 
We learned from the discussions two years ago 
(https://mailman.nanog.org/pipermail/nanog/2020-June/108309.html) that AS6939 
uses reactive ROV. I.e., route collectors identify invalid routes, write them 
into scripts and send to routers, who then send "withdrawals" of the invalids 
based on the scripts.
However, for the BGP collection time 2022-10-31 00:00:00, we downloaded the 
two-hour updates afterwards, and found very few withdrawals from AS6939 about 
those invalid routes in the first hour. In the second hour, AS6939 withdraws 
hundreds of invalid prefixes, but most of these withdraws are followed by 
another invalid announcement with the same prefix and same invalid origin AS.


Can anyone help us to correctly interpret this case? Thank you very much.

Re: Jon Postel Re: 202210301538.AYC

[William Allen Simpson]

On 11/5/22 8:19 AM, Masataka Ohta wrote:

William Allen Simpson wrote:


Something similar happened with IPv6.  Cisco favored a design where only
they had the hardware mechanism for high speed forwarding.  So we're
stuck with 128-bit addresses and separate ASNs.





Given that high speed forwarding at that time meant TCAM,
difference between 128 bit address should mean merely twice
more TCAM capacity than 64 bit address.



Carrying the ASN in every packet, going back to my Practical
Internet Protocol Extensions (PIPE) draft that was merged into
SIP->SIPP, meant there was no need for Content Addressable Memory.

And was closer to the original Internet Protocol design of smart
edges with dumber switches.

Reminder, PIPE was 1992.  We'd barely deployed BGP.



I think the primary motivation for 128 bit was to somehow
encode NSAP addresses into IPng ones as is exemplified
by RFC1888. 


Probably as many motivations as there were members of the IESG.
Telcos wanted their addresses, some hardware vendors wanted
IEEE addresses.

But several vendors seemed very intent on using the standards
process for putting competitors out of business.



Though the motivation does not make any
engineering sense, IPv6 neither.



Not much about the IPv6 result makes any sense.  I'd reserved v6.
For a long time, I've been rather irritated that it was used for
purposes so far from my design intent.

Offline contact for MS Windows network stack dev? (Win10 IPv6 bug Q.)

[Nathan Anderson]

Not sure this is the best place to ask, but I'm not sure where else to go at 
this point...  I'm trying to find somebody on the Windows development team that 
might be able & willing to help me track down some info on a bizarre IPv6 bug 
I've been chasing in Win10 & its related fix.

I can confirm the bug in question was silently fixed somewhere in between 
10.0.18362.657 and 10.0.18362.693 and that it seems to be within the tcpip.sys 
component, but the release notes for KB4535996 make zero mention of it.  The 
fix has also seemingly never been backported to LTSC 2019.

Essentially the problem is that, in a dual-stack environment, if a DNS lookup 
returns both an A and an  record, Windows will prefer to make a connection 
to the target host via v4, claiming that it chose to do so because it is 
"Prefer[ring] [the] Aoac Interface", as if the given network interface only 
supports Connected/Modern Standby for IPv4 and not v6.  Despite this, with the 
exact same drivers on the exact same host with the exact same hardware & 
network interfaces connected to the exact same LAN, the seemingly-fixed 
tcpip.sys no longer behaves this way.  (It actually even works on "buggy" 
tcpip.sys after a fresh reboot, but only for some undefined amount of time 
before it reverts to this behavior.  My theory is the codepath that is causing 
this is only *supposed* to be followed while the PC is *actually* asleep & not 
during normal operation, but some bit in memory is getting flipped when some 
event occurs, and the logic that is taking this particular bit into account is 
faulty.)

If anybody can put me in touch with somebody who can pull a changelog of 
tcpip.sys between those two versions, I'd really appreciate it!  I'm just 
trying to better understand the exact nature of the bug & the fix, since a 
NetTrace would implicate buggy network interface drivers, but that clearly 
can't be the whole story.  And I'd like to figure out if a workaround is 
available for still-supported Windows versions that do not incorporate the 
actual fix (e.g., some registry entry that will make Windows ignore the 
freaking AOAC support reported by the network interface driver...the NetTrace 
entry implies Windows is following RFC 6724 and that it is considering the IPv6 
destination to be "unreachable" [merely because of lack of AOAC support in the 
driver for IPv6?!], which is clearly not the case).

Thanks!

-- 
Nathan Anderson
First Step Internet, LLC
nath...@fsr.com