[db-wg] RE: [ipv6-wg at ripe.net] RPSLng database deployment?

Sorry, this was a reply to the wrong message.

Tony

> -----Original Message-----
> From: Tony Hain [mailto:alh-ietf at tndh.net]
> Sent: Wednesday, October 06, 2004 5:09 PM
> To: 'Bernhard Schmidt'; 'db-wg at ripe.net'
> Cc: 'ipv6-wg at ripe.net'
> Subject: RE: [ipv6-wg at ripe.net] RPSLng database deployment?
> 
> A few additional comments now that the text is cleaned up:
> 
> The last sentence of 2.1 is out of context to the heading. The point it is
> making really belongs in 2.2. It makes a nice lead-in sentence, and taking
> the word 'these' out would probably fix the sentence to make sense as the
> start of the next section.
> 
> 2.2 ... ', and hence there is no specific security value in the NAT
> function.'   That should probably be a stand alone sentence with the 'NAT'
> string replaced by 'address translation'.
> 
> The perceived security comes from the lack of pre-established mapping
> state. Dynamically establishing state in response to internal requests
> prevents unexpected external connections to internal devices.
> 
> ... the security policy is already likely to consist of multiple
> components such as Firewalls, data-filters activity logging and intrusion
> detection systems. Simplified forms of these for the less security aware
> users could assist to make their private networks more secure.
> -delete list-
> 
> 2.4 ... they do prevent the external tracking and profiling of individual
> host computers by means of their IP addresses.
> -(2.3 just talked about how to track if one has access to the NAT, so this
> one needs to be explicit about external)-
> 
> ... which some enterprises believe is a useful ...
> - replace 'enterprises' with 'network managers' -
> 
> 2.5 ... unique and routable IPv4 address will continue increasing as
> allocation policies tighten so that they become more difficult to obtain.
> 
> 'This mechanism allows the simultaneous usage of certain IPv4 prefix for
> various end-customers or end-systems.  The overall benefit to the provider
> is that fewer globally unique IPv4 addresses are required.'
> - This is confusing unless the reader understands the need for stability
> in IPv4 end system configurations. RE: how does simultaneous use of an
> IPv4 address allow the ISP to use fewer addresses? It really doesn't. The
> ISP will use as many addresses as it takes for independent instances of an
> application. What NAT does in this situation is allow the IPv4 end systems
> to have stable addresses that may overlap with other organizations, and
> the ISP only needs as many public addresses as there are simultaneous
> instances of a given app. -
> 
> This type of local control of address resources allow a clean and
> hierarchical addressing structure in the network that is not restricted by
> the size of the publicly routed address pool.
> 
> 2.6.1 ... larger (probably with less-administrative overhead) IPv4 address
> range ...
> 
> 2.6.2 'only have only'  -->> 'have'
> 
> 'For this type of private networks mainly RFC 1918 addressing is used
> internally to reduce the needed amount of global routable prefixes,
> because there no need for owned IPv4 prefixes by the enterprise and for
> simplicity of the administrative overhead by the lack of a dedicated NOC.'
> - I don't buy the argument to begin with. 'Lack of need' is bogus and we
> shouldn't propagate it here because it will deflate the value of the IPv6
> argument later. We should put this in the context of a cost trade-off,
> forfeiting some applications in favor of reduced access costs. How about:
> Small networks typically deploy RFC 1918 addressing internally to limit
> the explicit charges for publicly routable addresses. This approach also
> has the advantage of avoiding the administrative overhead and dedicated
> NOC associated with acquiring blocks of publicly routed address space.
> 
> 2.6.3 ... 'due to the operational stateful operation' ...
> - I think the first operational should go.
> 
> 2.7 - drop the last sentence. For one those savings are only short term,
> the long term costs of dealing with conflicting space will be higher. For
> two, the point of the paper is to show how IPv6 makes things better, and
> even the simplified renumbering will appear to be more expensive than
> throwing a NAT at the problem. If you really want to say something about
> cost, put it in the context of -perception-, -short term-, and -simple-.
> -
> 
> Why is 2.8 different from 2.2?
> 
> I though you were going to align the numbering.
> 2.1 -> 3.2
> 2.2 -> 3.3
> I think we should be able to summarize with a table like:
>       Function          2.x    (IPv4)           3.x    (IPv6)
> x.1   Simple Gateway    simple management       DHCP-PD
> x.2   Simple security   stateful filter         reflexive acl
> x.3   tracking          nat state table         global uniqueness
> x.4   topology hiding   nat as virtual presence MIPv6
> x.5   addressing control RFC 1918               RFC 3177 & ULA
> x.6   address allocation RFC 1918               RFC 3177 & ULA
> x.7   renumbering        RFC 1918               Multiple addr/interface
> 
> Just trying to populate that table might clean up the overlaps and make it
> clear what the point of each section should be. If we can delineate the
> functions in crisp one or two word labels we can both make it simpler to
> understand and more consistent between the versions. As it is even I am
> having trouble figuring out if that table is correct. For example 3041 is
> listed in 3.5, but it does absolutely nothing for topology hiding. Yes
> privacy is one aspect of topology hiding, but end system privacy has
> nothing to do with masking the network topology.
> 
> 3.2 - why are renumbering & firewalls being discussed in the simple
> gateway section? -
> 
> 3.3 - the first two paragraphs are really summary material about ongoing
> evolution in best practices and shouldn't be here. The last paragraph is
> somewhat unrelated to the NAT->IPv6 effort. If it stays, comparable text
> should be in the IPv4 section that makes it clear that open ports through
> a nat will map to multiple machines, so configured state to run servers in
> the private space are just as exposed as they would be without the nat. -
> 
> 3.4 - all of this appears to be too much detail except the next to last
> paragraph. The last paragraph is about IPv4 and is already stated there so
> it should not be here. -
> 
> 3.5 - End system privacy and network topology privacy are very separate
> topics and shouldn't be in the same section. -
> 
> - recommending that people use different subnet structures for internal &
> external is just asking for trouble. Most 1st level ops have a hard enough
> time with subnets anyway, so making this unnecessarily complex is just a
> bad idea. 'Untraceable'/host-routes are a much better plan yet not even
> mentioned here. -
> 
> 3.6 - should be replaced with:
> IPv6 provides for autonomy in local use addresses through ULAs
(draft-???).
> At the same time IPv6 simplifies simultaneous use of multiple addresses
> per interface so that a NAT is not required (or even defined) between the
> ULA and the public Internet. Nodes that need access to the public Internet
> should have a global use address, and may simultaneously have a local use
> ULA. Since the IPv6 address space for global use is not a scarce resource
> like it is in IPv4, each network should be able to acquire a sufficient
> quantity for its needs. While global IPv6 allocation policy is managed
> through the Regional Internet Registries, it is expected that they will
> continue with derivatives of RFC 3177 for the foreseeable future.
> 
> 3.7.1 - seems to wander over several topics without a point. -
> 
> 3.7.3 - if the ISP is allocating /128's then 3041 is not possible.
> 
> 3.7.x - I still don't see the point in separating these out. There is
> nothing that says an ISP can't or shouldn't use DHCP-PD for *every*
> customer interface. The point is the length is flexible so any size
> network fits. If there is to be a static mapping it should be done on the
> back side of the DHCP server. The only time you might get into size
> distinction here is if the customer is not part of the ISP aggregate and
> is therefore injecting routes. The thing is injecting routes is not a
> function of IPv4/NAT, so it really doesn't belong in this document. -
> 
> 3.9 is really a subset of 3.3
> 
> I need to call it a day. I don't have a problem with the current draft
> going out as a -00, but we should follow it with a fixed up -01 asap.
> 
> Tony
> 
> 
> > -----Original Message-----
> > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf
> Of
> > Bernhard Schmidt
> > Sent: Wednesday, October 06, 2004 2:24 PM
> > To: db-wg at ripe.net
> > Cc: ipv6-wg at ripe.net
> > Subject: [ipv6-wg at ripe.net] RPSLng database deployment?
> >
> > Dear all,
> >
> > having missed the last RIPE meeting I'm unfortunately somewhat out of
> > date regarding this, but could someone please enlighten me about the
> > current plans for deployment of RPSLng in the regular RIPE database?
> >
> > I am using rpslng.ripe.net, but unfortunately almost noone else does.
> > Running a network without any sustainable prefix authorization sucks
> > quite hard, it is a real pain to have to contact your upstream by mail
> > if you have a new prefix (besides other things).
> >
> > Are there any problems with RPSLng currently?
> >
> > Thanks
> > Bernhard