[6bone] pTLA request NDSOFTWARE - review closes 23 October 2002

[Nicolas DEFFAYET]

On Sun, 2002-10-20 at 16:24, John Fraizer wrote:

> OK.  I'm still wondering what NDSoftware does.  Don't get me wrong.  The
> ASPath Tree is slick, the ftp site is handy for some I'm sure, providing
> 6bone connectivity is definately a service but, there has to be something
> going on that actually generates income, otherwise, you're hemorrhaging
> money on colocation and IP transit charges.  Generally, when someone forms
> a company, as you state you have done, it is to generate income.  To do
> that, you have to offer services that people will purchase.  You _can't_
> sell 6bone access and thus-far, every "service" you claim to provide is
> 6bone-centric.

6bone is a research activity for NDSoftware, see my FAQ
(http://mailman.isi.edu/pipermail/6bone/2002-October/006462.html).

> I'm simply looking at the overall health of the 6bone here.  If you're
> issued a pTLA and start providing "services" to folks with that address
> space and suddenly, your "company" goes tits-up because you're not able to
> pay your colocation/transit fees (because your "company" isn't actually
> SELLING anything to generate revenue) then not only have you embarrassed
> yourself but, you will have inconvenienced who knows how many other 
> people.


We generate revenue, see my FAQ
(http://mailman.isi.edu/pipermail/6bone/2002-October/006462.html).
We have an operational bussiness.

> > All tech contact in NDSoftware's whois have a root access on each
> > routers. They understand v4/v6 routing, unix administration,... 
> > 
> 
> Wow.  You're a trusting soul there.  SUDU is your friend, Dude.  You might
> want to look at the man page for it.

Sudo is very limited.
We trust our technical staff.

> I'm simply looking for you to demonstrate that you or one of your
> employees can properly maintain appropriate records for address
> allocation.  Just because the 6bone is experimental does not relieve you,
> the administrator of a network, from the burdon of due diligence.  Suppose
> one of your downstreams started a SPAM campaign to v6 connected
> mailservers or started trying to hack into other v6 connected
> systems?  How long does it take you to track down the appropriate contact
> information for the source address?  Do you have appropriate records to
> provide to law enforcement agencies in the event that you are subpoenaed
> for this type of information?

We have a database with all informations about peering and IPv6
connectivity provided.

> > We have 3 /32, but 1 /32 is enough. We have 3 /32 for have a backup if
> > one of our upstream can't provide us anymore a BGP peering. 
> > 
> 
> Ya, like if they were to say "your peering session is going to die in a
> week because our routers are overloaded with BGP sessions.  We've decided
> to drop all of our BGP peers who are using reserved ASNs." -- Something
> like that?

Now, please forgot the problem of delete of peer with private ASN on our
routers.

It's not a world and public problem.

> > > I submit that without your own portable v4 address space for an endpoint
> > > of tunnels, you're at the mercy of your upstreams.  If they require you to
> > > renumber, every one of your peers will have to reconfigure their tunnels.
> > 
> > Yes, i know. 
> > 
> 
> So, when you went after your ASN, did you try to brow-beat some v4 space
> out of RIPE as well?

Yes, if we start in production NDSoftware Hosting project.

> > > (5) I find this strange.  Can you explain it?
> > > 
> > > Nice routing loop there.  Have you considered: (1) Not having a v6 default on your border
> > > router. (2) Having a connection between your two border routers and running an IGP between them?
> > 
> > Ops, fixed. 
> > 
> > I have forgot to add "ifconfig lo add 3ffe:81f1:2:1::1/64" in the init
> > scripts of parcr1.fr.ndsoftwarenet.net. 
> 
> Wow.  I can't imagine trying to explain that to one of my customers.  This
> is all about attention to detail Nicolas.  So, you get your own pTLA and
> people start actually listening to and propagating your announcements and
> you "forget" a little thing like applying an access-list or route-map to
> a peering session.  Guess what?  Your lack of attention to detail does
> more than embarrass you.  It can cause service effecting outages for a
> whole ton of OTHER people.


All humains do errors.
You have do too many errors...

> role:         IPv6-FR NOC
> address:      IPv6-FR
> address:      57 rue du president Wilson
> address:      92300 Levallois-Perret
> address:      France
> phone:        +33 671887502
> 
> role:         NDSoftware NOC
> address:      NDSoftware
> address:      57 rue du president Wilson
> address:      92300 Levallois-Perret
> address:      France
> phone:        +33 671887502
> 
> 
> I'm sorry Nicolas.  Providing address space to YOURSELF doesn't
> count!  Sheesh! 


NDSoftware and IPv6-FR are in the same building but aren't the same
legal organization.
I'm a network administrator for the both.

> > NexGentCollective (http://www.nextgencollective.net/)
> > tunnel broker:  150 users, each user have a /48. 
> 
> ipv6-site:    NEXTGENCOLLECTIVE
> origin:       AS65055
> descr:        NextGenCollective IPv6 Research Organization
> country:      US
> prefix:       3FFE:8271:A020::/44
> prefix:       3FFE:8271:A030::/44
> prefix:       3FFE:8271:B000::/40
> prefix:       3FFE:2C01:1000::/36
>
> Don't you think that a tunnel-broker housed in Wichita, KS, USA would be
> better served by a 6bone pTLA *IN* the USA?  Also, with your current
> peering policy change, isn't this site going to get NIXED?  I note their
> use of a Reserved ASN.

They don't find any help somewhere...

We don't only provide a block, we provide a small tech support, help in
tunnel and zebra configuration,....

> > > Part of properly maintaining _YOUR_ ipv6-site object is making sure that
> > > you don't reference an object that doesn't exist.  If someone is unable or
> > > unwilling to create & maintain an ipv6-site object, do you really feel
> > > that they are a good peering candidate?  I certainly don't.
> > 
> > They can be a good peering candidate !
> > 
> > A whois updated or not don't make the quality of a peering. 
> 
> 
> I SERIOUSLY BEG TO DIFFER!  If someone is too damned lazy to create and
> maintain an ipv6-site object, how on earth can you expect them to maintain
> appropriate BGP filters, allocation records, etc, etc, etc?  Man, it is
> _OBVIOUS_ that this is a *toy* to you.
> 
> By virtue of your ipv6-site object referencing tunnel endpoints that have
> no corresponding ipv6-site object, it is NOT accurate and you (and your
> sites with nonexistant or invalid ipv6-site objects) are in violation of
> RFC2772:
> 
> 5. The 6Bone Registry
> 
>    The 6Bone registry is a RIPE-181 database with IPv6 extensions used
>    to store information about the 6Bone, and its sites. The 6bone is
>    accessible at:
> 
>          <http://www.6bone.net/whois.html>)
> 
>    Each 6Bone site MUST maintain the relevant entries in the 6Bone
>    registry. In particular, the following object MUST be present for all
>    6Bone leaf sites, pNLAs and pTLAs:
> 
>    -  IPv6-site: site description
> 
>    -  Inet6num: prefix delegation (one record MUST exist for each
>       delegation)
> 
>    -  Mntner: contact info for site maintance/administration staff.
> 
>    Other object MAY be maintained at the discretion of the sites such as
>    routing policy descriptors, person, or role objects.  The Mntner
>    object MUST make reference to a role or person object, but those MAY
>    NOT necessarily reside in the 6Bone registry. They can be stored
>    within any of the Internet registry databases (ARIN, APNIC, RIPE-NCC,
>    etc.)
> 
> 6. Guidelines for new sites joining the 6Bone
> 
>    New sites joining the 6Bone should seek to connect to a transit pNLA
>    or a pTLA within their region, and preferably as close as possible to
>    their existing IPv4 physical and routing path for Internet service.
>    The 6Bone web site at <http://www.6bone.net> has various information
>    and tools to help find candidate 6bone networks.
> 
>    Any site connected to the 6Bone MUST maintain a DNS server for
>    forward name lookups and reverse address lookups.  The joining site
>    MUST maintain the 6Bone objects relative to its site, as describe in
>    section 5.
> 
>    The upstream provider MUST delegate the reverse address translation
>    zone in DNS to the joining site, or have an agreement in place to
>    perform primary DNS for that downstream. The provider MUST also
>    create the 6Bone registry inet6num object reflecting the delegated
>    address space.
> 
> 
> 
> 
> 
> 
> Now, from section 7 of RFC2772, a bit more for you to ponder:
> 
>       During the entire qualifying period the Applicant must be
>       operational providing the following:
> 
>       a. Fully maintained, up to date, 6Bone Registry entries for their
>          ipv6-site inet6num, mntner, and person objects, including each
>          tunnel that the Applicant has.
> 
> <snip>
> 
> 
>    4. The pTLA Applicant MUST commit to abide by the current 6Bone
>       operational rules and policies as they exist at time of its
>       application, and agree to abide by future 6Bone backbone
>       operational rules and policies as they evolve by consensus of the
>       6Bone backbone and user community.
> 
> 
> 
> Now, since you obviously don't care if your peers maintain their ipv6-site
> objects or even HAVE them for that matter, how is it that you are abiding
> by RFC2772, Section 5?
> 

Check all others pTLA request, you have the same problem.

You can't force a peer to register a whois entry...

Our whois is always updated.