Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Fred Baker (fred)]

> On Aug 13, 2015, at 8:21 PM, Brian E Carpenter  
> wrote:
> 
> I think all we have to do is delete 'on-link' in the second paragraph.
> (The 'generally' in the first paragraph allows for the exceptional
> case that Mikael was concerned about, I think.)

I'll give people a couple of days to comment further, but that change is locked 
into the next version.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Fred Baker (fred)]

> On Aug 13, 2015, at 7:37 PM, Brian E Carpenter  
> wrote:
> 
> So I think the -01 draft is wrong, since it says "on-link."

What is says is

   A host receives prefixes in a Router Advertisement [RFC4861], which
   goes on to identify whether they are usable by SLAAC [RFC4862]
   [RFC4941] [RFC7217].  When no prefixes are usable for SLAAC, the
   Router Advertisement would normally signal the availability of DHCPv6
   [RFC3315] and the host would use it to configure its addresses.  In
   the latter case it will be generally the case that the configured
   addresses match one of the prefixes advertised in a Router
   Advertisement that are supposed to be on-link in that subnet.

   Since the host derives fundamental default routing information from
   the Route Advertisement, this implies that, in any network with hosts
   using multiple prefixes, each prefix SHOULD be advertised via on-link
   Prefix Information Options [RFC4861] by one of the attached routers,
   even if addresses are being assigned using DHCPv6.  A router that
   advertises a prefix indicates that it is able to appropriately route
   packets with source addresses within that prefix.

Tell me what to make it say.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Fred Baker (fred)]

> On Aug 12, 2015, at 5:44 AM, Juliusz Chroboczek 
>  wrote:
> 
> Ole, Mikael, could either of you please summarise the discussion you're
> having for us mere mortals?  I don't understand what problem you're trying
> to solve, and I don't understand why you're distinguishing between SLAAC
> and DHCPv6.

For the record, I'm having the same question. To my way of thinking, we have 
effectively two or more routing systems (able to get messages to each relevant 
upstream network, for reasons that might be physical or virtual in nature), and 
a single client (the host in question). The host chose a source address (RFC 
6724) and needs to hand a packet to the routing system using that address as a 
source.

We could involve the host in a full-blown routing implementation, trying to 
micro-optimize routes through the default-free zone from a host that probably 
has a grand total of two default routes in its route table, but haven't 
historically chosen to do that.

The fact that neither of us even understands the sentence says, to me, that 
there is a whole lot of complexity going on that probably isn't necessary...


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Fred Baker (fred)]

> On Aug 10, 2015, at 12:02 PM, Juliusz Chroboczek 
>  wrote:
> 
> I'm not sure if I read you right, but I assume you are concerned about
> what happens when a delegated prefix is retraceted.  (The ISP stops the
> delegation, or the DHCPv6-PD client decides to hide the prefix from the
> rest of the Homenet).  In that case, the DHCPv6-PD client refloods its set
> of delegated prefixes, which triggers the prefix assignment algorithm,
> which causes the APs in the retracted DP to be retracted.

OK, that should work.

The first issue stands.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Fred Baker (fred)]

https://tools.ietf.org/html/draft-baker-6man-multi-homed-host-00

Something that homenet, and specifically HNCP, might be interested to consider 
is the impact of egress/SADR routing as discussed in this draft on its 
recommendations. The draft is in WGLC and in need of a revised draft, so you 
may consider this a late comment or a WGLC comment as you please. Or, tell me 
that the person who raised the question to me is incorrect.

It has been pointed out to me that HNCP expects that every router in a homenet 
network will advertise every PA or PI prefix in use in the network. This 
creates two issues.

The recommended host behavior is to have a host that has an address in each of 
two or more prefixes (which, note, might be on the same interface or on 
different ones) is to have it originate traffic using a given source prefix to 
the router, or one of the routers, that advertised the prefix to it. In the 
simplest case, which would be to have one or more hosts on a LAN with two or 
more routers connected to as many upstream networks, would have the network 
avoid BCP 84 routing among the routers, but instead have a host present a 
packet to the router the packet needs to use.

A more general case is exemplified in my home office. Due to Cisco Information 
Security rules, my office is effectively part of and served by Cisco's 
corporate network, while my home is served by my ISP. There is physically one 
router, but it is configured in two slices, and packets don't travel between 
the slices. So conceptually - and there is no reason this couldn't be physical 
- there are two separate routers. If I turn on the WiFi interface on my laptop, 
I now have a Cisco address on the Ethernet port and an ISP address on the WiFi 
port. I can expect both Cisco and the ISP to implement BCP 38 (discarding 
traffic that has the wrong source address), and there is no mechanism or 
connectivity by which a packet with one of the two prefixes might be redirected 
(BCP 84) to the other router. I am absolutely dependent on my host guessing 
correctly - absent this rule. The first issue is that, absent this rule, we are 
absolutely dependent on Happy Eyeballs processing to even get a packet out of 
the door.

The second issue, and this one I'm unsure about but raise in case there is an 
issue, has to do with the process of removing a prefix from a network. It seems 
likely that we have a counterpart to RIP's count-to-infinity problem, except 
that there is no counter to rely on. If a router advertising a prefix into a 
network decides to withdraw it, the last router in the network that maintains 
knowledge of it has some possibility of re-infecting the network with it. I 
think you want the advertisement of a prefix in an RA to be tightly linked to 
its current allocation status and lifetime.

