Subject: [Int-area] Revving draft-intarea-shared-addressing-issues

From: Matthew Ford <[email-masked]>
Date: Thu, 10 Jun 2010 14:00:03 +0100

Hi,

I'd like to revise draft-intarea-shared-addressing-issues in time for IETF78. I've listed the comments I've received since the previous version was submitted and presented in Anaheim below. Before I put keyboard to xml, are there any further comments on the current document?

 o Augment the table in §3 to include a column identifying whether the issues apply to NAT44.

 o Add a section taking a content provider as an example of a 3rd party, and detail the issues that apply specifically.

 o Add some text to clarify that whether we're talking about DS-LITE, NAT64 or NAT444 isn't especially important - it's the view from the outside that matters, and given that, most of the issues apply regardless of the specific address sharing scenario in question.

 o Revise the first portion of §10 as follows:

"In many jurisdictions, service providers are legally obliged to provide the identity of a subscriber upon request to the appropriate authorities.  Where one public IPv4 address is shared between several subscribers, the knowledge of the IP address alone is not enough to identify the appropriate subscriber.  The legal request should include the information: [IP address - Port - Protocol- Begin_Timestamp - End_Timestamp]. Accurate time-keeping (e.g. use of NTP or SNTP) is vital because port assignments are dynamic.  A densely populated CGN could mean even very small amounts of clock skew between a content provider and the CGN operator will result in ambiguity about which customer was using a specific port at a given time.

Considering that it is unrealistic to expect all servers to start logging port information of connection attempts, address sharing service providers may need to start logging IP destination addresses as well, giving rise to privacy concerns.

If multiple subscribers are accessing the same (popular) server at nearly the same time, it can be impossible to disambiguate which subscriber accessed the server, especially with protocols that involve several connections (e.g. HTTP).  Thus, logging the destination address on the NAT is inferior to logging the source port at the server.

If the server is not logging source port numbers and the NAT is not logging destination IP addresses, the service provider  cannot trace the offending activity to a specific subscriber. In this circumstance, the service provider would need to disclose the identity of all subscribers who had active sessions on the NAT during the time period in question. This may be a large number of subscribers."

  - Mat

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Jun 2010 04:00:45 +1200

On 2010-06-11 01:00, Matthew Ford wrote:

...

> If the server is not logging source port numbers and the NAT
> is not logging destination IP addresses, the service provider
> cannot trace the offending activity to a specific subscriber.
> In this circumstance, the service provider would need to
> disclose the identity of all subscribers who had active
> sessions on the NAT during the time period in question. This
> may be a large number of subscribers."

I'm not a privacy expert, but this seems to raise an essentially
impossible-to-resolve conflict between privacy protection and
lawful intercept, in jurisdictions that have strong privacy
laws.

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Jun 2010 15:30:45 -0700

> -----Original Message-----
> From: Matthew Ford [mailto:[email-masked]] 
> Sent: Thursday, June 10, 2010 6:00 AM
> To: [email-masked]
> Cc: [email-masked]; Brian 
> E Carpenter; Lorenzo Colitti; Dan Wing
> Subject: Revving draft-intarea-shared-addressing-issues
> 
> Hi,
> 
> I'd like to revise draft-intarea-shared-addressing-issues in 
> time for IETF78. I've listed the comments I've received since 
> the previous version was submitted and presented in Anaheim 
> below. Before I put keyboard to xml, are there any further 
> comments on the current document?
> 
>  o Add a section taking a content provider as an example of a 
> 3rd party, and detail the issues that apply specifically.
> 
>  o Add some text to clarify that whether we're talking about 
> DS-LITE, NAT64 or NAT444 isn't especially important - it's 
> the view from the outside that matters, and given that, most 
> of the issues apply regardless of the specific address 
> sharing scenario in question.

That would be good.  Should be NAT44 (not "444"), though.  The
problem of IP address sharing is orthogonal to the subscriber
operating their own NAT in their house (which is one of the
4's of NAT444).

As another addition, do you perhaps want to point out that
all IP address sharing mechanisms (proposed to date) are
limited to TCP, UDP, and ICMP, thereby preventing end users 
from fully utilizing "The Internet" (e.g., SCTP, DCCP, 
RSVP, protocol 41 (IPv6-over-IPv4), protocol 50 (IPsec ESP)).

-d

> "In many jurisdictions, service providers are legally obliged 
> to provide the identity of a subscriber upon request to the 
> appropriate authorities.  Where one public IPv4 address is 
> shared between several subscribers, the knowledge of the IP 
> address alone is not enough to identify the appropriate 
> subscriber.  The legal request should include the 
> information: [IP address - Port - Protocol- Begin_Timestamp - 
> End_Timestamp]. Accurate time-keeping (e.g. use of NTP or 
> SNTP) is vital because port assignments are dynamic.  A 
> densely populated CGN could mean even very small amounts of 
> clock skew between a content provider and the CGN operator 
> will result in ambiguity about which customer was using a 
> specific port at a given time.
> 
> Considering that it is unrealistic to expect all servers to 
> start logging port information of connection attempts, 
> address sharing service providers may need to start logging 
> IP destination addresses as well, giving rise to privacy concerns.
> 
> If multiple subscribers are accessing the same (popular) 
> server at nearly the same time, it can be impossible to 
> disambiguate which subscriber accessed the server, especially 
> with protocols that involve several connections (e.g. HTTP).  
> Thus, logging the destination address on the NAT is inferior 
> to logging the source port at the server.
> 
>  cannot trace the offending activity to a specific 
> subscriber. In this circumstance, the service provider would 
> need to disclose the identity of all subscribers who had 
> active sessions on the NAT during the time period in 
> question. This may be a large number of subscribers."
> 
>   - Mat
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Jun 2010 19:53:37 +1200

On 2010-06-11 10:30, Dan Wing wrote:
...
> operating their own NAT in their house (which is one of the

Really, in every single case? I thought there were cases
where single-NAT traversal works and double-NAT traversal doesn't.
Certainly the issues of subscriber identification and geolocation
are significantly worse for NAT444 than for NAT44.

Also, A+P should be in the list.

    Brian

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 12 Jun 2010 09:27:10 -0700

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Friday, June 11, 2010 12:54 AM
> To: Dan Wing
> Cc: 'Matthew Ford'; [email-masked]; 
> [email-masked]; 'Lorenzo Colitti'
> Subject: Re: Revving draft-intarea-shared-addressing-issues
> 

Yes, there are such cases.  And those cases should be called 
out.

> are significantly worse for NAT444 than for NAT44.

If we consider home routers with 802.11, geolocation works as well
with or without NAT -- the WiFi device could be in the living room
or maybe the back yard, but won't be much farther away.  Subscriber
ID works as well as telephone numbers (can't tell if it's me or
my wife or my kid using my telephone -- just know it is someone
at my house).

> Also, A+P should be in the list.

Agreed.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Jun 2010 20:10:00 +1200

Dan,

> my wife or my kid using my telephone -- just know it is someone

Viewed from the content provider, a NAT444 subscriber geolocates to
wherever the prefix of the provider NAT appears to be; very often
that will be in a different city, and sometimes in a different country,
than the subscriber. In contrast, a subscriber behind a single CPE NAT can
be pretty accurately located these days. (Of course, that is geolocation
for coarse-grain commercial purposes, not accurate enough for legal or
emergency response purposes, which is a whole other discussion.)

   Brian

---

From: Matthew Ford <[email-masked]>
Date: Mon, 14 Jun 2010 10:19:02 +0100

Hi Dan,

> Yes, there are such cases.  And those cases should be called 

Care to offer (or point me to) some text on this point?

Mat

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Jun 2010 09:31:14 -0700

> Sent: Sunday, June 13, 2010 1:10 AM
> To: Dan Wing

Yes, I am very familiar with that problem.

That comparison and the view (from the content provider) is 
exactly the same no matter if the subscriber is operating a NAT
in their home ("NAT444") or is *not* operating a NAT in their 
home (e.g., DS-Lite). 

The problem is caused by the carrier's NAT (NAT44), not by
the subscriber's NAT.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Jun 2010 10:44:06 -0700

> Sent: Monday, June 14, 2010 2:19 AM
> To: Dan Wing
> Cc: 'Brian E Carpenter'; [email-masked]; 

Here is a shot at some text:

"There are several commonly-deployed mechanisms that support
operating servers behind a NAT by forwarding a specific TCP 
or UDP ports to a specific internal host ([UPnP-IGD], 
[I-D.cheshire-nat-pmp], and manual HTML configuration).  All
of these mechanisms assume the NAT's WAN address is a 
publicly-routable IP address, and fail to work normally
when that assumption is wrong.  There have been attempts to
avoid that problem by disabling the NAT function and merely
bridging traffic (is is required for [Windows-Logo] 
certification), but this only works if the WAN address is
a specific address, and bridging (rather than NATting) has
other side effects (DHCP requests are served by an upstream
DHCP server which can increase complexity of in-home 
networking).

Some routers enable 6to4 [RFC3056] on their WAN link.  6to4
requires a publicly-routable IPv4 address.  Enabling 6to4
behind a NAT causes a disconnected IPv6 island."

references in XML:

&I-D.cheshire-nat-pmp;

      <reference anchor="UPnP-IGD"
                 target="http://www.upnp.org/standardizeddcps/igd.asp">
        <front>
          <title>Universal Plug and Play (UPnP) Internet Gateway Device
          (IGD)</title>

          <author fullname="UPnP Forum" surname="UPnP Forum">
            <organization></organization>
          </author>

          <date month="November" year="2001" />
        </front>
      </reference>

      <reference anchor="Windows-Logo"
target="http://www.microsoft.com/whdc/winlogo/hwrequirements/default.mspx">
        <front>
          <title>Windows Logo Program Device Requirements</title>
          <author fullname="Microsoft" surname="Microsoft">
            <organization></organization>
          </author>
          <date year="2006" />
        </front>
      </reference>

-d

---

From: Dave Thaler <[email-masked]>
Date: Mon, 14 Jun 2010 19:04:31 +0000

> Some routers enable 6to4 [RFC3056] on their WAN link.  6to4 requires a
> publicly-routable IPv4 address.  Enabling 6to4 behind a NAT causes a
> disconnected IPv6 island."

The last sentence above is incorrect.  The second sentence is correct.
So one cannot "enable" 6to4 behind a NAT since one has no 
publically-routable IPv4 address.  Hence one does not get an IPv6
island.  One gets no IPv6 at all (from 6to4 anyway).

-Dave

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Jun 2010 12:16:41 -0700

> From: Dave Thaler [mailto:[email-masked]] 
> Sent: Monday, June 14, 2010 12:05 PM
> To: Dan Wing; 'Matthew Ford'
> Cc: [email-masked]; 'Brian E Carpenter'; 
> Subject: RE: [Int-area] Revving draft-intarea-shared-addressing-issues
> 
> requires a

I was attempting to summarize the problem that has been ascribed to Apple's
Airport Extreme routers turning on 6to4, which is mentioned in many threads on
the Internet including
http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00263.html

If there is more accurate wording, I'm all for it.  I would like
some discussion of CPE (and hosts) blindly enabling 6to4 causing
problems when the CPE's IPv4 WAN address is shared.  

-d

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 14 Jun 2010 12:39:44 -0700

> Enabling 6to4 behind a NAT causes a disconnected IPv6 island.

s/NAT/proto-41 filtering firewall/

Fred
[email-masked]

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing
> Sent: Monday, June 14, 2010 12:17 PM
> To: 'Dave Thaler'; 'Matthew Ford'
> Cc: [email-masked]; 'Brian E Carpenter'; [email-masked];
> 'Lorenzo Colitti'
> Subject: Re: [Int-area] Revving draft-intarea-shared-addressing-issues
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Jun 2010 12:47:37 -0700

> From: Templin, Fred L [mailto:[email-masked]] 
> Sent: Monday, June 14, 2010 12:40 PM
> To: Dan Wing; 'Dave Thaler'; 'Matthew Ford'

True.  However this document is discussing IP address sharing 
(not firewalls, nor all of other failures of IPv6-over-IPv4
tunneling.)

-d

> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dan Wing

---

From: Dave Thaler <[email-masked]>
Date: Mon, 14 Jun 2010 20:00:03 +0000

> From: Dan Wing [mailto:[email-masked]]
> Sent: Monday, June 14, 2010 12:48 PM
> To: 'Templin, Fred L'; Dave Thaler; 'Matthew Ford'
> Cc: [email-masked]; 'Brian E Carpenter'; draft-ford-shared-addressing-
> [email-masked]; 'Lorenzo Colitti'
> True.  However this document is discussing IP address sharing (not firewalls, nor
> all of other failures of IPv6-over-IPv4
> tunneling.)

Which is why the message post you were trying to summarize seems to be
unrelated to this document.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Mon, 14 Jun 2010 20:01:45 +0000

> To: Dave Thaler; 'Matthew Ford'

As Fred points out, that issue is not about shared IPv4 addresses so seems
out of scope for this thread.

> 
> If there is more accurate wording, I'm all for it.  I would like some discussion of
> CPE (and hosts) blindly enabling 6to4 causing problems when the CPE's IPv4
> WAN address is shared.

I don't follow what you're getting at.  Can you elaborate?

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 14 Jun 2010 13:04:47 -0700

The NAT box can use its public IPv4 address to enable 6to4, thereby providing IPv6 support for hosts "behind" it.  Why would this result in a disconnected IPv6 island?

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Mon, 14 Jun 2010 19:04:31 +0000
> CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Jun 2010 13:15:44 -0700

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Monday, June 14, 2010 1:05 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> The NAT box can use its public IPv4 address to enable 6to4, 
> thereby providing IPv6 support for hosts "behind" it.  Why 
> would this result in a disconnected IPv6 island?

Diagram of what I understand the problem to be with 6to4
behind another NAT:

  IPv6 host--+
              \
               +---[home NAT]----[Carrier's NAT]---[Internet]
              /      ^       ^                  ^
  IPv6 host--+       ^       ^                  ^
                     ^       ^             IP address sharing
                     ^       ^             with multiple 
                     ^       ^             subscribers
                     ^       ^
                     ^     the in-home NAT's WAN address 
                     ^     is not publicly routable
                     ^
                     ^
               this in-home 
             NAT turns on 6to4

-d

> > CC: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Mon, 14 Jun 2010 20:23:26 +0000

> Sent: Monday, June 14, 2010 1:16 PM
> To: 'Bernard Aboba'; Dave Thaler; [email-masked]
> Cc: [email-masked]; [email-masked]; draft-ford-shared-
> [email-masked]; [email-masked]
> > The NAT box can use its public IPv4 address to enable 6to4, thereby
> > providing IPv6 support for hosts "behind" it.  Why would this result
> > in a disconnected IPv6 island?
> 
> Diagram of what I understand the problem to be with 6to4 behind another NAT:
> 
>   IPv6 host--+
>               \

The in-home NAT cannot turn on 6to4, it's simply not possible.
To turn on 6to4 per the RFC one has to have a globally unique
IPv4 address, which it doesn't in the diagram above.

-Dave

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Mon, 14 Jun 2010 15:36:46 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing
Sent: Monday, June 14, 2010 4:16 PM
To: 'Bernard Aboba'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Int-area] Revving draft-intarea-shared-addressing-issues

  IPv6 host--+
              \

Two comments -
This should only be a concern if the carrier NAT is allocating non-RFC1918 IPs to end users in the place of 1918 space, thus confusing the home router/host into thinking that it can make 6to4 work properly. Non-broken 6to4 implementations recognize 1918 space and don't try to use it as a 6to4 source. They don't recognize 11.0/8 as unroutable because it's being "borrowed" for use inside a NAT when 10.0/8 is exhausted.

This specific issue is definitely something we should capture as an issue with shared addresses. It might be fixable by having a local 6to4 relay to translate the traffic to native IPv6 before it leaves the NAT domain, but you'd need a NAT66 to handle the fact that the 6to4 address is only locally significant. And that's ugly, but since it's probably not possible to simply say "don't use 6to4" unless you are going to track down and replace all 6to4 end devices with those that speak native IPv6, you may not have a choice.

Wes George

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Jun 2010 13:45:11 -0700

> Sent: Monday, June 14, 2010 1:23 PM
> To: Dan Wing; 'Bernard Aboba'; [email-masked]
> draft-ford-shared-

That works until the Carrier NAT provides a non-RFC1918 address
to the home NAT.  I don't believe anything requires the carrier's
NAT provide RFC1918 addresses.  draft-nishitani-cgn doesn't 
mention RFC1918.  Do we need such a requirement to avoid the
problem of 6to4 being enabled?

Things like draft-miles-behave-l2nat can give the NAT any
address it likes, including giving every NAT the same public,
non-RFC1918 IPv4 address:

   "... This
   technique can be leveraged post IPv4-exhaustion within the
   constraints of existing host and CPE implementations to assign the
   exact same public IPv4 address to every subscriber session and to
   then perform IPv4-to-IPv4 NAT on the subscriber traffic.  For
   example, multiple PPP subscribers could be assigned the exact same
   IPv4 address through IPCP and the L2-Aware NAT will translate all
   packets to an external/WAN public IPv4 address by including
   subscriber-identifier as an additional delimiter in the NAT mapping
   table."

-d

---

From: Dave Thaler <[email-masked]>
Date: Mon, 14 Jun 2010 21:28:04 +0000

Ok, I agree that it's good to point out that any shared address should be
from space designated as such.  Otherwise it will break the widely used
assumption that public IPv4 addresses are "globally unique" addresses
and hence break many protocols and applications.

-Dave

> Sent: Monday, June 14, 2010 1:45 PM
> To: Dave Thaler; 'Bernard Aboba'; [email-masked]
> That works until the Carrier NAT provides a non-RFC1918 address to the home
> NAT.  I don't believe anything requires the carrier's NAT provide RFC1918
> addresses.  draft-nishitani-cgn doesn't mention RFC1918.  Do we need such a
> requirement to avoid the problem of 6to4 being enabled?
> 
> Things like draft-miles-behave-l2nat can give the NAT any address it likes,
> including giving every NAT the same public,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Jun 2010 19:15:33 +1200

On 2010-06-15 08:23, Dave Thaler wrote:
...
> The in-home NAT cannot turn on 6to4, it's simply not possible.

In any case, supermarket NATs don't do this to my knowledge,
even when they have a global v4 address.

    Brian

---

From: Dave Thaler <[email-masked]>
Date: Fri, 18 Jun 2010 02:18:50 +0000

My point is that anything that sends out RAs with 6to4 prefixes derived from RFC 1918 is in violation
of the RFC and thus isn't doing 6to4, they're doing some proprietary extension to 6to4, not the
standard "6to4".

That's different from Dan's point about if a public IPv4 address is given to multiple devices
(which changes the IP model in ways I warned about in the port restricted IP issues doc)
then the standard "6to4" will break.

-Dave

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, June 17, 2010 5:38 PM
To: Dave Thaler
Cc: Dan Wing; Bernard Aboba; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Int-area] Revving draft-intarea-shared-addressing-issues

On Mon, Jun 14, 2010 at 1:23 PM, Dave Thaler <[email-masked]<mailto:[email-masked]>> wrote:
The in-home NAT cannot turn on 6to4, it's simply not possible.
To turn on 6to4 per the RFC one has to have a globally unique
IPv4 address, which it doesn't in the diagram above.

It shouldn't, but it does. There are home routers in the field that will send out RAs, with 6to4 prefixes derived from RFC1918 addresses, even if they have private IP addresses on the WAN side. The fact that this will never result in working connectivity doesn't prevent the gateways from doing it anyway.

Which by the way is why I think this type problem can only be fixed in the hosts OS and not in the home router (because users never upgrade home routers).

Cheers,
Lorenzo

---

From: Christian Vogt <[email-masked]>
Date: Thu, 24 Jun 2010 16:26:16 -0700

On Jun 10, 2010, Matthew Ford wrote:

> "In many jurisdictions, service providers are legally obliged to provide
> the identity of a subscriber upon request to the appropriate
> authorities.  [...]  The legal request should include the information:
> [IP address - Port - Protocol- Begin_Timestamp - End_Timestamp]...

Shouldn't the legal request include only one timestamp, as opposed to a
time interval as your text is suggesting?  The time interval should be
a logging requirement, not a requirement for requests.

- Christian

---

From: <[email-masked]>
Date: Fri, 25 Jun 2010 10:05:34 +0200

Yes I agree the smallest element needed is one timestamp

So it is more accurate to write [IP address - Port - Protocol - Timestamp]

And this does not preclude that a real legal request can bear other pieces of information

Pierre 

-----Message d'origine-----
De : Christian Vogt [mailto:[email-masked]] 
Envoyé : vendredi 25 juin 2010 01:26
À : Matthew Ford; [email-masked]
Cc : Internet Area Mailing List
Objet : Re: [Int-area] Revving draft-intarea-shared-addressing-issues

- Christian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Jun 2010 17:38:19 -0700

> IPv4 address, which it doesn't in the diagram above.

It shouldn't, but it does. There are home routers in the field that will
send out RAs, with 6to4 prefixes derived from RFC1918 addresses, even if
they have private IP addresses on the WAN side. The fact that this will
never result in working connectivity doesn't prevent the gateways from doing
it anyway.

Which by the way is why I think this type problem can only be fixed in the
hosts OS and not in the home router (because users never upgrade home
routers).

Cheers,
Lorenzo

---

From: Matthew Ford <[email-masked]>
Date: Tue, 29 Jun 2010 14:30:05 +0100

Dan,

On 14 Jun 2010, at 18:44, Dan Wing wrote:

8< snip >8

> DHCP server which can increase complexity of in-home 

Thanks for this. Can you clarify the the point about 'this only works if the WAN address is a specific address' - this isn't clear to me at least.

  - Mat

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 Jun 2010 13:00:20 -0700

> Sent: Tuesday, June 29, 2010 6:30 AM
> To: Dan Wing
> Cc: 'Brian E Carpenter'; [email-masked]; draft-ford-shared-
> [email-masked]; 'Lorenzo Colitti'
> Thanks for this. Can you clarify the the point about 'this only works
> if the WAN address is a specific address' - this isn't clear to me at
> least.

Reword to:

  ... and the bridging function is triggered when certain specific WAN
  addresses is assigned

better?

-d

>   - Mat=