One document matched: draft-diao-eipv4-00.txt
Network Working Group Yongping Diao
Internet-Draft China Telecom
Expires: May 10, 2007 November 10, 2006
Source Route Based Extensible IP Network (EIPv4)
draft-diao-eipv4-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 10, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
In order to resolve the problem of IP address shortage Internet
society try hard and use or intend to use some technologies such as
NAT/NAPT, IPv6. But the shortcoming or difficult deployment make it
progress slowly. Here provides an extensible IP network realization
method to exist IP version 4. Two-level extensible IP network
architecture is adopted which includes public IP address domain and
private IP address domain. With the position denotation of source IP
node and destination IP node, IP datagram can progress through the
whole extensible IP network freely using the source route based
method.
Diao Expires May 10, 2007 [Page 1]
Internet-Draft November 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Glossary of Terms . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions used in this document . . . . . . . . . . . . 3
2. Extensible IP Network Architecture . . . . . . . . . . . . . . 4
3. IP Node Position Definition . . . . . . . . . . . . . . . . . 5
4. Adoption of Source Route . . . . . . . . . . . . . . . . . . . 6
5. Change Maybe Need . . . . . . . . . . . . . . . . . . . . . . 10
6. Advantage of the Measure . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Diao Expires May 10, 2007 [Page 2]
Internet-Draft November 2006
1. Introduction
Rapid development of Internet has cause severe deficiency of IP
address. And it would retard all-IP application service development.
Internet society has provided series technologies such as private IP
address network, dynamic IP address allocation, VLSM, CIDR and
NAT/NAPT and etc. But they can only reduce exhausted speed of IP
address. In the other hand, IETF has decided to adopt IPv6 as the
next generation Internet to resolve the problem of IP address
shortage. But the process is relatively slow to satisfy the
requirement of rapid development of Internet.
Here provides extensible IP network scheme based on source route. It
is very competent. It makes existing IP version 4 network extend
flexibility. Enough IP address is provided which in theory has 2^24
times the scale of current Internet address space. There is no so
much difficulty of the scheme or not even any change needed in
upgrade or transition. Network performance or security might almost
be not changed or possibly be enhanced. According to IP node Position
Definition method, datagram can be transfer fluently through
extensible IP network if only source IP node knows the position
denotation of destination IP node. The extensible IP network provides
good network infrastructure and help develop all-IP network
application service.
1.1. Glossary of Terms
EIPv4 - Source Route Based Extensible IP Network version 4
IPD - IP Node Position Definition
1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Diao Expires May 10, 2007 [Page 3]
Internet-Draft November 2006
2. Extensible IP Network Architecture
Extensible IP network architecture shows as following figure 1. It
includes Public IP Address Domain, Private IP Address Domain, Border
Gateway between Public IP Address Domain and Private IP Address
Domain.
+-----------------------------------------------------------------+
| +----------+ +-----------+ |
| |IP Node S2| |IP Node D2 | |
| | AddrS2 | | AddrD2 | |
| |PositionS2| | PositionD2| |
| +----------+ +-----------+ |
| Public IP Address Domain |
+-----------/\-----------------------------------/\---------------+
|| PublicAddrGA || PublicAddrGB
+---------------+ +---------------+
| Gateway GA | | Gateway GB |
| PositionGA | | PositionGB |
+---------------+ +---------------+
|| PrivateAddrGA || PrivateAddrGB
+-----------\/-----------------+ +-------------\/--- ----------+
| +----------+ +----------+ | | +----------+ |
| |IP Node S1| |IP Node D1| | | |IP Node D3| |
| | AddrS1 | | AddrD1 | | | | AddrD3 | |
| |PositionS1| |PositionD1| | | |PositionD3| |
| +----------+ +----------+ | | +----------+ |
| Private IP Address Domain A | | Private IP Address Domain B |
+------------------------------+ +------------------------------+
Figure 1. Source Route Based Extensible IP Network Architecture
Public IP Address Domain includes all the public IP address nodes,
and all IP nodes with public IP address should belong to Public IP
Address Domain. In fact, Public IP Address Domain is the exist
Internet, and it keep all the IP node and routing mechanism
unchanged. In figure 1, IP node S2, D2 are in the Public IP Address
Domain with public IP address AddrS2, AddrD2 respectively.
Private IP Address Domain includes private IP address nodes, and
private IP address node should belong to Private IP Address Domain.
There would be multiple Private IP Address Domains in the extensible
IP network. It is similar to some existing enterprise private IP
networks which use the same routing mechanism as Public IP Address
Domain merely with private IP address. In figure 1, IP node S1, D1,
D3 are in the Private IP Address Domain with private IP address
AddrS1, AddrD1, AddrD3 respectively.
Diao Expires May 10, 2007 [Page 4]
Internet-Draft November 2006
Border Gateway locates between Public IP Address Domain and Private
IP Address Domain. In general, it is a gateway with address of Public
IP Address Domain and address of Private IP Address Domain. IP node
in Private IP Address Domain accesses Public IP Address Domain
through Border Gateway, or vice versa. In figure 1, IP node GA, GB
are Border Gateways. They have public IP address PublicAddrGA,
PublicAddrGB and private IP address PrivateAddrGA, PrivateAddrGB
respectively.
The existing Internet (Public IP Address Domain) Keep unchanged, and
it can be expanded by attaching Private IP Address Domain through
Border Gateway. Because any different Border Gateway can be attached
a whole Private IP Address Domain, it means that tens of millions IP
nodes are expanded through single Border Gateway. In theory, this
architecture can have about 2^32*2^24 IP nodes. Its scale is about
2^24 times of exist Internet. Even get rip of used IP address,
reserved IP address and routing configured address, the times is
still huge.
3. IP Node Position Definition
In traditional Internet only public IP address is legal, so each
Internet IP node can be located uniquely by public IP address. In
this extensible IP network architecture, public IP address is still
unique in the whole network, but the Private IP Address Domain can be
reused. So a method named "IP Node Position Definition(IPD)" is
adopted to uniquely locate IP node in the extensible IP network
architecture.
We find that any IP node in this extensible IP network architecture
can be uniquely located either by IP node¡¯s public IP address or by
IP node¡¯s private IP address with correlated public IP address. IP
node position denotation is show as:
(public IP address)[:private IP address]
Then, we can use this method to locate any IP node:
* IP node in Public IP Address Domain has position denotation:
its public IP address. In figure 1, IP node S2, D2 are in the
Public IP Address Domain. Their location PositionS2, PositionD2
are denoted as their public IP address AddrS2, AddrD2
Respectively. Namely:
PositionS2 = AddrS2
PositionD2 = AddrD2
Diao Expires May 10, 2007 [Page 5]
Internet-Draft November 2006
* IP node in Private IP Address Domain has position denotation:
its correlated Border Gateway¡¯s public IP address:its private IP
address. In figure 1, IP node S1, D1, D3 are in the Private IP
Address Domain. Their locations PositionS1, PositionD1, PositionD3
are denoted as:
PositionS1 = PublicAddrGA£ºAddrS1
PositionD1 = PublicAddrGA£ºAddrD1
PositionD3 = PublicAddrGB£ºAddrD3
* IP node as Border Gateway between Public IP Address Domain and
Private IP Address Domain has position denotation: its public IP
address, or its public IP address:its private IP address. In
figure 1, IP nodes GA, GB are Border Gateways between Public IP
Address Domain and Private IP Address Domain. Their public IP
addresses are PublicAddrGA, PublicAddrGB respectively, and
private IP addresses are PrivateAddrGA, PrivateAddrGB
respectively. Their locations PositionGA, PositionGB are denoted
as:
PositionGA = PublicAddrGA£¬OR PublicAddrGA£ºPrivateAddrGA
PositionGB = PublicAddrGB£¬OR PublicAddrGB£ºPrivateAddrGB
4. Adoption of Source Route
In order to transport datagram using source route method, source
route should be prepared. We should identify the source IP node and
destination IP node at first. Then we can get source IP node position
denotation and destination IP node position denotation with above IP
node position definition. Now according to the denotation of source
IP node and destination IP node, we can predefine the "Path" which
datagram should pass through. For example, in figure 1 we have source
IP node S1 and destination IP node D3. IP node S1 whose IP address is
AddrS1 belongs to Private IP Address Domain A whose Border Gateway GA
has public IP address PublicAddrGA. So source IP node S1 position
denotation is PositionS1 = PublicAddrGA£ºAddrS1. IP node D3 whose IP
address is AddrD3 belongs to Private IP Address Domain B whose Border
Gateway GB has public IP address PublicAddrGB. So destination IP node
D3 position denotation is PositionD3 = PublicAddrGB£ºAddrD3. Then we
got the Path "AddrS1->PublicAddrGA->PublicAddrGB->AddrD3" which MUST
be passed through from IP node S1 to IP node D3. Namely, reverse
address sequence of source IP node position denotation connects with
address sequence of destination IP node position denotation in
series, which constitutes "Path Address Sequence" of datagram. It is
the source defined path.
Diao Expires May 10, 2007 [Page 6]
Internet-Draft November 2006
Now we set out to realize predefined source route. According to
source route theory, source IP node MUST fill in Source Address
Field, Destination Address Field, Loose Source and Record Route
Option Field with "Path Address Sequence". In this example source IP
node S1 fills the Source Address Field of IP header with the first IP
address of the "Path Address Sequence" which is source IP node
address "AddrS1". The rest IP address of the "Path Address Sequence"
except the first IP address (source IP address) is so call "Source
Route Address Sequence". Here is PublicAddrGA->PublicAddrGB->AddrD3.
Fill the "Source Route Address Sequence" in "route data" field of IP
header Loose Source and Record Route Option Field and set parameters
such as option¡¯s length, pointer and etc. The second IP address of
the "Path Address Sequence" is the public IP address "PublicAddrGA"
of the Border Gateway which is source IP node correlated. This IP
address acts as destination IP address of the first section and it is
filled in the Destination Address Field of IP header. Now source IP
node make up the IP header so that its datagram can reach destination
IP node according to the predefine "Path".
The first section of the "Path" is in the Private IP Address Domain A
and between source IP node and Border Gateway GA. In this section,
IP datagram should transport from the first IP address of the "Path
Address Sequence" to the second IP address of the "Path Address
Sequence". In fact, because IP header Loose Source and Record Route
Option Field is exist as described above, the source IP node should
forward the IP datagram basing on the first IP address of the "Source
Route Address Sequence", namely PublicAddrGA. It is also destination
IP address in this Private IP Address Domain A. Then in the first
section of the "Path" all other routers in the middle can forward
datagram either by source route or by destination route. In either
case datagram will reach the first IP address of the source route,
which is also the destination IP address of the first section. In
this example it is IP address PublicAddrGA of Border Gateway GA
between Private IP Address Domain A and Public IP Address Domain.
Border Gateway GA should process received datagram basing on source
route theory. If the address in destination address field has been
reached and the pointer is not greater than the length, the next
address in the source route replaces the address in the destination
address field, and the recorded route address replaces the source
address just used, and pointer is increased by four. In this way, IP
address indicated by pointer in the source route and IP address in
the Destination IP Address Field are conformably changed into next IP
address of "Source Route Address Sequence", namely PublicAddrGB, the
second IP address of source route.
Diao Expires May 10, 2007 [Page 7]
Internet-Draft November 2006
Now the second section of the "Path" is in the Public IP Address
Domain and between Border Gateway GA and Border Gateway GB. All other
routers in the middle of the second section of the "Path" can forward
datagram either by source route or by destination route. In either
case datagram will reach the second IP address of the source route,
which is also the destination IP address of the second section. In
this example it is IP address PublicAddrGB of Border Gateway GB
between Public IP Address Domain and Private IP Address Domain B
where destination IP node D3 locates.
Similarly, Border Gateway GB should process received datagram basing
on source route theory. Then IP address indicated by pointer in the
source route and IP address in the Destination IP Address Field are
conformably changed into the next IP address of "Source Route Address
Sequence", namely AddrD3, the last IP address of source route which
is also the last IP address of "Path Address Sequence"
The third section, also the last section of the "Path" is in the
Private IP Address Domain B and between Border Gateway GB and
destination IP node. All other routers in the middle of the last
section of the "Path" can forward datagram either by source route or
by destination route. In either case datagram will reach the last IP
address of the source route, which is also the destination IP address
of the last section. In this example it is IP address AddrD3 of
destination IP node D3.
Finally, destination IP node D3 gets the datagram. It finds that the
predefined source route is gone through and it is the final
destination. According to the source route theory, "Source Route
Address Sequence" is replaced into "Recorded Route Address Sequence".
Then basing on the source IP address and "Recorded Route Address
Sequence" of received datagram, destination IP node acquires "Reverse
Path Address Sequence" which is used to reply IP datagram to source
IP node. "Reverse Path Address Sequence" is in the reverse of the
order of "Path Address Sequence". In this example it is "AddrD3->
PublicAddrGB ->PublicAddrGA ->AddrS1". Namely, reverse address
sequence of reverse source IP node D3 position denotation connects
with address sequence of reverse destination IP node S1 position
denotation in series, which constitutes "Reverse Path Address
Sequence" of received datagram. It is the reverse source defined
path. In this way, destination IP node can also fluently transport
responding IP datagram to source IP node according to the method
described above.
Diao Expires May 10, 2007 [Page 8]
Internet-Draft November 2006
The method described above can also be used in all other scenarios in
figure 1 to realize routing in extensible IP network:
* Scenario from source IP node S1 to destination IP node D2. Their
position denotations are PositionS1 =PublicAddrGA£ºAddrS1 and
PositionD2 =AddrD2 respectively. The Path Address Sequence is
AddrS1 ->PublicAddrGA ->AddrD2.
* Scenario from source IP node S2 to destination IP node D1. Their
position denotations are PositionS2 = AddrS2 and
PositionD1 = PublicAddrGA£ºAddrD1 respectively. The Path Address
Sequence is AddrS2->PublicAddrGA ->AddrD1.
* Scenario from source IP node S2 to destination IP node D3. Their
position denotations are PositionS2 = AddrS2 and
PositionD3 = PublicAddrGB£ºAddrD3 respectively. The Path Address
Sequence is AddrS2->PublicAddrGB ->AddrD3.
* Scenario from source IP node S2 to destination IP node D2. Their
position denotations are PositionS2 = AddrS2 and
PositionD2 = AddrD2 respectively. Both of them belong to Public IP
Address Domain. The Path Address Sequence is AddrS2->AddrD1.
According to the situation in traditional Internet, source IP
address field and destination IP address field in IP datagram
header are filled directly using destination routing manner. No
source route need here.
* Scenario from source IP node S1 to destination IP node D1. Their
position denotations are PositionS1 = PublicAddrGA£ºAddrS1 and
PositionD1 = PublicAddrGA£ºAddrD1 respectively. Because both of
them belong to the same Private IP Address Domain, the Path
Address Sequence is simplified to AddrS1->AddrD1. Then still
source IP address field and destination IP address field in IP
datagram header are filled directly using destination routing
manner. No source route need here too.
Diao Expires May 10, 2007 [Page 9]
Internet-Draft November 2006
5. Change Maybe Need
It is obvious that there are differences between source route manner
and existing destination route manner. It is necessary to do some
configuration or change on specific IP node:
* Any source IP node which is possible to adopt source route SHOULD
fill in Source Address Field, Destination Address Field, Loose
Source and Record Route Option Field of datagram to be sent
according to the method described above.
* Any Border Gateway between Public IP Address Domain and Private IP
Address Domain SHOULD support Loose Source and Record Route Option
function.
* Any destination IP node whose received datagram is using source
route manner SHOULD support Loose Source and Record Route Option
function. After it gets the "Reverse Path Address Sequence" basing
on received datagram, destination IP node SHOULD transport
responding IP datagram to source IP node adopting the same source
route method as source IP node.
In more ideal situation, router in the network or at least Border
Gateway between Public IP Address Domain and Private IP Address
Domain must have support Loose Source and Record Route Option
function, whose implementation is a "MUST" in RFC 791. Then the whole
Internet need not any change, and the only change needed is a little
IP module software change in source IP node or destination IP node.
6. Advantage of the Method
Source route based extensible IP network give a solution to an
important issue which puzzles Internet development. It has
significance:
* Make IP network extensible. Any individual gateway of Public IP
Address Domain can attach a whole Private IP Address Domain. This
make IP network become two level architecture and flexible
extensible network.
* Resolve the problem of IPv4 address shortage. Any individual
Border Gateway can be attached a whole Private IP Address Domain,
it means that tens of millions IP nodes are expanded through
single Border Gateway. In theory, this architecture can have about
2^32*2^24 IP nodes. Its scale is about 2^24 times of existing
Internet. Even get rip of used IP address, reserved IP address and
routing configured address, the times is still huge.
Diao Expires May 10, 2007 [Page 10]
Internet-Draft November 2006
* Make extensible IP network transition quite simple. Even more
there is not any change needed to existing Internet, and the only
change needed is a little IP module software change in source IP
node or destination IP node.
* Save a lot of cost which would be necessary when IP network
technology reform or upgrade. Considering immature and great
upgrade difficulties of IPv6, EIPv4 introduced here is very
competent.
* Make IP network the infrastructure for various all-IP-network
services. Enough IP address resources, flexible extensibility,
without difficult network transition problem, without technology
reformation, the existing IP network now is ready for various
all-IP-network services such as 3G, IMS, NGN and etc.
7. Security Considerations
To exist enterprise private IP networks, their owner may want to keep
certain private security. Free penetration into these private IP
network may bring worry about security. Following solutions cover
these issues considering security:
* Security control basing on the whole Path Address Sequence.
Destination address field of IP datagram header will change in the
transmitting path of EIPv4. It causes serious effect on
traditional security control method basing on destination address.
In order to improve and ensure effective security control, it
needs security control process basing on the whole Path Address
Sequence of datagram.
* Reserve old exist enterprise IP private IP network. The old IP
private network can still use NAT/NAPT, proxy and so on to
interwork with Internet and keep its private character. This
private network can not only attach to border of Public IP Address
Domain but also border of Private IP Address Domain. Then the
extensible IP network is change to three level extensible IP
network. Of course, difficulties still exist and need special
process to support some services for this private network.
Diao Expires May 10, 2007 [Page 11]
Internet-Draft November 2006
8. Acknowledgments
Author likes to thank everybody for their valuable opinion and
evaluation to this document.
9. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 791] Postel, J., ed., "Internet Protocol - DARPA Internet
Program Protocol Specification", RFC 791, September 1981.
[RFC1597] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot,
"Address Allocation for Private Internets", RFC 1597,
March 1994.
[RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, September 1993.
[RFC2663] P. Srisuresh, M. Holdrege., "IP Network Address Translator
(NAT) Terminology and Considerations" RFC 2663,
August 1999.
[RFC2460] S. Deering, R. Hinden.£¬ "Internet Protocol, Version 6
(IPv6) Specification", December 1998.
Diao Expires May 10, 2007 [Page 12]
Internet-Draft November 2006
Authors' Addresses
Diao Yongping
China Telecom-Guangzhou Institute
109 West Zhongshan Ave
Guangzhou, China. 510630
Phone: +86 20 38639732
Email: diao@gsta.com, diaoyp@yahoo.com
Diao Expires May 10, 2007 [Page 13]
Internet-Draft November 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Diao Expires May 10, 2007 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 10:25:28 |