Report from IETF 89 in London - DNS, DHCP and IPv6

©!Men!&!Mice!!http://menandmice,com!

IETF!89!Review

12.!March!2014

1Monday 17 March 14

http://www.menandmice.com



IETF

•The!Internet!Engineering!Task!Force!(IETF)!is!a!large!open!international!community!of!network!designers,!operators,!vendors,!and!researchers!concerned!with!the!evolution!of!the!Internet!architecture!and!the!smooth!operation!of!the!Internet.!It!is!open!to!any!interested!individual.!The!IETF!Mission!Statement!is!documented!in!RFC!3935.

•http://www.ietf.org/about/

2Monday 17 March 14



http://www.ietf.org/glossary.html#IETF

http://www.ietf.org/glossary.html#IETF

http://www.ietf.org/rfc/rfc3935.txt

http://www.ietf.org/rfc/rfc3935.txt

http://www.ietf.org/about/

http://www.ietf.org/about/


Agenda

• IETF!89!in!London!

• DNS

• DNSSEC!/!DANE

• DHCP

• IPv6

• the!following!information!is!an!excerpt!of!the!IETF!working!group!activities

• for!a!full!overview!of!all!activities!at!IETF!89,!see!https://datatracker.ietf.org/meeting/89/materials.html

3Monday 17 March 14



https://datatracker.ietf.org/meeting/89/materials.html

https://datatracker.ietf.org/meeting/89/materials.html


DNS

4Monday 17 March 14




published!new!RFCs!since!last!IETF

RFC Title Category

6950Architectural Considerations on Application Features in the

DNSInformational

7043Resource Records for EUI-48 and EUI-64 Addresses in the

DNSInformational

7050Discovery of the IPv6 Prefix Used for IPv6 Address

SynthesisStandards Track

7129 Authenticated Denial of Existence in the DNS Informational

5Monday 17 March 14




DNSE!BoF

•Confidentiality!and!Privacy!in!DNS

•DNS!traffic!reveals!a!lot!of!information!about!a!user

•IETF!has!a!plan!to!harden!all!Internet!protocols!agains!pervasive!monitoring

•DNS!is!no!exception

6Monday 17 March 14




DNSE!BoF

• the!problem!statement!has!been!presented!and!discussed

• some!proposed!solutions!have!been!presented

• DTLS!(TLS!for!UDP,!RFC!6347)

• DNScrypt/DNScurve

• CGA-TSIG

• Confidential!DNS

• t-DNS!(StartTLS!for!TCP!DNS)

• discussion!continues!on!the!mailing!lists!(DNSOP)!about!possible!solutions!and!their!operational!impact

7Monday 17 March 14




DNSOP

•Revived!documents:

• Initializing!a!DNS!Resolver!with!Priming!Queries!(draft-ietf-dnsop-resolver-priming)

• the!initial!queries!a!DNS!resolver!is!supposed!to!emit!to!initialize!its!cache!with!a!current!NS!RRSet!for!the!root!zone!as!well!as!the!necessary!address!information.

• the!“root-hints”!file!and!how!DNS!caching!server!use!it

• how!long-running!DNS!servers!update!the!root-hint!information

8Monday 17 March 14




DNSOP

•Revived!documents:

• DNSSEC!Key!Timing!Considerations!(draft-ietf-dnsop-dnssec-key-timing)

• Explains!the!relationships!between!the!parameters!used!in!a!DNSSEC!key!rollover

• important!for!implementers!of!DNSSEC!key-rollover!automation!software

• and!DNS!administrators!that!plan!manual!DNSSEC!key!rollover

9Monday 17 March 14




Special!Names

•RFC!6761!“Special-Use!Domain!Names”!defines!a!registry!of!domain!names!that!are!“special-use”!domain!names

•“.local”!for!multicast-DNS!and!local!service!discovery!

10Monday 17 March 14




Special!Names

•“Special-Use!Domain!Names!of!Peer-to-Peer!Systems”!(draft-grothoff-iesg-special-use-p2p-names)

• proposes!to!add!new!names!to!the!special-names!registry:!".gnu",!".zkey",!".onion",!".exit",!".i2p",!and!!!".bit"

• TOR

• GNUnet

• i2p

• Namecoin





Special!Names

•“The!ALT!Special!Use!Top!Level!Domain”!(draft-wkumari-dnsop-alt-tld-00)