In any event, I would urge the HNCP design team to consider the cases, and 
either make an argument that making network routing more complex (BCP 84) has a 
benefit I'm missing and actually works without the rule, or change HNCP to not 
have each RA contain every possible prefix.

I'll draw a picture to help understand the case. There are two upstream ISPs, 
which I'll call ISP-Alice and ISP-Bob. In the home, there are two LANs, three 
routers (Alice, Bob, and Carol), two LANs, and two hosts (Spanky and Alfalfa):

   +---++--+
   |   ||  |
   |ISP-Alice  ||ISP-Bob   |
   |   ||  |
   |   ||  |
   +--+++-++
  |   |
   +--+--+  +-+-+
   |Alice|  |Bob|
   +--+--+  +-+-+
  |   |
   ++-+--+++
||
 +--+---+ +--+--+
 |Spanky| |Carol|
 +--+ +--+--+
 |
   +++-+
|
 +--++
 |Alfalfa|
 +---+

If every router is responsible to announce prefixes from ISP-Alice and ISP-Bob 
on every LAN, then Spanky has a distinct probability that, to get a packet to 
ISP-Alice, it will send it to ISP-Bob, who will then have to redirect it to 
ISP-Alice. If on that LAN, Alice advertises the ISp-Alice prefix and Bob 
advertises the ISP-Bob prefix, and Spanky presents the packet to the router 
that advertised its source prefix, Spanky will invariably present such a packet 
to Alice.

On the second LAN, Carol will of course have to announce both prefixes, and use 
SADR routing to get the packet to the right egress router. But Alfalfa doesn't 
need to know the details; he learned both prefixes from Carol and presents all 
packets to her.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo

[homenet] Fwd: I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Fred Baker (fred)]

This is actually being discussed in 6man, as the chairs requested it there, but 
homenet might have comments to pass along.

> Begin forwarded message:
> 
> From: 
> Subject: I-D Action: draft-baker-6man-multi-homed-host-00.txt
> Date: August 7, 2015 at 7:40:43 AM PDT
> To: 
> Reply-To: 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>   Title   : Host routing in a multi-prefix network
>   Authors : Fred Baker
> Brian Carpenter
>   Filename: draft-baker-6man-multi-homed-host-00.txt
>   Pages   : 6
>   Date: 2015-08-07
> 
> Abstract:
>  This note describes expected host behavior in a network that has more
>  than one prefix, each allocated by an upstream network that
>  implements BCP 38 filtering.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-baker-6man-multi-homed-host/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-baker-6man-multi-homed-host-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet requirements on ISPs -- should write them down?

[Fred Baker (fred)]

Concur. Even if it isn't discussed at a NG per se, NOGs should be polled for 
the discussion. Welcome in v6ops if there isn't a better place found.

> On May 15, 2015, at 11:53 AM, Lee Howard  wrote:
> 
> 
> 
> From: Mark Townsley mailto:m...@townsley.net>>
> Date: Thursday, May 7, 2015 at 9:39 AM
> To: Ray Bellis mailto:r...@bellis.me.uk>>
> Cc: "homenet@ietf.org "  >, "v6ops-cha...@tools.ietf.org 
> "  >
> Subject: Re: [homenet] homenet requirements on ISPs -- should write them down?
> 
>> 
>> 
>> On Tue, Apr 28, 2015 at 7:18 PM, Ray Bellis > > wrote:
>>> 
>>> 
>>> On 28/04/2015 02:02, Tim Chown wrote:
>>> 
>>> > Something for the chairs to consider. None of the above should
>>> > prevent existing work continuing, but it may be useful to document
>>> > common understanding of what we’re trying to achieve.
>>> 
>>> It sounds like a fine idea to me, but I shall need to discuss with my
>>> co-chair and AD when I get back to the UK next week, not least to
>>> confirm whether it's in charter (and if not, whether the charter could
>>> be updated to accommodate this).
>> 
>> Ray and I have met up since his return, but haven't had a chance to talk 
>> about this.
>> 
>> Let me ask: Would something like this fit better in v6ops?
> 
> 
> My attitude is to write the document and then find the home for it. Our ADs 
> won’t let good work go undone for bureaucratic reasons; if no group is 
> chartered to do it, they’ll recharter one. I’m fine with pointing v6ops at 
> such a document and inviting discussion there, too. If there’s interest, we 
> could put it on the agenda for a v6ops meeting.
> 
> On the other hand, it might be an even better discussion for a BCOP, 
> discussed at a NOG. Then you’ll get ISP input.
> 
> Lee
> 
>> 
>> - Mark
>> 
>>> 
>>> Ray
>>> 
>>> ___
>>> homenet mailing list
>>> homenet@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/homenet 
>>> 
>> 
>> ___ homenet mailing list 
>> homenet@ietf.org  
>> https://www.ietf.org/mailman/listinfo/homenet 
>> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Selecting a routing protocol for HOMENET

[Fred Baker (fred)]

My understanding, which could be wrong, is that the IESG has a long-standing 
policy that a routing protocol needs to have two interoperable implementations, 
written from the specification. It’s not about the SDO or the specification 
(IS-IS anyone?), it’s about having proof that the specification is in fact 
correct and implementable from, by having two or more parties do it.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Routing protocol comparison document

[Fred Baker (fred)]

