Subject: [BEHAVE] Some Thought about the Automatic Tunnel Address

From: Xu Xiaohu <[email-masked]>
Date: Thu, 03 Sep 2009 10:15:43 +0800

Hi all,

As quoted from "IPv6 Transition Mechanism" [RFC1933], "...The tunnel
endpoint is the node to which the IPv6 packet is addressed.  Since the
endpoint of the tunnel is the destination of the IPv6 packet, the tunnel
endpoint can be determined from the destination IPv6 address of that packet:
If that address is an IPv4-compatible address, then the low-order 32-bits
hold the IPv4 address of the destination node, and that can be used as the
tunnel endpoint address." 

Unfortunately, the usage of IPv4-compatible address may cause routing
scalability issue for IPv6 in practice when multiple sites use such
addresses.

The ISATAP (RFC5214) solves the above routing scalability issue with the
automatic tunneling address by concatenating a /64 LIR prefix and an ISATAP
interface ID (which is constructed in the Modified EUI-64) to generate an
IPv6 Global unicast address. I wonder whether it is better to directly
concatenate a /96 LIR prefix (which can be learnt from the prefix
information option in the RA message) and a 32-bit IPv4 address to generate
an IPv6 address. One obvious benefit of this method is IPv6 prefix resource
can be allocated in a more efficient way. By the way, the IPv6 DAD action
can also be avoided since the IPv4 address is already guaranteed to be
unique.

Xiaohu

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 3 Sep 2009 16:13:27 -0700

Hi Xu,

> -----Original Message-----
> From: Xu Xiaohu [mailto:[email-masked]]
> Sent: Wednesday, September 02, 2009 7:16 PM
> To: [email-masked]; 'Behave WG'
> Subject: [Softwires] Some Thought about the Automatic Tunnel Address
> 
> Hi all,
> 
> can be allocated in a more efficient way.

I floated the idea of a /96 for ISATAP during either an
intarea or ipv6 meeting several years ago (can't remember
which) but there was no uptake. Looking back, I don't see
any advantages, and in fact it goes against the model in
which IPv6 addresses beginning with other than '000' use
a 64-bit prefix. Indeed, ISATAP and SLAAC already fit
together naturally, and I see no reason to change that. 
 
> By the way, the IPv6 DAD action

This was left as a silent assumption in RFC5214, but it
is called out explicitly in VET.

Thanks - Fred
[email-masked]

> 
> Xiaohu
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 04 Sep 2009 10:25:32 +0800

Hi Templin,

> a 64-bit prefix. 

Yes, I also noticed the above specification defined in RFC4291 as "... for
all unicast addresses, except those that start with the binary value 000,
Interface IDs are required to be 64 bits long and to be constructed in
Modified EUI-64 format". However, I don't know what the real meaning of such
constraint is in practice. Can anybody kindly help me understanding this?

> Indeed, ISATAP and SLAAC already fit

Yes, I agree with your opinion to some extent. It seems too early to
consider how to use the IPv6 address resource in an efficiently way.
However, the Internet history is, at the initial stage of the Internet
deployment, seldom people thought about CIDR since most people believed the
IPv4 address is most enough for use in the future. Unfortunately, the
reality is beyond most people's expectations. Maybe the same problem will
not happen on IPv6.

Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 08 Sep 2009 12:17:09 +0800

> which IPv6 addresses beginning with other than '000' use

What's the real purpose of the above model (IPv6 addresses beginning with
other than '000' use a 64-bit prefix)? Can somebody help explain it?

Thanks,
Xiaohu

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 10 Sep 2009 12:59:34 +0200

> other than '000' use a 64-bit prefix)? Can somebody help explain it?

The IPv6 addresses in ::/3 are/were used for special purposes, such as  
the localhost address, IPv4-mapped addresses and mapping NSAPs and  
IPX. So the requirement that there should be a valid IID in those  
addresses doesn't make sense.

---

From: Rémi Després <[email-masked]>
Date: Wed, 16 Sep 2009 13:58:25 +0200

> other than '000' use a 64-bit prefix)? Can somebody help explain it?

Xu,

I had the view that this statement badly needed a reliable  
justification, and argued about it.

But it now happens that the study about routing-loop attacks  
documented last August by Gabi Nakibly, in www.ops.ietf.org/lists/ 
v6ops/v6ops.2009/msg00601, leads IMHO to such a justification.

