Subject: [v6ops] default LAN routing protocol for IPv6 CE router

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 27 Jul 2011 11:28:30 -0500

IPv6 CPE router vendors, please give feedback.  Does anyone object if we
specify the default routing protocol as OSPFv3 with only area zero for
the IPv6 CE router bis document?   Or would you prefer the document is
silent on specification of any  default?

Thanks,

Hemant

---

From: Don Sturek <[email-masked]>
Date: Wed, 27 Jul 2011 09:33:44 -0700

Hi Hemant,

I think we need some type of default routing protocol.  We need to enable
deployment of devices into the home with the expectation that the various
sub-nets can be reached in terms of site local multicast (service discovery,
etc.) and I think that means we need to select a default routing protocol.

Don

From:  "Hemant Singh (shemant)" <[email-masked]>
Date:  Wed, 27 Jul 2011 11:28:30 -0500
To:  IPv6 Operations <[email-masked]>
Subject:  [v6ops] default LAN routing protocol for IPv6 CE router

IPv6 CPE router vendors, please give feedback.  Does anyone object if we
specify the default routing protocol as OSPFv3 with only area zero for the
IPv6 CE router bis document?   Or would you prefer the document is silent on
specification of any  default?
 
Thanks,
 
Hemant
 
_______________________________________________ v6ops mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 27 Jul 2011 13:25:37 -0400

> specification of any  default?

Can such a default be extensible to exchange different types of information
than just reachability? For example, can it propagate information such as
"this is a guest network and this is an internal network" or "this is a
prefix that I have tentatively assigned but do not own yet"? If not, then
perhaps something more flexible like IS-IS would be better.

---

From: Shishio Tsuchiya <[email-masked]>
Date: Wed, 27 Jul 2011 13:37:27 -0400

Hemant
I would like to comment as member of IPv6 home gateway sub working group in Japan.
I think OSPFv3 is not acceptable as default routing protocol on CPE router.
We considered RIPng as optional requirement when we made IPv6 home router guideline which published in June 2009.
http://www.v6pc.jp/pdf/v6hgw_Guideline_1_0-English.pdf

Regards,
-Shishio

Hemant Singh (shemant) wrote:
> IPv6 CPE router vendors, please give feedback. Does anyone object if we specify the default routing protocol as OSPFv3 with only area zero for the IPv6 CE router bis document? Or would you prefer the document is silent on specification of any default?
> 
> Thanks,
> 
> Hemant
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 27 Jul 2011 19:49:11 +0200 (CEST)

> I think OSPFv3 is not acceptable as default routing protocol on CPE router.

Care to elaborate on that?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Shishio Tsuchiya <[email-masked]>
Date: Wed, 27 Jul 2011 14:21:14 -0400

Mikael
> Care to elaborate on that?

Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol.
The reasons are..
-OSPF consumes CPU/memory than RIP.
-OSPF operetaion is needed more knowledge compare with RIP.
The character of these protocol does not change on IPv6 environment,too.
So we thought RIPng would be acceptable routing protocol for IPv6 CPE router,also.

Regards,
-Shishio

---

From: Ole Troan <[email-masked]>
Date: Wed, 27 Jul 2011 13:41:06 -0400

> IPv6 CPE router vendors, please give feedback.  Does anyone object if we specify the default routing protocol as OSPFv3 with only area zero for the IPv6 CE router bis document?   Or would you prefe…

I think this choice should be left for homenet. e.g. there are proposals for prefix assignment tightly coupled with a routing protocol.

cheers,
Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 27 Jul 2011 20:40:05 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ole Troan
> Sent: Wednesday, July 27, 2011 7:41 PM
> To: Hemant Singh (shemant)
> Cc: IPv6 Operations
> Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router
> 
the
> I think this choice should be left for homenet. e.g. there are
proposals for
> prefix assignment tightly coupled with a routing protocol.
> 
+1

Pascal

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 27 Jul 2011 20:41:22 +0200

for scalability problems ISPs don't usually exchange routes with CPE routers/residential customers.

Regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shishio Tsuchiya
Sent: mercoledì 27 luglio 2011 20.21
To: [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router

Mikael

Regards,
-Shishio
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 27 Jul 2011 14:53:54 -0400

> for scalability problems ISPs don't usually exchange routes with CPE routers/residential customers.

Nor would they in this case. In fact from a isp perspective you want the igp used in the home to be identifiable and easy to filter such that inadvertant leakage is effectively impossible. Although best practices for PE ports generally would be sufficient to preclude that, you also want to do one better.

joel

---

From: Shishio Tsuchiya <[email-masked]>
Date: Wed, 27 Jul 2011 14:57:27 -0400

Roberta
Yes,I agree.
This routing protocol purpose would be exchange of internal home network.

Regards,
-Shishio

---

From: [email-masked]
Date: Wed, 27 Jul 2011 15:35:44 -0400

> This routing protocol purpose would be exchange of internal home 
network.

Disagree. Cable ISPs use an IGP (usually RIP) to exchange (a) route(s) 
with residential or SMB routers on the WAN interface. This provides a 
stable prefix to the CPE even in the case of topology changes (happening 
quite frequently in cable networks). 

If the LAN IGP chosen in homenet is different than the one required by 
ISPs on the WAN side, home routing equipement vendors may not be able to 
support both at the same time because of resources constraints. 

/JF

---

From: Don Sturek <[email-masked]>
Date: Wed, 27 Jul 2011 12:39:48 -0700

Hi Joel (and Roberta),

Correct, the routing protocol is to support multiple CPE in the home each
of which is connected to a separate WAN with different global prefixes.

The use case (and one actively being worked on with deployment next year)
is:
1)  Customer has a CPE router connected to broadband service
2)  Smart meter is installed with a different global prefix supplied by
the energy service provider.  Devices on the subnet for the CPE router in
(1) want to deploy energy applications that connect to the smart meter.

The issue is that around 17M smart meters have been deployed with IEEE
802.15.4.  This MAC/PHY offers a 127 byte frame so you need 6LoWPAN and a
mesh routing protocol like ROLL RPL (in the case used by ZigBee IP).  This
subnet cannot be bridged with subnets typically deployed with broadband
service (hence the need in an intra-home routing protocol).

Note that neither of the service providers in (1) or (2) need to do
anything special routing wise with the CPE routing protocol in the home.

Don

On 7/27/11 11:53 AM, "Joel Jaeggli" <[email-masked]> wrote:

>Nor would they in this case. In fact from a isp perspective you want the
>igp used in the home to be identifiable and easy to filter such that
>inadvertant leakage is effectively impossible. Although best practices
>for PE ports generally would be sufficient to preclude that, you also
>want to do one better.
>
>joel
>
>> Regards,
>> Roberta
>> 
>>Of Shishio Tsuchiya
>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
>>persone indicate. La diffusione, copia o qualsiasi altra azione
>>derivante dalla conoscenza di queste informazioni sono rigorosamente
>>vietate. Qualora abbiate ricevuto questo documento per errore siete
>>cortesemente pregati di darne immediata comunicazione al mittente e di
>>provvedere alla sua distruzione, Grazie.
>> 
>> This e-mail and any attachments is confidential and may contain
>>privileged information intended for the addressee(s) only.
>>Dissemination, copying, printing or use by anybody else is unauthorised.
>>If you are not the intended recipient, please delete this message and
>>any attachments and advise the sender by return e-mail, Thanks.
>>

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 27 Jul 2011 21:47:57 +0200

Hi Don,
   In your environment you have a routing protocol running in the home network for the reasons you explained, but my understanding is that you don't have a routing protocol on the WAN link between the CPE and the Service provider's network; is it correct?
Thanks,
Regards,
Roberta

-----Original Message-----
From: Don Sturek [mailto:[email-masked]]
Sent: mercoledì 27 luglio 2011 21.40
To: Joel Jaeggli; Maglione Roberta
Cc: [email-masked]
Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router

Hi Joel (and Roberta),

Don

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 27 Jul 2011 14:50:31 -0500