It seems, in each case, that the word "RECOMMEND" is far superior to "MUST". If 
I connect two ports from the same router to the same LAN, I really don't 
normally want them in different subnets (although from a specific reason I 
might choose that). MIF tells us that we can enumerate members of the same 
subnet on different physical media in certain cases. While that is true, to my 
small mind it's not a great configuration from a routing perspective.

I would indeed RECOMMEND that different ports on the same router be, in the 
normal case, connected to different subnets, and I would RECOMMEND that a small 
simple network be kept as small and simple as meets the design requirements of 
its operator - which in a home network, is the occupants of the home. If the 
person is trying to (as I do) connect things that don't move, like TVs, using 
wired media and connect things that do move using wireless, or to route high 
volume data by different paths than occasional data flows, there exist 
requirements that probably don't belong in a document like this, but need to be 
configurable by a clueful operator.

I'd stick to RECOMMEND, and make it clear that the recommendation targets the 
general case.

From: homenet [homenet-boun...@ietf.org] on behalf of Joel M. Halpern 
[j...@joelhalpern.com]
Sent: Thursday, February 19, 2015 11:36 AM
To: Ted Lemon; Mikael Abrahamsson
Cc: homenet@ietf.org; Juliusz Chroboczek
Subject: Re: [homenet] Routing protocol comparison document

I would note that RFC 7368 says that "simple Layer 3 topologies
involving as few subnets as possible are preferred in home networks".  I
presume this is reflective of WG agreement.
While it does go on to note that multiple subnets are sometimes needed,
mandating that each physical port on the access router be a distinct
subnet (much less extending such a mandate further in the home) seems to
violate this agreement.

Yours,
Joel M. Halpern

On 2/19/15 1:11 PM, Ted Lemon wrote:
> On Feb 19, 2015, at 12:33 PM, Mikael Abrahamsson  wrote:
>> Sure, ISIS could be made smarter when it comes to this, but it all comes 
>> down to what the requirements are. Right now when we started to evaluate 
>> routing protocols, people started pitching USP for their perticular 
>> favorite, and we found out we weren't even on the same page when it comes to 
>> requirements, and even what a homenet looks like.
>
> I think it is you who are not on the same page, not the working group.   The 
> working group recently published a document describing our goals, RFC 7368.   
> Many of the points you have raised as supposed points of disagreement are 
> addressed in the document, although I will admit that it is not always 
> obvious that they have been addressed.   The case of routing over Wifi was 
> discussed at length; the text referring to it in the document is here:
>
> Due to the use of a variety of diverse underlying link technologies,
> path selection in a homenet may benefit from being more refined than
> minimising hop count.
>
> Regarding your criticism about people pitching their favorite routing 
> protocols, you seem to be doing precisely that, so the criticism seems a bit 
> unfair.   The responses you have been hearing seem like legitimate attempts 
> to address points you have raised on a technical level, not mere advocacy, 
> and it is unfortunate that you would suggest otherwise: I haven't actually 
> seen you raise any technical points in favor of IS-IS, which you seem to be 
> advocating.
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)

[Fred Baker (fred)]

On Oct 29, 2014, at 5:05 AM, Ray Hunter  wrote:

> 
> 
> Fred Baker (fred) wrote:
>> On Oct 28, 2014, at 11:28 PM, David Lamparter  wrote:
>> 
>>> What I'm personally wondering most in this regard is: to what extent
>>> will larger networks deploy multiple prefixes to the hosts?
>> 
>> Well, define “larger”. Any network that gets a PI prefix is unlikely to 
>> deploy multiple prefixes. The question is at what size network is makes 
>> sense to obtain an AS number and a PI prefix, and use BGP to talk with one’s 
>> upstream.
> 
> I don't agree with this statement for the following reasons.
> 
> Availability: There are many enterprises that have very numerous far-flung 
> sales-office type locations which do not host any critical data or 
> applications, but which could benefit from higher availability than that 
> provided by a single ISP provider (some of which are currently served by a 
> specialised box offering a Very Small Office Service running dual IPSec 
> tunnels to a central site, which then performs the break out to the corporate 
> intranet/Internet)
> 
> Latency: There are many sites which could benefit from local Internet 
> breakout to regional cloud services, where you don't want to suffer the 
> latency associated with a back haul from an office in Australia to a regional 
> hub in Hong Kong, or even East coast US to West coast US and back. You'd 
> still also want some back up via the central breakout if the local breakout 
> failed.
> 
> Cost: There are cost savings to be made in many countries where private 
> network services are still many orders of magnitude more expensive than plain 
> old Internet. So Internet offload for non-mission-critical traffic can be 
> very attractive. If you could achieve this via direct host-server connections 
> using address selection rules or multipath TCP; rather than via PBR, GRE 
> tunnels + NAT, that would be a lot simpler.

I have a hunch we’re talking past each other. We would agree, but we’re 
discussing different cases. I was discussing a case in which a company operates 
a single addressing plan. I think you’re discussing a company that operates 
multiple addressing plans, one for each of several locations.

Cisco might be an example of a “larger” company. We have an IPv6 /32, more 
locations than you can shake a stick at, and maybe 20 DMZs, places where our 
network interconnects with the Internet. I don’t know exactly what we advertise 
or where, but I could imagine that a few of our DMZs advertise the /32 and each 
of our DMZs advertises a /40, or something along that line. For us, PI is “duh, 
obvious”, and the only case in which we might - *might* - have a second prefix 
would be a ULA in a lab.