I tried to explain all this in www.ietf.org/mail-archive/web/behave/ 
current/msg06816.
You may find relevant to this discussion.

Regards,
RD

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 17 Sep 2009 11:17:29 +0800

Hi Remi,

> You may find relevant to this discussion.

Thanks for your reply. 

In your msg
(http://www.ietf.org/mail-archive/web/behave/current/msg06816.html), you
said "... Suffice it to say that a 6to4 relay router may need, to be safe,
to look at IPv4 addresses that are embedded in ISATAP IPv6 addresses. In the
above example, if the 6to4 relay router sees that the IPv4 embedded address
in the IPv6 destination is its own IPv4 address 192.88.99.1, it can discard
the packet and thus prevent the loop". However, I feel this is not a good
idea for a 6to4 router to check the ISATAP address. In fact, the
routing-loop attack can be easily avoided by using a private IPv4 address,
rather that a public IPv4 address as the ISATAP tunnel endpoint address on
the ISATAP router.

Hence, I don't think the routing-loop attack prevention is a justification
for the "IID-format constraint".

Best wishes,
Xiaohu

NOTE: The following is quoted from Remi's msg
(http://www.ietf.org/mail-archive/web/behave/current/msg06816.html)
******************************************************************
ROUTING-LOOP ATTACK PROTECTION AND ITS IMPLICATION ON IPV6 ADDRESS FORMATS 

In a mail of Aug 17 (www.ops.ietf.org/lists/v6ops/v6ops.2009/ msg00601),
Gabi Nakibly documented a new type of attack: the "routing loop" attack.
With it, some packets can be repeatedly retransmitted between two ISATAP
routers, or between an ISATAP router and a 6to4 relay router. 

For a brief illustration of one instance of the the attack, here is an
example: 

+-------------------------------------------------------+
| IPv6                   IPv6 packet                    |
|Internet        dst6:  2002:198.16.9.9::1              |
|                src6:  2001:db8:1::200:5efe:192.88.99.1|
|                                           |           |
|                                           V           |
|          .--------------->--------------. |           |
|         /                                \|           |
+--------+----------------------------------+-----------+
         |                                  |
  2001:db8:1::/48                       2002::/16
    +---------+                        +---------+
    | ISATAP  |                        |  6to4   |
    +---------+                        +---------+
    198.16.9.9                         192.88.99.1
         |                                  |
+--------+---------+                        |
| IPv4   ^         |                        |
| site   ^         |                        |
|        ^         |                        V
|        ^         |                        |
+--------+---------+                        |
    198.16.9.0/24                           |
         |                                  |
         |                                  |
+--------+----------------------------------+-----------+
| IPv4    \                                /            |
|internet  '----------------<-------------'             |
|                 IPv6 in IPv4 packet                   |
|                  dst4: 198.16.9.9                     |
|                  src4: 192.88.99.1                    |
|                                                       |
+--------+----------------------------------+-----------+

Detailed protection mechanisms against these attacks are being discussed on
the v6ops and 6man lists, in particular with Gabi Nakibly, Fred Templin, and
Christian Huitema, and are out of scope here. Suffice it to say that a 6to4
relay router may need, to be safe, to look at IPv4 addresses that are
embedded in ISATAP IPv6 addresses. In the above example, if the 6to4 relay
router sees that the IPv4 embedded address in the IPv6 destination is its
own IPv4 address 192.88.99.1, it can discard the packet and thus prevent the
loop. 

Now, IPv4 addresses embedded in ISATAP addresses can be reliably detected
ONLY if non-ISATAP addresses NEVER have 200:5efe::/32 in their octets 8 to
15. If some mappable-only address would have this pattern, there could be a
slight but real possibility that an intermediate 6to4 relay would discard
packets sent to this address. 

This is, in my understanding, a sufficient technical reason for the
IID-format constraint to apply to all IPv6 addresses (with or without real
IID). 

Regards,
RD

*****************************************************************

---

From: Rémi Després <[email-masked]>
Date: Thu, 17 Sep 2009 10:40:18 +0200

Xu,

Thanks for you answer.
Further comment below.

> rather that a public IPv4 address as the ISATAP tunnel endpoint  

If the IPv4 address of an ISATAP router is private, the attack  
scenario  below doesn't exists, YES.

But 5214 says in its introduction that "ISATAP enables automatic  
tunneling whether global or private IPv4 addresses are used".
To prevent all routing-loop attacks, 6to4 relay routers should  
therefore also deal with ISATAP routers that have global IPv4 addresses.

As a matter of facts, ISATAP can be useful with a global IPv4 address  
in a large private network that has enough global IPv4 addresses to  
use them internally: this provides IPv6 connectivity to dual-stack  
hosts that support ISATAP (e.g. with Windows or Linux AKAIK).

> for the "IID-format constraint".

I also wish it would not have been a justification, but for the  
reason above I believe it is one we have to live with :-(.

Did I miss anything?

Regards,
RD

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 17 Sep 2009 17:28:28 +0800

Hi Remi,

> tunneling whether global or private IPv4 addresses are used".

Yes. However, to avoid the routing-loop attack, it'd better to use a private
address.

> hosts that support ISATAP (e.g. with Windows or Linux AKAIK).

The site network could use public IPv4 address as long as the address used
as ISATAP tunnel endpoint on the ISATAP router is an address which is
unaccessible from the IPv4 Internet.

Xiaohu

---

From: Rémi Després <[email-masked]>
Date: Thu, 17 Sep 2009 12:12:27 +0200

> unaccessible from the IPv4 Internet.

Yes.
I would also suggest to configure it this way.

But, one may want to protect the 6to4 relay WITHOUT assumptions that  
go beyond what the ISATAP spec says (IMHO a legitimate objective).
For this, the proposed check can do the job.

BTW, are there scenarios you are interested in where having to  
protect the 9th octet of IPv6 addresses is very annoying (I find it  
annoying myself but, well, if we have to live with it let's accept it  
and proceed.)

Regards,
RD

---

From: <[email-masked]>
Date: Thu, 17 Sep 2009 16:45:07 +0200

Hello,
Xu Xiaohu comment is right but probably be too much restrictive.
Excluding all public IPv4 addresses is too strict and not enough because it does not excludes 6 to 4 gateways between the local private network and the IPv6 network with a private IPv4 address.

ISATAP use an IPv6 operator prefix instead of a well known prefix, so it means that ISATAP is built to ensure IPv6 connectivity of IPv4 Islands inside an IPv6 network managed by a specific operator.
So the encapsulation of IPv6 packet into IPv4 done by the gateway must be restricted to IPv4 destination addresses managed by this operator (the ISATAP equipment operator) excluding all IPv4 addresses managed by this operator and allocated to ISATAP, 6 to 4 gateway or any other gateway between the IPv4 network and the IPv6 network like for example IVI-T gateways.

This limitation can be implemented through an access list in the ISATAP gateway, in IVI-T gateways or in any other gateway between the IPv4 network and the IPv6 network doing encapsulation of IPv6 packet, with a prefix allocated to an operator, in IPv4 packet.

	Eric BURGEY 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Rémi Després
Envoyé : jeudi 17 septembre 2009 10:40
À : Xu Xiaohu
Cc : [email-masked]; 'Templin, Fred L'; 'Behave WG'
Objet : Re: [BEHAVE] [Softwires] Some Thought about the AutomaticTunnelAddress

Xu,

Thanks for you answer.
Further comment below.

Did I miss anything?

Regards,
RD

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Sep 2009 10:25:37 -0700

Eric,

The point is that ISATAP can be used with public IPv4
addresses (in which case the IPv6 address is constructed
as: "FOO::0200:5EFE:V4ADDR") and there is no guarantee
in that case that the ISATAP router is located behind an
ip-proto-41 nor ingress-filtering site border router. Plus,
I know of at least one major enterprise network that uses
public IPv4 addresses internally, and the network is much
too large to be covered by a single ISATAP link.

This discussion should probably by synchronized with the
one taking place on the v6ops, 6man and secdir lists.

Fred

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, September 17, 2009 7:45 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Templin, Fred L; [email-masked]
> Subject: RE: [BEHAVE] [Softwires] Some Thought about the AutomaticTunnelAddress
> 
> Hello,
> Excluding all public IPv4 addresses is too strict and not enough because it does not excludes 6 to 4
> gateways between the local private network and the IPv6 network with a private IPv4 address.
> 
> ISATAP use an IPv6 operator prefix instead of a well known prefix, so it means that ISATAP is built
> to ensure IPv6 connectivity of IPv4 Islands inside an IPv6 network managed by a specific operator.
> So the encapsulation of IPv6 packet into IPv4 done by the gateway must be restricted to IPv4
> destination addresses managed by this operator (the ISATAP equipment operator) excluding all IPv4
> addresses managed by this operator and allocated to ISATAP, 6 to 4 gateway or any other gateway
> between the IPv4 network and the IPv6 network like for example IVI-T gateways.
> 
> 
> This limitation can be implemented through an access list in the ISATAP gateway, in IVI-T gateways or
> in any other gateway between the IPv4 network and the IPv6 network doing encapsulation of IPv6
> packet, with a prefix allocated to an operator, in IPv4 packet.
> 
> 
> 	Eric BURGEY
>

---

From: <[email-masked]>
Date: Fri, 18 Sep 2009 16:33:58 +0200

Thanks Fred,

Thanks Fred,
You are right it is difficult to protect tunnelling mechanism against spoofing attacks without ip-proto-41 and ingress filtering in site border router.
A major enterprise or an ISP may use more than one single ISATAP link. 

But the point is, as you have written in chapter 4 of RFC 5214 ,
>"The domain of applicability for this technical specification is automatic >tunneling of IPv6 packets in IPv4 for ISATAP nodes within sites that >observe the security considerations found in this document, including host->to-router, router-to-host, and host-to-host automatic tunneling in certain >enterprise networks and 3GPP/3GPP2 wireless operator networks.  (Other >scenarios with a sufficient trust basis ensured by the mechanisms specified >in this document also fall   within this domain of applicability.)",
Automatic tunnelling must be limited to a "Site".

Even if I have not found a precise definition of a "Site" IMHO it means that there is an organisation able to create the trust inside the "Site". Such organisation is able to know all IPv4 addresses allocated to ISATAP router or all 6 to 4 router used to interconnect this site with internet and to prohibit automatic tunnelling between 2 ISATAP routers inside the "Site" or between an ISATAP router and 6 to 4 router inside the "Site".
So if these ISATAP-ISATAP or ISATAP-6_to_4 tunnels are prohibited inside the "Site", and if the automatic tunnelling process is limited to intra-site tunnels, I don't see how the loop described in REMI DESPRES mail can be closed in the IPv4 domain.

	Eric BURGEY

-----Message d'origine-----
De : Templin, Fred L [mailto:[email-masked]] 
Envoyé : jeudi 17 septembre 2009 19:26
À : BURGEY Eric RD-CORE-ISS; [email-masked]; [email-masked]
Cc : [email-masked]; [email-masked]
Objet : RE: [BEHAVE] [Softwires] Some Thought about the AutomaticTunnelAddress

Eric,

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 18 Sep 2009 10:22:31 -0700

Hi Eric,

> Sent: Friday, September 18, 2009 7:34 AM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> You are right it is difficult to protect tunnelling mechanism against spoofing attacks without ip-
> proto-41 and ingress filtering in site border router.

OK.

> >"The domain of applicability for this technical specification is automatic >tunneling of IPv6
> packets in IPv4 for ISATAP nodes within sites that >observe the security considerations found in this
> document, including host->to-router, router-to-host, and host-to-host automatic tunneling in certain
> >enterprise networks and 3GPP/3GPP2 wireless operator networks.  (Other >scenarios with a sufficient
> trust basis ensured by the mechanisms specified >in this document also fall   within this domain of
> applicability.)",

The statement beginning: "Other scenarios with a sufficient
trust basis..." is the one to consider when the "site" we
are considering is the public Internet itself. The check
for '*::0200:5EFE:V4ADDR' updates this statement.

> Even if I have not found a precise definition of a "Site" IMHO it means that there is an organisation
> able to create the trust inside the "Site".

The "organization" in this case is the IANA that delegated
the public IPv4 addresses, along with the collective
administrative authorities of all BGP routers in the DFZ.
 
> Such organisation is able to know all IPv4 addresses
> allocated to ISATAP router or all 6 to 4 router used to interconnect this site with internet and to
> prohibit automatic tunnelling between 2 ISATAP routers inside the "Site" or between an ISATAP router
> and 6 to 4 router inside the "Site".

In some sites, configuring ISATAP/6to4 routers with a list of
all other ISATAP/6to4 routers - and then using that list for
filtering purposes - might not scale well. This is definitely
true for the case of the public Internet as a "site", and
probably also true for many large enterprises.
 
> So if these ISATAP-ISATAP or ISATAP-6_to_4 tunnels are prohibited inside the "Site", and if the
> automatic tunnelling process is limited to intra-site tunnels, I don't see how the loop described in
> REMI DESPRES mail can be closed in the IPv4 domain.

As above, populating a list of all IPv4 addresses of
ISATAP/6to4 routers on each router might not scale well
in many environments. So, a simple solution is to use
the ISATAP router neighbor cache to avoid looping. In
particular, an ISATAP router *with a coherent neighbor
cache* should only accept/send a tunneled packet with
dst/src address other than FE80::* IFF the tunnel far
end is a known neighbor.

Within enterprise networks protected by site border
routers there are two ways to ensure a coherent neighbor
cache: 1) administrative assurance that no IPv4 spoofing
is possible within the enterprise, or 2) secure neighbor
discovery. Within the global Internet as a site, we can
rely on neither of these and have only the
'*::0200:5EFE:V4ADDR' check as protection.

You should probably also have a look at the thread titled:
"routing loop attacks using IPv6 tunnels" in the v6ops and
6man lists.

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Sep 2009 08:59:53 +1200

Hi Eric,

On 2009-09-19 02:33, [email-masked] wrote:
...
> Automatic tunnelling must be limited to a "Site".

If you are referring to ISATAP, that may be a sustainable position.
However, by definition, 6to4 and Teredo involve multiple sites,
for any reasonable definition of site.

    Brian

---

From: <[email-masked]>
Date: Wed, 23 Sep 2009 13:52:01 +0200

Hi Fred
I fully agree with you. 
If the Site is the internet we clearly need a mechanism known by all manager of ISATAP equipment connected to internet and the ISATAP interface prefix is the best solution. 

	Eric BURGEY

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Templin, Fred L
Envoyé : vendredi 18 septembre 2009 19:23
À : BURGEY Eric RD-CORE-ISS
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [BEHAVE] [Softwires] Some Thought about the AutomaticTunnelAddress

Hi Eric,

OK.

 

Fred

---

From: Rémi Després <[email-masked]>
Date: Thu, 24 Sep 2009 15:54:39 +0200

> for any reasonable definition of site.

... and we can add 6rd (an ISP IP4 network across which IPv6 is  
tunneled in 6rd isn't in general considered a "site").

Regards,

RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Sep 2009 09:23:22 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rémi Després
> Sent: Thursday, September 24, 2009 6:55 AM
> To: Brian E Carpenter
> Cc: [email-masked]; [email-masked]; [email-masked]; Templin, Fred L
> Subject: Re: [BEHAVE] [Softwires] Some Thought aboutthe AutomaticTunnelAddress
> 
> 

That depends on one's definition of "site". I would consider
the ISP network as a site that contains other sites (i.e.,
recursively-nested sites-within-sites).

Fred

---

From: Rémi Després <[email-masked]>
Date: Thu, 24 Sep 2009 19:02:50 +0200

Le 24 sept. 09 à 18:23, Templin, Fred L a écrit :

> That depends on one's definition of "site".

Agreed.
Only if there would be an agreed definition of site would it be  
possible to be sure what Eric's sentence means, and to then formally  
agree or disagree with it.

> I would consider

In my understanding, the original meaning of site (now deprecated but  
still present in many minds) was close to "customer site", and in any  
case not recursive.

"Domain" seems to me more intuitive than "site" for recursive or  
hierarchical entities (routing domains, administrative domains etc.)

Regards,
RD

> In

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Sep 2009 10:12:45 -0700

Hi Remi,

> Sent: Thursday, September 24, 2009 10:03 AM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] [Softwires] Some Thought abouttheAutomaticTunnelAddress
> 
> 

Actually, in my opinion better than either "domain" or
"site" is "enterprise", which RANGER and VET talk about.
This is also almost the same as what the original CATENET
work called "Packet Switching Network (PSN)".

Fred

---

From: Dong Zhang <[email-masked]>
Date: Fri, 25 Sep 2009 15:54:05 +0800

>recursively-nested sites-within-sites).