From: Lorenzo Colitti [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 1:26 PM
To: Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router

>Can such a default be extensible to exchange different types of
information than just reachability? For example, can it propagate
information such as "this is a guest network and this is an internal
network" or "this is a prefix that I have tentatively >assigned but do
not own yet"? If not, then perhaps something more flexible like IS-IS
would be better.

Not possible because the proposal is not workable.   Someone brought up
using OSPFv3 for use in prefix delegation in the home LAN to our IETF
CPE router design team.  See the questions I asked followed by the
person's reply and my responses back to show no routing protocol can be
used to delegate prefixes in the LAN.  

I asked, HS: How do you know OSPF has converged before responding to
DHCPv6 PD requests?

Reply: The CE router SHOULD wait until two sequential link-state
advertisements have no link state  changes before delegating any
prefixes.  This allows time for OSPF to converge, and for the  router to
build a topology map.

Seeing the above reply, I made my comment:

HS: Still does not work.  After OSPF converges, what happens if the user
changes the network such  as unplugging a router and moving the router?

Reply: The router has a link state table-when it changes, you go through
discovery again and issue a  Reconfigure where appropriate.  

HS:  There is a network bridge between two routers and the bridge does
not have any means to report link-up  or down.  Further, what if a
network interface of a router is flapping all the time and thus  basing
any algorithm on OSPF convergence breaks down.  The flapping interface
problem becomes  worse if one has a cyclic network.  Your proposal still
does not work.  

Hemant

---

From: Don Sturek <[email-masked]>
Date: Wed, 27 Jul 2011 12:54:34 -0700

Hi Roberta,

I don't think any special routing protocol is needed on the WAN link.

The main problem we see is routing between subnets in the home.

As Ole pointed out, there are probably some defensive best practices
needed to ensure these routing protocols don't transmit onto the WAN.....

Don

On 7/27/11 12:47 PM, "Maglione Roberta"
<[email-masked]> wrote:

>Hi Don,
>   In your environment you have a routing protocol running in the home
>network for the reasons you explained, but my understanding is that you
>don't have a routing protocol on the WAN link between the CPE and the
>Service provider's network; is it correct?
>Thanks,
>Regards,
>Roberta
>
>persone indicate. La diffusione, copia o qualsiasi altra azione derivante
>dalla conoscenza di queste informazioni sono rigorosamente vietate.
>Qualora abbiate ricevuto questo documento per errore siete cortesemente
>pregati di darne immediata comunicazione al mittente e di provvedere alla
>sua distruzione, Grazie.
>
>privileged information intended for the addressee(s) only. Dissemination,
>copying, printing or use by anybody else is unauthorised. If you are not
>the intended recipient, please delete this message and any attachments
>and advise the sender by return e-mail, Thanks.
>

---

From: Philip Homburg <[email-masked]>
Date: Wed, 27 Jul 2011 22:15:54 +0200

In your letter dated Wed, 27 Jul 2011 14:50:31 -0500 you wrote:
>=20
>used to delegate prefixes in the LAN. =20

Assuming a relatively small home network:

Why not use PD just to assign unique network numbers to networks and let 
the routing protocol figure out how to get packets from one net to another?

I.e. the WAN router hands out /64s from a /48 or /56 to whatever router want
one and interior routers work as DHCP relay agents for routers further removed
from the WAN router.

If the topology is tree, every link gets at most one prefix. If not, there
maybe a need for a protocol to figure out which one to use.

---

From: Shishio Tsuchiya <[email-masked]>
Date: Wed, 27 Jul 2011 17:14:45 -0400

JF
I see.I agree your opinion,in your environment.
Our home gateway guideline not included cable eRouters and well-managed CPE as  scope.
We need define scope of discussion on homenet.

Regards,
-Shishio

[email-masked] wrote:
> Disagree. Cable ISPs use an IGP (usually RIP) to exchange (a) route(s) with residential or SMB routers on the WAN interface. This provides a stable prefix to the CPE even in the case of topology changes (happening quite frequently in cable networks).
> 
> If the LAN IGP chosen in homenet is different than the one required by ISPs on the WAN side, home routing equipement vendors may not be able to support both at the same time because of resources constraints.
> 
> /JF

---

From: Ole Troan <[email-masked]>
Date: Wed, 27 Jul 2011 18:35:56 -0400

Hemant,

> Not possible because the proposal is not workable.   Someone brought up using OSPFv3 for use in prefix delegation in the home LAN to our IETF CPE router design team.  See the questions I asked followed by the person’s reply and my responses back to show no routing protocol can be used to delegate prefixes in the LAN.

https://datatracker.ietf.org/doc/draft-dimitri-zospf/

this belongs in homenet.

cheers,
Ole

---

From: [email-masked]
Date: Wed, 27 Jul 2011 19:21:50 -0400

> We need define scope of discussion on homenet.

Understood. However not all SMB routers are eRouters. Most of them are 
actually 
off-the-shelf devices, often considered as "home" routers. 

In this regard, the choice of a homenet IGP has an impact on the WAN side, 
because 
most implementors will not want to support two IGPs. The position I wanted 
to express 
here is the same than yours, that RIPng seems a better and simpler choice. 

But as Ole suggested, let's move this thread in homenet, it doesn't belong 
in v6ops. 

/JF

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 28 Jul 2011 11:09:24 -0400

Correct, default route is the operative thing on the outside.

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 28 Jul 2011 11:18:59 -0400

> So we thought RIPng would be acceptable routing protocol for IPv6 CPE router,also.

So, if one is working with requirements rather than working backwards from a selected protocol one would suppose that some of the requirements might look something like:

* can be used with acceptable defaults (e.g. no configuration)
* has sensive safeguards to prevent interaction with isp IGP.
* can distinguish between the desirability of a path on the basis of something other than hop count. e.g. just because I happen to have connected an 802.5.14 network to two largely ethernet devices doesn't mean traffic to other parts of the network should traverse the former when it happens to be the best path.

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 28 Jul 2011 11:42:13 -0400

On Jul 27, 2011, at 1:25 PM, Lorenzo Colitti wrote:

> On Wed, Jul 27, 2011 at 12:28, Hemant Singh (shemant) <[email-masked]> wrote:
> Can such a default be extensible to exchange different types of information than just reachability? For example, can it propagate information such as "this is a guest network and this is an internal network" or "this is a prefix that I have tentatively assigned but do not own yet"? If not, then perhaps something more flexible like IS-IS would be better.

If the routing protocol were not dependent on the ip layer having already been bootstrapped that might the ease the complexity and depedancy graph during setup...

---

From: Don Sturek <[email-masked]>
Date: Thu, 28 Jul 2011 08:53:04 -0700

Hi Joel,

I think the third point on desirability of a path is key.  The routing
protocol should avoid constrained paths like 802.15.4 mesh networks in
favor of longer routes through technologies like Wi-Fi or Ethernet.  We
need to define appropriate routing metrics to make this happen.

Also, new subnets will be added by the homeowner in an ad hoc fashion and
new path characteristics must be determined automatically and factored
into new routing paths.

The idea would be to use some off the shelf existing routing protocol as
is and maybe work on some intelligence on path cost (this topic might be
an interesting one for Homenet).

Don

On 7/28/11 8:18 AM, "Joel Jaeggli" <[email-masked]> wrote:

>So, if one is working with requirements rather than working backwards
>from a selected protocol one would suppose that some of the requirements
>might look something like:
>
>* can distinguish between the desirability of a path on the basis of
>something other than hop count. e.g. just because I happen to have
>connected an 802.5.14 network to two largely ethernet devices doesn't
>mean traffic to other parts of the network should traverse the former
>when it happens to be the best path.
>
>> Regards,
>> -Shishio

---

From: Shishio Tsuchiya <[email-masked]>
Date: Thu, 28 Jul 2011 14:54:44 -0400

Just for your information,
We considered about routing protocol on LAN and WAN.
http://www.v6pc.jp/pdf/v6hgw_Guideline_1_0-English.pdf
I listed our consensus in below 
-Routing Control on WAN-side
1.Static route  
2.Automatic Configuration of Default Route Using RA 
Both requirement as mandatory[MUST].

-Route Control to LAN-side
1.RIPng [RFC 2080]
2.More-Specific Route [RFC 4191]
Both requirement as Optional[May].

We thought this is typical case for our countries.
Of course,we are watching ietf homenet discussion.
If the requirement would be acceptable in our environment too,we will modify our guideline.

Regards,
-Shishio

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Jul 2011 17:18:02 -0400

On Thu, Jul 28, 2011 at 11:18, Joel Jaeggli <[email-masked]> wrote:

> So, if one is working with requirements rather than working backwards from
> a selected protocol one would suppose that some of the requirements might
> look something like:
>
> something other than hop count. e.g. just because I happen to have connected
> an 802.5.14 network to two largely ethernet devices doesn't mean traffic to
> other parts of the network should traverse the former when it happens to be
> the best path.

I would add:

* can distribute information beyond IP reachability; for example, "this
prefix belongs to a guest network" or "this is a prefix that I have
tentatively assigned to my interface, not a prefix that is already in use".
This would be useful for autoconfiguration.

It might also be good if the protocol supported authentication so that
unrelated devices could not join the network.

Personally, I think preventing interaction with the ISP's IGP is the ISP's
business, not the device's. An ISP that listens to routing protocol
advertisements from home users with no prior agreement with them deserves
what it gets. That said, you could use different authentication keys to
prevent interaction, even if the protocol is the same. Others have asked to
use a different protocol because some implementations can't run, e.g.,
multiple OSPF processes or multiple IS-IS processes, but it doesn't seem
that this is an unsolvable technical problem.

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 30 Jul 2011 04:33:42 +0000

Why would it have to if the guest network or other LAN side network is
simply a subset of a larger allocated prefix?

On 7/28/11 11:42 AM, "Joel Jaeggli" <[email-masked]> wrote:

>network" or "this is a prefix that I have tentatively assigned but do not
>own yet"? If not, then perhaps something more flexible like IS-IS would
>be better.
>
>
>
>
>If the routing protocol were not dependent on the ip layer having already
>been bootstrapped that might the ease the complexity and depedancy graph
>during setup...

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 30 Jul 2011 04:34:43 +0000

On 7/28/11 5:18 PM, "Lorenzo Colitti" <[email-masked]> wrote:

>tentatively assigned to my interface, not a prefix that is already in
>use". This would be useful for autoconfiguration.
[jjmb] as I emailed before why would this be required of the LAN side
network is part of an already delegated prefix?  Am I missing something?
>unrelated devices could not join the network.
[jjmb] not sure this is a might, if this were to be used authentication
would be required.
>
>Personally, I think preventing interaction with the ISP's IGP is the
>ISP's business, not the device's. An ISP that listens to routing protocol
>prevent interaction, even if the protocol is the same. Others have asked
>to use a different protocol because some implementations can't run, e.g.,
[jjmb] agreed.  It seems to me that specifying the use of an IGP like OSPF
or ISIS is overkill for a home scenario.  For a business or SOHO perhaps
this would be ok, not to reiterate what others have said about resource
constraints and complexity of setup for some types of users.

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 30 Jul 2011 04:33:44 +0000

These seem like reasonable, basic recommendations.

=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

---

From: Ole Troan <[email-masked]>
Date: Sat, 30 Jul 2011 08:35:11 -0400

John,

> constraints and complexity of setup for some types of users.

two ideas in prefix assignment space:
 - use zOSPF (border routers advertise a site prefix in a new LSA, internal routers randomly pick a subnet id and does
              collision detection for each of their links)
 - use a DHCP "God server" with SPF topology. each internal router requests a /64 for its downstream links, as the DHCP server is
             part of the topology, it can make sure that each link only gets a single prefix even if multiple routers are connected to
             it.

both ideas require something different than RIP.
let's give homenet a little time to figure out what they like to do before making a decision.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 30 Jul 2011 14:41:41 -0400

> network is part of an already delegated prefix?  Am I missing something?

In a routed home network, you want guest networks and non-guest networks to
be routed, but not talk to each other. Carrying in the IGP the information
about whether each /64 assigned to an interface is for a guest network or a
non-guest network allows the routers to apply the appropriate firewalls
between the guest network and the non-guest network, while still routing
both guest and non-guest prefixes. It's a bit like having two VRFs or an
MPLS VPN.

As regards the "tentative" tag, that might be useful when doing
autoconfiguration. As Ole says, a CE could pick one random /64 out of the
aggregate for each of its interfaces and do collision detection to see if
it's unique. If the IGP carries a flag saying "this prefix is tentative"
that might make it easier.

Of course, these are just examples of why a protocol that can carry
additional information beyond just "this prefix lives here with this metric"
can be useful: it allows the network to do stuff that we haven't thought of
yet.

Cheers,
Lorenzo

---

From: Erik Kline <[email-masked]>
Date: Sun, 31 Jul 2011 08:39:29 +0000

> can be useful: it allows the network to do stuff that we haven't thought of

Like advertise future standardized "this *service* is reachable via
this path" sorts of things.  The routing protocol could aid in service
discovery this way.

---

From: Satoru Matsushima <[email-masked]>
Date: Sun, 31 Jul 2011 18:08:26 +0900

> this path" sorts of things.  The routing protocol could aid in service

I think it would be a good point.
A crazy idea come up me like opaque-lsa for advertise beyond advertising just prefix, and a flavor of bgp community to import/export to manage connectivity among routing instances.

cheers,
--satoru

---

From: Erik Kline <[email-masked]>
Date: Sun, 31 Jul 2011 10:10:24 +0000

> A crazy idea come up me like opaque-lsa for advertise beyond advertising just prefix, and a flavor of bgp community to import/export to manage connectivity among routing instances.

Hehe.  On the plane ride back I was thinking of something like ES-IS
advertising service things to IS-IS routers, which could choose to
propagate them.

Of course, I also though to redo IS-IS without OSI numbering and just
use link-local addresses...somehow.

=)