I suspect the company you are discussing might have a number of small offices 
in as many cities, and as many PA prefixes as it takes. The company might also 
have a PI prefix, but I would be surprised if it used the PI prefix in all of 
its little offices; if it did, it would essentially use it for internal 
traffic, and have some sort of VPN connecting the offices on which it was used. 
It would, however, use the PA prefixes from the offices when they need to talk 
outside the house. If it is using the PI prefix plus a PA prefix in any given 
office, it would depend on RFC 6724’s Rule 8 (longest match) to prefer a PI 
address when talking to another address within the prefix, and a temporary 
address from PA space otherwise.

In any event, in the context of my comment above, I am thinking of the many 
small offices as separate networks. They don’t justify their own PI spaces; the 
PI in context acts more like PA from the central corporation than PI in the 
traditional sense of the term. They might well get PA from one or more ISPs, 
and they might have something akin to PA from their central office or whatever.

Coming back to the question - “would they put multiple subnet prefixes on any 
given LAN” - the question really comes back to their requirements and stomach 
for complexity. If they require multihoming, such as Jim suggests, I would hope 
they would do that. Among my “NAT == Security” customers and SEs, getting them 
there requires their network to work well (egress routing being one of many 
important parts of that), and a good security solution that doesn’t involve 
NAT. Until they have one AND they are convinced, they tell us that the lack of 
a NAT solution is a reason to delay deployment. I don’t think that last is 
about the number of prefixes around; it’s about security policy and mindset.

>>  Wherever that boundary is, below that networks will use PA prefixes. The 
>> question then becomes: will they multi home?
>> 
>> And I think the answer today is that we don’t know the answer.
> 
> This I agree with.
> 
> 
> -- 
> Re

Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)

[Fred Baker (fred)]

On Oct 28, 2014, at 11:28 PM, David Lamparter  wrote:

> What I'm personally wondering most in this regard is: to what extent
> will larger networks deploy multiple prefixes to the hosts?

Well, define “larger”. Any network that gets a PI prefix is unlikely to deploy 
multiple prefixes. The question is at what size network is makes sense to 
obtain an AS number and a PI prefix, and use BGP to talk with one’s upstream. 
Wherever that boundary is, below that networks will use PA prefixes. The 
question then becomes: will they multi home?

And I think the answer today is that we don’t know the answer.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)

[Fred Baker (fred)]

On Oct 22, 2014, at 12:06 PM, David Lamparter  wrote:

> On Mon, Oct 20, 2014 at 10:40:33PM +0200, David Lamparter wrote:
>> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-routing-extra-qualifiers/?include_text=1
>> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-dst-src-routing/?include_text=1

Speaking strictly for myself, I’m not sure why homenet is relevant. The 
technology is related to networks that have different routing depend on on 
one’s use case. A class of solutions for it has been called the “fish” problem, 
and built using multi-topology routing. In homenet, it’s called SADR, and is 
primarily about egress routing (routing to an egress to an upstream ISP that 
gave you a PA prefix). While one doesn’t really want to confuse theory with 
practice, in theory it could be used between points of a network, to prevent 
folks using one set of prefixes to talk with another set, or to force routing 
of some sessions in some ways.

Personally, those are a class of problems I associate with campus networks more 
than residential networks.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Examples of ambiguous routes

[Fred Baker (fred)]

I looked at draft-baker-rtgwg-src-dst-routing-use-cases for the text I 
mentioned, and you are correct: it's not there.

It is in:

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing-03#section-2.2

and its is-is counterpart. I'll copy that example into the use case draft.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Tsinghua work on source/destination routing

[Fred Baker (fred)]

I'd like to draw your attention to a talk that will be given this morning in 
homenet. The context is:

http://datatracker.ietf.org/doc/draft-baker-rtgwg-src-dst-routing-use-cases
http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases
  "Requirements and Use Cases for Source/Destination Routing", Fred Baker,
  2013-08-13

http://datatracker.ietf.org/doc/draft-xu-homenet-traffic-class
http://tools.ietf.org/html/draft-xu-homenet-traffic-class
  "Traffic Class Routing Protocol in Home Networks", Mingwei Xu, Shu Yang,
  Jianping Wu, Fred Baker, 2013-10-21

http://datatracker.ietf.org/doc/draft-xu-homenet-twod-ip-routing
http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing
  "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu
  Yang, Jianping Wu, Dan Wang, 2013-08-22

http://datatracker.ietf.org/doc/draft-baker-ipv6-ospf-dst-src-routing
http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
  "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2013-08-28

http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend
http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend
  "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fred
  Baker, 2013-10-15

I had breakfast this morning with Shu Yang, who has been writing Quagga code 
for several years in the course of his PHd. He first implemented a 
source/destination model, reported on in draft-xu-homenet-twod-ip-routing, 
which was an MTR scheme. He tells me he found that very complex. He also 
listened to my talk in homenet around draft-baker-fun-routing-class, and has 
now implemented (if I understand him correctly) 
draft-ietf-ospf-ospfv3-lsa-extend and draft-baker-ipv6-ospf-dst-src-routing. 
The FIB implementation has a limitation: the source prefixes must be disjoint. 
However, given that, he has two FIB implementations, one of which has separate 
FIBs for each source prefix in play including ::/0 (so if there are M prefixes 
in the network, M+1 FIBs), and one of which is a single hierarchical M-Trie 
that looks up the destination and then the source. He has tested the code in 
simulation; the next step is testing in live networks.

