Subject: RE: apps people?

From: "Christian Huitema" <[email-masked]>
Date: Wed, 6 Aug 2003 12:42:57 -0700

>> Let's be clear. Our group (Windows Networking) has received a lot
>> of feedback from developers of applications on the Windows
>> platform. The negative developers' feedback was mostly centered on the
>> difficulty of identifying the scope of an address, specially when a
>> node is connected to several sites (e.g. home network and VPN to the
>> corporate network), or when a node moves from site to site.
>
>  Which is to say, topology information which it didn't
>  have to consider in the past and for which it has little
>  information at its disposal from which to make decisions.

No, I specifically did not say "topology information". Topology is a very wide notion, and application developers are actually OK with some amount of topology handling, e.g. doing things differently with folks that are "near me". The feedback on local addresses was very specific. Applications would learn or remember that the address of some correspondent was "FEC0::1234:5678:9ABC", they would try to feed the address in a socket address structure and issue a connect, and the call will fail because they did not fill up the "site identifier" variable, as in "FEC0::1234:5678:9ABC&1". The problem is compounded by the fact that the site identifier varies with the host instantiation, e.g. sometimes &1 and sometimes &2, and thus that the host identifier cannot be remembered in memory, or learned from a name server. Having a non ambiguous address solves that problem, because the stack will know over which interface a connect request to "FC00:DEAD:BEEF::1234:5678:9ABC" shall be routed!
 . The application will not have to handle "site identifiers", and that is a very good thing.
 
-- Christian Huitema

--------------------------------------------------------------------
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: "Brian Zill" <[email-masked]>
Date: Wed, 6 Aug 2003 20:47:46 -0700

Note that both #1 will always be the case for nodes that support both IPv4 and IPv6.  And #2 is always a concern for apps that need to run on nodes/networks that may support either version of IP or both, and wish to talk to other nodes/networks that may support either version of IP or both.

In other words, expecting to have only one IP address per node is an increasingly naïve assumption for an app to make (not even true very often for IPv4 today), and likewise is expecting everyone else's connectivity to be the same (i.e. you can't forward the IPv4 address of one of your peers to another one of your peers and expect them to be able to deal with it - the second peer may be an IPv6 only node).

There are issues here that have nothing to do with site-locals.

--Brian

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andrew White
> Sent: Wednesday, 06 August, 2003 18:31
> Cc: [email-masked]
> Subject: Re: apps people?
> 
> 
> Unless I'm missing something, the 'apps' problem can be 
> neatly divided into two issues:
> 
> (1) If there are multiple addresses per node, then the 
> application needs to somehow iterate through the various 
> src/dest combos until it finds one that works.  If multiple 
> ones would work, how does it choose the best combo?
> 
> (2) If there are filters in place, then addresses that work 
> from one node attached at one point may not work from a 
> different node or a different location.
> 
> If we agree to remove filters and have one address per node, 
> then we can continue to write simplistic apps.  If not, then 
> applications need to use techniques that allow them to cope 
> with these issues.
> 
> Notice that if an application only creates connections using 
> a single pair of endpoints then (assuming no mobility) it 
> only has to deal with issue #1. 
> Issue #2 only comes into play when applications forward IP 
> address to other applications and expect them to keep 
> working.  Sending DNS addresses instead may be a solution for 
> some applications.  Manual configuration is the other option.
> 
> This discussion is only relevant to 'local' addresses in as 
> much as local addresses are one class of filtered address.  
> As soon as you introduce filters you MUST consider #2, 
> regardless of your address 'scope'.
> 
> 
> Christian's point about apps not wanting to deal with scope 
> ids to resolve overlapping mutually ambiguous scopes is 
> taken, but I think most of us agree with that aspect.
> 
> 
> Network ambiguity is largely irrelevant - the connection 
> succeeds or it doesn't (remember that most nodes have a 
> unique interface id).  Rather, ambiguity is a big bugbear for 
> network merging.
> 
> -- 
> Andrew White

---

From: "Michel Py" <[email-masked]>
Date: Fri, 8 Aug 2003 08:07:08 -0700

> Eliot Lear wrote:
> The question isn't whether you *can* do it but whether
> it's a good and scalable approach.  There was code
> *before* this debate started.

Indeed. And people were deploying before this debate started as well.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Fri, 8 Aug 2003 08:45:48 -0700

Eliot,

> Eliot Lear wrote:
> I was referring to the smaller devices a'la Linksys,
> DNET, etc.

The first part of my post also did. When you scratch the surface it
works on an IP address basis, the rest is GUI paint to make it easy on
Joe.

> With ciscos you pretty much run sed on the header
> if you want to

In the example I pasted it was not my choice; there was no other way.

> - not that I think it's a good idea.

Well, if there is a good reason for it which I am confident there is,
it's ok.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Fri, 8 Aug 2003 13:57:48 -0700

> Would you say that your network is a typical representation of
> a future Joe Six- Pack network with IPv6? With the eBGP peers
> and all?

A little overkill for Joe Six-Pack, but the eBGP peering is already
available for free from several providers, I don't see why it would
change for power users.

> With that setup I think you are competent enough to handle your
> IPv6 internal network, and filtering (routing, access-lists and
> what not) without relying on site locals for any of it.

I always like that people that haven't even seen a diagram of my network
teach me how I should operate it.

> So the people in whos homes these devices are installed have
> several subnets internally

Not internal to their home. Their home subnet is part of the corporate
address plan.

> and therefore needs to run a dynamic routing protocol within their
> home as well as extending it to the service provider upstream?

No relation with the former paragraph but yes. Static routes suck.

> Is NAT involved here somewhere?

Most of the time.

> Or do you mean that there are VPNish configurations over which
> the dynamic routing is run with an internal corporate network
> but still a static configuration for the defaultroute to the
> service provider and vice verse?

For v4, mostly. There are three types of config. On one the default
route comes from the dynamic routing and goes across the tunnel; the
only routes in the home router are two /32 routes to the corporate VPN
endpoints (pointing to the default gateway of the ISP). This ensures
that even regular web surfing is encrypted on the last mile. On the
other one the tunnel is used to access the corporate network only and
the regular Internet traffic goes over the default route to the ISP. On
another one there is no public Internet access and the network is used
to access corporate assets only (typically there will be another PC to
access the net).
 
For v6 there is no clear picture.

> Does the people in their home manage their configuration and
> routers themselves or is that provided as part of the service?

No, heaven forbid. Done by corporate IT and/or consultants.

> In my view the "consumer" is the average user connecting
> the home to the Internet by some form of broadband access
> to get access to triple-play services etc. Perhaps that
> connection is also used for telecommuting. But I do not
> see the requirement for dynamic routing and through that
> route filtering with the upstream service provider(s).

How do you configure multiple links? A T1 with ISDN as a backup (from
the same provider) is a very common config.

> Running a VPN tunnel and routing over that to the job
> over the broadband access is a different thing, most likely
> not involving the service provider at all except for
> carrying tunnel packets.

Correct it's a different animal.

> I commented on route filtering in combination with security.
> I argue that route filtering for security to prevent hacking
> is neither common

ridiculous

> nor encouraged. There are many valid uses of route filtering
> in networks with routing requirements. I do not think the
> average consumer network will be of such complexity to require
> filtering of routes, and I do not think that site locals would
> add anything if route filtering would be used for security to
> prevent hacking.

You certainly are entitled to an opinion, but the bottom line is that it
is my call and I decided otherwise.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 12 Aug 2003 08:18:47 -0700

> Mark Smith wrote:
> The security paranoid, at least in an government environment,
> would *like* to perform route filtering as part of a defense
> in depth strategy in addition to filtering, but end-user
> access requirements usually put an end to that idea.

All government networks that I have worked on use route filtering: they
have static routes on some parts and especially at the edge. That's the
ultimate form of route filtering.

Michel.