Agree with Tony that Andrew's real-life deployment scenario sequence
(a) thru (h) is of interest for the requirements doc.

Fred
[EMAIL PROTECTED]

Tony Hain wrote:

Andrew,

Would you mind if we put this sequence in the requirements doc?

Tony




-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew White
Sent: Wednesday, August 06, 2003 6:55 PM
To: IPng
Subject: Real life scenario - requirements (local addressing)



A 'real life' deployment scenario.


(a) I set up a local network. I currently have no ISP, but I want my network to 'just work' out of the box. This network consists of (initially) three routers, plus other infrastructure.

(b) Sometime later I decide I want internet connectivity, so I connect to an ISP. I add my ISP provided address to my network in addition to the address/es that are there already. For argument's sake, let's say the ISP doesn't have IPv6 capability, so I use a 6to4 address.

I do not want my internal addressing exposed outside the network, so I filter my addresses. I do use the ISPs addresses for external connectivity.

(c+d) Meanwhile, my friend has done the same thing, except that his ISP DOES offer IPv6, so he has a 'real' IPv6 address.

(e) We connect our two local networks together (either by VPN tunnel or a wireless link - doesn't matter). We can now send local traffic to each other, and out either ISP.

(f) Sometime later I disconnect my ISP, and we use just his ISP.

(g) Sometime later I disconnect my network from his.

(h) Sometime later I register with a new ISP, and get a new IPv6 prefix.


Salient points:


(1) At points (a), (c) and (g) we have networks that are standalone and have no connection to an ISP or the global internet. Further, the networks in
(a) and (c) have never had such a connection. The users don't want to have to register to get an address that works.


(2) In (b), the external (6to4) prefix is unstable. Many ISPs allocate a temporary IPv4 internet address, and change these frequently.

(3) The set of global prefixes valid for the network changes over time.
(a) None
(b) #1 (my 6to4)
(e) #1 and #2 (friend's v6)
(f) #2
(g) None
(h) #3 (my new v6)


(4) The only 'reliable' address that the hosts in my network have is the local one they started with.

This example is quite similar to Tony's research ship example, with the possible caveat that a research ship might be big and organised enough to register with an ISP to get an address space plus connectivity they never intend to use.


Consequences:


- I need some form of local addressing that is not dependent on anyone or anything connected to the global internet.

- I need this local addressing unique enough that I can safely join my network and my friend's network together and allow them to swap prefixes.

- I want hosts in my network to prefer my local address scheme when talking to other hosts in my network. I want hosts in my network to prefer one of the local schemes when talking to hosts in my friend's network (since I don't want the packets to leave 'our' network). I want hosts in my network to prefer global addresses when talking externally.

- I want my local addresses filtered at appropriate borders, preferably without having to set it up myself.

- The ISPs probably want my local addresses filtered too.


Looks suspiciously like the filtered local address proposal, doesn't it?


--
Andrew White
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------




--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------




--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------

Reply via email to