Examples of use cases are generally around multi-prefix campus networks. There 
is a security use case that could be of value; at IETF 87, George Michaelson of 
APNIC reported on ULAs seen in his darknet. The short report is that he sees a 
fair bit of traffic with a ULA source address on the backbone. An interesting 
potential use of source/destination routing would counter that, and perhaps 
mitigate the need for ISP BCP 38 if generally deployed; in a case where a 
network is using a ULA and a global prefix (e.g., is not multihomed but has two 
prefixes, one of which is intended to only be used within its network), the 
default route to the network egress would use the global prefix as a source, 
and as a result traffic sent outside the network with a ULA source prefix would 
in effect have no route. The network could literally only emit traffic from its 
correct prefix.

I think this is relevant to the discussion of 
draft-baker-rtgwg-src-dst-routing-use-cases
draft-ietf-ospf-ospfv3-lsa-extend
draft-baker-ipv6-ospf-dst-src-routing
draft-baker-ipv6-isis-dst-src-routing



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today

[Fred Baker (fred)]

Yes, pretty much. 

On Nov 5, 2013, at 6:39 AM, Acee Lindem  wrote:

> Hi Mark,
> I attended and the majority of the discussion centered on whether the
> problem could be solved with a simpler model such as a FIB per provider.
> Fred pointed out that this would not handle overlapping source subnets and
> the fact that it was possible to solve the general problem with a Patricia
> tree and the installation disambiguating routes. Alvaro also commented
> that there are use cases beyond homenet. As you'd expect, the next step
> was that there needs to be more discussion on the RTG WG list (copied).
> Thanks,
> Acee
> 
> On 11/4/13 11:05 PM, "Mark Townsley"  wrote:
> 
>> 
>> Was anyone on this list able to attend the rtgwg meeting today where Fred
>> presented draft-baker-rtgwg-src-dst-routing-use-cases-00? I missed it,
>> and would be interested in the reaction, feedback, or next steps (if any).
>> 
>> Thanks,
>> 
>> - Mark
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> 


The ignorance of how to use new knowledge stockpiles exponentially. 
   - Marshall McLuhan



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] automatic prefix management (OSPF or ISIS version)

[Fred Baker (fred)]

On Feb 25, 2013, at 6:56 PM, Mark Andrews  wrote:

> 
> In message <1d1732d1-ac03-450a-add2-611f2fb1c...@apple.com>, james woodyatt 
> wri
> tes:
>> p3. All this pain can be traded away for the reasonably well-understood pain 
>> of NAT66 and a single ULA prefix with a constant 16-bit subnet identifier spa
>> ce, where collisions will be rare and stateless prefix autoconfiguration will
>> settle quickly basically every time.  I personally don't think that's a good
>> trade, but if routed home networks are ever to become the normal setup, then
>> I'm very skeptical that my opinion will turn out to be the majority one.
> 
> NAT66 assumes a /48 or else you don't have enough bits to fix the checksums.

You really need to re-read the document. https://tools.ietf.org/html/rfc6296

First, the term "NAT66" refers to stateful Network *Address* Translation, which 
doesn't update checksums in the prefix at all - it is what we have done in 
IPv4/IPv4 NAT but done in IPv6/IPv6 junction points, which means replacing the 
address entirely. If you're talking about stateless prefix translation, which 
can update the checksum in the prefix, it's Network Prefix Translation, NPT66. 

The reason we changed the name was that we couldn't get people to distinguish 
between those two notions; one blocks traffic while the other does not, and 
there are other ramifications. We obviously still have not succeeded.

NPT66 is not limited to /48s. It can update the checksum in the EID if the 
prefix is longer.

And then there's ILNP, which doesn't update the checksum in the translator 
because it changed the end to end checksum algorithm (the definition of the 
pseudo-header).

> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] automatic prefix management (OSPF or ISIS version)

[Fred Baker (fred)]

On Feb 25, 2013, at 11:21 AM, james woodyatt  wrote:

> Basically, we've given up on stateless router autoconfiguration in HOMENET, 
> and we're forced into a stateful solution.  There are no good choices here, 
> and the worst case outcome is that we will force the widespread adoption of 
> NAT66 at HOMNET borders, precisely because it may turn out that subscribers 
> want stable subnet identifiers, and more of them than their service providers 
> are willing to provide at reasonable price.  This all happened before, and 
> we're not showing any signs of making sure it doesn't happen again.

Here I'm a little confused. Who is "we"? To my knowledge, homenet hasn't given 
up on automated subnet allocation. If homenet has, no problem, let the draft 
expire.

If the ISP wants to allocate specific /64s to a customer, that's actually OK. 
It requires some thought, however. We are going to have to send a DHCP-PD 
request from each router in the network to the ISP's DHCP-PD server, which will 
allocate some number of /64s to the requesting router. I don't know about your 
world; in my world, it's not unusual for routers to have more than two 
interfaces; in a home using wireless and wifi, one could imagine each router 
asking for two downstream subnets just for that in addition to an upstream 
interface. The router in my home, a Cisco 881W, could conceivably have five 
subnets on as many interfaces in addition to whatever is on the ISP-facing 
interface.

I could imagine this requiring some jiggling of the DHCP-PD spec. As I recall, 
it (RFC 3633 section 10) allocates a prefix with a length, and allocates from 
that prefix to a variety of its own interfaces and potentially others. A router 
asking for 5 /64s will in fact ask for, and receive, one /61. If we want it to 
literally ask for a list of /64s, I think we have to play with it a bit. I 
suppose the IA_PD could contain multiple of those options; maybe that's the 
work-around.

What would actually be topical and helpful would be specific comments on the 
draft in question. What that it says do you object to, and what do you wish it 
would say?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] automatic prefix management (OSPF or ISIS version)

[Fred Baker (fred)]

On Feb 22, 2013, at 1:11 PM, james woodyatt  wrote:

> On Feb 22, 2013, at 06:16 , Michael Richardson  wrote:
>> 
>> If the ISP with the longest prefix is alive first, then the routers 
>> pick subnet-id parts that fit into that.  If that ISP has provided
>> enough subnets, then even when another ISP comes along, the "xx23"
>> part might remain stable for a long time.
> 
> This problem is precisely why I campaigned bitterly and vigorously against 
> the adoption and V6OPS and later the publication of RFC 6177.
> 
> When there was still a consensus that subscribers should always get a /48 
> prefix, it was reasonable to expect that a randomly chosen 16-bit subnet 
> identifier would be unlikely to collide with another subnet in most 
> automatically numbered routing domains.  We were also in a position to expect 
> that when a subscriber adds a new prefix from the same or a different 
> provider, that all the subnet identifiers in use on one prefix could be 
> mapped 1:1 into the new prefix.  Now we have RFC 6177, which explodes all of 
> that, for basically no sensible reason that I can see, and we are all the 
> poorer for it.
> 
> Well done, V6OPS, well done.

Two thoughts.

One: the v6ops result reflects the operational result in the ARIN community: 
operators there would like to be able to allocate /56 prefixes to smaller 
customers and /48s to larger ones. If you want castigate someone, castigate 
them.

Two: If randomization within the home is the issue, I'm not sure the difference 
between a /48 and a /56 is all that significant. We're discussing the ability 
to pick a half dozen at best out of a much larger field, and arguing against 
operators that can't see a reason for anything shorter than a /64. You've heard 
me argue before that prefix length should be an attribute of the service one 
purchases, much as capacity is: in the home, I suspect that a /60 would suffice 
for the vast majority of purposes, and I can imagine companies that would not 
be happy with a /56 but might be happy with a /52. I don't see a technical 
argument that everyone has to have precisely a /48.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Egress Routing Discussion: Baker model

[Fred Baker (fred)]

inline 

On Feb 23, 2013, at 12:48 AM, David Lamparter 
 wrote:
> For both "simple" and "full-blown" OSPFv3 the following loop/interop
> mechnisms come to my mind:
> 
> 1. refusing adjacencies between SADR and non-SADR routers.
>   Easily implemented with a Hello bit, this is the crowbar solution.
>   Quite sufficient for homenet I guess, but probably less acceptable
>   for anything else.
> 
> 2. flagging SADR support in router LSAs/LSPs.
>   Provides enough information to avoid loops.  Three things can be done
>   with this information:
> 
> 2a. install null/reject routes for paths that cross non-SADR routers.
> Provides adequate failure semantics, instead of looping packets
> around we get an ICMP unreachable.  Easy to implement.
> Downside: if there really is a non-SADR router, "not working" is
> now a state that is part of the result set of the dynamic route
> calculations.  Users (and admins) probably do not expect this.
> 
> 2b. calculate SPF around non-SADR routers
> Gets us a working network, but at a cost: there may now be 2
> different paths to reach some faraway router, one for SADR-routed
> packets and a different one for non-SADR packets.  Depending on how
> the router performs its SPF calculations, this can be hard to
> implement correctly - it's essentially a very narrowly and exactly
> specified case of multitopology routing.
> 
> 2c. on encountering non-SADR routers, figure whether they'll do the
> right thing with the packet.
> ... complicated and of questionable use IMHO.  Just listing this
> for completeness.
> 
> 2a and 2b can be mixed with each other; packets will get passed along by
> 2a-type routers until they get discarded at a 2b-type router.
> 
> My personal opinion at this point is that 2a and 2b should both be
> specified, with a requirement to indicate support level in the router
> documentation.  We're unlikely to encounter normal OSPFv3 speakers in a
> plain "production/final" homenet, so they could take the easy way.  If
> this gets implemented on routers for enterprise use, I'd expect 2b
> behaviour.


So you want the non-SADR routers to implement a null route, and the SADR 
routers to route around the non-SADR routers.

I'm scratching my head on how the un-updated routers would know to install a 
null route if they don't understand the information. 

I do think it would be straightforward to add a flag to the Hello indicating 
that they understand such updates, and refusing to neighbor with a router that 
doesn't. We have done that for other features. That does mean that adding a 
router to an area that understands the updates forces an update to all of the 
routers in an area, which could be a pain when upgrading. 

Setting a flag in the Router LSA indicating willingness to handle these routes 
is possible, but takes us in the direction of topological routing. My problem 
with approaching it as a topology is the implied management overhead; we need 
to know whether to include any given router or link in a given topology, and 
where we might have advertised topology-specific metrics in RFC 4915, we now 
want to infer that from a capability flag. ick. 


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] automatic prefix management (OSPF or ISIS version)

[Fred Baker (fred)]

On Feb 23, 2013, at 3:18 AM, Michael Richardson 
 wrote:

> Can you elaborate the scenario where a subnet-id renumbering would be 
> desireable, and would we want to actually signal this situation explicitly?

There is a BAA (a request for a research proposal) from the US Air Force for a 
technology or methodology that would enable a network to "morph under attack." 
A presumably-related question came to me a couple of years ago from a 
researcher at Johns Hopkins APL; she wondered whether it would be possible for 
a network to blunt a DDOS attack without betraying the information that the 
attack had been detected.

One way that *could* work would be to have the network periodically renumber. 
Imagine the network as a whole, or individual LANs from time to time, adding a 
prefix, making the old one "not preferred", and then removing the old one a few 
minutes later. The network endures the attack for a little while and then - not 
because it has detected an attack, but because it would do so anyway - 
side-steps it in routing.

I'm imagining the operators in the room giggling to themselves at this point, 
or tearing their hair before running screaming from the "room". One would not 
want to have to debug anything in such a network.

But that's what I'm referring to. I can imagine a network that, by policy, 
actively wants the algorithm to choose a new number.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] automatic prefix management (OSPF or ISIS version)

[Fred Baker (fred)]

On Feb 23, 2013, at 3:16 AM, Michael Richardson 
 wrote:

> 
>> "Lorenzo" == Lorenzo Colitti  writes:
>>> I.e. the "0123" is identical for the two prefixes?
>>> 
> 
>Lorenzo> In the general case where the prefixes assigned by the
>Lorenzo> operators are of different lengths, it cannot be. Right?
> 
> True.
> 
> If the ISP with the longest prefix is alive first, then the routers 
> pick subnet-id parts that fit into that.  If that ISP has provided
> enough subnets, then even when another ISP comes along, the "xx23"
> part might remain stable for a long time.
> 
> I think this is a human friendly feature that none of our protocols
> should depend upon, but that nothing should forbid.  Do you agree?
> 
> -- 
> Michael Richardson , Sandelman Software Works 


I think we have violent agreement here. The text we're discussing is

  
Each router advertising a Reachability TLV
, including a pseudonode on a LAN, when it receives the
Autoconfiguration TLV Advertisement, calculates and announces a more
specific prefix from the advertised autoconfiguration prefix in a
Reachability TLV. This prefix is chosen at random, but may not collide
with any prefix currently advertised within the network and therefore
in the LSP database.

If you would like I can change

This prefix is chosen at random, but may not collide with any prefix currently 
advertised within the network and therefore in the LSP database.

to read

In the absence of other considerations, this prefix is chosen at random. It MAY 
be derived from previous prefix allocation decisions, such as a prefix stored 
in nonvolatile memory, the prefix used by a previous pseudonode on the same 
LAN, or the subnet part of another prefix on the same interface. In any event, 
it MUST NOT collide with any prefix currently advertised within the network and 
therefore in the LSP database.


BTW, a side-note on the issue of non-volatile memory. The OSPF autoconfig draft 
says that an allocated prefix MUST be stored in non-volatile memory and as a 
result survive a reboot. Speaking for myself, I don't see the need for that; 
I'm not opposed to someone doing it, but they now have to think about "what 
happens when" for various kinds of network changes. I think the principle might 
be one of "least surprise"; if a certain prefix is in use on a LAN and the DIS 
changes (perhaps the old one fails), the new DIS should use the same prefix as 
the old one, so that the hosts don't have to jump through hoops. That said, I 
don't see the argument around a whole-building power failure; unless there is a 
server being advertised in DNS, a randomly-selected new prefix will work just 
as well as the old one.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Egress Routing Discussion: Baker model

[Fred Baker (fred)]

On Feb 22, 2013, at 9:35 AM, Michael Richardson  wrote:

> Fred, I'm not sure that foo-chairs@  needs to be CC'ed on this
> discussion?  Having not been through your documents yet...

I wanted them to see that the discussion was happening. They have each asked me 
to take some time with their working groups. In one case, that will be amusing; 
I chair v6ops, and ospf and v6ops conflict. Yes, that's a great reason for 
having a co-chair.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] automatic prefix management (OSPF or ISIS version)

[Fred Baker (fred)]

On Feb 22, 2013, at 1:54 PM, Michael Richardson  wrote:

> For a network where there is more than one ISP, is it acceptable for a CPE 
> that has decided that it is PREFIX1:0123::/64, to "randomly" decide to be 
> PREFIX2:0123::/64?

I don't see why not, at least in the home.

There is a case, which homenet hasn't thought much about that I'm aware of, 
which is renumbering a network. You'll notice in my draft that if the 
autoconfig prefix is withdrawn, I expect prefixes dependent on it to be 
withdrawn, and if stored in permanent storage, erased. The implication is that 
if the same prefix is then readvertised, there's a good chance that all of the 
subnet numbers will change. I know of at least one scenario where that would be 
considered a desirable characteristic. But I don't think that case is, at least 
at this point, a general case or one I would specify beyond a "MAY".
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Egress Routing Discussion: Baker model

[Fred Baker (fred)]

On Feb 22, 2013, at 6:22 AM, Fred Baker  wrote:

> In Atlanta, Mark asked Lorenzo and I to put together a draft of an approach 
> to source/destination, and especially egress, routing. I pulled together a 
> plan of attack that I applied to both IPv4 and IPv6, and to both IS-IS and 
> OSPF and sought review from a limited list including Lorenzo; this includes 
> capabilities for at least one other use case I'm looking at. Mark asked me to 
> cut that down to make things separately implementable (which they would be 
> anyway, but to make it apparent). So I have broken it into components.
> 
> ..
> 
> I have documented my approach, which provides the generalized concept, is 
> built into the routing protocols IS-IS and OSPF, and also addresses at least 
> one other "tagged routing" option, which is to look at flow labels.
> 
> http://tools.ietf.org/html/draft-baker-ipv6-isis-automatic-prefix
>  "Automated prefix allocation in IS-IS", Fred Baker, 18-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing
>  "Using IS-IS with Role-Based Access Control", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing
>  "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing
>  "Using OSPFv3 with Role-Based Access Control", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
>  "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-ospf-extensible
>  "Extensible OSPF LSAs", Fred Baker, 17-Feb-13
> 
> I'll say why I think mine is the correct approach in another email, as I 
> imagine my colleagues will for theirs. But the working group should consider 
> the question.


This is that separate email. As I start, may I make the most direct possible 
apology to my colleagues with other approaches. I'm going to say that I think 
you're "wrong", and say why. That is in the spirit of open discussion in which 
we have a technical disagreement. BTW, you should be aware that I have a fair 
set of people who are telling me I'm wrong as well, hopefully in the same 
spirit. Some of them are pretty irritated with me, and I have gotten irritated 
with them.

Two parts of the question here relate to "what problem do we think we're 
solving" and "how do we model the network". A third will be "how do we 
implement it in a router?"

Homenet, I believe, thinks it's solving "how do I provide egress routing with 
zero, or perhaps epsilon, configuration, using open source code in the cheapest 
possible implementation." That's laudable; that said, I do believe that egress 
routing is a requirement for any IPv6 network involving multiple 
provider-allocated prefixes, and that as a result this is something to be built 
into the base protocol. In OSPF terminology, it is sufficient to build on an 
AS-external-LSA if that's the only source/destination route to be considered 
(it is certainly a principal use case); for a general network, however, we 
don't generally carry a lot of AS-external information around. So we need, I 
think, the ability to use native default routes as well as AS-external default 
routes, which means that we also need to look at the intra-area-prefix-LSA and 
the inter-area-prefix-LSA. The problem, I argue, is how to tag a route with a 
set of attributes and apply a route policy to it. One possible att
 ribute is the source prefix that might be used by systems communicating with 
this destination, and there are other possible attributes. The route policy is 
that traffic is forwarded to a stated destination if and only if it also 
matches the other specified attributes. So, when we want to source/destination 
route to a specified egress, the destination in question is a default route 
(::/0), the source is the relevant PA prefix, and we are asking the network to 
build routes in the way it natively does so for traffic that has the specified 
set of attributes.

As to "how we model it", there are at least two possible approaches. When Jon 
Moy was first building what we now call OSPF, one of the problems that the 
Internet was dealing with was congestive collapse. There were several 
experiments, one of which I was involved in with Neil Bierbaum of NASNET, in 
which we wanted to send interactive traffic using paths that had relatively low 
delay, and high volume file transfer traffic on other paths that had high 
throughput. It was not unusual for those "high throughput" paths to also have 
long delay, such as through a geosynchronous satellite. The technology for 
doing this was originally documented, at least publicly, in RFCs 1131 and 1247, 
commented on in RFC 1812, and has evolved to RFC 4915's Multi-topology Routing; 
it was developed in parallel in IS-IS as well. The multi-topology model is 
based on the premise that routers and/or links differ from each other i

[homenet] Egress Routing Discussion

[Fred Baker (fred)]

In Atlanta, Mark asked Lorenzo and I to put together a draft of an approach to 
source/destination, and especially egress, routing. I pulled together a plan of 
attack that I applied to both IPv4 and IPv6, and to both IS-IS and OSPF and 
sought review from a limited list including Lorenzo; this includes capabilities 
for at least one other use case I'm looking at. Mark asked me to cut that down 
to make things separately implementable (which they would be anyway, but to 
make it apparent). So I have broken it into components.

So we have several drafts in play at this IETF.

Shu Yang documented his work in Quagga, in which he implemented 
source/destination routing as a multi-topology routing model.

http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing
  "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu
  Yang, Jianping Wu, Dan Wang, 18-Feb-13

Ole Troan and Lorenzo Colitti documented their model, which is strictly egress 
routing based on the OSPF AS-prefix-LSA and the assumption of automated prefix 
allocation. This is not multi-topology; it in effect tags the default route 
advertised as a route from an alternate universe.

http://tools.ietf.org/html/draft-troan-homenet-sadr
  "IPv6 Multihoming with Source Address Dependent Routing (SADR)", Ole
  Troan, Lorenzo Colitti, 18-Feb-13

I have documented my approach, which provides the generalized concept, is built 
into the routing protocols IS-IS and OSPF, and also addresses at least one 
other "tagged routing" option, which is to look at flow labels.

http://tools.ietf.org/html/draft-baker-ipv6-isis-automatic-prefix
  "Automated prefix allocation in IS-IS", Fred Baker, 18-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing
  "Using IS-IS with Role-Based Access Control", Fred Baker, 17-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing
  "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 17-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing
  "Using OSPFv3 with Role-Based Access Control", Fred Baker, 17-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
  "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 17-Feb-13

http://tools.ietf.org/html/draft-baker-ipv6-ospf-extensible
  "Extensible OSPF LSAs", Fred Baker, 17-Feb-13

I'll say why I think mine is the correct approach in another email, as I 
imagine my colleagues will for theirs. But the working group should consider 
the question.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet