Subject: Re: Geoff Huston's draft and the intended use of the hinden/templin address space

From: "Nir Arad" <[email-masked]>
Date: Mon, 11 Aug 2003 15:06:12 +0200

> Nir Arad wrote:
>
> > As for internal communications (here's another flame bait):
> > I propose to prefer global addresses too.
> > Only those "special, internal applications" that should maintain very
> > long term connections at the transport layer should be a little
> > complicated by allowing the user to prefer local addresses, thus
> > addressing the debated stability issue.
> > Hosts will be forced down to local addressing only if the destination
> > has only a local scope address (e.g. an internal printer).
>
> Define 'special, internal applications'?
> - Is my NFS mount a special, internal application?
> - What about my game session?
> - My ssh session to a server?
>
> Define 'very long term'?
>

I was refering the Moore-Hain discussion in the "local vs. nonlocal address stability" thread.

[snip]

> Applications that do forward IP addresses can't a-priori trust any address,
> since they can't know where the filters are (if any).  Safe strategies
> include:
>   - manual configuration
>   - send DNS names and let the target choose
>   - send all available options and let the target choose (this isn't a very
> good option)
>   - additional information
>

My suggestion is to use scoping explicitly;
the application will KNOW that packets with mismatched address scopes WILL get filtered in the first node they
encounter.

Nodes may still do address selection as per your suggestions, but only if the source node and the destination node have
several configured addresses in shared scopes.

> I'll also note that no deployment is forced to use local addresses - if
> someone or something doesn't configure them then they won't exist.
>

agreed.

>
> There is a solution that will cause all these considerations to be obsolete
> - strictly enforce one (and only one) address per node.  And ban filters
> while you're at it.  Any takers?
>

I think we already know that there is a strong opposition to that.

>
> Side point: a policy which allows for local addresses but auto-deprecates
> them when an external address becomes available causes local addresses to
> lose one advantage - the local address is now subject to failure because of
> site-external events.
>

I never suggested that. I don't think anyone does.

>
> > I would like to point out again, that as per my suggestion, nodes MUST
> > NOT send, receive or forward traffic in which the source and destination
> > addresses are not of the same scope.
>
> I think this is unnecessarily stringent.  Certainly nodes should prefer not
> to send packets with non-matching 'scopes' (see "default address
> selection"), but I don't see it as an error condition to do so.
>

I think that anything less than that will take us again to the currently ongoing debate.
I'm in favor of answering the major requirements, and otherwise keeping things simple.
In my eyes, the major requirements are:
- Provide an addressing solution to disconnected networks.
- Provide address stability, at least internally.
- Allow various administrative scenarios (merging, connecting/disconnecting the internet), while minimizing the chance
to harm other entities (implying uniqeness)
- Make address selection, and applications in general, as simple as possible; make it even simpler to the users

Regards,

-- Nir Arad

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Nir Arad" <[email-masked]>
Date: Tue, 12 Aug 2003 10:19:34 +0200

You can make it simpler yet:

Option 1:
Use only one local address scope.
Control device has only a scoped address.
The host has one scoped address and one global address.
The DFZ host has only a global address.

Option 2:
All have global addresses.
Use firewall rules to filter.

Regards,

-- Nir Arad

----- Original Message ----- 
From: "Nir Arad" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 12, 2003 9:42 AM
Subject: Re: Geoff Huston's draft and the intended use of the hinden/templin address space

> Excellent scenario, and a simple solution:
> 
> The administrator needs to define 2 address scopes.
> 
> The control device has an address in scope 1.
> The host has addresses in both scopes 1 and 2, as well as a global unicast address.
> The DFZ host has an address of scope 2, and a global unicast address.
> 
> All requirements met.
> 
> Regards,
> 
> -- Nir Arad
> 
> ----- Original Message ----- 
> From: "Michel Py" <[email-masked]>
> To: "Nir Arad" <[email-masked]>; <[email-masked]>
> Sent: Monday, August 11, 2003 6:29 PM
> Subject: RE: Geoff Huston's draft and the intended use of the hinden/templin address space
> 
> 
> > >>> Nir Arad wrote:
> > >>> I would like to point out again, that as per my suggestion, nodes
> > >>> MUST NOT send, receive or forward traffic in which the source and
> > >>> destination addresses are not of the same scope.
> >  
> > >> Michel Py wrote:
> > >> That would some problems but appears to be unworkable to me. It's
> > >> not flexible enough.
> > 
> > > Could you please give a scenario that breaks it?
> > 
> > 
> > <-------------------- Global Addresses ----------------><- Local addr ->
> > +-----+
> > | ISP |    :
> > +--+--+    :
> >    !       :
> > +--+---------+  +----------+     +----------+     +----------+
> > | Router A : +--|< Firewall+--+--|< Firewall+--+--+ Router B +----+
> > +------------+  +----------+  |  +----------+  |  +----------+    |
> >            :                  |                |                  |
> >            :              +---+--+          +--+---+         +----+----+
> >            :              | DFZ  |          | Host |         | Control |
> >            :              | Host |          +------+         | Device  |
> >            :              +------+                           +---------+
> > ---Site -->:<-------------------------- Site -------------------------->
> >            :
> > 
> > - Router A is the SBR.
> > - DFZ hosts need to be able to talk to hosts between the internal
> > firewall and router B, but not to the control devices.
> > - DFZ hosts need to be able to talk to the outside.
> > - Hosts between the internal firewall and router B need to be able to
> > talk to everybody.
> > - Control devices are accessible only from hosts between the internal
> > firewall and router B.
> > 
> > Michel.
> > 
> >

---

From: "Michel Py" <[email-masked]>
Date: Tue, 12 Aug 2003 09:12:58 -0700

> The host has addresses in both scopes 1 and 2, as well as a global
> unicast address. The DFZ host has an address of scope 2, and a
> global unicast address.
> All requirements met.

Then unless each host has two NICs (which is not acceptable as it
doubles the size of the local network) the host interface is in two
scopes simultaneously which means the entire VLAN spans two scopes which
makes your proposal that scopes don't communicate together void.

Michel.

---

From: "Nir Arad" <[email-masked]>
Date: Wed, 13 Aug 2003 16:56:15 +0200

Michel,

The notion of subnets still exists in any address scoping suggestion.
The point you raised below only means that the particular VLAN to which this host belongs, spans one subnet of one scope, and one subnet of the other.

The control device could reside in another VLAN, which only spans one subnet of one of the scopes.

Per my suggestion, "scopes don't communicate" is only refering layer-3 processing of IPv6 packets.
Hosts in different scopes can still communicate using IPv4 or other protocols,
and there is nothing on IPv6 scoped addresses that me or anyone else can do to stop it.

Regards,

--
Nir Arad
Marvell Semiconductor Israel
http://www.marvell.com/

Michel.