Imho, the word of "site" means a network. However, the size 
of the network is not fixed. It seems that "site" is not a 
clear concept. This leads to some misunderstanding.
If there is a specific definition for "site",
it could be easier to understand when using this word.

Thank you.
------------------				 
Dong Zhang
2009-09-25

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 25 Sep 2009 08:08:37 -0700

> it could be easier to understand when using this word.

Part of the problem with site-local was that the scope was ambiguous.
the term is not rooted in a discrete object with a position in the
topology, contrast with autonomous system or prefix.

---

From: Dong Zhang <[email-masked]>
Date: Tue, 29 Sep 2009 14:28:29 +0800

Hi Joel,

>Part of the problem with site-local was that the scope was ambiguous.
Agree.
>topology, contrast with autonomous system or prefix.
Just because of this point, it would better confirm the scope of
"site" when talking about it in case misunderstanding and confusion.

Thank you.

------------------				 
Dong Zhang
2009-09-29

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Sep 2009 09:04:46 +1300

On 2009-09-29 19:28, Dong Zhang wrote:
...
> "site" when talking about it in case misunderstanding and confusion.

It may be impossible. Actually I'd be very interested to hear any comments
about the approach to defining address scope that we have taken in
draft-carpenter-behave-referral-object. Maybe what we call a "limited scope"
is a site? This should be discussed at a BOF in Hiroshima. Comments on the
grobj mailing list please:
 [email-masked]
 https://www.ietf.org/mailman/listinfo/grobj .

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 29 Sep 2009 14:10:48 -0700