•proposes!a!single!“.ALT”!(alternate)!TLD!for!special!names

•this!TLD!can!be!“blacklisted”!in!DNS!caching!server!software!to!prevent!leakage!of!these!names!into!the!“normal”!Internet!DNS!(Root-Name!Server!System)





DNS!cookies

•Domain!Name!System!(DNS)!Cookies!(draft-eastlake-dnsext-cookies)

•DNS!cookies!are!intended!to!provide!significant!but!limited!protection!against!certain!attacks!by!off-path!attackers.!

•These!attacks!include!denial-of-service,!cache!poisoning!and!answer!forgery.

•cookies!are!some!random!data!identifying!a!DNS!server,!send!inside!the!EDNS0!“OPT”!record





DNS!cookies

www.example.com IN A?

Authoritative DNS

Caching/Resolving DNS

Attacker




http://www.example.com



DNS!cookies


www.example.com IN A?+ Resolver cookie in OPT

Auth DNS server storesresolver cookie









DNS!cookies




www.example.com IN A 192.0.2.1+ server cookie in OPT

Cache DNS server storesauth-server cookie











DNS!cookies




www.example.com IN A 192.0.2.1+ server cookie in OPT

Cache DNS server storesserver cookie

www.example.com IN A 192.0.2.1













DNS!cookies

www.example.com IN AAAA?+ Resolver cookie in OPT

Auth DNS server hasresolver cookie

www.example.com IN AAAA 2001:db8::1Cache DNS server hasserver cookie

Attacker sendsforged DNS data









DNS!cookies

www.example.com IN AAAA?+ Resolver cookie in OPT

Auth DNS server hasresolver cookie

www.example.com IN AAAA 2001:db8::1Cache DNS server hasserver cookie

Attacker sendsforged DNS data









DNS!cookies

•a!prototype!of!DNS!cookies!(Source!Identity!Token)!has!been!implemented!in!BIND!9.10

• not!the!same,!but!similar!to!the!IETF-draft

•Beta!1!of!BIND!9.10!is!now!available

•as!there!is!no!RFC!standard,!it!uses!an!experimental!private!EDNS0!OPT!option!code!(65001)





getdnsapi

•NLnetLabs,!Verisign!and!No!Mountain!Software!released!a!new!client!DNS!resolver!library!under!an!open!source!BSD!license

•based!on!an!original!specification!from!Paul!Hoffman!(vpnc.org)

•Download!and!information:!https://getdnsapi.net

•Support!for!DNSSEC,!DANE!(TLSA),!new!record!types,!SRV!record!handling




https://getdnsapi.net

https://getdnsapi.net


getdnsapi

• Platforms!as!of!IETF!89!!

• RHEL/CentOS

• MacOS

• Soon!to!by!available:

• FreeBSD!

• iOS!(now!rough!but!usable)!!

• In!view:

• Windows,!Android





getdnsapi

•Language!bindings

•Python

•Objective-C

•Java

•JavaScript!(NodeJS)





DANE






No!DANE!related!RFC!documents!have!beenpublished!since!the!last!IETF





DANE

•DANE!utilizes!DNSSEC!to!provide!opportunistic!(without!manual!configuration)!encryption!with!our!without!Certification!Authorities!(CAs)

•there!is!much!interest!in!the!DANE!work!from!other!IETF!working!groups!and!application!developers





DANE!in!Web-Browser

• RFC!6698!-!The!DNS-Based!Authentication!of!Named!Entities!(DANE)!Transport!Layer!Security!(TLS)!Protocol:!TLSA

• Plugin!for!Firefox,!Opera,!Chrome!and!Internet!Exporer!available!https://www.dnssec-validator.cz/

• Internet!sites!start!using!TLSA,!for!example

https://packages.debian.org




https://www.dnssec-validator.cz

https://www.dnssec-validator.cz




SMTP!TLSA!in!Postfix

•using!TLS!(Transport!Layer!Security,!formerly!known!as!SSL)!with!SMTP!(E-Mail!delivery)!has!many!issues

•certificate!validation!is!not!mandatory!(and!often!not!possible)

•Plaintext!is!the!default,!TLS!is!optional

• “Men!in!the!Middle”!attacker!can!force!plain-text!connections!through!a!downgrade!attack!(remove!“STARTTLS”!command!from!conversation)





SMTP!TLSA

•DANE!specifies!the!use!of!the!TLSA!resource!record!for!SMTP

•can!make!TLS!connections!mandatory!between!servers!that!support!TLS

•TLSA!resource!record!holds!a!hash!of!the!server!certificateshell> dig mx tidelock.de +short10 ns3.tidelock.de.

shell> dig _25._tcp.ns3.tidelock.de. tlsa +short3 0 1 76AD75E4F300C2BACBDC9363A337A533F3B3C15CAAFED4E0010D5DD3 52B83935





TLSA!in!Postfix

•the!Postfix!Mail-Server!2.11!implements!DANE!TLSA!for!SMTP

• Viktor!Dukhovni!from!the!Postfix!team!presented!on!the!challenges!of!implementing!TLSA!checking!in!applications

• DANE!implementation!in!software!can!be!very!complicated!(easy!to!get!wrong)

• should!be!handled!by!a!toolkit!(OpenSSL,!GnuTLS,!NSS!...)

•Postfix!author!Wietse!Venema!presented!the!Postfix!TLSA!implementation!during!FOSDEM!2014!(1!February!2014)




https://fosdem.org/2014/schedule/speaker/wietse_venema/

https://fosdem.org/2014/schedule/speaker/wietse_venema/


more!DANE!work

•DANE!for!SIP!(VoIP)

•DANE!for!SRV!records!(for!Jabber/XMPP!and!other!protocols!using!SRV-Records)

•as!of!March!2014,!58!Jabber!Server!already!use!DANE!and!DNSSEC!(!https://xmpp.net/reports.php#dnssecdane )




https://xmpp.net/reports.php#

https://xmpp.net/reports.php#


more!DANE!work

•OpenPGP!keys!in!DNS

• today,!OpenPGP!key!are!stored!in!central!“key-server”,!such!as!hks://pgp.mit.edu

• “Using!DANE!to!Associate!OpenPGP!public!keys!with!email!addresses”!(draft-wouters-dane-openpgp)!proposes!to!store!OpenPGP!keys!in!DNS!(DNSSEC!secured)





more!DANE!work


• the!owner-name!of!the!OPENPGPKEY!Record!is!the!SHA224!hash!of!the!user!portion!of!an!E-Mail!address

• the!user!part!of!an!E-Mail!address!can!contain!characters!illegal!in!DNS!names!

• Example!([email protected])shell> echo -n "paul" | openssl dgst -sha224 ab16de0656382d91838914109ab89a0a4e04321550a1a20ace7a8b66

SHA224!hash!of!the!username





more!DANE!work

• OpenPGP!keys!in!DNS

• Example!([email protected])shell> dig -t TYPE65280 ab16de0656382d91838914109ab89a0a4e04321550a1a20ace7a8b66._openpgpkey.nohats.ca +m ; <<>> DiG 9.9.4-P2 <<>> -t TYPE65280 ab16de0656382d91838914109ab89a0a4e04321550a1a20ace7a8b66._openpgpkey.nohats.ca +m;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24851;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;ab16de0656382d91838914109ab89a0a4e04321550a1a20ace7a8b66._openpgpkey.nohats.ca. IN TYPE65280

;; ANSWER SECTION:ab16de0656382d91838914109ab89a0a4e04321550a1a20ace7a8b66._openpgpkey.nohats.ca. 2822 IN TYPE65280 \# 2527 ( 99010D033F7B0C3D00000107FF686BB69E18ACD31C38 0005F186CCF2BC9697CB87FDD4C5CD5DA994CB7E0958 7B57910637B89C9BC9FE697509798FA9BDFB638978F4 92F10999C3A595F6EF1BEE01BACE1C9F636D33B632D2 [...] 4356D7E7E6DF1AAF09075505380D20C3164276 )

;; Query time: 6 msec;; SERVER: 127.0.0.1#53(127.0.0.1);; WHEN: Tue Mar 11 17:22:21 CET 2014;; MSG SIZE rcvd: 2646

OpenPGP!Key

(Base64)

DNSSEC!secured!

private!record!type!for!experimental!new!protocols





more!DANE!work


• “milter”!plugin!for!postfix!and!sendmail:

https://github.com/letoams/openpgpkey-milter/

• “hash-slinger”!tool!to!create!and!verify!“openpgpkey”!records:https://github.com/letoams/hash-slinger

• also!available!in!Fedora!Linuxshell> yum install hash-slinger






https://github.com/letoams/hash-slinger

https://github.com/letoams/hash-slinger


IPSEC!in!DNS

• opportunistic!(automatic!and!authenticated)!IPSec!VPN!tunnel!between!client!and!server

• client!looks!up!the!server!public!key!in!DNSshell> dig ipseckey nohats.ca +m;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31467;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4;; QUESTION SECTION:;nohats.ca. IN IPSECKEY

;; ANSWER SECTION:nohats.ca. 3591 IN IPSECKEY ( 10 0 2 . AQPl2UGDJvDff4BiJWFZoSuYrerisFXZdD6M+QPDtpuH i4rNmW+jqNGzF7k4orsggHyaglXSN2llTb0dTCwBamX8 [...] dVbEHKz2sWdESIA2YNVqtPirkdYA0MeyO8SwYgMvlmg3 E8JcNBbcndEZidrlfINzFs2GmugvNHHHX6a7CPACNU0o E2mzXeDY3FUW2F2XvERTnQPpU9zl )

;; AUTHORITY SECTION:[....];; ADDITIONAL SECTION:[....]

;; Query time: 1 msec;; SERVER: 127.0.0.1#53(127.0.0.1);; WHEN: Tue Mar 11 17:41:17 CET 2014;; MSG SIZE rcvd: 590





IPSEC!Keys!in!DNS

•implemented!in!“libreswan”!(Linux)https://github.com/libreswan

•IPSECKEY!record!type!is!specified!in!RFC!4025!“A!Method!for!Storing!IPsec!Keying!Material!in!DNS”

•IPSECKEYs!for!IP-Address!initiated!connections!can!be!stored!in!reverse!(in-addr.arpa!and!ip6.arpa)!zones.




https://github.com/libreswan

https://github.com/libreswan


dbounds!BoF

•dbounds!=!Domain!Boundaries

•Browsers!and!other!software!(e.g.!DMARC)!relies!on!knowledge!of!administrative!delegation!boundaries!in!DNS

•the!public-suffix!list!provides!this!informationhttp://www.publicsuffix.org/




http://www.publicsuffix.org

http://www.publicsuffix.org


dbounds!BoF

• Example!from!the!public!suffix!list*.uk*.sch.uk!bl.uk!british-library.uk!mod.uk!national-library-scotland.uk!nic.uk!parliament.uk...

• Discussion!in!the!BoF:!is!DNS!better!suited!to!hold!this!information!than!a!plain!list?

• the!plain!list!needs!to!“guess”!administrative!boundaries,!whereas!domain!owner!can!specify!these!boundaries!in!their!DNS!zone

• no!decisions!so!far,!discussion!will!continue!on!the!mailing-list(s)





DHCP






RFC Title Category

7031 DHCPv6 Failover Requirements Informal

7037 RADIUS Option for the DHCPv6 Relay AgentStandards

Track

7078 Distributing Address Selection Policy Using DHCPv6Standards

Track

7083Modification to Default Values of SOL_MAX_RT and

INF_MAX_RTStandards

Track





Customizing!DHCP!Configuration!on!the!Basis!of!Network!Topology

•BCP-Document!“draft-ietf-dhc-topo-conf“

•documents!how!DHCP!clients,!DHCP!relay-agents!and!DHCP!server!interact

• DHCP!server!can!select!options!to!send!to!the!client!based!on!the!network!location!of!the!client

• covers!both!IPv4!and!IPv6





RFC!3315bis

•the!original!DHCPv6!RFC!3315!is!now!over!10!years!old

•more!operational!experience!exists!in!the!IETF!since!the!time!the!RFC!was!written

•some!parts!of!the!RFC!need!clarification

•merge!in!references!and!updates!from!other!RFCs!since!3315





dhcpv6bis

•Bug!tracker!and!mailing!listhttp://wiki.tools.ietf.org/group/dhcpv6bis/

•github!repository!with!the!new!documenthttps://github.com/dhcwg/rfc3315bis

•if!you!have!feedback!or!questions!on!DHCPv6bis,!please!contribute




http://wiki.tools.ietf.org/group/dhcpv6bis/

http://wiki.tools.ietf.org/group/dhcpv6bis/


DHCPv6!failover!design

•The!DHCPv6!failover!design!document!has!been!submitted!to!the!IESG!after!last!IETF!meeting

•came!back!and!will!now!be!split!into!two!documents

• failover!design

• failover!protocol!specification





DHC!Load!Balancing!Algorithm!for!DHCPv6

•“draft-ietf-dhc-dhcpv6-load-balancing”!describes!a!load-balancing!algorithm!for!DHCPv6!server,!where!the!servers!do!not!need!to!exchange!information

•!This!algorithm!is!an!extension!of!an!already!defined!and!proven!algorithm!used!for!DHCPv4,!as!described!in!RFC!3074.!





Registering!self-generated!IPv6!Addresses!in!DNS!using!DHCPv6

•Document!“draft-ietf-dhc-addr-registration”

•clients!that!use!self-generated!IPv6!addresses!(SLAAC,!CGA,!privacy!addresses)!send!a!request!to!the!DHCP!server!to!add!their!AAAA!forward!mapping!and!PTR!reverse!mapping!into!DNS

•only!the!DHCPv6!server!require!to!have!update!permissions!on!the!DNS!server,!not!all!clients





DHCPv4!over!DHCPv6!Transport

•running!two!network!protocols!site-by-site!(IPv4!and!IPv6)!is!expensive!(double!work)

•network!operators!try!to!remove!IPv4!as!much!as!possible!(access!networks,!backbone!networks,!datacenter!networks)

•client!machines!often!still!require!IPv4

•draft-ietf-dhc-dhcpv4-over-dhcpv6!defines!options!so!that!DHCPv4!requests!can!be!send!inside!DHCPv6!messages





DHCPv4!over!DHCPv6!Transport

•Tsinghua!University!has!implemented!DHCPv4!over!DHCPv6!on!top!of!BIND!10!1.1.0!DHCP

• https://github.com/gnocuil/DHCPv4oDHCPv6

• Site!note:!BIND!10!1.2.0!beta!1!has!been!released!last!week:!http://ftp.isc.org/isc/bind10/1.2.0beta1/

•“Provisioning!IPv4!Configuration!Over!IPv6!Only!Networks”!(draft-ietf-dhc-v4configuration)!discussed!the!various!options!available!to!send!IPv4!configuration!over!IPv6!only!networks




https://github.com/gnocuil/DHCPv4oDHCPv6

https://github.com/gnocuil/DHCPv4oDHCPv6

http://ftp.isc.org/isc/bind10/1.2.0beta1/

http://ftp.isc.org/isc/bind10/1.2.0beta1/


Secure!DHCPv6!with!Public!Key

•DHCPv6!is!more!powerful!than!DHCPv4

• for!some!functions,!authentication!and!integrity!checks!are!requested!(like!server-reconfigure!message!to!clients)

•‘draft-jiang-dhc-sedhcpv6’!specifies!an!protocol!extension!to!secure!the!DHCPv6!communication!between!client,!relay-agent!and!server!via!public/private!key!pairs.

•The!authority!of!the!sender!may!depend!on!either!pre-configuration!mechanism!or!a!Public!Key!Infrastructure.





IPv6






RFC Title Category

7045 Transmission and Processing of IPv6 Extension Headers Standards Track

7048 Neighbor Unreachability Detection Is Too Impatient Standards Track

7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis Standards Track

7059 A Comparison of IPv6-over-IPv4 Tunnel Mechanisms Informational

7094 Architectural Considerations of IP Anycast Informational

7136 Significance of IPv6 Interface Identifiers Standards Track

7112 Implications of Oversized IPv6 Header Chains Standards Track

7123 Security Implications of IPv6 on IPv4 Networks Informational





Stable!IPv6!Interface!Identifiers

•the!current!IPv6!standards!mandate!that!Interface-ID!of!Statless-Address-Auto-Configuration!(SLAAC)!addresses!are!generated!from!the!hardware-address!(MAC-Address)!of!the!Interface

2001:db8:100:0:28c:f5ff:fe05:4235

Prefix Interface-ID






• the!draft!“Privacy!Considerations!for!IPv6!Address!Generation!Mechanisms”

(draft-ietf-6man-ipv6-address-generation-privacy)!discusses!privacy!and!security!considerations!for!several!IPv6!address!generation!mechanisms

• correlation!of!activities!over!time

• location!tracking

• address!scanning

• device-specific!vulnerability!exploitation






•The!IETF!draft!“A!Method!for!Generating!Semantically!Opaque!Interface!Identifiers!with!IPv6!Stateless!Address!Auto-Configuration!(SLAAC)”(draft-ietf-6man-stable-privacy-addresses)!describes!a!way!to!generate!Interface!IDs!for!IPv6!addresses!that!are

•unique!and!stable!for!each!network

•but!change!for!every!network!the!host!visits





Why!“/64”?

• IPv6!subnets!are,!with!the!exception!of!loopback!and!point-to-point!connections,!of!size!/64

• RFC!7136!states!that!"For!all!unicast!addresses,!except!those!that!start!with!the!binary!value!000,!Interface!IDs!are!required!to!be!64!bits!long."

• “Analysis!of!the!64-bit!Boundary!in!IPv6!Addressing”(draft-carpenter-6man-why64)!discusses

• why!the!“/64”!size!was!chosen

• why!network!administrators!ask!for!other!subnet!sizes!(prefixes!longer!than!/64)

• what!will!break!if!IPv6!is!configured!with!subnet!sizes!other!than!“/64”





Unknown!IPv6!Extension!header

•“middle-boxes”!(Firewalls,!Intrusion!Detection!Systems,!specialized!Router)!cannot!parse!the!Extension-Header!chain,!as!they!cannot!“jump-over”!unknown!extensions

•this!was!on-purpose!in!the!original!IPv6!specifications,!as!the!core!of!the!network!should!be!“dumb”,!just!forwarding!packets,!not!inspecting!them

• however!in!reality!today,!IPv6!traffic!often!is!dropped!because!of!middle-boxes!that!cannot!check!the!header!chain






IPv6header

next=43 (routing)

Routing header

next=123 (??)TCP payload

Destination Option headernext=6 (tcp)

Unknown header

next=60 (dest option)

unknown size

Middle-box!cannot!find!TCP!

port!information






•the!draft!“IPv6!Universal!Extension!Header”(draft-gont-6man-ipv6-universal-extension-header)proposes!an!universal!extension!header!containing!just!one!header-type-identifier!and!an!8bit!sub-type!field,!which!allows!for!256!extension!header!sub-types

• it!proposes!to!close!the!registry!for!new!IPv6!extension!headers

•new!header-functions!would!be!implemented!as!sub-types!of!the!“universal-extension-header”





SLAAC!and!DHCPv6

• DHCPv6/SLAAC!Address!Configuration!Interaction!Problem!Statement!(draft-ietf-v6ops-dhcpv6-slaac-problem)

• DHCPv6/SLAAC!Interaction!Operational!Guidance!Considerations!(draft-liu-v6ops-dhcpv6-slaac-guidance)

• Guidance!for!DHCPv6-only!Deployment

• Guidance!for!SLAAC-only!Deployment

• Guidance!for!DHCPv6/SLAAC!Co-exist!Deployment

• DHCPv6/SLAAC!Interaction!Implementation!Guidance!(draft-liu-6man-dhcpv6-slaac-implementation-guide)





Unique!Local!Addresses!(ULA)

•“Recommendations!of!Using!Unique!Local!Addresses”(draft-ietf-v6ops-ula-usage-recommendations)

• lists!use-cases!of!ULA!and!documents!possible!drawbacks

• use!of!ULA!in!isolated!networks

• use!of!ULA!together!with!Globally!Unique!Addresses!(GUA)





Design!Choices!for!IPv6!Networks

•“draft-ietf-v6ops-design-choices”

•Mix!IPv4!and!IPv6!on!the!Same!Link?

•Links!with!Only!Link-Local!Addresses?

•Link-Local!Next-Hop!in!a!Static!Route?

•Choice!of!IGP!(OSPF!vs.!IS-IS)!





Reducing!multicast!in!IPv6

•Multicast!can!be!expensive!in!terms!of!energy!consumption!on!certain!link-layer!technologies!(e.g.!W-LAN)

• IPv6!neighborhood!discovery!relies!heavily!on!link-local!multicast

• other!protocols!like!multicast-dns!can!create!equally!or!more!multicast!traffic

• the!IETF!6ops!and!6man!working-groups!discuss!options!to!replace!the!use!of!multicast!in!these!networks!with!alternatives!(unicast)





Q/A

?Slides,!Links,!Recording!and!errata!will!be!posted!@

https://www.menandmice.com/resources/educational-resources/webinars/




Technology

Report from IETF 89 in London - DNS, DHCP and IPv6