FUTURE HOMENET MEETS IEEE DRAFT 6
F
U
T
U
R
E
H
O
M
E
N
E
T
M
E
E
T
S
I
E
E
E
D
R
A
F
T
6
Jouni Korhonen, Philippe Klein
July 2014
I
E
T
F
H
o
m
e
n
e
t
W
G
w
o
r
k
s
a
n
a
s
e
t
o
f
s
o
l
u
t
i
o
n
s
t
o
e
n
a
b
l
e
“
n
e
x
t
g
e
n
e
r
a
t
i
o
n
”
I
P
v
6
h
o
m
e
n
e
t
w
o
r
k
i
n
g
e
n
v
i
r
o
n
m
e
n
t
,
w
h
e
r
e
m
u
l
t
i
p
l
e
r
o
u
t
e
r
s
a
n
d
d
e
v
i
c
e
s
c
a
n
b
e
p
l
u
g
g
e
d
t
o
g
e
t
h
e
r
i
n
a
n
a
d
-
h
o
c
m
a
n
n
e
r
b
y
h
o
p
e
l
e
s
s
l
y
n
o
n
-
t
e
c
h
n
i
c
a
l
p
e
o
p
l
e
.
E
n
t
i
r
e
l
y
a
L
a
y
e
r
3
o
n
l
y
,
I
P
c
e
n
t
r
i
c
,
s
o
l
u
t
i
o
n
–
i
t
i
s
a
s
s
u
m
e
d
L
a
y
e
r
2
j
u
s
t
w
o
r
k
s
.
.
(
*
)
H
o
m
e
n
e
t
m
u
s
t
s
u
p
p
o
r
t
:
Routing, Prefix configuration for routers, Name resolution, Service discovery,
and Network security.
A
r
c
h
i
t
e
c
t
u
r
e
a
n
d
r
e
q
u
i
r
e
m
e
n
t
s
a
r
e
d
o
c
u
m
e
n
t
e
d
:
draft-ietf-homenet-arch-17 (in IESG already..)
F
U
T
U
R
E
H
O
M
E
N
E
T
A
C
T
I
V
I
T
I
E
S
-
I
E
T
F
(*) not quite right in reality.. This is where TSN & IWK can give a hand and cooperation needed across layers.
S
o
l
u
t
i
o
n
s
M
U
S
T
w
o
r
k
w
i
t
h
I
P
v
6
,
a
n
d
I
P
v
4
s
u
p
p
o
r
t
i
s
a
b
o
n
u
s
.
.
M
u
s
t
s
u
p
p
o
r
t
m
u
l
t
i
p
l
e
r
o
u
t
e
r
s
a
n
d
a
r
b
i
t
r
a
r
y
t
o
p
o
l
o
g
i
e
s
w
i
t
h
a
n
y
n
u
m
b
e
r
o
f
s
u
b
n
e
t
s
/
p
r
e
f
i
x
e
s
/
l
i
n
k
s
.
S
u
p
p
o
r
t
f
o
r
m
u
l
t
i
p
l
e
I
S
P
s
a
n
d
/
o
r
m
u
l
t
i
p
l
e
C
P
E
s
.
P
l
u
g
’
n
’
p
l
a
y
a
u
t
o
/
z
e
r
o
c
o
n
f
;
e
.
g
.
l
o
o
p
s
m
u
s
t
n
o
t
c
o
n
f
u
s
e
t
h
e
s
y
s
t
e
m
.
A
d
e
q
u
a
t
e
d
e
f
a
u
l
t
s
e
c
u
r
i
t
y
;
f
r
o
m
o
u
t
s
i
d
e
t
h
e
n
e
t
w
o
r
k
a
n
d
w
i
t
h
i
n
t
h
e
n
e
t
w
o
r
k
.
P
o
s
s
i
b
i
l
i
t
y
t
o
i
s
o
l
a
t
e
p
a
r
t
s
o
f
t
h
e
n
e
t
w
o
r
k
e
.
g
.
f
o
r
o
w
n
,
v
i
s
i
t
o
r
,
u
t
i
l
i
t
y
,
I
o
T
a
n
d
3
r
d
p
a
r
t
y
m
a
n
a
g
e
d
n
e
t
w
o
r
k
s
e
g
m
e
n
t
s
.
G
O
A
L
S
A
N
D
P
R
I
N
C
I
P
L
E
S
A
R
C
H
I
T
E
C
T
U
R
E
E
X
A
M
P
L
E
.
.
N
e
t
w
o
r
k
s
e
g
m
e
n
t
e
d
f
o
r
d
i
f
f
e
r
e
n
t
u
s
e
s
Using L3 addressing
Each segment _may_ have further switched L2
L
3
r
o
u
t
i
n
g
e
s
s
e
n
t
i
a
l
t
o
m
a
k
e
t
h
e
h
o
m
e
n
e
t
t
o
p
o
l
o
g
y
t
o
w
o
r
k
.
.
CPE
I
S
P
D
H
C
P
v
6
-
P
D
-
>
TV etc
e.g. TV feed
H
o
m
e
A
u
t
o
m
a
t
i
o
n
R
e
m
o
t
e
m
a
n
a
g
e
d
u
t
i
l
i
t
i
e
s
/64
/64
/64
/64
/64
/64
Public
server
NAS
HNET
RTR
HNET
RTR
HNET
RTR
V
i
s
i
t
o
r
n
w
3
r
d
p
a
r
t
y
M
a
n
a
g
e
d
n
w
H
o
m
e
I
o
T
M
e
d
i
a
n
w
H
o
m
e
n
w
C
o
m
m
o
n
n
w
? (unintentinal loop)
S
o
u
r
c
e
a
d
d
r
e
s
s
s
e
l
e
c
t
i
o
n
b
e
c
o
m
e
s
e
s
s
e
n
t
i
a
l
IP packets with ISP#1 configured source address are not routable via
ISP#2 CPE (ingress filtering is common).
I
t
i
s
p
o
s
s
i
b
l
e
t
h
a
t
a
h
o
s
t
c
o
n
f
i
g
u
r
e
s
a
d
d
r
e
s
s
e
s
f
r
o
m
b
o
t
h
I
S
P
s
Would be “normal” with IPv6 when SLAAC is used..
A
R
C
H
I
T
E
C
T
U
R
E
E
X
A
M
P
L
E
–
T
W
O
I
S
P
ISP#1 CPE
ISP#2 CPE
I
S
P
#
1
I
S
P
#
2
I
n
t
e
r
n
a
l
n
e
t
w
o
r
k
HNET RTR
Host
Host
Host
Host
A
R
C
H
I
T
E
C
T
U
R
E
E
X
A
M
P
L
E
–
T
W
O
I
S
P
O
N
E
C
P
E
CPE
I
S
P
#
1
I
S
P
#
2
I
n
t
e
r
n
a
l
n
e
t
w
o
r
k
HNET RTR
Host
Host
Host
Host
S
o
u
r
c
e
a
d
d
r
e
s
s
s
e
l
e
c
t
i
o
n
“
c
o
m
p
l
e
x
i
t
y
”
i
n
a
d
i
f
f
e
r
e
n
t
f
o
r
m
IP packets with ISP#1 configured source address are not routable via ISP#2
CPE (ingress filtering is common).
End hosts see only one CPE and source for addressing.. However.. only
certain range of source addresses can be used to reach e.g. ISP#2 services..
“Content” services
accessible only via
ISP#2.. (TV etc..
CPE provides
“aggregate” of
configuration
information..
N
o
c
h
a
n
g
e
s
t
o
e
n
d
h
o
s
t
s
-
>
e
x
i
s
t
i
n
g
h
o
s
t
c
o
n
f
i
g
u
r
a
t
i
o
n
p
r
o
t
o
c
o
l
s
r
e
m
a
i
n
s
u
n
c
h
a
n
g
e
d
(
S
L
A
A
C
,
D
H
C
P
v
6
,
D
N
S
(
S
D
)
,
e
t
c
)
.
M
i
n
i
m
a
l
c
h
a
n
g
e
s
t
o
e
x
i
s
t
i
n
g
m
a
n
a
g
e
m
e
n
t
/
i
n
f
r
a
p
r
o
t
o
c
o
l
s
:
New protocols or extensions may be introduced if seen necessary.
O
n
t
h
e
t
a
b
l
e
:
S
o
u
r
c
e
A
d
d
r
e
s
s
D
e
p
e
n
d
e
n
t
R
o
u
t
i
n
g
,
P
r
e
f
i
x
C
o
l
o
r
i
n
g
&
A
s
s
i
g
n
m
e
n
t
a
n
d
B
o
u
n
d
a
r
y
D
e
t
e
c
t
i
o
n
e
t
c
.
N
o
r
e
q
u
i
r
e
m
e
n
t
f
o
r
a
“
h
o
m
e
n
e
t
w
i
d
e
”
r
o
u
t
i
n
g
p
r
o
t
o
c
o
l
:
Plug-ins for OSPFv3 do exist already to assist zeroconf..
R
o
u
t
e
r
s
s
y
n
c
h
r
o
n
i
z
e
s
t
a
t
e
a
c
r
o
s
s
h
o
m
e
n
e
t
w
o
r
k
u
s
i
n
g
t
h
e
u
s
i
n
g
t
h
e
H
o
m
e
n
e
t
w
o
r
k
i
n
g
C
o
n
t
r
o
l
P
r
o
t
o
c
o
l
(
H
N
C
P
)
i
n
o
r
d
e
r
t
o
f
a
c
i
l
i
t
a
t
e
a
u
t
o
m
a
t
e
d
c
o
n
f
i
g
u
r
a
t
i
o
n
a
n
d
u
s
e
o
f
r
o
u
t
i
n
g
p
r
o
t
o
c
o
l
s
w
i
t
h
o
u
t
h
o
m
e
n
e
t
s
p
e
c
i
f
i
c
e
x
t
e
n
s
i
o
n
:
Automated configuration requires support for host configuring & serving
“daemons” to be HNCP aware.
Must allow mixing “legacy” CPEs a’la RFC7084.
T
H
E
S
O
L
U
T
I
O
N
S
P
A
C
E
A
T
r
i
c
k
l
e
-
d
r
i
v
e
n
[
R
F
C
6
2
0
6
]
m
u
l
t
i
c
a
s
t
s
t
a
t
e
f
l
o
o
d
i
n
g
+
u
n
i
c
a
s
t
s
t
a
t
e
s
y
n
c
h
r
o
n
i
z
a
t
i
o
n
p
r
o
t
o
c
o
l
o
n
t
o
p
o
f
U
D
P
.
Link scope and IPv6 link-local addressing.
Trickle (per each link) makes sure the flooding is not too babbling and not
everybody floods at the same time.. Rapid propagation, low maintenance.
Protocol documented in [draft-ietf-homenet-hncp-01].
Download implementation:
https://github.com/sbyx/hnetd
C
o
n
f
i
g
u
r
a
t
i
o
n
i
n
f
o
r
m
a
t
i
o
n
(
e
.
g
.
o
r
i
g
i
n
a
l
l
y
r
e
c
e
i
v
e
d
b
y
t
h
e
C
P
E
f
a
c
i
n
g
I
S
P
n
e
t
w
o
r
k
v
i
a
D
H
C
P
v
6
-
P
D
,
e
t
c
.
.
.
)
d
i
s
t
r
i
b
u
t
e
d
t
o
h
o
m
e
n
e
t
a
w
a
r
e
r
o
u
t
e
r
s
.
.
T
H
E
H
O
M
E
N
E
T
W
O
R
K
I
N
G
C
O
N
T
R
O
L
P
R
O
T
O
C
O
L
MC=Multicast
UC=Unicast
S
t
a
t
e
(
i
.
e
.
d
a
t
a
b
a
s
e
)
s
y
n
c
h
r
o
n
i
z
a
t
i
o
n
b
e
t
w
e
e
n
r
o
u
t
e
r
s
link-local multicast transmission
unicast fallback for bulk synchronization
collision and conflict detection and resolving
P
r
e
f
i
x
d
i
s
t
r
i
b
u
t
i
o
n
a
n
d
a
l
l
o
c
a
t
i
o
n
IPv6 prefix delegation
IPv4 prefix allocation
R
o
u
t
i
n
g
s
e
t
u
p
Selection of a shared routing protocol
Fallback mechanism to setup routes autonomously
D
y
n
a
m
i
c
b
o
r
d
e
r
-
d
e
t
e
c
t
i
o
n
f
o
r
I
P
v
4
a
n
d
I
P
v
6
On-demand firewall reconfiguration
On-demand RA/DHCP/DHCPv6 server configuration
Integration of fixed external connections (e.g. PPP, 6rd, ...)
S
h
a
r
i
n
g
o
f
D
N
S
a
n
d
S
e
r
v
i
c
e
D
i
s
c
o
v
e
r
y
c
o
n
f
i
g
u
r
a
t
i
o
n
Local DNS configuration
mDNS / DNS-SD hybrid proxy configuration
H
N
C
P
F
E
A
T
U
R
E
S
–
M
O
R
E
D
E
T
A
I
L
E
D
R
U
N
D
O
W
N
F
l
e
x
i
b
l
e
T
L
V
-
o
n
l
y
m
e
s
s
a
g
e
s
t
r
u
c
t
u
r
e
.
E
a
c
h
r
o
u
t
e
r
h
a
s
:
An unique identity, for example, it may be a public key, unique hardware
ID, or some other unique blob of binary data.
A synchronized configuration data set (ordered set of TLVs), with:
Latest update sequence number.
Relative time, in milliseconds, since last publishing of the current TLV data set.
Hash over the set for fast comparison.
A public/private key-pair for authentication.
C
h
a
n
g
e
i
n
s
t
a
t
e
/
d
a
t
a
n
o
t
i
c
e
d
w
h
e
n
t
h
e
h
a
s
h
c
a
l
c
u
l
a
t
e
d
(
a
n
d
a
d
v
e
r
t
i
s
e
d
)
o
v
e
r
t
h
e
d
a
t
a
c
h
a
n
g
e
s
.
.
H
N
C
P
D
A
T
A
M
O
D
E
L
R
e
c
e
n
t
A
u
t
o
n
o
m
i
c
N
e
t
w
o
r
k
i
n
g
”
(
A
V
)
a
c
t
i
v
i
t
y
a
n
d
n
o
n
-
W
G
f
o
r
m
i
n
g
B
o
F
o
n
U
C
A
N
s
t
e
p
s
i
n
t
o
h
o
m
e
n
e
t
w
o
r
k
i
n
g
a
r
e
a
a
s
w
e
l
l
:
Aims at self-management, including self-configuration, self-optimization,
self-healing and self-protection of the network.
AN will need to discover information about the surrounding network and to
negotiate parameter settings with their neighbors and other nodes.
Possible a learning and cognitive capability, i.e. the ability for distributed
entities to self-adapt their decision making process based on information
and knowledge gained from their environment (sensing).
D
e
f
i
n
e
s
a
n
e
w
“
C
o
n
f
i
g
u
r
a
t
i
o
n
D
i
s
c
o
v
e
r
y
a
n
d
N
e
g
o
t
i
a
t
i
o
n
P
r
o
t
o
c
o
l
f
o
r
N
e
t
w
o
r
k
D
e
v
i
c
e
s
”
(
C
D
N
P
)
.
H
N
C
P
i
s
a
d
a
t
a
b
a
s
e
s
y
n
c
h
r
o
n
i
z
a
t
i
o
n
p
r
o
t
o
c
o
l
w
h
i
l
e
C
D
N
P
i
s
a
g
e
n
e
r
i
c
n
e
g
o
t
i
a
t
i
o
n
p
r
o
t
o
c
o
l
.
.
b
u
t
c
a
n
b
e
u
s
e
d
t
o
a
c
h
i
e
v
e
t
h
e
s
a
m
e
t
h
i
n
g
.
.
A
N
a
n
d
C
D
N
P
t
a
r
g
e
t
s
l
a
r
g
e
r
n
e
t
w
o
r
k
s
t
h
a
n
h
o
m
e
n
e
t
w
o
r
k
s
b
u
t
.
.
A
C
T
U
A
L
L
Y
T
H
E
R
E
I
S
M
O
R
E
I
N
T
H
E
P
I
P
E
.
.
I
n
c
e
r
t
a
i
n
d
e
p
l
o
y
m
e
n
t
s
,
l
i
k
e
,
h
o
m
e
n
e
t
w
o
r
k
i
n
g
e
n
v
i
r
o
n
m
e
n
t
:
L3 and L2 are developing their own.
T
h
e
r
e
s
h
o
u
l
d
b
e
a
s
t
a
n
d
a
r
d
w
a
y
t
o
m
a
k
e
t
h
e
s
e
t
w
o
l
a
y
e
r
s
t
o
c
o
m
m
u
n
i
c
a
t
e
;
f
o
r
e
x
a
m
p
l
e
:
When doing path computation and reservation over multiple L3 segments.
When segmenting the network for different purposes so that both layers
have the same view of the topology.
T
h
e
l
i
s
t
g
o
e
s
o
n
.
.
B
a
s
i
c
a
l
l
y
e
n
s
u
r
i
n
g
a
l
i
g
n
m
e
n
t
.
A
N
D
H
O
W
T
H
I
S
R
E
L
A
T
E
S
T
O
8
0
2
.
1
Q
C
A
E
T
A
L
.
.
?
A
R
C
H
I
T
E
C
T
U
R
E
C
O
N
S
I
D
E
R
A
T
I
O
N
S
F
O
R
.
1
Q
C
A
P
a
t
h
r
e
s
e
r
v
a
t
i
o
n
o
v
e
r
m
u
l
t
i
p
l
e
L
3
s
e
g
m
e
n
t
s
:
L2 may still have arbitrary non-loop-free cabling..
L2 area in a L3 segment may contain arbitrary switched topology..
L
2
u
s
i
n
g
I
S
-
I
S
S
P
B
,
w
h
e
r
e
a
s
L
3
c
a
n
b
e
e
.
g
.
I
S
-
I
S
,
O
S
P
F
v
3
o
r
n
o
t
h
i
n
g
.
.
N
e
e
d
f
o
r
a
L
3
t
o
L
2
c
o
m
m
u
n
i
c
a
t
i
o
n
f
o
r
p
a
t
h
r
e
s
e
r
v
a
t
i
o
n
a
n
d
c
o
o
r
d
i
n
a
t
e
d
n
e
t
w
o
r
k
s
e
g
m
e
n
t
a
t
i
o
n
?
CPE
I
S
P
D
H
C
P
v
6
-
P
D
-
>
TV etc
e.g. TV feed
H
o
m
e
A
u
t
o
m
a
t
i
o
n
R
e
m
o
t
e
m
a
n
a
g
e
d
u
t
i
l
i
t
i
e
s
/64
/64
/64
/64
/64
/64
Public
server
NAS
HNET
RTR
HNET
RTR
HNET
RTR
V
i
s
i
t
o
r
n
w
3
r
d
p
a
r
t
y
M
a
n
a
g
e
d
n
w
H
o
m
e
I
o
T
M
e
d
i
a
n
w
H
o
m
e
n
w
C
o
m
m
o
n
n
w
? (unintentional loop)
How does
.1Qca fit
here?
H
o
w
w
o
u
l
d
8
0
2
.
1
Q
c
a
w
i
t
h
P
C
E
–
P
E
a
r
c
h
i
t
e
c
t
u
r
e
f
i
t
h
e
r
e
.
.
Multiple PCEs and Pes. Also PCE to PCE communication..
See
ca-farkas-small-nets-0514-v02.pdf
A
R
C
H
I
T
E
C
T
U
R
E
C
O
N
S
I
D
E
R
A
T
I
O
N
S
F
O
R
.
1
Q
C
A
ISP#1 CPE
ISP#2 CPE
I
S
P
#
1
I
S
P
#
2
I
n
t
e
r
n
a
l
n
e
t
w
o
r
k
HNET RTR
Host
Host
Host
Host
PCE1
PCE2
PEs for
PCE1
PEs for
PCE2
.1Qca
(br to br)
.1Qca
PCE to PE
What if a host
belongs to two
CPEs? A PE belongs
still to one PCE..
L
2
p
r
o
t
o
c
o
l
s
e
x
p
o
r
t
s
s
e
r
v
i
c
e
p
o
i
n
t
s
t
o
t
h
e
L
3
p
r
o
t
o
c
o
l
s
t
o
a
l
l
o
w
t
h
e
s
e
p
r
o
t
o
c
o
l
s
t
o
b
e
d
e
t
e
r
m
i
n
i
s
t
i
c
w
h
i
l
e
n
e
t
w
o
r
k
a
g
n
o
s
t
i
c
.
O
k
.
.
T
h
e
a
r
c
h
i
t
e
c
t
u
r
e
a
p
p
l
i
e
s
t
o
l
a
r
g
e
r
o
r
s
m
a
l
l
e
r
s
c
a
l
e
n
e
t
w
o
r
k
s
t
h
a
n
a
h
o
m
e
n
e
t
w
o
r
k
;
i
t
j
u
s
t
s
e
r
v
e
s
a
g
o
o
d
s
t
a
r
t
i
n
g
p
o
i
n
t
.
.
A
R
C
H
I
T
E
C
T
U
R
E
P
R
O
P
O
S
A
L
F
O
R
M
I
N
G
.
.
PCE ”part of” the
router or CPE
PEs agnostic to the
multiple PCEs and
L3 segments
L3 PCE to PCE link
missing..? .1Qca or
something else..?
L3-L2 “PCE”
service point
missing..?
N
e
e
d
f
o
r
a
l
i
g
n
m
e
n
t
w
i
t
h
L
2
a
n
d
L
3
e
f
f
o
r
t
s
:
For example in home networking.
S
o
l
u
t
i
o
n
f
o
r
L
2
a
n
d
L
3
c
o
o
p
e
r
a
t
i
o
n
f
o
r
e
.
g
.
p
a
t
h
r
e
s
e
r
v
a
t
i
o
n
s
:
Expose required service points.
Agree on minimum set of required information elements passed between
functions and layers.
F
i
t
t
i
n
g
t
h
e
(
.
1
Q
c
a
)
P
C
E
–
P
E
m
o
d
e
l
w
i
t
h
L
3
d
e
v
e
l
o
p
m
e
n
t
s
.
T
h
e
s
a
m
e
a
r
c
h
i
t
e
c
t
u
r
e
p
r
i
n
c
i
p
l
e
s
s
h
o
u
l
d
w
o
r
k
f
o
r
:
Large networks (with added bells and whistles); and
Smaller networks (with reduced “dynamic” parts).
C
O
N
C
L
U
S
I
O
N
S
Future Homenet, as discussed in the IEEE draft by Jouni Korhonen and Philippe Klein, focuses on enabling next-generation IPv6 home networking environments through solutions like routing, prefix configuration, name resolution, service discovery, and network security. The architecture emphasizes IPv6 support, multiple routers, easy setup, security, and network segmentation for different uses. Through examples, the architecture illustrates scenarios involving multiple ISPs, addressing complexities, and service access considerations.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
FUTURE HOMENET MEETS IEEE DRAFT 6 Jouni Korhonen, Philippe Klein July 2014 1
FUTURE HOMENET ACTIVITIES - IETF IETF Homenet WG works an a set of solutions to enable next generation IPv6 home networking environment, where multiple routers and devices can be plugged together in an ad-hoc manner by hopelessly non-technical people. Entirely a Layer 3 only, IP centric, solution it is assumed Layer 2 just works.. (*) Homenet must support: Routing, Prefix configuration for routers, Name resolution, Service discovery, and Network security. Architecture and requirements are documented: draft-ietf-homenet-arch-17 (in IESG already..) (*) not quite right in reality.. This is where TSN & IWK can give a hand and cooperation needed across layers. 2
GOALS AND PRINCIPLES Solutions MUST work with IPv6, and IPv4 support is a bonus.. Must support multiple routers and arbitrary topologies with any number of subnets/prefixes/links. Support for multiple ISPs and/or multiple CPEs. Plug n play auto/zeroconf; e.g. loops must not confuse the system. Adequate default security; from outside the network and within the network. Possibility to isolate parts of the network e.g. for own, visitor, utility, IoT and 3rd party managed network segments. 3
ARCHITECTURE EXAMPLE.. Media nw Common nw NAS TV etc CPE Home nw Public server e.g. TV feed ISP DHCPv6-PD -> /64 /64 Home IoT HNET RTR HNET RTR Home Automation /64 /64 ? (unintentinal loop) HNET RTR /64 Remote managed utilities 3rd party Managed nw /64 Visitor nw Network segmented for different uses Using L3 addressing Each segment _may_ have further switched L2 L3 routing essential to make the homenet topology to work.. 4
ARCHITECTURE EXAMPLE TWO ISP ISP #1 ISP #2 ISP#1 CPE ISP#2 CPE HNET RTR Host Host Host Host Internal network Source address selection becomes essential IP packets with ISP#1 configured source address are not routable via ISP#2 CPE (ingress filtering is common). It is possible that a host configures addresses from both ISPs Would be normal with IPv6 when SLAAC is used.. 5
ARCHITECTURE EXAMPLE TWO ISP ONE CPE ISP #1 ISP #2 CPE Content services accessible only via ISP#2.. (TV etc.. CPE provides aggregate of configuration information.. HNET RTR Host Host Host Host Internal network Source address selection complexity in a different form IP packets with ISP#1 configured source address are not routable via ISP#2 CPE (ingress filtering is common). End hosts see only one CPE and source for addressing.. However.. only certain range of source addresses can be used to reach e.g. ISP#2 services.. 6
THE SOLUTION SPACE No changes to end hosts -> existing host configuration protocols remains unchanged (SLAAC, DHCPv6, DNS(SD), etc). Minimal changes to existing management/infra protocols: New protocols or extensions may be introduced if seen necessary. On the table: Source Address Dependent Routing, Prefix Coloring & Assignment and Boundary Detection etc. No requirement for a homenet wide routing protocol: Plug-ins for OSPFv3 do exist already to assist zeroconf.. Routers synchronize state across home network using the using the Home networking Control Protocol (HNCP) in order to facilitate automated configuration and use of routing protocols without homenet specific extension: Automated configuration requires support for host configuring & serving daemons to be HNCP aware. Must allow mixing legacy CPEs a la RFC7084. 7
THE HOMENETWORKING CONTROL PROTOCOL A Trickle-driven [RFC6206] multicast state flooding + unicast state synchronization protocol on top of UDP. Link scope and IPv6 link-local addressing. Trickle (per each link) makes sure the flooding is not too babbling and not everybody floods at the same time.. Rapid propagation, low maintenance. Protocol documented in [draft-ietf-homenet-hncp-01]. Download implementation: https://github.com/sbyx/hnetd Configuration information (e.g. originally received by the CPE facing ISP network via DHCPv6-PD, etc...) distributed to homenet aware routers.. MC State Announcement MC State Announcement Link-local scope Link-local scope UC State Sync UC State Sync MC=Multicast UC=Unicast 8
HNCP FEATURES MORE DETAILED RUNDOWN State (i.e. database) synchronization between routers link-local multicast transmission unicast fallback for bulk synchronization collision and conflict detection and resolving Prefix distribution and allocation IPv6 prefix delegation IPv4 prefix allocation Routing setup Selection of a shared routing protocol Fallback mechanism to setup routes autonomously Dynamic border-detection for IPv4 and IPv6 On-demand firewall reconfiguration On-demand RA/DHCP/DHCPv6 server configuration Integration of fixed external connections (e.g. PPP, 6rd, ...) Sharing of DNS and Service Discovery configuration Local DNS configuration mDNS / DNS-SD hybrid proxy configuration 9
HNCP DATA MODEL Flexible TLV-only message structure. Each router has: An unique identity, for example, it may be a public key, unique hardware ID, or some other unique blob of binary data. A synchronized configuration data set (ordered set of TLVs), with: Latest update sequence number. Relative time, in milliseconds, since last publishing of the current TLV data set. Hash over the set for fast comparison. A public/private key-pair for authentication. Change in state / data noticed when the hash calculated (and advertised) over the data changes.. 10
ACTUALLY THERE IS MORE IN THE PIPE.. Recent Autonomic Networking (AV) activity and non-WG forming BoF on UCAN steps into home networking area as well: Aims at self-management, including self-configuration, self-optimization, self-healing and self-protection of the network. AN will need to discover information about the surrounding network and to negotiate parameter settings with their neighbors and other nodes. Possible a learning and cognitive capability, i.e. the ability for distributed entities to self-adapt their decision making process based on information and knowledge gained from their environment (sensing). Defines a new Configuration Discovery and Negotiation Protocol for Network Devices (CDNP). HNCP is a database synchronization protocol while CDNP is a generic negotiation protocol.. but can be used to achieve the same thing.. AN and CDNP targets larger networks than home networks but.. 11
AND HOW THIS RELATES TO 802.1QCA ET AL..? In certain deployments, like, home networking environment: L3 and L2 are developing their own. There should be a standard way to make these two layers to communicate; for example: When doing path computation and reservation over multiple L3 segments. When segmenting the network for different purposes so that both layers have the same view of the topology. The list goes on.. Basically ensuring alignment. 12
ARCHITECTURE CONSIDERATIONS FOR .1QCA Media nw Common nw NAS TV etc CPE Home nw Public server e.g. TV feed ISP DHCPv6-PD -> /64 /64 Home IoT HNET RTR HNET RTR Home Automation /64 /64 ? (unintentional loop) HNET RTR /64 Remote managed utilities 3rd party Managed nw How does .1Qca fit here? /64 Visitor nw Path reservation over multiple L3 segments: L2 may still have arbitrary non-loop-free cabling.. L2 area in a L3 segment may contain arbitrary switched topology.. L2 using IS-IS SPB, whereas L3 can be e.g. IS-IS, OSPFv3 or nothing.. Need for a L3 to L2 communication for path reservation and coordinated network segmentation? 13
ARCHITECTURE CONSIDERATIONS FOR .1QCA ISP #1 ISP #2 .1Qca (br to br) PCE2 ISP#1 CPE ISP#2 CPE PCE1 .1Qca PCE to PE PEs for PCE1 HNET RTR PEs for PCE2 Host Host Host Host Internal network What if a host belongs to two CPEs? A PE belongs still to one PCE.. How would 802.1Qca with PCE PE architecture fit here.. Multiple PCEs and Pes. Also PCE to PCE communication.. See ca-farkas-small-nets-0514-v02.pdf 14
ARCHITECTURE PROPOSAL FORMING.. L3 PCE to PCE link missing..? .1Qca or something else..? ED ED ED ED BR (PE) BR (PE) HN RTR BR (PE) BR (PE) CPE PCE 1 PCE 2 BR (PE) BR (PE) L3-L2 PCE service point missing..? ED ED PEs agnostic to the multiple PCEs and L3 segments PCE part of the router or CPE L2 protocols exports service points to the L3 protocols to allow these protocols to be deterministic while network agnostic. Ok.. The architecture applies to larger or smaller scale networks than a home network; it just serves a good starting point.. 15
CONCLUSIONS Need for alignment with L2 and L3 efforts: For example in home networking. Solution for L2 and L3 cooperation for e.g. path reservations: Expose required service points. Agree on minimum set of required information elements passed between functions and layers. Fitting the (.1Qca) PCE PE model with L3 developments. The same architecture principles should work for: Large networks (with added bells and whistles); and Smaller networks (with reduced dynamic parts). 16
