Subject: (ngtrans) I-D ACTION:draft-ietf-ngtrans-harden-00.txt

From: [email-masked]
Date: Tue, 22 Jun 1999 09:54:23 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Generation Transition Working Group of the IETF.

	Title		: 6Bone Hardening Effort
	Author(s)	: R. Rockell, B. Fink, A. Durand, B. Buclin
	Filename	: draft-ietf-ngtrans-harden-00.txt
	Pages		: 
	Date		: 21-Jun-99
	
The 6Bone is an Ipv6 testbed to assist in the evolution and deployment  
of IPv6. Because of this, it is important that the core backbone
of the IPv6 network maintain stability, and that all operators have
a common set of rules and guildelines by which to deploy IPv6 routing
equipment. This document provides a set of guildelines for all IPv6
routing equipment operators to use as a reference for efficient and stable deployment of IPv6 routing systems. As the complexity of the 6Bone grows, the adherence to a common set of rules becomes increasingly important in order for an efficient backbone to exist.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-harden-00.txt

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-ietf-ngtrans-harden-00.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

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ngtrans-harden-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Randy Bush <[email-masked]>
Date: Tue, 22 Jun 1999 18:59:33 -0700 (PDT)

4. Routing Policies

    Leaf sites or pNLAs MUST only advertise to an upstream provider the
    prefixes assigned by that provider. Advertising a prefix assigned by
    another provider to a provider is not acceptable, and breaks the
    aggregation model.  A site MUST not advertise a prefix from another
    provider to a provider as a way around the multi-homing problem.

so how does one get the benefit of redundancy in the multi-homed case?

    All pTLAs MUST NOT advertise prefixes longer than a given pTLA
    delegation (currently /24 or /28) to other pTLAs unless special peering
    arrangements are implemented.

you may want to note that this will eventually be relaxed the registries are
a$$igning /35s.

    The peering agreements across the 6Bone may be by nature non-commercial,
    and therefore MAY allow transit traffic, if peering agreements of this
    nature are made. However, no pTLA is REQUIRED to give or receive transit
    service from another pTLA.

you may want to point out that sites offering ipv6 transit MUST look very
carefully at the relevant transit/peering policies of the underlying ipv4 
infrastructure and MUST be sure not to violate them.

it would seem to me that folk MUST register ALL announced route:/inet6num:
objects in the registry, as that is the major useful data to an operator as
one bases route filters on them.

     c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) 
        entries for their site's router, and at least one host ser-
        ver system.

you might be optimistic that the a6 rr will become unblocked in the iesg.

s/falacious/fallacious/

randy

---

From: Peter Tattam <[email-masked]>
Date: Wed, 23 Jun 1999 12:58:45 +1000 (EST)

The following is a change in policy, no?

  The peering agreements across the 6Bone may be by nature non-commercial, and
  therefore MAY allow transit traffic, if peering agreements of this nature
  are made. However, no pTLA is REQUIRED to give or receive transit service
  from another pTLA.

I agree with this, but I might add a comment.

There is the temptation for pTLA's to be peered with as many other pTLA's as
possible but only providing transit traffic to a small subset (possibly none).
The proliferation of too many peering connections could leasd to instability of
the default free zone.  While easy to do while the 6bone is constructed with
tunnels, when native Ipv6 traffic starts to flow the number of peering
connections will diminish due to the cost of having to establish each physical
peering connection.

Is there a broad intention of where the 6bone is heading on this topic?

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210