Re: New routing ideas for OpenBSD ;) (Was: Is Theo still hiking ????)

2007-01-30 Thread Brian Candler
On Mon, Jan 29, 2007 at 04:09:41PM +, Jeroen Massar wrote:
  There is *NO* demand from anyone for giving /48's to customers. It is
  only a suggestion.
  
  Talking again about RIPE policy, section 5.4.1 requires /48, or larger for
  very large subscribers. Exceptions are made to allow /64 when it is known
  that one and only one subnet is needed by design, and /128 when it is
  absolutely known that one and only one device is connecting
 
 As I said it is only a suggestion. When a LIR gives out /56's they can
 do this. No RIPE police will be knocking on their doors.

But surely, if LIR's feel it is necessary to make smaller allocations than
/48's, it's a tacit admission that this supposedly near-infinite IPv6 space
is *already* under pressure.

I think you're right in one sense: /48 end-user allocations are stupid. With
128 bits of address space, you could give most end users a /112, which would
still be the equivalent of a whole class B in the current Internet. But the
current IPv6 design is broken.

 BTW: calculate how many /48's are in 2000::/3 and you'll get an idea.

France Telecom got a /19. Does this mean they have a plan to connect 2^29
(over 500 million) customers in the next two years? I don't think so.

Making your network aggregatable means having a lot of address sparseness,
and therefore a large amount of wastage.

The attitude which says I'll allocate a /32 here, rather than the /39 I
actually need, because the boundary is easier to see and type compounds
this problem by orders of magnitude.

  So NAT will be deployed because it has *commercial* benefits. The IPv6
  techno-utopians will continue to be unhappy.
 
 No the application programmer will remain unhappy as they need to fiddle
 to get around that NAT all the time.

Well, any protocol which has separate control and data connections will
require application layer gateway magic at the firewall, even without NAT,
since the firewall has to open new [src,srcport,dst,dstport] tuples in
response to requests negotiated down the control connection, and therefore
it has to fully parse and understand the control messages. Adding support
for NAT is only a small extra bit of work.

Some would argue that all firewalls should be application layer gateways
anyway. Do I want my clients talking HTTP directly, packet-by-packet, to
untrusted servers on the Internet? Or should the firewall take a HTTP
request, forward it, accept and validate the whole response, passing it in
sanitised form back to the client?

The former leaves the clients vulnerable to all sorts of attacks from
malicious servers. The latter allows the firewall to validate data. As a
side effect it can also give an audit log of activity at layer 7, which many
companies require for compliance reasons anyway.

Regards,

Brian.



New routing ideas for OpenBSD ;) (Was: Is Theo still hiking ????)

2007-01-29 Thread Jeroen Massar
[changed subject to something more related ;) ]

Brian Candler wrote:
 On Sun, Jan 28, 2007 at 03:17:14PM +, Jeroen Massar wrote:
 And if you need to change ISP, and
 therefore get a new address allocation, many people would rather just put
in
 some NAT at the border than take the pain of network renumbering (which
IPv6
 doesn't make any easier than IPv4)
 Depends on the size of your network of course. But you can actually get
 IPv6 PI space already, you will have to cash out a bit for it, just like
 for IPv4 address space, but it is there. Problem for that solved. Same
 non-scaling solution as in IPv4. No differences there.

 And otherwise read RFC4193 to get your unique local goo for free.

 I'll freely admit I've not been following every micro-level change to IPv6
 over the last couple of years, nor every RIR policy. I wrote my notes in
 2004, a year before RFC4193 came out.

That Internet thing is a changing place, things that are broken get fixed ;)

[..]
 Now, there is a proposal for modifying this policy to allow PI allocations:
 http://www.ripe.net/ripe/policies/proposals/2006-02.html
 but as far as I can tell this is still just a proposal.

Then shout and scream in the RIPE forums and support the policy. That is
the only way that it will be accepted: when the majority wants it.

[..]
 That is, the IPv6 tail still tries to wag the commercial dog.

The Internet has been commercial for ages already, thus of course it
will follow the people with the big money. But as with any kind of
politics, and this is just that, the one with the biggest mouth +
biggest amount of cash wins.

 Of course if you have better ideas, you can always bring it up on the
 various RIR forums.

 I'm afraid my better idea is to abandon IPv6 as still-born, and stick
with
 IPv4 until we have a new protocol which addresses more of the problems of
 the Internet today.

Which is a bad plan. Although the routing issues are not solved (yet).
The addressing issue is solved with IPv6. Getting a deployed base of
enduser systems that supports IPv6 is a very important factor. Otherwise
you will finally have this great routing system, but nothing will
actually be able to use it yet and thus you still have to wait for the
endusers to upgrade; which will take ages. Deploying IPv6 now is a good
thing.

The core of the network will take care of the routing and any other
tricks that will be needed to route the 128bit address space.
Routing is the problem, not the addressing anymore.

 If IPv6 had stuck
 with DHCP, which everyone knows and understands, then you could just give
 each customer a /96, rather than a /48 as demanded by IPv6, and we would
 have addresses for aeons. Not so now.
 There is *NO* demand from anyone for giving /48's to customers. It is
 only a suggestion.

 Talking again about RIPE policy, section 5.4.1 requires /48, or larger for
 very large subscribers. Exceptions are made to allow /64 when it is known
 that one and only one subnet is needed by design, and /128 when it is
 absolutely known that one and only one device is connecting

As I said it is only a suggestion. When a LIR gives out /56's they can
do this. No RIPE police will be knocking on their doors.

Also there are proposals to start using /56's. The counter argument
against them though is that there are so extremely many /48's and so
extremely many /32's to get them from that the point of using /56's is a
little bit moot.

/48's are very handy in use, as the first 4 numbers are 'theirs', the
rest is yours.

BTW: calculate how many /48's are in 2000::/3 and you'll get an idea.
Note that when 2000::/3 is full there are 7 other 'tries' left to get it
right.

 But the implication of this policy is that it is not feasible for a
customer
 to have one /64 and slice it up into 2^32 /96's (for instance), because
 otherwise you could just give all customers a /64. That contradicts what
you
 wrote.

If that customer requires multiple /64's they should get a /48 at the
moment. Note my use of SHOULD which is not a MUST.

 I suggest you start doing some background reading, read a good book or
 something as you clearly are missing a LOT of information, as I've
 easily shown by the answering the FUD you where trying to spread above.

 Well, I don't know what the opposite of FUD is called, but IPv6
 afficianados have been trying to spread it for many many years :-)

Some people like marketing and filling their pockets with government and
 consulting tricks, can you blame them? ;)

 Therefore many of the points you make are essentially agreeing with me:
IPv4
 and IPv6 are the same in many cases.

Correctemundo. Except for the larger address space they are mostly the same.

 3. THE MULTI-HOMING PROBLEM
 See 1) Same problem in effect.

 Btw, phone numbers are analogous to DNS, not to IP addresses.

 Yes. So in a *real* solution to the problems of IPv4, maybe you make IP
 addresses look more like DNS names.

 Random thought: consider something like IP header stuffing. Each