---

From: "Brzozowski, John" <[email-masked]>
Date: Sun, 31 Jul 2011 14:38:05 +0000

On 7/30/11 8:35 AM, "Ole Troan" <[email-masked]> wrote:

> - use zOSPF (border routers advertise a site prefix in a new LSA,
>internal routers randomly pick a subnet id and does
[jjmb] advertisement to the ISP? Subnet-id selection is for IPv4 and IPv6?
 For IPv6 DHCPv6 could be used which would allow for collision avoidance,
this is in part similar to the below (I think).

> - use a DHCP "God server" with SPF topology. each internal router
>requests a /64 for its downstream links, as the DHCP server is
>             part of the topology, it can make sure that each link only
>gets a single prefix even if multiple routers are connected to
>             it.
[jjmb] this is something I have been thinking about as a viable option.
The outer most router supports DHCPv6 PD (LAN side).  It would have to be
seeded with adequate address space to serve up IA_PD (and possibly IA_NA)
for downstream routers.  Based on conversations to date I assume there
would be interest in downstream routers also support and being able to
delegate prefixes?
>both ideas require something different than RIP.
[jjmb] perhaps...I have to ponder this some more.  I believe one of our
goals (regardless of the WG venue) should be to simply how such
deployments work.

>before making a decision.
[jjmb] I would rather help HOMENET by participating/driving some of these
discussions.

---

From: "Brzozowski, John" <[email-masked]>
Date: Sun, 31 Jul 2011 14:45:30 +0000

On 7/30/11 2:41 PM, "Lorenzo Colitti" <[email-masked]> wrote:

>On Sat, Jul 30, 2011 at 00:34, Brzozowski, John
><[email-masked]> wrote:
>
>In a routed home network, you want guest networks and non-guest networks
>to be routed, but not talk to each other. Carrying in the IGP the
>information about whether each /64 assigned to an interface is for a
>guest network or a non-guest network allows the routers to apply the
>appropriate firewalls between the guest network and the non-guest
>network, while still routing both guest and non-guest prefixes. It's a
>bit like having two VRFs or an MPLS VPN.
[jjmb] an IGP is not required to prevent two LANs from interacting with
one another.  The vision I have for at least one scenario is a delegated
prefix of something shorter than 64 with /64 allocations to separate LANs,
some of which may communicate with others while others do not.  Requiring
advertising or requesting separate prefixes is not necessarily useful or
beneficial.
>that might make it easier.
[jjmb] Ok, we should vet this out some more.  The notion of "tentative"
could be useful for collision detection/avoidance.

>additional information beyond just "this prefix lives here with this
>metric" can be useful: it allows the network to do stuff that we haven't
>thought of yet.
[jjmb] while I do not disagree regarding future needs we need to make sure
folks who have yet to deploy IPv6 at all can do so starting with the basic
models allowing for evolution over time.