headers
Keith Moore | 1 Jul 2002 01:28
Picon

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

> Keith Moore wrote:
> > ...
> > > Lets use the
> > > following example:
> > >          |       |
> > >       A -|-- B --|- C
> > >          |       |
> > >       SL | SL&G  | Global
> > >
> > > What Keith is asking for is that B should be able to tell C
> > about the SL
> > > for A because A doesn't have a global address.
> >
> > B has no way of knowing whether or not there is a route from A to C.
> 
> In this example B knows the scopes don't match.

so what?  the fact that A used a limited-scope address to talk to B 
doesn't doesn't tell B anything about whether A and C can communicate
directly.  B knows nothing, absolutely nothing, about the network
connectivity between A and C and there's absolutely no way B can 
make *any* inferences about connectivity by looking at any set
of A's and C's addresses.  furthermore, there's nothing that any 
address selection rule can do to change this situation.

> > But if there *is* a route from A to C, then there needs to be a an
> > address for A that B can give to C, even if A is not connected to the
> > public Internet.
> 
> This is where we fundamentally disagree. If A is not connected to the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vijay Amrit Agrawal | 1 Jul 2002 07:46
Favicon

Re: Maybe: IPv6 Scoped Addresses and Routing Protocols

Hi,
The disadvantages of NAT is pretty well known but I was trying to see if I
can extract any feature of NAT that is useful. I am not saying that use NAT
as it is, but see if we can learn any thing positive from it, beside saying
it has problems. These are the two things which I think we can learn from
NAT:

i) I see discussion here of the application trying to decide the address. I
don't think it is a good idea to couple application with addresses, (Nat
being one example, though some may say invalid example, it is a real life
example.).  For example in IPv4 world if we had decided that the application
had to use mac address if the peer is in same subnet else use the IP
address. I think it is better to avoid such concepts unless we see some
other big advantage out of it.(Perhaps you also don't like the idea of
application dealing with addresses).

ii)If you can model NAT in a different way, you can see that it gives a
different way of route aggregation. An enterprise might be using lots of
private address but so many private address are aggregated into few public
address. This is a different way of address aggregation at least very
different from what I am aware of. This address aggregation as existing
currently in NAT is certainly a problem as the private addresses overlap but
this architecture can be modified

I think if we can modify the applications and IP stacks (as we have to do
for IPv6), the problems of NAT can be solved too.  I also think not many
people will like to modify there system for NAT. (An example for solving NAT
problem: To make the address unique, the application passes both the private
address and the public address to the peer. The peer uses both the address
in the packet and on the receiving side the gateway changes the public IP
(Continue reading)

Permalink | Reply | 1 comment |
headers
itojun | 1 Jul 2002 08:02

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

>This (if it's still possible) would certainly resolve the problem, but
>would leave open Keith's question about how to allocate a prefix for
>disconnected sites (especially those which don't have even a single
>IPv4 address and therefore an implied 6to4 prefix).

	it think i have already answered that question in the past:
	draft-itojun-ipv6-local-experiment-02.txt

itojun
--------------------------------------------------------------------
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 majordomo <at> sunroof.eng.sun.com
--------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
JINMEI Tatuya / 神明達哉 | 1 Jul 2002 07:44
Picon

Re: Request for Agenda Items for IETF 54 IPv6 Sessions

>>>>> On Sat, 29 Jun 2002 18:17:47 +0200, 
>>>>> Francis Dupont <Francis.Dupont <at> enst-bretagne.fr> said:

>  In your previous mail you wrote:
>    => Francis Dupont wrote:
>    => I strongly encourage items about prefix delegation for
>    => home sites because these are *urgent* for IPv6 deployment.

>    I must have missed something. Can you develop this / post links?

> => today ISP which manages an IPv6 dialup service (i.e., its customers
> run "home sites") should allocate a /48 per connection but there is
> no available protocol to do this.

Just FYI: in the forthcoming Networld + Interop Tokyo we'll present
IPv6 prefix delegation using DHCPv6 in a multi-vendor environment.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei <at> isl.rdc.toshiba.co.jp
--------------------------------------------------------------------
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 majordomo <at> sunroof.eng.sun.com
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Robert Elz | 1 Jul 2002 09:44
Picon

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

    Date:        Mon, 01 Jul 2002 15:02:47 +0900
    From:        itojun <at> iijlab.net
    Message-ID:  <20020701060247.19AB44B2B <at> coconut.itojun.org>

  | 	it think i have already answered that question in the past:
  | 	draft-itojun-ipv6-local-experiment-02.txt

Hmm - this is the (relevant) answer from your draft ...

  2.4.  Completely disconnected site

  If the site has no external IP connectivity, the site may use site local
  address space.

What such a site would do if it there were no site local addresses isn't
answered.    But this is not really relevant, as it is already quite clear
from this discussion that site local addresses are not going away.  At most
they may be modified a little.

wrt your draft, in advising against site local addresses, you make three
points ...

  o Site-local addresses are "scoped" address, while global addresses are
    not.

  o Configuration must correctly identify site border routers.  This is an
    additional requirement.

  o There are proposals on scoped routing exist [Deering, 2000] , however,
    implementation status is still rather disappointing.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Francis Dupont | 1 Jul 2002 10:20
Picon
Picon

Re: I-D ACTION:draft-ietf-ipv6-default-addr-select-08.txt

 In my previous mail I wrote:

      Rule 8: Use longest matching prefix. 
      If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. 
      Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then 
      prefer SB. 

   => this rule has no meaning when CommonPrefixLen is not bound to 0..64.

=> I've changed a bit my mind about this: in fact the 64 boundary works
only for IPv6 addresses, not for IPv4 addresses where the right
boundary is between 96 and 128 (exclusive). So the right implementation
of the CommonPrefixLen() function must include a sound maximal value for
each prefix of the policy table.

   (BTW are there common cases where D8 is not overruled by D6 for
   not twisted policy tables?)

=> multicasts... I still wonder if the D8 is useful.

Francis.Dupont <at> enst-bretagne.fr
--------------------------------------------------------------------
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 majordomo <at> sunroof.eng.sun.com
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 Jul 2002 12:37
Picon
Favicon

I-D ACTION:draft-savola-ipv6-127-prefixlen-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Use of /127 Prefix Length Between Routers Considered 
                          Harmful
	Author(s)	: P. Savola
	Filename	: draft-savola-ipv6-127-prefixlen-04.txt
	Pages		: 6
	Date		: 28-Jun-02
	
In some cases, the operational decision may be to use IPv6 /127
prefix lengths, especially on point-to-point links between routers.
Under certain situations, this may lead to one router claiming both
addresses due to subnet-router anycast being implemented.  This draft
discusses the issue and offers a couple of solutions to the problem;
nevertheless, /127 should be avoided between two routers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-savola-ipv6-127-prefixlen-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Elz | 1 Jul 2002 13:59
Picon

Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

    Date:        Fri, 28 Jun 2002 18:56:57 -0700
    From:        "Michel Py" <michel <at> arneill-py.sacramento.ca.us>
    Message-ID:  <2B81403386729140A3A899A8B39B046405E170 <at> server2000.arneill-py.sacramento.ca.us>

  | One of the drafts is ready
  | http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt

Sorry, "ready" isn't an adjective I'd use to describe that draft.

I've been trying to follow it over the weekend, and the best I've
been able to do so far is to guess at what it is trying to describe.

As best I can tell, this is a rehash of the old idea to separate the
endpoint ID from the address (basically) - that is, there's the stable
ID, which is constant, and the address, which is topology sensitive
(just the same address that we have today).   In this version those are
both taken from the same address space (though different chunks of it)
and constrained so that the numbering within a site is identical
(the ID prefix will differ from the address prefix, but the rest of
the bits will always be the same).

Then, rather that simply carry both values in packets, a weird perversion
of NAT is done, which flips from one value to the other in the packets
while in transit.

But I couldn't figure out exactly when that was supposed to happen exactly.
I did understand that it is supposed to be invertible, so the endpoints
don't ever know it happened (removing the worst effect of NAT).

That is, the method described, as best I can understand it (which isn't
(Continue reading)

Permalink | Reply | 0 comments |
headers
Toni Stoev | 1 Jul 2002 14:17
Picon
Favicon

IP grand-Next Generation addressing


Hello, everybody.

I propose a grand-next generation addressing approach:
– Hierarchical levels in a certain unicast type of addresses to represent 
actual connectivity:
A node is elected to be a starting node.
Every node's neighbors are identified uniquely to that node.
A node's connectivity address (location) from a starting node is a 
sequence of neighbor identifications representing a path from the 
starting node to the node having the address.
Consequences:
Nodes with addresses from the same starting node (root) form a routing 
domain (tree; may be called also a site, if this concept is unoccupied).

There is more.

The following information is appended by dispatch 
service provider for this message.

__________________________________
12MB-POP3-WAP-SMS---TOBA-E-mail.bG
----------------------------------

" Ako uckame u Bue agpec B mail.bg 
ugeme myk: http://www.mail.bg/new/ "

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Machalek | 1 Jul 2002 15:15

RE: Stateful Address Config - I-D ACTION:draft-ietf-ipv6-node-requirements-00.txt


John,

I was hoping for something a little more specific, helping to clear up just
what an implementation needs in order to be conformant.  How does something
like the following sound?

4.4.5 Stateful Address Autoconfiguration

Stateful Address Autoconfiguration is conditionally mandatory.  For those
IPv6 Nodes that implement a stateful configuration mechanism such as
[DHCPv6], those nodes SHOULD/MUST initiatiate stateful address
autoconfiguration upon the reciept of a Router Advertisement with the
Managed address flag set.  In addition, as defined in [RFC2462], in the
absence of a router, hosts that implement a stateful configuration
mechanism such as [DHCPv6] MUST attempt to use stateful address
autoconfiguration.

For IPv6 Nodes that do not implement the optional stateful configuration
mechanisms such as [DHCPv6], the Managed Address flag of a Router
Advertisement can be ignored.  Furthermore, in the absensce of a router,
this type of node is not required to initiate stateful address
autoconfiguration as specified in [RFC2462].

Adam Machalek

                                                                                                                                     
                      <john.loughney <at> no                                                                                              
                      kia.com>                 To:       <Adam_Machalek <at> nmss.com>, <ipng <at> sunroof.eng.sun.com>                        
                                               cc:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane