[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: new draft on IPv6 CPE router available for review

On Fri, 4 Jul 2008, teemu.savolainen@nokia.com wrote:


If the forwarding is the key differentiator, then isn't e.g. "host"
computers running Microsoft Windows, Apple OS/X, and even certain mobile
phones, also "routers" as they support "sharing of the network
connection", which means forwarding packets from the uplink connection
to local area network - possibly implementing DHCPv4 server, to allocate
private IPv4 addresses for LAN, and NAT for address translation between
LAN and uplink connection?


Correct.


If the "CPE router" would be defined as something that implements and
executes routing protocols, has MIBs, is fully controllable by ISP then
these hosts would not fit into that category.
For me, for instance a D-link 604 (NAT gateway) is a CPE router, if that helps. It doesn't do SNMP, no routing protocols, but some of those are provisionable via DHCP (will tftp download conf files). 


Anyhow, in my mind a "host" is not so much of a name for a category of
devices, but rather a behavioral pattern of a node. At any given moment
a node can start to behave as a "router" (if that is defined only as
doing packet forwarding). For a network the node may still look like a
"host", if the node does this transparently for the network (i.e. with
help of NAT).
Yes, I realise this, but I want my native IPv6 service offering to require a "router" class device, even if it means that this "router" only forwards traffic logically between the WAN link-local interface and it's internal loopback address (DHCPv6-PD assigned space). 


I did not think that was the idea either? If the end hosts would use
DHCPv6 PD, would that be an act of sourcing packets to IP core? If so,
could the delegating DHCPv6 server locate somewhere where "hosts" could
safely (from ISP point of view) talk?

The talking to ISP core is one differentiator, then we might(?) have:
Hm, the problem is that i don't want customers in core IP space, and I don't want core in customer IP space. 


(1) CPE router:
- allowed to directly source packets to ISP core
[host]---[CPE router]---[ISP]---[Internet]
What adresses would be used between CPE router and ISP? I would like it to be link-local only. 


(2) "Host router":
- not able to directly source packets to ISP core, but still able to
forward packets and use DHCPv6 PD
[host]---[host router]---[CPE router/access
concentrator]---[ISP]---[Internet]

The (1) case is what you are aiming I believe, and the (2) is what I'm
trying to describe.


Sounds about right, if (1) CPE-router <-> ISP is link-local.


An example of case (1) would be a DSL box at home/small office, and an
example of case (2) would be a cellular device that:
- connects with point-to-point link to operator's access concentrator
(e.g. GGSN), and gets a /64 prefix for itself (SLAAC)
- uses DHCPv6 PD to get more prefixes, and announces these prefixes to
LAN
- possibly implements DHCPv6 relay in order to enable other devices in
LAN to utilize DHCPv6 PD as well
Yes, that sounds about right, but what adress space is used on the p-t-p link? Is that the /64? That would mean that the GGSN IP adress in this space is globally reachable, with the security implications that brings.
Then again, I think tunneled approach is suboptimal as well, it usually involves CPU/network processors which have fairly low performance (compared to simple L3 switch devices using ASICs), so they can probably get into trouble even if the customer space is DDOSed anyway, and have to incorporate means to protect against that. 

A cheap and efficient service delivery or IPv6 for me is:

[host]-PD-[CPE router]-ll-[L3 switch]-core
The L2 and L3 device might be the same device, ie a L2/L3 switch with IPv6 capability, with either VDSL2 or Ethernet PHY. It will most likely have limited TCAM space (might be 1024 entries or something like that), does forwarding using ASICs and very limited CPU resources, thus the reason why I want to protect it from IP packets from the global Internet. 

--
Mikael Abrahamsson    email: swmike@swm.pp.se