Brian,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Tuesday, September 29, 2009 1:05 PM
> To: Dong Zhang
> Cc: [email-masked]; Templin, Fred L; [email-masked]; [email-masked]
> Subject: [BEHAVE] What is a site? [Re: [Softwires]Some Thought about theAutomatic Tunnel Address
> 

I'm not sure it is impossible to define "site"; a site is
just a logical or physical partition (bounded by site border
routers) within a connected routing region. As long as the
nodes within the site remain associated with their site
border routers, they are still within the same site.

Back to site-locals, my understanding was that RFC4193
ULAs were introduced in part to accommodate sites that
partition or merge. As long as each site border router
configures and advertises a its own ULA prefix, there
would be no ambiguity regarding the scope over which
the ULA applies.

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Sep 2009 11:01:26 +1300

> would be no ambiguity regarding the scope over which

That can change if you use the ULA over a VPN to another "site",
or if the scope is chopped up with a NAT. I think it's rather
a different thing for a human to understand what the effective
scope is, compared with all hosts knowing algorithmically the
scope of an arbitrary address. I think Dong Zhang is asking for
an algorithmic definition.

    Brian

---

From: Scott Brim <[email-masked]>
Date: Tue, 29 Sep 2009 18:54:00 -0400

> an algorithmic definition.

That gives you two different viewpoints: that of the tunnel client (of
whatever size) and that of the network transporting the tunnel.  From
the point of view of the client it is in the same "site" as the other
client.  Outside the tunnel IP forwarders see the outer header, and
carry it across a "site" boundary.

The scope is not physical.  A site is defined by shared state and
behaviors that cannot be done outside of a "site" scope.

imho fwiw, ymmv ... swb

---

From: Dong Zhang <[email-masked]>
Date: Wed, 30 Sep 2009 10:29:57 +0800

>an algorithmic definition.
Hmm... Yes.

------------------				 
Dong Zhang
2009-09-30

---

From: Dong Zhang <[email-masked]>
Date: Wed, 30 Sep 2009 10:46:20 +0800

Hi Scott,
>behaviors that cannot be done outside of a "site" scope.
Agree, imho, the nodes who have the same behaviors, policy rules and so on 
compose a "site". It is a logical scope. If so, the unambiguous definition 
of logical partition rule should be unified.

Thanks.
------------------				 
Dong Zhang
2009-09-30

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 30 Sep 2009 08:22:24 -0700

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, September 29, 2009 3:01 PM
> To: Templin, Fred L
> Cc: Dong Zhang; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] What is a site? [Re: [Softwires]Some Thought about theAutomatic Tunnel Address
> 

I think what I was suggesting can be expressed algorithmically.
For a node within a site, as long as its site border routers
are still reachable and as long as its on-link or delegated
prefixes are still valid, then the node is still in the same
site. So, the site simply comprises the set of all nodes which
affiliate with the same set of site border routers in this way.

Additionally, the site is known by a name, e.g., "example.com".
Nodes within the site can resolve this name to determine the
list of site border routers.

Fred