Subject: More CPE

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 10 Jan 2008 01:15:45 +0100

Based on the discussion of the past days, I think this is a mixture of  
what we seem to agree on and some random things that I think are  
necessary and/or a good idea. Feel free to shoot down any part as  
needed.

All of this only applies to presumably unmanaged consumer and SOHO  
installations.

1. The expectation is that broadband modems will have IPv6 routing  
functionality.

2. Despite 1., we expect users to be able to add zero or more IPv6  
routers of their own.

3. Authentication of users towards ISPs is undefined at this time.

4. These routers (both with and without modem functionality) configure  
addresses and routing functionality as follows:

4a. The router listens for RAs on its WAN port. If there are RAs with  
global prefixes, the router autoconfigures global addresses as usual  
for hosts. If there are no global prefixes in the RAs then the router  
doesn't autoconfigure global addresses and borrows a global address  
from another interface when necessary for generating ICMP messages  
etc. If the advertised prefixes are (unique) site local the behavior  
is undefined; this is not recommended. If there are no RAs there is no  
native IPv6 connectivity and/or manual configuration is required.

4b. DAD is performed as specified in the relevant RFCs with the  
understanding that if the layer 2 network echoes back the router's own  
neighbor solicitation that is used for DAD the router recognizes its  
own source MAC address and doesn't take reception of this packet to  
mean the address is a duplicate. (To aid in ISP configurations where  
layer 2 multicasts must go through a central point so looping back of  
multicast packets can't be avoided.)

4c. Routers obtain an IPv6 prefix through DHCPv6 prefix delegation.  
They honor the unicast server option if they have a RA configured  
global address so that ISPs may base DHCPv6 server decisions on the  
autoconfigured address if this is desired as an alternative for  
implementing DHCPv6 snooping and option injection.

4d. If prefix delegation is unsuccessful but there are RAs with global  
prefixes on the WAN side, the router ceases native IPv6 routing and  
offers the user the option to operate in bridge mode and/or falls back  
to tunneling. Routers that can reasonably assume to operate behind  
another router (i.e., routers that don't have modem functionality) and  
routers that can firewall while operating in bridge mode MAY enter  
bridge mode automatically.

4e. Because of 2., it is recommended that routers implement DHCPv6  
prefix delegation server functionality in order to sub-delegate part  
of the prefix obtained from the ISP to routers connected on the LAN  
side. Routing of delegated prefixes must track the delegation;  
lifetimes must track those of the prefix the router itself obtained as  
a DHCPv6 PD client. It is recommended that routers sub-delegate the  
next power of two block equal to or larger than half the address space  
obtained but not in use in order to allow for the maximum possible  
daisy chaining of routers. Prefix delegation through a DHCPv6 relay is  
not recommended because the relay can't be presumed capable of  
installing the required routes.

5. Routers advertise the prefixes they have learned through DHCPv6  
prefix delegation using RAs on the LAN side using lifetimes copied  
from the DHCPv6 lifetimes. If the ISP-supplied prefix is shorter than / 
64 then, in the absense of user configuration, the router uses the  
lowest /64 from that prefix on the LAN side. (Discussion: this makes  
everything easier to guess for attackers. But using random bits here  
will lead to unnecessary address changes when the router reboots and  
makes troubleshooting more difficult.) The router tracks at least the  
two most recently delegated prefixes from the ISP, i.e., during  
renumbering events both the old and new prefix are usable for as long  
as the lifetime of the old prefix persists.

6. Routers validate the source addresses of outgoing packets.

6a. Optionally, routers track the presence of other routers on their  
LAN side and forward packets with source addresses that match the  
prefixes advertised by those routers to them. (Helps to get around  
ingress filtering by ISPs when there are multiple routers connecting  
to multiple ISPs.)

6b. Optionally, routers may obtain multiple global addresses and  
default gateways through RAs and multiple prefixes using DHCPv6 PD and  
then use both sets of information side by side in such a way that  
packets go to the next hop router / ISP matching the source address in  
packets received on the LAN side. (Very helpful for shim6-style  
multihoming.)

6c. Routers generate "invalid source address" ICMP errors for packets  
that can't be forwarded because their source address falls outside of  
the delegated prefix. (The full prefix if shorter than /64.) (More  
robust in the presence of ingress filtering.)

7. Routers support at least a small number of static routes,  
preferably such that static routes to other routers within the site  
can be set up with wildcard bits for the ISP-delegated prefix. (To  
allow having different subnets separated by different routers within a  
site.)

8. If routers have stateless DHCPv6 server capability, they MAY set  
the O bit in their router advertisements and provide DNS, domain etc  
information that they obtained along with the DHCPv6 prefix  
delegation, IPv4 DHCP or from manual configuration to hosts on the LAN  
side through stateless DHCPv6. A router that is prepared to forward  
DNS queries to IPv4 DNS servers, has 1 or more IPv4 resolver addresses  
and IPv4 connectivity SHOULD advertise its own address through  
stateless DHCPv6 if it doesn't know of any IPv6 DNS resolvers.

9. If routers don't implement DHCPv6 server capability, they SHOULD  
implement a DHCPv6 relay function and copy the O bit from RAs received  
on the WAN side in their own RAs on the LAN side.

(Discussion: having ISPs push the M bit / stateful address  
configuration is probably not appropriate. However, if the hosts  
generate stateful DHCP requests anyway, a relay is a relay...)

10. Routers SHOULD insert the IPv6 DNS resolver addresses they have  
knowledge of in an RFC 5006 RA option. A router that is prepared to  
forward DNS queries to IPv4 DNS servers, has 1 or more IPv4 resolver  
addresses and IPv4 connectivity SHOULD advertise its own address in an  
RFC 5006 RA option if it doesn't know of any IPv6 DNS resolvers.

11. Firewalling in unmanaged routers is a complex issue. Both  
firewalling and not firewalling have important downsides. See separate  
documents on firewalling best practices in this area and on how to  
open up ports in firewalls. Irrespective of that, it is highly  
recommended that vendors in this area make it as easy as possible for  
users to enable/disable firewalling, both site-wide and on a per-host  
basis. (Based on MAC address?)

(Discussion: how does a host know if it's firewalled? In IPv4 you can  
see that you have an RFC1918 address. But your IPv6 address is the  
same whether you need to bypass a firewall or not. Apparently, at  
least one vendor has decided to not publish AAAA records because of  
this issue. Do we need to push out information about the firewall  
status to hosts?)

(Discussion: is there any MIPv6 functionality that is so important  
that we should try to get CPE vendors to implement it?)

---

From: "Miguel A. Diaz" <[email-masked]>
Date: Thu, 10 Jan 2008 10:54:22 +0100

If both RA and DHPCPv6 are setup in the WAN port, the ISP has to
manage two prefix pools: one for the point-to-point link (RA) and the
other one for the delegated prefix (usually /48).

That can be avoided by getting one /64 for the point-to-point link
(RA) from the delegated prefix (/48) as explained at
http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-point2point-
01.txt

This approach has benefits from both operational and routing
aggregation perspectives and it may be taken into account by both ISPs
and CPEs manufacturers.

Regarding MIPv6, the most important feature that a firewalled CPE must
implement is not filtering the specific extension headers to let MIPv6
to work:

* Destination option extension header
* Type 2 routing extension header
* MIPv6 extension header messages (BU, BA, BE, etc.)

See
http://www.ist-enable.org/open/draft-thiruvengadam-nsis-mip6-fw-06.txt
for detailed explanation on this.

Otherwise the firewalled CPE should implement some signaling mechanism
to open the required pinholes in the firewall for allowing such
packets to go out/come in, for instance by using the NSIS protocol as
proposed at
http://www.ietf.org/internet-drafts/draft-thiruvengadam-nsis-mip6-fw-0
8.txt

Regards
Miguel

> -----Mensaje original-----
> De: [email-masked] 
> [mailto:[email-masked]] En nombre de Iljitsch van Beijnum
> Enviado el: jueves, 10 de enero de 2008 1:16
> Para: IPv6 Operations
> Asunto: More CPE
> 
> Based on the discussion of the past days, I think this is a 
> mixture of what we seem to agree on and some random things 
> that I think are necessary and/or a good idea. Feel free to 
> shoot down any part as needed.
> 
> All of this only applies to presumably unmanaged consumer and 
> SOHO installations.
> 
> 1. The expectation is that broadband modems will have IPv6 
> routing functionality.
> 
> 2. Despite 1., we expect users to be able to add zero or more 
> IPv6 routers of their own.
> 
> 4. These routers (both with and without modem functionality) 
> configure addresses and routing functionality as follows:
> 
> 4a. The router listens for RAs on its WAN port. If there are 
> RAs with global prefixes, the router autoconfigures global 
> addresses as usual for hosts. If there are no global prefixes 
> in the RAs then the router doesn't autoconfigure global 
> addresses and borrows a global address from another interface 
> when necessary for generating ICMP messages etc. If the 
> advertised prefixes are (unique) site local the behavior is 
> undefined; this is not recommended. If there are no RAs there 
> is no native IPv6 connectivity and/or manual configuration is 
> required.
> 
> 4b. DAD is performed as specified in the relevant RFCs with 
> the understanding that if the layer 2 network echoes back the 
> router's own neighbor solicitation that is used for DAD the 
> router recognizes its own source MAC address and doesn't take 
> reception of this packet to mean the address is a duplicate. 
> (To aid in ISP configurations where layer 2 multicasts must 
> go through a central point so looping back of multicast 
> packets can't be avoided.)
> 

> They honor the unicast server option if they have a RA 
> configured global address so that ISPs may base DHCPv6 server 
> decisions on the autoconfigured address if this is desired as 
> an alternative for implementing DHCPv6 snooping and option
injection.
> 
> 4d. If prefix delegation is unsuccessful but there are RAs 
> with global prefixes on the WAN side, the router ceases 
> native IPv6 routing and offers the user the option to operate 
> in bridge mode and/or falls back to tunneling. Routers that 
> can reasonably assume to operate behind another router (i.e., 
> routers that don't have modem functionality) and routers that 
> can firewall while operating in bridge mode MAY enter bridge 
> mode automatically.
> 
> 4e. Because of 2., it is recommended that routers implement 
> DHCPv6 prefix delegation server functionality in order to 
> sub-delegate part of the prefix obtained from the ISP to 
> routers connected on the LAN side. Routing of delegated 
> prefixes must track the delegation; lifetimes must track 
> those of the prefix the router itself obtained as a DHCPv6 PD 
> client. It is recommended that routers sub-delegate the next 
> power of two block equal to or larger than half the address 
> space obtained but not in use in order to allow for the 
> maximum possible daisy chaining of routers. Prefix delegation 
> through a DHCPv6 relay is not recommended because the relay 
> can't be presumed capable of installing the required routes.
> 
> 5. Routers advertise the prefixes they have learned through 
> DHCPv6 prefix delegation using RAs on the LAN side using 
> lifetimes copied from the DHCPv6 lifetimes. If the 
> ISP-supplied prefix is shorter than /
> 64 then, in the absense of user configuration, the router 
> uses the lowest /64 from that prefix on the LAN side. 
> (Discussion: this makes everything easier to guess for 
> attackers. But using random bits here will lead to 
> unnecessary address changes when the router reboots and makes 
> troubleshooting more difficult.) The router tracks at least 
> the two most recently delegated prefixes from the ISP, i.e., 
> during renumbering events both the old and new prefix are 
> usable for as long as the lifetime of the old prefix persists.
> 
> 6a. Optionally, routers track the presence of other routers 
> on their LAN side and forward packets with source addresses 
> that match the prefixes advertised by those routers to them. 
> (Helps to get around ingress filtering by ISPs when there are 
> multiple routers connecting to multiple ISPs.)
> 
> 6b. Optionally, routers may obtain multiple global addresses 
> and default gateways through RAs and multiple prefixes using 
> DHCPv6 PD and then use both sets of information side by side 
> in such a way that packets go to the next hop router / ISP 
> matching the source address in packets received on the LAN 
> side. (Very helpful for shim6-style
> multihoming.)
> 
> 6c. Routers generate "invalid source address" ICMP errors for 
> packets that can't be forwarded because their source address 
> falls outside of the delegated prefix. (The full prefix if 
> shorter than /64.) (More robust in the presence of ingress
filtering.)
> preferably such that static routes to other routers within 
> the site can be set up with wildcard bits for the 
> ISP-delegated prefix. (To allow having different subnets 
> separated by different routers within a
> site.)
> 
> 8. If routers have stateless DHCPv6 server capability, they 
> MAY set the O bit in their router advertisements and provide 
> DNS, domain etc information that they obtained along with the 
> DHCPv6 prefix delegation, IPv4 DHCP or from manual 
> configuration to hosts on the LAN side through stateless 
> DHCPv6. A router that is prepared to forward DNS queries to 
> IPv4 DNS servers, has 1 or more IPv4 resolver addresses and 
> IPv4 connectivity SHOULD advertise its own address through 
> 9. If routers don't implement DHCPv6 server capability, they 
> SHOULD implement a DHCPv6 relay function and copy the O bit 
> from RAs received on the WAN side in their own RAs on the LAN side.
> 
> configuration is probably not appropriate. However, if the 
> hosts generate stateful DHCP requests anyway, a relay is a relay...)
> 
> 10. Routers SHOULD insert the IPv6 DNS resolver addresses 
> they have knowledge of in an RFC 5006 RA option. A router 
> that is prepared to forward DNS queries to IPv4 DNS servers, 
> has 1 or more IPv4 resolver addresses and IPv4 connectivity 
> SHOULD advertise its own address in an RFC 5006 RA option if 
> it doesn't know of any IPv6 DNS resolvers.
> 
> firewalling and not firewalling have important downsides. See 
> separate documents on firewalling best practices in this area 
> and on how to open up ports in firewalls. Irrespective of 
> that, it is highly recommended that vendors in this area make 
> it as easy as possible for users to enable/disable 
> firewalling, both site-wide and on a per-host basis. (Based 
> on MAC address?)
> 
> (Discussion: how does a host know if it's firewalled? In IPv4 
> you can see that you have an RFC1918 address. But your IPv6 
> address is the same whether you need to bypass a firewall or 
> not. Apparently, at least one vendor has decided to not 
> publish AAAA records because of this issue. Do we need to 
> push out information about the firewall status to hosts?)
> 
> (Discussion: is there any MIPv6 functionality that is so 
> important that we should try to get CPE vendors to implement it?)
> 
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Jan 2008 21:22:01 +1030

On Thu, 10 Jan 2008 10:54:22 +0100

> aggregation perspectives and it may be taken into account by both ISPs

I'm personally not against this addressing method, however I'm not all
that sure that might be a good idea for the customers. "Stealing" a /64
out of the customer's /48 creates opportunities for the customer to
accidently use it on their side of the CPE, breaking their external
connectivity. This probably would only happen occasionally (although as
an ISP you'd probably want to avoid the first 5, 20 or 100 /64s),
however when you have 10 000s or 100 000s customers, those occasions
can start to occur quite often, and those are calls your helpdesk has
to receive and deal with.

IOW, I think it's easier for all customers to remember, "this /48 is
mine", verses "this /48 is mine, except that one which my ISP assigns,
that I'll always have to remember to avoid."

Regards,
Mark.

---

From: [email-masked]
Date: Thu, 10 Jan 2008 10:50:55 -0700

Iljitsch van Beijnum writes: 

> necessary and/or a good idea. Feel free to shoot down any part as  needed. 
> 

I would presume that the same authentication that is used now would still be 
appropriate. Currently my CPE (Router, DSL Modem, etc.) needs to 
authenticate using a user name and password provided by the ISP.

---

From: james woodyatt <[email-masked]>
Date: Thu, 10 Jan 2008 10:31:06 -0800

On Jan 9, 2008, at 16:15, Iljitsch van Beijnum wrote:
>
> (Discussion: how does a host know if it's firewalled?

That's easy.  It receives an ALD Firewall Advertisement message.  A  
more difficult question is How Does A Node Discover That It *ISN'T*  
Firewalled?

> In IPv4 you can see that you have an RFC1918 address. But your IPv6  
> address is the same whether you need to bypass a firewall or not.  
> Apparently, at least one vendor has decided to not publish AAAA  
> records because of this issue. Do we need to push out information  
> about the firewall status to hosts?)

Heh.  I've seen at least one large US financial institution *remove*  
its AAAA records for the more serious reason that some (more than  
one) major North American ISP's are deliberately routing 6to4 traffic  
into black holes and refusing to deploy relays of their own between  
their production IPv6 and IPv4 networks.

We have more than a few bugs to work out of the system at this point.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Jan 2008 09:34:24 +1300

> that I'll always have to remember to avoid."

Surely it should be the CPE itself that does the remembering? I don't
envisage that SOHO users will be assigning IPv6 prefixes manually.
And even if they did, a simple instruction like "start numbering your
subnets at 1, because subnet 0 is used internally" should work.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 11 Jan 2008 08:21:43 +1030

On Fri, 11 Jan 2008 09:34:24 +1300

> subnets at 1, because subnet 0 is used internally" should work.

Possibly. OTOH, it could be the CPE vendors that pre-configure subnet
numbers to the one or more downstream interfaces for use with DHCP-PD,
and they might be in the habit of using the first 3 subnets, possibly
including zero.

If we were to recommend a /64 to "steal", I'd be suggesting 0xffff or
maybe 0x00ff (for /56 case) (although people like me tend to use those
specifically *because* they don't conflict with what other people
commonly choose :-) ).

Regards,
Mark.

---

From: james woodyatt <[email-masked]>
Date: Thu, 10 Jan 2008 14:53:13 -0800

On Jan 10, 2008, at 01:54, Miguel A. Diaz wrote:
> manage two prefix pools: one for the point-to-point link (RA) and  
> the other one for the delegated prefix (usually /48).

And, this is difficult why?  Everyone at the ISP has only one finger—  
so, therefore, they're unable to count up to two?

> That can be avoided by...

I think you skipped a step.  I don't understand why you want to spend  
any effort avoiding this "problem" when the "solution" seems to pose  
a whole passle of other, new and interesting problems, i.e. how to  
delegate a fractional prefix to a customer, i.e. "all these addresses  
belong to you, except this /64... ATTEMPT NO LANDINGS THERE!"

---

From: Alain Durand <[email-masked]>
Date: Thu, 10 Jan 2008 18:25:49 -0500

> 1. The expectation is that broadband modems will have IPv6 routing

This assumption is wrong. DOCSIS (2.0 & 3.0) modems are defined as simple
bridges for both IPv4 and IPv6. There is an additional spec, the "eRouter"
that define a minimum optional implementation of IPv6 routing, so you'll see
two types of products, bridges & routers.

   - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Jan 2008 14:16:09 +1300

> two types of products, bridges & routers.

So a subscriber who gets stuck behind the bridge version but wants to run
an IPv6 subnet will have to buy a separate router and get a prefix from
somewhere? That's broken.

   Brian

---

From: "Miguel A. Diaz" <[email-masked]>
Date: Fri, 11 Jan 2008 09:23:07 +0100

> De: Mark Smith 
> [mailto:[email-masked]] 
> Enviado el: jueves, 10 de enero de 2008 11:52
> Para: [email-masked]
> CC: [email-masked]
> Asunto: Re: More CPE
> 
> I'm personally not against this addressing method, however 
> I'm not all that sure that might be a good idea for the 
> customers. "Stealing" a /64 out of the customer's /48 creates 
> opportunities for the customer to accidently use it on their 
> side of the CPE, breaking their external connectivity. This 
> probably would only happen occasionally (although as an ISP 
> you'd probably want to avoid the first 5, 20 or 100 /64s), 
> however when you have 10 000s or 100 000s customers, those 
> occasions can start to occur quite often, and those are calls 
> your helpdesk has to receive and deal with.
> 

Not sure if that will happen very likely. Most of the residential
users don't know anything about networking, so they just follow the
instructions from their ISPs and/or CPEs. Probably they will have one
only router (the CPE) which in the event this addressing method is a
convention it will prevent the assignment of the WAN /64 to other LAN
port.

In case of advanced users and or network administrators in
enterprises, there's nothing new with this addressing method. Those
users are supposed to be able to manage ip address allocation in the
same way that currently happens with IPv4: if they receive an IPv4 /29
from their ISP, they must be able to know what IP is broadcast, what
the gateway, etc, and not re-use it in the internal network.

> IOW, I think it's easier for all customers to remember, "this 
> /48 is mine", verses "this /48 is mine, except that one which 
> my ISP assigns, that I'll always have to remember to avoid."
> 
> Regards,
> Mark.
> 

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: "Miguel A. Diaz" <[email-masked]>
Date: Fri, 11 Jan 2008 09:52:08 +0100

> [mailto:[email-masked]] En nombre de james woodyatt
> Enviado el: jueves, 10 de enero de 2008 23:53
> Para: IPv6 Operations
> Asunto: Re: More CPE
> 
> And, this is difficult why?  Everyone at the ISP has only one 

Not really difficult but inefficient.

> finger- so, therefore, they're unable to count up to two?
> 
> I think you skipped a step.  I don't understand why you want 
> to spend any effort avoiding this "problem" when the 
> "solution" seems to pose a whole passle of other, new and 
> interesting problems, i.e. how to delegate a fractional 
> prefix to a customer, i.e. "all these addresses belong to 
> you, except this /64... ATTEMPT NO LANDINGS THERE!"
> 
> 

Having only one pool for address assignement has at least the
following advantages (surely others ones as well):

* better HD-Ratio. Probably you'll think is that really important in
IPv6? But any LIR has to take care of that in order to receive the IP
(v4 or v6) address space from its RIR.

* one only pool in the ISP AAA infrastructure (i.e. RADIUS), so you
reduce the configuration and maintenance resources

* you are able to reduce one route in routing table of the access
router (ISP side). See
http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-point2point-
01.txt section 4 for more details.

Regards
Miguel

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: Gert Doering <[email-masked]>
Date: Fri, 11 Jan 2008 11:20:31 +0100

hi,

> (v4 or v6) address space from its RIR.

As the ISP is explicitely allowed (at least in RIPE land) to use one /48 
per POP, this argument is pretty much moot.

"Ease of administration" and "less possible irritations on the customer
side" should be the focal points for IPv6 guidelines.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  110584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Remi Denis-Courmont <[email-masked]>
Date: Fri, 11 Jan 2008 13:28:10 +0100

On Fri, 11 Jan 2008 14:16:09 +1300, Brian E Carpenter

> somewhere? That's broken.

I don't see how this is broken.

When I bought my (IPv4-only) cable modem, I was given the choice between a

model with a single Ethernet port (that is the bridge version), and the

more expensive model with multiple ports (plus Wi-Fi, IIRC), which I assume

is actually a modem integrated with an IPv4 NAT-router.

To me, this is a feature (mind you I took the cheapest model!) not a bug.

-- 

Rémi

---

From: Mark Smith <[email-masked]>
Date: Sat, 12 Jan 2008 15:52:30 +1030

Hi Miguel,

On Fri, 11 Jan 2008 09:23:07 +0100

> the gateway, etc, and not re-use it in the internal network.

Another thought I've had is SOHO users might be interested in being
dual homed to the same upstream ISP. So at least 2 /64s would have to
be reserved and avoided out of the customers /48. I don't think we
can reserve the first two, as I'm pretty sure people will commonly
number their first subnet number one.

The first and last subnets might be ok, although renumbering the last
subnet of a /56 to the last subnet of a /48 if the customers prefix
length is shortened is something that probably would need to be done for
consistency. People are likely to forget subnet 0x00ff out of their /48
is taken if it isn't renumbered.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Jan 2008 11:32:23 +1300

> To me, this is a feature (mind you I took the cheapest model!) not a bug.

My assumption is that this is exceptional, and the typical SOHO
user wants to buy one box providing wireless and wired connectivity
for multiple hosts. But the vendors know better than I do what
they typically sell...

   Brian

---

From: Mark Smith <[email-masked]>
Date: Mon, 14 Jan 2008 19:27:12 +1030

On Mon, 14 Jan 2008 11:32:23 +1300

> for multiple hosts. But the vendors know better than I do what

All the DSL CPE my employer has sold over at least the last 3 years has
been router CPE. The options are either single ethernet/single USB or
embedded 4 port ethernet switch/single USB/wireless. They can be
configured to operate as a bridge, routed (with NAT) is the default.

Regards,
Mark.

---

From: "Eduard Metz" <[email-masked]>
Date: Tue, 15 Jan 2008 16:48:45 +0100

> for multiple hosts. But the vendors know better than I do what

The typical functionality of the-box-that-terminates-the-access-medium
may be different for different access technologies. E.g. for
DSL/copper the common choice seems to be L3, whereas for Cable and
Fiber L2 seems more common, for wireless (WiMax etc) ..? . Both models
are valid I guess. Also it doesn't change much wrt the functionality
of the first L3 CPE (if present), the first L3 node may be a host
though, instead of a router.

cheers,
  Eduard