From nobody Sun Jan 3 19:46:40 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CCB3A15C5 for ; Sun, 3 Jan 2021 19:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.019 X-Spam-Level: * X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BIGNUM_EMAILS=1.717, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_sU-vRw-85L for ; Sun, 3 Jan 2021 19:46:35 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 678763A15E3 for ; Sun, 3 Jan 2021 19:46:15 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app09-12009 (RichMail) with SMTP id 2ee95ff28f73dfa-39fe8; Mon, 04 Jan 2021 11:45:55 +0800 (CST) X-RM-TRANSID: 2ee95ff28f73dfa-39fe8 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from PENG (unknown[10.2.53.108]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee35ff28f72ffa-53a04; Mon, 04 Jan 2021 11:45:55 +0800 (CST) X-RM-TRANSID: 2ee35ff28f72ffa-53a04 MIME-Version: 1.0 x-PcFlag: 25914a26-a384-4ef8-bcd0-129899ea6eb3_5_45223 X-Mailer: PC_RICHMAIL 2.8.5 Date: 04 Jan 2021 11:45:56 +0800 From: =?utf-8?B?5YiY6bmP?= To: =?utf-8?B?Qm9iIEhpbmRlbg==?=, =?utf-8?B?SVB2NiBMaXN0?= Cc: =?utf-8?B?Qm9iIEhpbmRlbg==?= Subject: Re: Working Group Last Call for Message-ID: <20210104114556320992441@chinamobile.com> Content-Type: multipart/Alternative; boundary="----=_001_NextPart320992441_=----" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 03:46:38 -0000 This is a multi-part message in MIME format. ------=_001_NextPart320992441_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQ1JIHN1cHBvcnQgdGhlIHB1YmxpY2F0aW9uLiANDQ0NDVJlZ2FyZHMsDQ1QZW5nDQ0NDQ0NDQ0N UGVuZyBMaXUgfCDliJjpuY8NDUNoaW5hIE1vYmlsZSB8IOenu+WKqOeglOeptumZog0NbW9iaWxl IHBob25l77yaMTM4MTAxNDYxMDUNDWVtYWlsOiAgbGl1cGVuZ3lqeUBjaGluYW1vYmlsZS5jb20N DSANDQ0N5Y+R5Lu25Lq6OiBCb2IgSGluZGVuDQ3ml7bpl7Q6IDIwMjAvMTIvMjEo5pif5pyf5LiA KTAzOjEwDQ3mlLbku7bkuro6IElQdjYgTGlzdDsNDeaKhOmAgeS6ujogQm9iIEhpbmRlbjsNDeS4 u+mimDogV29ya2luZyBHcm91cCBMYXN0IENhbGwgZm9yIFRoaXMgbWVzc2FnZSBzdGFydHMgYSBu ZXcgdGhyZWUgd2VlayA2TUFOIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uDWFkdmFuY2luZzoN DSAgICAgICBUaXRsZSAgICAgICAgICAgOiBJUHY2IEFwcGxpY2F0aW9uIG9mIHRoZSBBbHRlcm5h dGUgTWFya2luZyBNZXRob2QNICAgICAgIEF1dGhvcnMgICAgICAgICA6IEdpdXNlcHBlIEZpb2Nj b2xhDSAgICAgICAgICAgICAgICAgICAgICAgICBUaWFucmFuIFpob3UNICAgICAgICAgICAgICAg ICAgICAgICAgIE1hdXJvIENvY2lnbGlvDSAgICAgICAgICAgICAgICAgICAgICAgICBGZW5nd2Vp IFFpbg0gICAgICAgICAgICAgICAgICAgICAgICAgUmFuIFBhbmcNICAgICAgICBGaWxlbmFtZSAg ICAgICAgOiBkcmFmdC1pZXRmLTZtYW4taXB2Ni1hbHQtbWFyay0wMi50eHQNICAgICAgICBQYWdl cyAgICAgICAgICAgOiAxNQ0gICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMjAtMTAtMTMNDWFz IGEgUHJvcG9zZWQgU3RhbmRhcmQuICBXZSBub3JtYWxseSBkbyB0d28gd2VlayBsYXN0IGNhbGxz LCBidXQgZ2l2ZW4gdGhlDWhvbGlkYXlzLCB3ZSB0aGluayB0aHJlZSB3ZWVrcyBpcyBhcHByb3By aWF0ZS4NDVN1YnN0YW50aXZlIGNvbW1lbnRzIGFuZCBzdGF0ZW1lbnRzIG9mIHN1cHBvcnQgZm9y IHB1Ymxpc2hpbmcgdGhpcyBkb2N1bWVudA1zaG91bGQgYmUgZGlyZWN0ZWQgdG8gdGhlIGlwdjZA aWV0Zi5vcmcgbWFpbGluZyBsaXN0LiAgRWRpdG9yaWFsIHN1Z2dlc3Rpb25zDWNhbiBiZSBzZW50 IHRvIHRoZSBhdXRob3JzLiAgVGhpcyBsYXN0IGNhbGwgd2lsbCBlbmQgb24gMTAgSmFudWFyeSAy MDIxLg0NVGhhbmtzLA1Cb2IgJmFtcDsgT2xlDQ0NDT4gQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6 DT4NPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNPiBTdWJqZWN0OiBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLTZtYW4taXB2Ni1hbHQtbWFyay0wMi50eHQNPiBEYXRlOiBPY3RvYmVyIDEz LCAyMDIwIGF0IDc6MTA6NDIgQU0gUERUDT4gVG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DT4g Q2M6IGlwdjZAaWV0Zi5vcmcNPiBSZXBseS1UbzogaXB2NkBpZXRmLm9yZw0+DT4NPiBBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMNZGlyZWN0b3JpZXMuDT4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBN YWludGVuYW5jZSBXRyBvZiB0aGUgSUVURi4NPg0+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBJ UHY2IEFwcGxpY2F0aW9uIG9mIHRoZSBBbHRlcm5hdGUgTWFya2luZyBNZXRob2QNPiAgICAgICAg QXV0aG9ycyAgICAgICAgIDogR2l1c2VwcGUgRmlvY2NvbGENPiAgICAgICAgICAgICAgICAgICAg ICAgICAgVGlhbnJhbiBaaG91DT4gICAgICAgICAgICAgICAgICAgICAgICAgIE1hdXJvIENvY2ln bGlvDT4gICAgICAgICAgICAgICAgICAgICAgICAgIEZlbmd3ZWkgUWluDT4gICAgICAgICAgICAg ICAgICAgICAgICAgIFJhbiBQYW5nDT4gICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi02bWFuLWlwdjYtYWx0LW1hcmstMDIudHh0DT4gICAgICAgUGFnZXMgICAgICAgICAgIDogMTUN PiAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDIwLTEwLTEzDT4NPiBBYnN0cmFjdDoNPiAgIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0aGUgQWx0ZXJuYXRlIE1hcmtpbmcgTWV0aG9kIGNh biBiZSB1c2VkDT4gICBhcyB0aGUgcGFzc2l2ZSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCB0b29s IGluIGFuIElQdjYgZG9tYWluIGFuZA0+ICAgcmVwb3J0cyBpbXBsZW1lbnRhdGlvbiBjb25zaWRl cmF0aW9ucy4gIEl0IHByb3Bvc2VzIGhvdyB0byBkZWZpbmUgYQ0+ICAgbmV3IEV4dGVuc2lvbiBI ZWFkZXIgT3B0aW9uIHRvIGVuY29kZSBhbHRlcm5hdGUgbWFya2luZyB0ZWNobmlxdWUgYW5kDT4g ICBib3RoIEhvcC1ieS1Ib3AgT3B0aW9ucyBIZWFkZXIgYW5kIERlc3RpbmF0aW9uIE9wdGlvbnMg SGVhZGVyIGFyZQ0+ICAgY29uc2lkZXJlZC4NPg0+DT4NPiBUaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLTZtYW4taXB2Ni1hbHQtbWFyay8NPg0+IFRoZXJlIGFyZSBhbHNv IGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNPiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi02bWFuLWlwdjYtYWx0LW1hcmstMDINPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtNm1hbi1pcHY2LWFsdC1tYXJrLTAyDT4N PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DT4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtNm1hbi1pcHY2LWFsdC1t YXJrLTAyDT4NPg0+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mDXN1Ym1pc3Npb24NPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0+DT4gSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0+IGZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDT4N ------=_001_NextPart320992441_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
<=21--StartFragment-->= I=20support=20the=20publication.&n= bsp;<=21--EndFragment-->

Regards,Peng
Peng=20Liu=20= =7C=20=E5=88=98=E9=B9=8F
Ch= ina=20Mobile=20=7C=20=E7=A7=BB=E5=8A=A8=E7=A0=94=E7=A9=B6=E9=99=A2<= font=20style=3D=22font-size:=2011pt;=22>mobile=20phone=EF=BC=9A13810146105<= /font>email:  liupengyjy=40chinamobile.com
 
=E5=8F=91=E4=BB=B6=E4=BA=BA:= =20Bob=20Hinden=E6=97=B6=E9=97=B4:=202020/12/21(=E6=98=9F=E6=9C=9F=E4=B8=80)03:10= =E6=94=B6=E4=BB=B6=E4=BA=BA:=20IPv6=20List;=E6=8A=84=E9=80=81=E4=BA=BA= :=20Bob=20Hinden;= =E4=B8=BB=E9=A2=98:=20Working=20Group=20Last=20Call=20for=20
This=20message=20starts=20a=20new=20three=20week=206MAN=20Workin= g=20Group=20Last=20Call=20on
advancing:

=20=20=20=20=20=20=20Titl= e=20=20=20=20=20=20=20=20=20=20=20:=20IPv6=20Application=20of=20the=20Alter= nate=20Marking=20Method
=20=20=20=20=20=20=20Authors=20=20=20=20=20=20= =20=20=20:=20Giuseppe=20Fioccola
=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20Tianran=20Zhou
=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Mauro=20Cociglio
= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Fengwei=20Qin
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20Ran=20Pang
=20=20=20=20=20=20=20=20Filename=20=20=20= =20=20=20=20=20:=20draft-ietf-6man-ipv6-alt-mark-02.txt
=20=20=20=20=20= =20=20=20Pages=20=20=20=20=20=20=20=20=20=20=20:=2015
=20=20=20=20=20=20= =20=20Date=20=20=20=20=20=20=20=20=20=20=20=20:=202020-10-13

as=20a= =20Proposed=20Standard.=20=20We=20normally=20do=20two=20week=20last=20calls= ,=20but=20given=20the
holidays,=20we=20think=20three=20weeks=20is=20appr= opriate.

Substantive=20comments=20and=20statements=20of=20support=20= for=20publishing=20this=20document
should=20be=20directed=20to=20the=20i= pv6=40ietf.org=20mailing=20list.=20=20Editorial=20suggestions
can=20be= =20sent=20to=20the=20authors.=20=20This=20last=20call=20will=20end=20on=201= 0=20January=202021.

Thanks,
Bob=20&=20Ole



>= =20Begin=20forwarded=20message:
>
>=20From:=20internet-drafts= =40ietf.org
>=20Subject:=20I-D=20Action:=20draft-ietf-6man-ipv6-alt-m= ark-02.txt
>=20Date:=20October=2013,=202020=20at=207:10:42=20AM=20PDT=
>=20To:=20<i-d-announce=40ietf.org>
>=20Cc:=20ipv6=40iet= f.org
>=20Reply-To:=20ipv6=40ietf.org
>
>
>=20A=20N= ew=20Internet-Draft=20is=20available=20from=20the=20on-line=20Internet-Draf= ts
directories.
>=20This=20draft=20is=20a=20work=20item=20of=20the= =20IPv6=20Maintenance=20WG=20of=20the=20IETF.
>
>=20=20=20=20= =20=20=20=20Title=20=20=20=20=20=20=20=20=20=20=20:=20IPv6=20Application=20= of=20the=20Alternate=20Marking=20Method
>=20=20=20=20=20=20=20=20Auth= ors=20=20=20=20=20=20=20=20=20:=20Giuseppe=20Fioccola
>=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Tianran= =20Zhou
>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20Mauro=20Cociglio
>=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Fengwei=20Qin
>=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Ran=20= Pang
>=20=20=20=20=20=20=20Filename=20=20=20=20=20=20=20=20:=20draft-= ietf-6man-ipv6-alt-mark-02.txt
>=20=20=20=20=20=20=20Pages=20=20=20= =20=20=20=20=20=20=20=20:=2015
>=20=20=20=20=20=20=20Date=20=20=20=20= =20=20=20=20=20=20=20=20:=202020-10-13
>
>=20Abstract:
>= =20=20=20This=20document=20describes=20how=20the=20Alternate=20Marking=20Me= thod=20can=20be=20used
>=20=20=20as=20the=20passive=20performance=20m= easurement=20tool=20in=20an=20IPv6=20domain=20and
>=20=20=20reports= =20implementation=20considerations.=20=20It=20proposes=20how=20to=20define= =20a
>=20=20=20new=20Extension=20Header=20Option=20to=20encode=20alte= rnate=20marking=20technique=20and
>=20=20=20both=20Hop-by-Hop=20Optio= ns=20Header=20and=20Destination=20Options=20Header=20are
>=20=20=20co= nsidered.
>
>
>
>=20The=20IETF=20datatracker=20stat= us=20page=20for=20this=20draft=20is:
>=20https://datatracker.ietf.org= /doc/draft-ietf-6man-ipv6-alt-mark/
>
>=20There=20are=20also=20= htmlized=20versions=20available=20at:
>=20https://tools.ietf.org/html= /draft-ietf-6man-ipv6-alt-mark-02
>=20https://datatracker.ietf.org/do= c/html/draft-ietf-6man-ipv6-alt-mark-02
>
>=20A=20diff=20from= =20the=20previous=20version=20is=20available=20at:
>=20https://www.ie= tf.org/rfcdiff?url2=3Ddraft-ietf-6man-ipv6-alt-mark-02
>
>
&= gt;=20Please=20note=20that=20it=20may=20take=20a=20couple=20of=20minutes=20= from=20the=20time=20of
submission
>=20until=20the=20htmlized=20ver= sion=20and=20diff=20are=20available=20at=20tools.ietf.org.
>
>= =20Internet-Drafts=20are=20also=20available=20by=20anonymous=20FTP=20at:>=20ftp://ftp.ietf.org/internet-drafts/
>
------=_001_NextPart320992441_=------ From nobody Mon Jan 4 03:00:50 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEEF3A0BF6 for ; Mon, 4 Jan 2021 03:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=guest.telecomitalia.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7Dn9ePREwBd for ; Mon, 4 Jan 2021 03:00:45 -0800 (PST) Received: from mx05.telecomitalia.it (mx05.telecomitalia.it [156.54.232.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85A93A0BF3 for ; Mon, 4 Jan 2021 03:00:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=guest.telecomitalia.it; s=selector1; c=relaxed/relaxed; q=dns/txt; i=@guest.telecomitalia.it; t=1609758039; x=2473671639; h=MIME-Version:From:Date:Message-ID:Subject:To; bh=c3mTee6A8dzb1q+nNGj87qb4APjgLE8DPBtqsPBZrLg=; b=dqjjfEmJdhuK2rAR3KqPL/evXY74f+sOGBtrdLSQfiq/BKhsyQQsNQD0z9mBqRbS Jb9wxr8UUB7kQY0STz344VNifFv4DoRBudeh0GPln7I8lktW+OBRTVPtpB+xoNjH lo5Q/C3wGoqMHdMCr/+rUmUIJLgGio6Vh0BeK4tSTmUQ9x4nnWXZYhaagzjg8ZiS CBz7nvES40HIqxRwB1Js1lrHCYK9JZN3pbfjeEutHtp9465yetlrgbcYGjUpXufh /p9lbafN9ZyRPZnYM3TEVeJXMy1Qt2ZQiHO7Yh4DFOSA/dMXRAY3vr0uPLMplV67 WT6RjLVDb8070dM2+D4qwQ==; X-AuditID: 0a5a2d15-a642ea80000056af-65-5ff2f55624ee Received: from TELMBXC12BA020.telecomitalia.local ( [10.90.43.46]) by mx05.telecomitalia.it () with SMTP id 19.13.22191.655F2FF5; Mon, 4 Jan 2021 12:00:38 +0100 (CET) From: "Bulgarella Fabio (Guest)" To: IPv6 List CC: Bob Hinden Subject: Re: Working Group Last Call for Thread-Topic: Working Group Last Call for Thread-Index: AQHW1wPw68JE2pVQPUW0/quCUCCYKKoBKANQgBY63+s= Date: Mon, 4 Jan 2021 11:00:37 +0000 Message-ID: <1609758037648.37065@guest.telecomitalia.it> References: <160022348671.28445.8378620622786303015@ietfa.amsl.com> <7154EC82-1F39-404B-A98B-F656A4CB19BA@gmail.com>, In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [5.8.125.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsXCFaWtpxv29VO8wdxrRhZb3+9js3h59j2T A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXx7skUtoLD0hXr385mbGC8KNLFyMkhIWAi 8fHALPYuRi4OIYGVjBIT9l9m7GLk4GAT8JKYfUcZpEZEQFZizvIprCBhZgFVid83wkDCwgIe Epu7/jFDlHhKvD88Acq2klh57SMTiM0ioCLRdPIDC4jNK2Ah0bm8ixVi1RJGieffJ4Ct4gRq 2HjTF6SGEWjVhN2LGEFsZgFxiRfTT7BDnCkgsWTPeWYIW1Ti5eN/rBC2gcTWpftYIGw5iTX7 O9ghevUkbkydwgZha0ssW/iaGeIGQYmTM5+wTGAUnYVkxSwkLbOQtMxC0rKAkWUVo2huhYGp XklqTmpyfm5mSWJOZqJeZskmRnCM6IruYNy24o3eIUYmDsZDjBIczEoivBUXPsQL8aYkVlal FuXHF5XmpBYfYpTmYFES57385VO8kEB6YklqdmpqQWoRTJaJg1OqgUlP9p/6M+H1tsv553Ak ikS+dw2443JE5Vpi8YepZhuvTmiRKZ9884mMfVpiat7e9oX9h9qDvCtOOTh+fPJg8ekbnzZw rNr+Ypu6yvJj0xWn35nWt2Xf0n/Ny4J3VWRqXDO3XKDSuPDbF5fe/mlGr0JmPJtSuGDRt4Ti H7blv9x7uyq/nnAWZpX7W/jcuz2g+PNhS4lDhk8LFD1ZftQddzH3Pny/9sa7KzniTRcqPuax v46btVqyS0+CrTlVi/PppurScqMtIaJ7js6XuXfg1A35Owu+e801r0mt5PsVv4rveNSpBS2F Wr/3138qSVdl5n5byZ+gOttp6/ZFk1uaY87Up+7PubO76f6h/wtzig2VWIozEg21mIuKEwFd EKldAAMAAA== Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 11:00:48 -0000 Dear All,=0A= I support its pubblication.=0A= =0A= Best Regards,=0A= Fabio B.=0A= =0A= =0A= -----Original Message-----=0A= From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden=0A= Sent: Sunday, December 20, 2020 8:11 PM=0A= To: IPv6 List =0A= Cc: Bob Hinden =0A= Subject: Working Group Last Call for =0A= =0A= This message starts a new three week 6MAN Working Group Last Call on advanc= ing:=0A= =0A= Title : IPv6 Application of the Alternate Marking Method= =0A= Authors : Giuseppe Fioccola=0A= Tianran Zhou=0A= Mauro Cociglio=0A= Fengwei Qin=0A= Ran Pang=0A= Filename : draft-ietf-6man-ipv6-alt-mark-02.txt=0A= Pages : 15=0A= Date : 2020-10-13=0A= =0A= as a Proposed Standard. We normally do two week last calls, but given the = holidays, we think three weeks is appropriate.=0A= =0A= Substantive comments and statements of support for publishing this document= should be directed to the ipv6@ietf.org mailing list. Editorial suggestio= ns can be sent to the authors. This last call will end on 10 January 2021.= =0A= =0A= Thanks,=0A= Bob & Ole=0A= =0A= =0A= =0A= > Begin forwarded message:=0A= >=0A= > From: internet-drafts@ietf.org=0A= > Subject: I-D Action: draft-ietf-6man-ipv6-alt-mark-02.txt=0A= > Date: October 13, 2020 at 7:10:42 AM PDT=0A= > To: =0A= > Cc: ipv6@ietf.org=0A= > Reply-To: ipv6@ietf.org=0A= >=0A= >=0A= > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories.=0A= > This draft is a work item of the IPv6 Maintenance WG of the IETF.=0A= >=0A= > Title : IPv6 Application of the Alternate Marking Method= =0A= > Authors : Giuseppe Fioccola=0A= > Tianran Zhou=0A= > Mauro Cociglio=0A= > Fengwei Qin=0A= > Ran Pang=0A= > Filename : draft-ietf-6man-ipv6-alt-mark-02.txt=0A= > Pages : 15=0A= > Date : 2020-10-13=0A= >=0A= > Abstract:=0A= > This document describes how the Alternate Marking Method can be used=0A= > as the passive performance measurement tool in an IPv6 domain and=0A= > reports implementation considerations. It proposes how to define a=0A= > new Extension Header Option to encode alternate marking technique and= =0A= > both Hop-by-Hop Options Header and Destination Options Header are=0A= > considered.=0A= >=0A= >=0A= >=0A= > The IETF datatracker status page for this draft is:=0A= > https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/=0A= >=0A= > There are also htmlized versions available at:=0A= > https://tools.ietf.org/html/draft-ietf-6man-ipv6-alt-mark-02=0A= > https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-02=0A= >=0A= > A diff from the previous version is available at:=0A= > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-ipv6-alt-mark-02=0A= >=0A= >=0A= > Please note that it may take a couple of minutes from the time of=0A= > submission until the htmlized version and diff are available at tools.iet= f.org.=0A= >=0A= > Internet-Drafts are also available by anonymous FTP at:=0A= > ftp://ftp.ietf.org/internet-drafts/=0A= >=0A= From nobody Mon Jan 4 03:53:23 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685213A0C64 for ; Mon, 4 Jan 2021 03:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telecomitalia.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGvKY28Ie-Kl for ; Mon, 4 Jan 2021 03:53:18 -0800 (PST) Received: from mx08.telecomitalia.it (mx08.telecomitalia.it [156.54.232.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565983A0C5F for ; Mon, 4 Jan 2021 03:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=telecomitalia.it; s=selector1; c=relaxed/relaxed; q=dns/txt; i=@telecomitalia.it; t=1609761193; x=2473674793; h=MIME-Version:From:Date:Message-ID:Subject:To; bh=X7by3nZBmTc40HFO0z59CYtLZmnuxHzm/L4xlistp/k=; b=eMx7A1BJdPBehOXqAvlgvPuoe18Y4QR+gwQ9Ws5cr2w7ugEA2/LPTmLOgXQPj5CW 0ftGF631Fw7d1gkT/uUIzNN/np47pzn3etVLYS92X/2k1BmykObtTfDHz8bfDabr GmRHmdZlr4NzfykRbT3aMgzIlZ1fSWngKXXJ4FNKyFxZF56cP9pv7IwSqrvNwRCY /ZDgLIPACRA9V1ggriHDD8fIRmVvmhUBRcZWdhf9kdfllSevocvd7rYyXSo1hc0v C1aIFGhye1DmzGe9BRQ9IN9YcOEJORQGIpu+sgz4m/BL4jXQiIu5IqfTYCar87QY Z7eqm9vhjPlWKy766JhK1w==; X-AuditID: 0a5a2d18-7d9ff70000002bf2-ae-5ff301a92182 Received: from TELMBXD15BA020.telecomitalia.local ( [10.90.43.81]) by mx08.telecomitalia.it () with SMTP id 35.94.11250.9A103FF5; Mon, 4 Jan 2021 12:53:13 +0100 (CET) From: Nilo Massimo To: IPv6 List CC: Bob Hinden Subject: Re: Working Group Last Call for Thread-Topic: Re: Working Group Last Call for Thread-Index: Adbij2l0nYnfW1vIRB6rcYDngs0ofA== Date: Mon, 4 Jan 2021 11:53:13 +0000 Message-ID: <0e2e0cfefb4147dabdfb86a4014eb191@TELMBXC15BA020.telecomitalia.local> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.115.143.97] x-ti-disclaimer: ADBanner Content-Type: multipart/alternative; boundary="_000_0e2e0cfefb4147dabdfb86a4014eb191TELMBXC15BA020telecomit_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsXCFaUdqLuS8XO8wZyfBhZb3+9js3h59j2T A5PHzll32T2WLPnJFMAU1cBok5iXl1+SWJKqkJJanGyr5JJZnJyTmJmbWqTg6OIElEwtUlLI TLFVMlNSKMhJTE7NTc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+uhYWppa6 hkp2gaWpxSX5CrmpxcWJ6emZ+QoJ80QzGo7JFdyfwFjx+WkTYwPjqvouRk4OCQETiQkvfzB1 MXJxCAmsZJSYfW4lO0iCTcBI4vSKX6wgtoiArMSc5VOAbA4OZgFVid83wkDCwgIeEpu7/jFD lPhKPLvZxgJh60ksmN7JCGKzCKhItM4+wwzSyisQKDGlxwMkzAg0ccLuRWAlzALiEreezGeC OEdAYsme88wQtqjEy8f/WCFsA4mtS/exQNiKEqs/XYayJSUOH97EBjEnX+Ja1zWwOK+AoMTJ mU9YJjAKz0KyYhaSsllIyiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRtHcCgMLvZLU nNTk/NzMksSczES9zJJNjOBUoSuxg/HIxTd6hxiZOBgPMUpwMCuJ8FZc+BAvxJuSWFmVWpQf X1Sak1p8iNEHGEYTmaVEk/OBySqvJN7Q1MzU3NjIzNTA1MwSh7CSOC/Pn0/xQgLpwBSVnZpa kFoEM46Jg1OqgSnOwFI9RiRESzPZtz3gX8/i7Fc7PjUuTN1pvueO8qIJMz3cpu/1UbSr36LP Jz3T6c2RZ893reDuvZw+N/rQZYuP547WeviUvXjdzGkcLafUqjrt6aq5+ha/Kv0mTFly6ax5 82d2gaP+raqc046zMKs0MF7aGWao/nJVVM3C53zPS0x36hSZ7d2mnXxw8tILf7yLJT9/C+hW 4fpyJlBtjk+QxGXVWT84K/ZnGmQGPp28SmT/LfOYlfPzlpxonlue9bz7zNf27OMnb5swfeK2 36uTd7J2limvKW/wUQffI/yH3y5Y+eeg9LNZjZLlS7w/Jj3jmNolohBwauWzmrtbD1lFfy2L WzJtGZuBxVHjjgVKLMUZiYZazEXFiQCndEHJtQMAAA== Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 11:53:21 -0000 --_000_0e2e0cfefb4147dabdfb86a4014eb191TELMBXC15BA020telecomit_ Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I support its publication. Best Regards, Massimo ------------------------Original Message---------------------- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden Sent: Sunday, December 20, 2020 8:11 PM To: IPv6 List > Cc: Bob Hinden > Subject: Working Group Last Call for This message starts a new three week 6MAN Working Group Last Call on advanci= ng: Title : IPv6 Application of the Alternate Marking Method Authors : Giuseppe Fioccola Tianran Zhou Mauro Cociglio Fengwei Qin Ran Pang Filename : draft-ietf-6man-ipv6-alt-mark-02.txt Pages : 15 Date : 2020-10-13 as a Proposed Standard. We normally do two week last calls, but given the h= olidays, we think three weeks is appropriate. Substantive comments and statements of support for publishing this document= should be directed to the ipv6@ietf.org mailing list.= Editorial suggestions can be sent to the authors. This last call will end= on 10 January 2021. Thanks, Bob & Ole > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-6man-ipv6-alt-mark-02.txt > Date: October 13, 2020 at 7:10:42 AM PDT > To: > > Cc: ipv6@ietf.org > Reply-To: ipv6@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the IPv6 Maintenance WG of the IETF. > > Title : IPv6 Application of the Alternate Marking Method > Authors : Giuseppe Fioccola > Tianran Zhou > Mauro Cociglio > Fengwei Qin > Ran Pang > Filename : draft-ietf-6man-ipv6-alt-mark-02.txt > Pages : 15 > Date : 2020-10-13 > > Abstract: > This document describes how the Alternate Marking Method can be used > as the passive performance measurement tool in an IPv6 domain and > reports implementation considerations. It proposes how to define a > new Extension Header Option to encode alternate marking technique and > both Hop-by-Hop Options Header and Destination Options Header are > considered. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-6man-ipv6-alt-mark-02 > https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-ipv6-alt-mark-02 > > > 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/ Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. --_000_0e2e0cfefb4147dabdfb86a4014eb191TELMBXC15BA020telecomit_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I support its publication.

 

Best Regards,

Massimo

 

------------------------Origi= nal Message----------------------

From: ipv6 [mailto:ipv6-bounces@ietf= .org] On Behalf Of Bob Hinden

Sent: Sunday, December 20, 20= 20 8:11 PM

To: IPv6 List <ipv6@ietf.org>

Cc: Bob Hinden <bob.hinden@gmail.= com>

Subject: Working Group Last C= all for <draft-ietf-6man-ipv6-alt-mark>

 

This message starts a new thr= ee week 6MAN Working Group Last Call on advancing:

 

     = ;  Title           := IPv6 Application of the Alternate Marking Method

     = ;  Authors         : Giu= seppe Fioccola

        &n= bsp;            =     Tianran Zhou

        &n= bsp;            =     Mauro Cociglio

        &n= bsp;            =     Fengwei Qin

     = ;            &nb= sp;       Ran Pang

     = ;         Filename   =      : draft-ietf-6man-ipv6-alt-mark-02.txt

     = ;         Pages   &nb= sp;       : 15

     = ;         Date   &nbs= p;        : 2020-10-13<= /p>

 

as a Proposed Standard. = We normally do two week last calls, but given the holidays, we think three= weeks is appropriate.

 

Substantive comments and stat= ements of support for publishing this document should be directed to the ipv6@ietf.org mailing list.  Editorial suggestions can= be sent to the authors.  This last call will end on 10 January 2021.

 

Thanks,

Bob & Ole

 

 

> Begin forwarded message:=

>

> From: internet-drafts@ietf.o= rg

> Subject: I-D Action: dra= ft-ietf-6man-ipv6-alt-mark-02.txt

> Date: October 13, 2020 a= t 7:10:42 AM PDT

> To: <i-d-announce@ietf.org= >

> Cc: ipv6@ietf.org

> Reply-To: ipv6@ietf.org

>

>

> A New Internet-Draft is= available from the on-line Internet-Drafts directories.

> This draft is a work ite= m of the IPv6 Maintenance WG of the IETF.

>

>    &= nbsp;   Title         = ;  : IPv6 Application of the Alternate Marking Method=

>        Aut= hors         : Giuseppe Fioccola

>       &nbs= p;            &n= bsp;     Tianran Zhou

>       &nbs= p;            &n= bsp;     Mauro Cociglio

>    &= nbsp;            = ;         Fengwei Qin

>    &= nbsp;            = ;         Ran Pang=

>     =        Filename     &= nbsp;  : draft-ietf-6man-ipv6-alt-mark-02.txt

>     =        Pages     &nbs= p;     : 15

>     =        Date      = ;      : 2020-10-13

>

> Abstract:

>   This documen= t describes how the Alternate Marking Method can be used

>   as the passi= ve performance measurement tool in an IPv6 domain and

>   reports impl= ementation considerations.  It proposes how to define a

>   new Extensio= n Header Option to encode alternate marking technique and<= /p>

>   both Hop-by-= Hop Options Header and Destination Options Header are

>   considered.<= o:p>

>

>

> The IETF datatracker sta= tus page for this draft is:

> https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/

>

> There are also htmlized= versions available at:

> https://tools.ietf.org/html/draft-ietf-6man-ipv6-alt-mark-02

> https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-ma= rk-02

>

> A diff from the previous= version is available at:

> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-ipv6-alt-mark= -02

>

>

> Please note that it may= take a couple of minutes from the time of

> submission until the htm= lized version and diff are available at tools.ietf.org.

>

> Internet-Drafts are also= available by anonymous FTP at:

> ftp://ftp.ietf.org/inter= net-drafts/



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

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

Rispetta l'ambiente. Non stampare questa mail se non è necessa= rio.
--_000_0e2e0cfefb4147dabdfb86a4014eb191TELMBXC15BA020telecomit_-- From nobody Mon Jan 4 07:16:06 2021 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F433A0DEA; Mon, 4 Jan 2021 07:16:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, ipv6@ietf.org Subject: IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-6man-mtu-option X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160977336092.6519.7514718342579170806@ietfa.amsl.com> Date: Mon, 04 Jan 2021 07:16:00 -0800 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 15:16:01 -0000 Dear Bob Hinden, Gorry Fairhurst: An IPR disclosure that pertains to your Internet-Draft entitled "IPv6 Minimum Path MTU Hop-by-Hop Option" (draft-ietf-6man-mtu-option) was submitted to the IETF Secretariat on 2020-12-27 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4567/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-6man-mtu-option" Thank you IETF Secretariat From nobody Mon Jan 4 19:21:42 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19CA3A0DE7 for ; Mon, 4 Jan 2021 19:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.329 X-Spam-Level: X-Spam-Status: No, score=-1.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPwBAQSgiC6C for ; Mon, 4 Jan 2021 19:21:38 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 12FDA3A0DE9 for ; Mon, 4 Jan 2021 19:21:36 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.17]) by rmmx-syy-dmz-app11-12011 (RichMail) with SMTP id 2eeb5ff3db29f61-54a60; Tue, 05 Jan 2021 11:21:15 +0800 (CST) X-RM-TRANSID: 2eeb5ff3db29f61-54a60 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from CMCC-PC (unknown[223.69.29.179]) by rmsmtp-syy-appsvr09-12009 (RichMail) with SMTP id 2ee95ff3db221cd-14dfc; Tue, 05 Jan 2021 11:21:15 +0800 (CST) X-RM-TRANSID: 2ee95ff3db221cd-14dfc MIME-Version: 1.0 x-PcFlag: 9e148ebb-4e28-46f9-86fe-59970d8943aa_5_28656 X-Mailer: PC_RICHMAIL 2.8.4 Date: 05 Jan 2021 11:20:07 +0800 From: =?utf-8?B?WWlzb25nIExpdQ==?= To: =?utf-8?B?Qm9iIEhpbmRlbg==?=, =?utf-8?B?SVB2NiBMaXN0?= Cc: =?utf-8?B?Qm9iIEhpbmRlbg==?= Subject: =?utf-8?B?UkXvvJogV29ya2luZyBHcm91cCBMYXN0IENhbGwgZm9yIDxkcmFmdC1pZXRmLTZtYW4taXB2Ni1hbHQtbWFyaz4=?= Message-ID: 202101051120072386411223@chinamobile.com> Content-Type: multipart/Alternative; boundary="----=_001_NextPart-1908556073_=----" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 03:21:41 -0000 This is a multi-part message in MIME format. ------=_001_NextPart-1908556073_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQ1IaSBhbGwsDQ0NDQ1JIHN1cHBvcnQgdGhlIHB1YmxpY2F0aW9uIG9mIHRoaXMgZHJhZnQuDQ0N DQ1UaGFua3MNDVlpc29uZw0NDQ0NDQ0NDQ0gDQ0NDeWPkeS7tuS6ujogQm9iIEhpbmRlbg0N5pe2 6Ze0OiAyMDIwLzEyLzIxKOaYn+acn+S4gCkwMzoxMA0N5pS25Lu25Lq6OiBJUHY2IExpc3Q7DQ3m ioTpgIHkuro6IEJvYiBIaW5kZW47DQ3kuLvpopg6IFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZv ciBUaGlzIG1lc3NhZ2Ugc3RhcnRzIGEgbmV3IHRocmVlIHdlZWsgNk1BTiBXb3JraW5nIEdyb3Vw IExhc3QgQ2FsbCBvbg1hZHZhbmNpbmc6DQ0gICAgICAgVGl0bGUgICAgICAgICAgIDogSVB2NiBB cHBsaWNhdGlvbiBvZiB0aGUgQWx0ZXJuYXRlIE1hcmtpbmcgTWV0aG9kDSAgICAgICBBdXRob3Jz ICAgICAgICAgOiBHaXVzZXBwZSBGaW9jY29sYQ0gICAgICAgICAgICAgICAgICAgICAgICAgVGlh bnJhbiBaaG91DSAgICAgICAgICAgICAgICAgICAgICAgICBNYXVybyBDb2NpZ2xpbw0gICAgICAg ICAgICAgICAgICAgICAgICAgRmVuZ3dlaSBRaW4NICAgICAgICAgICAgICAgICAgICAgICAgIFJh biBQYW5nDSAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi02bWFuLWlwdjYtYWx0 LW1hcmstMDIudHh0DSAgICAgICAgUGFnZXMgICAgICAgICAgIDogMTUNICAgICAgICBEYXRlICAg ICAgICAgICAgOiAyMDIwLTEwLTEzDQ1hcyBhIFByb3Bvc2VkIFN0YW5kYXJkLiAgV2Ugbm9ybWFs bHkgZG8gdHdvIHdlZWsgbGFzdCBjYWxscywgYnV0IGdpdmVuIHRoZQ1ob2xpZGF5cywgd2UgdGhp bmsgdGhyZWUgd2Vla3MgaXMgYXBwcm9wcmlhdGUuDQ1TdWJzdGFudGl2ZSBjb21tZW50cyBhbmQg c3RhdGVtZW50cyBvZiBzdXBwb3J0IGZvciBwdWJsaXNoaW5nIHRoaXMgZG9jdW1lbnQNc2hvdWxk IGJlIGRpcmVjdGVkIHRvIHRoZSBpcHY2QGlldGYub3JnIG1haWxpbmcgbGlzdC4gIEVkaXRvcmlh bCBzdWdnZXN0aW9ucw1jYW4gYmUgc2VudCB0byB0aGUgYXV0aG9ycy4gIFRoaXMgbGFzdCBjYWxs IHdpbGwgZW5kIG9uIDEwIEphbnVhcnkgMjAyMS4NDVRoYW5rcywNQm9iICZhbXA7IE9sZQ0NDQ0+ IEJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0+DT4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnDT4gU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi02bWFuLWlwdjYtYWx0LW1hcmst MDIudHh0DT4gRGF0ZTogT2N0b2JlciAxMywgMjAyMCBhdCA3OjEwOjQyIEFNIFBEVA0+IFRvOiA8 aS1kLWFubm91bmNlQGlldGYub3JnPg0+IENjOiBpcHY2QGlldGYub3JnDT4gUmVwbHktVG86IGlw djZAaWV0Zi5vcmcNPg0+DT4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g dGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDWRpcmVjdG9yaWVzLg0+IFRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgTWFpbnRlbmFuY2UgV0cgb2YgdGhlIElFVEYuDT4NPiAg ICAgICAgVGl0bGUgICAgICAgICAgIDogSVB2NiBBcHBsaWNhdGlvbiBvZiB0aGUgQWx0ZXJuYXRl IE1hcmtpbmcgTWV0aG9kDT4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IEdpdXNlcHBlIEZpb2Nj b2xhDT4gICAgICAgICAgICAgICAgICAgICAgICAgIFRpYW5yYW4gWmhvdQ0+ICAgICAgICAgICAg ICAgICAgICAgICAgICBNYXVybyBDb2NpZ2xpbw0+ICAgICAgICAgICAgICAgICAgICAgICAgICBG ZW5nd2VpIFFpbg0+ICAgICAgICAgICAgICAgICAgICAgICAgICBSYW4gUGFuZw0+ICAgICAgIEZp bGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtNm1hbi1pcHY2LWFsdC1tYXJrLTAyLnR4dA0+ICAg ICAgIFBhZ2VzICAgICAgICAgICA6IDE1DT4gICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAyMC0x MC0xMw0+DT4gQWJzdHJhY3Q6DT4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdGhlIEFs dGVybmF0ZSBNYXJraW5nIE1ldGhvZCBjYW4gYmUgdXNlZA0+ICAgYXMgdGhlIHBhc3NpdmUgcGVy Zm9ybWFuY2UgbWVhc3VyZW1lbnQgdG9vbCBpbiBhbiBJUHY2IGRvbWFpbiBhbmQNPiAgIHJlcG9y dHMgaW1wbGVtZW50YXRpb24gY29uc2lkZXJhdGlvbnMuICBJdCBwcm9wb3NlcyBob3cgdG8gZGVm aW5lIGENPiAgIG5ldyBFeHRlbnNpb24gSGVhZGVyIE9wdGlvbiB0byBlbmNvZGUgYWx0ZXJuYXRl IG1hcmtpbmcgdGVjaG5pcXVlIGFuZA0+ICAgYm90aCBIb3AtYnktSG9wIE9wdGlvbnMgSGVhZGVy IGFuZCBEZXN0aW5hdGlvbiBPcHRpb25zIEhlYWRlciBhcmUNPiAgIGNvbnNpZGVyZWQuDT4NPg0+ DT4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DT4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi02bWFuLWlwdjYtYWx0 LW1hcmsvDT4NPiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6 DT4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1pcHY2LWFsdC1t YXJrLTAyDT4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LTZtYW4taXB2Ni1hbHQtbWFyay0wMg0+DT4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNp b24gaXMgYXZhaWxhYmxlIGF0Og0+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLTZtYW4taXB2Ni1hbHQtbWFyay0wMg0+DT4NPiBQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg1zdWJtaXNzaW9u DT4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NPg0+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDoNPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0+ DQ== ------=_001_NextPart-1908556073_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi=20all,
<= div=20class=3D=22rich_html_content=22=20style=3D=22color:=23000000;=20font-= Size:12pt;=20font-family:=E5=BE=AE=E8=BD=AF=E9=9B=85=E9=BB=91;=20word-wrap:= break-word;x-overflow:hidden;=22>
I=20support=20the=20publication=20of=20this=20draft.
Thanks<= /div>Yisong
=
 
=E5=8F=91=E4=BB=B6=E4=BA=BA:=20Bob=20Hinden=E6= =97=B6=E9=97=B4:=202020/12/21(=E6=98=9F=E6=9C=9F=E4=B8=80)03:10=E6=94=B6=E4=BB=B6=E4=BA=BA:=20IPv6=20List;=E6=8A=84=E9=80=81=E4=BA=BA:=20Bob=20Hinden;= =E4=B8=BB=E9=A2=98:=20Working=20Group=20Last=20Call=20for=20
Th= is=20message=20starts=20a=20new=20three=20week=206MAN=20Working=20Group=20L= ast=20Call=20on
advancing:

=20=20=20=20=20=20=20Title=20=20=20=20= =20=20=20=20=20=20=20:=20IPv6=20Application=20of=20the=20Alternate=20Markin= g=20Method
=20=20=20=20=20=20=20Authors=20=20=20=20=20=20=20=20=20:=20Gi= useppe=20Fioccola
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20Tianran=20Zhou
=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20Mauro=20Cociglio
=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Fengwei=20Qin=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20Ran=20Pang
=20=20=20=20=20=20=20=20Filename=20=20=20=20=20=20=20=20:= =20draft-ietf-6man-ipv6-alt-mark-02.txt
=20=20=20=20=20=20=20=20Pages=20= =20=20=20=20=20=20=20=20=20=20:=2015
=20=20=20=20=20=20=20=20Date=20=20= =20=20=20=20=20=20=20=20=20=20:=202020-10-13

as=20a=20Proposed=20Sta= ndard.=20=20We=20normally=20do=20two=20week=20last=20calls,=20but=20given= =20the
holidays,=20we=20think=20three=20weeks=20is=20appropriate.
Substantive=20comments=20and=20statements=20of=20support=20for=20publishin= g=20this=20document
should=20be=20directed=20to=20the=20ipv6=40ietf.org= =20mailing=20list.=20=20Editorial=20suggestions
can=20be=20sent=20to=20t= he=20authors.=20=20This=20last=20call=20will=20end=20on=2010=20January=2020= 21.

Thanks,
Bob=20&=20Ole



>=20Begin=20forwa= rded=20message:
>
>=20From:=20internet-drafts=40ietf.org
>= ;=20Subject:=20I-D=20Action:=20draft-ietf-6man-ipv6-alt-mark-02.txt
>= =20Date:=20October=2013,=202020=20at=207:10:42=20AM=20PDT
>=20To:=20&= lt;i-d-announce=40ietf.org>
>=20Cc:=20ipv6=40ietf.org
>=20Re= ply-To:=20ipv6=40ietf.org
>
>
>=20A=20New=20Internet-Draf= t=20is=20available=20from=20the=20on-line=20Internet-Drafts
directories.=
>=20This=20draft=20is=20a=20work=20item=20of=20the=20IPv6=20Maintena= nce=20WG=20of=20the=20IETF.
>
>=20=20=20=20=20=20=20=20Title=20= =20=20=20=20=20=20=20=20=20=20:=20IPv6=20Application=20of=20the=20Alternate= =20Marking=20Method
>=20=20=20=20=20=20=20=20Authors=20=20=20=20=20= =20=20=20=20:=20Giuseppe=20Fioccola
>=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Tianran=20Zhou
>=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= Mauro=20Cociglio
>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20Fengwei=20Qin
>=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Ran=20Pang
>=20=20= =20=20=20=20=20Filename=20=20=20=20=20=20=20=20:=20draft-ietf-6man-ipv6-alt= -mark-02.txt
>=20=20=20=20=20=20=20Pages=20=20=20=20=20=20=20=20=20= =20=20:=2015
>=20=20=20=20=20=20=20Date=20=20=20=20=20=20=20=20=20=20= =20=20:=202020-10-13
>
>=20Abstract:
>=20=20=20This=20doc= ument=20describes=20how=20the=20Alternate=20Marking=20Method=20can=20be=20u= sed
>=20=20=20as=20the=20passive=20performance=20measurement=20tool= =20in=20an=20IPv6=20domain=20and
>=20=20=20reports=20implementation= =20considerations.=20=20It=20proposes=20how=20to=20define=20a
>=20=20= =20new=20Extension=20Header=20Option=20to=20encode=20alternate=20marking=20= technique=20and
>=20=20=20both=20Hop-by-Hop=20Options=20Header=20and= =20Destination=20Options=20Header=20are
>=20=20=20considered.
>=
>
>
>=20The=20IETF=20datatracker=20status=20page=20for= =20this=20draft=20is:
>=20https://datatracker.ietf.org/doc/draft-ietf= -6man-ipv6-alt-mark/
>
>=20There=20are=20also=20htmlized=20vers= ions=20available=20at:
>=20https://tools.ietf.org/html/draft-ietf-6ma= n-ipv6-alt-mark-02
>=20https://datatracker.ietf.org/doc/html/draft-ie= tf-6man-ipv6-alt-mark-02
>
>=20A=20diff=20from=20the=20previous= =20version=20is=20available=20at:
>=20https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-6man-ipv6-alt-mark-02
>
>
>=20Please=20no= te=20that=20it=20may=20take=20a=20couple=20of=20minutes=20from=20the=20time= =20of
submission
>=20until=20the=20htmlized=20version=20and=20diff= =20are=20available=20at=20tools.ietf.org.
>
>=20Internet-Drafts= =20are=20also=20available=20by=20anonymous=20FTP=20at:
>=20ftp://ftp.= ietf.org/internet-drafts/
>
=0A ------=_001_NextPart-1908556073_=------ From nobody Mon Jan 4 19:38:13 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B789C3A0E1B for ; Mon, 4 Jan 2021 19:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Na1FaZ7XGbX for ; Mon, 4 Jan 2021 19:38:09 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id CA95C3A0E10 for ; Mon, 4 Jan 2021 19:38:08 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.19]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee65ff3df159f3-554b1; Tue, 05 Jan 2021 11:37:57 +0800 (CST) X-RM-TRANSID: 2ee65ff3df159f3-554b1 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.50.166]) by rmsmtp-syy-appsvr10-12010 (RichMail) with SMTP id 2eea5ff3df145f7-1280a; Tue, 05 Jan 2021 11:37:57 +0800 (CST) X-RM-TRANSID: 2eea5ff3df145f7-1280a From: "Weiqiang Cheng" To: "'Bob Hinden'" , "'IPv6 List'" Cc: "'Bob Hinden'" References: 202101051120072386411223@chinamobile.com> In-Reply-To: 202101051120072386411223@chinamobile.com> Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D:_RE=EF=BC=9A_Working_Group_Last_Call_?= =?UTF-8?Q?for_=3Cdraft-ietf-6man-ipv6-alt-ma?= =?UTF-8?Q?rk=3E?= Date: Tue, 5 Jan 2021 11:38:03 +0800 Message-ID: <020a01d6e314$2cef2710$86cd7530$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020B_01D6E357.3B126710" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdbjEe3x6OVmhs5tQ1uvdcVT28LP1QAAh9ZQ Content-Language: zh-cn Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 03:38:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_020B_01D6E357.3B126710 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support the publication of this draft. Weiqiang =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Bob Hinden =20 =E6=97=B6=E9=97=B4: 2020/12/21(=E6=98=9F=E6=9C=9F=E4=B8=80)03:10 =E6=94=B6=E4=BB=B6=E4=BA=BA: IPv6 List ; =E6=8A=84=E9=80=81=E4=BA=BA: Bob Hinden ; =E4=B8=BB=E9=A2=98: Working Group Last Call for=20 This message starts a new three week 6MAN Working Group Last Call on advancing: Title : IPv6 Application of the Alternate Marking Method Authors : Giuseppe Fioccola Tianran Zhou Mauro Cociglio Fengwei Qin Ran Pang Filename : draft-ietf-6man-ipv6-alt-mark-02.txt Pages : 15 Date : 2020-10-13 as a Proposed Standard. We normally do two week last calls, but given = the holidays, we think three weeks is appropriate. Substantive comments and statements of support for publishing this = document should be directed to the ipv6@ietf.org mailing list. Editorial = suggestions can be sent to the authors. This last call will end on 10 January 2021. Thanks, Bob & Ole > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-6man-ipv6-alt-mark-02.txt > Date: October 13, 2020 at 7:10:42 AM PDT > To: > Cc: ipv6@ietf.org > Reply-To: ipv6@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Maintenance WG of the IETF. > > Title : IPv6 Application of the Alternate Marking Method > Authors : Giuseppe Fioccola > Tianran Zhou > Mauro Cociglio > Fengwei Qin > Ran Pang > Filename : draft-ietf-6man-ipv6-alt-mark-02.txt > Pages : 15 > Date : 2020-10-13 > > Abstract: > This document describes how the Alternate Marking Method can be used > as the passive performance measurement tool in an IPv6 domain and > reports implementation considerations. It proposes how to define a > new Extension Header Option to encode alternate marking technique and > both Hop-by-Hop Options Header and Destination Options Header are > considered. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-6man-ipv6-alt-mark-02 > https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-ipv6-alt-mark-02 > > > 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/ > ------=_NextPart_000_020B_01D6E357.3B126710 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I support the publication of this = draft.

Weiqiang

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: Bob = Hinden

=E6=97=B6=E9=97=B4: = 2020/12/21(=E6=98=9F=E6=9C=9F=E4=B8=80)03:10

=E6=94=B6=E4=BB=B6=E4=BA=BA: IPv6 = List;

=E6=8A=84=E9=80=81=E4=BA=BA: Bob = Hinden;

=E4=B8=BB=E9=A2=98: Working Group Last = Call for

This message starts a new three = week 6MAN Working Group Last Call on
advancing:

Title : IPv6 = Application of the Alternate Marking Method
Authors : Giuseppe = Fioccola
Tianran Zhou
Mauro Cociglio
Fengwei Qin
Ran = Pang
Filename : draft-ietf-6man-ipv6-alt-mark-02.txt
Pages : = 15
Date : 2020-10-13

as a Proposed Standard. We normally do = two week last calls, but given the
holidays, we think three weeks is = appropriate.

Substantive comments and statements of support for = publishing this document
should be directed to the ipv6@ietf.org = mailing list. Editorial suggestions
can be sent to the authors. This = last call will end on 10 January 2021.

Thanks,
Bob & = Ole



> Begin forwarded message:
>
> From: = internet-drafts@ietf.org
> Subject: I-D Action: = draft-ietf-6man-ipv6-alt-mark-02.txt
> Date: October 13, 2020 at = 7:10:42 AM PDT
> To: <i-d-announce@ietf.org>
> Cc: = ipv6@ietf.org
> Reply-To: ipv6@ietf.org
>
>
> A = New Internet-Draft is available from the on-line = Internet-Drafts
directories.
> This draft is a work item of the = IPv6 Maintenance WG of the IETF.
>
> Title : IPv6 = Application of the Alternate Marking Method
> Authors : Giuseppe = Fioccola
> Tianran Zhou
> Mauro Cociglio
> Fengwei = Qin
> Ran Pang
> Filename : = draft-ietf-6man-ipv6-alt-mark-02.txt
> Pages : 15
> Date : = 2020-10-13
>
> Abstract:
> This document describes how = the Alternate Marking Method can be used
> as the passive = performance measurement tool in an IPv6 domain and
> reports = implementation considerations. It proposes how to define a
> new = Extension Header Option to encode alternate marking technique = and
> both Hop-by-Hop Options Header and Destination Options = Header are
> considered.
>
>
>
> The IETF = datatracker status page for this draft is:
> = https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/
>> There are also htmlized versions available at:
> = https://tools.ietf.org/html/draft-ietf-6man-ipv6-alt-mark-02
> = https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-02>
> A diff from the previous version is available at:
> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-ipv6-alt-mark-02
&= gt;
>
> 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/
>

------=_NextPart_000_020B_01D6E357.3B126710-- From nobody Mon Jan 4 23:47:47 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209A23A0AD4 for ; Mon, 4 Jan 2021 23:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, MSGID_FROM_MTA_HEADER=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pUoClIjoAsX for ; Mon, 4 Jan 2021 23:47:44 -0800 (PST) Received: from smtpbg.qq.com (smtpbg515.qq.com [203.205.250.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E273A0AA7 for ; Mon, 4 Jan 2021 23:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1609832857; bh=vkysFO0+N0ceZcXrj8ZEBXOKPONSY9ME2bpxQXyaCx8=; h=From:To:Subject:Mime-Version:Date:Message-ID; b=aR8cOtA8ZXZmw+cLtVpKtVmR4Y7uZs6jLRGiHxIKkXxF83QOd1IOwCFVM80X0OmIU ngTwIz9mDsrLpsu+8Lc1P2EjIuUSG3G0v6NwL8rSL+bB5zIUjIgl8mYACtD+e+e9Hf KKe278gHN24tsg859H3hmDwgVEnI25Yob2xkBCMs= X-QQ-FEAT: 7+ajplIYo77davFyywEoUGYYEF+ZKZo3RNFaCXtjuTpXVzp8nP68ElLj0v2bv JkbrFpIPlwujZlqUjADjTls8s5jJZPBPiN5xnKjaU7jdRMi0WW9/Awv9MyAQUgXja0ttAMe af5GHFcrnQ6BnLBbns7gq5gPN45TovftHpwMTcLJwhSpIcqfc+sSbgSYY8WAMc24WvIqvzh YSmCDgcDJvNifNPUQPo/QWMlAb9kaZ/I0w56wglcTzoOND64WUtk0Ptgf3mNXRU7gLo3DwY 2P73l5fjk2REMb X-QQ-SSF: 0000000000000090 X-QQ-XMAILINFO: MgAhjl/AmVEuinWjKLFM+r8L0T/I/cgOfXblVucS4sz5yp9IDUL6Afqp65Htof x3BsydPCGQyBqC/O1MVITjpk2MApvlJBd+ceTwXK0QtnPSC4VrrNTO25qi6cXQbSHEFoW9WCbtMlR SMWPRCY7NR9dLDXjjnEbwFGGSGDoYWAU/O96MTaDOcw4zcI9/CLgHMFQNuslKMjRbnt8JGVdMgc5E mxKLnflg6OymuPo5RDHqPH0HSxrAmIrd+aWeVOvdri+61Iqb4yjV1i2qGFcSspm1r0XPqoXXGcddE 4/9OWcmYrWyb5R86rN1NWdQT/Hevmyz7qlE5fN4WSzwiTeiNcWHmP4fYnn6OWDjHImPW0/rhxZvuD dni2RwLXnA7ikvZTUxtDTKpU7zEL38/lleon0Ub/A+89kar9WNMzLqRhgRroqI+wCF3kscFQtX+oL 2SBmXoa4tdAeLRN7koDZqyYuprJf27PB6i9ypGs6Nz0v7i1CYaYgumWY2H7d1kCCf13YvZrt90zrA ZbWpqm1nl9iPnmHc1XIMQjsvyXlnZQtIv2/DePY9vNGASB2THAVEsAWvSSvUrblCNq8FLJWA7Th0X CFYVAseY9kenIPn5LwStw75oJ3VgaxoRnpp7N9mf/mHXDvm4WP6hg/k1s9pjOS4Y33csU0tuJuDdZ nuKzYc5//WhE/XmU+gxqDPAZHVLP8n9A5DeOp64w2iF1zwyfHah0lP0hrlDm74HGhr5XTGEpXe3Nt 1mq8FD02abEQChDGU04O6PWT6c+wJoiARZweJCcc9dOHnKSuVb+4lQUxH X-QQ-WAPMAIL: 1 X-QQ-BUSINESS-ORIGIN: 2 X-Originating-IP: 106.38.249.249 X-QQ-STYLE: X-QQ-mid: wapmail70t1609832855t6051399 From: "=?gb18030?B?Q2hvbmdmZW5n?=" To: "=?gb18030?B?WWlzb25nJmFtcDtuYnNwO0xpdQ==?=" , "=?gb18030?B?Qm9iJm5ic3A7SGluZGVu?=" , "=?gb18030?B?SVB2NiZuYnNwO0xpc3Q=?=" Cc: "=?gb18030?B?Qm9iJm5ic3A7SGluZGVu?=" Subject: =?gb18030?B?u9i4tKO6UkWjuiBXb3JraW5nIEdyb3VwIExhc3Qg?= =?gb18030?B?Q2FsbCBmb3IgPGRyYWZ0LWlldGYtNm1hbi1pcHY2?= =?gb18030?B?LWFsdC1tYXJrPg==?= Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_5FF41996_112C5E78_42A976A0" Content-Transfer-Encoding: 8Bit Date: Tue, 5 Jan 2021 15:47:34 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-QQ-SENDSIZE: 520 Received: from qq.com (unknown [127.0.0.1]) by smtp.qq.com (ESMTP) with SMTP id ; Tue, 05 Jan 2021 15:47:36 +0800 (CST) Feedback-ID: wapmail:foxmail.com:bgweb:bgweb4 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 07:47:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_5FF41996_112C5E78_42A976A0 Content-Type: text/plain; charset="gb18030" Content-Transfer-Encoding: base64 U3VwcG9ydCBhZG9wdGlvbiArMSBDaG9uZ2ZlbmcgLS0tLS0tLS0tLS0tLS0tLS0tJm5ic3A7 1K3KvNPKvP4mbmJzcDstLS0tLS0tLS0tLS0tLS0tLS0NCreivP7IyzombmJzcDsmcXVvdDtZ aXNvbmcmYW1wO25ic3A7TGl1JnF1b3Q7PGxpdXlpc29uZ0BjaGluYW1vYmlsZS5jb20mZ3Q7 DQq3osvNyrG85DombmJzcDsyMDIxxOox1MI1yNUo0MfG2rb+KSDW0M7nMTE6MjANCsrVvP7I yzombmJzcDsmcXVvdDtCb2IgSGluZGVuJnF1b3Q7PGJvYi5oaW5kZW5AZ21haWwuY29tJmd0 OzsmcXVvdDtJUHY2IExpc3QmcXVvdDs8aXB2NkBpZXRmLm9yZyZndDs7DQqzrcvNOiZuYnNw OyZxdW90O0JvYiBIaW5kZW4mcXVvdDs8Ym9iLmhpbmRlbkBnbWFpbC5jb20mZ3Q7Ow0K1vfM 4jombmJzcDtSRaO6IFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciA8ZHJhZnQtaWV0Zi02 bWFuLWlwdjYtYWx0LW1hcmsmZ3Q7 ------=_NextPart_5FF41996_112C5E78_42A976A0 Content-Type: text/html; charset="gb18030" Content-Transfer-Encoding: base64 U3VwcG9ydCBhZG9wdGlvbiArMQpDaG9uZ2ZlbmcKCgo8RElWIHN0eWxlPSJDT0xPUjogIzAw MCI+PERJViBzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDBweDsg Rk9OVC1TSVpFOiAxMnB4OyBQQURESU5HLUJPVFRPTTogMnB4OyBQQURESU5HLVRPUDogMnB4 OyBGT05ULUZBTUlMWTogQXJpYWwgTmFycm93Ij4tLS0tLS0tLS0tLS0tLS0tLS0mbmJzcDvU rcq808q8/iZuYnNwOy0tLS0tLS0tLS0tLS0tLS0tLTwvRElWPjxESVYgc3R5bGU9IlBBRERJ TkctUklHSFQ6IDhweDsgUEFERElORy1MRUZUOiA4cHg7IEZPTlQtU0laRTogMTJweDsgQkFD S0dST1VORDogI2VmZWZlZjsgUEFERElORy1CT1RUT006IDhweDsgUEFERElORy1UT1A6IDhw eCI+PERJVj48Qj63orz+yMs6PC9CPiZuYnNwOyZxdW90O1lpc29uZyZhbXA7bmJzcDtMaXUm cXVvdDsmbHQ7bGl1eWlzb25nQGNoaW5hbW9iaWxlLmNvbSZndDs8d2JyLz48L0RJVj48RElW PjxCPreiy83KsbzkOjwvQj4mbmJzcDsyMDIxxOox1MI1yNUo0MfG2rb+KSDW0M7nMTE6MjA8 L0RJVj48RElWPjxCPsrVvP7Iyzo8L0I+Jm5ic3A7JnF1b3Q7Qm9iIEhpbmRlbiZxdW90OyZs dDtib2IuaGluZGVuQGdtYWlsLmNvbSZndDs7JnF1b3Q7SVB2NiBMaXN0JnF1b3Q7Jmx0O2lw djZAaWV0Zi5vcmcmZ3Q7OzwvRElWPjxESVY+PEI+s63LzTo8L0I+Jm5ic3A7JnF1b3Q7Qm9i IEhpbmRlbiZxdW90OyZsdDtib2IuaGluZGVuQGdtYWlsLmNvbSZndDs7PC9ESVY+PERJVj48 Qj7W98ziOjwvQj4mbmJzcDtSRaO6IFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciAmbHQ7 ZHJhZnQtaWV0Zi02bWFuLWlwdjYtYWx0LW1hcmsmZ3Q7PC9ESVY+PC9ESVY+PC9ESVY+ ------=_NextPart_5FF41996_112C5E78_42A976A0-- From nobody Tue Jan 5 17:21:27 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AD03A108E; Tue, 5 Jan 2021 17:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bnZu7Xtp6RO; Tue, 5 Jan 2021 17:21:17 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A96D3A0FB3; Tue, 5 Jan 2021 17:21:13 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B48A8284516; Wed, 6 Jan 2021 01:21:06 +0000 (UTC) Subject: Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> To: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations From: Fernando Gont X-Forwarded-Message-Id: <160989494094.6024.7402128068704112703@ietfa.amsl.com> Message-ID: <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> Date: Tue, 5 Jan 2021 22:20:55 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <160989494094.6024.7402128068704112703@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 01:21:22 -0000 Folks, Based on the recent discussion on the v6ops list (https://mailarchive.ietf.org/arch/msg/v6ops/b7r35HgOb-6dfxsDoW8c4FtGnZo//), I've posted this new I-D, meant to discuss the scope of ULAs: Title: "Scope of Unique Local IPv6 Unicast Addresses" I-D: https://tools.ietf.org/id/draft-gont-6man-ipv6-ula-scope-00.txt Short version of the story: ULAs are formally part of the GUA space. However, the characteristics of ULAs do not seem to match the definition of global scope from RFC4007 (IPv6 Scope Addr Architecture). ULA seem to have a scope of scope(link-local) < scope(ULA) < scope(GUA). This is not only a terminology thing (which I think is nevertheless important to get right) but also has practical implications. For example, there's a python library that considers ULAs as "not global", and "private" -- contradicting the current RFC4291/RFC4193 specs. Prior to posting this document, we had some on-list discussion (on the v6ops list) and also some off-list discussion with some of you (bcc'ed). The opinions have been in one of these camps: 1) the current specs are coherent and there's no problem 2) There's a problem with the definition of "global scope" -- so ULAs *are* global scope, but global scope does not really stand for the definition in RFC4007. 3) The definitions in RFC4007 are correct, and thus the scope of ULAs is not really global, but scopee(link-local) < scope(ULAs) < scope(global) While this document does propose a way out (it assumes #3 above, and acts accordingly), I believe the first step is to agree on what "global scope" means and, subsequently, whether ULAs are really "global scope" or not. Since opinions on the topic have vary a lot (as noted above), I've posted this I-D and I'm sending this note for further input from the WG. Thanks! Regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt Date: Tue, 05 Jan 2021 17:02:20 -0800 From: internet-drafts@ietf.org To: Fernando Gont A new version of I-D, draft-gont-6man-ipv6-ula-scope-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-6man-ipv6-ula-scope Revision: 00 Title: Scope of Unique Local IPv6 Unicast Addresses Document date: 2021-01-05 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-gont-6man-ipv6-ula-scope-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-6man-ipv6-ula-scope/ Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-6man-ipv6-ula-scope Htmlized: https://tools.ietf.org/html/draft-gont-6man-ipv6-ula-scope-00 Abstract: Unique Local IPv6 Unicast Addresses (ULAs) are formally part of the IPv6 Global Unicast address space. However, the semantics of ULAs clearly contradict the definition of "global scope". This document discusses the why the terminology employed for the specification of ULAs is problematic, along with some practical consequences of the current specification of ULAs. Finally, it formally updates RFC4291 and RFC4193 such that the scope of ULAs is defined as "local". 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. The IETF Secretariat From nobody Tue Jan 5 18:01:10 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278643A0D2A; Tue, 5 Jan 2021 18:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y16jCpfkva-F; Tue, 5 Jan 2021 18:01:05 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7EC3A0D05; Tue, 5 Jan 2021 18:01:04 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id b24so1736552otj.0; Tue, 05 Jan 2021 18:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e4jNDger57+idXBpKrmMk9dDH+WVc4CyfDfylyy4sug=; b=BQKN9NXIyYRfowfpSyBWnB/ohkc3fPsZ3xjqyDTw683Ihcuveo0SaApAIwCZybUSEw cMbp+oN/k0zP+9aU9WpEJwqXz0i15gWBSWWHwfMk0+/U0mWVgiZPdKm/GwVuVjiAuVIR Z80guenFHgQkEIuu4oB8it3wvGcVtYd36jUhmh5XFXSttTWQ5Iu+CAELoaeH7oCz3xA4 JSUnQQAVR3I2czWH9sDzswuqH/SpEfDc7IJlYBDRp2FYPEao9i1DgRrDLWXXseP4o581 vp7W2zeWCMFZEJn6iyqYNjsoU5kOQaRW7zEKbPWPEGTc5q8ERcFcj8PJyjVWv7LAT5HY 85Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e4jNDger57+idXBpKrmMk9dDH+WVc4CyfDfylyy4sug=; b=Rjt+ThZ2YcYyIcJ+yP39R/exsoNmAa7mGjJG7RolSXQHa3ySDAKDkzO0WTptnumCL8 BTWcUZJjm0LvNMEErRJwM7Fe+D9BRP1ljRwahsnbGNTOuKwek1CEwnyRTN+d9W4sGtJe tUzCKoW54HyGNwE2ktAMjlmpnb8IMVt5mvlFrVvUBQhRF2IN1vnjMX2KmdOuq5mJDwuA LHW0MLTrXwQuj9IWgZJARx6xqUdApKXxe6UlJrsBUdXFu3lyPy9zH1w6oDWSjufO2KWT Oask+2837ssVBVv2gGdaGI2/ahMNkjAuYslGfAzOZDtydJURQpdPnAoAwlqZdLt/pUgD fM0w== X-Gm-Message-State: AOAM533u6dl1JIKCjZ6+SbL9/XwELyEFqM5NOqt6MwFtxz3qoreheTWP CoR4I/SyvHC9WtZg8vrQd+6W92tstFwYMeMU8BA3ZquqD8c= X-Google-Smtp-Source: ABdhPJxt0J/YTR1O6MDJhBVf4VyZ1drSlq6xj6jnuf/HH8KCcakN++ZC7ZebtIrOcgALUG24d66cKNQa9j5P6lHlLIM= X-Received: by 2002:a05:6830:1517:: with SMTP id k23mr1740995otp.348.1609898464162; Tue, 05 Jan 2021 18:01:04 -0800 (PST) MIME-Version: 1.0 References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> In-Reply-To: <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> From: Mark Smith Date: Wed, 6 Jan 2021 13:00:36 +1100 Message-ID: Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Fernando Gont Cc: 6MAN <6man@ietf.org>, IPv6 Operations Content-Type: multipart/alternative; boundary="00000000000014b8c605b831b23b" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 02:01:09 -0000 --00000000000014b8c605b831b23b Content-Type: text/plain; charset="UTF-8" On Wed, 6 Jan 2021, 12:21 Fernando Gont, wrote: > Folks, > > Based on the recent discussion on the v6ops list > (https://mailarchive.ietf.org/arch/msg/v6ops/b7r35HgOb-6dfxsDoW8c4FtGnZo//), > > I've posted this new I-D, meant to discuss the scope of ULAs: > > Title: "Scope of Unique Local IPv6 Unicast Addresses" > I-D: https://tools.ietf.org/id/draft-gont-6man-ipv6-ula-scope-00.txt > > > Short version of the story: > > ULAs are formally part of the GUA space. However, the characteristics of > ULAs do not seem to match the definition of global scope from RFC4007 > (IPv6 Scope Addr Architecture). ULA seem to have a scope of > scope(link-local) < scope(ULA) < scope(GUA). > > This is not only a terminology thing (which I think is nevertheless > important to get right) but also has practical implications. For > example, there's a python library that considers ULAs as "not global", > and "private" -- contradicting the current RFC4291/RFC4193 specs. > > Prior to posting this document, we had some on-list discussion (on the > v6ops list) and also some off-list discussion with some of you (bcc'ed). > > The opinions have been in one of these camps: > > 1) the current specs are coherent and there's no problem > > 2) There's a problem with the definition of "global scope" -- so ULAs > *are* global scope, but global scope does not really stand for the > definition in RFC4007. > 3) The definitions in RFC4007 are correct, and thus the scope of ULAs is > not really global, but scopee(link-local) < scope(ULAs) < scope(global) > The thing that is really missing from "global scope" is what scope or domain is being described? Forwarding scope? Uniqueness scope? Some other scope (DNS visibility is probably another one). All of them? ULAs are intended to be globally unique addresses, but not to be globally (Internet) forwardable. Their forwarding scope is limited to non-global, either within a single local network, or between a set of local networks that have agreed to forward their respective ULA /48 prefixes between each other, overriding the default of local networks only forwarding scope. (Ethernet addresses are a similar example, globally unique addresses, link only forwarding scope.) GUAs also are intended to be globally unique addresses, but are intended to be globally (Internet) forwardable. There isn't really a ULA equivalent in IPv4, although I think a lot of the arguments in RFC1627, "Network 10 Considered Harmful (Some Practices Shouldn't be Codified)" would have been arguments for one e.g, "The lesson that we learned was that every IP address ought to be globally unique, independent of its attachment to the Internet." (There is a statement about effectively everything attached to the Internet too, however that's 1994 Internet naivety, before DDoSes and Internet wide scanning for and exploiting of vulnerabilities were much of a thing.) Regards, Mark. > > While this document does propose a way out (it assumes #3 above, and > acts accordingly), I believe the first step is to agree on what "global > scope" means and, subsequently, whether ULAs are really "global scope" > or not. Since opinions on the topic have vary a lot (as noted above), > I've posted this I-D and I'm sending this note for further input from > the WG. > > Thanks! > > Regards, > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt > Date: Tue, 05 Jan 2021 17:02:20 -0800 > From: internet-drafts@ietf.org > To: Fernando Gont > > > A new version of I-D, draft-gont-6man-ipv6-ula-scope-00.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-6man-ipv6-ula-scope > Revision: 00 > Title: Scope of Unique Local IPv6 Unicast Addresses > Document date: 2021-01-05 > Group: Individual Submission > Pages: 8 > URL: > https://www.ietf.org/archive/id/draft-gont-6man-ipv6-ula-scope-00.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-6man-ipv6-ula-scope/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-gont-6man-ipv6-ula-scope > Htmlized: > https://tools.ietf.org/html/draft-gont-6man-ipv6-ula-scope-00 > > > Abstract: > Unique Local IPv6 Unicast Addresses (ULAs) are formally part of the > IPv6 Global Unicast address space. However, the semantics of ULAs > clearly contradict the definition of "global scope". This document > discusses the why the terminology employed for the specification of > ULAs is problematic, along with some practical consequences of the > current specification of ULAs. Finally, it formally updates RFC4291 > and RFC4193 such that the scope of ULAs is defined as "local". > > > > > 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. > > The IETF Secretariat > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000014b8c605b831b23b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 6 Jan 2021, 12:21 Fernando Go= nt, <fgont@si6networks.com> wrote:
Folks,

Based on the recent discussion on the v6ops list
(http= s://mailarchive.ietf.org/arch/msg/v6ops/b7r35HgOb-6dfxsDoW8c4FtGnZo//),=
I've posted this new I-D, meant to discuss the scope of ULAs:

Title: "Scope of Unique Local IPv6 Unicast Addresses"
I-D: https://to= ols.ietf.org/id/draft-gont-6man-ipv6-ula-scope-00.txt


Short version of the story:

ULAs are formally part of the GUA space. However, the characteristics of ULAs do not seem to match the definition of global scope from RFC4007
(IPv6 Scope Addr Architecture). ULA seem to have a scope of
scope(link-local) < scope(ULA) < scope(GUA).

This is not only a terminology thing (which I think is nevertheless
important to get right) but also has practical implications. For
example, there's a python library that considers ULAs as "not glob= al",
and "private" -- contradicting the current RFC4291/RFC4193 specs.=

Prior to posting this document, we had some on-list discussion (on the
v6ops list) and also some off-list discussion with some of you (bcc'ed)= .

The opinions have been in one of these camps:

1) the current specs are coherent and there's no problem

2) There's a problem with the definition of "global scope" --= so ULAs
*are* global scope, but global scope does not really stand for the
definition in RFC4007.

3) The definitions in RFC4007 are correct, and thus the scope of ULAs is not really global, but scopee(link-local) < scope(ULAs) < scope(globa= l)

The thing that is really missing from "global scope" is what sc= ope or domain is being described? Forwarding scope? Uniqueness scope? Some = other scope (DNS visibility is probably another one). All of them?

ULAs are intended to be globally= unique addresses, but not to be globally (Internet) forwardable. Their for= warding scope is limited to non-global, either within a single local networ= k, or between a set of local networks that have agreed to forward their res= pective ULA /48 prefixes between each other, overriding the default of loca= l networks only forwarding scope. (Ethernet addresses are a similar example= , globally unique addresses, link only forwarding scope.)

GUAs also are intended to be globally uni= que addresses, but are intended to be globally (Internet) forwardable.

There isn't really a ULA e= quivalent in IPv4, although I think a lot of the arguments in RFC1627, &quo= t;Network 10 Consider= ed Harmful (So= me Practices Shouldn't be Codified)" would have been arguments for= one e.g, "The lesson that we learned was that every IP address= ought to be globally unique, independent of its attachment to the Internet= ." (There is a statement about effectively everything attached to the = Internet too, however that's 1994 Internet naivety, before DDoSes and I= nternet wide scanning for and exploiting of vulnerabilities were much of a = thing.)
Re= gards,
Mark.



While this document does propose a way out (it assumes #3 above, and
acts accordingly), I believe the first step is to agree on what "globa= l
scope" means and, subsequently, whether ULAs are really "global s= cope"
or not. Since opinions on the topic have vary a lot (as noted above),
I've posted this I-D and I'm sending this note for further input fr= om
the WG.

Thanks!

Regards,
Fernando




-------- Forwarded Message --------
Subject: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt=
Date: Tue, 05 Jan 2021 17:02:20 -0800
From: internet-drafts@ietf.org
To: Fernando Gont <fgont@si6networks.com>


A new version of I-D, draft-gont-6man-ipv6-ula-scope-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gont-6man-ipv6-ula-scop= e
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Scope of Unique Local IPv6 Unicast= Addresses
Document date:=C2=A0 2021-01-05
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:
https://w= ww.ietf.org/archive/id/draft-gont-6man-ipv6-ula-scope-00.txt
Status:
https://datatr= acker.ietf.org/doc/draft-gont-6man-ipv6-ula-scope/
Htmlized:
https://da= tatracker.ietf.org/doc/html/draft-gont-6man-ipv6-ula-scope
Htmlized:
https://tools.iet= f.org/html/draft-gont-6man-ipv6-ula-scope-00


Abstract:
=C2=A0 =C2=A0 Unique Local IPv6 Unicast Addresses (ULAs) are formally part = of the
=C2=A0 =C2=A0 IPv6 Global Unicast address space.=C2=A0 However, the semanti= cs of ULAs
=C2=A0 =C2=A0 clearly contradict the definition of "global scope"= .=C2=A0 This document
=C2=A0 =C2=A0 discusses the why the terminology employed for the specificat= ion of
=C2=A0 =C2=A0 ULAs is problematic, along with some practical consequences o= f the
=C2=A0 =C2=A0 current specification of ULAs.=C2=A0 Finally, it formally upd= ates RFC4291
=C2=A0 =C2=A0 and RFC4193 such that the scope of ULAs is defined as "l= ocal".




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tool= s.ietf.org.

The IETF Secretariat



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listin= fo/v6ops
--00000000000014b8c605b831b23b-- From nobody Tue Jan 5 18:45:12 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3648A3A0418; Tue, 5 Jan 2021 18:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLkHb31cw-vY; Tue, 5 Jan 2021 18:45:03 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27EA3A040B; Tue, 5 Jan 2021 18:45:02 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 438632837EF; Wed, 6 Jan 2021 02:44:57 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Mark Smith Cc: 6MAN <6man@ietf.org>, IPv6 Operations References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> From: Fernando Gont Message-ID: <2e80ec51-ec66-16c7-7c9e-a6e8d632c5de@si6networks.com> Date: Tue, 5 Jan 2021 23:44:49 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 02:45:07 -0000 Hi, Mark, Thanks a lot for your comments! In-line.... On 5/1/21 23:00, Mark Smith wrote: [...] > Prior to posting this document, we had some on-list discussion (on the > v6ops list) and also some off-list discussion with some of you (bcc'ed). > > The opinions have been in one of these camps: > > 1) the current specs are coherent and there's no problem > > 2) There's a problem with the definition of "global scope" -- so ULAs > *are* global scope, but global scope does not really stand for the > definition in RFC4007. > > > 3) The definitions in RFC4007 are correct, and thus the scope of > ULAs is > not really global, but scopee(link-local) < scope(ULAs) < scope(global) > > The thing that is really missing from "global scope" is what scope or > domain is being described? Forwarding scope? Uniqueness scope? Some > other scope (DNS visibility is probably another one). All of them? FWIW, the definition of "scope" as per RFC4007 has to do with being able to being able to uniquely identify an interface. i.e., "uniqueness" from your list. As such, forwarding scope should always be smaller than that (i.e., address: where the thing is, route: how to get there). > ULAs are intended to be globally unique addresses, but not to be > globally (Internet) forwardable. The math in RFC4193 for "uniqueness" considers *only a reduced number of uLA-based networks being inter-connected*. So, when computing global uniqueness, you should consider *all ULA prefixes in use*, not just those of networks you are interconnecting. And when you do that, you get a very high probability of collisions (~1). > Their forwarding scope is limited to > non-global, either within a single local network, or between a set of > local networks that have agreed to forward their respective ULA /48 > prefixes between each other, overriding the default of local networks > only forwarding scope. (Ethernet addresses are a similar example, > globally unique addresses, link only forwarding scope.) Not really: Ethernet Addresses (when "U/L" bit set) are centrally assigned. When not set, they only have local significance, and are not globally unique. The analogy is that ULAs are like local Ethernet addresses, whereas ULA-C would be similar to Universal/global Ethernet addresses. > GUAs also are intended to be globally unique addresses, but are intended > to be globally (Internet) forwardable. The birthday paradox tells you that with a 40-bit Global ID, you cannot really expect ULA prefixes to be globally-unique. > There isn't really a ULA equivalent in IPv4, ULAs are the equivalent of RFC1918, with the addition of: 1) More bits for the addresses (both the prefix, subnet id, and interface ID) 2) A requirement to generate ULA prefixes from a PRNG -- something that wouldn't have made sense for RFC1918, anyway, because you only have a limited number of bits for the addresses. > although I think a lot of > the arguments in RFC1627, "Network 10 Considered Harmful (Some Practices > Shouldn't be Codified)" would have been arguments for one e.g, "The > lesson that we learned was that every IP address ought to be globally > unique, independent of its attachment to the Internet." How could you possibly achieve that without a central registry, and only 40 bits (think birthday paradox)? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 5 20:38:35 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD213A0F3D for ; Tue, 5 Jan 2021 20:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9gz_76P3ySg for ; Tue, 5 Jan 2021 20:38:28 -0800 (PST) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C753A0EF9 for <6man@ietf.org>; Tue, 5 Jan 2021 20:38:28 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 4D9c7R6NjMz9vbJV for <6man@ietf.org>; Wed, 6 Jan 2021 04:38:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pCB-LH2AxoA for <6man@ietf.org>; Tue, 5 Jan 2021 22:38:27 -0600 (CST) Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 4D9c7R2qt3z9vYxg for <6man@ietf.org>; Tue, 5 Jan 2021 22:38:27 -0600 (CST) DMARC-Filter: OpenDMARC Filter v1.3.2 mta-p7.oit.umn.edu 4D9c7R2qt3z9vYxg DKIM-Filter: OpenDKIM Filter v2.11.0 mta-p7.oit.umn.edu 4D9c7R2qt3z9vYxg Received: by mail-ej1-f71.google.com with SMTP id m11so836548ejr.20 for <6man@ietf.org>; Tue, 05 Jan 2021 20:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WQdUxq1ytyVplLkVJOIk96RjBVwPNCJ/nPb6Oz5naKQ=; b=inOgmPtwvtn0c/EEMLF9CblCHi8TRuviUFT48jETru4k8ENVbqIBuxUMDtu3EqV06B ovgYTkEez1sDb9jTAOGmUDZ0RSG3F2JcbqHYgiha8IwZVAm820KvtvZJIRxcFMpZ5PpE NZmr0hf3dNrbgNeD/sqlEu+jFqcWYIYEefr9us0kEi6Tgn60D44j4wm3ZlOMFFFViudu +ePilF6wmsupi80a1htqZPMoKyVRkcQxOGlPVmrw6fB+vzHis5h4Ad1bkjIz9kbtnzrC 5vUXUhjngF4EsfMkHPh5rfA1c/baFMPlcMFdMZoZHQBXEsdhotZ7zOudvU2tZPRyi6Hs TqXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WQdUxq1ytyVplLkVJOIk96RjBVwPNCJ/nPb6Oz5naKQ=; b=XWzLzytPmvko/CpyhyANZ71utgRClWlF44F7mnxpiieOKnMF/hRDY3pBThWqAfqPMA Sdq5LWQuTl0+W7XIiGbua0hnMwBYX9VWu8D4FOjs8AkpzGehQxoxbwi2cjbXuuOxZCt9 avT4c2DD8/Wx0P63XL+gc3d3I/7cLy2QF5QEn2jGbtW4dXNOfswvofKYa/3AGIoJ+9j3 yk0MTq+dMkWazy0t0a191w28gq39KOK6QhsRwrJ8IiIaJljl6/OHktiFPJsM/XDyzu5i gixMD3Ge0knibUiHY+n/w3rozg0o3sicLNjuLGSK0o8ps/PGA9TlqhcZ1ZFzVMlvfnOB XsJw== X-Gm-Message-State: AOAM530MAyEkcQJ/cDnhq2eVlU9ib2hKWRPw/rz+I4axgnZYKrXon/bw e0lRq1FXydnmn1NwKNiaZ7nVodSvN93vcVSTk9SJ1tho/zWos0BiVrwNdMw/twgo22rTTht5D7Q 00kjj+eQDRNMk34/fM4k66dKJ X-Received: by 2002:a17:906:4fcc:: with SMTP id i12mr557831ejw.32.1609907905733; Tue, 05 Jan 2021 20:38:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJyqcJbBLz5gh1h2Pe475I6c9jU6ucsqH5hGMVpZuszEadvlLI576eY0mtD5GybNRdG+jEmGZGK2c3wbVtWTeYo= X-Received: by 2002:a17:906:4fcc:: with SMTP id i12mr557814ejw.32.1609907905388; Tue, 05 Jan 2021 20:38:25 -0800 (PST) MIME-Version: 1.0 References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> In-Reply-To: <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> From: David Farmer Date: Tue, 5 Jan 2021 22:38:09 -0600 Message-ID: Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Fernando Gont Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations Content-Type: multipart/alternative; boundary="000000000000d27cd705b833e449" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 04:38:33 -0000 --000000000000d27cd705b833e449 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think this is the right direction the previous draft indirectly defined a new scope "non-global", I much prefer explicitly defining a new local scope= . I would add something like the following to better define the relationship between the three scopes; The boundary of the link-local scope is strongly defined, limiting the extent of the link-local scope to an individual link. However, in contrast, the boundary of the local scope is weakly defined, it is amorphous and imprecise. In some instances, the extent of the local scope can be a single site, in other instances, a group of unrelated sites, a single organization, or even a cooperating group of organizations. Furthermore, the extent of an individual instance of the local scope doesn't necessarily remain constant, it may expand or contract over time as the local situation dictates, for example when two organizations merge. Nevertheless, the extent of the local scope doesn=E2=80=99t encompass the entirety of the Int= ernet which the global scope does. On Tue, Jan 5, 2021 at 7:21 PM Fernando Gont wrote: > Folks, > > Based on the recent discussion on the v6ops list > (https://mailarchive.ietf.org/arch/msg/v6ops/b7r35HgOb-6dfxsDoW8c4FtGnZo/= /), > > I've posted this new I-D, meant to discuss the scope of ULAs: > > Title: "Scope of Unique Local IPv6 Unicast Addresses" > I-D: https://tools.ietf.org/id/draft-gont-6man-ipv6-ula-scope-00.txt > > > Short version of the story: > > ULAs are formally part of the GUA space. However, the characteristics of > ULAs do not seem to match the definition of global scope from RFC4007 > (IPv6 Scope Addr Architecture). ULA seem to have a scope of > scope(link-local) < scope(ULA) < scope(GUA). > > This is not only a terminology thing (which I think is nevertheless > important to get right) but also has practical implications. For > example, there's a python library that considers ULAs as "not global", > and "private" -- contradicting the current RFC4291/RFC4193 specs. > > Prior to posting this document, we had some on-list discussion (on the > v6ops list) and also some off-list discussion with some of you (bcc'ed). > > The opinions have been in one of these camps: > > 1) the current specs are coherent and there's no problem > > 2) There's a problem with the definition of "global scope" -- so ULAs > *are* global scope, but global scope does not really stand for the > definition in RFC4007. > > 3) The definitions in RFC4007 are correct, and thus the scope of ULAs is > not really global, but scopee(link-local) < scope(ULAs) < scope(global) > > > While this document does propose a way out (it assumes #3 above, and > acts accordingly), I believe the first step is to agree on what "global > scope" means and, subsequently, whether ULAs are really "global scope" > or not. Since opinions on the topic have vary a lot (as noted above), > I've posted this I-D and I'm sending this note for further input from > the WG. > > Thanks! > > Regards, > Fernando > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.t= xt > Date: Tue, 05 Jan 2021 17:02:20 -0800 > From: internet-drafts@ietf.org > To: Fernando Gont > > > A new version of I-D, draft-gont-6man-ipv6-ula-scope-00.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-6man-ipv6-ula-scope > Revision: 00 > Title: Scope of Unique Local IPv6 Unicast Addresses > Document date: 2021-01-05 > Group: Individual Submission > Pages: 8 > URL: > https://www.ietf.org/archive/id/draft-gont-6man-ipv6-ula-scope-00.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-6man-ipv6-ula-scope/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-gont-6man-ipv6-ula-scope > Htmlized: > https://tools.ietf.org/html/draft-gont-6man-ipv6-ula-scope-00 > > > Abstract: > Unique Local IPv6 Unicast Addresses (ULAs) are formally part of the > IPv6 Global Unicast address space. However, the semantics of ULAs > clearly contradict the definition of "global scope". This document > discusses the why the terminology employed for the specification of > ULAs is problematic, along with some practical consequences of the > current specification of ULAs. Finally, it formally updates RFC4291 > and RFC4193 such that the scope of ULAs is defined as "local". > > > > > 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. > > The IETF Secretariat > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --000000000000d27cd705b833e449 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this is the right direction the p= revious draft indirectly defined a new scope "non-global", I much= prefer explicitly=C2=A0defining a new local scope.

I wo= uld add something like the following to better define the relationship betw= een the three scopes;

The boundary of the link-local scope is= strongly defined, limiting the extent of the link-local scope to an indivi= dual link. However, in contrast, the boundary of the local scope is weakly = defined, it is amorphous and imprecise. In some instances, the extent of th= e local scope can be a single site, in other instances, a group of unrelate= d sites, a single organization, or even a cooperating group of organization= s. Furthermore, the extent of an individual instance of the local scope doe= sn't necessarily remain constant, it may expand or contract over time a= s the local situation dictates, for example when two organizations merge. N= evertheless, the extent of the local scope doesn=E2=80=99t encompass the en= tirety of the Internet which the global scope does.

On Tu= e, Jan 5, 2021 at 7:21 PM Fernando Gont <fgont@si6networks.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Folks,

Based on the recent discussion on the v6ops list
(https://mailarchive.ietf.o= rg/arch/msg/v6ops/b7r35HgOb-6dfxsDoW8c4FtGnZo//),
I've posted this new I-D, meant to discuss the scope of ULAs:

Title: "Scope of Unique Local IPv6 Unicast Addresses"
I-D: https://tools.ietf.org/id/draft-= gont-6man-ipv6-ula-scope-00.txt


Short version of the story:

ULAs are formally part of the GUA space. However, the characteristics of ULAs do not seem to match the definition of global scope from RFC4007
(IPv6 Scope Addr Architecture). ULA seem to have a scope of
scope(link-local) < scope(ULA) < scope(GUA).

This is not only a terminology thing (which I think is nevertheless
important to get right) but also has practical implications. For
example, there's a python library that considers ULAs as "not glob= al",
and "private" -- contradicting the current RFC4291/RFC4193 specs.=

Prior to posting this document, we had some on-list discussion (on the
v6ops list) and also some off-list discussion with some of you (bcc'ed)= .

The opinions have been in one of these camps:

1) the current specs are coherent and there's no problem

2) There's a problem with the definition of "global scope" --= so ULAs
*are* global scope, but global scope does not really stand for the
definition in RFC4007.

3) The definitions in RFC4007 are correct, and thus the scope of ULAs is not really global, but scopee(link-local) < scope(ULAs) < scope(globa= l)


While this document does propose a way out (it assumes #3 above, and
acts accordingly), I believe the first step is to agree on what "globa= l
scope" means and, subsequently, whether ULAs are really "global s= cope"
or not. Since opinions on the topic have vary a lot (as noted above),
I've posted this I-D and I'm sending this note for further input fr= om
the WG.

Thanks!

Regards,
Fernando




-------- Forwarded Message --------
Subject: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt=
Date: Tue, 05 Jan 2021 17:02:20 -0800
From: interne= t-drafts@ietf.org
To: Fernando Gont <fgont@si6networks.com>


A new version of I-D, draft-gont-6man-ipv6-ula-scope-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gont-6man-ipv6-ula-scop= e
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Scope of Unique Local IPv6 Unicast= Addresses
Document date:=C2=A0 2021-01-05
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:
https://www.ietf.org/archive/id= /draft-gont-6man-ipv6-ula-scope-00.txt
Status:
https://datatracker.ietf.org/doc/dra= ft-gont-6man-ipv6-ula-scope/
Htmlized:
https://datatracker.ietf.org/doc= /html/draft-gont-6man-ipv6-ula-scope
Htmlized:
https://tools.ietf.org/html/draft-gont-= 6man-ipv6-ula-scope-00


Abstract:
=C2=A0 =C2=A0 Unique Local IPv6 Unicast Addresses (ULAs) are formally part = of the
=C2=A0 =C2=A0 IPv6 Global Unicast address space.=C2=A0 However, the semanti= cs of ULAs
=C2=A0 =C2=A0 clearly contradict the definition of "global scope"= .=C2=A0 This document
=C2=A0 =C2=A0 discusses the why the terminology employed for the specificat= ion of
=C2=A0 =C2=A0 ULAs is problematic, along with some practical consequences o= f the
=C2=A0 =C2=A0 current specification of ULAs.=C2=A0 Finally, it formally upd= ates RFC4291
=C2=A0 =C2=A0 and RFC4193 such that the scope of ULAs is defined as "l= ocal".




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Da= vid Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu<= br>Networking & Telecommunication Services
Office of Information Tec= hnology
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-30= 29=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--000000000000d27cd705b833e449-- From nobody Tue Jan 5 20:45:40 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE5F3A0F47; Tue, 5 Jan 2021 20:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.419 X-Spam-Level: X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK-NP-oEXSoQ; Tue, 5 Jan 2021 20:45:37 -0800 (PST) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A12A3A0F46; Tue, 5 Jan 2021 20:45:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 1064jYYw006946; Tue, 5 Jan 2021 23:45:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1609908334; bh=Fa5HEr0ZJEwwtxRZXw3KErn8oaGeCdTLvf1KxX6DwJc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=PjEj8Of0qd9fV+hP1A/p9YcVmvdwkShSfW14NT9InaHrhAIB+HBOWtMPTudcYl4HL lFhmm2nGuviXOnLN8RvEM1QPzhgxIm66S/A1GH5muFM13V+uSkgWza9bLpPeI4/GUs lyuwtkwPkLFAAAmDfemj1su0cCHXppnaFFmLtl84PDg834Z3wFSHGOk9XmbMqY0fom ccL20KusX26qAxB5a9BGjvP3HDsNTRq+t9mJMOX8SHFCEaqYPGpFn3EgT9VSPl4QIq /KWZoB5dy7OVG/jhCDCD7jtVokEtDvGlTTn+DHleaXQkY1aJ9254lX46OXzLtnVqCR fLHAWqp5PPAJQ== Received: from XCH16-01-07.nos.boeing.com (xch16-01-07.nos.boeing.com [144.115.65.217]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 1064jN73006891 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 5 Jan 2021 23:45:23 -0500 Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-07.nos.boeing.com (144.115.65.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 5 Jan 2021 20:45:21 -0800 Received: from XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b]) by XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b%4]) with mapi id 15.01.2044.004; Tue, 5 Jan 2021 20:45:21 -0800 From: "Manfredi (US), Albert E" To: Fernando Gont CC: IPv6 Operations , 6MAN <6man@ietf.org> Subject: RE: [EXTERNAL] Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Thread-Topic: [EXTERNAL] Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Thread-Index: AQHW48/q6MYge4t1TkCUP2ZIbkIFhaoaakmA//+V2PA= Date: Wed, 6 Jan 2021 04:45:21 +0000 Message-ID: <91dd34c29aa64a5d80f64bd0a4370dcc@boeing.com> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <2e80ec51-ec66-16c7-7c9e-a6e8d632c5de@si6networks.com> In-Reply-To: <2e80ec51-ec66-16c7-7c9e-a6e8d632c5de@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.115.204.6] x-tm-snts-smtp: 6474391E86DD1113A4A3D58B79511EA11C1EF70C24971B184B223E004BA848792000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 04:45:38 -0000 -----Original Message----- From: ipv6 On Behalf Of Fernando Gont > The math in RFC4193 for "uniqueness" considers *only a reduced number of= =20 uLA-based networks being inter-connected*. So, when computing global=20 uniqueness, you should consider *all ULA prefixes in use*, not just=20 those of networks you are interconnecting. And when you do that, you get=20 a very high probability of collisions (~1). This is getting unnecessarily complicated, IMO. ULAs are more than just lin= k-local, because an administrative domain, such as even an enterprise net, = can use them, throughout that network. Within such a domain, the top /48 ca= n be guaranteed to be unique, because the same admin computes those 40 rand= om Global ID bits. Not so? Such as, use the same PRNG, document the seed, t= hen pick your five random bytes to use for each site, from the long random = sequence. Now you can organize that enterprise net into separate /48 networks, or for= that matter, even link various geo-separated sites, through tunnels, where= each site gets one or more of those random /48 prefixes. The important poi= nt being, only route inside that enterprise, and use a consistent method to= compute the Global ID bits. I just object to equating this with link-local. It's way more than that. Bert From nobody Tue Jan 5 21:10:50 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D7C3A1034; Tue, 5 Jan 2021 21:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXJN1GtZtBQD; Tue, 5 Jan 2021 21:10:41 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2850F3A102D; Tue, 5 Jan 2021 21:10:39 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D70CD28462F; Wed, 6 Jan 2021 05:10:33 +0000 (UTC) Subject: Re: [EXTERNAL] Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: "Manfredi (US), Albert E" Cc: IPv6 Operations , 6MAN <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <2e80ec51-ec66-16c7-7c9e-a6e8d632c5de@si6networks.com> <91dd34c29aa64a5d80f64bd0a4370dcc@boeing.com> From: Fernando Gont Message-ID: <02c4c5bd-5a49-81f3-4379-c71dbb252112@si6networks.com> Date: Wed, 6 Jan 2021 02:10:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <91dd34c29aa64a5d80f64bd0a4370dcc@boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 05:10:45 -0000 Hello, Bert, On 6/1/21 01:45, Manfredi (US), Albert E wrote: > -----Original Message----- From: ipv6 On > Behalf Of Fernando Gont > >> The math in RFC4193 for "uniqueness" considers *only a reduced >> number of > uLA-based networks being inter-connected*. So, when computing global > uniqueness, you should consider *all ULA prefixes in use*, not just > those of networks you are interconnecting. And when you do that, you > get a very high probability of collisions (~1). > > This is getting unnecessarily complicated, IMO. ULAs are more than > just link-local, Indeed, my draft argues that the scope of ULAs is larger than that of link-locals. They key point is that it also argues that scope(ULAs) < scope(GUAs). > because an administrative domain, such as even an > enterprise net, can use them, throughout that network. Within such a > domain, the top /48 can be guaranteed to be unique, How could you possibly guaranteed that if you're selecting the ULA prefix with a PRNG? Probabilities don't buy you any guarantees, except if P=1 or P=0, which is clearly not the case here. Additionally, there's a difference between "the ULA prefix is probabilistically unique if you connect a limited number of networks" -- which is the math in Section 3.2.3 of RFC4193 -- versus being globally unique, which implies that the ULA prefix is unique among or ULA-based networks, whether you interconnected them or not. > because the same > admin computes those 40 random Global ID bits. Not so? Such as, use > the same PRNG, document the seed, then pick your five random bytes to > use for each site, from the long random sequence. RFC4193 does not mandate a specific algorithm, but rather specified the requirements for the PRNG (good for the RFC4193 authors!). So, documenting the seed will serve no purpose, because other implementations might use a completely different algorithm for generating the ULA prefix. > Now you can organize that enterprise net into separate /48 networks, > or for that matter, even link various geo-separated sites, through > tunnels, where each site gets one or more of those random /48 > prefixes. The important point being, only route inside that > enterprise, This one seems, already, an indication of prefixes being non-global. > and use a consistent method to compute the Global ID bits. An this one is obviously non-enforceable, for multiple reasons, including the fact that RFC4193 doesn't mandate any specific algorithm. > I just object to equating this with link-local. It's way more than > that. I don't think anybody has equated ULAs with link-locals. The argument has been, instead, that: scope(link-local) < scope(ULA) < scope(GUA) In a way, the expectation of ULAs to be global-scope is probably what drove the recent discussion on the 6man list about a ULA registry -- which yes, is probably the only way in which ULAs could actually be GUAs (except that unless you can enforce the use of such registry, having a non-enforceable partial registry won't make the ULA prefixes global scope). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 5 21:28:53 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFDF3A1071; Tue, 5 Jan 2021 21:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKvpnrfTuANd; Tue, 5 Jan 2021 21:28:48 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8A423A1070; Tue, 5 Jan 2021 21:28:48 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id DD53E284635; Wed, 6 Jan 2021 05:28:44 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: David Farmer Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> From: Fernando Gont Message-ID: Date: Wed, 6 Jan 2021 02:28:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 05:28:52 -0000 Hello, David, Thanks a lot for your feedback! In-line.... On 6/1/21 01:38, David Farmer wrote: > I think this is the right direction the previous draft indirectly > defined a new scope "non-global", I much prefer explicitly defining a > new local scope. Good point. > I would add something like the following to better define the > relationship between the three scopes; > > The boundary of the link-local scope is strongly defined, limiting > the extent of the link-local scope to an individual link. However, > in contrast, the boundary of the local scope is weakly defined, it > is amorphous and imprecise. In some instances, the extent of the > local scope can be a single site, in other instances, a group of > unrelated sites, a single organization, or even a cooperating group > of organizations. Furthermore, the extent of an individual instance > of the local scope doesn't necessarily remain constant, it may > expand or contract over time as the local situation dictates, for > example when two organizations merge. Following the terminology in RFC4007, I wonder if this last bit should be expressed as: "the extent of an individual instantiation of a local scope (i.e., a zone), does not necessarily remain constant..."? > Nevertheless, the extent of > the local scope doesn’t encompass the entirety of the Internet which > the global scope does. A remaining item to figure out here is: According to RFC4007, you can't have to instantiations of the same scope. One way to analyze this is 1) that this doesn't apply to ULAs, or, 2) That it's impossible to tell the specific extent of a local scope. As a result, all instantiations of local scopes are considered to be different zones, and hence you are free to have as many instantiations of "local scope" as you wish. (RFC4007 defines "zone" to be an instantiation of "scope"). Thoughts? Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 5 21:54:07 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E2B3A10B0; Tue, 5 Jan 2021 21:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtis1i2_kBJR; Tue, 5 Jan 2021 21:53:59 -0800 (PST) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502093A10A9; Tue, 5 Jan 2021 21:53:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 1065rsuf011035; Wed, 6 Jan 2021 00:53:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1609912435; bh=hVTCdQ8W6Bi5oftCoJck+M9/zAiFptEjpuL3xw6rPac=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=AQiFXsMMc2Tvj6XMBaMjAIsBPB8SJ2YRGZuIKlynE2fa+27kfhbqXDB/566yBN7/l cz2tFfiLJ08OLyS75UA6PGE/yYCRAie+lKTGp/rZCUlKqdhsChx3qp7mJEWG+bq2MF F51JToVu/fV4SlqwUT0UtfnalUExHI7iulQsZMVPhR3B9szZZQs1fxh1uaChA34Pwn 9jQ0Z2eJUn6yqSFIqqGUb/Y9qcAQN9Rff9gpkZo9oAyjnyXLEbt1rqFFOj+wDYhpqM RUFN3jiEiRwrCoyzW1ud4JmtKOungCXMZp7PhvEcf/UQ7iFeKkZanMC6F4xdw0AZ1y WO0FMk9gul7uQ== Received: from XCH16-01-09.nos.boeing.com (xch16-01-09.nos.boeing.com [144.115.65.234]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 1065rkWp010903 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 6 Jan 2021 00:53:47 -0500 Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-09.nos.boeing.com (144.115.65.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 5 Jan 2021 21:53:45 -0800 Received: from XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b]) by XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b%4]) with mapi id 15.01.2044.004; Tue, 5 Jan 2021 21:53:45 -0800 From: "Manfredi (US), Albert E" To: Fernando Gont CC: IPv6 Operations , 6MAN <6man@ietf.org> Subject: RE: [EXTERNAL] Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Thread-Topic: [EXTERNAL] Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Thread-Index: AQHW4+pOG7wrQgzUhUyECNniNFZ8MKoaEugA Date: Wed, 6 Jan 2021 05:53:45 +0000 Message-ID: References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <2e80ec51-ec66-16c7-7c9e-a6e8d632c5de@si6networks.com> <91dd34c29aa64a5d80f64bd0a4370dcc@boeing.com> <02c4c5bd-5a49-81f3-4379-c71dbb252112@si6networks.com> In-Reply-To: <02c4c5bd-5a49-81f3-4379-c71dbb252112@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.115.204.6] x-tm-snts-smtp: ACB09E3227197A01887590E975206EC663A8A91DCF7408D9619DBC18429613CB2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 05:54:01 -0000 SGkgRmVybmFuZG8sIGxldCdzIGZvbGxvdyB0aGUgS0lTUyBwcmluY2lwbGUuDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jr cy5jb20+IA0KDQo+IFJGQzQxOTMgZG9lcyBub3QgbWFuZGF0ZSBhIHNwZWNpZmljIGFsZ29yaXRo bSwgYnV0IHJhdGhlciBzcGVjaWZpZWQgdGhlIA0KcmVxdWlyZW1lbnRzIGZvciB0aGUgUFJORyAo Z29vZCBmb3IgdGhlIFJGQzQxOTMgYXV0aG9ycyEpLiBTbywgDQpkb2N1bWVudGluZyB0aGUgc2Vl ZCB3aWxsIHNlcnZlIG5vIHB1cnBvc2UsIGJlY2F1c2Ugb3RoZXIgDQppbXBsZW1lbnRhdGlvbnMg bWlnaHQgdXNlIGEgY29tcGxldGVseSBkaWZmZXJlbnQgYWxnb3JpdGhtIGZvciANCmdlbmVyYXRp bmcgdGhlIFVMQSBwcmVmaXguDQoNCldpdGhpbiBhbiBlbnRlcnByaXNlLCB0aGUgYWRtaW4gaGFz IGEgY2hvaWNlIG9mIHdoaWNoIFBSTkcgdG8gdXNlLCBhbmQgd2hhdCBzZWVkIHRvIHVzZS4gVGhp bmsgaW4gdGVybXMgb2Ygb25lIGd1eSwgbWFraW5nIHRoYXQgZGVjaXNpb24sIGFuZCB0aGVuIGRv Y3VtZW50aW5nIGFsbCB0aGUgR2xvYmFsIElEIDQwLWJpdCBzZXF1ZW5jZXMgaW4gdXNlLCBpbiB0 aGUgdmFyaW91cyBuZXRzIG9mIHRoZSBlbnRlcnByaXNlLiBUaGUgZ3V5IHdpdGggdGhpcyByZXNw b25zaWJpbGl0eSBjYW4gY2VydGFpbmx5IGRlY2lkZSBvbiB3aGljaCBhbGdvcml0aG0gdG8gdXNl IQ0KDQpJdCBpcyBlYXN5IGVub3VnaCB0byBndWFyYW50ZWUgdW5pcXVlbmVzcywgaW4gdGhpcyBj YXNlLg0KDQo+IEFuIHRoaXMgb25lIGlzIG9idmlvdXNseSBub24tZW5mb3JjZWFibGUsIGZvciBt dWx0aXBsZSByZWFzb25zLCANCmluY2x1ZGluZyB0aGUgZmFjdCB0aGF0IFJGQzQxOTMgZG9lc24n dCBtYW5kYXRlIGFueSBzcGVjaWZpYyBhbGdvcml0aG0uDQoNCkkgYW0gdGhlIGVudGVycHJpc2Ug YWRtaW4sIEknbSB0YXNrZWQgd2l0aCBhZG1pbmlzdGVyaW5nIHRoZSBVTEFzIGZvciB0aGUgZW50 ZXJwcmlzZSwgYW5kIEkgZW5mb3JjZSB0aGUgcnVsZS4gVGhlIGFkbWluIG9mIG9uZSBlbnRlcnBy aXNlIG5ldHdvcmsgaGFzIG5vIHNheSBpbiB3aGF0IG90aGVyIGFkbWlucywgb2Ygb3RoZXIgZW50 ZXJwcmlzZSBuZXR3b3Jrcywgd2FudCB0byBkby4gTm9yIGlzIHRoZXJlIGFueSByZXF1aXJlbWVu dCBmb3IgVUxBcyBvZiBkaWZmZXJlbnQgZW50ZXJwcmlzZSBuZXRzIHRvIGJlIG11dHVhbGx5IHVu aXF1ZS4NCg0KPiBJIGRvbid0IHRoaW5rIGFueWJvZHkgaGFzIGVxdWF0ZWQgVUxBcyB3aXRoIGxp bmstbG9jYWxzLiBUaGUgYXJndW1lbnQgDQpoYXMgYmVlbiwgaW5zdGVhZCwgdGhhdDogc2NvcGUo bGluay1sb2NhbCkgPCBzY29wZShVTEEpIDwgc2NvcGUoR1VBKQ0KDQpTb21ldGhpbmcgbGlrZSAi c2luZ2xlIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBzY29wZSwiIGlmIHRoYXQgZXhpc3RlZCwgbWFr ZXMgc2Vuc2UgdG8gbWUuIEkgdGhpbmsgdGhlIHByb2JsZW0gaXMgdGhhdCB0b2RheSwgaXQncyBl aXRoZXIgbGluayBsb2NhbCBvciBnbG9iYWwgc2NvcGU/DQoNCj4gSW4gYSB3YXksIHRoZSBleHBl Y3RhdGlvbiBvZiBVTEFzIHRvIGJlIGdsb2JhbC1zY29wZSBpcyBwcm9iYWJseSB3aGF0IA0KZHJv dmUgdGhlIHJlY2VudCBkaXNjdXNzaW9uIG9uIHRoZSA2bWFuIGxpc3QgYWJvdXQgYSBVTEEgcmVn aXN0cnkgLS0NCg0KVG8gbWUsIHRoYXQncyBhIGRpZmZlcmVudCBkaXNjdXNzaW9uLiBUaGF0IHJl Z2lzdHJ5IGlkZWEgd291bGQgcHJvYmFibHkgYmUgYSBuZWNlc3NpdHksIGJ1dCBvbmx5IGZvciB0 aGUgZmMwMDo6LzggVUxBcywgd2hpY2ggYXJlIGZvciBmdXR1cmUgdXNlLiBXaGVuIFVMQXMgYXJl IG5vdCBhc3NpZ25lZCBieSBhbiBpbmRpdmlkdWFsIGFkbWluLCB0aGUgcHJvYmxlbSBvZiB1bmlx dWVuZXNzIGlzIGRpZmZlcmVudCwgbm8/IFRvIG1lLCB0aGF0IHJlZ2lzdHJ5IHByb2JsZW0gaXMg YSBub24taXNzdWUsIHVubGVzcyBhbmQgdW50aWwgd2Ugc3RhcnQgdXNpbmcgdGhlIGZjMDA6Oi84 IGFkZHJlc3Nlcy4gQXMgb2Ygbm93LCBvbmx5IGZkMDA6Oi84IGFyZSBiZWluZyBkaXNjdXNzZWQu DQoNCkJlcnQNCg0K From nobody Tue Jan 5 22:32:59 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351403A106F; Tue, 5 Jan 2021 22:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpPOcDwNfiZm; Tue, 5 Jan 2021 22:32:50 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A37C3A103F; Tue, 5 Jan 2021 22:32:49 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EE92E283BB4; Wed, 6 Jan 2021 06:32:44 +0000 (UTC) Subject: Re: [EXTERNAL] Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: "Manfredi (US), Albert E" Cc: IPv6 Operations , 6MAN <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <2e80ec51-ec66-16c7-7c9e-a6e8d632c5de@si6networks.com> <91dd34c29aa64a5d80f64bd0a4370dcc@boeing.com> <02c4c5bd-5a49-81f3-4379-c71dbb252112@si6networks.com> From: Fernando Gont Message-ID: <31ab1e02-ea3c-08db-20be-83576afa5b7a@si6networks.com> Date: Wed, 6 Jan 2021 03:32:32 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 06:32:54 -0000 Hi, Bert, On 6/1/21 02:53, Manfredi (US), Albert E wrote: > Hi Fernando, let's follow the KISS principle. KISS *and* real, please ;-) > -----Original Message----- From: Fernando Gont > > >> RFC4193 does not mandate a specific algorithm, but rather specified >> the > requirements for the PRNG (good for the RFC4193 authors!). So, > documenting the seed will serve no purpose, because other > implementations might use a completely different algorithm for > generating the ULA prefix. > > Within an enterprise, the admin has a choice of which PRNG to use, > and what seed to use. Think in terms of one guy, making that > decision, and then documenting all the Global ID 40-bit sequences in > use, in the various nets of the enterprise. The guy with this > responsibility can certainly decide on which algorithm to use! > > It is easy enough to guarantee uniqueness, in this case. Please do the math. Being able to connect a few networks together does not mean the addreses are unique. You can't normally connect several 10.0.0.0/8 nets, too. Global-scope, as per RFC4007 would imply that *the ULA prefixes are globally unique*. *All, at the same time*. >> An this one is obviously non-enforceable, for multiple reasons, > including the fact that RFC4193 doesn't mandate any specific > algorithm. > > I am the enterprise admin, I'm tasked with administering the ULAs for > the enterprise, and I enforce the rule. The admin of one enterprise > network has no say in what other admins, of other enterprise > networks, want to do. Nor is there any requirement for ULAs of > different enterprise nets to be mutually unique. Indeed, "global scope" would imply exactly that. Please check my I-D, which quotes the relevant text from RFC4193. >> I don't think anybody has equated ULAs with link-locals. The >> argument > has been, instead, that: scope(link-local) < scope(ULA) < scope(GUA) > > Something like "single administrative domain scope," if that existed, > makes sense to me. I think the problem is that today, it's either > link local or global scope? Exactly! ULAs are not link-local, but not "global", either. They have a scope that lies somewhere in between link-local and global. In my I-D, I called the ULA scope "local", but I don't mind changing that to "single administrative domain scope", "private scope", or anything else. The point is, indeed, that ULAs are currently defined as global. BUt they are not -- their scope is certainly smaller than global. >> In a way, the expectation of ULAs to be global-scope is probably >> what > drove the recent discussion on the 6man list about a ULA registry -- > > To me, that's a different discussion. That registry idea would > probably be a necessity, but only for the fc00::/8 ULAs, which are > for future use. When ULAs are not assigned by an individual admin, > the problem of uniqueness is different, no? Indeed. When they are not centrally assigned, or not assigned by the same admin, you cannot expect them to be unique across different administrative domains. You can expect the probability of collisions *when interconnecting a reduced number of ULA-based networks* to be small. But you can certainly not expect the ULA prefixes to be unique at a global scale. when you consider ~1M networks (not a big deal if you e.g. expect that each home will generate a ULA prefix) you actually have almost certainty that there's a collision. > To me, that registry > problem is a non-issue, unless and until we start using the fc00::/8 > addresses. As of now, only fd00::/8 are being discussed. To me, it's also a non issue. But it looks like the proposal for a registry has been motivated by the expectation of ULAs being *globally unique* (as opposed to "unlikely to collide if you interconnect a handful of ULA-based networks"). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 5 23:08:09 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF1B3A11A8 for ; Tue, 5 Jan 2021 23:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.972 X-Spam-Level: X-Spam-Status: No, score=-17.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1VAbLINskIM for ; Tue, 5 Jan 2021 23:08:03 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2BD3A104D for <6man@ietf.org>; Tue, 5 Jan 2021 23:08:03 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id b10so277010ilr.4 for <6man@ietf.org>; Tue, 05 Jan 2021 23:08:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rVuMKwVhqknYlyoyBH1sSDT7zjC+qLgw3QlWEuB09Jg=; b=Izyh5WctGCr1TgY/OsGfiBiGYBJMFAMgz9P54e8BkUIF6koXWuDe090zukLxWsOglW TnlOJdqO6U6z/j6aQfelA5ArpVifUQOkwFmvZ+KBSc3XxS0i/2gdXMt73NgkFTYSWs5k qvwPyN/tNPeyQTKG0oxOPJhFCX2teyjpoYhoj42gkEZVvfqbBwS8QH5ihLfGSsCzzAPd sw/GibJ6B9+s13Z+LnFnXYU21NIT/eZ42VXCt+DoxPpUmTN2edgic4vka+TRkTA3iXbm uhP6UlqQaqrG7SJNXomdGplT9CWvb8XXaG6jtmlQKMrudUUMfgzL361FqP+SMbIOszqM 7vJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rVuMKwVhqknYlyoyBH1sSDT7zjC+qLgw3QlWEuB09Jg=; b=JWrWuTVWe/pYbWml/7zJWtPFGIz0qiqCVKQXCxURkUXqqaF2cjcOvikInBFib8dGAO RyUDE4MiuvI9PyAUwvrOaa1hWhh7nP+MVpHACAMscWbXEnMUeyqUMworxK8joyjNhvO0 i2avJsOMj7KFaVtEes0HpcvhmNtAO5RABjdooWWCoFBujsDLTo6dX859AbUxZ8c9ziOK Ep6IWOAq+uIryFexW5kxQqR6s0ejXmItGmhriEBOh+ERhPXA74wHrKkfJKcO6IiTcGYT 6+mixLRhYRiF2H7q103jccP6b3gp5qNYbiU2TTMDUYNfvSQkp8IS4fg1i+J4zpQQYtg+ VB7w== X-Gm-Message-State: AOAM532m+VrZ+kUAWWb75r/DBhUBL2rFYNoqY3RHsytx6hh1YwTnwxjj ElRAmJTsWTSdxP94lIoPtH2+cx4oOT3XosZBaqY3RQ== X-Google-Smtp-Source: ABdhPJzjvyQrMUrRQ17bv+gnWQ5o9NZiAPCSyewUuXIlQL/eqx9H7bajk7AswrT+9p7Uuvw8KxOJGGtcI2WqE7DKVXw= X-Received: by 2002:a05:6e02:85:: with SMTP id l5mr3004120ilm.187.1609916882175; Tue, 05 Jan 2021 23:08:02 -0800 (PST) MIME-Version: 1.0 References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> In-Reply-To: From: Lorenzo Colitti Date: Wed, 6 Jan 2021 16:07:51 +0900 Message-ID: Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Mark Smith Cc: Fernando Gont , IPv6 Operations , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000e1b9f005b835fbc9" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 07:08:05 -0000 --000000000000e1b9f005b835fbc9 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 6, 2021 at 11:01 AM Mark Smith wrote: > ULAs are intended to be globally unique addresses, but not to be globally > (Internet) forwardable. Their forwarding scope is limited to non-global, > either within a single local network, or between a set of local networks > that have agreed to forward their respective ULA /48 prefixes between each > other, overriding the default of local networks only forwarding scope. > (Ethernet addresses are a similar example, globally unique addresses, link > only forwarding scope.) > IMO defining ULAs as they are was a mistake. Global scope implies unique. But probabilistic uniqueness doesn't work because humans choose ULAs instead of generating them manually. Registry-based uniqueness doesn't work (and, to be fair, was never tried by the IETF) because there is no registry that has jurisdiction. Even if there were, there is no reason to keep addresses unique if they don't have global reachability. So I guess I'm somewhere between 1) and 3). The specs are consistent but they fail to consider human behaviour, so they don't actually work in practice. I don't know what to do about this though. If we say they're non-global scope, then they are going to be the exact equivalent of RFC1918 addresses, with all the problems that that causes. If we continue to say they're global scope, then the specs don't match reality. :-( --000000000000e1b9f005b835fbc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 6, 2021 at 11:01 AM Mark Smit= h <markzzzsmith@gmail.com&= gt; wrote:
ULAs are inte= nded to be globally unique addresses, but not to be globally (Internet) for= wardable. Their forwarding scope is limited to non-global, either within a = single local network, or between a set of local networks that have agreed t= o forward their respective ULA /48 prefixes between each other, overriding = the default of local networks only forwarding scope. (Ethernet addresses ar= e a similar example, globally unique addresses, link only forwarding scope.= )

IMO defining ULAs as th= ey are was a mistake. Global scope implies unique. But probabilistic unique= ness doesn't work because humans choose ULAs instead of generating them= manually. Registry-based uniqueness doesn't work (and, to be fair, was= never tried by the IETF) because there is no registry that has jurisdictio= n. Even if there were, there is no reason to keep addresses unique if they = don't have global reachability.

So I guess I&#= 39;m somewhere between 1) and 3). The specs are consistent but they fail to= consider human behaviour, so they don't actually work in practice. I d= on't know what to do about this though. If we say they're non-globa= l scope, then they are going to be the exact equivalent of RFC1918 addresse= s, with all the problems that that causes. If we continue to say they'r= e global scope, then the specs don't match reality. :-(
--000000000000e1b9f005b835fbc9-- From nobody Tue Jan 5 23:30:47 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63C83A11C2; Tue, 5 Jan 2021 23:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLA3otnRg3Hl; Tue, 5 Jan 2021 23:30:43 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B052B3A11BE; Tue, 5 Jan 2021 23:30:43 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id c14so1579942qtn.0; Tue, 05 Jan 2021 23:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=B09ywsGA62ENIR/fCzCVsO5C/xl/SVDxSOe5Op63kOM=; b=ek75tAkOEp1cEBeq53fFrxWr9c071vLaQoToXCIAhBTuCmFeqDcBUyYb2ir2ByXVun ud7glL3nWg9Zr0HFZeAej8ceLBhGh2PI3gMZqWzeKiMaGrF7Nxv7Tq2NHVJBOLrxa+yJ kS/yoymsUi2zmwUK+OEBqjRAOamJWi8f0m9+G/f8FDyowWJCJwtGEx+/BzH1NndVGThp LtdKpeh469NmumxnKkGH/RiSiVq5kLxJX4i/W4iI7EccGy3ptDrVKgkNNIPsa71paAqs mAooYzwzw3r90p2Nrhoh+r6qLkPVUQGqreNMZxATASSP0hndY7QcP8pNNJ4u/e4xV3Zu vLUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=B09ywsGA62ENIR/fCzCVsO5C/xl/SVDxSOe5Op63kOM=; b=fZZR+/mEQfx5lQsCTaAnUM7PoFi6tIHTNJbkjGd0geuTLwdyGSlw+tNVdVb5EPRzgB Q3NnpwP2Ia8tVbThKHLud3QDZ2u6aCKN6t/ejqiePofsy7iD/ikajQgC3SM/s1qmSYdG WIXwjOUMEG3C9eJwf74sf4CpBnmz7XLIFfV7zHFodohe5gVAMnLDI8G4jb2qri3SiRMn AVn1AQlq1SAKmLuH25DNl+hzMTHnBMKeoMriJvTyeXXSoifwmMVmqe1w+8X+nkdlj/Z6 ol3/FsJFQ5X2JYl4BGTXxyP+gG428WDqRp9l+S7LM8WCseeysUEOKT+JPKx73WPDYWoJ w0fA== X-Gm-Message-State: AOAM530Ji3DjkUh1t6flZNoYnJtfF3JpHThulmMzMW3O4/m94EmCndaI cSRO38SnB49SNTTBWKt96XFfH25Z4E3BmfPBagM= X-Google-Smtp-Source: ABdhPJzwDFeCmWmM9ZD7yWv4vgyfvQZotdId8kM9jYQduV27QvVKSUQ2RILMrf7FlNgdOh1LMctQ3lOiYNdv/dcVgWc= X-Received: by 2002:aed:2e63:: with SMTP id j90mr3043667qtd.338.1609918242587; Tue, 05 Jan 2021 23:30:42 -0800 (PST) MIME-Version: 1.0 References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> In-Reply-To: From: Christopher Morrow Date: Wed, 6 Jan 2021 02:30:31 -0500 Message-ID: Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Lorenzo Colitti Cc: Mark Smith , Fernando Gont , IPv6 Operations , 6MAN <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 07:30:46 -0000 On Wed, Jan 6, 2021 at 2:09 AM Lorenzo Colitti wrote: > > On Wed, Jan 6, 2021 at 11:01 AM Mark Smith wrote= : >> >> ULAs are intended to be globally unique addresses, but not to be globall= y (Internet) forwardable. Their forwarding scope is limited to non-global, = either within a single local network, or between a set of local networks th= at have agreed to forward their respective ULA /48 prefixes between each ot= her, overriding the default of local networks only forwarding scope. (Ether= net addresses are a similar example, globally unique addresses, link only f= orwarding scope.) > > > IMO defining ULAs as they are was a mistake. Global scope implies unique.= But probabilistic uniqueness doesn't work because humans choose ULAs inste= ad of generating them manually. Registry-based uniqueness doesn't work (and= , to be fair, was never tried by the IETF) because there is no registry tha= t has jurisdiction. Even if there were, there is no reason to keep addresse= s unique if they don't have global reachability. > > So I guess I'm somewhere between 1) and 3). The specs are consistent but = they fail to consider human behaviour, so they don't actually work in pract= ice. I don't know what to do about this though. If we say they're non-globa= l scope, then they are going to be the exact equivalent of RFC1918 addresse= s, with all the problems that that causes. If we continue to say they're gl= obal scope, then the specs don't match reality. :-( option 4, deprecate ULA. the best option (tm). From nobody Tue Jan 5 23:38:49 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20B63A08E7; Tue, 5 Jan 2021 23:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJhZi8F01NB9; Tue, 5 Jan 2021 23:38:41 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3763A095E; Tue, 5 Jan 2021 23:38:40 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A4256283A88; Wed, 6 Jan 2021 07:38:36 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Lorenzo Colitti , Mark Smith Cc: IPv6 Operations , 6MAN <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> From: Fernando Gont Message-ID: <3e8a9ff3-ac2b-988b-8517-fbbdcff9ff9e@si6networks.com> Date: Wed, 6 Jan 2021 04:38:23 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 07:38:44 -0000 On 6/1/21 04:07, Lorenzo Colitti wrote: > On Wed, Jan 6, 2021 at 11:01 AM Mark Smith > wrote: > > ULAs are intended to be globally unique addresses, but not to be > globally (Internet) forwardable. Their forwarding scope is limited > to non-global, either within a single local network, or between a > set of local networks that have agreed to forward their respective > ULA /48 prefixes between each other, overriding the default of local > networks only forwarding scope. (Ethernet addresses are a similar > example, globally unique addresses, link only forwarding scope.) > > > IMO defining ULAs as they are was a mistake. Global scope implies > unique. But probabilistic uniqueness doesn't work because humans choose > ULAs instead of generating them manually. Not only that. At a global scale, the Birthday problem tells you that the ULA prefixes will also be non-unique. ~1.2M of house-hods generating their ULA prefixes already gives you P~1 that you have a collision at the global level. Indeed, the math in https://tools.ietf.org/html/rfc4193#section-3.2.3 already implicitly acknowledges this fact, because the probability of collision is computed on the basis of how many networks you interconnect -- that's certainly not what "global scope" means. > Registry-based uniqueness > doesn't work (and, to be fair, was never tried by the IETF) because > there is no registry that has jurisdiction. Even if there were, there is > no reason to keep addresses unique if they don't have global reachability. Fully agreed. > So I guess I'm somewhere between 1) and 3). The specs are consistent but > they fail to consider human behaviour, so they don't actually work in > practice. If you look at the definition of scope and global scope from RFC4007, it's inconsistent with employing it for defining ULAs as global. (Indeed, the *L* in ULA says it all ;-) ) > I don't know what to do about this though. If we say they're > non-global scope, then they are going to be the exact equivalent of > RFC1918 addresses, with all the problems that that causes. If we > continue to say they're global scope, then the specs don't match > reality. :-( One can say that they are local scope, with the expectation that since the ULA prefix is meant to be randomly generated, then sites that comply with such requirement will have a small probability of prefix collisions if two ULA-based sites were to be merged/interconnected. I think that's as real and factually correct as it can get. Besides, this also means that libraries such as ipaddress match the specs. -- right now, they don't. And it would be hard to argue that libraries such as Python's ipaddress should be changed such that ULAs are flagged as both "global" and "public". -- something that would not only be wrong, but that can also not be done in a backwards compatible manner. Also, if apps, for some reason, are checking such address attributes, it's certainly better that the attributes are set in an intuitive way (the current one, which doesn't match the specs), in the hopes that they can make something useful out of differentiating IPv6 address properties. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 00:16:47 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055433A11E8; Wed, 6 Jan 2021 00:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0RMNszsbVGm; Wed, 6 Jan 2021 00:16:40 -0800 (PST) Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A233A08A9; Wed, 6 Jan 2021 00:16:40 -0800 (PST) Received: by mail-oo1-xc2e.google.com with SMTP id j21so573577oou.11; Wed, 06 Jan 2021 00:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Hv+z6C8N/8tsSlNhDQeWDtom18SNWfr6ue8W5TflGHw=; b=HHmc7Ql0Qv9HTgFtHYREXql30u4OCb3SCUNPyVVd3Xci+vguMgsuzZGRtPRzego6cZ 1SuyFa3LJsOLJ3N8tNjI+gKhRdk5v9tcTMrlWrgQ+W+Tyq0eZmGMWYYKca4BifWewGPH GaNjs5YuvMXYNlrHHo6GeTUbpvm/yiWPTXJvzqN6oxxBtPtmQmznvLW+nFQGyj8un7xp ZfS6F3udTR2YO8pobxvjPJoS6X6KGictxIforODtWbocsWgjcVEULMIlRcVknFfx3fnT YJOQj+G/K2TVgfCTHArVjUMMgDwlbwTrxSAe6Jf6d7dg6l0WMvTIM1ZCzw/qY0f83MGU aHBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Hv+z6C8N/8tsSlNhDQeWDtom18SNWfr6ue8W5TflGHw=; b=lVDWBMfYrH4ZOqwUrATXXzw+RdZvs9NANyH5UD6Fs8i7gxQp4ibRIQhfQtLlcWTrNM tly5TMXGzusspL68J3StKsyn8cAtbwcB96w8KbKlmdR5aC8Lxk6A2sIohN1rGprzJMDe 22unXUJ1IV/CRduxam5zHn5LeYVLNzki9sLts1t256tbgN6uKKmAz0ryN6wLzMfMCWvv Br2jJmbbOqZivpM+x/UNEFGuWqrF6CHVLCr1tnYmXCwG7PvWMe4Gq9V0SSzwuyfL4lsk pZODR7rRCl5DQ//WmNTkAsnXndILI15hDCoNXhLNziXw4tifpRDKL+2Dc3s5UB/0Ot0B xrrQ== X-Gm-Message-State: AOAM532x4m2MXQCgKGXJBUrnluqVRgeCxIxZJZftmpsj7G47hB2edg+f eMps9VUbAt6m/G4JeQuLkDeEDBkRPIftSdGIrBk= X-Google-Smtp-Source: ABdhPJzeupSNH2bYv620WA0DLsyOvzEKoG67i4LT3+Er3myuU6xXXaaYl/MJDPwLj3P+PBPhQZrY9NpYi4uV1DejZGY= X-Received: by 2002:a4a:520f:: with SMTP id d15mr1995880oob.29.1609920999896; Wed, 06 Jan 2021 00:16:39 -0800 (PST) MIME-Version: 1.0 References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> In-Reply-To: From: Mark Smith Date: Wed, 6 Jan 2021 19:16:27 +1100 Message-ID: Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Christopher Morrow Cc: Lorenzo Colitti , Fernando Gont , IPv6 Operations , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="00000000000050b8a705b836f140" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 08:16:42 -0000 --00000000000050b8a705b836f140 Content-Type: text/plain; charset="UTF-8" On Wed, 6 Jan 2021, 18:30 Christopher Morrow, wrote: > On Wed, Jan 6, 2021 at 2:09 AM Lorenzo Colitti > wrote: > > > > On Wed, Jan 6, 2021 at 11:01 AM Mark Smith > wrote: > >> > >> ULAs are intended to be globally unique addresses, but not to be > globally (Internet) forwardable. Their forwarding scope is limited to > non-global, either within a single local network, or between a set of local > networks that have agreed to forward their respective ULA /48 prefixes > between each other, overriding the default of local networks only > forwarding scope. (Ethernet addresses are a similar example, globally > unique addresses, link only forwarding scope.) > > > > > > IMO defining ULAs as they are was a mistake. Global scope implies > unique. But probabilistic uniqueness doesn't work because humans choose > ULAs instead of generating them manually. Registry-based uniqueness doesn't > work (and, to be fair, was never tried by the IETF) because there is no > registry that has jurisdiction. Even if there were, there is no reason to > keep addresses unique if they don't have global reachability. > > > > So I guess I'm somewhere between 1) and 3). The specs are consistent but > they fail to consider human behaviour, so they don't actually work in > practice. I don't know what to do about this though. If we say they're > non-global scope, then they are going to be the exact equivalent of RFC1918 > addresses, with all the problems that that causes. If we continue to say > they're global scope, then the specs don't match reality. :-( > > option 4, deprecate ULA. > the best option (tm). > If you want to destroy IPv6 by causing enterprises to replicate RFC1918s via site-locals and use NAT66, do that. ULAs exist because site-locals would have created that problem. People are already deploying ULAs mostly correctly - I know of 4 electricity smart meter networks that have more than 2 million meters attached that are using ULA addressing. The only relatively minor mistake made was that the smartmeter vendor took the 4 network's ULA spaces out of a single /48, using /52s if I recall correctly, rather than generating a /48 for each one. While probably prohibited by government, if any if those networks merged, routing between them will be as simple as linking them together and trading /52 routes. If they'd used site-locals, merging would instead be either as complex as renumbering, or as bad as NAT66, the latter being most likely. --00000000000050b8a705b836f140 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, 6 Jan 2021, 18:30 Christopher Morrow, <christopher.morrow@gmail.com> wrote:
On Wed, Jan 6, 2021 at= 2:09 AM Lorenzo Colitti
<lorenzo=3D
40google.com@dmarc.ietf.org> wrote:
>
> On Wed, Jan 6, 2021 at 11:01 AM Mark Smith <markzzzsmith@gmail.= com> wrote:
>>
>> ULAs are intended to be globally unique addresses, but not to be g= lobally (Internet) forwardable. Their forwarding scope is limited to non-gl= obal, either within a single local network, or between a set of local netwo= rks that have agreed to forward their respective ULA /48 prefixes between e= ach other, overriding the default of local networks only forwarding scope. = (Ethernet addresses are a similar example, globally unique addresses, link = only forwarding scope.)
>
>
> IMO defining ULAs as they are was a mistake. Global scope implies uniq= ue. But probabilistic uniqueness doesn't work because humans choose ULA= s instead of generating them manually. Registry-based uniqueness doesn'= t work (and, to be fair, was never tried by the IETF) because there is no r= egistry that has jurisdiction. Even if there were, there is no reason to ke= ep addresses unique if they don't have global reachability.
>
> So I guess I'm somewhere between 1) and 3). The specs are consiste= nt but they fail to consider human behaviour, so they don't actually wo= rk in practice. I don't know what to do about this though. If we say th= ey're non-global scope, then they are going to be the exact equivalent = of RFC1918 addresses, with all the problems that that causes. If we continu= e to say they're global scope, then the specs don't match reality. = :-(

option 4, deprecate ULA.
the best option (tm).


If you want to destroy IPv= 6 by causing enterprises to replicate RFC1918s via site-locals and use NAT6= 6, do that.

ULAs exist b= ecause site-locals would have created that problem.=C2=A0

People are already deploying ULAs mostly = correctly - I know of 4 electricity smart meter networks that have more tha= n 2 million meters attached that are using ULA addressing. The only relativ= ely minor mistake made was that the smartmeter vendor took the 4 network= 9;s ULA spaces out of a single /48, using /52s if I recall correctly, rathe= r than generating a /48 for each one.

While probably prohibited by government, if any if those netw= orks merged, routing between them will be as simple as linking them togethe= r and trading /52 routes.

If they'd used site-locals, merging would instead be either as comple= x as renumbering, or as bad as NAT66, the latter being most likely.


--00000000000050b8a705b836f140-- From nobody Wed Jan 6 02:54:57 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600483A12CD for ; Wed, 6 Jan 2021 02:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2_YaL42R5Cu for ; Wed, 6 Jan 2021 02:54:50 -0800 (PST) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608CF3A12CF for <6man@ietf.org>; Wed, 6 Jan 2021 02:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1609930490; x=1641466490; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=qGqVBzIEllYOVbK2HCRYQOQdY8WzeMK7J3U2WgaSOoE=; b=Wwe460oKGcvWdBbpTlGarT08gPRBJpT83pJ6lumBKbc9vyAH/cYKF6Xk 0Wmft54Ek9nhO/650XO1QnLTYa+YA3OzKJNcwmJJW9Sg6714KwMYRCqD3 sJFcY9MDS13dSjIcEEo4CokrG6LhZ+R1oPzwLuLi2aTOCZ6dRtz6ovtsW lkrNy4vzmYT+OVtMCalvE2AhKhU54YZPqtHJx6+ke0gNHyT3hjZMSwEav eM5jW0CKVrashvHXRDM3vntP0A5VQaYWukRSGzpK75+uBfeeD6sKBumkp ab3L2fdLJBUetqqHcKFWXZ3iR4dX6Jgfn2G+F18dEkHRhdBKbb3lHNsP+ Q==; IronPort-SDR: 7NLLhzLJcMAY1WELdGSKqMka4/Kss1Yxm5VOwoCKBeXMA4v5hJW4KvpbUPMdtwq2BCN8WqNdNc uPMxt/NsZHE1EYsRURd/kIeTwxizcgzVr2iSLzxUsTammjPx9MXojz12JcN3LX9i1JkxuZXBrS iYk0HSSeAF6s79Nt5aNZtgaIidHlqVpwnEpLED/ZAU8m4mA6+dFC7EvZdslMDMn1nLJO+YeQmp Pkdjj98n8s3mF2i9FpCR8SD7/d10844t0o7Xcc2pa1/fFQTv1PCbJGF93TOanmkISjPBOEVwAw CfM= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2021 11:54:45 +0100 X-Original-To: 6man@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 83BF943AD1 for <6man@ietf.org>; Wed, 6 Jan 2021 11:54:45 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 18B60427F9; Wed, 6 Jan 2021 11:54:45 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 0F741DDC86; Wed, 6 Jan 2021 11:54:45 +0100 (CET) Date: Wed, 6 Jan 2021 11:54:45 +0100 From: Gert Doering To: Lorenzo Colitti Cc: Mark Smith , Fernando Gont , IPv6 Operations , 6MAN <6man@ietf.org> Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Message-ID: <20210106105445.GU13005@Space.Net> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 10:54:52 -0000 Hi, On Wed, Jan 06, 2021 at 04:07:51PM +0900, Lorenzo Colitti wrote: > Registry-based uniqueness doesn't work > (and, to be fair, was never tried by the IETF) because there is no registry > that has jurisdiction. ULA-C was abandoned. But that could be revived... Find a registry is not hard. Anyone could be the registry, if IETF gives their blessing and says "there's a machine that spits out a guaranteeed unique ULA /48s for each $20 you feed in"... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Jan 6 04:17:40 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801823A03EE for ; Wed, 6 Jan 2021 04:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1_c0eO_a-rM for ; Wed, 6 Jan 2021 04:17:37 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04D03A03EB for <6man@ietf.org>; Wed, 6 Jan 2021 04:17:37 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id i18so2536539ioa.1 for <6man@ietf.org>; Wed, 06 Jan 2021 04:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4LlZbIUceEaVckEvBwddjJ9hRtWzsxnSprME/90jWOA=; b=uTdOfJ1HYvu8mCXpj+YDIp4V+Z5+qJD6mieOhxjFl7snIlTbXS+0rxTYIvtlrr1W3T +W+kdQX7tIDMffJ8KGSKzAYYtguoZDJ+sZu+iWBg3lRLmzHER9QSDi6fFGDZLhFDAwlg kANkkZ1BIyZgdyXRiaMqGaiNbWKGiWbXw83q4a5GaB8kDNNJXW8Rg7e98IIShpbjR14D RBWo/s2uD6hwRGj6eW+okdfBrd1ozxrZgtK3es1unD4REMliZyfpGkZh/GUPwjVq8ujy Z1cQW+jOlmd1tOiVtQQZaWauraHpIMJmoKGc+G+sAln/RXf2/6OyL8I7VAYGBt+GTOPN M2fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4LlZbIUceEaVckEvBwddjJ9hRtWzsxnSprME/90jWOA=; b=qppReHkT4n79KS7K3ZILu8nJtto+pz8py/P5vLldRY9S/ASJawSr6w2IpABH/cQ6Y3 mcq0O+q0Xr7mMJH02p2Pie0LWsN4lpOyuMSzStbmq/rEwLF4JOoVQnTreftqOyy7Kftu 9gw58bLxN2C1YhgyXTPD0BoDdUBBO09b+Ow7SHZkRS4zqcvDcCuxxECL/0r/+WinFpgR ruPNQg6d6nuGkvlmdHPN73JugI664a4fBhds7ura7YkZ79zwX1cjiWOR7lBWL2pGw0PS cdIcQsg7lwufXI9yddRocZEESY8XmYusq4gPd92d/1x8agQ+YCWa7FHvbk3D2V1ZEryC 6Ctg== X-Gm-Message-State: AOAM531ESXfJnDsvbkcuVow0NoSHNSN990n50r0NLXl0rhhOJne7COaA 80l+jf0WPTeSyQhdPxH0KbyXKQ== X-Google-Smtp-Source: ABdhPJxJsngGd9akaIiVZjq97k/GB1FRzARSuG/2+EZ86+DgDmsLhhGWtnEG9h9rNJ5O7GqCt5bu2A== X-Received: by 2002:a6b:4f13:: with SMTP id d19mr2603904iob.121.1609935456681; Wed, 06 Jan 2021 04:17:36 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id r12sm1908049ile.59.2021.01.06.04.17.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 04:17:35 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_10497EDE-6AC7-4BB4-BBC2-0FE624F2F492" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Wed, 6 Jan 2021 07:17:33 -0500 In-Reply-To: Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> To: David Farmer References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 12:17:40 -0000 --Apple-Mail=_10497EDE-6AC7-4BB4-BBC2-0FE624F2F492 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 5, 2021, at 11:38 PM, David Farmer = wrote: > I think this is the right direction the previous draft indirectly = defined a new scope "non-global", I much prefer explicitly defining a = new local scope. Actually, I think you=E2=80=99ve got it right here: the scope is = =E2=80=9Cnon-global.=E2=80=9D > I would add something like the following to better define the = relationship between the three scopes; >=20 > The boundary of the link-local scope is strongly defined, limiting the = extent of the link-local scope to an individual link. However, in = contrast, the boundary of the local scope is weakly defined, it is = amorphous and imprecise. In some instances, the extent of the local = scope can be a single site, in other instances, a group of unrelated = sites, a single organization, or even a cooperating group of = organizations. Furthermore, the extent of an individual instance of the = local scope doesn't necessarily remain constant, it may expand or = contract over time as the local situation dictates, for example when two = organizations merge. Nevertheless, the extent of the local scope = doesn=E2=80=99t encompass the entirety of the Internet which the global = scope does. There is at least one obvious problem with this definition: the term = =E2=80=9Clocal.=E2=80=9D ULAs aren=E2=80=99t really local, despite the = name. Using the name =E2=80=9Clocal=E2=80=9D is what leads to this = confusion. Consider this taxonomy: GUA: =E2=80=9Cvalid everywhere on the internet scope=E2=80=9D ULA: =E2=80=9Cnot valid everywhere scope=E2=80=9D LLA: =E2=80=9Cvalid only on this link scope=E2=80=9D Of course these names are awkward, but I hope they are clarifying. A ULA = is =E2=80=9Cnot valid everywhere.=E2=80=9D That=E2=80=99s really all you = can say about it. You can=E2=80=99t put a ULA prefix in a global routing = domain. You can put it in a site routing domain. You can put it in a = multi-site routing domain. You can not route it at all. All these uses = are valid. So I don=E2=80=99t really object to your text, but I do object to the = name =E2=80=9Clocal.=E2=80=9D How about =E2=80=9Cexplicit=E2=80=9D? That = is, the scope of a ULA is explicit, in the sense that it must be _made_ = explicit by the user(s) of the ULA? If that doesn=E2=80=99t work, I=E2=80=99= m sure we can come up with a more agreeable term, but please let it not = be =E2=80=9Clocal.=E2=80=9D Sorry to be a sticky wicket. :) --Apple-Mail=_10497EDE-6AC7-4BB4-BBC2-0FE624F2F492 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 5, 2021, at 11:38 PM, David Farmer <farmer=3D40umn.edu@dmarc.ietf.org> = wrote:
I think this is the right direction the previous draft = indirectly defined a new scope "non-global", I much prefer = explicitly defining a new local = scope.

Actually, I = think you=E2=80=99ve got it right here: the scope is = =E2=80=9Cnon-global.=E2=80=9D

I would add something like the = following to better define the relationship between the three = scopes;

The boundary of the link-local scope is = strongly defined, limiting the extent of the link-local scope to an = individual link. However, in contrast, the boundary of the local scope = is weakly defined, it is amorphous and imprecise. In some instances, the = extent of the local scope can be a single site, in other instances, a = group of unrelated sites, a single organization, or even a cooperating = group of organizations. Furthermore, the extent of an individual = instance of the local scope doesn't necessarily remain constant, it may = expand or contract over time as the local situation dictates, for = example when two organizations merge. Nevertheless, the extent of the = local scope doesn=E2=80=99t encompass the entirety of the Internet which = the global scope does.

There is at least one obvious problem with = this definition: the term =E2=80=9Clocal.=E2=80=9D ULAs aren=E2=80=99t = really local, despite the name. Using the name =E2=80=9Clocal=E2=80=9D = is what leads to this confusion. Consider this taxonomy:

GUA: =E2=80=9Cvalid = everywhere on the internet scope=E2=80=9D
ULA: = =E2=80=9Cnot valid everywhere scope=E2=80=9D
LLA: = =E2=80=9Cvalid only on this link scope=E2=80=9D

Of course these names are awkward, but = I hope they are clarifying. A ULA is =E2=80=9Cnot valid everywhere.=E2=80=9D= That=E2=80=99s really all you can say about it. You can=E2=80=99t put a = ULA prefix in a global routing domain. You can put it in a site routing = domain. You can put it in a multi-site routing domain. You can not route = it at all. All these uses are valid.

So I don=E2=80=99t really object to = your text, but I do object to the name =E2=80=9Clocal.=E2=80=9D How = about =E2=80=9Cexplicit=E2=80=9D? That is, the scope of a ULA is = explicit, in the sense that it must be _made_ explicit by the user(s) of = the ULA? If that doesn=E2=80=99t work, I=E2=80=99m sure we can come up = with a more agreeable term, but please let it not be =E2=80=9Clocal.=E2=80= =9D Sorry to be a sticky wicket. :)

= --Apple-Mail=_10497EDE-6AC7-4BB4-BBC2-0FE624F2F492-- From nobody Wed Jan 6 04:33:24 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172EA3A05D0 for ; Wed, 6 Jan 2021 04:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhqwP7-Mb7Iw for ; Wed, 6 Jan 2021 04:33:16 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735DC3A0596 for <6man@ietf.org>; Wed, 6 Jan 2021 04:33:16 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id e22so1996280iom.5 for <6man@ietf.org>; Wed, 06 Jan 2021 04:33:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YNFQP3IieN1wBTliOwkbOYceBsMswg28OVyh1Bd9XMI=; b=lCZZkPEzd8QpbwjAUI/SPu5MqQOE57j+H69ehwn1yfVj8dmNNAZk72Di9qd1UOeQ24 XDysbCGHX5CR4hBwNPlDABvqoNQohEeIGa0S9qTd5fPtVl3lY9ATsQJqFX18lYgA/IBp vxyB4JqX4Mk8cWnuMSRHC+CIrCywgsk/LTQGrOx7wh80DiVqFoWYqX8CUDZvVHzG7lRg o5MnFfKRr20YiGxMURapA5oDvRgh50ffJ5fyvmw1gR3SLTnf0nZpftWD52ArQUHqAJFb A/sz56ot+cWu0RDMGdhZmCeGrCvNW3/1xMOGUEbcrR/m1UFPQdcdnmP7aX4JVoiOM0bo 6jIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YNFQP3IieN1wBTliOwkbOYceBsMswg28OVyh1Bd9XMI=; b=rp4rA8fY+YqWbyI5ANiahYEDVxXEaYVZ4Uowr12ySfS2gVNyk7LfypNGkGIDdKz6Pv +AaacxKVayptUDdN1PmDpr7/G5eCGyGfxKhz4rtFTVtS8Yds9xGzGOEYZPHV2ozjENBf RXhriK5b3NcGt5rVpWt1FOcRj0bzN+wJDB+BjumTBZxVjzI/jWcpssODEsT4nQ2mFE04 QLIX3rE5ALEWE8PIV29JqAapABpL4ndrrEO2NOr+yKxoJTEjftJcVclOqg7BdLVwoCng rQeFQrrWvDe0VF6Vve5H1A+knszaQ9bSqmFDjihSCO43Ynd1TwTrM9BmpIalYtHswWIE m+/w== X-Gm-Message-State: AOAM530FE132rhHVvQaRhaHIbbEztclZp6caFj+gExnWQ45R7ma41JdK hvMPv1u6Pcst8yQ90CtzxxP2FA== X-Google-Smtp-Source: ABdhPJxr8ZJETE76M+MTzT3RPk0K8vGIXr/kjPegBYf6a6UpufGRoF0ReqUoG8GTB8HPaFcQQTAYew== X-Received: by 2002:a02:a417:: with SMTP id c23mr3539867jal.42.1609936395443; Wed, 06 Jan 2021 04:33:15 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id m19sm1905214ila.81.2021.01.06.04.33.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 04:33:14 -0800 (PST) From: Ted Lemon Message-Id: <735226B9-5A0E-48AE-8B9A-CCDC5ED8C3ED@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_13BF4F69-5645-4479-9094-BEEE0BA2F6FD" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Wed, 6 Jan 2021 07:33:12 -0500 In-Reply-To: Cc: Lorenzo Colitti , Fernando Gont , IPv6 Operations , 6MAN <6man@ietf.org> To: Christopher Morrow References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 12:33:18 -0000 --Apple-Mail=_13BF4F69-5645-4479-9094-BEEE0BA2F6FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 6, 2021, at 2:30 AM, Christopher Morrow = wrote: > option 4, deprecate ULA. > the best option (tm). If that were an option, we wouldn=E2=80=99t be having this = argument=E2=80=94nobody would care about ULAs. ULAs are a good idea. The = terminology around them needs work, that=E2=80=99s all.=20 For example, we use ULAs in the HomePod Mini to route between adjacent = network links where IPv6 GUA delegation isn=E2=80=99t available. The ULA = never winds up in the global routing topology. The Mini chooses it using = a secure RNG, so the likelihood of collision is vanishingly small. ULAs = are _much_ more flexible than RFC1918 addresses, simply by virtue of the = process by which the /48 prefix is chosen. I would have major wibbles about using RFC1918 addresses in the Mini the = way we currently use ULAs, because we=E2=80=99d have (at best!) eight = bits of randomness, and a strong likelihood of collisions with competing = private network uses of the 10.0/8 space. Because ULA is specific about = each prefix being a /48, and because a /48 is most likely enough for = most use cases, the worries about this sort of collision are = nonexistent: nobody is going to allocate the whole ULA space to a single = site, and if they do, we can legitimately say that they are at fault for = things not working. We can=E2=80=99t and shouldn=E2=80=99t deprecate ULAs. I think = clarifying what the name means makes sense, though, and perhaps the term = should be CUA (collision-unlikely address) prefix rather than ULA = prefix. --Apple-Mail=_13BF4F69-5645-4479-9094-BEEE0BA2F6FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 6, 2021, at 2:30 AM, Christopher Morrow <christopher.morrow@gmail.com> wrote:
option 4, deprecate ULA.
the best option (tm).

If that were an option, we wouldn=E2=80=99t = be having this argument=E2=80=94nobody would care about ULAs. ULAs are a = good idea. The terminology around them needs work, that=E2=80=99s = all. 

For = example, we use ULAs in the HomePod Mini to route between adjacent = network links where IPv6 GUA delegation isn=E2=80=99t available. The ULA = never winds up in the global routing topology. The Mini chooses it using = a secure RNG, so the likelihood of collision is vanishingly small. ULAs = are _much_ more flexible than RFC1918 addresses, simply by virtue of the = process by which the /48 prefix is chosen.

I would have major wibbles about using = RFC1918 addresses in the Mini the way we currently use ULAs, because = we=E2=80=99d have (at best!) eight bits of randomness, and a strong = likelihood of collisions with competing private network uses of the = 10.0/8 space. Because ULA is specific about each prefix being a /48, and = because a /48 is most likely enough for most use cases, the worries = about this sort of collision are nonexistent: nobody is going to = allocate the whole ULA space to a single site, and if they do, we can = legitimately say that they are at fault for things not = working.

We = can=E2=80=99t and shouldn=E2=80=99t deprecate ULAs. I think clarifying = what the name means makes sense, though, and perhaps the term should be = CUA (collision-unlikely address) prefix rather than ULA = prefix.

= --Apple-Mail=_13BF4F69-5645-4479-9094-BEEE0BA2F6FD-- From nobody Wed Jan 6 04:34:53 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226ED3A0596; Wed, 6 Jan 2021 04:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKhNJ8nCvw9r; Wed, 6 Jan 2021 04:34:48 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65363A048B; Wed, 6 Jan 2021 04:34:47 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C71C7284516; Wed, 6 Jan 2021 12:34:42 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Gert Doering , Lorenzo Colitti Cc: Mark Smith , IPv6 Operations , 6MAN <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106105445.GU13005@Space.Net> From: Fernando Gont Message-ID: Date: Wed, 6 Jan 2021 08:47:23 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20210106105445.GU13005@Space.Net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 12:34:51 -0000 On 6/1/21 07:54, Gert Doering wrote: > Hi, > > On Wed, Jan 06, 2021 at 04:07:51PM +0900, Lorenzo Colitti wrote: >> Registry-based uniqueness doesn't work >> (and, to be fair, was never tried by the IETF) because there is no registry >> that has jurisdiction. > > ULA-C was abandoned. But that could be revived... > > Find a registry is not hard. Anyone could be the registry, if IETF gives > their blessing and says "there's a machine that spits out a guaranteeed > unique ULA /48s for each $20 you feed in"... Given what seems to be the fee for a /48 (not to mention that you can also get a /48 for free), not sure if such a registry would ever be attractive. Anyway, that would still leave as with ULAs, as currently specified, marked as "global scope"... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 04:46:53 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A1C3A07F5 for ; Wed, 6 Jan 2021 04:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3rxtsrsplpL for ; Wed, 6 Jan 2021 04:46:45 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886633A07F0 for <6man@ietf.org>; Wed, 6 Jan 2021 04:46:44 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id p187so2593121iod.4 for <6man@ietf.org>; Wed, 06 Jan 2021 04:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xt+DFGaVFCABlwXAJA9vbnTxHsQdfnWceh+GcUIyTeE=; b=1z9JA0aoSuQX5dsOuOm92qouVykl7KixTA3fWSiGO5OuVBDiXyi+U3Z+slL7DlPytW YeHxHd4K7e1WrbsljF/OAPQgXcsVma9bP23c3XjdGDLK9qX1+aa1PijqJXL0B2njqHpz peZyyhmMiwN4eOnz1iZzfxEag2Tea4FdvNYqFFCGdlzzXgDNDK66ogUGvFj+EDE1n4S7 TxWGRo2iHGXv2szThRQPITdmjT4BWZ/u59V6cxgeaniRqZf8+qAtTHpQs6qEI1y9dJkt oRqvrYtOg/8ltIDI+Fa6eVq6nhWyx5kXB6b0kDkbHIby2Khl5/fgnZyHq34Bijv+Y+wC 9WuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xt+DFGaVFCABlwXAJA9vbnTxHsQdfnWceh+GcUIyTeE=; b=rfyo/u48HWKuSq/7AKw98vtPCSn486xhoUEAuyPXqr1WxLxkuPEIiaKk2ZM+ym2UIL hVAHwJQhZEEXD1wZGOm2j4ZWEEEbHhwGTFvky6zTF6ZrEKFh3SoMYl96202lKPHo6gZn 3Vy2yHfeVbvEHF4SCW5SgxofdMYxHS4CY9Jb3oRo91I8ffoj1AZMXXrYwgeKMjcQGEsi s8/ct9RnwZ8lZiC+GsX1yPOG3GKqe+e0X1r2UM69i6PfGFBduvBgPfGJ/bcWJa0OEkMD 9Ax3sY0tk17efpEoERzkhzfMsFJylp8Y0bnZwtRSq7nyhoqJFIFKnhM7snh5NIbT4nHf If5A== X-Gm-Message-State: AOAM532iN8ibxsHnjzSFkYHqQMqkXeKn7j4NjW+wMULXU5lSw3hXIoSC EKwSXElzZQep/Buevl/g0agsmA== X-Google-Smtp-Source: ABdhPJwAa7Kvh+nHS0cPCplnRaoSowOFq4QnPSN86oxXEzl5QzTYeayQzC6O54xAhT8aRQLDfFufdw== X-Received: by 2002:a02:778f:: with SMTP id g137mr207980jac.41.1609937204153; Wed, 06 Jan 2021 04:46:44 -0800 (PST) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com. [209.85.166.49]) by smtp.gmail.com with ESMTPSA id s17sm1850265ilj.25.2021.01.06.04.46.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Jan 2021 04:46:43 -0800 (PST) Received: by mail-io1-f49.google.com with SMTP id u26so2602752iof.3; Wed, 06 Jan 2021 04:46:42 -0800 (PST) X-Received: by 2002:a6b:b5d2:: with SMTP id e201mr2630790iof.111.1609937202742; Wed, 06 Jan 2021 04:46:42 -0800 (PST) MIME-Version: 1.0 References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> In-Reply-To: From: Richard Patterson Date: Wed, 6 Jan 2021 12:46:31 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Christopher Morrow Cc: IPv6 Operations , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000001489b805b83ab735" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 12:46:48 -0000 --0000000000001489b805b83ab735 Content-Type: text/plain; charset="UTF-8" On Wed, 6 Jan 2021 at 07:31, Christopher Morrow < christopher.morrow@gmail.com> wrote: > > option 4, deprecate ULA. > the best option (tm). > Strongly disagree. I think defining a new scope for ULA is a good idea and will help to demystify and improve their use in the real world. --0000000000001489b805b83ab735 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 6 Jan 2021 at 07:31, Christopher = Morrow <christopher.morr= ow@gmail.com> wrote:

option 4, deprecate ULA.
the best option (tm).

Strongly disagree= .
I think defining a new scope for ULA is a good idea and will he= lp to demystify and improve their use in the real world.
--0000000000001489b805b83ab735-- From nobody Wed Jan 6 05:45:54 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3003A0A73; Wed, 6 Jan 2021 05:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.009, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PYCM59ZJ0eo; Wed, 6 Jan 2021 05:45:50 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D943A0A5E; Wed, 6 Jan 2021 05:45:48 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kx98E-0000EhC; Wed, 6 Jan 2021 14:45:46 +0100 Message-Id: To: ipv6@ietf.org Cc: Fernando Gont , IPv6 Operations Subject: Re: Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> In-reply-to: Your message of "Tue, 5 Jan 2021 22:20:55 -0300 ." <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> Date: Wed, 06 Jan 2021 14:45:43 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 13:45:53 -0000 >Prior to posting this document, we had some on-list discussion (on the >v6ops list) and also some off-list discussion with some of you (bcc'ed). > >The opinions have been in one of these camps: > >1) the current specs are coherent and there's no problem > >2) There's a problem with the definition of "global scope" -- so ULAs >*are* global scope, but global scope does not really stand for the >definition in RFC4007. > >3) The definitions in RFC4007 are correct, and thus the scope of ULAs is >not really global, but scopee(link-local) < scope(ULAs) < scope(global) > > >While this document does propose a way out (it assumes #3 above, and >acts accordingly), I believe the first step is to agree on what "global >scope" means and, subsequently, whether ULAs are really "global scope" >or not. Since opinions on the topic have vary a lot (as noted above), >I've posted this I-D and I'm sending this note for further input from >the WG. In my opinion we should leave scope the way it is. Scope has a specific meaning for link local. In the past we tried to define local scope similar to how link-local scope is defined and it failed. 'local' scope is an operational reality. You don't see it at the protocol level. So we need to keep it clearly separate from link-local where we do have quite a bit of protocol and API specification. If I look at the problem statement in this draft, the issue seems to be that ULAs may not work if you connect two networks that independently picked ULAs. It is at all clear to me how giving ULAs a 'non-global' label would change any of that. I'm not sure this is a relevant problem. Locally anybody can make sure their ULAs have enough randomness. This results in a failure chance when connecting to other networks of one in 2^40. Of all the operational problems you can get when connecting two networks, this seems to be a very remote one. I doubt that we can solve all operational problems that have a chance of one in 2^40 of happening. Of cource with badly chosen ULAs, then chance is higher. But then again, does calling ULAs 'local' solve anything? I don't see an immediate technical problem with ULAs, certainly not one that needs to be addressed with a standards track document. A practical point that is mentioned in Section 5.1 is what to call ULAs. For example, we could call them 'private'. I think there is a need to the group of addresses that includes both rfc1918 and ULA. A short informational draft that addresses that point could be useful. The main technical problem is that happens if you want to connect two networks that both use ULAs. However, in my opinion this requires operational guidance. I.e., use ULA if you expect to never connect to another network. Use ULA if in the one in 2^40 chance of a collision you can renumber. Do not use ULAs for security purposes, that will come back to bite you. From nobody Wed Jan 6 06:19:36 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C1D3A0EE1; Wed, 6 Jan 2021 06:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOktExs6kDsv; Wed, 6 Jan 2021 06:19:27 -0800 (PST) Received: from dataplane.org (dataplane.org [IPv6:2001:49f0:d0c4:3::2]) by ietfa.amsl.com (Postfix) with ESMTP id A4DE83A0E1D; Wed, 6 Jan 2021 06:19:27 -0800 (PST) Received: from p50.localdomain (localhost [127.0.0.1]) by dataplane.org (Postfix) with ESMTP id DA6E0688051C; Wed, 6 Jan 2021 14:19:26 +0000 (UTC) Date: Wed, 6 Jan 2021 08:19:26 -0600 From: John Kristoff To: Gert Doering Cc: Lorenzo Colitti , Fernando Gont , IPv6 Operations , 6MAN <6man@ietf.org> Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Message-ID: <20210106081926.2ddcd33e@p50.localdomain> In-Reply-To: <20210106105445.GU13005@Space.Net> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106105445.GU13005@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 14:19:34 -0000 On Wed, 6 Jan 2021 11:54:45 +0100 Gert Doering wrote: > Find a registry is not hard. Anyone could be the registry, if IETF gives > their blessing and says "there's a machine that spits out a guaranteeed > unique ULA /48s for each $20 you feed in"... This reminds me of IEEE OUIs. You would want a price high enough that would provide some disincentive to having anyone and everyone registering for one or multiple assignments just because they can. In addition, not every one or every organization will want to publicly listed in a registry. akin to LAAs, I don't have a strong opinion on the matter, but a prefix for locally assigned addresses aren't all bad until they either leak or must join another network that may have conflicting practices. That seems like an operational problem that can be dealt with in a fairly straightforward way. John From nobody Wed Jan 6 06:27:29 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439233A0CDC; Wed, 6 Jan 2021 06:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28YBZkPX-0Pq; Wed, 6 Jan 2021 06:27:24 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043F73A0CC7; Wed, 6 Jan 2021 06:27:23 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C1567284F4D; Wed, 6 Jan 2021 14:27:18 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Ted Lemon , David Farmer Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> From: Fernando Gont Message-ID: <684e3296-a9d9-c899-9964-d80d693c1971@si6networks.com> Date: Wed, 6 Jan 2021 11:04:43 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 14:27:27 -0000 Hi, Ted, On 6/1/21 09:17, Ted Lemon wrote: > On Jan 5, 2021, at 11:38 PM, David Farmer > > wrote: >> I think this is the right direction the previous draft indirectly >> defined a new scope "non-global", I much prefer explicitly defining a >> new local scope. > > Actually, I think you’ve got it right here: the scope is “non-global.” Indeed. But then, link-locals are non-global, too. >> I would add something like the following to better define the >> relationship between the three scopes; >> >> The boundary of the link-local scope is strongly defined, limiting >> the extent of the link-local scope to an individual link. However, >> in contrast, the boundary of the local scope is weakly defined, it >> is amorphous and imprecise. In some instances, the extent of the >> local scope can be a single site, in other instances, a group of >> unrelated sites, a single organization, or even a cooperating >> group of organizations. Furthermore, the extent of an individual >> instance of the local scope doesn't necessarily remain constant, >> it may expand or contract over time as the local situation >> dictates, for example when two organizations merge. Nevertheless, >> the extent of the local scope doesn’t encompass the entirety of >> the Internet which the global scope does. > > There is at least one obvious problem with this definition: the term > “local.” ULAs aren’t really local, despite the name. FWIW, I suggested "local" as the scope as given the "L" in "ULA", it was the obvious choice. I don't mind using any other term. What really matters is to use consistent terminology. So I guess possible options (other than "local scope") are: * private scope? * organizational scope? * administrative scope? > So I don’t really object to your text, but I do object to the name > “local.” How about “explicit”? That is, the scope of a ULA is explicit, > in the sense that it must be _made_ explicit by the user(s) of the ULA? mm.. not really. As a user of ULAs, it's impossible to tell if the scope ends up being just one link (think a CPE that locally generates a ULA prefix and advertises it in the only internal net/link), or multisite. If not "local" or "explicit", maybe one of the others suggestions above would work? Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 06:27:42 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B463A0E12; Wed, 6 Jan 2021 06:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jPvMtMvwmP4; Wed, 6 Jan 2021 06:27:32 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857A73A0EA0; Wed, 6 Jan 2021 06:27:32 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 157C0284F20; Wed, 6 Jan 2021 14:27:27 +0000 (UTC) Subject: Re: Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Philip Homburg , ipv6@ietf.org Cc: IPv6 Operations References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> From: Fernando Gont Message-ID: Date: Wed, 6 Jan 2021 11:26:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 14:27:41 -0000 Hi, Philip, On 6/1/21 10:45, Philip Homburg wrote: [...] >> While this document does propose a way out (it assumes #3 above, and >> acts accordingly), I believe the first step is to agree on what "global >> scope" means and, subsequently, whether ULAs are really "global scope" >> or not. Since opinions on the topic have vary a lot (as noted above), >> I've posted this I-D and I'm sending this note for further input from >> the WG. > > In my opinion we should leave scope the way it is. The current definition of global scope as per RFC4007 doesn't match the definition of ULAs as being global scope. Both of them can't be right. > Scope has a specific > meaning for link local. In the past we tried to define local scope similar > to how link-local scope is defined and it failed. > > 'local' scope is an operational reality. You don't see it at the protocol > level. So we need to keep it clearly separate from link-local where we do have > quite a bit of protocol and API specification. "scope" and "zone" are part of the architecture. So we have a IPv6 Scoped Addressing Architecture, and then a definition ULAs that doesn't really comply with that definition. [...] > > Of cource with badly chosen ULAs, then chance is higher. But then again, does > calling ULAs 'local' solve anything? Changing the formal scope of ULAs does change the expectation when it comes to their usage: i.e., ULAs are not expected to be globally unique. They are just expected to have small chances of collision if you connected a limited number of ULA-based networks. Besides, this does have an impact on current libraries (such as Python's ipaddress) and other libraries or macros that may have been defined for other languages, or that may be defined in the future. This in turn probably affects the use such apps make of a list of addresses, when more than one is available. > I don't see an immediate technical problem with ULAs, certainly not one that > needs to be addressed with a standards track document. > > A practical point that is mentioned in Section 5.1 is what to call ULAs. > For example, we could call them 'private'. I think there is a need to > the group of addresses that includes both rfc1918 and ULA. A short > informational draft that addresses that point could be useful. The problem is that for ULAs to be marked as "non-global" (whatever we call that), RFC4291 needs to be updated. Also, at least a part of RFC4193 needs to be updated. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 06:37:05 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D66F3A0ADE for ; Wed, 6 Jan 2021 06:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIyhaquj5vwe for ; Wed, 6 Jan 2021 06:36:58 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7408E3A0D04 for <6man@ietf.org>; Wed, 6 Jan 2021 06:36:58 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id v3so3379973ilo.5 for <6man@ietf.org>; Wed, 06 Jan 2021 06:36:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=18gTR4klejsgf9D8zlgLaKC/yvmobUF0sw7dbBHOzDY=; b=fGdC6F2CVoGpyhe6+Bm6F20i3in+HnDu31XwB58lDvBxV6P98IFIvyTHXZyM6izLjc wRMmzBS12uW3va5qGqQr+vpgRYtBk/WTqzgLsIn4/4Cfhl/Jyrzq51bFY4m1Pqb3VRQD ruc6zcpGCpquJQ69mWXXvz0vba/+THILukG8BNY2w9dQDe9Ovkd+1MF0Jos+j0t/5c59 d+2hzKEN9xmfNOjl6Kl1YV9RAyYOSTe0NMT1/G7KIU78ML0zrkj4g5Ixs5M9Fcw4w0DG wCVaRKhRsjwNjTSmiU/OR0v68qa+PxiDqI8K5xw9df8DMUdERieS69aeKo+TAkRAE3z7 2TKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=18gTR4klejsgf9D8zlgLaKC/yvmobUF0sw7dbBHOzDY=; b=VYLeayvCod4BosXWwNzYd/zcjWoMvS4Hl4Avu4XuQzAFSYmbEvoBURh6gsAlut3J48 eYViRDDrWhvVSB4SFtXC02jPQiJpw9I0ZigHZkvQ5DjartnJgf15SRBf/Ldc0l7MYQVn yUKTmfomsNxr/uBuzPOVdFU6ke6N/OlNTcxphdjCzMalN2ZKv7gaZP4YYmprN0p2iQpS OX8ue5O0lnuWZAR1lln9DayS9rWHZ1lVJ+X1/P96sbGguby3FVi5ocg1uuKS3iXl3riC jjDL+gb4Jt2EwshwlrG4IG6ciCl5SzEQbPM0DQ8GQ+frhwdO1uUzVbIOY7S9mepLCh5y frRw== X-Gm-Message-State: AOAM531Zgx2uMmeaFmg2j9JtTz1Pirgi84EHctl6ZkbmgRwtN4m4xrGf rck9scQvAscRVcPGxU2EtDgLkw== X-Google-Smtp-Source: ABdhPJyQHgfBwOuxZe4jKbPW8Bh6p+5oyRfIuZ01yS2OUqW5IGG4LU5OzH1m8zljmYNdkq6n40Doew== X-Received: by 2002:a05:6e02:1545:: with SMTP id j5mr4392513ilu.168.1609943817372; Wed, 06 Jan 2021 06:36:57 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id k5sm1674989ioa.27.2021.01.06.06.36.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 06:36:56 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_ACEB3287-069E-4D89-A7CE-9505EF43AFB7" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Wed, 6 Jan 2021 09:36:54 -0500 In-Reply-To: <684e3296-a9d9-c899-9964-d80d693c1971@si6networks.com> Cc: David Farmer , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> To: Fernando Gont References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <684e3296-a9d9-c899-9964-d80d693c1971@si6networks.com> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 14:37:00 -0000 --Apple-Mail=_ACEB3287-069E-4D89-A7CE-9505EF43AFB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 6, 2021, at 9:04 AM, Fernando Gont wrote: > If not "local" or "explicit", maybe one of the others suggestions = above would work? =E2=80=9Cprivate=E2=80=9D isn=E2=80=99t bad. --Apple-Mail=_ACEB3287-069E-4D89-A7CE-9505EF43AFB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 6, 2021, at 9:04 AM, Fernando Gont <fgont@si6networks.com> wrote:
If not "local" or "explicit", maybe one of the others = suggestions above would work?

=E2=80=9Cprivate=E2=80=9D isn=E2=80=99t = bad.

= --Apple-Mail=_ACEB3287-069E-4D89-A7CE-9505EF43AFB7-- From nobody Wed Jan 6 07:13:46 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C2C3A0FD0; Wed, 6 Jan 2021 07:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.009, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxZDyELjCJ_6; Wed, 6 Jan 2021 07:13:38 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5D53A0FBF; Wed, 6 Jan 2021 07:13:35 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kxAVC-0000KhC; Wed, 6 Jan 2021 16:13:34 +0100 Message-Id: To: ipv6@ietf.org Cc: Fernando Gont , IPv6 Operations Subject: Re: Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> In-reply-to: Your message of "Wed, 6 Jan 2021 11:26:57 -0300 ." Date: Wed, 06 Jan 2021 16:13:31 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 15:13:45 -0000 >> In my opinion we should leave scope the way it is. > >The current definition of global scope as per RFC4007 doesn't match the >definition of ULAs as being global scope. Both of them can't be right. Some things don't need fixing even if they are not 100% correct. Yes, we can define global scope (in the context of unicast) as anything that is not link-local. And that would be nice for a bis document. But why bother? >"scope" and "zone" are part of the architecture. So we have a IPv6 >Scoped Addressing Architecture, and then a definition ULAs that doesn't >really comply with that definition. Effectively we have only two scopes: link-local and 'other'. What we need to do is simply things, not create a bigger mess. We don't need zone IDs that try to identify the scope of a ULA. All of this was part of attempts to define local addresses. It didn't work. We need to redefine zone IDs as interface IDs and clean up a lot of that stuff. (It is possible that multicast is different, I haven't done multicast beyond a single subnet for ages) >Changing the formal scope of ULAs does change the expectation when it >comes to their usage: i.e., ULAs are not expected to be globally unique. >They are just expected to have small chances of collision if you >connected a limited number of ULA-based networks. Networks don't just connect by themselves. Networks admins who connect two networks are not going the read RFC 4007 and conclude from the definition of scope that is safe to connect the networks. People also connect RFC 1918 networks and have to deal with the consequences. This is why operational documents could help. >Besides, this does have an impact on current libraries (such as Python's >ipaddress) and other libraries or macros that may have been defined for >other languages, or that may be defined in the future. The IETF does not define APIs for Python libraries, so I don't see why we would need to change the scope of ULA to accomodate them. We could call ULA 'private' if that would help python devs. But they can just well call ULA 'private' without involving the IETF. >This in turn probably affects the use such apps make of a list of >addresses, when more than one is available. Applications should not do widely different things if they encouter a ULA. We have policy tables for source and destination address selection. Those should be used to decide what to do. >The problem is that for ULAs to be marked as "non-global" (whatever we >call that), RFC4291 needs to be updated. Also, at least a part of >RFC4193 needs to be updated. They don't need to be marked 'non-global'. Changing the scope of ULA serves no purpose. From nobody Wed Jan 6 07:30:08 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EC53A0EA4 for ; Wed, 6 Jan 2021 07:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfG4iD9LtWZE for ; Wed, 6 Jan 2021 07:30:01 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422EB3A0EB5 for ; Wed, 6 Jan 2021 07:30:00 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id e22so2540672iom.5 for ; Wed, 06 Jan 2021 07:30:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O7L9LgvfK4hgI5B/LXK8N1uy/dWphdiXI5FDOydoy04=; b=OrlGgfBIWTreWb9phjW2WEFAH8BthF/m3q4GZOu6sSj1qLbEbQGSPEa86IFny7q5pn 7A330dkL7wPNwM/ofDBrvxA4UPehCP0PklTQZUzrvVsDeR7fhpIAow+KUKaq1wbEwqwH Go+4j/fAJUga24LQi8QhmD0kKx9Toq27jFgKIGdjUuzgvzGobkO16Hj/qPWUNc7xyR9C +utRSvgEhNcQIcMSAz5yrB+eSY9ugCFRmDW+C9ZOSQSl1ADQIiI+AOQCwb4HPB44hPHI XZ4wS+f1/eVJfynWaM+6iI17RhfID1QjUJz98V0A11jxz+tGiN5KUEz/gAHY4X3lE4xK 6Dxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O7L9LgvfK4hgI5B/LXK8N1uy/dWphdiXI5FDOydoy04=; b=UY2WPlYWdPFvONOLLO30wgmoWANbP+V2rrxQYRK0srk+KZAfeqCBwoQL7nOsiNHFqd N4Cm2DnvqFyVM9mHGbVRTwRUnemswLHzhOogQ5I17HY+MVerOsdUK44ttKFEI2AMAQBp H7Pd+w9gmepoatHqwqMQTcmKS10BrU2fppnE8x79Eh0G1iBgzEb69LF7E6PWX1UZZTEf Am2y03oQa0nUPyT5aT4HguGSImJpIg8cbKDBxL748UUldqp+01GYq9sqhfIQbx1be7/2 vDAgLm00GnxdPlOztSOgrwLpfBXzZlimqWjB636i72G7ZqahOXrh2bMwcaRz/58nFBH7 ebKg== X-Gm-Message-State: AOAM530P0qRMsWolakoyF8S99WRQ59ZnUKNBvBV5WCwlmYjf0Ma0TYd3 LWiWoXYRnsuTrKNJp8ebhfO/VNZUp6bm67cK X-Google-Smtp-Source: ABdhPJw10KMDlSVnigRnEPGKbTVZC0oDFX2T6VN1zCLrd4/58k0zz0sOC3V+kvnJRBG/pmjOtjCr/A== X-Received: by 2002:a02:3541:: with SMTP id y1mr4044875jae.66.1609946999621; Wed, 06 Jan 2021 07:29:59 -0800 (PST) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com. [209.85.166.51]) by smtp.gmail.com with ESMTPSA id a15sm2286379ilh.10.2021.01.06.07.29.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Jan 2021 07:29:59 -0800 (PST) Received: by mail-io1-f51.google.com with SMTP id d9so3090202iob.6; Wed, 06 Jan 2021 07:29:58 -0800 (PST) X-Received: by 2002:a05:6638:2243:: with SMTP id m3mr4107610jas.115.1609946998679; Wed, 06 Jan 2021 07:29:58 -0800 (PST) MIME-Version: 1.0 References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> In-Reply-To: From: Richard Patterson Date: Wed, 6 Jan 2021 15:29:47 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Philip Homburg Cc: 6man WG , Fernando Gont , IPv6 Operations Content-Type: multipart/alternative; boundary="000000000000f6af3405b83cfe1e" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 15:30:03 -0000 --000000000000f6af3405b83cfe1e Content-Type: text/plain; charset="UTF-8" On Wed, 6 Jan 2021 at 15:14, Philip Homburg wrote: > > Applications should not do widely different things if they encouter a ULA. > > But they do. Some OSes will see the presence of a ULA address on an interface, and start sending AAAA queries, some will not. Some applications will see a ULA destination address and simply ignore it, preferring the IPv4 destination address returned. We need to ask the question why this is happening, and if the answer is "They're doing it wrong", great, let's point them at the existing RFCs and educate them, but if not...... we need to do something, and I think this I-D is a good starting point for WG discussion at least. We have policy tables for source and destination address selection. Those > should be used to decide what to do. As above, it's not just about simple routing table lookups, or source address selection. But I do also think there's room for improvement here as well, with a new scope for ULA. --000000000000f6af3405b83cfe1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 6 Jan 2021 at 15:14, Philip Hombu= rg <pch-ipv6-ietf-7@u-= 1.phicoh.com> wrote:

Applications should not do widely different things if they encouter a ULA.<= br>

But they do.
Some OSes wi= ll see the presence of a ULA address on an interface, and start sending AAA= A queries, some will not.
Some applications will see a ULA destin= ation address and simply ignore it, preferring the IPv4 destination address= returned.=C2=A0

We need to ask the question why t= his is happening, and if the answer is "They're doing it wrong&quo= t;, great, let's point them at the existing RFCs and educate them, but = if not...... we need to do something, and I think this I-D is a good starti= ng=C2=A0point for WG discussion at least.


=
We have policy tabl= es for source and destination address selection. Those
should be used to= decide what to do.

As above, it's not = just about simple routing=C2=A0table lookups, or source address selection. = But I do also think there's room for improvement here as well, with a n= ew=C2=A0scope for ULA.


=
--000000000000f6af3405b83cfe1e-- From nobody Wed Jan 6 07:42:48 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EE43A0F01; Wed, 6 Jan 2021 07:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPzbZjXLLcte; Wed, 6 Jan 2021 07:42:39 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D903A0FF3; Wed, 6 Jan 2021 07:42:36 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 186EA283833; Wed, 6 Jan 2021 15:42:32 +0000 (UTC) Subject: Re: Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Philip Homburg , ipv6@ietf.org Cc: IPv6 Operations References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> From: Fernando Gont Message-ID: Date: Wed, 6 Jan 2021 12:42:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 15:42:43 -0000 On 6/1/21 12:13, Philip Homburg wrote: >>> In my opinion we should leave scope the way it is. >> >> The current definition of global scope as per RFC4007 doesn't match the >> definition of ULAs as being global scope. Both of them can't be right. > > Some things don't need fixing even if they are not 100% correct. There's an architecture document, and a spec that doesn't follow it. That's a bug. I don't know if that means 45% correct or 95.4% correct. But it does mean that we have defined terms, and that we don't use them in a consistent manner. If we expect people to read our specs, and make sense out of them, we have fix them if we find issues. And, as noted, there are concrete implications: RFC4007 says ULAs are non-global, RFC4193 says that ULAs are global, and a Python library says ULAs are non-global. I don't think we want that. >> "scope" and "zone" are part of the architecture. So we have a IPv6 >> Scoped Addressing Architecture, and then a definition ULAs that doesn't >> really comply with that definition. > > Effectively we have only two scopes: link-local and 'other'. What we need to > do is simply things, not create a bigger mess. > > We don't need zone IDs that try to identify the scope of a ULA. All of this > was part of attempts to define local addresses. It didn't work. > > We need to redefine zone IDs as interface IDs and clean up a lot of that > stuff. You mean use interface IDs as zone IDs? >> Changing the formal scope of ULAs does change the expectation when it >> comes to their usage: i.e., ULAs are not expected to be globally unique. >> They are just expected to have small chances of collision if you >> connected a limited number of ULA-based networks. > > Networks don't just connect by themselves. Networks admins who connect two > networks are not going the read RFC 4007 and conclude from the definition of > scope that is safe to connect the networks. It must be clear what ULAs are, and what they are not. Part of that is acknowledging that their scope is not global. [...] >> Besides, this does have an impact on current libraries (such as Python's >> ipaddress) and other libraries or macros that may have been defined for >> other languages, or that may be defined in the future. > > The IETF does not define APIs for Python libraries, so I don't see why we would > need to change the scope of ULA to accomodate them. You seem to be missing my original point: The definition of ULAs as "global scope" contradicts the definition of "global scope" from RFC4007. We don't need to change the scope of ULAs to accommodate them. We need to change the scope of ULAs such that we don't have specs that contradict with each other (consistency). Most likely, when we have that, we'll end up accommodating the Python library as a side effect. They got it right, and we didn't. > We could call ULA 'private' if that would help python devs. But they can just > well call ULA 'private' without involving the IETF. So.. from the pov of RFC4007 ULAs are non-global. From the pov of RFC4193 ULAs are global. ... and you don't mean to fix that, but still expect devolopers from multiple languages to get that right, and programmers to make sense out of the outcome? >> This in turn probably affects the use such apps make of a list of >> addresses, when more than one is available. > > Applications should not do widely different things if they encouter a ULA. > > We have policy tables for source and destination address selection. Those > should be used to decide what to do. That's a "one size fits all". There are valid reasons for which you mihgt *not* want to do that, (including using ULAs for services that are expected to be local-only, not binding temporary addresses to listening sockets, etc., etc., etc.) >> The problem is that for ULAs to be marked as "non-global" (whatever we >> call that), RFC4291 needs to be updated. Also, at least a part of >> RFC4193 needs to be updated. > > They don't need to be marked 'non-global'. Changing the scope of ULA serves > no purpose. So what we do here is specifying protocols, and you argue that fixing inconsistencies when specs have conflicting definitions and usages serve no purpose? Me, that's the least I'd expect from us.... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 07:45:43 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784B43A0F01; Wed, 6 Jan 2021 07:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB0enQhHquVK; Wed, 6 Jan 2021 07:45:34 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223163A0F02; Wed, 6 Jan 2021 07:45:33 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B78BD283833; Wed, 6 Jan 2021 15:45:27 +0000 (UTC) Subject: Re: Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Richard Patterson , Philip Homburg Cc: 6man WG , IPv6 Operations References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> From: Fernando Gont Message-ID: Date: Wed, 6 Jan 2021 12:45:18 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 15:45:38 -0000 On 6/1/21 12:29, Richard Patterson wrote: > On Wed, 6 Jan 2021 at 15:14, Philip Homburg > > > wrote: > > > Applications should not do widely different things if they encouter > a ULA. > > > But they do. And good for them that they do. The ones that don't are the ones that end up e.g. posting ULAs and link-locals on the public-facing DNS. (I've had to do it myself when using dynamic DNS updates, for instance) Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 07:52:21 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4793A0F0A; Wed, 6 Jan 2021 07:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.009, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xi8YjGKBlH3; Wed, 6 Jan 2021 07:52:18 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED3913A0F01; Wed, 6 Jan 2021 07:52:16 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kxB6c-00007tC; Wed, 6 Jan 2021 16:52:14 +0100 Message-Id: To: ipv6@ietf.org Cc: Richard Patterson , IPv6 Operations Subject: Re: Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> In-reply-to: Your message of "Wed, 6 Jan 2021 15:29:47 +0000 ." Date: Wed, 06 Jan 2021 16:52:12 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 15:52:20 -0000 >We need to ask the question why this is happening, and if the answer is >"They're doing it wrong", great, let's point them at the existing RFCs and >educate them, but if not...... we need to do something, and I think this >I-D is a good starting point for WG discussion at least. This I-D doesn't seem to list anything that goes wrong in applications, let alone how applications are following the specs and getting it wrong. So I don't see how this I-D helps. We have a clear policy table for source and destination selection. I don't see anything in the draft that suggests that the table is wrong. From nobody Wed Jan 6 07:56:58 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC733A1043 for ; Wed, 6 Jan 2021 07:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWDKk0QA2L6q for ; Wed, 6 Jan 2021 07:56:46 -0800 (PST) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE493A102C for <6man@ietf.org>; Wed, 6 Jan 2021 07:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1609948605; x=1641484605; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=tPRDX7gtq+Z2TcN2QbW8MiDW495QusQdssI4UBiHxNk=; b=EKiOuIcor6LhXsfdQdTbr4RCKLmTYtkTi0s3VvQ/7JjQcaBl+1XTsJJV tqd225or+kLPamJOh5TB4o0K2mVAq65ZBOdZOEpG9sembSrWjssFWTQus wUUVUcKch/RXnipNqsPzBTH0fVVfpvQRQq5htsg3mju65SRLkIZBD7fXy DIvmV5CglDxX9upK6GT1W4UesjBB7/aNT59rujtLpi6tejmMe7YcrIutD 9BWquDACpX1V9/zJ3LZxMTD7eKQA5Muz2f9mG2Tt6jE+irMzTWxgx/Xtl Xt7cAQjQzw3eoGLnkjAN/oqSEFH3ABdIytf5OLOTqCGC53SMWMOsvIhc/ g==; IronPort-SDR: EwIXYSBC69vEKlhq+LKz9KkO/8NTRp7ZU17XdwdVBzI4RAszTP3cXeYUy6/0+4cMh/WZDpl3qS 7xZ/AYL6AXlV33ZmW6hkg6Fv0mJy2FEUJQGalSDwVO3d1vlNsSfagdxj/Lf63lpFjxM64Xh86f UqgXgt2EkpRXmDkRvHuhnG7tCqAd5/PLrolWi/NEiUm/mujiMo5yjM32K2hGwR+EFS+VwxxdHg FiCvefOTgm3mc4htF924qODlgHInlgJcsK+Qz2SXFecM3URmRlU8szf55K8Q+wcMD10eZ7NHfm fP4= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2021 16:56:42 +0100 X-Original-To: 6man@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C663743ACF for <6man@ietf.org>; Wed, 6 Jan 2021 16:56:42 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 6E10A427F9; Wed, 6 Jan 2021 16:56:42 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 6D65DDB2A; Wed, 6 Jan 2021 16:56:42 +0100 (CET) Date: Wed, 6 Jan 2021 16:56:42 +0100 From: Gert Doering To: Ted Lemon Cc: David Farmer , Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Message-ID: <20210106155642.GW13005@Space.Net> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 15:56:55 -0000 Hi, On Wed, Jan 06, 2021 at 07:17:33AM -0500, Ted Lemon wrote: > On Jan 5, 2021, at 11:38 PM, David Farmer wrote: > > I think this is the right direction the previous draft indirectly defined a new scope "non-global", I much prefer explicitly defining a new local scope. > > Actually, I think you???ve got it right here: the scope is ???non-global.??? Indeed. This sounds like a nice way to express the intended usage. "It is not link-local, but definitely not intended or usable for global usage, thus: 'non-global scope'" Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Jan 6 07:58:51 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE783A1262; Wed, 6 Jan 2021 07:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caYxS2B-TAAU; Wed, 6 Jan 2021 07:58:43 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D031A3A1267; Wed, 6 Jan 2021 07:58:04 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8089E2845F0; Wed, 6 Jan 2021 15:58:01 +0000 (UTC) Subject: Re: Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Philip Homburg , ipv6@ietf.org Cc: IPv6 Operations References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> From: Fernando Gont Message-ID: <127fd75f-eead-ba5c-ca4f-d9608246c73b@gont.com.ar> Date: Wed, 6 Jan 2021 12:57:21 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 15:58:50 -0000 On 6/1/21 12:52, Philip Homburg wrote: >> We need to ask the question why this is happening, and if the answer is >> "They're doing it wrong", great, let's point them at the existing RFCs and >> educate them, but if not...... we need to do something, and I think this >> I-D is a good starting point for WG discussion at least. > > This I-D doesn't seem to list anything that goes wrong in applications, > let alone how applications are following the specs and getting it wrong. Isn't it clear enough that the definition of ULAs as "global scope" contradicts the definition of global scope from RFC4007? That, from starters, needs to be fixed. Any library or macro that follows the definition of ULAs as being "global scope" will lead to ULAs leaking out of their zone, as e.g., posting them in the DNS. Because they are defined as "global scope", when they are not. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Jan 6 08:09:29 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C99B3A0F44; Wed, 6 Jan 2021 08:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwwKb6JASzus; Wed, 6 Jan 2021 08:09:23 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61973A10EB; Wed, 6 Jan 2021 08:09:15 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id CC83C2845F0; Wed, 6 Jan 2021 16:09:10 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Gert Doering , Ted Lemon Cc: David Farmer , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106155642.GW13005@Space.Net> From: Fernando Gont Message-ID: <49520404-ff67-ed9d-eb8e-c90491ae965e@si6networks.com> Date: Wed, 6 Jan 2021 13:01:59 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20210106155642.GW13005@Space.Net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 16:09:27 -0000 On 6/1/21 12:56, Gert Doering wrote: > Hi, > > On Wed, Jan 06, 2021 at 07:17:33AM -0500, Ted Lemon wrote: >> On Jan 5, 2021, at 11:38 PM, David Farmer wrote: >>> I think this is the right direction the previous draft indirectly defined a new scope "non-global", I much prefer explicitly defining a new local scope. >> >> Actually, I think you???ve got it right here: the scope is ???non-global.??? > > Indeed. This sounds like a nice way to express the intended usage. > > "It is not link-local, but definitely not intended or usable for global > usage, thus: 'non-global scope'" The only issue with using this term (non-global) is that it also applies to link-locals... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 08:14:01 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425EE3A0FAF; Wed, 6 Jan 2021 08:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXlLUhk0x8KV; Wed, 6 Jan 2021 08:13:58 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B423A0F9D; Wed, 6 Jan 2021 08:13:56 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kxBRZ-0000INC; Wed, 6 Jan 2021 17:13:53 +0100 Message-Id: To: ipv6@ietf.org Cc: Fernando Gont , IPv6 Operations Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> In-reply-to: Your message of "Wed, 6 Jan 2021 12:42:13 -0300 ." Date: Wed, 06 Jan 2021 17:13:50 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 16:13:59 -0000 >And, as noted, there are concrete implications: >RFC4007 says ULAs are non-global, RFC4193 says that ULAs are global, and >a Python library says ULAs are non-global. I don't think we want that. RFC 4007 does not mention ULA. I don't see why python libraries are relevant for what we do. >> We need to redefine zone IDs as interface IDs and clean up a lot of that >> stuff. > >You mean use interface IDs as zone IDs? No, rewrite RFC 4007 and get rid of zone IDs. And the introduce interface IDs to select the interface of an outgoing packet, whether link-local or global. It doesn't change anything in practice, because that is what existing code does. >It must be clear what ULAs are, and what they are not. Part of that is >acknowledging that their scope is not global. ULAs are not link-local addressses. That's the only thing we need to know. Yes, we could update the definition of global scope in RFC 4007 such that ULAs are included, but it strikes me as a waste of time. Unless, we are doing a bis document. >We don't need to change the scope of ULAs to accommodate them. We need >to change the scope of ULAs such that we don't have specs that >contradict with each other (consistency). Most likely, when we have >that, we'll end up accommodating the Python library as a side effect. >They got it right, and we didn't. Like I said, the definition of global scope in RFC 4007 can be fixed if we would care enough. >... and you don't mean to fix that, but still expect devolopers from >multiple languages to get that right, and programmers to make sense out >of the outcome? Developers should not use scope to mean anything. Maybe some applications need to do something special when they encouter certain addresses. In that case they can directly list the prefixes that need special treatment. There is no need to come up with convoluted library schemes that try to classify addresses. That only causes operational nightmares. >> We have policy tables for source and destination address selection. Those >> should be used to decide what to do. > >That's a "one size fits all". There are valid reasons for which you >mihgt *not* want to do that, (including using ULAs for services that are >expected to be local-only, not binding temporary addresses to listening >sockets, etc., etc., etc.) Do you propose to introduce new scopes for temporary addresses? The I-D we are discussion doesn't describe these issues in the problem statement. Maybe you want to go back to the problem statement and describe what you really want to solve. From nobody Wed Jan 6 08:27:03 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866143A0FC2 for ; Wed, 6 Jan 2021 08:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaspjoN5oymk for ; Wed, 6 Jan 2021 08:26:57 -0800 (PST) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04E73A0FC3 for ; Wed, 6 Jan 2021 08:26:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1609950416; x=1641486416; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ca8JMmgl+idm3kxJhO5x4N/rOegglqWBI+42lAtFmgE=; b=L5djBtzRiUVkUcXTIgj9i3+qIj/3TqiI0ltVmpZE8etrluUXBZxuuEU6 EsbVB62LEEzVGsDplKsvScfUysaQ2S4pR2b7zFBwJ33JBD/5Vqx7gVNDv UDCgEHMcCRd+Ts5sM+vfFF77kNsUdqR9pwyVWqY/i2vQNQp69bRrJ6mDf VIPMMcEqtx5TEgg0lR/Dls/VbY0w2UHBOEyjmZ+OS5uZApkQJTMjlURwI Z8GFosU2XadjLLo1/+bMz7E04FWgU5KhaEFK5bcLlvFTiA850BM11etvx sgkwVPqU4ajh8JUroeyS1e+FW4ZKSySI+Z9wRarKsxOHziGNh8LlHK9S2 w==; IronPort-SDR: Z/cWxzPn8sMQ7BFTKZzoG4tFhGMAHE698tAy0eoehkB880/AUeuoCss8jGuSb8BfvOdW37czzP tE10E8277BHFujgIA9N817M2gztFNpsgub6o6xnGfgo104lgHbmg/cZCCTXV6vYT3BVgvh+msJ oHH+HFx0RzMjvb1BHEDD1LEb5bcEXxd5uAmvyFntr22HMhx7MTntmfsoYki0/3J4R8TloZP9bz I8FX2z9lXYnm9Zafb8IL7YusKHcwL2RaGvIrMhB6g76o+ppclspS8DSgOkAfz8voWCdD389Wwy nsM= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2021 17:26:52 +0100 X-Original-To: ipv6@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C42CB43AD1 for ; Wed, 6 Jan 2021 17:26:52 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 8611943AC3; Wed, 6 Jan 2021 17:26:52 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 80A80E7EF; Wed, 6 Jan 2021 17:26:52 +0100 (CET) Date: Wed, 6 Jan 2021 17:26:52 +0100 From: Gert Doering To: Fernando Gont Cc: Philip Homburg , ipv6@ietf.org, IPv6 Operations Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Message-ID: <20210106162652.GX13005@Space.Net> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 16:26:59 -0000 HI, On Wed, Jan 06, 2021 at 12:42:13PM -0300, Fernando Gont wrote: > And, as noted, there are concrete implications: > RFC4007 says ULAs are non-global, RFC4193 says that ULAs are global, and > a Python library says ULAs are non-global. I don't think we want that. On a tangent, I wonder why this is relevant at all. Why should applications, or anything that is not an admin, care if an address is a ULA or a GUA? (I can see the bit about "tools that enter GUAs in the global DNS", but this is very special anyway - because "DNS" might not be "global", so general "refuse to put ULA into DNS" is not correct behaviour either) Consistent terminology is important, true, and if we just want to make sure that something can properly flag a ULA different than a GUA, we could just introduce "mid-range scoped" or rename the scopes to be 0 (link-local), 5 (mid-range), 10 (global)... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Jan 6 08:51:55 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3273A0FE8; Wed, 6 Jan 2021 08:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8a5tmgnpUa6; Wed, 6 Jan 2021 08:51:50 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25B03A0DDD; Wed, 6 Jan 2021 08:51:49 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5EDC8284F56; Wed, 6 Jan 2021 16:51:45 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Philip Homburg , ipv6@ietf.org Cc: IPv6 Operations References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> From: Fernando Gont Message-ID: <1beb9c59-28ef-ac69-d5d3-7bfba0f70606@si6networks.com> Date: Wed, 6 Jan 2021 13:36:10 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 16:51:53 -0000 On 6/1/21 13:13, Philip Homburg wrote: >> And, as noted, there are concrete implications: >> RFC4007 says ULAs are non-global, RFC4193 says that ULAs are global, and >> a Python library says ULAs are non-global. I don't think we want that. > > RFC 4007 does not mention ULA. RFC4007 defines what "scope" and "global scope" are. RFC4193 defines ULAs to be global scope. But ULAs (defined in RFC4193 as global scope) contradict the definition of global scope from RFC4007. Hence the connection between the two. >>> We need to redefine zone IDs as interface IDs and clean up a lot of that >>> stuff. >> >> You mean use interface IDs as zone IDs? > > No, rewrite RFC 4007 and get rid of zone IDs. And the introduce interface IDs > to select the interface of an outgoing packet, whether link-local or global. At the end of the day, when you do that, the interface is being employed as the zone ID. >> It must be clear what ULAs are, and what they are not. Part of that is >> acknowledging that their scope is not global. > > ULAs are not link-local addressses. That's the only thing we need to know. *That is not how they are specified in RFC4193*! [...] >> We don't need to change the scope of ULAs to accommodate them. We need >> to change the scope of ULAs such that we don't have specs that >> contradict with each other (consistency). Most likely, when we have >> that, we'll end up accommodating the Python library as a side effect. >> They got it right, and we didn't. > > Like I said, the definition of global scope in RFC 4007 can be fixed if we > would care enough. It's the definition of ULAs as global scope that is incorrect. NOt the other way around. >> ... and you don't mean to fix that, but still expect devolopers from >> multiple languages to get that right, and programmers to make sense out >> of the outcome? > > Developers should not use scope to mean anything. Maybe some applications > need to do something special when they encouter certain addresses. In that > case they can directly list the prefixes that need special treatment. Applications should deal with prefixes. If anything, they should deal with address properties. > There is no need to come up with convoluted library schemes that try to > classify addresses. That only causes operational nightmares. You get operational nightmares when you get multi-scoped addresses and you have no clue about the differences and what to do with them. Crawl Alexa's Top-1M sites, and look at the IPv6 addresses. You find anything from loopback, to unspecified address, to link-locals, and ULAs. >>> We have policy tables for source and destination address selection. Those >>> should be used to decide what to do. >> >> That's a "one size fits all". There are valid reasons for which you >> mihgt *not* want to do that, (including using ULAs for services that are >> expected to be local-only, not binding temporary addresses to listening >> sockets, etc., etc., etc.) > > Do you propose to introduce new scopes for temporary addresses? Huh? I'm saying: "There are valid reasons for which you mihgt *not* want to do that, (including using ULAs for services that are expected to be local-only, not binding temporary addresses to listening sockets, etc., etc., etc.)" that is: given a bunch of addresses with different properties, most likely applications do need to look at their properties to make appropriate use for them. We're talking about the ULA scope being in contradiction with the "global scope definition". > The I-D we are discussion doesn't describe these issues in the problem > statement. Problem #1: The IETF publishes protocol specifications. We have two protocol specifications that contradict each other. Someone that reads both RFC4007 and RFC4193 will have an interesting WTH moments. For the rest of the stuff, I said it already. THere's no point in re-hashing the same arguments over and over again. > Maybe you want to go back to the problem statement and describe what you > really want to solve. ---- cut here ---- 5.1. Address Attributes in Programming Languages Python's ipaddress library [Python-ipaddr] defines 'IPv6Address' objects that have a number of attributes, including: o 'True' if the address is allocated for private networks. o 'True' if the address is allocated for public networks. For ULAs, the is_private attribute is 'True', while the is_global attribute is 'False'. This contradicts the definition of ULAs as having "global scope" [RFC4291] [RFC4193], but is in line with the specification update performed by this document (see Section 6). ---- cut here ---- This will be faced by every other library or macro in every other language. ---- cut here ---- 6. Specification Updates The ultimate goal is to employ coherent terminology and definitions throughout the relevant protocol specifications. Probably the only option to achieve this goal is update the definition of ULAs as having "local scope", with "local scope" defined as "larger than link-local, and smaller than global" (based on ULAs being defined as "local addresses"). ---- cut here ---- The least we can aim at is consistency among our own specs, right? ... and one should also add to the list "a clarification of the expectations regarding ULAs. Because many (including myself in the very recent past) had the assumption that ULAs are globally-unique, when they are not. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 08:52:10 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C4F3A105E; Wed, 6 Jan 2021 08:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iWwMfJTDdwR; Wed, 6 Jan 2021 08:51:54 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1893A0FE8; Wed, 6 Jan 2021 08:51:54 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2841E284F56; Wed, 6 Jan 2021 16:51:50 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Gert Doering Cc: Philip Homburg , ipv6@ietf.org, IPv6 Operations References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> From: Fernando Gont Message-ID: <1ddf8850-a8cb-53a7-31bc-7433d5a984f2@si6networks.com> Date: Wed, 6 Jan 2021 13:46:51 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20210106162652.GX13005@Space.Net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 16:52:01 -0000 Hi, Gert, On 6/1/21 13:26, Gert Doering wrote: > HI, > > On Wed, Jan 06, 2021 at 12:42:13PM -0300, Fernando Gont wrote: >> And, as noted, there are concrete implications: >> RFC4007 says ULAs are non-global, RFC4193 says that ULAs are global, and >> a Python library says ULAs are non-global. I don't think we want that. > > On a tangent, I wonder why this is relevant at all. > > Why should applications, or anything that is not an admin, care if an > address is a ULA or a GUA? I can report on my own case: I have Raspberry Pis that deploy here and there. In order to be able to access them, they use dynamic DNS to post their addresses on their DNS. If I don't look at the properties of the addresses, then I end up puting crap on the DNS. One straightforward consequence is that many apps that don't do Happy Eyeballs end up having an insane connection-establishment period, if they happen to try the unusable addresses first. So "find all your IPv6 addresses and post them to the DNS" doesn't work. > (I can see the bit about "tools that enter GUAs in the global DNS", > but this is very special anyway - because "DNS" might not be "global", > so general "refuse to put ULA into DNS" is not correct behaviour either) What I do is: For each node, I have one domain name for global addresses, and another for non-globals. > Consistent terminology is important, true, and if we just want to make > sure that something can properly flag a ULA different than a GUA, we > could just introduce > > "mid-range scoped" > > or rename the scopes to be 0 (link-local), 5 (mid-range), 10 (global)... Any of those options are totally fine. The point is that ULAs don't have the "global scope" properties described in RFC4007. It is not acceptable to have folks that do their homework and read RFC4291/RFC4007, and then read other documents and are left scratching their heads. If we can't fix specs when we have inconsistencies, I don't think we can expect people to make sense out of them. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 09:06:50 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB963A1010 for ; Wed, 6 Jan 2021 09:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6EejdIn-WF4 for ; Wed, 6 Jan 2021 09:06:44 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE0F3A1014 for ; Wed, 6 Jan 2021 09:06:43 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id r9so3385038ioo.7 for ; Wed, 06 Jan 2021 09:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=g3ZhDyVo/k42I6I/PMldshUEnV86D5MYCjlxBflZFOg=; b=OX8kEYr2tIktHcDv2DhyOCtBn0Ndl3jDaQWjWj+3/4BUxT83EFPP+c2UB4dr6gGAqq DlIX9kaGxhtbldkdYJMpsRUvXYAYQ00NRS2rd105Rdby8KN43X+nNTJdXdwLjdtMjtJc WJZp97kBBuF1rPa0POO8BeHVswEvwTfJOAa3YgclQQ4+vabFFmeDYdZZ7rbVGNxvAH7F aJYDjDjBzWc1MOzeyTI7BN6tcngX1/ParQaYol3SPsf43ZZ/yGY42O3noDWwCd/KCBrF TirYwU+Tqq72/TDj9PDczrXT5wStsLPfA2H7XNtBrMV15/elly/XNVOaZhIYCtZlIkc2 SUpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=g3ZhDyVo/k42I6I/PMldshUEnV86D5MYCjlxBflZFOg=; b=ZlezPb1UdhKVvyKhBpIggRbcKuroWKzWO6IeInfd1qk2HbqRlM/UmwAz2+Ous/nM9S EKqRv3otjN2Hqc2zzWSlhvp2c8UTe8HWCnWcpJKQpKJ61B0kpruVPTtSUEUWDqXfOpkY 5ngTIJS8hqKadafXgAH+WYteqOQIS/rPqk6/KWyWUR+DcNxgObKnpi6wQ9U+BEik10mu +t2Y5FzmuoHV3hcVcoZf+sTrSK+IbPEK0PpsECBVqGPGGVZuAdZbG+cTJpj+8get6FjP TaxcjgsBejWKigw4xKEH7bIpde/E8YA8CCPVH1DYG8U1pUvB0RXjF8wmh6C91X3B3ONb 3wZQ== X-Gm-Message-State: AOAM5320LOawKCZg4ean4vvm03laM5ZFn6U/cYqejvYv8L0SWph7h4M6 sEb+/Hz2W1IaN8h+dsucdh+D8A== X-Google-Smtp-Source: ABdhPJw6TcUNiaKcZaFq7wC7T4VUNmBJapk03H1FzkD0vbFFeE9ACmITw4Nc/BHFNMMB58AFy82cuw== X-Received: by 2002:a02:b011:: with SMTP id p17mr4484495jah.55.1609952803332; Wed, 06 Jan 2021 09:06:43 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id i6sm2249819ilm.70.2021.01.06.09.06.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 09:06:42 -0800 (PST) From: Ted Lemon Message-Id: <88297320-9516-4627-A673-FBFDA6A10B0C@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BA223DAC-C9A6-4053-8D2A-5D3045ED3765" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Wed, 6 Jan 2021 12:06:39 -0500 In-Reply-To: <20210106162652.GX13005@Space.Net> Cc: Fernando Gont , IPv6 Operations , Philip Homburg , ipv6@ietf.org To: Gert Doering References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 17:06:46 -0000 --Apple-Mail=_BA223DAC-C9A6-4053-8D2A-5D3045ED3765 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 6, 2021, at 11:26 AM, Gert Doering wrote: > or rename the scopes to be 0 (link-local), 5 (mid-range), 10 = (global)=E2=80=A6 This implies concentric circles, which isn=E2=80=99t really valid. = Different ULAs can have disjoint or overlapping applicability. I agree = with a previous comment that talking about this in terms of scope = doesn=E2=80=99t make much sense. I don=E2=80=99t know how to write code = that takes into account the difference in scope between ULA and GUA, = other than perhaps in routing protocols. --Apple-Mail=_BA223DAC-C9A6-4053-8D2A-5D3045ED3765 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 6, 2021, at 11:26 AM, Gert Doering <gert@space.net> = wrote:
or rename the = scopes to be 0 (link-local), 5 (mid-range), 10 = (global)=E2=80=A6

This implies concentric circles, which isn=E2=80=99t = really valid. Different ULAs can have disjoint or overlapping = applicability. I agree with a previous comment that talking about this = in terms of scope doesn=E2=80=99t make much sense. I don=E2=80=99t know = how to write code that takes into account the difference in scope = between ULA and GUA, other than perhaps in routing protocols.

= --Apple-Mail=_BA223DAC-C9A6-4053-8D2A-5D3045ED3765-- From nobody Wed Jan 6 09:10:36 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670D13A1018 for ; Wed, 6 Jan 2021 09:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9q0CV-uattGA for ; Wed, 6 Jan 2021 09:10:30 -0800 (PST) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38CBA3A1016 for ; Wed, 6 Jan 2021 09:10:29 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id a13so1540312qvv.0 for ; Wed, 06 Jan 2021 09:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yt0ZHOktr4ML5Bf/HT33ja6/SmubbXEHNR3xroi0C9I=; b=aHAqRW0AYIzhoCCN7rAUqyOILKC6TvSWWpOdGclj1XR7fInSpCy2YlrLM5e3DimzaK wpkxQXr2mFr8mx/xGqGbRL0flnufZvXfq+9DP4dwOE1PUxJZrv1YSqgbdAmsH7N0Z4gK 7wARfnQhiQmFNMjyR1xD0c3crDzoDg2DL0zYiChwXg7HoaSwLlIpw50RJ0J2GyuIHSjf WJpuT8hxhbRX0cEYphwSy5YGVtagbsJNZ8TrA1OP6giTAtA2oH6BfSNGpmym29/ETRUI EpcZ6BAYro9Wd6dDJJFMDZo25o3NP3tuDqcejg9nTYTZYnEmWA8wjVZmSQqRm13q876Q QvqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=yt0ZHOktr4ML5Bf/HT33ja6/SmubbXEHNR3xroi0C9I=; b=B9RUI5URi38BomH4EI7dmBSNNv5/F/FAT7kWJc8wWg85xFhJ5zIMzJZeTsvAgiqadK WMmRGiye0MV8mrmibdtcqlyeu2MSrczUt/AtLRzDHaDLkGmXFvykin/TJJ0wn0J0mGe5 bL6L6fIewpoiO7w+qWWxt0y+X1i4ciTPBqoRTyWD7qCEX8hKpnTSwMnIZSCLIIP6Yiju UlcmdEyKZZ9vabO3PN4bt3WeVR7SfU5U/8ppaKGTAZ98UZztdpvIS/3pBZkYR6oPgAH/ gUqO+QcqWqRmg68ppUp6vm5bDdwt5gEEF9lmZwG28+Ji9puoudagO1t7Fqdp+X2/kA8x ZaVQ== X-Gm-Message-State: AOAM531kVCDcYtuDe4ZRF3xIkpereUYMIifoVr/NqdZTvXRS/gxD189r RkKlVM3z1pvRZNRytK4INCduaA== X-Google-Smtp-Source: ABdhPJwfBN5Q4ugTr51+dHCH70g66tSA+6GVvO2bXXYDoDhL+XFGOOTMmn3vOBYs9E4NZfRHl0lVfA== X-Received: by 2002:a05:6214:487:: with SMTP id ay7mr4705144qvb.37.1609953029088; Wed, 06 Jan 2021 09:10:29 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id r22sm1607040qkk.67.2021.01.06.09.10.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 09:10:28 -0800 (PST) From: Ted Lemon Message-Id: <1089BC1B-A8E6-4BF5-BB3E-FD440181DB56@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_709B8E6A-B91B-489C-92F8-A4AD0698AE32" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Wed, 6 Jan 2021 12:10:26 -0500 In-Reply-To: <1ddf8850-a8cb-53a7-31bc-7433d5a984f2@si6networks.com> Cc: Gert Doering , IPv6 Operations , Philip Homburg , ipv6@ietf.org To: Fernando Gont References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> <1ddf8850-a8cb-53a7-31bc-7433d5a984f2@si6networks.com> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 17:10:31 -0000 --Apple-Mail=_709B8E6A-B91B-489C-92F8-A4AD0698AE32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 6, 2021, at 11:46 AM, Fernando Gont = wrote: > I have Raspberry Pis that deploy here and there. In order to be able = to access them, they use dynamic DNS to post their addresses on their = DNS. > If I don't look at the properties of the addresses, then I end up = puting crap on the DNS. One straightforward consequence is that many = apps that don't do Happy Eyeballs end up having an insane = connection-establishment period, if they happen to try the unusable = addresses first. >=20 > So "find all your IPv6 addresses and post them to the DNS" doesn't = work. It is of course not even obvious how to solve this, because sometimes = you do want ULA in DNS, and sometimes you don=E2=80=99t. And it depends = on what DNS. If you are doing split DNS, then you can scope the DNS that = advertises ULAs only to serve those networks where those ULAs are = in-scope. The DNS that is advertised globally would of course contain no = ULAs. How this is arranged is either a matter of local configuration or = an interesting topic of future work, depending on how you look at it. --Apple-Mail=_709B8E6A-B91B-489C-92F8-A4AD0698AE32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 6, 2021, at 11:46 AM, Fernando Gont <fgont@si6networks.com> wrote:
I have Raspberry Pis that deploy here and there. In order to = be able to access them, they use dynamic DNS to post their addresses on = their DNS.
If I don't = look at the properties of the addresses, then I end up puting crap on = the DNS. One straightforward consequence is that many apps that don't do = Happy Eyeballs end up having an insane connection-establishment period, = if they happen to try the unusable addresses first.

So "find all = your IPv6 addresses and post them to the DNS" doesn't = work.

It = is of course not even obvious how to solve this, because sometimes you = do want ULA in DNS, and sometimes you don=E2=80=99t. And it depends on = what DNS. If you are doing split DNS, then you can scope the DNS that = advertises ULAs only to serve those networks where those ULAs are = in-scope. The DNS that is advertised globally would of course contain no = ULAs. How this is arranged is either a matter of local configuration or = an interesting topic of future work, depending on how you look at = it.

= --Apple-Mail=_709B8E6A-B91B-489C-92F8-A4AD0698AE32-- From nobody Wed Jan 6 09:11:58 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901623A100F; Wed, 6 Jan 2021 09:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1XyCEExApZz; Wed, 6 Jan 2021 09:11:54 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D80C3A11A8; Wed, 6 Jan 2021 09:11:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 61B12389AF; Wed, 6 Jan 2021 12:12:39 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KEdkm-ER0ceQ; Wed, 6 Jan 2021 12:12:39 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F08C6389AE; Wed, 6 Jan 2021 12:12:38 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7705B240; Wed, 6 Jan 2021 12:11:32 -0500 (EST) From: Michael Richardson To: Fernando Gont cc: Gert Doering , IPv6 Operations , ipv6@ietf.org Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) In-Reply-To: <1ddf8850-a8cb-53a7-31bc-7433d5a984f2@si6networks.com> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> <1ddf8850-a8cb-53a7-31bc-7433d5a984f2@si6networks.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 17:11:57 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > On 6/1/21 13:26, Gert Doering wrote: >> HI, >> >> On Wed, Jan 06, 2021 at 12:42:13PM -0300, Fernando Gont wrote: >>> And, as noted, there are concrete implications: >>> RFC4007 says ULAs are non-global, RFC4193 says that ULAs are global= , and >>> a Python library says ULAs are non-global. I don't think we want th= at. >> >> On a tangent, I wonder why this is relevant at all. >> >> Why should applications, or anything that is not an admin, care if an >> address is a ULA or a GUA? > I can report on my own case: > I have Raspberry Pis that deploy here and there. In order to be able = to > access them, they use dynamic DNS to post their addresses on their DN= S. > If I don't look at the properties of the addresses, then I end up put= ing crap > on the DNS. One straightforward consequence is that many apps that do= n't do > Happy Eyeballs end up having an insane connection-establishment perio= d, if > they happen to try the unusable addresses first. > So "find all your IPv6 addresses and post them to the DNS" doesn't wo= rk. And, yet, for the case where some device is doing dynamic DNS update to a D= NS server that is within some ULA scope, posting the ULA to the DNS is actually correct. But, it's hard to know that without knowing what clients are expected to co= nnect. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/170QACgkQgItw+93Q 3WX1Hwf+P4UUyzktb1Z1VEOErPH0H7cGHcq3bIYXcN6+3+paw2fGIui4tD6RIeDt 2fIU+bfW5djoS6SPGnx3BJ6RnbRlifexrxNFs+6cZdrG/f5DcOk78rfAvx7YUWEr jDOJcUa+yFuhFb+aTLqiWNZAehZaTVfiP6ond8M16zNdg/cU8o1IoxKfZR33lt0C TFEqxkYcUjFSQL9FFRot1Pebx+MS+LRDg5nzGHByqxWswNcT/1zx+RKY563aT5gL 2M2ekeU3OCccK6aujSMIsSKkV+XWIQoZcGLOmMYNBLUBgAFn+h73A47Pethv4iYG 62i7kSVuMjypJbloH0kXHFDjdptFZA== =N3el -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 6 09:21:06 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2763A103D for ; Wed, 6 Jan 2021 09:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z53PI2V6znVm for ; Wed, 6 Jan 2021 09:20:59 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A42D3A0FFD for ; Wed, 6 Jan 2021 09:20:59 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id n142so3128238qkn.2 for ; Wed, 06 Jan 2021 09:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hVhd3Mrd/3yE9Sf4MQ+Yg3zxjyIot/MsStZtU4gZcmc=; b=j2Ab9R1ZE/UdQMQMmz+256www/3e9BX0lr6wUXWj2NVAE8r3QRQ9LE/dXEqcad4X+X N86SY+4S20RpaaoK1G/79MDueObyXb45eVMWfsIj0BuGlGmln3H9/fM+hpO1Qkl86brq BrGSl8jz6VHqTLoyRi5VsqFIxuIvmUotsQ1p7VkURMpc7ygAh5/Y5ORiWd2EWibVDEPe vll4lmA9bgSFbuQZ7qBmnyhAfsJO1MpkllRmKkJzvHezkNEtnZ4swzBUWcb/PnaFGvB5 uWMOhHT3fMQ5TlCtON24/o2KBKLWdorZrkAxcehpFDQCf2FZDY4x4hKLgd3a6mVy9oMD axFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hVhd3Mrd/3yE9Sf4MQ+Yg3zxjyIot/MsStZtU4gZcmc=; b=Buu53QRAvE3UgJ8xNm1u5uHQfgWzn8Ltczp53LV+gnPOvSDz+24tZ3gPQtDSCd5vme RIcU3bQSSUCL+7vCaph5R29mBEcxqdkT3lYWEptz5ClLnXIQfXvhSBWr8J7u6kO9vG/v eRmf/hwVcivnXX3FhZClg0DcN/wLjYXEryI7hGz2TXnm3kLn8bjMYYpnytTik3phZshP anTKTfqqbNbjzyXKm9Y4a3aUBTVxFCk0YSVEWAicG+GiYezbWTpYQVQe/CsbiN3v3hlL +a3hr7sUkTFDdEUCwqyNuvWNKQBa4e6XnUm+Z5goSNMUEFulFwG6SXI7LE5W38ZOsjWy KW2A== X-Gm-Message-State: AOAM533Yl2xdNgBy/SwbVgsKXfjbz7UoEJ0szKGoQ/Q6MDMT95nP5mVK NxH88GcosHSUv8+Dw/LertMX5g== X-Google-Smtp-Source: ABdhPJy/inGdaceZXDRkkj+2dMwblA7gSIz4BtbfDAyJvmWlbHsOrRDQzDk9mQ7IINPqR8DyWNnTsQ== X-Received: by 2002:a37:642:: with SMTP id 63mr5308505qkg.123.1609953658182; Wed, 06 Jan 2021 09:20:58 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id c136sm1700371qkg.71.2021.01.06.09.20.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 09:20:57 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A28683EA-943E-4F3B-BAD2-FAC9C11F86EE" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Wed, 6 Jan 2021 12:20:54 -0500 In-Reply-To: <1169.1609953092@localhost> Cc: Fernando Gont , IPv6 Operations , ipv6@ietf.org, Gert Doering To: Michael Richardson References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> <1ddf8850-a8cb-53a7-31bc-7433d5a984f2@si6networks.com> <1169.1609953092@localhost> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 17:21:02 -0000 --Apple-Mail=_A28683EA-943E-4F3B-BAD2-FAC9C11F86EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 6, 2021, at 12:11 PM, Michael Richardson = wrote: > And, yet, for the case where some device is doing dynamic DNS update = to a DNS > server that is within some ULA scope, posting the ULA to the DNS is = actually > correct. > But, it's hard to know that without knowing what clients are expected = to connect. It seems straightforward that the client should send all the addresses = it wants to advertise, and the DNS server should decide which ones to = advertise in what scopes. --Apple-Mail=_A28683EA-943E-4F3B-BAD2-FAC9C11F86EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Jan 6, 2021, at 12:11 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
And, yet, for the case where some device is doing dynamic DNS = update to a DNS
server that is within some ULA scope, posting the ULA to the = DNS is actually
correct.
But, it's hard to know that without knowing what clients are = expected to connect.

It seems straightforward that the client should send all the = addresses it wants to advertise, and the DNS server should decide which = ones to advertise in what scopes.

= --Apple-Mail=_A28683EA-943E-4F3B-BAD2-FAC9C11F86EE-- From nobody Wed Jan 6 09:29:19 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810A43A1049; Wed, 6 Jan 2021 09:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKbDBDPRtvRy; Wed, 6 Jan 2021 09:29:16 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2213A0FFD; Wed, 6 Jan 2021 09:29:15 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 117482839E5; Wed, 6 Jan 2021 17:29:10 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Ted Lemon , Gert Doering Cc: IPv6 Operations , Philip Homburg , ipv6@ietf.org References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> <88297320-9516-4627-A673-FBFDA6A10B0C@fugue.com> From: Fernando Gont Message-ID: <035a725a-19bf-efae-bf13-15e8dae4cc97@si6networks.com> Date: Wed, 6 Jan 2021 14:26:56 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <88297320-9516-4627-A673-FBFDA6A10B0C@fugue.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 17:29:19 -0000 On 6/1/21 14:06, Ted Lemon wrote: > On Jan 6, 2021, at 11:26 AM, Gert Doering > wrote: >> or rename the scopes to be 0 (link-local), 5 (mid-range), 10 (global)… > > This implies concentric circles, which isn’t really valid. Different > ULAs can have disjoint or overlapping applicability. I agree with a > previous comment that talking about this in terms of scope doesn’t make > much sense. I don’t know how to write code that takes into account the > difference in scope between ULA and GUA, other than perhaps in routing > protocols. e.g., for thinks like mDNS, you'd only bind() and listen on your ULAs, if any. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 09:33:11 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5583B3A1062 for ; Wed, 6 Jan 2021 09:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfNMHxm5xYfB for ; Wed, 6 Jan 2021 09:33:04 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036643A104F for ; Wed, 6 Jan 2021 09:33:03 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id 22so3120777qkf.9 for ; Wed, 06 Jan 2021 09:33:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=M6VBounNQZWk7Kr83wg0AHKe8/bRAnAILERIUROwyDc=; b=byFRFHrHBcxfFZJ6XGMhA/Zx++sf1XXyAPJ21/3/77tk3OfbBs3or/bE4WSxwGRAi/ ZOa+Uc3AdIZy3uOPDNydqu4Y+YEovwsjdHZQYzPzfBr7dw1653MSC/WfEBohv/Lk7dru UuerMXfvsLDwsFXIcBNQ9TRD5faPy6sVCvtpxuYHnTvH43uOFj0Iuehw03YdrtiUEVHD JkavVi63eVIqaR9MqJfBq3gbPgM/pj31/qnLuRGdN5tucQ0LAJus1uhuS4MoDNJ7LDeP BO4U3QkOzkA80mMAnFeOs5O5kdjTKL5Meh0QbsOfTWxTkjlkj8RSNrCMKsVp/I2Dp5v0 BsTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=M6VBounNQZWk7Kr83wg0AHKe8/bRAnAILERIUROwyDc=; b=cA08bsvUif+1S/Fl7gU4/8yQE1lG07e588E3Sr829k4n/Db5aIrmCzPpkGpC6/2yWf XUw681cHezOSLInSXpK57HtaI9Zw8q+JIeuqtqBAQF+BQQYRW4kV8dQNdkpvWEvNzHF+ njA0O3+FNt12vUSFC3GIYKD3guPzuOviuSjyrSJerLhVKYOWdjfoxj7+fEUz86+EU79J 9nAVOqQitopgz8mXQ2+FADW7CqjUsGiMkK6ZAnPHbey5xWnSZaE9KxW5QMP4hUt4EU9F wx8Ciqnm1ld1OluK45+mZtiEpfgQa64LtGpwzepgFK3l1yLNJoCDjImNiaxkj7lys5la bNFQ== X-Gm-Message-State: AOAM531dFbgylWIkZ/hLWK9o53vimdpXGRoSayqQe3eiQR6C9416Dqb2 n1i5qdGE/6mJqIfdHd/XS/oWMA== X-Google-Smtp-Source: ABdhPJwinEpfM5OkcDadF+Nabzqk3QWs/H3zBBcTXLazcUQHiLKTDLdliVPYa6TP3smX0VEfZ1wATA== X-Received: by 2002:a37:4ecd:: with SMTP id c196mr5339208qkb.264.1609954382938; Wed, 06 Jan 2021 09:33:02 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id x47sm1422398qtb.86.2021.01.06.09.33.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 09:33:02 -0800 (PST) From: Ted Lemon Message-Id: <184A442D-53F0-4B21-B094-779A1F66AD39@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_53341688-AB71-480F-88E9-B6A66985680D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Wed, 6 Jan 2021 12:33:00 -0500 In-Reply-To: <035a725a-19bf-efae-bf13-15e8dae4cc97@si6networks.com> Cc: Gert Doering , IPv6 Operations , Philip Homburg , ipv6@ietf.org To: Fernando Gont References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> <88297320-9516-4627-A673-FBFDA6A10B0C@fugue.com> <035a725a-19bf-efae-bf13-15e8dae4cc97@si6networks.com> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 17:33:06 -0000 --Apple-Mail=_53341688-AB71-480F-88E9-B6A66985680D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 6, 2021, at 12:26 PM, Fernando Gont = wrote: > e.g., for thinks like mDNS, you'd only bind() and listen on your ULAs, = if any. mDNS is link-local, so you can actually use your LLA for that (and we = do). But e.g. if you are using SRP = (https://tools.ietf.org/html/draft-ietf-dnssd-srp-07), then it makes = sense to push your GUA and your ULA and bind to both, or to INADDR_ANY = (if you want to be globally reachable). I would expect the SRP server to = do the work of figuring out on which DNS server to publish the ULA and = on which to publish the GUA. --Apple-Mail=_53341688-AB71-480F-88E9-B6A66985680D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Jan 6, 2021, at 12:26 PM, Fernando Gont <fgont@si6networks.com> wrote:
e.g., for thinks like mDNS, you'd only bind() and listen on = your ULAs, if any.

mDNS is link-local, so you can actually use = your LLA for that (and we do). But e.g. if you are using SRP (https://tools.ietf.org/html/draft-ietf-dnssd-srp-07), = then it makes sense to push your GUA and your ULA and bind to both, or = to INADDR_ANY (if you want to be globally reachable). I would expect the = SRP server to do the work of figuring out on which DNS server to publish = the ULA and on which to publish the GUA.

= --Apple-Mail=_53341688-AB71-480F-88E9-B6A66985680D-- From nobody Wed Jan 6 09:49:01 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA253A108E; Wed, 6 Jan 2021 09:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEy4LoReysU6; Wed, 6 Jan 2021 09:48:54 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E293A107E; Wed, 6 Jan 2021 09:48:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9EFC9389A8; Wed, 6 Jan 2021 12:49:58 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HyHH_lKGjd31; Wed, 6 Jan 2021 12:49:58 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 35C88389A7; Wed, 6 Jan 2021 12:49:58 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 97603240; Wed, 6 Jan 2021 12:48:51 -0500 (EST) From: Michael Richardson To: Ted Lemon cc: Fernando Gont , IPv6 Operations , ipv6@ietf.org, Gert Doering Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) In-Reply-To: <1089BC1B-A8E6-4BF5-BB3E-FD440181DB56@fugue.com> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> <1ddf8850-a8cb-53a7-31bc-7433d5a984f2@si6networks.com> <1089BC1B-A8E6-4BF5-BB3E-FD440181DB56@fugue.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 17:48:56 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: > It is of course not even obvious how to solve this, because sometimes > you do want ULA in DNS, and sometimes you don=E2=80=99t. And it depen= ds on what > DNS. > If you are doing split DNS, then you can scope the DNS that > advertises ULAs only to serve those networks where those ULAs are > in-scope. Ideally.... but that's a lot of policy stuff to put into DNS. I think that geolocated answers in DNS is already a bad thing. We should be using a better anycast. > The DNS that is advertised globally would of course contain > no ULAs. I'm not sure that I agree! I think that ULAs often do belong. There are potentially many GUA (2000::/3) addresses that could be in DNS, which would not work for some originators due to ACLs, and yet a different entry might work just fine. Why would ULA be any different? I think that happy eyeballs and source address selection ought to cut out many possibilities. It's just too bad that libcurl doesn't implement Happy Eyeballs... {ideally in a system-wide, privacy-preserving, maybe even LAN-wide [RFC2186-like] way} (I also lament shim6, but feel that MPTCP and QUIC might give us something equivalent. Again... anycast) > How this is arranged is either a matter of local configuration > or an interesting topic of future work, depending on how you look at > it. Also, is this an operational or architectural issue? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/1+AMACgkQgItw+93Q 3WW0Cwf/TdUl/zbPO8IZgOPJ/M9sgsVmqpcxtXjxlteQhNm1i3RSAdNGnY0yoF1k QSK2TbsEWGz+3PIBjiTNLfu+KP/Qdz9agEXxvNbqaw6weChMxd4hcO1MOlBVfzCZ ZPIGOoCnDhsoEVQh2bnKKLswyMuMyNHxuXOO94mjtAtvTyZT9eIOvmVQM/9eRB73 uz8jxuq5ukzjmywUO5jJp/yRXEro4b5R95AgdgsyWZSlYG0AamC+Z3M1fvf5FV3J 6dTLzNmwPYOJkK4QhjBW39rXWpNptd5o/JlnQgnPKeeeFOV1v8RNQmIsl4OIxgid 0fV8nHnO4GDvWtd5wpAl9EZtZsG5Rw== =WJ7A -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 6 09:51:22 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A19F3A108E; Wed, 6 Jan 2021 09:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnTGYKDwE7TN; Wed, 6 Jan 2021 09:51:14 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF8E3A106E; Wed, 6 Jan 2021 09:51:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A6318389A3; Wed, 6 Jan 2021 12:52:19 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZLaPCX_DohRe; Wed, 6 Jan 2021 12:52:17 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B9BED389A0; Wed, 6 Jan 2021 12:52:17 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 259B0240; Wed, 6 Jan 2021 12:51:11 -0500 (EST) From: Michael Richardson To: Ted Lemon cc: Fernando Gont , IPv6 Operations , ipv6@ietf.org, Gert Doering Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) In-Reply-To: References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> <1ddf8850-a8cb-53a7-31bc-7433d5a984f2@si6networks.com> <1169.1609953092@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 17:51:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: > On Jan 6, 2021, at 12:11 PM, Michael Richardson wrote: >> And, yet, for the case where some device is doing dynamic DNS update= to a DNS >> server that is within some ULA scope, posting the ULA to the DNS is = actually >> correct. >> But, it's hard to know that without knowing what clients are expecte= d to connect. > It seems straightforward that the client should send all the addresses > it wants to advertise, and the DNS server should decide which ones to > advertise in what scopes. Ideally, yes. If you ask from ULA xyz, and there is a ULA xyz answer, then clearly it should be included. But... caching and outsourcing of DNS servers and outsourcing of DNS resolv= ers. I hate all of that: except for simpler (IoT) devices, which should always u= se local DNS server to get local policy, all this policy should be in the client, not the server. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/1+I4ACgkQgItw+93Q 3WV9IQf+JSn8ik56ogTeoUQlw6YPg3JjKK4nPlF/V1C/6KVzaoP1fjyKG9sS6dod mT+Z6XgZ9Yb3ESDuLQI48m9anapX1Q9HVPq83FkmjP86y0sN9irCGyVAlQ4QVx/z s7LAX7aPLI0awwz0dI+S4lY3WZUTsOWSz8OKsKxOtrj/+9EzmOkHJpz/NkZWAv1p NK5nItV4R9IAsSMqEhuxQDDGNZWvzRLpiwhGwAnToKynoGNKgG3FxRvEuX7Usg1w kBWDosrX+Zv00xSLOGudRWBh0s4IGZ3l0eivipoDuMycneBcxcTwkg6j9X7YbX1k BzATNCcWzRqRCFKpZQ3+EH7XCMJLcg== =+jQd -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 6 10:04:42 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4865B3A10E5 for ; Wed, 6 Jan 2021 10:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGFfGEJfHyTZ for ; Wed, 6 Jan 2021 10:04:35 -0800 (PST) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D713A1093 for ; Wed, 6 Jan 2021 10:04:34 -0800 (PST) Received: by mail-qv1-xf31.google.com with SMTP id j18so1617531qvu.3 for ; Wed, 06 Jan 2021 10:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Ev2ewpUTRjo6okUM8t5+VYmznhPRQ2qdHAqyRUjQQ3o=; b=udUGF4n0DNj+VnKT8nt8zsmrU4za/D0djSo40ZfiQSkLuqmxG2HS5O9pHiKPsSK6E9 0ZqjhrUQf2MeUmTjCiDQ3kRVP9Ka9s3FbJTsv9UtgPH6Rfqcv7JTUbqBoOstSysrwgjS wCis8EiSNjAyO/i6+w4tLc7kDFChivjvYutqj/jQryfOkln8dZTxCMVA2dCdqLDes7aU Rr2O4gz+6KjSto3vIECewJ+gKIq5Hi6CFkxaD+yxR3LFDgwFSWhm5pBQxqpFT30GQbjW kKtx22d+rMcj3mXatGgLktqrgcPJZW1Co3SBbOirGwEKah8F/WY5kcjQZ1RrnHp3QpMK yMJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Ev2ewpUTRjo6okUM8t5+VYmznhPRQ2qdHAqyRUjQQ3o=; b=lLp/dvgeJM98l7Q45eHHuTPCB217L4mgAwrUBSE38GkVWCqIj6OUXuB9B8xIYG4kXu JJjVSo1HGHTCZb1N0pPVWP18pSwT4wEOpHPXRkx/3EibI0z8P+mKcLpgBzws9RXI27VZ 5YH2W4L/p2Vn8F66YW/9N0I1EZcipR8N5IJ2RFKgwWccUkdVo1XIm5YMikPT4Q9EINuZ wz5OVNCyUKEFLqzei/2UrQV1K/Bcap/NEm7KWNfSHFNtiuCzsNSiX145yOKC6R3HBLRF BIPfihcvjfzlYUrX6h6/bff4a0e/8T52kniUTVRsfX9Op4rDgLsbz7iIN5L43tkYJ5az UsYQ== X-Gm-Message-State: AOAM531otu+puzf8Bprh1MfjVLWjtxtvPJiJvAPDTPycen+k4IgXkR6U CoD98x6B5nIhtAPPHlbL87fA6g== X-Google-Smtp-Source: ABdhPJxlJ/OHKMDkwBP/pwqInoLhNbDCiu77FB9ZmeMI+7XHCKRFE0SpNmws7k9Faip3JGwizgN14w== X-Received: by 2002:ad4:4643:: with SMTP id y3mr5086140qvv.3.1609956273821; Wed, 06 Jan 2021 10:04:33 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id f134sm1752619qke.23.2021.01.06.10.04.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 10:04:33 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4A9A3EC7-1DF5-4FF5-BADC-4F63CD8F2DAE" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Wed, 6 Jan 2021 13:04:30 -0500 In-Reply-To: <12491.1609955331@localhost> Cc: Fernando Gont , IPv6 Operations , ipv6@ietf.org, Gert Doering To: Michael Richardson References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> <1ddf8850-a8cb-53a7-31bc-7433d5a984f2@si6networks.com> <1089BC1B-A8E6-4BF5-BB3E-FD440181DB56@fugue.com> <12491.1609955331@localhost> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 18:04:36 -0000 --Apple-Mail=_4A9A3EC7-1DF5-4FF5-BADC-4F63CD8F2DAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 6, 2021, at 12:48 PM, Michael Richardson = wrote: > There are potentially many GUA (2000::/3) addresses that could be in = DNS, > which would not work for some originators due to ACLs, and yet a = different > entry might work just fine. Why would ULA be any different? The usual case here would be through a VPN; in that case the VPN will = specify some set of domains that should be resolved through the VPN=E2=80=99= s name servers. You really don=E2=80=99t want the ULA advertised = globally. --Apple-Mail=_4A9A3EC7-1DF5-4FF5-BADC-4F63CD8F2DAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 6, 2021, at 12:48 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
There are = potentially many GUA (2000::/3) addresses that could be in = DNS,
which would = not work for some originators due to ACLs, and yet a different
entry might = work just fine.  Why would ULA be any = different?

The usual case here would be through a VPN; in that case the = VPN will specify some set of domains that should be resolved through the = VPN=E2=80=99s name servers. You really don=E2=80=99t want the ULA = advertised globally.

= --Apple-Mail=_4A9A3EC7-1DF5-4FF5-BADC-4F63CD8F2DAE-- From nobody Wed Jan 6 10:09:11 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782373A10DA for ; Wed, 6 Jan 2021 10:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq8EYBjJkKeb for ; Wed, 6 Jan 2021 10:09:03 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFB33A0EE5 for ; Wed, 6 Jan 2021 10:09:03 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id a6so2618994qtw.6 for ; Wed, 06 Jan 2021 10:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lI1K76zbEooCB95VgnJbDrPuqokTja1trr1xk39pa1s=; b=QnivyyyFbBGERu1GRNI3VNflNZXxtGnBZcQhHzEFUwsAu2lV7TJRpquD10JIrRyj5I KDCpSignmzDYEhMmqKK1aniXtngFa2j00zA/cYtikBIIynAgIOFygeGv1nqKbJsB9/sN 2J/4J6WSXPQPo/sFPoqt7V88A9aBhy/tXAzezHVeKyV3BBt+8wN+PrJ46yinEuRxCD9r adconG4kStQF7se7THxvNnuKBOZucTF0VxUsAGtbnuSsa3+zAlRmbhf0aKXpcoyBxK6o Fn2I9Yrj2MpA4lrcQ0spNu4x75m81WjUoKQlo4EJm346cecYCfdpjLpKj16OfwD5TqBt lFyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lI1K76zbEooCB95VgnJbDrPuqokTja1trr1xk39pa1s=; b=MJSZAOGOZ9P3CKS3zhHg+O4AdPWq/VlNXxb2MFWqPIPfZshVWawma52T/GpnNKCwj/ mJzqAsE3bXkIEsJuw+SULqH3OxAEa82wihJznKBFg6BAL8Ybtc1dlssMaTCBEvoZMYzz FYMHlYEiiWFH0lTWijYjw+/lD28k6bE7/QpqKBa/voR+0Up8SRYhDwLchf1xtE4nZBt7 j75yfZ6BDXHMy70oIJdTZmTMEV3h6kn4Kpv6HAcV2MQFMdwmr+0x8MSBQ38EMh1ruyKr ZV/x/IYG+F5teVvYMwSDWZkKn0DdiCI719zSJ5nvQw2etU2G5tc0hbJSoMwCoBI0GmHr kDOg== X-Gm-Message-State: AOAM5334iEJKeFFQcIEJooBmfL2UPKcMkaOz/4Nby6GRcD0vGoZbR11R sin68ggMwNnbhoF7VDzDaI8a1Q== X-Google-Smtp-Source: ABdhPJwUR9nH81OHF6GjmKiSG7V4owprwzPWlVhI90JlwEgm0OMlTB12U4gy5rrkwArcs2lKJqjavg== X-Received: by 2002:ac8:5a90:: with SMTP id c16mr5070025qtc.331.1609956542471; Wed, 06 Jan 2021 10:09:02 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id q32sm1591342qtb.0.2021.01.06.10.09.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 10:09:01 -0800 (PST) From: Ted Lemon Message-Id: <26933B3A-039C-4418-A1FF-5EFD5FC92523@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_47C06E68-CF31-4E53-A189-1212BBB9B1C3" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Wed, 6 Jan 2021 13:08:59 -0500 In-Reply-To: <13054.1609955471@localhost> Cc: Fernando Gont , IPv6 Operations , ipv6@ietf.org, Gert Doering To: Michael Richardson References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> <1ddf8850-a8cb-53a7-31bc-7433d5a984f2@si6networks.com> <1169.1609953092@localhost> <13054.1609955471@localhost> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 18:09:06 -0000 --Apple-Mail=_47C06E68-CF31-4E53-A189-1212BBB9B1C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 6, 2021, at 12:51 PM, Michael Richardson = wrote: > But... caching and outsourcing of DNS servers and outsourcing of DNS = resolvers. > I hate all of that: except for simpler (IoT) devices, which should = always use > local DNS server to get local policy, all this policy should be in = the > client, not the server. Okay, if that=E2=80=99s possible, sure, but the way to do that sort of = policy would be to say what server to contact for what domain. The VPN = example is just one example; you could certainly also do this without a = VPN. It=E2=80=99s pretty easy to do on the Mac=E2=80=94just add a scoped = DNS resolver; not sure how hard it is on Linux. The thing is, though, that somebody has to provide the intelligence to = decide either who to ask or what address to use. I think that by default = you should never see a ULA other than from the local resolver, because = there=E2=80=99s just no way for someone who _doesn=E2=80=99t_ know that = ULA to know whether it would work or not. So if there are some domains = that you want treated specially, the easiest way to do that is to have a = different resolver for those domains (a scoped resolver). --Apple-Mail=_47C06E68-CF31-4E53-A189-1212BBB9B1C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 6, 2021, at 12:51 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
But... = caching and outsourcing of DNS servers and outsourcing of DNS = resolvers.
I hate all of = that: except for simpler (IoT) devices, which should always = use
local DNS = server to get local policy,  all this policy should be in = the
client, not = the server.

Okay, if that=E2=80=99s possible, sure, but the way to do = that sort of policy would be to say what server to contact for what = domain. The VPN example is just one example; you could certainly also do = this without a VPN. It=E2=80=99s pretty easy to do on the Mac=E2=80=94just= add a scoped DNS resolver; not sure how hard it is on Linux.

The thing is, though, = that somebody has to provide the intelligence to decide either who to = ask or what address to use. I think that by default you should never see = a ULA other than from the local resolver, because there=E2=80=99s just = no way for someone who _doesn=E2=80=99t_ know that ULA to know whether = it would work or not. So if there are some domains that you want treated = specially, the easiest way to do that is to have a different resolver = for those domains (a scoped resolver).

= --Apple-Mail=_47C06E68-CF31-4E53-A189-1212BBB9B1C3-- From nobody Wed Jan 6 10:56:17 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5961C3A1143; Wed, 6 Jan 2021 10:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc_re41DPrij; Wed, 6 Jan 2021 10:56:08 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977013A1135; Wed, 6 Jan 2021 10:56:08 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6744E2838B1; Wed, 6 Jan 2021 18:56:04 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Ted Lemon Cc: Gert Doering , IPv6 Operations , Philip Homburg , ipv6@ietf.org References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> <1ddf8850-a8cb-53a7-31bc-7433d5a984f2@si6networks.com> <1089BC1B-A8E6-4BF5-BB3E-FD440181DB56@fugue.com> From: Fernando Gont Message-ID: Date: Wed, 6 Jan 2021 14:34:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <1089BC1B-A8E6-4BF5-BB3E-FD440181DB56@fugue.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 18:56:12 -0000 On 6/1/21 14:10, Ted Lemon wrote: > On Jan 6, 2021, at 11:46 AM, Fernando Gont > wrote: >> I have Raspberry Pis that deploy here and there. In order to be able >> to access them, they use dynamic DNS to post their addresses on their DNS. >> If I don't look at the properties of the addresses, then I end up >> puting crap on the DNS. One straightforward consequence is that many >> apps that don't do Happy Eyeballs end up having an insane >> connection-establishment period, if they happen to try the unusable >> addresses first. >> >> So "find all your IPv6 addresses and post them to the DNS" doesn't work. > > It is of course not even obvious how to solve this, because sometimes > you do want ULA in DNS, and sometimes you don’t. And it depends on what > DNS. If you are doing split DNS, then you can scope the DNS that > advertises ULAs only to serve those networks where those ULAs are > in-scope. The DNS that is advertised globally would of course contain no > ULAs. How this is arranged is either a matter of local configuration or > an interesting topic of future work, depending on how you look at it. What I do is set up to different names. e.g.: node.mydomain,com for the global addresses, and, node-local.mydomain.com for the non-global addresses. In the case of apps that are expected to be available only to local nodes (e.g., mDNS) the daemon might want to explicitly bind() a ULA, rather than bind() the wildcard "address". So the app gets an extra layer of isolation as a result of the address scope. And probably also gets more stability, since in most cases the ULA prefix will be generated by the local router and thus be stable, while the global prefix may end up being dynamic. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 10:56:21 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A676D3A1200; Wed, 6 Jan 2021 10:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvQeLHdaGQkr; Wed, 6 Jan 2021 10:56:15 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D913A114A; Wed, 6 Jan 2021 10:56:14 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 126AA283A88; Wed, 6 Jan 2021 18:56:10 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Ted Lemon , Michael Richardson Cc: IPv6 Operations , ipv6@ietf.org, Gert Doering References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> <1ddf8850-a8cb-53a7-31bc-7433d5a984f2@si6networks.com> <1169.1609953092@localhost> From: Fernando Gont Message-ID: Date: Wed, 6 Jan 2021 14:35:29 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 18:56:21 -0000 On 6/1/21 14:20, Ted Lemon wrote: > On Jan 6, 2021, at 12:11 PM, Michael Richardson > wrote: >> And, yet, for the case where some device is doing dynamic DNS update >> to a DNS >> server that is within some ULA scope, posting the ULA to the DNS is >> actually >> correct. >> But, it's hard to know that without knowing what clients are expected >> to connect. > > It seems straightforward that the client should send all the addresses > it wants to advertise, and the DNS server should decide which ones to > advertise in what scopes. FWIW, I didn't find that magic in BIND (even if it's there), so I had to deal with it on the client side. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 10:56:43 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40803A138C; Wed, 6 Jan 2021 10:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRI3J9mAODNh; Wed, 6 Jan 2021 10:56:33 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1793A1179; Wed, 6 Jan 2021 10:56:22 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6F12F284F56; Wed, 6 Jan 2021 18:56:17 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Ted Lemon Cc: Gert Doering , IPv6 Operations , Philip Homburg , ipv6@ietf.org References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <20210106162652.GX13005@Space.Net> <88297320-9516-4627-A673-FBFDA6A10B0C@fugue.com> <035a725a-19bf-efae-bf13-15e8dae4cc97@si6networks.com> <184A442D-53F0-4B21-B094-779A1F66AD39@fugue.com> From: Fernando Gont Message-ID: <42ebf28f-ea1e-9650-f84f-c561a673720e@si6networks.com> Date: Wed, 6 Jan 2021 14:46:04 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <184A442D-53F0-4B21-B094-779A1F66AD39@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 18:56:42 -0000 On 6/1/21 14:33, Ted Lemon wrote: > On Jan 6, 2021, at 12:26 PM, Fernando Gont > wrote: >> e.g., for thinks like mDNS, you'd only bind() and listen on your ULAs, >> if any. > > mDNS is link-local, so you can actually use your LLA for that (and we > do). The problem with link-locals is that having to specify the "zone id" with the "Addr%iface" thing at times is nto friendly with some apps. > But e.g. if you are using SRP > (https://tools.ietf.org/html/draft-ietf-dnssd-srp-07), then it makes > sense to push your GUA and your ULA and bind to both, or to INADDR_ANY > (if you want to be globally reachable). I would expect the SRP server to > do the work of figuring out on which DNS server to publish the ULA and > on which to publish the GUA. ... in which case the server would have to be able to infer address properties, using macros or libraries such as the one in https://tools.ietf.org/html/draft-gont-6man-ipv6-ula-scope-00#section-5.1 -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 11:04:43 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A21E3A113B; Wed, 6 Jan 2021 11:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eW3RAcWb2nxz; Wed, 6 Jan 2021 11:04:36 -0800 (PST) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0913A1135; Wed, 6 Jan 2021 11:04:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 106J4X6m032398; Wed, 6 Jan 2021 14:04:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1609959873; bh=LB9t1eHnYXeiQTDPm9Eki2k4TemLD87tkA0BbWoYDE8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=BmTYpgccygxJdVNNnQbAC2NwV0tkFxsqCL9ad+xzcrt3aJNuY3lY2n2Vw1mGKnjg7 ebzTIgi4+K6IpDfPBuVav5kyojoITuvm53R6zJf3SEceiQrwXm+bzrvGAcv3FsQhM3 tbwNWUgNokWsISGqimn07KamnmDuOeL37Jn7DhZRHmBZ5yFSqiko1MYhAlb3AO6clY 1/qX9U4VXLAerqVPUcSocu3AMX0+zYdxhzQ4ViNRsXWL0u/0BqaYXm0tMBXv2lPJ+y KEk9Z6540lXbBYmHqWuXctt1oe7hw2Q+LAttPxa4lSZZBsmYUL60ogr07RwJORLrzk a/Yw3n+tIsyEQ== Received: from XCH16-01-10.nos.boeing.com (xch16-01-10.nos.boeing.com [144.115.66.5]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 106J4MEN032297 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 6 Jan 2021 14:04:23 -0500 Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-10.nos.boeing.com (144.115.66.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 6 Jan 2021 11:04:21 -0800 Received: from XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b]) by XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b%4]) with mapi id 15.01.2044.004; Wed, 6 Jan 2021 11:04:21 -0800 From: "Manfredi (US), Albert E" To: Richard Patterson CC: IPv6 Operations , 6MAN <6man@ietf.org> Subject: RE: [EXTERNAL] Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Thread-Topic: [EXTERNAL] Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Thread-Index: AQHW48/q6MYge4t1TkCUP2ZIbkIFhaoas8eAgAAGVYCAAFhKgP//4oMg Date: Wed, 6 Jan 2021 19:04:21 +0000 Message-ID: <5074034efaf04777be2517645c1c4630@boeing.com> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.115.204.6] x-tm-snts-smtp: 4557121A5A16E431CFCA3671F83E7FDE93A4DF79B10CCC59715DE3B668D8A3232000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 19:04:38 -0000 RnJvbTogaXB2NiA8aXB2Ni1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUmljaGFyZCBQ YXR0ZXJzb24NCg0KPj4gT24gV2VkLCA2IEphbiAyMDIxIGF0IDA3OjMxLCBDaHJpc3RvcGhlciBN b3Jyb3cgPG1haWx0bzpjaHJpc3RvcGhlci5tb3Jyb3dAZ21haWwuY29tPiB3cm90ZToNCj4+DQo+ PiBvcHRpb24gNCwgZGVwcmVjYXRlIFVMQS4NCj4+IHRoZSBiZXN0IG9wdGlvbiAodG0pLg0KPg0K PiBTdHJvbmdseSBkaXNhZ3JlZS4NCj4gSSB0aGluayBkZWZpbmluZyBhIG5ldyBzY29wZSBmb3Ig VUxBIGlzIGEgZ29vZCBpZGVhIGFuZCB3aWxsIGhlbHAgdG8gZGVteXN0aWZ5IGFuZCBpbXByb3Zl IHRoZWlyIHVzZSBpbiB0aGUgcmVhbCB3b3JsZC4NCg0KKzEuIEVtcGhhdGljYWxseS4gQW5kLCB0 aGUgc2FtZSB3b3VsZCBhbHNvIGFwcGx5IHRvIFJGQyAxOTE4Lg0KDQpCZXJ0DQoNCg== From nobody Wed Jan 6 11:46:56 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907AC3A1188; Wed, 6 Jan 2021 11:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkONk5ccEK6K; Wed, 6 Jan 2021 11:46:50 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E883A1102; Wed, 6 Jan 2021 11:46:50 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id d8so4116581otq.6; Wed, 06 Jan 2021 11:46:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=a0KX+rMiBdbGde6DZlSiPYYZyPtyoAQSf5pMHGhu6ng=; b=gRjfRqPbTPH9DS3l7benl8KLf7OZGN0P9+cF5SZIv320DDX376qyUBl7yNX2wJ9+jL 9JDbXgpD/8qnEtIWGpURdLFMyfit6lls9LtYIX0FYBxuVMMAcYznST/d0NcrV9n7n/9q gu1wRA5eEvFz/BqmcUXNjQjhp0+7J+Z8OUYO4ThfpoEd681gnXYfj4WCMpyG1XqLoMzP RgZW+9RIME9LnvL2deCXKUaBFZb18LDf68MB8Q/GV1q+1t24g4ZuryEX08F0RKGEZsLm oFmPUXKJk0BP6v2rhFhaMkjHQx160JXlmY+dWmLC91vYJkjJBaNsXPgmsqqpXAB5OV5R iO0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=a0KX+rMiBdbGde6DZlSiPYYZyPtyoAQSf5pMHGhu6ng=; b=QiwKAiecDysgafJjZVJrM4vuPYsj4malu6BZlZPK1y8jC7N6254wIf0cAeplaSQaOK Mkifx2TDEe0qG53SsEHrPzgxkOuJhuOEQNxZV6XOxGAvbP2g16t40tl/ziSlvGBu3mZh k41gK6rSdX3QDVexriPbPwhcPzxC2cv0LGNtoHwz+Bbw470Mo9cyT10z8SAQDFxTzuPk s1b6RwuFRgWewaAyBwhL02UjDK3hFPCYj7yY5chvjH8Q1F6cNPDtb6r6QFV9bGU3Vv+n xiaYyysvkwQK3jTsYOWyNHGIOPNrJeU4ZfuD2oyJYEKQBcjVtPvs8owPdYrO1JA1trR8 NADQ== X-Gm-Message-State: AOAM531XHMZqA1MY6Y8ml4rf0G1yvszaq4i9ZlgyHeErqWILtrAF8udC L+y5lpmTGaz0DqssHFMYzQD6JTnyAj7fh6of1V8= X-Google-Smtp-Source: ABdhPJz7e0bY7uqnU4rhILeeIOXzWZVK74LZJimeR72vkb30Nx973X6Ba/xEyTS697ReCwwYLF2ebh2cSB38wTMl+fw= X-Received: by 2002:a9d:602:: with SMTP id 2mr4305378otn.153.1609962409393; Wed, 06 Jan 2021 11:46:49 -0800 (PST) MIME-Version: 1.0 References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> In-Reply-To: From: Mark Smith Date: Thu, 7 Jan 2021 06:46:22 +1100 Message-ID: Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Ted Lemon Cc: David Farmer , Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 19:46:52 -0000 On Wed, 6 Jan 2021 at 23:18, Ted Lemon wrote: > > On Jan 5, 2021, at 11:38 PM, David Farmer wrote: > > I think this is the right direction the previous draft indirectly defined= a new scope "non-global", I much prefer explicitly defining a new local sc= ope. > > > Actually, I think you=E2=80=99ve got it right here: the scope is =E2=80= =9Cnon-global.=E2=80=9D I > > I would add something like the following to better define the relationshi= p between the three scopes; > > The boundary of the link-local scope is strongly defined, limiting the ex= tent of the link-local scope to an individual link. However, in contrast, t= he boundary of the local scope is weakly defined, it is amorphous and impre= cise. In some instances, the extent of the local scope can be a single site= , in other instances, a group of unrelated sites, a single organization, or= even a cooperating group of organizations. Furthermore, the extent of an i= ndividual instance of the local scope doesn't necessarily remain constant, = it may expand or contract over time as the local situation dictates, for ex= ample when two organizations merge. Nevertheless, the extent of the local s= cope doesn=E2=80=99t encompass the entirety of the Internet which the globa= l scope does. > > > There is at least one obvious problem with this definition: the term =E2= =80=9Clocal.=E2=80=9D ULAs aren=E2=80=99t really local, despite the name. U= sing the name =E2=80=9Clocal=E2=80=9D is what leads to this confusion. Cons= ider this taxonomy: > > GUA: =E2=80=9Cvalid everywhere on the internet scope=E2=80=9D > ULA: =E2=80=9Cnot valid everywhere scope=E2=80=9D > LLA: =E2=80=9Cvalid only on this link scope=E2=80=9D > > Of course these names are awkward, but I hope they are clarifying. A ULA = is =E2=80=9Cnot valid everywhere.=E2=80=9D That=E2=80=99s really all you ca= n say about it. You can=E2=80=99t put a ULA prefix in a global routing doma= in. You can put it in a site routing domain. You can put it in a multi-site= routing domain. You can not route it at all. All these uses are valid. > > So I don=E2=80=99t really object to your text, but I do object to the nam= e =E2=80=9Clocal.=E2=80=9D How about =E2=80=9Cexplicit=E2=80=9D? That is, t= he scope of a ULA is explicit, in the sense that it must be _made_ explicit= by the user(s) of the ULA? If that doesn=E2=80=99t work, I=E2=80=99m sure = we can come up with a more agreeable term, but please let it not be =E2=80= =9Clocal.=E2=80=9D Sorry to be a sticky wicket. :) > I think "local" is close to, if not the right word. I consider anything that is non-global or smaller than global to be "local"= . I think "local" is a word that has the word's user's perspective and the context of its use as part of its semantics. The perspective and context defines what the "local" domain boundary is, and it is possible that different people might have different definitions, although they'll probably be pretty similar. People have their own local perspective on the definition of the word "local" ;-) When I'm at home, my "local" network is my home network. When I'm at work, my "local" network is the ISP I work at's network. I don't consider our customers' home networks "local" though, even though they're all part of the network with the same AS number. Some examples of "local" outside of networking. I go for walks around my local neighbourhood. I ride my bike around the local neighbourhood. As I can ride further than I can walk, my local neighbourhood in the context of being on my bike is a greater geographical area than my local neighbourhood when I walk. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Jan 6 13:30:52 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4053A1320; Wed, 6 Jan 2021 13:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWsUfmKOqwEG; Wed, 6 Jan 2021 13:30:42 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DED3A1332; Wed, 6 Jan 2021 13:30:41 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id x12so2199860plr.10; Wed, 06 Jan 2021 13:30:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sDkEyE+FbLEVswaEdAeRtvWNY5jlhRPI34LVCkuErN0=; b=qrUDy0PF9T2NyNbe6hnDXRibVufsKsQ7HMWlif1BchBBJUY7pAc6FkY4Eq/xwi14AB ZZfnYiGLAOrF8KPsNSC792KzWrxrsWYKEIiGNhuhxwRaNRRF6F8orLQAlcfFUlufPXuT o29PYJaZ7aIMccMPqmKEuyb6A6bMEas24J7ybbPqI7jUiZjDYD714HsnsjLLw2WKvnAi PtBkPmeAsXm4/Tys0PkNuw2vlFSiDXwIGPIsusDYdAePrSP6PzQK2qLgtRy2DYRAl8j+ 486sPM59UgeFMahHWIUIewMAoLwrEHJX2dX7bdQ3pGPZpOmq/awlF3vikuB31IodkdWX TvVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sDkEyE+FbLEVswaEdAeRtvWNY5jlhRPI34LVCkuErN0=; b=iOnjeRr4OzulSVq3fwzt9sOOc8CEAhKgcX/D78wGhvwcKJP8mbix4MYX3QJoM7jZu5 lKYCvmMgQEYMETl34so1FfqDelXgYBL1g7xJPLaRY6JPX7Tu4ffGM4Gm+fFqLtWlF8v9 GhnbwsbXGx2hIvaXryY4k2st6HYQ1YTJ3a2Ri/yybyVlB8qQ31glMpIJYSEp3+mcDnnA 0uDsrgx7J8xADVTLwMmfpZhFOciuxFC3Eh/BBcS5r2hXFkkoyWxwCq6GotnbDFc3zynY TDn+wdNN+owEpFUV7rPicbiHLewKufYp33LMLj2+TOw0YLUSR9pNVqYpWn97aSLJJwli Raqw== X-Gm-Message-State: AOAM532fQ+owaCKcZjkryMHSF+vr08C3q2b9STxl9pdN2VoUloovGmbq Xr2Hke35kNLuF+0psQRnRbPy3SOt4XBOAQ== X-Google-Smtp-Source: ABdhPJzL0elJfnYbv+Ik5uRx+JzATNfkKiiqF9YhLMzIEoaeL+uYQiE9K/MhwJh/9U2cmeAPQ2H9tA== X-Received: by 2002:a17:902:8483:b029:dc:3e69:4095 with SMTP id c3-20020a1709028483b02900dc3e694095mr6188436plo.66.1609968640690; Wed, 06 Jan 2021 13:30:40 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id q6sm3109412pfu.23.2021.01.06.13.30.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 13:30:39 -0800 (PST) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Lorenzo Colitti , Mark Smith Cc: Fernando Gont , IPv6 Operations , 6MAN <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> From: Brian E Carpenter Message-ID: <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> Date: Thu, 7 Jan 2021 10:30:35 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 21:30:50 -0000 Portmanteau reply to multiple messages: On 06-Jan-21 20:07, Lorenzo Colitti wrote: =2E.. > So I guess I'm somewhere between 1) and 3). The specs are consistent bu= t they fail to consider human behaviour, so they don't actually work in p= ractice. I disagree. They work fine in practice. The smart meter example is a goo= d one. The ANIMA autonomic control plane is another. My TV has a ULA addr= ess. I have no idea whether it's used when I control it from my Android p= hone, because address selection does its job. The problem is largely theoretical, and educational for people who train = IPv4 users in IPv6 terminology and practices. As Fernando has pointed out= , the use of the word "global" is confusing for something that has L for = "local" in its name. On 06-Jan-21 20:30, Christopher Morrow wrote: =2E.. > option 4, deprecate ULA. > the best option (tm). I can't see the least argument for that (no proven damage) and very stron= g arguments against (running code and operational deployments). On 07-Jan-21 01:17, Ted Lemon wrote: =2E.. > GUA: =E2=80=9Cvalid everywhere on the internet scope=E2=80=9D > ULA: =E2=80=9Cnot valid everywhere scope=E2=80=9D > LLA: =E2=80=9Cvalid only on this link scope=E2=80=9D Friendly amendment: GUA: valid everywhere ULA: Unique Limited-domain Address LLA: valid only on this link ("scope" is really a noise word, and "Internet" is too restrictive.) On 07-Jan-21 02:45, Philip Homburg wrote: =2E.. > 'local' scope is an operational reality. You don't see it at the protoc= ol > level. So we need to keep it clearly separate from link-local where we = do have > quite a bit of protocol and API specification. That's why using "scope" is a noise word. It isn't an abstract property. = Try to draw it and you get a mess. This really hasn't changed since https= ://tools.ietf.org/html/rfc3879. Or see https://www.cs.auckland.ac.nz/~bri= an/scope6.pdf. On 07-Jan-21 04:13, Philip Homburg wrote: =2E.. > Some things don't need fixing even if they are not 100% correct. +1 On 07-Jan-21 04:29, Richard Patterson wrote: >> Applications should not do widely different things if they encoute= r a ULA. >=20 > But they do. > Some OSes will see the presence of a ULA address on an interface, and s= tart sending AAAA queries, some will not. > Some applications will see a ULA destination address and simply ignore = it, preferring the IPv4 destination address returned.=20 >=20 > We need to ask the question why this is happening, and if the answer is= "They're doing it wrong", great, let's point them at the existing RFCs a= nd educate them, but if not...... we need to do something, and I think th= is I-D is a good starting point for WG discussion at least. FYI, we tried 6 years ago, but draft-ietf-v6ops-ula-usage-recommendations= stalled. On 07-Jan-21 05:13, Philip Homburg wrote: =2E.. >> You mean use interface IDs as zone IDs? >=20 > No, rewrite RFC 4007 and get rid of zone IDs. And the introduce interfa= ce IDs > to select the interface of an outgoing packet, whether link-local or gl= obal. Effectively that's what RFC3879 did. RFC4007 was a bit behind the curve. = As far as I know, zone IDs and interface IDs are exactly equivalent (at l= east in POSIX and WinSock environments). IMHO this is *only* a terminolog= y question. > It doesn't change anything in practice, because that is what existing c= ode > does. Really? Using the interface ID for non-link-local addresses? On 07-Jan-21 05:26, Gert Doering wrote: =2E.. > Why should applications, or anything that is not an admin, care if an > address is a ULA or a GUA? It depends on what you mean by "application". I've written code that expl= icitly prefers a ULA, and I could imagine a security spec saying "prefer = ULA". But anyway, it's not really a problem, is it? (It's annoying to me = that in Python, a ULA has .is_global =3D=3D False, but I managed to code = round that error.) On 07-Jan-21 06:06, Ted Lemon wrote: =2E.. >> or rename the scopes to be 0 (link-local), 5 (mid-range), 10 (global)=E2= =80=A6 >=20 > This implies concentric circles, which isn=E2=80=99t really valid. It really, really, really isn't valid. That's where we went wrong in 1995= =2E Once the mid-range scopes start to overlap, the concentric circles mo= del fails completely. That's the main reason we scrapped site-local. On 07-Jan-21 07:04, Ted Lemon wrote: =2E.. >> There are potentially many GUA (2000::/3) addresses that could be in D= NS, >> which would not work for some originators due to ACLs, and yet a diffe= rent >> entry might work just fine. Why would ULA be any different? >=20 > The usual case here would be through a VPN; in that case the VPN will s= pecify some set of domains that should be resolved through the VPN=E2=80=99= s name servers. You really don=E2=80=99t want the ULA advertised globally= =2E But neither do you want private-use 2000::/3 addresses advertised globall= y. I really don't see a difference between RIR-assigned and self-assigned= (ULA) prefixes in this respect. Regards Brian From nobody Wed Jan 6 14:24:55 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180523A133D; Wed, 6 Jan 2021 14:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GxGEiAuJ1Ff; Wed, 6 Jan 2021 14:24:48 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106DE3A133F; Wed, 6 Jan 2021 14:24:42 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 06155280A8E; Wed, 6 Jan 2021 22:24:37 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Brian E Carpenter , Lorenzo Colitti , Mark Smith Cc: IPv6 Operations , 6MAN <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> From: Fernando Gont Message-ID: Date: Wed, 6 Jan 2021 19:23:49 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 22:24:51 -0000 On 6/1/21 18:30, Brian E Carpenter wrote: > Portmanteau reply to multiple messages: > > On 06-Jan-21 20:07, Lorenzo Colitti wrote: ... >> So I guess I'm somewhere between 1) and 3). The specs are >> consistent but they fail to consider human behaviour, so they don't >> actually work in practice. > [...] > > The problem is largely theoretical, and educational for people who > train IPv4 users in IPv6 terminology and practices. As Fernando has > pointed out, the use of the word "global" is confusing for something > that has L for "local" in its name. There is indeed a terminology issue, which ends up making it complicated to explain e.g. the concept of "scope" as a result. > On 07-Jan-21 01:17, Ted Lemon wrote: ... >> GUA: “valid everywhere on the internet scope” ULA: “not valid >> everywhere scope” LLA: “valid only on this link scope” > > Friendly amendment: > > GUA: valid everywhere ULA: Unique Limited-domain Address LLA: valid > only on this link Would certainly also work. > On 07-Jan-21 04:13, Philip Homburg wrote: ... >> Some things don't need fixing even if they are not 100% correct. > > +1 My take is that if the topics is confusing for us, we cannot expect it to be any better for others. > On 07-Jan-21 05:26, Gert Doering wrote: ... >> Why should applications, or anything that is not an admin, care if >> an address is a ULA or a GUA? > > It depends on what you mean by "application". I've written code that > explicitly prefers a ULA, and I could imagine a security spec saying > "prefer ULA". But anyway, it's not really a problem, is it? (It's > annoying to me that in Python, a ULA has .is_global == False, but I > managed to code round that error.) The question is: Is it an error? I've just checked the most "up to date" textbook that I have at hand on IPv6. Page 335 has a subsection entitled "Global addresses versus ULAs". The discussion in the textbook is indeed fine. Could one actually make the case that e.g. Python's library should change? If it did, it would be counter intuitive. It would match RFC4193/4291, but not RFC4007, e.g. the textbook I've checked, and the intuitive meaning of private/global. FWIW, I don't think there's a problem with how ULAs work. But I do think that the terminology problem does have ramifications. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 17:13:05 2021 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F09A3A1435; Wed, 6 Jan 2021 17:12:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christopher Wood via Datatracker To: Cc: draft-ietf-6man-rfc4941bis.all@ietf.org, ipv6@ietf.org, last-call@ietf.org Subject: Secdir last call review of draft-ietf-6man-rfc4941bis-12 X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160998197921.18103.15481726186693031049@ietfa.amsl.com> Reply-To: Christopher Wood Date: Wed, 06 Jan 2021 17:12:59 -0800 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 01:12:59 -0000 Reviewer: Christopher Wood Review result: Has Issues Document: draft-ietf-6man-rfc4941bis-12 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is: Ready with issues High-level comments: This is a great document! I apologize for taking so long to review it. My main comments are on the details of the address generation logic and heuristics, and how it ties into the larger threat model. In general, a clear description of the threat model these temporary addresses aim to address might be worth including, perhaps by expanding the Security Considerations. Comments: Section 1. The default address selection for IPv6 has been specified in [RFC6724]. The determination as to whether to use stable versus temporary addresses can in some cases only be made by an application. For example, some applications may always want to use temporary addresses, while others may want to use them only in some circumstances or not at all. An Application Programming Interface (API) such as that specified in [RFC5014] can enable individual applications to indicate a preference for the use of temporary addresses. I wonder if this should mention TAPS, which has discussed APIs for this sort of selection in the past. See https://tools.ietf.org/html/draft-ietf-taps-interface-10#section-5.2.13. Section 1.2. The correlation can be performed by: This probably isn't exhaustive, so perhaps: "Correlation can be performed by a variety of attackers, including, though not limited to:" (or something to that effect). Section 2.1. One of the requirements for correlating seemingly unrelated activities is the use (and reuse) of an identifier that is recognizable over time within different contexts. IP addresses provide one obvious example, but there are more. For example, What about MAC addresses? As I understand it, most systems are moving towards MAC address randomization, though it's still probably worth mentioning. Likewise, similar to cookies, one could also mention TLS (or transport) layer identifiers, such as TLS session tickets. This is touched on somewhat in the Security Considerations. Section 2.2. To make it difficult to make educated guesses as to whether two different interface identifiers belong to the same host, the algorithm for generating alternate identifiers must include input that has an unpredictable component from the perspective of the outside entities that are collecting information. It seems like this "must" be normative, and should probably reference the RFC4086 [https://tools.ietf.org/html/rfc4086]. Section 3.1. 3. New temporary addresses are generated over time to replace temporary addresses that expire. I assume expiration here means that the address is deprecated, right? If so, that might be worth clarifying. 4. The lifetime of temporary addresses must be statistically different for different addresses, such that it is hard to predict or infer when a new temporary address is generated, or correlate a newly- generated address with an existing one. This "must" is not normative, right? I assume not, since the previous guideline in this item ("the lifetime of an address should be further reduced when privacy-meaningful events ... takes place") does not require all temporary addresses to cease working. It might be better to drop the "or correlate a newly-generated address with an existing one" bit. Moreover, what does "statistically different" mean, precisely? It might be more accurate to talk about this property from the perspective of the adversary. For example, I think this is trying to say that given two different temporary addresses, an adversary must have negligible probability in determining whether or not they correspond to the same or different sources. (That would match better with the Randomized Interface Identifier algorithms given in Section 3.3.) Section 3.2. This document also assumes that an API will exist that allows individual applications to indicate whether they prefer to use temporary or stable addresses and override the system defaults (see e.g. [RFC5014]). If a reference to TAPS is made for these APIs, it is probably also worth including here. Section 3.3. The algorithm specified in Section 3.3.1 benefits from a Pseudo-Random Number Generator (PRNG) available on the system. What does "benefits" mean here? If we're specifying an algorithm to generate random values, shouldn't a PRNG be *required*? Section 3.3.2. This section assumes a "hash-based" algorithm, but is specified using a PRF. Later, in the text, it reads: F() could be the result of applying a cryptographic hash over an encoded version of the function parameters. But a cryptographic hash is not a PRF. If the hash function is meant to be keyed, even that probably isn't sufficient. (Some constructions, like H(k || m) for secret k and input m, are vulnerable to length extensions.) I think it's probably safest to recommend a particular construction, such as HKDF with secret_key and output length equal to the number bytes needed for the interface identifier. Moreover, requirements for secret_key are not really strict enough. There's text about F(), e.g.,: F() MUST also be difficult to reverse, such that it resists attempts to obtain the secret_key And it is said that secret_key "SHOULD be of at least 128 bits," but what if it's less? What if it only has a single byte of entropy? Section 3.4. Constants here are used before defined. Moving Section 3.8 to somewhere before Section 3.4 might help. What happens if the constants are chosen such that the rule (5) is not possible to achieve? Section 3.6. The frequency at which temporary addresses change depends on how a device is being used (e.g., how frequently it initiates new communication) and the concerns of the end user. The most egregious privacy concerns appear to involve addresses used for long periods of time (weeks to months to years). The more frequently an address changes, the less feasible collecting or coordinating information keyed on interface identifiers becomes. Moreover, the cost of collecting information and attempting to correlate it based on interface identifiers will only be justified if enough addresses contain non-changing identifiers to make it worthwhile. Thus, having large numbers of clients change their address on a daily or weekly basis is likely to be sufficient to alleviate most privacy concerns. I don't disagree with the text, but is there anything we can cite here? Why do we think it's "sufficient," for example? Finally, when an interface connects to a new (different) link, existing temporary addresses for the corresponding interface MUST be eliminated, and new temporary addresses MUST be generated immediately for use on the new link. If the addresses are eliminated, how does one run DAD and ensure that the same (or similar) addresses are not used on the new link? Section 3.7. Devices implementing this specification MUST provide a way for the end user to explicitly enable or disable the use of temporary addresses. Why is this a MUST, rather than a SHOULD? Since this is effectively describing an API, I think this ought to be relaxed. Section 6. An implementation might want to keep track of which addresses are being used by upper layers so as to be able to remove a deprecated temporary address from internal data structures once no upper layer protocols are using it (but not before). It seems an application might also want to consider other information linkable to select addresses in the future. For example, TLS resumption may link clients across two different temporary addresses. (This goes back to my comment on Section 2.1 above.) From nobody Wed Jan 6 18:51:33 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1343A1466; Wed, 6 Jan 2021 18:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk7zQNkHuFPd; Wed, 6 Jan 2021 18:51:30 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34E53A1290; Wed, 6 Jan 2021 18:51:29 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id n10so3776321pgl.10; Wed, 06 Jan 2021 18:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MjSqEhTYe1vxKIVIBvOA0nU2xqkroFuWVOMOrhqZrF8=; b=pfKxrkkGSrh6u54LS3Z56aA3ebPneo9lcaRcdFjLdSzczDGXrTajOe46nnVNSe/3VL YAcsFYS8Tdr3GzasBUbgwLu/3DAccNGDUfoCIGknLMoCGZxxCYJ9AOuklJspdtEqWa9x 6UPegYD6yMTGkI7uRZR048BWZcdTXmD8pO/Zx5J2c0hPERHb11wTVAHtHQeg3V0lc/Rk y+JmRtniROAwkGuV8pqUkjIyg6z2i7zu5YmvWm0fHbHxI4O6CXQruuOXGzcWZEhYigNZ QvUus4b7ud4/mMeSDNi4GNe+60iPsVkGfdEBgFAKRQ8qNtPm+J+XpCI/Za5yDvPR5+bt or4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MjSqEhTYe1vxKIVIBvOA0nU2xqkroFuWVOMOrhqZrF8=; b=XPnTgXp78gwEmaGLFT5jD2yiwTfEsSCD7XhjhNgJ3RkbMzrL6WfyGFHjRb0rY62qg6 Ykd1waAGdIfTl3i7EiduWRp+DIREiTuKRH+C3/rZMokxYqur30yG8t6/vlLpF/WZ1Rhu B5jsl9bJgT+KsT9o2+wgXqpO1MEeYXJSJD3PafpAkxPUfZ6IugyhCCURbR9dIjUPM5qw WMr1Fdi8QUTRoXuq3Z++mqiW4nKbfsEIn0J29/kLXX9Mu1o48SXdPlsOr2Uw3k8pJSmv LFH9x7WHuvxplWKTA41Nzdcy3GMNFrpQC4hf6he4QCCyAXZO9ZK6lpqKvqczyZfLQ9RF +xWA== X-Gm-Message-State: AOAM532yaT+egs47YX592PrMCMORnZlWDaVumcDmY1754NIC1CFyJYp7 tl3vEileTR8vMXta4XkzNajC8O80uxAg3A== X-Google-Smtp-Source: ABdhPJyURsbqfGBfI1Lxv4Iy0mxzcxiFO4J5qOgZiAq9FXzt9ELy/gWQwjX1twdd9pbYG770pac4cA== X-Received: by 2002:a63:1863:: with SMTP id 35mr7710055pgy.191.1609987889112; Wed, 06 Jan 2021 18:51:29 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id p16sm3381582pju.47.2021.01.06.18.51.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jan 2021 18:51:28 -0800 (PST) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Fernando Gont , Lorenzo Colitti , Mark Smith Cc: IPv6 Operations , 6MAN <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> From: Brian E Carpenter Message-ID: <7b3809f0-2db4-bcff-b669-66911ee9c087@gmail.com> Date: Thu, 7 Jan 2021 15:51:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 02:51:31 -0000 On 07-Jan-21 11:23, Fernando Gont wrote: > On 6/1/21 18:30, Brian E Carpenter wrote: >> Portmanteau reply to multiple messages: >> >> On 06-Jan-21 20:07, Lorenzo Colitti wrote: ... >>> So I guess I'm somewhere between 1) and 3). The specs are >>> consistent but they fail to consider human behaviour, so they don't >>> actually work in practice. >> > [...] >> >> The problem is largely theoretical, and educational for people who >> train IPv4 users in IPv6 terminology and practices. As Fernando has >> pointed out, the use of the word "global" is confusing for something >> that has L for "local" in its name. >=20 > There is indeed a terminology issue, which ends up making it complicate= d=20 > to explain e.g. the concept of "scope" as a result. >=20 >=20 >=20 >> On 07-Jan-21 01:17, Ted Lemon wrote: ... >>> GUA: =E2=80=9Cvalid everywhere on the internet scope=E2=80=9D ULA: =E2= =80=9Cnot valid >>> everywhere scope=E2=80=9D LLA: =E2=80=9Cvalid only on this link scope= =E2=80=9D >> >> Friendly amendment: >> >> GUA: valid everywhere ULA: Unique Limited-domain Address LLA: valid >> only on this link >=20 > Would certainly also work. >=20 >=20 >> On 07-Jan-21 04:13, Philip Homburg wrote: ... >>> Some things don't need fixing even if they are not 100% correct. >> >> +1 >=20 > My take is that if the topics is confusing for us, we cannot expect it = > to be any better for others. >=20 >=20 >=20 >> On 07-Jan-21 05:26, Gert Doering wrote: ... >>> Why should applications, or anything that is not an admin, care if >>> an address is a ULA or a GUA? >> >> It depends on what you mean by "application". I've written code that >> explicitly prefers a ULA, and I could imagine a security spec saying >> "prefer ULA". But anyway, it's not really a problem, is it? (It's >> annoying to me that in Python, a ULA has .is_global =3D=3D False, but = I >> managed to code round that error.) >=20 > The question is: Is it an error? According to the addressing architecture and the ULA definition, it's an error. It's also a tricky one to fix, because who knows what running code might depend on it? A test for ULA-ness in Python, using only the address properties that the= ipaddress module already defines, is: def is_ula(a): """Test for ULA""" return (a.is_private and not a.is_link_local and not a.is_loopback and not a.is_unspecified) which also, not coincidentally, returns True for RFC1918 addresses. (Of course you could equally well do a bit-mask test.) > I've just checked the most "up to date" textbook that I have at hand on= =20 > IPv6. Page 335 has a subsection entitled "Global addresses versus ULAs"= =2E > The discussion in the textbook is indeed fine. >=20 > Could one actually make the case that e.g. Python's library should=20 > change? If it did, it would be counter intuitive. It would match=20 > RFC4193/4291, but not RFC4007, e.g. the textbook I've checked, and the = > intuitive meaning of private/global. That's of course exactly why the term "globally reachable" was added by RFC8190. My objection to the Python library is not that it provides the property .is_private, which is very clear, but that it asserts that ipaddress.IPv6Address("fd63:45eb:dc14:0:8546:6ab7:1529:b435").is_global is False. Because according to the Proposed Standard RFCs, ULAs are both private and global. Unfortunately I don't think it's reasonable to ask for a non-backwards- compatible change in the Python library. If you were maintaining such a widely used library, would you want to break compatibility? =20 > FWIW, I don't think there's a problem with how ULAs work. But I do thin= k=20 > that the terminology problem does have ramifications. Yes. Brian From nobody Wed Jan 6 20:01:07 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56793A14E8; Wed, 6 Jan 2021 20:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsvTBPYXXi7U; Wed, 6 Jan 2021 20:00:58 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B75F3A14EC; Wed, 6 Jan 2021 20:00:49 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A62272846D0; Thu, 7 Jan 2021 04:00:44 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Brian E Carpenter , Lorenzo Colitti , Mark Smith Cc: IPv6 Operations , 6MAN <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> <7b3809f0-2db4-bcff-b669-66911ee9c087@gmail.com> From: Fernando Gont Message-ID: <8345b02d-4c26-d5d8-7d85-1e85f3b15642@si6networks.com> Date: Thu, 7 Jan 2021 01:00:29 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <7b3809f0-2db4-bcff-b669-66911ee9c087@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 04:01:01 -0000 Hi, Brian, On 6/1/21 23:51, Brian E Carpenter wrote: [...] >> >>> On 07-Jan-21 05:26, Gert Doering wrote: ... >>>> Why should applications, or anything that is not an admin, care if >>>> an address is a ULA or a GUA? >>> >>> It depends on what you mean by "application". I've written code that >>> explicitly prefers a ULA, and I could imagine a security spec saying >>> "prefer ULA". But anyway, it's not really a problem, is it? (It's >>> annoying to me that in Python, a ULA has .is_global == False, but I >>> managed to code round that error.) >> >> The question is: Is it an error? > > According to the addressing architecture and the ULA definition, it's > an error. But this is where we go back to the original question: * RFC4007 says that global scope addresses are globally unique. * RFC4193 aims to reduce the collision fo a number of ULA prefixes when grouped together, but certainly does *not* result in globally-unique prefixes. Still, RFC4193 claims that ULAs globals. So from the pov of RFC4193, ULAs are globals. From the pov of RFC4007, they are not. Which of the two (RFC4007 vs RFC4193) takes precedence? > It's also a tricky one to fix, because who knows what running > code might depend on it? > > A test for ULA-ness in Python, using only the address properties that the > ipaddress module already defines, is: > > def is_ula(a): > """Test for ULA""" > return (a.is_private and not a.is_link_local > and not a.is_loopback > and not a.is_unspecified) > > which also, not coincidentally, returns True for RFC1918 addresses. > (Of course you could equally well do a bit-mask test.) > >> I've just checked the most "up to date" textbook that I have at hand on >> IPv6. Page 335 has a subsection entitled "Global addresses versus ULAs". >> The discussion in the textbook is indeed fine. >> >> Could one actually make the case that e.g. Python's library should >> change? If it did, it would be counter intuitive. It would match >> RFC4193/4291, but not RFC4007, e.g. the textbook I've checked, and the >> intuitive meaning of private/global. > > That's of course exactly why the term "globally reachable" was added > by RFC8190. My objection to the Python library is not that it provides > the property .is_private, which is very clear, but that it asserts that > ipaddress.IPv6Address("fd63:45eb:dc14:0:8546:6ab7:1529:b435").is_global > is False. Because according to the Proposed Standard RFCs, > ULAs are both private and global. [RFC4007] defines the scope of an address as: "[the] topological span within which the address may be used as a unique identifier for an interface or set of interfaces" And defines the "global scope" to be used for: "uniquely identifying interfaces anywhere in the Internet" Given ~1.2M ULA prefixes, you have a probability P~1 that there's a collision. In that light, it's hard to assert that they are globally unique, and hence that they have global scope.... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 21:22:28 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702BE3A0418; Wed, 6 Jan 2021 21:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7CZBK4Dv6rO; Wed, 6 Jan 2021 21:22:24 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0E63A0408; Wed, 6 Jan 2021 21:22:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F101D389AD; Thu, 7 Jan 2021 00:23:29 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Q5XRtFHrXu5J; Thu, 7 Jan 2021 00:23:28 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 950C4389AC; Thu, 7 Jan 2021 00:23:28 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C1DAF591; Thu, 7 Jan 2021 00:22:19 -0500 (EST) From: Michael Richardson To: Fernando Gont , IPv6 Operations , 6MAN <6man@ietf.org> Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) In-Reply-To: <8345b02d-4c26-d5d8-7d85-1e85f3b15642@si6networks.com> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> <7b3809f0-2db4-bcff-b669-66911ee9c087@gmail.com> <8345b02d-4c26-d5d8-7d85-1e85f3b15642@si6networks.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 05:22:26 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > But this is where we go back to the original question: > * RFC4007 says that global scope addresses are globally unique. > * RFC4193 aims to reduce the collision fo a number of ULA prefixes wh= en > grouped together, but certainly does *not* result in globally-unique > prefixes. Still, RFC4193 claims that ULAs globals. > So from the pov of RFC4193, ULAs are globals. From the pov of RFC4007= , they > are not. > Which of the two (RFC4007 vs RFC4193) takes precedence? It really doesn't matter, because Global has many terms. ULAs are globally unique (ideally), but are not globally routable. Their lack of routability is not an architectural consideration, but a bureaucratic RIR-based concern. They don't get RPSL, RPKI, whois or revers= e DNS. {Whether you are convinced of the statistics of ULA-R being unique or not, does not change the goal that they be unique} RFC4007 defines a Global Scope. (Not Global Routing) ULAs have Global Scope, and I see nothing in RFC4007 that contradicts that. Unless, you live in IPv4 land, and think that everything that isn't RFC1918 must be routable. And I'm sure that you don't think that way. This python library you mention is wrong, but being a python library, is probably too opinionate to listen to reason. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/2mosACgkQgItw+93Q 3WVVLggAtK0rkDtcqgj64CHq9DV1V/Udsw2Pz0iM0k0B/USXl+rXpZArpMgCCbT5 JDSPoGPyGdHx8yIVsWUnoSbnuppcX+a8ZCTgYAb6OmYKChxX5QWeDCgW0v+nsGIw BUwBto+px2NzNn7Ehma879Q5WtErS++guDaD/grmhbXPuPIPW1F3YnrN0K4V9UVt fBvZp7Up/BH6m5cyhAOMjZwQQ6ufXCjjqf8qdH8MkvO+hhMMDuIwEyItwigB1nkB AbOOCL9pWb+n9ZsaTzUbRZFq7e3oiB298EydYg6tCIyhlsRNrMdU9p6s/g1V82yj K6cgit6eYh8pz4pjap1K6ca1o/Qk/Q== =Lxev -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 6 22:11:15 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27523A091C; Wed, 6 Jan 2021 22:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF3jNnFGP0Fc; Wed, 6 Jan 2021 22:11:03 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A413A08B7; Wed, 6 Jan 2021 22:11:02 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 08B94280899; Thu, 7 Jan 2021 06:10:58 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Michael Richardson , IPv6 Operations , 6MAN <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> <7b3809f0-2db4-bcff-b669-66911ee9c087@gmail.com> <8345b02d-4c26-d5d8-7d85-1e85f3b15642@si6networks.com> <27939.1609996939@localhost> From: Fernando Gont Message-ID: <9ce92832-e698-a66a-58b3-28e6ab5e00d1@si6networks.com> Date: Thu, 7 Jan 2021 03:03:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <27939.1609996939@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 06:11:06 -0000 On 7/1/21 02:22, Michael Richardson wrote: > > Fernando Gont wrote: > > But this is where we go back to the original question: > > * RFC4007 says that global scope addresses are globally unique. > > > * RFC4193 aims to reduce the collision fo a number of ULA prefixes when > > grouped together, but certainly does *not* result in globally-unique > > prefixes. Still, RFC4193 claims that ULAs globals. > > > So from the pov of RFC4193, ULAs are globals. From the pov of RFC4007, they > > are not. > > > Which of the two (RFC4007 vs RFC4193) takes precedence? > > It really doesn't matter, because Global has many terms. It does. RFC 4193 claims that they have global scope. Global scope does have a meaning. > ULAs are globally unique (ideally), but are not globally routable. THey can't be globally routable, because they can't be globally unique. > Their lack of routability is not an architectural consideration, but a > bureaucratic RIR-based concern. They don't get RPSL, RPKI, whois or reverse DNS. > > {Whether you are convinced of the statistics of ULA-R being unique or not, > does not change the goal that they be unique} But this is a key thing: 10-1000 nets with no ULAs -> low probability of colission != global scope! > RFC4007 defines a Global Scope. (Not Global Routing) > ULAs have Global Scope, and I see nothing in RFC4007 that contradicts that. [RFC4007] defines the scope of an address as: "[the] topological span within which the address may be used as a unique identifier for an interface or set of interfaces" And defines the "global scope" to be used for: "uniquely identifying interfaces anywhere in the Internet" You have 40 bits for the "global ID" -- how many networks before collisions? And, at the global level, do you expet to be above or bellow that number of networks? If above, you won't have unique prefixes, and hence, per the definition of RFC4007, you don't hable global scope. > Unless, you live in IPv4 land, and think that everything that isn't RFC1918 > must be routable. And I'm sure that you don't think that way. They *can't* be globally routeable, because they are not globally unique. Similarly, even if you removed bogon filters etc, you cannot use 10.0.0.0/8 globally because they mean different things for each of us. -- they are not global scope. ULAs are just bigger (and yes, have a recommended algorithm for generating prefixes) such that if you grab a few ULA prefixes together, it's unlikely that there will be collisions. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 23:38:20 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCDC3A03F1; Wed, 6 Jan 2021 23:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhJrYFSe2FVV; Wed, 6 Jan 2021 23:38:17 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0DDC3A03EF; Wed, 6 Jan 2021 23:38:17 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5AD873BD545; Thu, 7 Jan 2021 07:38:17 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B4E9B16005A; Thu, 7 Jan 2021 07:38:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A2AA9160080; Thu, 7 Jan 2021 07:38:16 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sFq10-aUek07; Thu, 7 Jan 2021 07:38:16 +0000 (UTC) Received: from [172.30.42.68] (n114-75-149-106.bla4.nsw.optusnet.com.au [114.75.149.106]) by zmx1.isc.org (Postfix) with ESMTPSA id 86E1E16005A; Thu, 7 Jan 2021 07:38:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) From: Mark Andrews In-Reply-To: Date: Thu, 7 Jan 2021 18:38:12 +1100 Cc: Richard Patterson , Philip Homburg , IPv6 Operations , 6man WG Content-Transfer-Encoding: quoted-printable Message-Id: <91424EEE-EF12-4B5B-ADE4-38230E049290@isc.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.9.7) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 07:38:19 -0000 > On 7 Jan 2021, at 02:45, Fernando Gont wrote: >=20 > On 6/1/21 12:29, Richard Patterson wrote: >> On Wed, 6 Jan 2021 at 15:14, Philip Homburg = > = wrote: >> Applications should not do widely different things if they = encouter >> a ULA. >> But they do. >=20 > And good for them that they do. The ones that don't are the ones that = end up e.g. posting ULAs and link-locals on the public-facing DNS. Really AAAA records need to be replaced with something that identifies = the zone the IPv6 address is applicable to. A 128bit followed by a domain name would work. System would need to = which domain names where applicable to which links. I would expect the = could be done with a RA option. e.g. www.andrews.example.id.au. SA 2001:DB8::1c59:17c:a2ce:e9ee . www.andrews.example.id.au. SA fd37:287a:df67::1 = dv.andrews.example.id.au. www.andrews.example.id.au. SA fe80::14f4:ff53:6bfa:960b = link1.dv.andrews.example.id.au. www.andrews.example.id.au. SA ::ffff:10.0.0.1 = dv.andrews.example.id.au. The above has global, ULA, link-local and RFC 1918 addresses for a = fictional web server. =20 > (I've had to do it myself when using dynamic DNS updates, for = instance) >=20 > Cheers, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jan 7 03:09:12 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2EB3A0F4D for ; Thu, 7 Jan 2021 03:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVvRDAvMZpeX for ; Thu, 7 Jan 2021 03:09:04 -0800 (PST) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C403A0F5E for <6man@ietf.org>; Thu, 7 Jan 2021 03:09:03 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 4DBNlg1y12z9vC9L for <6man@ietf.org>; Thu, 7 Jan 2021 11:09:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63KnDc6b4s7r for <6man@ietf.org>; Thu, 7 Jan 2021 05:09:03 -0600 (CST) Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 4DBNlf5S01z9vC8R for <6man@ietf.org>; Thu, 7 Jan 2021 05:09:02 -0600 (CST) DMARC-Filter: OpenDMARC Filter v1.3.2 mta-p7.oit.umn.edu 4DBNlf5S01z9vC8R DKIM-Filter: OpenDKIM Filter v2.11.0 mta-p7.oit.umn.edu 4DBNlf5S01z9vC8R Received: by mail-ej1-f70.google.com with SMTP id dc13so2275967ejb.9 for <6man@ietf.org>; Thu, 07 Jan 2021 03:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cNrAGB4aYnFMnsAbLDyZ5/GVegnHYRzuUqOFB4yRgkQ=; b=qqlhBzf+KT04Qe9xb2DlAGvcQx+btPA4eGB4mPiIdp60WvYHaC80jiMg2qyIPPu3FP T0rVyQrBBWJ3GT32t28f/5w8entD0cSWztwY9Uv3fsNm9pUnurmOhLxDjpNEBhL3nBO+ BYpQNupWfxarJDRcmZa9ezaO/0jLQ8lULGEQzmxp6rUNZoag9z9Tptc6OmfVi+v9OMUE G+uzkqea2M+QE2Vu7S65z1HNGFGIH+WFrBu79ooOAiD27vbj32nWB7AsE0nsTVzwTKEL SS9aroClu2G3GzFbR4Ee8SYbgEa/S2q5WA00i0niPp5Qpa7Wa45oGncEGSKo+8KX2Hcl mauA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cNrAGB4aYnFMnsAbLDyZ5/GVegnHYRzuUqOFB4yRgkQ=; b=MAe+SKjeFiAEfGncjIpskNB3J5mN3z6zuD76qpdAK9zoH2OCm5fsgVMoZkd4ObHosz 5nAHajCM+wdGg6kD/NRStqnifnSXcNd7qX2pTdKxxaMOzrjOn14UOdBHmUhNSs+Xf47k hJl3SrpNHTDPre/bl2S5yXXsBy6uVP/a0ZLoJ5LJmgje/UFLjXWn/v9atYWtlXNnc+nA WwnkO864H+iDYYmKezhCLkb6AGkNeTee+8Dcm6GQymaLMq5e2hFm2ZBLx5rGIGyvwKtY iPSEWZnAxbV8tBdkK/zsUdROgEVYyDBCqH4Vrmy/4/GnLOBcOH+ev5Rfy2T7n5fVlMi5 aN5w== X-Gm-Message-State: AOAM5303hCVi9HNskUU19gj1yUnHA3NG/VHbt70aoSWCdvyzOWdV7Hk+ agalSfWQ1XWQqjo4NrMjald1+Kd4i+lrsjZ6dekjdErOXOeSDNtIgVRWwfZJIBsW8JHEkavFFNc 5FMVxXHOEEbsenwJP1tiPImVY X-Received: by 2002:a05:6402:2041:: with SMTP id bc1mr1250137edb.369.1610017739865; Thu, 07 Jan 2021 03:08:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJxM1qdJpl0fuqwZuE9ZLpjcN6nuTXgCy0HLPb7zag0jFyD5HuQzvaQQa3ZzKYJMGSO5xcPN/mFjkjZteWOgJkU= X-Received: by 2002:a05:6402:2041:: with SMTP id bc1mr1250115edb.369.1610017739457; Thu, 07 Jan 2021 03:08:59 -0800 (PST) MIME-Version: 1.0 References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> In-Reply-To: From: David Farmer Date: Thu, 7 Jan 2021 05:08:43 -0600 Message-ID: Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Fernando Gont Cc: Brian E Carpenter , Lorenzo Colitti , Mark Smith , IPv6 Operations , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000007164cf05b84d7792" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 11:09:06 -0000 --0000000000007164cf05b84d7792 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry for the top post. Fernando, you are correct that by the definition of global scope in RFC4007, ULA is not global scope. However, Brian and RFC4139 are also correct, given the intended reachability domain for ULA, it has a uniqueness that is many many orders of magnitude greater than is necessary for the task. So, while not technically global scope as defined in RFC4007 it is effectively global scope in any way that matters. I have an idea for what to call ULA's scope without redefining global scope in RFC4007, how about we call ULA's scope "pseudo-global" scope. This gives us; Link-Local > Site-Local >>>>>> Pseudo-Global > Global Yes, Site-Local is deprecated, it is just there for comparison. I'm trying to show that Link-Local and Site-Local are in the same neighborhood, and pseudo-global and global are in a completely different neighborhood. Calling ULA pseudo-global scope I believe conveys RFC4139's original intent without conflicting with the definition of global scope in RFC4007, while still allowing it to be treated effectively as if it is global scope. What do other people think? Thanks. On Wed, Jan 6, 2021 at 4:24 PM Fernando Gont wrote: > On 6/1/21 18:30, Brian E Carpenter wrote: > > Portmanteau reply to multiple messages: > > > > On 06-Jan-21 20:07, Lorenzo Colitti wrote: ... > >> So I guess I'm somewhere between 1) and 3). The specs are > >> consistent but they fail to consider human behaviour, so they don't > >> actually work in practice. > > > [...] > > > > The problem is largely theoretical, and educational for people who > > train IPv4 users in IPv6 terminology and practices. As Fernando has > > pointed out, the use of the word "global" is confusing for something > > that has L for "local" in its name. > > There is indeed a terminology issue, which ends up making it complicated > to explain e.g. the concept of "scope" as a result. > > > > > On 07-Jan-21 01:17, Ted Lemon wrote: ... > >> GUA: =E2=80=9Cvalid everywhere on the internet scope=E2=80=9D ULA: =E2= =80=9Cnot valid > >> everywhere scope=E2=80=9D LLA: =E2=80=9Cvalid only on this link scope= =E2=80=9D > > > > Friendly amendment: > > > > GUA: valid everywhere ULA: Unique Limited-domain Address LLA: valid > > only on this link > > Would certainly also work. > > > > On 07-Jan-21 04:13, Philip Homburg wrote: ... > >> Some things don't need fixing even if they are not 100% correct. > > > > +1 > > My take is that if the topics is confusing for us, we cannot expect it > to be any better for others. > > > > > On 07-Jan-21 05:26, Gert Doering wrote: ... > >> Why should applications, or anything that is not an admin, care if > >> an address is a ULA or a GUA? > > > > It depends on what you mean by "application". I've written code that > > explicitly prefers a ULA, and I could imagine a security spec saying > > "prefer ULA". But anyway, it's not really a problem, is it? (It's > > annoying to me that in Python, a ULA has .is_global =3D=3D False, but I > > managed to code round that error.) > > The question is: Is it an error? > > I've just checked the most "up to date" textbook that I have at hand on > IPv6. Page 335 has a subsection entitled "Global addresses versus ULAs". > The discussion in the textbook is indeed fine. > > Could one actually make the case that e.g. Python's library should > change? If it did, it would be counter intuitive. It would match > RFC4193/4291, but not RFC4007, e.g. the textbook I've checked, and the > intuitive meaning of private/global. > > FWIW, I don't think there's a problem with how ULAs work. But I do think > that the terminology problem does have ramifications. > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --0000000000007164cf05b84d7792 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the top post.

Fernando, you a= re correct that by the definition=C2=A0of global scope in RFC4007, ULA is n= ot global scope.

However, Brian and RFC4139 are al= so correct, given the intended reachability=C2=A0domain for ULA, it has a u= niqueness=C2=A0that is many many orders of magnitude=C2=A0greater than is n= ecessary for the task. So, while not technically=C2=A0global scope as defin= ed in RFC4007 it is effectively global scope in any way that matters.=C2=A0=

I have an idea for what to call ULA's scope w= ithout redefining global scope in RFC4007, how about we call ULA's scop= e "pseudo-global" scope.

This gives us;<= /div>

Link-Local > Site-Local >>>>>>= ; Pseudo-Global > Global

Yes, Site-Local is dep= recated, it is just there for comparison. I'm trying to show that Link-= Local and Site-Local are in the same neighborhood, and pseudo-global=C2=A0a= nd global are in a completely=C2=A0different=C2=A0neighborhood.
<= br>
Calling ULA pseudo-global scope I believe conveys RFC4139'= ;s original=C2=A0intent without conflicting with the definition=C2=A0of glo= bal scope in RFC4007, while still allowing it to be treated effectively as = if it is global scope.

What do other people=C2=A0t= hink?

Thanks.

On Wed, Jan 6, 2021 at 4:24 PM = Fernando Gont <fgont@si6network= s.com> wrote:
On 6/1/21 18:30, Brian E Carpenter wrote:
> Portmanteau reply to multiple messages:
>
> On 06-Jan-21 20:07, Lorenzo Colitti wrote: ...
>> So I guess I'm somewhere between 1) and 3). The specs are
>> consistent but they fail to consider human behaviour, so they don&= #39;t
>> actually work in practice.
>
[...]
>
> The problem is largely theoretical, and educational for people who
> train IPv4 users in IPv6 terminology and practices. As Fernando has > pointed out, the use of the word "global" is confusing for s= omething
> that has L for "local" in its name.

There is indeed a terminology issue, which ends up making it complicated to explain e.g. the concept of "scope" as a result.



> On 07-Jan-21 01:17, Ted Lemon wrote: ...
>> GUA: =E2=80=9Cvalid everywhere on the internet scope=E2=80=9D ULA:= =E2=80=9Cnot valid
>> everywhere scope=E2=80=9D LLA: =E2=80=9Cvalid only on this link sc= ope=E2=80=9D
>
> Friendly amendment:
>
> GUA: valid everywhere ULA: Unique Limited-domain Address LLA: valid > only on this link

Would certainly also work.


> On 07-Jan-21 04:13, Philip Homburg wrote: ...
>> Some things don't need fixing even if they are not 100% correc= t.
>
> +1

My take is that if the topics is confusing for us, we cannot expect it
to be any better for others.



> On 07-Jan-21 05:26, Gert Doering wrote: ...
>> Why should applications, or anything that is not an admin, care if=
>> an address is a ULA or a GUA?
>
> It depends on what you mean by "application". I've writt= en code that
> explicitly prefers a ULA, and I could imagine a security spec saying > "prefer ULA". But anyway, it's not really a problem, is = it? (It's
> annoying to me that in Python, a ULA has .is_global =3D=3D False, but = I
> managed to code round that error.)

The question is: Is it an error?

I've just checked the most "up to date" textbook that I have = at hand on
IPv6. Page 335 has a subsection entitled "Global addresses versus ULAs= ".
The discussion in the textbook is indeed fine.

Could one actually make the case that e.g. Python's library should
change? If it did, it would be counter intuitive. It would match
RFC4193/4291, but not RFC4007, e.g. the textbook I've checked, and the =
intuitive meaning of private/global.

FWIW, I don't think there's a problem with how ULAs work. But I do = think
that the terminology problem does have ramifications.

--
Fernando Gont
SI6 Networks
e-mail: fgont@si= 6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0=C2=A0 E= mail:farmer@umn.edu
Networking & Telecommunication Services
O= ffice of Information Technology
University of Minnesota=C2=A0=C2=A0
= 2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Mi= nneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--0000000000007164cf05b84d7792-- From nobody Thu Jan 7 03:26:58 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEF33A0FB8; Thu, 7 Jan 2021 03:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hZcOI2iCbIa; Thu, 7 Jan 2021 03:26:54 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [46.182.8.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D011A3A0FB6; Thu, 7 Jan 2021 03:26:53 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.16.1/8.16.1) with ESMTPSA id 107BQne7079755 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2021 11:26:50 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: David Farmer Cc: Fernando Gont , IPv6 Operations , 6MAN <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> From: Nick Hilliard Message-ID: <73bd1a42-d9e7-2d24-9689-e053f11a3a0e@foobar.org> Date: Thu, 7 Jan 2021 11:26:48 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.43 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 11:26:57 -0000 David Farmer wrote on 07/01/2021 11:08: > What do other people think? that ULA is a poor idea to start with, and that attempting to encapsulate its scope characteristics within 1, or 2, or even 3 words is unlikely to succeed in a way which encompasses its full subtlety. We are better off sticking with a particular phrase (the exact choice of which will end up disappointing some or maybe lots of people) and then defining what that means in free-text. This seems to be what draft-gont-6man-ipv6-ula-scope is attempting to do. Nick From nobody Thu Jan 7 03:41:45 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222FB3A0FDF; Thu, 7 Jan 2021 03:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlnjXTAYZIiw; Thu, 7 Jan 2021 03:41:41 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166753A0FDE; Thu, 7 Jan 2021 03:41:39 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kxTfc-0000M9C; Thu, 7 Jan 2021 12:41:36 +0100 Message-Id: To: ipv6@ietf.org Cc: Brian E Carpenter , IPv6 Operations Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> In-reply-to: Your message of "Thu, 7 Jan 2021 10:30:35 +1300 ." <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> Date: Thu, 07 Jan 2021 12:41:35 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 11:41:43 -0000 > > No, rewrite RFC 4007 and get rid of zone IDs. And the introduce interface I > Ds > > to select the interface of an outgoing packet, whether link-local or global > . > > Effectively that's what RFC3879 did. RFC4007 was a bit behind the > curve. As far as I know, zone IDs and interface IDs are exactly > equivalent (at least in POSIX and WinSock environments). IMHO this > is *only* a terminology question. > > > It doesn't change anything in practice, because that is what existing code > > does. > > Really? Using the interface ID for non-link-local addresses? It works on Linux and MacOS. On freebsd I get '2001:67c:2e8:3::c100:a4%re0: Name does not resolve' which suggests that they do an extra check in a library. I didn't check if the kernel handles it. From nobody Thu Jan 7 03:49:21 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159103A0FEA; Thu, 7 Jan 2021 03:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ONaOnSvK179; Thu, 7 Jan 2021 03:49:15 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B233A0FE8; Thu, 7 Jan 2021 03:49:15 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kxTmy-0000KhC; Thu, 7 Jan 2021 12:49:12 +0100 Message-Id: To: ipv6@ietf.org Cc: Mark Andrews , IPv6 Operations Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <91424EEE-EF12-4B5B-ADE4-38230E049290@isc.org> In-reply-to: Your message of "Thu, 7 Jan 2021 18:38:12 +1100 ." <91424EEE-EF12-4B5B-ADE4-38230E049290@isc.org> Date: Thu, 07 Jan 2021 12:49:11 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 11:49:20 -0000 > Really AAAA records need to be replaced with something that identifies > the zone the IPv6 address is applicable to. A 128bit followed by > a domain name would work. System would need to which domain names > where applicable to which links. I would expect the could be done > with a RA option. > > e.g. > www.andrews.example.id.au. SA 2001:DB8::1c59:17c:a2ce:e9ee . www.andrews.example.id.au. SA fd37:287a:df67::1 dv.andrews.example.id.au. www.andrews.example.id.au. SA fe80::14f4:ff53:6bfa:960b link1.dv.andrews.example.id.au. > www.andrews.example.id.au. SA ::ffff:10.0.0.1 dv.andrews.example.id.au. This looks nice, but I wonder how hard it is for this to get traction. From nobody Thu Jan 7 03:52:22 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8E33A0FF1; Thu, 7 Jan 2021 03:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.009, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xj6z438egmXb; Thu, 7 Jan 2021 03:52:20 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7263A0FF2; Thu, 7 Jan 2021 03:52:19 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kxTpt-0000CxC; Thu, 7 Jan 2021 12:52:13 +0100 Message-Id: To: ipv6@ietf.org Cc: David Farmer , IPv6 Operations Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> In-reply-to: Your message of "Thu, 7 Jan 2021 05:08:43 -0600 ." Date: Thu, 07 Jan 2021 12:52:13 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 11:52:21 -0000 >I have an idea for what to call ULA's scope without redefining global scope >in RFC4007, how about we call ULA's scope "pseudo-global" scope. >What do other people think? In my opinion we need to kill the RFC 4007 scope concept. We can define for example 'address types' that have no scope, but as a way to label different types of addresses. From nobody Thu Jan 7 05:08:18 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867343A108B for ; Thu, 7 Jan 2021 05:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSLHKMaBayvI for ; Thu, 7 Jan 2021 05:08:14 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2723A1086 for ; Thu, 7 Jan 2021 05:08:09 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id r17so6575297ilo.11 for ; Thu, 07 Jan 2021 05:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HXOk9zpsltNr56BSv3WdZM/7EMy6eG3cO3azLkmWbzY=; b=s8YRhV7SLLm9qvgFs6GUhYBRTymnT0yIh1Or4NWHi0udhXxcNk1mc3evc4usppEWkl sRfjJ0VcNLjYSHjjnyBiFCHXWPJ6dBIbPOpGcWPHzLdZVHRIRuNJOl+Yv8dOtuIbnOIa Kh/fuD2fH7Xmdg+Vz5n2YNCR9sTzmTz22RDNUFmNXR7BIIFs0kXdoCVab/uKwEjOKNyD xsp/utOsazpAk69scWFLeDimROC+Fq77gvfTyir+vulYcNjB4hMD+JwsD8XmpsIggUhT hClFAKzfON6aXTNfXVJ8dHVUEvHwvhoagZxWGDeSdh/iAwBm+ybgagm8tT1GhuJhjpbQ 6/sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HXOk9zpsltNr56BSv3WdZM/7EMy6eG3cO3azLkmWbzY=; b=TDYGbElR5mmNoh1T8idzgBARoaNQo4YNI5Uo+3vDpiDqgZ9eCXMIz3e+f1AsUBebTj kNzIsz8BadkOzdon6TDr7ZwODahtaqxsSZ5jOSmBzmYtAn5y6IwdmD9GwBSPpzJquylC 0r7VWpsbjEs4M+6kPOVb2OLxOkfwj3zE261pdRYWNad2TBvDrzUVwN4z0KNevc6BkD6e znA5kuNZgyXNArS9Nf5E8EfgfLjaVLVuZDUA+m1ek/zYFcONcHA5xdtjJcnM2aw2qgKT 0R3HWSOc1iVCJtVJ3kX1y9AEM5zUIKDFe1HHCW/yScBqwT2JJy2o2E7IbY5hnL+IRfow VSqw== X-Gm-Message-State: AOAM531rMw263PQ2BUcTyKwTgGDFZhVrT2ddqHOUmuoy46WpAxNtMCKG 2w2wkpz2wpViAwHXIcQT6PIacA== X-Google-Smtp-Source: ABdhPJyexQvE2MSBunyO7opsHvBakyZHb+8tHdWd7Tful9L20a26Xbb237Tj1iv9VYJg0zhhQFYVIg== X-Received: by 2002:a05:6e02:20cc:: with SMTP id 12mr9134824ilq.91.1610024888499; Thu, 07 Jan 2021 05:08:08 -0800 (PST) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id f20sm4442509ilj.14.2021.01.07.05.08.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 05:08:07 -0800 (PST) From: Ted Lemon Message-Id: <6F3726EE-F089-4F26-BB30-F22686617C03@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DC93ABDD-F5B5-405A-BCB2-0DC40F61D11C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Thu, 7 Jan 2021 08:08:05 -0500 In-Reply-To: Cc: IPv6 List , IPv6 Operations , Mark Andrews To: Philip Homburg References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <91424EEE-EF12-4B5B-ADE4-38230E049290@isc.org> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 13:08:17 -0000 --Apple-Mail=_DC93ABDD-F5B5-405A-BCB2-0DC40F61D11C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 7, 2021, at 6:49 AM, Philip Homburg = wrote: > This looks nice, but I wonder how hard it is for this to get traction. And for that matter how hard it would be to implement, and what the = benefit would be, versus the drawbacks. Most of the time when people do = split DNS, it=E2=80=99s because they want information behind the = firewall to be invisible globally not so much for operational reasons = (because they wouldn=E2=80=99t work) but because they don=E2=80=99t want = to reveal the inner workings of the network behind the firewall. So even = if this feature Mark=E2=80=99s proposing were widely implemented in host = resolvers (which it would have to be to be useful), and even if we had = the technology to actually populate this sort of information accurately = in the DNS, I think most people who operate DNS servers that could in = principle advertise non-global addresses this way would choose not to. = So yeah, I=E2=80=99d predict not much uptake. On Jan 7, 2021, at 6:26 AM, Nick Hilliard wrote: > that ULA is a poor idea to start with, and that attempting to = encapsulate its scope characteristics within 1, or 2, or even 3 words is = unlikely to succeed in a way which encompasses its full subtlety. We = are better off sticking with a particular phrase (the exact choice of = which will end up disappointing some or maybe lots of people) and then = defining what that means in free-text. This seems to be what = draft-gont-6man-ipv6-ula-scope is attempting to do. If you mean =E2=80=9Cthe name ULA is a poor idea=E2=80=9D then I would = tend to agree, although not vehemently. I definitely agree that trying = to mechanically define the scope of a ULA is impossible. On Jan 6, 2021, at 9:51 PM, Brian E Carpenter = wrote: >> I've just checked the most "up to date" textbook that I have at hand = on=20 >> IPv6. Page 335 has a subsection entitled "Global addresses versus = ULAs". >> The discussion in the textbook is indeed fine. >>=20 >> Could one actually make the case that e.g. Python's library should=20 >> change? If it did, it would be counter intuitive. It would match=20 >> RFC4193/4291, but not RFC4007, e.g. the textbook I've checked, and = the=20 >> intuitive meaning of private/global. >=20 > That's of course exactly why the term "globally reachable" was added > by RFC8190. My objection to the Python library is not that it provides > the property .is_private, which is very clear, but that it asserts = that > = ipaddress.IPv6Address("fd63:45eb:dc14:0:8546:6ab7:1529:b435").is_global > is False. Because according to the Proposed Standard RFCs, > ULAs are both private and global. >=20 > Unfortunately I don't think it's reasonable to ask for a = non-backwards- > compatible change in the Python library. If you were maintaining such > a widely used library, would you want to break compatibility? I=E2=80=99d be really curious to know how this is used, and whether it = works. I suspect it works poorly, and hence backwards compatibility is = not an issue, but without knowing how it=E2=80=99s actually used, who = can really say? What does my code do if is_global is false? If it is = true? Is it possible that because of this library, connections that = could be made aren=E2=80=99t being made, because a valid, usable address = is being ignored?= --Apple-Mail=_DC93ABDD-F5B5-405A-BCB2-0DC40F61D11C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 7, 2021, at 6:49 AM, = Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com> = wrote:
This looks nice, but I wonder how hard it is for this to get = traction.

And for that = matter how hard it would be to implement, and what the benefit would be, = versus the drawbacks. Most of the time when people do split DNS, it=E2=80=99= s because they want information behind the firewall to be invisible = globally not so much for operational reasons (because they wouldn=E2=80=99= t work) but because they don=E2=80=99t want to reveal the inner workings = of the network behind the firewall. So even if this feature Mark=E2=80=99s= proposing were widely implemented in host resolvers (which it would = have to be to be useful), and even if we had the technology to actually = populate this sort of information accurately in the DNS, I think most = people who operate DNS servers that could in principle advertise = non-global addresses this way would choose not to. So yeah, I=E2=80=99d = predict not much uptake.

On Jan 7, 2021, at 6:26 AM, = Nick Hilliard <nick@foobar.org> wrote:
that ULA is a poor idea to = start with, and that attempting to encapsulate its scope characteristics = within 1, or 2, or even 3 words is unlikely to succeed in a way which = encompasses its full subtlety.  We are better off sticking with a = particular phrase (the exact choice of which will end up disappointing = some or maybe lots of people) and then defining what that means in = free-text.  This seems to be what draft-gont-6man-ipv6-ula-scope is = attempting to do.

If you mean =E2=80=9Cthe name = ULA is a poor idea=E2=80=9D then I would tend to agree, although not = vehemently. I definitely agree that trying to mechanically define the = scope of a ULA is impossible.

On Jan 6, 2021, at 9:51 PM, = Brian E Carpenter <brian.e.carpenter@gmail.com> = wrote:
I've just checked the most = "up to date" textbook that I have at hand on 
IPv6. = Page 335 has a subsection entitled "Global addresses versus ULAs".
The discussion in the textbook is indeed fine.

Could one actually make the case that e.g. = Python's library should 
change? If it did, it would = be counter intuitive. It would match 
RFC4193/4291, = but not RFC4007, e.g. the textbook I've checked, and the 
intuitive meaning of private/global.

That's of course exactly why the term = "globally reachable" was added
by RFC8190. My = objection to the Python library is not that it provides
the property .is_private, which is very clear, but that it = asserts that
ipaddress.IPv6Address("fd63:45eb:dc14:0:8546:6ab7:1529:b435")= .is_global
is False. Because according to the Proposed = Standard RFCs,
ULAs are both private and = global.

Unfortunately I don't = think it's reasonable to ask for a non-backwards-
compatible change in the Python library. If you were = maintaining such
a widely used library, would you want = to break compatibility?

I=E2=80=99d be really curious = to know how this is used, and whether it works. I suspect it works = poorly, and hence backwards compatibility is not an issue, but without = knowing how it=E2=80=99s actually used, who can really say? What does my = code do if is_global is false? If it is true? Is it possible that = because of this library, connections that could be made aren=E2=80=99t = being made, because a valid, usable address is being = ignored?
= --Apple-Mail=_DC93ABDD-F5B5-405A-BCB2-0DC40F61D11C-- From nobody Thu Jan 7 06:55:30 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF753A11DC; Thu, 7 Jan 2021 06:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCImI63Zm8-s; Thu, 7 Jan 2021 06:55:26 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9E03A11D8; Thu, 7 Jan 2021 06:55:25 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kxWh9-0000ImC; Thu, 7 Jan 2021 15:55:23 +0100 Message-Id: To: ipv6@ietf.org Cc: Ted Lemon , IPv6 Operations Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <91424EEE-EF12-4B5B-ADE4-38230E049290@isc.org> <6F3726EE-F089-4F26-BB30-F22686617C03@fugue.com> In-reply-to: Your message of "Thu, 7 Jan 2021 08:08:05 -0500 ." <6F3726EE-F089-4F26-BB30-F22686617C03@fugue.com> Date: Thu, 07 Jan 2021 15:55:21 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 14:55:29 -0000 > And for that matter how hard it would be to implement, and what > the benefit would be, versus the drawbacks. Most of the time > when people do split DNS, it's because they want information > behind the firewall to be invisible globally not so much for > operational reasons (because they wouldn't work) but because > they don't want to reveal the inner workings of the network > behind the firewall. So even if this feature Mark's proposing > were widely implemented in host resolvers (which it would have > to be to be useful), and even if we had the technology to actually > populate this sort of information accurately in the DNS, I think > most people who operate DNS servers that could in principle > advertise non-global addresses this way would choose not to. So > yeah, I'd predict not much uptake. I can see a few benefits of Mark's proposal. One is that it is good to have a standard representation of information. In particular, Mark's proposal would make it possible to have a master zone file that has both public and private DNS entries. Then a split-DNS server could serve only the public data to the outside world. At the same time, I think it would be great if we can put link-local addresses in DNS. There may be more applications, for example in the context of VPNs. It may tie in nicely with scope IDs in socket addresses. If a DNS record specifies that is valid only on a VPN link, then maybe we can already tie the address to that link. No need to change applications, it can be hidden in the stub resolver. From nobody Thu Jan 7 07:09:03 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2343A11F3 for ; Thu, 7 Jan 2021 07:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24UmEGTeyKRI for ; Thu, 7 Jan 2021 07:09:00 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E8D3A11F0 for ; Thu, 7 Jan 2021 07:09:00 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id j26so4376998qtq.8 for ; Thu, 07 Jan 2021 07:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=i/xEVBkSieHZArJg8d3oJd2WhMQxpjhvY8+lzHUpDWg=; b=NEYlJ1RT9rcLO8WdESHVD5gmEiSPslWDLLKDVneWUICINTMP2W0BVS8o9K/oWGd04X bNvHxElMhwV7Wj5nA3dya+P6X00Z5XMuyJ1wGZUpLXPKzsZL+61lmBLr+VpkWKEr10zX B3Zf5uLBOpl1VC4SGn4OaWV2Bw7q5zcprtTN8qVhRs4IgAq4/YmGH+YCPGKdTnFaeO94 dQmfcBpmdCfSu8LwtT5lee3faKO67EHdp8yi4uvu9MTJD1f2h6AHKFb2arbGTDdPlwju npjcl5mv6mJLwqDSs+SRrQsLT1dxbp/iWzb5netN+JC9CZ+rmpRHtkkwkhKaaJuwbWz2 zQLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=i/xEVBkSieHZArJg8d3oJd2WhMQxpjhvY8+lzHUpDWg=; b=V78MeIhDIaQulZUHwuV8ur8jQtN1Vk9cn68MuvVJ39KExQnFRcA11vSNGg4l+nl/43 8/1Jq8s/myIPZgrdkZIw43o3DsGM2u1xBz/AnjhxKWOCrAG3aKgKU66v+mKaBgEODGB+ VnIQ7/itYupKichuGC9U3Kpi4DSSbTnMM6Uce8qoUJarZzZWy+/F36gM1/E4oMgLijdN vLXzdVF+ohnaph0jmDhpRrnqyLTcemv/rH8QQZidjWQB2GQXBbtZSv3PFq5gS2rduGnr Egx47WOOrlg7W8akpUSQedtamNIHkgzD/UXv1Isq0ZkoYOannEHKWJYhtd67cw7IviGO S84Q== X-Gm-Message-State: AOAM532qWe5guSWTWnyuOC5bcHVr3QEeBCrnPI+7U2UwWrWoh228MY8H KPHY7otORpYaAXSuBDOghCFBkQ== X-Google-Smtp-Source: ABdhPJxJZ5tXCkLrHP76EIBlwK0wUSI3A6bNT2GfpPFHwIQ+sKAjRYCGWKaBargVi/6VvzVHrLGFQA== X-Received: by 2002:ac8:47da:: with SMTP id d26mr8681000qtr.4.1610032139164; Thu, 07 Jan 2021 07:08:59 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id c2sm3196157qke.109.2021.01.07.07.08.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 07:08:58 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6C76C077-BFCE-4960-8931-385B55739E09" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Thu, 7 Jan 2021 10:08:56 -0500 In-Reply-To: Cc: IPv6 List , IPv6 Operations To: Philip Homburg References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <91424EEE-EF12-4B5B-ADE4-38230E049290@isc.org> <6F3726EE-F089-4F26-BB30-F22686617C03@fugue.com> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 15:09:02 -0000 --Apple-Mail=_6C76C077-BFCE-4960-8931-385B55739E09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 7, 2021, at 9:55 AM, Philip Homburg = wrote: > I can see a few benefits of Mark's proposal. One is that it is good to > have a standard representation of information. In particular, > Mark's proposal would make it possible to have a master zone file that = has > both public and private DNS entries. Then a split-DNS server could = serve > only the public data to the outside world.=20 That=E2=80=99s a good point, although it would still be a good point if = this were just a feature of the zone file and not of the wire format. > At the same time, I think it would be great if we can put link-local = addresses > in DNS.=20 That sounds like a really heavy lift. > It may tie in nicely with scope IDs in socket addresses. If a DNS > record specifies that is valid only on a VPN link, then maybe we can = already > tie the address to that link. No need to change applications, it can = be > hidden in the stub resolver. Now we need to standardize a way to identify links. This is a Hard = Problem. I say this based on experience, not supposition. HNCP tried to = do this, not as successfully as I=E2=80=99d hoped. I=E2=80=99ve been = working on it for the Thread Border Router work, and haven=E2=80=99t = come up with a general solution. Sure, if you have a data center and a = managed multi-subnet LAN, and you can just type in configurations, this = works, but most networks aren=E2=80=99t like that. I think the VPN case = is probably tractable, but it=E2=80=99s really hard to see a path to = broad adoption for this idea. If there is a path to broad adoption, it probably involves bottom-up = work, not top-down design. Most of the ideas I=E2=80=99ve had about this = that I think are practicable are very context-dependent. E.g., you can = identify that you are on the same link because you received a = link-scoped multicast. --Apple-Mail=_6C76C077-BFCE-4960-8931-385B55739E09 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 7, 2021, at 9:55 AM, Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com> wrote:
I can see a = few benefits of Mark's proposal. One is that it is good to
have a = standard representation of information. In particular,
Mark's = proposal would make it possible to have a master zone file that = has
both public = and private DNS entries. Then a split-DNS server could serve
only the = public data to the outside world. 

That=E2=80=99s a good point, although = it would still be a good point if this were just a feature of the zone = file and not of the wire format.

At the same time, I think it = would be great if we can put link-local addresses
in = DNS. 

That = sounds like a really heavy lift.

It may tie in nicely with = scope IDs in socket addresses. If a DNS
record specifies that is = valid only on a VPN link, then maybe we can already
tie the = address to that link. No need to change applications, it can = be
hidden in the stub resolver.

Now we need to standardize a way to = identify links. This is a Hard Problem. I say this based on experience, = not supposition. HNCP tried to do this, not as successfully as I=E2=80=99d= hoped. I=E2=80=99ve been working on it for the Thread Border Router = work, and haven=E2=80=99t come up with a general solution. Sure, if you = have a data center and a managed multi-subnet LAN, and you can just type = in configurations, this works, but most networks aren=E2=80=99t like = that.  I think the VPN case is probably tractable, but it=E2=80=99s = really hard to see a path to broad adoption for this idea.

If there is a path to = broad adoption, it probably involves bottom-up work, not top-down = design. Most of the ideas I=E2=80=99ve had about this that I think are = practicable are very context-dependent. E.g., you can identify that you = are on the same link because you received a link-scoped = multicast.

= --Apple-Mail=_6C76C077-BFCE-4960-8931-385B55739E09-- From nobody Thu Jan 7 08:03:16 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2DC3A12C0; Thu, 7 Jan 2021 08:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bicmG910BXzH; Thu, 7 Jan 2021 08:03:07 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B593A12AE; Thu, 7 Jan 2021 08:03:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 294EB389B1; Thu, 7 Jan 2021 11:04:14 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id v9VENTIA8t2c; Thu, 7 Jan 2021 11:04:13 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B013A389B0; Thu, 7 Jan 2021 11:04:13 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 99BB864F; Thu, 7 Jan 2021 11:03:03 -0500 (EST) From: Michael Richardson To: Ted Lemon , IPv6 Operations , IPv6 List Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) In-Reply-To: References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <91424EEE-EF12-4B5B-ADE4-38230E049290@isc.org> <6F3726EE-F089-4F26-BB30-F22686617C03@fugue.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 16:03:15 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: > On Jan 7, 2021, at 9:55 AM, Philip Homburg wrote: >> I can see a few benefits of Mark's proposal. One is that it is good = to >> have a standard representation of information. In particular, >> Mark's proposal would make it possible to have a master zone file th= at has >> both public and private DNS entries. Then a split-DNS server could s= erve >> only the public data to the outside world. > That=E2=80=99s a good point, although it would still be a good point = if this > were just a feature of the zone file and not of the wire format. No, it has to get into the wire format, and it has to be cachable on the client, and it has to evaluated on the client as close to the application as possible. Why? because caching is good, and throwing away your cache each time you ha= ve a link up/down is dumb in my opinion. Having said that, I think it's mostly too late to make a change like this. Convince me wrong with deployed code :-) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/3MLcACgkQgItw+93Q 3WUZNAgAmRcfDoJPKptPZRSx1TbWMgnd9pO7ZTw3alYeIYRVpdA8HaPuA5IMUzN1 AzvpilgTH53W+k/fn3B841UGGZSLfnaM5RqDFD4wpnM978dyN8/uMhMRZ//aBiGU 4OKr5PnMgUTrbEpmq0tsN2tXYY3zeOggLlnuyVektp8nbUpCouEkhnblS2iDwnVT 3jAcZIYos8OtFgECH2Ev2TVZflRFG+L9VlcIllhIQVtsDLF9uUEaJ0NYPbQlw1Q7 PmSrSSYaNqjiqNYR9TAAQ3lI9ahX1FQaHrR7/0GIhTJ5eUIqsDh2f6pcx2Jg9BzE U5+qYXT7/7uqcWJqZxuvkYJUCokJ0w== =6HWX -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 7 09:00:49 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C853A12A4 for ; Thu, 7 Jan 2021 09:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT9qElSHY0yc for ; Thu, 7 Jan 2021 09:00:45 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338D33A129F for ; Thu, 7 Jan 2021 09:00:44 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id 22so6016442qkf.9 for ; Thu, 07 Jan 2021 09:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0zjDd9zBeMMx7wlSt7B/rMozcs8c0Djrh+/nOzBJwcM=; b=fxveEez1yVPCpFfGoEB6M6EJQz6smV8H2ZvSp03zyCpdWQFU8JuAu+2tb2fKHWD+Pw h2K/Kk5wbM/RIbG5b27HIleoISs6MrVK8wGdRqeg7nM4LnEAZFsFzRrgSQxKPfaRqIiD zyRGwaYBbZxf9zqYFYEbzWvY+mopHgkdOxGgmYrE6bWGXgP9oP1cH3ihgJfE/yzZQJqM BcXpX0JUsZRgvNjkLSIsBXRJU2qLUP5ehAtiDQ/YnlGwLvTLlBuo4fikn0H+E+rOazpJ IllnMy6zfI0ILucGIPvHawRuZaC0pW5HMjHhqtbscj/OIwd9jMAFF7/13UolbXb9tiq3 skXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0zjDd9zBeMMx7wlSt7B/rMozcs8c0Djrh+/nOzBJwcM=; b=dPIU1bUf6gSV8ARrh7p465RhQhvh39RUB8K6F43jsj5dCQj4iw5dz1Ajpi3ALeEzD3 /mDt0hcLj3l1pqYccZ1SsDlvDF8CiuH6nEi7ahJw5PikNzdv8dRJ5R1s/Vz/HX0NIJve 5GpO3k///VqE5Yc/P466nCeM59APbnQD7uJuYfsDpLp11WbkZ41IZQwnm/0ThJNpF99X w656JYuXzTMmRzuvDYitmZNS6oBiAlJorvTUQ+gMgLFIH1WP/QyaUA7zfZcFOep/o304 aElpQIxrjc2n8NAC0ze2LZbq1NuaotZclXCI7sMKDbS712sN5LvwZCPDJ9edqCTmuVdP U2AA== X-Gm-Message-State: AOAM5335bQBGMv9vSJgw1LOZwUfnhuWI+c9yVW8f7gyZmEjCMTtoV18D pLn49+OVqQq3V89c4FGYArfrylhdiMej7w== X-Google-Smtp-Source: ABdhPJyKLEZDW5P8ewdnNcg/RMV+RD28BFdoK91zy6NfGsWC/sYybnLtrOWO5kkIfMAfwJj/j8cJiw== X-Received: by 2002:a05:620a:2297:: with SMTP id o23mr10099066qkh.149.1610038843972; Thu, 07 Jan 2021 09:00:43 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id p15sm3356844qke.11.2021.01.07.09.00.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 09:00:42 -0800 (PST) From: Ted Lemon Message-Id: <48FF13BF-D878-4706-BB62-429273AD0EBE@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4CCC9A5D-F6AB-494A-AFDD-6B29A4F37DAF" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Thu, 7 Jan 2021 12:00:42 -0500 In-Reply-To: <21510.1610035383@localhost> Cc: IPv6 Operations , IPv6 List To: Michael Richardson References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <91424EEE-EF12-4B5B-ADE4-38230E049290@isc.org> <6F3726EE-F089-4F26-BB30-F22686617C03@fugue.com> <21510.1610035383@localhost> X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 17:00:47 -0000 --Apple-Mail=_4CCC9A5D-F6AB-494A-AFDD-6B29A4F37DAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 7, 2021, at 11:03 AM, Michael Richardson = wrote: > No, it has to get into the wire format, and it has to be cachable on = the > client, and it has to evaluated on the client as close to the = application as > possible. >=20 > Why? because caching is good, and throwing away your cache each time = you have > a link up/down is dumb in my opinion. I don=E2=80=99t think this would help, because you=E2=80=99re assuming = that the data would be correct, and that the host would be able to tell = which view to use. This is Really Hard. I don=E2=80=99t think that = relying on this operationally could ever be a good tradeoff to save a = few round trips to the nearest cache. Since we don=E2=80=99t have a way to reliably identify links, and for = that matter to tell which link is in which zone, we can=E2=80=99t do the = efficient thing you are talking about. In practice, all resolvers that I = know of (admittedly, this is just one, mDNSResponder) do in fact throw = away the cache whenever the link changes, for exactly the reason we are = talking about: just because the info I got from the resolver was valid = on the link I was previously on, doesn=E2=80=99t mean it=E2=80=99s valid = on the link I=E2=80=99m currently on. Remember, just because something is efficient in principle, doesn=E2=80=99= t mean that it=E2=80=99s efficient in practice. :) --Apple-Mail=_4CCC9A5D-F6AB-494A-AFDD-6B29A4F37DAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 7, 2021, at 11:03 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
No, it has to get into the wire format, and it has to be = cachable on the
client, and it has to evaluated on the client as close to the = application as
possible.

Why? because caching is good, and throwing away your cache = each time you have
a link up/down is dumb in my = opinion.

I = don=E2=80=99t think this would help, because you=E2=80=99re assuming = that the data would be correct, and that the host would be able to tell = which view to use. This is Really Hard. I don=E2=80=99t think that = relying on this operationally could ever be a good tradeoff to save a = few round trips to the nearest cache.

Since we don=E2=80=99t have a way to = reliably identify links, and for that matter to tell which link is in = which zone, we can=E2=80=99t do the efficient thing you are talking = about. In practice, all resolvers that I know of (admittedly, this is = just one, mDNSResponder) do in fact throw away the cache whenever the = link changes, for exactly the reason we are talking about: just because = the info I got from the resolver was valid on the link I was previously = on, doesn=E2=80=99t mean it=E2=80=99s valid on the link I=E2=80=99m = currently on.

Remember, just because something is efficient in principle, = doesn=E2=80=99t mean that it=E2=80=99s efficient in practice. = :)

= --Apple-Mail=_4CCC9A5D-F6AB-494A-AFDD-6B29A4F37DAF-- From nobody Thu Jan 7 09:54:01 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07E43A0407 for ; Thu, 7 Jan 2021 09:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=aqHCftqe; dkim=pass (1024-bit key) header.d=juniper.net header.b=HoBdl2S6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Lrt8heST7W4 for ; Thu, 7 Jan 2021 09:53:58 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75FC53A0B33 for <6man@ietf.org>; Thu, 7 Jan 2021 09:53:55 -0800 (PST) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 107HiomE022937 for <6man@ietf.org>; Thu, 7 Jan 2021 09:53:55 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=uKgGqG9OOFmn534+0wIDVXHVh3pCUi1hgGEl5nmiXx8=; b=aqHCftqeTIUtInzgj+U4+3hyPWeMZrzeDzHGYNHfxSSIWHZT50TCouRIZrH/KI3ZDhAv Plqm+C0PBsMUwVjpMlzMiZW4dbVMFdZ8nBI9C4tahXVxWkN1/xv6o9KRpoLtvkBtLBdH UOGSDDYiP1TV4RaXbJUxMb3+qZgyaFvlbgF4622+v/J7VVxZkna9F9hBC1w1FY5Zgfik kqZ4G14y8PUGP2pF+UcYRSyQY3PHRcecpeOX4VqZ8FX9t+S0wIEUxwnAsTi+tihqOWrj 8tXJmAVMRAk80DGApK6N7I2Pgmyjx0ix8C/Gfi3FizTP1dUm5R8wsTQ6Bnys4BHbTMzY 1w== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2172.outbound.protection.outlook.com [104.47.55.172]) by mx0a-00273201.pphosted.com with ESMTP id 35wqbyscj2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <6man@ietf.org>; Thu, 07 Jan 2021 09:53:55 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZAT2+75K+5QaKziJlPeYnvd2QwCXtjGgsp0u7haHNUU3959Gsv99JVgfG6nfK3vTNMA47FlJ/n2JgNRt+fUljw2JqYUoS5+cF4cs/kNeF544OFI8YdHdP2HaMJo73ER0fu+1LLHUQAI6618NoE0c5PqfHDPlN4hVh0HaLX5sMCqD92oMt+urJydUAdV8PXX81QpAxis0QUd/VNNBnSCeqxN/piYjXHMbhpXjYvKwUSl3xyel00sREK5bd4FoVOVCeuOqV4yTapZeSg2WfvCV6hFKUNS1+a+b5VHHpLloWfgmPhrjcdPlSXzsEemtPAodlYqoCNm9plHiKZP29Ud2Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uKgGqG9OOFmn534+0wIDVXHVh3pCUi1hgGEl5nmiXx8=; b=R7Iuq7uURVuwucKPH/mhUVayL0SPaodjTMQvkBewQZIn88ZHbEf+k5gDbyKCbBDsPmf3V85SVIaVW0ujatkNS6akPB7dq7uef+ra4PhALRzer1Up8ent0lY863t2a6shiI/hym8R2oLS32JOE1H4PnqyyPmLfn6cXtz3pehxuQh/V/Jt/N3oJRm7v53kqh8Ew8fMq0B+TfkC96SUb5MiBzSxzvK4yTJLpkD/jyEXVMb0F4cW4KgfF6p2kN1P0zPDbFUHI4gGk6poGFkN135X3rTjA1mthzGIs4VsGBsgNpkfd1jX8zeS556SsYEwJrbhIczVfmWWJjQ+clt7aYvlrg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uKgGqG9OOFmn534+0wIDVXHVh3pCUi1hgGEl5nmiXx8=; b=HoBdl2S6N7ptcJJrS8CSYwN1ZcwML0SvSHYlxaeZp9o7qcVVJXYSWv18VR0fUv1LDLNPRoufVkGHH0/+yFmcQ7/qJKsiCcSakupQVP+3v1FDlK2HxHa0fL+puRBcR3V2YszWRAR9/cXnoJLJgQsnRXHlcO7b65SoVbl27xCMtDI= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (20.178.224.143) by DM5PR0501MB3829.namprd05.prod.outlook.com (10.167.106.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.2; Thu, 7 Jan 2021 17:53:52 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::a435:88ed:7e2a:4fe6]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::a435:88ed:7e2a:4fe6%5]) with mapi id 15.20.3763.004; Thu, 7 Jan 2021 17:53:52 +0000 From: Ron Bonica To: "6man@ietf.org" <6man@ietf.org> Subject: Forwarding Packets With Link Local Destination Addresses Thread-Topic: Forwarding Packets With Link Local Destination Addresses Thread-Index: AdblHDzlHUUyT5iKRq6/0g3froJALQ== Date: Thu, 7 Jan 2021 17:53:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-01-07T17:53:50Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=eadb069c-124b-4e69-8f03-593e0bad964b; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [173.79.115.7] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1b5ae8f2-4a73-4baf-209a-08d8b33531aa x-ms-traffictypediagnostic: DM5PR0501MB3829: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5/kfny7TYryi95AyXF7ivDRiPo2LnlT9xu4irR+qoF0dS3hgHiVFd4CgJ0Ou4xEjGJw3gWsIgGB9gVgI82zeR7Mc1vTcg7ykekA7wbaElCZeOPVuzGTodrdaI6BpmIxkrLgohJyO2/0idm3icNtslRLWsLapiDpWRlyXhy/OcUr+gT03D6ypQ2+qJopuMpGYsEAS4MpUuRD4yFyFI95fuhKhBNNTX2ux2vJBviCEmqIwys6qm/f2zOCMmPgqx//5tUw3uOvEGTunLvcPoWNTOFRJ0xTYh8UqcyowDWf7mtQP0il6bFe1vcNF8QSH3NvW+2KucI6zht0QFlhWPEjtBMm8zjF1yiwfTu3WQv4gknldebuuePVNW8VBf6UFUk5MAPeWufHm3i+fI+bEbzZLRg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(346002)(136003)(376002)(396003)(6916009)(186003)(6506007)(71200400001)(8676002)(2906002)(26005)(86362001)(5660300002)(316002)(478600001)(55016002)(9686003)(33656002)(52536014)(66946007)(66556008)(64756008)(8936002)(76116006)(66446008)(66476007)(4744005)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?578MdU8hXtxA980C+x6wyDjVLfutC1UUvaQ2kECcFS6bgMq6BqaucU277JQY?= =?us-ascii?Q?+ODdG/LFdjAn6EzDKwKUZqBcobJla10E2slW1CCxh6aOFLz3ikJP/G0d0Iy8?= =?us-ascii?Q?gwgYka/m5z71/Q14iSt94yaQiERW0psqtozA1MagD2g9GhfdQe/YoVzTDbYy?= =?us-ascii?Q?vI0bU+7yGfvGLNqJ4EeIt/dl219LqW3M9nYChNcI0j5PdXXM6U/zZbbPsngH?= =?us-ascii?Q?cB9yth13P99npyYvXfyHNHK6dBzXEiwNCils8NqJh1lp1xfL9OyEuVr0+6TF?= =?us-ascii?Q?WbBIEgAgPel6Qx9aL0Jw6AsLnPkVSaN82+r1DdFAw8URHjFlVlnde0m/SsnS?= =?us-ascii?Q?c0q9tpZDr7vruTrVJPQp0UYl6PWHh4u9Ngz2i4oDzyMwUXsKaeVMtf4eoBa0?= =?us-ascii?Q?P4+/b2KJzfUSyqLu9voYn/Aoo+NrxPBAh+M2FgYnqdAiRC4LJf+kStTgJMpo?= =?us-ascii?Q?PeuzbBWBEVqnvZ6dXNuR8EnYKF+L7gov5nMtev1RZXlSImXAaOTeI53Ng/FU?= =?us-ascii?Q?JpdbIwL63cKQv+Z9ZZlZc3esUkg3v537WLHzlWzcTwnNtuwjcRdeieXAwAtG?= =?us-ascii?Q?qyzvTClrPBeXseZErS5UImoSXpdSzH6hRJyeSKpkAbgPD0iRosglC6/FD0dZ?= =?us-ascii?Q?FPS8CXV5CNbeAPoKFEShNbNYpd8/tF1n2HEIyoHfP8xs4t2cu7vf+OUHZ0HF?= =?us-ascii?Q?wbSC15bJhkflzCm37hSVxpF2OXudPqSfxYENdCAuJlTQBYt74OsspKB+SJdR?= =?us-ascii?Q?7o1hi68+YZqybVdqv4rCHYagcuT2f75iTryYOualqg5qlaxBrS5y+1ab7Xk5?= =?us-ascii?Q?JDpDDhLyu4521OlnY4XBrm60jH3RwDZJECv749w6002/i9sB7l105moC0h4p?= =?us-ascii?Q?mhMsSnm2X5viLUmES1VQWAlETvp4IVdzAMmmHHUE/du4au95eE/D3YCl4WSp?= =?us-ascii?Q?kMGBX77suTHHcSI90rNX5IE2MFwv2MRgjfmMkN7axaI=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB6348A18046C5DDC7CF2AED76AEAF0DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1b5ae8f2-4a73-4baf-209a-08d8b33531aa X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2021 17:53:51.9957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: W7R1eiYUlmN4soRBSlYK5F+j87fx2oX+JdgSi3ZlTTrzfxHASvihjoaoLlHuWfJ2pekHNX9znWjSrSfN2GoB+w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0501MB3829 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-07_07:2021-01-07, 2021-01-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 lowpriorityscore=0 adultscore=0 spamscore=0 malwarescore=0 clxscore=1011 suspectscore=0 phishscore=0 priorityscore=1501 mlxlogscore=610 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101070104 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 17:54:00 -0000 --_000_DM6PR05MB6348A18046C5DDC7CF2AED76AEAF0DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, According to RFC 4291, "routers must not forward any packets with Link-Loca= l source or destination addresses to other links". I interpret this statement to include packets that contain routing headers.= For example, it forbids an SRv6 packet whose final segment has a locator t= hat begins with FE80. Does everyone share this interpretation? If so, do RFC 4291 or RFC 8200 mak= e this sufficiently clear? = Ron Juniper Business Use Only --_000_DM6PR05MB6348A18046C5DDC7CF2AED76AEAF0DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

According to RFC 4291, “routers must not forwa= rd any packets with Link-Local source or destination addresses to other lin= ks”.

 

I interpret this statement to include packets that c= ontain routing headers. For example, it forbids an SRv6 packet whose final = segment has a locator that begins with FE80.

 

Does everyone share this interpretation? If so, do R= FC 4291 or RFC 8200 make this sufficiently clear?

 

        &nbs= p;            &= nbsp;           &nbs= p;             =             &nb= sp;            =             &nb= sp;            =   Ron


Juniper Business= Use Only

--_000_DM6PR05MB6348A18046C5DDC7CF2AED76AEAF0DM6PR05MB6348namp_-- From nobody Thu Jan 7 10:08:52 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837A33A0927 for ; Thu, 7 Jan 2021 10:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF3JtQ97zsSC for ; Thu, 7 Jan 2021 10:08:50 -0800 (PST) Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5ED83A0812 for <6man@ietf.org>; Thu, 7 Jan 2021 10:08:49 -0800 (PST) Received: by mail-vs1-f46.google.com with SMTP id j140so4109345vsd.4 for <6man@ietf.org>; Thu, 07 Jan 2021 10:08:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2jlTm4MwBrV04ZY8I2F0lADd9pxUgJMGCI1awHRQH+E=; b=Mf3TLykJC1c5ARCS/uqqOszV4wR9dg+oQpSF1DyMKj5O1DsotaQM/g/mAnZ0gD/Ktz D22s/iLXRUAEIlE+dr1J7olOrjWatEQruvh15r/g88DnPp9+6L4wno59gcLx77IyaaV3 nvpQYAwVEaCNo5Kv2SB6wSkKeDqkMoLtDCBJGPaxSYnv0bkVLynSwOYrzlSoT3SkDM9e ECov5CulO396Ly7fKtn/KjCI3SUhl6/tHq/YQbaQu0fDqf+l1tM8+6TOEjK3wD1TRjc6 RrTREEU710yI187yxHpfTvY8MmDl6Xv0QY0s9lonBdCwPnp5QO1rSfVU5UmhrTkeMsLt Jc1Q== X-Gm-Message-State: AOAM532frm4o6H4NSn+pobPVE7xot5XIpL9uE1BEILYOolWk+4PrZYyK kKD6BTzaAQ95wCDWxvGj1o+a0fTExgKfxwe+phuqezWK+Bki5g== X-Google-Smtp-Source: ABdhPJyDzTAOc7drJpbb2VyrrSL0zw8jj0tgvEaVR2Qqauzc4zssjj/qHJs8AnpKQINqWD24dCUBN4OqsT1gyhy3Sbs= X-Received: by 2002:a67:ff03:: with SMTP id v3mr8305845vsp.48.1610042928875; Thu, 07 Jan 2021 10:08:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 7 Jan 2021 10:08:38 -0800 Message-ID: Subject: Re: Forwarding Packets With Link Local Destination Addresses To: Ron Bonica Cc: "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 18:08:51 -0000 At Thu, 7 Jan 2021 17:53:51 +0000, Ron Bonica wrote: > According to RFC 4291, "routers must not forward any packets with Link-Local source or destination addresses to other links". > > I interpret this statement to include packets that contain routing headers. For example, it forbids an SRv6 packet whose final segment has a locator that begins with FE80. > > Does everyone share this interpretation? If so, do RFC 4291 or RFC 8200 make this sufficiently clear? I believe Section 9 of RFC4007 answers the question. In short, you're *basically* correct. I said *basically* because there can be an exception that makes it legitimate, but I suspect that usually doesn't apply in practice. -- jinmei From nobody Thu Jan 7 10:24:14 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB483A0983 for ; Thu, 7 Jan 2021 10:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=JGw9zWbN; dkim=pass (1024-bit key) header.d=juniper.net header.b=JfkiGIJ1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3BhBY0sT8p6 for ; Thu, 7 Jan 2021 10:24:12 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6973A0981 for <6man@ietf.org>; Thu, 7 Jan 2021 10:24:12 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 107I9TJT006702; Thu, 7 Jan 2021 10:24:12 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=J46ZSQ3+G+nsRux8h3OztXlxj5LDzInv9S8hE1BMhWQ=; b=JGw9zWbN1Pfl3N97Tgu/Q5RCMOy18hS2LNXxJX/fDAalbTcP/EZPaLFmyXXetCjTt3jT Uq9hS9yYHYlrFQ86RB3qMcdG8/9HS+aleVXtDUxkubCNYkgCqIf+MszwjMxBzO5mV0DD LlQ5/y3EFX+vJEWtEALKu6s/7bvStd2wdrVHcLoxsEn9UKXJlf36AOGds/8966u0aRf9 N2+s81Hjfo/urcSm9rLzJn39VpA+oLQmb/XCc7QfgYkaFyvYrL0+sgDrf224tWVwmRbz F9LrxLZ0j6LFOc4PYfPYa5Y4cP9ug/zXBrd576fO0ovxbPGR4K/gGJfFZ7TT3tK4icSs HA== Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2174.outbound.protection.outlook.com [104.47.58.174]) by mx0a-00273201.pphosted.com with ESMTP id 35wptb1f72-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Jan 2021 10:24:11 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UkAD7rwqTXo6xsv03xD1/40uHzshfWz/YtknILb2enk97tu+8Fu9M8vfrNalFuri5uokNIw5bfZB+5tAREApQYfAgtvI2FExIWMhCXcQSyinvJkDamr2UzOGujhFvy13gZLTiut1/V9WsZDhdWgjGYpZ1OYIKPYXGEP+CRm2oVEOCVlg4CtSzCBBii4L+SKM2aoL8/iNkgJQsp75qOQA1nwJNAzZekLAnhvhEtMrLExY5e+ANwmHBdx2ZQaw8uXjrOksnvFGi4MevxUFiTFvrpj5f3HVO1wfI/+3DhuwmnOjcEDy7ua1pEB76wN8509ATnWhoEcBnwmBRsoWiONTPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J46ZSQ3+G+nsRux8h3OztXlxj5LDzInv9S8hE1BMhWQ=; b=WUDVszct1IXuBMbH3M+sS3D2OJKCOsFbj5W4/RpTnMn/4Zu02hfrii12VXk0FfGxk4ye/LYSMtwl2yne8FXdswm1F6ntz5cRNvTzKbOm1hKRxcTkAkG9Lhdku8omQMoIwATqcKCXaqa1vfu0pAkte/lu68OtW+djfUlqKXd4G+HuWmbALLiaI211i33ufcacqFA/D97SBxuKYeM3QIIQq3i/3syXRfp0hwclEpDlQIbOUSoRHMFw+BCjCmaQR6kXX3QQppU+P0Wgxpv3FLzzJARfjzzltnuHxmrNMpFB+AWeelzP5Zg6W3hjF3dkWHdWhGShPz6Er9MGtSEjySeLrQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J46ZSQ3+G+nsRux8h3OztXlxj5LDzInv9S8hE1BMhWQ=; b=JfkiGIJ1Y/mQ58WvpGTnMNFV0YIw9QE/Bcbe0NkOevJF5wTjuF4ecuLym76gJLR3yxrGEap67cNQ2KVpT7HNkBly1gEI7NxVgKe8hItKfWFuJoWMDxahjIn30HsWGxYF7CL0qH8OW/Xn7YCGokPzb1rOQLVYk+vjYyyPM/g4yDg= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB5019.namprd05.prod.outlook.com (2603:10b6:5:34::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.4; Thu, 7 Jan 2021 18:24:10 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::a435:88ed:7e2a:4fe6]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::a435:88ed:7e2a:4fe6%5]) with mapi id 15.20.3763.004; Thu, 7 Jan 2021 18:24:10 +0000 From: Ron Bonica To: =?utf-8?B?56We5piO6YGU5ZOJ?= CC: "6man@ietf.org" <6man@ietf.org> Subject: RE: Forwarding Packets With Link Local Destination Addresses Thread-Topic: Forwarding Packets With Link Local Destination Addresses Thread-Index: AdblHDzlHUUyT5iKRq6/0g3froJALQAA+JYAAAB/6IA= Date: Thu, 7 Jan 2021 18:24:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-01-07T18:24:08Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=9e4c3bc5-2b06-4ade-89b6-60ec283886c8; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: wide.ad.jp; dkim=none (message not signed) header.d=none;wide.ad.jp; dmarc=none action=none header.from=juniper.net; x-originating-ip: [173.79.115.7] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: cfb14d98-a00c-499e-25ba-08d8b3396d5a x-ms-traffictypediagnostic: DM6PR05MB5019: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZJB86KxjqKYDW93Fvq5X4N0XyCIoFtMOmg194AErvBYSyVmseGbJUUWW8y8nNMHy4gIjnJvtp/plJK3Cq81Vo/Kd/kQb9tAi+JKp01ZdVefABF9orVR/X3LEIeDp0OY+HyUPjLBxomfkRkHAJPCR5SVw8/YwOBCmvoVyv+xY59mCoFkUP1hX9YnJCzOLJ0vAIu7U+VF5rblgtmNx9zUZQZv3d94LdU9/C272Ai+iCWSyTdEmB9wAf31NPQBGfHG1yd7R6d1cmepC8za6WF3qHwsDFjf9/I0Ui4ZmHXmG4Ai8+AlZW/wqFihumT7KLQyXEqiL6QwKgEiwOU49LsmDSVKWprtkyzvc33d7WIbsbv6Owk+2OhR44Ltiv3rp/k06WLpASJsJmAbD7KNqnq9z9Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(366004)(346002)(136003)(396003)(8676002)(71200400001)(64756008)(316002)(66556008)(76116006)(26005)(9686003)(66946007)(52536014)(2906002)(66446008)(186003)(66476007)(33656002)(53546011)(55016002)(6916009)(86362001)(83380400001)(6506007)(8936002)(478600001)(5660300002)(7696005)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?K2tGY2tBamN3SjdwZVhFYWxhenRqM2VKVytBdlFCWUR3c1l4TkE5Nk9KZjR2?= =?utf-8?B?WklldkpjMVhobDNSK2h0TllnWDYrdHphSWtCMnNBdTAzVjd4N0ZWRFAvaito?= =?utf-8?B?Umh1OWhjQmxlb3lQNzlwOHp3T2tocXhXM3o3eDBWNFNpTmliQ3IvVjVUYndE?= =?utf-8?B?OVY5Yjc3LzNjQkpTbm85b0xBanlNUzhYTit0RGRMTXdvcVlEcGhkYkFSRi9S?= =?utf-8?B?bStYeGRCd2pvRzNhZzVXRFhOemxsa0lkamRXS1NlSENDdUY4Si96WEJOZURy?= =?utf-8?B?MVpCNzRoSkxlaVNEWjk0RFh0NHlwZXFlVVdIRGpTOWZTVnlwK1JTQm10UTZS?= =?utf-8?B?aVVVVE5LQnZJMGhKVWJtdXdvU3dBb0VOaUF6UkJIa3NyUmFQNFVqQ1JYSHBP?= =?utf-8?B?M25ZUUZCVCtWdUpHeGsvR2VjMDBVSGpkaW4wOHFzMTlzTW5jSWFmWXpGZjRZ?= =?utf-8?B?aXd3aFlac2tia0FBNXBhYitvS1R5WFVvYzhVOFRnb1hjUThRQzVCK2Z5cFpW?= =?utf-8?B?K2NlK2dHeWVVTEtLOGhtZk05KzRkdEhiNE5NWmloR0NNRlJqQ25yVXFPdXZU?= =?utf-8?B?VGFNTWNmVzFtN2psdjIzdXNETEtIQjVSemZqV25obkNQdjJUME1ncnE5K2t0?= =?utf-8?B?OXNicFVVcU5laVRiQXA0VXc3MS9hT3ZkTnlXbURTV3FoMTIvRERsQ05oZkpy?= =?utf-8?B?b3UwMjZrL0lPUkk2dTMzSHo1V0lyRlR4M0VBWlFqMEorWWpteEJFZEVCemEz?= =?utf-8?B?U3Qwc2pTN1FUa1pjNXFwNWZYZVlLWUtrMjV1L2MxeFY1Rm1Mbkxqa0l2VjBp?= =?utf-8?B?SjhYd1cvNmVHendkVE9vRkliMUp1RExCNkFaOHQ2bkNvNjQ5UXgzSGtPVndB?= =?utf-8?B?ZW9KTDNTdjlnNHJRY2RNTS9WdVphTEp1bUQ3R1JPQUY5L21vZU04dHdjUkYy?= =?utf-8?B?bjcvRE1ORkt0TmpUZVYyZkN0bTgxZ0cxQTA1bS9FUE5iS0wrNXp4SFA5Y2c3?= =?utf-8?B?aWg0aEdNcUppd1d5QlNOeFE5ZEt0K0ROVE1JZitXVGh4UXFSMzRlNzcrWUx5?= =?utf-8?B?T3JwenBSeHpqL0FpUHNsMFZNTTNyVDYrd0ZENHN6MU9EdWxzMWRsM1FXa3pG?= =?utf-8?B?RHNHMU9NMjU3YU5FSlBlTVFROGZFamQzOWV1SVIrOTVsS1hzWTMxcG92bE5p?= =?utf-8?B?d2p1RjR1WHVGbTc2Tk9lT0dSUGFJMUhYZEhYY3k0TitVeW5GTEI5c3YxODVY?= =?utf-8?B?bVdFVWhHWkIxbHIxa3lMYjk4QXB3WGtoTTVNQTBTTklLNE1GY0R3SzhrdGZo?= =?utf-8?Q?XI47RA9C8+f2U=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cfb14d98-a00c-499e-25ba-08d8b3396d5a X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2021 18:24:10.1397 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ecdojJ6qmSYtC62+TodarvqVQGYpWj+CBFW2gMqpP+nwHz0KdESKG2EFncpqCBPgaODKNzw6YuqYuWwWmZ8q/A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5019 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-07_07:2021-01-07, 2021-01-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 adultscore=0 spamscore=0 lowpriorityscore=0 bulkscore=0 clxscore=1011 mlxlogscore=999 priorityscore=1501 suspectscore=0 mlxscore=0 impostorscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101070107 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 18:24:14 -0000 SmlubWVpLA0KDQpUaGFua3MhIEkgdGhpbmsgdGhhdCB0aGUgZm9sbG93aW5nIHRleHQgZnJvbSBS RkMgNDAwNyBjb3ZlcnMgdGhlIGlzc3VlOg0KDQoiICAgQSBub2RlIHRoYXQgcmVjZWl2ZXMgYSBw YWNrZXQgYWRkcmVzc2VkIHRvIGl0c2VsZiBhbmQgY29udGFpbmluZyBhDQogICBSb3V0aW5nIEhl YWRlciB3aXRoIG1vcmUgdGhhbiB6ZXJvIFNlZ21lbnRzIExlZnQgKFNlY3Rpb24gNC40IG9mIFsz XSkNCiAgIGZpcnN0IGNoZWNrcyB0aGUgc2NvcGUgb2YgdGhlIG5leHQgYWRkcmVzcyBpbiB0aGUg Um91dGluZyBIZWFkZXIuICBJZg0KICAgdGhlIHNjb3BlIG9mIHRoZSBuZXh0IGFkZHJlc3MgaXMg c21hbGxlciB0aGFuIHRoZSBzY29wZSBvZiB0aGUNCiAgIG9yaWdpbmFsIGRlc3RpbmF0aW9uIGFk ZHJlc3MsIHRoZSBub2RlIE1VU1QgZGlzY2FyZCB0aGUgcGFja2V0LiAiDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBS b24NCg0KDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IOelnuaYjumBlOWTiSA8amlubWVpQHdpZGUuYWQuanA+IA0KU2VudDog VGh1cnNkYXksIEphbnVhcnkgNywgMjAyMSAxOjA5IFBNDQpUbzogUm9uIEJvbmljYSA8cmJvbmlj YUBqdW5pcGVyLm5ldD4NCkNjOiA2bWFuQGlldGYub3JnDQpTdWJqZWN0OiBSZTogRm9yd2FyZGlu ZyBQYWNrZXRzIFdpdGggTGluayBMb2NhbCBEZXN0aW5hdGlvbiBBZGRyZXNzZXMNCg0KW0V4dGVy bmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KDQoNCkF0IFRodSwgNyBKYW4gMjAy MSAxNzo1Mzo1MSArMDAwMCwNClJvbiBCb25pY2EgPHJib25pY2E9NDBqdW5pcGVyLm5ldEBkbWFy Yy5pZXRmLm9yZz4gd3JvdGU6DQoNCj4gQWNjb3JkaW5nIHRvIFJGQyA0MjkxLCAicm91dGVycyBt dXN0IG5vdCBmb3J3YXJkIGFueSBwYWNrZXRzIHdpdGggTGluay1Mb2NhbCBzb3VyY2Ugb3IgZGVz dGluYXRpb24gYWRkcmVzc2VzIHRvIG90aGVyIGxpbmtzIi4NCj4NCj4gSSBpbnRlcnByZXQgdGhp cyBzdGF0ZW1lbnQgdG8gaW5jbHVkZSBwYWNrZXRzIHRoYXQgY29udGFpbiByb3V0aW5nIGhlYWRl cnMuIEZvciBleGFtcGxlLCBpdCBmb3JiaWRzIGFuIFNSdjYgcGFja2V0IHdob3NlIGZpbmFsIHNl Z21lbnQgaGFzIGEgbG9jYXRvciB0aGF0IGJlZ2lucyB3aXRoIEZFODAuDQo+DQo+IERvZXMgZXZl cnlvbmUgc2hhcmUgdGhpcyBpbnRlcnByZXRhdGlvbj8gSWYgc28sIGRvIFJGQyA0MjkxIG9yIFJG QyA4MjAwIG1ha2UgdGhpcyBzdWZmaWNpZW50bHkgY2xlYXI/DQoNCkkgYmVsaWV2ZSBTZWN0aW9u IDkgb2YgUkZDNDAwNyBhbnN3ZXJzIHRoZSBxdWVzdGlvbi4gIEluIHNob3J0LCB5b3UncmUNCipi YXNpY2FsbHkqIGNvcnJlY3QuDQoNCkkgc2FpZCAqYmFzaWNhbGx5KiBiZWNhdXNlIHRoZXJlIGNh biBiZSBhbiBleGNlcHRpb24gdGhhdCBtYWtlcyBpdCBsZWdpdGltYXRlLCBidXQgSSBzdXNwZWN0 IHRoYXQgdXN1YWxseSBkb2Vzbid0IGFwcGx5IGluIHByYWN0aWNlLg0KDQotLQ0KamlubWVpDQo= From nobody Thu Jan 7 10:29:19 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4D93A09E0 for ; Thu, 7 Jan 2021 10:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODZr1JjPC99Z for ; Thu, 7 Jan 2021 10:29:16 -0800 (PST) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641363A09E9 for <6man@ietf.org>; Thu, 7 Jan 2021 10:29:16 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id f14so1938838pju.4 for <6man@ietf.org>; Thu, 07 Jan 2021 10:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=O0scznKxYJn8CrhzXOwPVKaUfMnd3tM1kFcAh0MeYdU=; b=K93KhJZDl607jfAYo/TK2ETBXH5N1OHwzEQNeZ0wb1rWilYgbhox2aLbN4G8ezgJHh Gh+KdDWMpq9HMopocUxFu76Ua0QXg6S2kE2XaBApWy+4yd7pdFZAHiJcyj3Cwk1ZBdiR EOLrUQ9W/5rFFTKVgOzp0fVRA6N+lJUg767xAXHXRAhwBVMTZ9Ee4vvpMFzNYTuL7u/p ynfhGNf1T3zoumyC03t/VkjosIF30QSxAxLe2t/Ig2+hMkitHoiM7H1w/JVjYzV9OZS1 YyqRq0Uu30jk9doAj4v4quQi2Jau2bzU+u9u6o4sWLHGDadDoDhLm1Jdp6om3mV286aH n7og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=O0scznKxYJn8CrhzXOwPVKaUfMnd3tM1kFcAh0MeYdU=; b=r9BXh9zm2VRWK4x/x790B+fh1R5loEBID9LhNiognAIhC/4epMXDcPVpGEEztsjSHo KXJU7cdoc2TMOPGApYIsatEzUI4EYutguX+VIatZF9UO78G06VnNX66L62fX3997g/1+ 9KJaFapV+FVkHH/IVB/OeJpGr7srw7W5gz0f7CEudAlvkJVB+cIWbIbUZQYnNpqm4uk5 Obb3yteyDRjYqTjIbSSZHhA3xpdh6bGhb5rhK7vCgEtDnqeAe39EtQjdsD9tpPKcie0g hrYhwWqKu73yS0sLIfMa1B63ru4wL9RjLv0sIU0mQ3XIJ8Xw7wH1hIVedR93Gu40IU7E Olyg== X-Gm-Message-State: AOAM532FRfG+RC+rQOgJ01LbeBACifzSfNkmIpk3daqbS1vFLYlCWVH4 XlCGzHWbSrvuojuHHdXajEE= X-Google-Smtp-Source: ABdhPJwTSu9j8UnIGs2tNVvxAZDfjKgcZq7Z5FV7zoS+yWukz0NVx+NCcDHXwsHKZFsBymXFAafwiA== X-Received: by 2002:a17:902:9f97:b029:da:357b:22b0 with SMTP id g23-20020a1709029f97b02900da357b22b0mr3244161plq.73.1610044155638; Thu, 07 Jan 2021 10:29:15 -0800 (PST) Received: from ?IPv6:2600:8802:5800:567::1022? ([2600:8802:5800:567::1022]) by smtp.gmail.com with ESMTPSA id m3sm6143200pfa.134.2021.01.07.10.29.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jan 2021 10:29:15 -0800 (PST) From: Fred Baker X-Google-Original-From: Fred Baker Content-Type: multipart/alternative; boundary=Apple-Mail-CAB5E939-10BB-4D08-89B9-64CF2BBA2F67 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: Forwarding Packets With Link Local Destination Addresses Date: Thu, 7 Jan 2021 10:29:13 -0800 Message-Id: <5C979A62-BD53-4256-AF1A-4A925344AC76@gmail.com> References: Cc: 6man@ietf.org In-Reply-To: To: Ron Bonica X-Mailer: iPad Mail (18D5030e) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 18:29:18 -0000 --Apple-Mail-CAB5E939-10BB-4D08-89B9-64CF2BBA2F67 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would think the RFC is pretty clear on the topic. Sent from my iPad > On Jan 7, 2021, at 9:54 AM, Ron Bonica wrote: >=20 > =EF=BB=BF > Folks, > =20 > According to RFC 4291, =E2=80=9Crouters must not forward any packets with L= ink-Local source or destination addresses to other links=E2=80=9D. > =20 > I interpret this statement to include packets that contain routing headers= . For example, it forbids an SRv6 packet whose final segment has a locator t= hat begins with FE80. > =20 > Does everyone share this interpretation? If so, do RFC 4291 or RFC 8200 ma= ke this sufficiently clear? > =20 > = Ron >=20 > Juniper Business Use Only > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-CAB5E939-10BB-4D08-89B9-64CF2BBA2F67 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would think the RFC is pretty clear on th= e topic.

Sent from my iPad
On Jan 7, 2021, at 9:54 AM, Ron Bonica <rbonic= a=3D40juniper.net@dmarc.ietf.org> wrote:

=EF=BB=BF =

Folks,

 

According to RFC 4291, =E2=80=9Crouters must not forw= ard any packets with Link-Local source or destination addresses to other lin= ks=E2=80=9D.

 

I interpret this statement to include packets that co= ntain routing headers. For example, it forbids an SRv6 packet whose final se= gment has a locator that begins with FE80.

 

Does everyone share this interpretation? If so, do RFC= 4291 or RFC 8200 make this sufficiently clear?

 

         = ;            &nb= sp;            &= nbsp;            &nbs= p;            &n= bsp;            =             &nbs= p;            &n= bsp;Ron


Juniper Business U= se Only

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@iet= f.org
Administrative Requests: https://www.ietf.org/mailman/= listinfo/ipv6
----------------------------------------------= ----------------------
= --Apple-Mail-CAB5E939-10BB-4D08-89B9-64CF2BBA2F67-- From nobody Thu Jan 7 10:45:48 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFF63A0A3B for ; Thu, 7 Jan 2021 10:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMLCGm2C5DCw for ; Thu, 7 Jan 2021 10:45:45 -0800 (PST) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF4B53A0A1E for <6man@ietf.org>; Thu, 7 Jan 2021 10:45:45 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id x12so3998122plr.10 for <6man@ietf.org>; Thu, 07 Jan 2021 10:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=1IxXAo9YRB2jAcH+WtRodxrnDnEe/7G04CuDLnU6MSc=; b=iIs6IwZR/G3eC2wZ0gDs3jB6T5rd5rUN2Q+LRL84yr6VG+k1MOzJLPE+6ccVFxvq5k 7zWDGv4JBcMx2hzm/591gdlfGSgFXYl79T1O14w60Ioj44p8DqDIrVdjRyCaBx8cEJF2 poDnXNABaWXBoUYq9rScSPTQxXmPlQPA1LPMUrtrH2Jv+Qp2PesIh9Wj2BGk/rLNTc+x skgVTA+UOXKgeDy7W4mKUwuKECHgCk3tJxYO+++MB2BUeI0b3dC8IuWN5S+9icI9sGOQ KCIfonkIkMbtsrbRNGM/dCNbgdsQn6N8k/3BtzgZqILBxewG6W1vtVPGaazDCM+9+Us4 qcvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=1IxXAo9YRB2jAcH+WtRodxrnDnEe/7G04CuDLnU6MSc=; b=Rq6rvaDQPK5H+BzmdwU2G+RWv0UHLYx/d3Y3jcu6hnVHa07RBzXEauykm/KECcC6AM abjBnLrzlSEQxWgddZPtoJauWiZ+ox6mqNu5mSZwz48j48V3LZ3KtjjN+5ZLzxfQ5Kzn 6IXhsklb6Wh/i6GdKRxTDhFPfhvkacjOnCLszu59VAoXHy97BVBboQR2Sv9mbx+OEu8n Z9HlpKaHnYPgj4pCzPjGJc3I6HRtSigT0bBFgCexpBXCtUD4zuCHNFGOy36ebgFT8LqJ +NlXw2W6CsUcu27A0qKRizIn97ldXA2Pf7RnHUSo8JaKe9IOjuQeaMK3qj0b6fLcjRHQ 5pyw== X-Gm-Message-State: AOAM533uEFqUXwhCMiZGGf+6KP46nMg3rlcTYX7gL3Xa7e7rGRA5R0jN TuWEwYfdendRfnwLHSkrgPg= X-Google-Smtp-Source: ABdhPJw2CBUGkGG9Xia5Y3Tcg254/gHzdgW3Ij4tC4D896Swdy7bUAoLGShegqSCqrDT8kGmGPj55w== X-Received: by 2002:a17:902:6807:b029:db:f60f:52f7 with SMTP id h7-20020a1709026807b02900dbf60f52f7mr234193plk.54.1610045145303; Thu, 07 Jan 2021 10:45:45 -0800 (PST) Received: from ?IPv6:2600:8802:5800:567::1022? ([2600:8802:5800:567::1022]) by smtp.gmail.com with ESMTPSA id g202sm6364535pfb.196.2021.01.07.10.45.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jan 2021 10:45:44 -0800 (PST) From: Fred Baker X-Google-Original-From: Fred Baker Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: Forwarding Packets With Link Local Destination Addresses Date: Thu, 7 Jan 2021 10:45:43 -0800 Message-Id: <92C51C9C-3C7F-4FE5-9626-1EBF7D55C17C@gmail.com> References: Cc: 6man@ietf.org In-Reply-To: To: Ron Bonica X-Mailer: iPad Mail (18D5030e) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 18:45:47 -0000 On Jan 7, 2021, at 9:54 AM, Ron Bonica wrote: > According to RFC 4291, =E2=80=9Crouters must not forward any packets with L= ink-Local source or destination addresses to other links=E2=80=9D. This, of course, imposes a requirement that no routers I=E2=80=99m aware of c= arry out absent explicit configuration, which is to make a forwarding decisi= on (in this case a filter) based on the source address. Reverse forwarding l= ookups *might* accomplish this by associating link local addresses with the i= nterface the packet it was received on, but that would only happen if revers= e address lookups (normally associated with BCP 38) were enabled.=20 So one could argue that RFC 4291 goes beyond its remit in this regard. > =20 From nobody Thu Jan 7 10:59:27 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C83F3A0A73 for ; Thu, 7 Jan 2021 10:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.408 X-Spam-Level: X-Spam-Status: No, score=0.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ0gFz-B9Uni for ; Thu, 7 Jan 2021 10:59:24 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C94003A0A4D for ; Thu, 7 Jan 2021 10:59:24 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 107IxNKF048714 for ; Thu, 7 Jan 2021 19:59:23 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 36F3E20CEEE for ; Thu, 7 Jan 2021 19:59:23 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2D28720CE89 for ; Thu, 7 Jan 2021 19:59:23 +0100 (CET) Received: from [10.14.1.83] ([10.14.1.83]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 107IxM4S025778 for ; Thu, 7 Jan 2021 19:59:22 +0100 Subject: Re: Forwarding Packets With Link Local Destination Addresses To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: Date: Thu, 7 Jan 2021 19:59:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 18:59:26 -0000 Le 07/01/2021 18:53, Ron Bonica a crit: > Folks, > > According to RFC 4291, routers must not forward any packets with > Link-Local source or destination addresses to other links. > > I interpret this statement to include packets that contain routing > headers. For example, it forbids an SRv6 packet whose final segment has > a locator that begins with FE80. It's easy to say that 'it begins with fe80' but that is hard to implement unless the programmer knows precisely the prefix length. Some might implement it with a /64 plen, others with a /10 plen, depending on which RFC and IANA table one looks at more trustfully. If one takes literally 'begins with fe80' then it would be a /16, but probably that is less likely to be considered seriously. It might be a problem more of basic link-local address format, and probably also of a SRv6 interest. Alex > > Does everyone share this interpretation? If so, do RFC 4291 or RFC 8200 > make this sufficiently clear? > > > Ron > > > Juniper Business Use Only > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Jan 7 11:02:26 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9538F3A0A69 for ; Thu, 7 Jan 2021 11:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ5M0IYRnV_T for ; Thu, 7 Jan 2021 11:02:22 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55733A0AB4 for <6man@ietf.org>; Thu, 7 Jan 2021 11:02:22 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 304EF548056; Thu, 7 Jan 2021 20:02:17 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 276D4440163; Thu, 7 Jan 2021 20:02:17 +0100 (CET) Date: Thu, 7 Jan 2021 20:02:17 +0100 From: Toerless Eckert To: Fred Baker Cc: Ron Bonica , 6man@ietf.org Subject: Re: Forwarding Packets With Link Local Destination Addresses Message-ID: <20210107190217.GE16251@faui48f.informatik.uni-erlangen.de> References: <92C51C9C-3C7F-4FE5-9626-1EBF7D55C17C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92C51C9C-3C7F-4FE5-9626-1EBF7D55C17C@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 19:02:25 -0000 On Thu, Jan 07, 2021 at 10:45:43AM -0800, Fred Baker wrote: > On Jan 7, 2021, at 9:54 AM, Ron Bonica wrote: > > According to RFC 4291, ???routers must not forward any packets with Link-Local source or destination addresses to other links???. > > This, of course, imposes a requirement that no routers I???m aware of carry out absent explicit configuration, which is to make a forwarding decision (in this case a filter) based on the source address. The words are english. The sentence structure looks more german, but i still can't parse it. I also thought we had (source/mask,dest/mask) forwarding for IPv6 multi-homing somehwere in Homenet at some point in time. Without explicit config, just to enable to use source address to steer packets towards the desired ISP exit point. > Reverse forwarding lookups *might* accomplish this by associating link local addresses with the interface the packet it was received on, but that would only happen if reverse address lookups (normally associated with BCP 38) were enabled. > > So one could argue that RFC 4291 goes beyond its remit in this regard. "beyond its remit" for mentioning source address ? Cheers toerless From nobody Thu Jan 7 11:05:52 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017813A0ADF for ; Thu, 7 Jan 2021 11:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4at20vVi-Rz for ; Thu, 7 Jan 2021 11:05:49 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEE13A0AA7 for ; Thu, 7 Jan 2021 11:05:49 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 107J5l5s000995 for ; Thu, 7 Jan 2021 20:05:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A353A20CF32 for ; Thu, 7 Jan 2021 20:05:47 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 98CB620CE7C for ; Thu, 7 Jan 2021 20:05:47 +0100 (CET) Received: from [10.14.1.83] ([10.14.1.83]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 107J5lAg027324 for ; Thu, 7 Jan 2021 20:05:47 +0100 Subject: Re: Forwarding Packets With Link Local Destination Addresses To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: <5cf537dc-b7e8-7de9-f461-26a25b5d31fe@gmail.com> Date: Thu, 7 Jan 2021 20:05:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 19:05:51 -0000 Le 07/01/2021 à 19:24, Ron Bonica a écrit : > Jinmei, > > Thanks! I think that the following text from RFC 4007 covers the > issue: > > " A node that receives a packet addressed to itself and containing > a Routing Header with more than zero Segments Left (Section 4.4 of > [3]) first checks the scope of the next address in the Routing > Header. If the scope of the next address is smaller than the scope > of the original destination address, the node MUST discard the > packet. " Are scopes bigger one than another? In multicast that may be true, but in unicast it's hard to say a scope might be smaller or bigger than another scope. In unicast, there might be only two scopes: LL and global. It might be that there is no inclusion from one into another, or it might be that a size comparison might not be possible. Intuitively, one might consider that LL scope to be smaller than Global scope, because of the reach. But knowing that each iface must have an LL address whereas not all ifaces have a Global address it might be that the number of assigned LL addresses is larger than the number of assigned Global addresses at one point in time. In that sense, it might be that the set of LL addresses is much larger (bigger) than the set of Global addresses. That is one reason that is hard to implement the paragraph cited in the beginning of this message. There is no number in an address that says 'scope', and that could be used to compare two addresses, and to decide that one address is of a larger scope than another. Alex > > Ron > > > > Juniper Business Use Only > > -----Original Message----- From: 神明達哉 Sent: > Thursday, January 7, 2021 1:09 PM To: Ron Bonica > Cc: 6man@ietf.org Subject: Re: Forwarding > Packets With Link Local Destination Addresses > > [External Email. Be cautious of content] > > > At Thu, 7 Jan 2021 17:53:51 +0000, Ron Bonica > wrote: > >> According to RFC 4291, "routers must not forward any packets with >> Link-Local source or destination addresses to other links". >> >> I interpret this statement to include packets that contain routing >> headers. For example, it forbids an SRv6 packet whose final segment >> has a locator that begins with FE80. >> >> Does everyone share this interpretation? If so, do RFC 4291 or RFC >> 8200 make this sufficiently clear? > > I believe Section 9 of RFC4007 answers the question. In short, > you're *basically* correct. > > I said *basically* because there can be an exception that makes it > legitimate, but I suspect that usually doesn't apply in practice. > > -- jinmei > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Thu Jan 7 11:38:21 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0D23A0BF8; Thu, 7 Jan 2021 11:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVqK8kUeci20; Thu, 7 Jan 2021 11:38:17 -0800 (PST) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8223A0BEB; Thu, 7 Jan 2021 11:38:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 107JcBLi057436; Thu, 7 Jan 2021 11:38:12 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1610048292; bh=DhKPi46UG75O1o0z72eQJVOWVovpntI2h/kBwmAJb9U=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ir8zsbxCuf72GnOf7XCo94F2kR9oC9mW06MN1ybmQtfYKQUEy6gwqxN4DYp0/ikZu e9i117mDYSRmeCH2EN4zzr4BgqWX6X0rIACrPpnzPW6/VVN3vkqH/lifXlcO1hGZs/ y8cIsrmskSlqnpCzdKX0nKMftjuXD8FoikgFnm/OZfctc3ejGmS0pHBN+O7YvOYrXY Da6Z05IuPLlrZQvBpUb323mivNUgShmQn7LqPW/PNNEmaIJTbRN1DVePbbwJNnlvQf cfPecQG4XnyRrzgOtlPaMmCxkk5ZWwzYZw//WW50NMz6WpRBwfXMSKdeSZ+45bK2TW 5tVENo2h4raBw== Received: from XCH16-01-10.nos.boeing.com (xch16-01-10.nos.boeing.com [144.115.66.5]) by ewa-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 107JbvPQ057227 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 7 Jan 2021 11:37:58 -0800 Received: from XCH16-01-11.nos.boeing.com (144.115.66.39) by XCH16-01-10.nos.boeing.com (144.115.66.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Thu, 7 Jan 2021 11:37:56 -0800 Received: from XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b]) by XCH16-01-11.nos.boeing.com ([fe80::c57c:39bc:4c0a:384b%4]) with mapi id 15.01.2044.004; Thu, 7 Jan 2021 11:37:56 -0800 From: "Manfredi (US), Albert E" To: David Farmer CC: IPv6 Operations , 6MAN <6man@ietf.org> Subject: RE: [EXTERNAL] Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Thread-Topic: [EXTERNAL] Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Thread-Index: AQHW5OW4RQf5NbyGPUqPbrUftFxb3qocjLcA Date: Thu, 7 Jan 2021 19:37:56 +0000 Message-ID: <80c00c12156342db8933e4ee564a6c59@boeing.com> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.115.204.6] x-tm-snts-smtp: D13308FB146C7B3BADBB05843D1758714BA0B6FF69747169BDE9AB32818E5C9B2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 19:38:19 -0000 RnJvbTogaXB2NiA8aXB2Ni1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRGF2aWQgRmFy bWVyDQoNCj4gTGluay1Mb2NhbCA+IFNpdGUtTG9jYWwgPj4+Pj4+IFBzZXVkby1HbG9iYWwgPiBH bG9iYWwNCg0KU29tZXRoaW5nIGxpa2UgdGhhdCwgc3VyZSwgYWx0aG91Z2ggSSB3b3VsZCBub3Qg dXNlIHRoYXQgdGVybS4NCg0KPiBXaGF0IGRvIG90aGVyIHBlb3BsZcKgdGhpbms/DQoNClJGQyAy MzY1IGRlZmluZXMgc29tZXRoaW5nIGV4YWN0bHkgYWxvbmcgdGhlc2Ugc2FtZSBsaW5lcywgZm9y IElQdjQgbXVsdGljYXN0IGFkZHJlc3NlcyB0aGF0IGFyZSBtZWFudCB0byBiZSB1c2VkIG9ubHkg aW5zaWRlIGEgcGFydGljdWxhciBkb21haW4uIFNvLCB0aGVyZSBpcyBhdCBsZWFzdCB0aGlzIG9u ZSBwcmVjZWRlbnQsIGFuZCBJIGRvbuKAmXQga25vdyB0aGF0IGl0IGNhdXNlcyBhbnkgY29uZnVz aW9uLiBSRkMgMjM2NSBpcyB0aXRsZWQgIkFkbWluaXN0cmF0aXZlbHkgU2NvcGVkIElQIE11bHRp Y2FzdC4iDQoNCkluIG15IHZpZXcsIHRoZXJlJ3Mgbm8gdXJnZW50IG5lZWQgdG8gbWFrZSBhbnkg Y2hhbmdlcy4gQnV0IGlmIHBlb3BsZSBmZWVsIHRoaXMgaXMganVzdCB0b28gY29uZnVzaW5nLCB0 aGVuIHdlIGNhbiBkZWZpbmUgdGhpcyAiYWRtaW4gc2NvcGUiIGZvciBJUHY2IFVMQXMuDQoNCklu IHByYWN0aWNlLCBSRkMgMTkxOCBhZGRyZXNzZXMgYXJlIHRoZSBzYW1lIHRoaW5nLiBBZG1pbmlz dHJhdGl2ZWx5IHNjb3BlZCwgYW5kIHRoZXkgZG8gbm90IG5lZWQgdG8gYmUgbGltaXRlZCB0byBq dXN0IG9uZSBsaW5rLg0KDQpCZXJ0DQoNCg== From nobody Thu Jan 7 12:02:40 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0403A1053 for ; Thu, 7 Jan 2021 12:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpmIDB15xqEo for ; Thu, 7 Jan 2021 12:02:32 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5443A0D75 for <6man@ietf.org>; Thu, 7 Jan 2021 12:01:47 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id q7so3801500pgm.5 for <6man@ietf.org>; Thu, 07 Jan 2021 12:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=qpS5jxAaErfXVP0BI9RWEe11U6JMm4hIqKg2nCQpm20=; b=IQFuA5No2M/iAUKNw/i26Ln2ZfploDmYVhd9MQtOZ4rouj1P5UWFpAbrNPtOQuMmYd ED83JQHdi4ebRhoM0UuxlPOEn6OMMJDAs+RxySfSxs5x9YjLJRKbJIcBnkzbtKv6Tpjp qqXiYzw7vo+bgzac/dwVjJTYgEdhkMYYToTz5wuPVIaDTMgYUnAnBFg2SHIsWXxJvN7e DDaoQ7jfQA9iK+qFKi0pB5V4lLZ6fGkrli7h47MQvFkHuvdisC0ojPYPepUnqqOoAZws V9QR5uts0p34f84SaYi7TsyoHwbbJKYF41mIy2RTUX0m3qyAJmf4MG7oQvKXbrBolHzY NYDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qpS5jxAaErfXVP0BI9RWEe11U6JMm4hIqKg2nCQpm20=; b=D1HI+2py/XL+h2HKJs20FOGlqE6jJ5yUIaW5EUr8DBpEbtCVbxphShtZcyTHWfByj3 f28gLXrDh+Bbt5T1gpULiXvNLRtYZ2VGFqnOkpZTlYEqKRX/JVP8NTSAmyh/6gvwiUIh BMEezRxdWMalQbujXxwfSPkoEKNqGzsnerW5pIK7ayvy7U4NvtDz0F0hpZmlY5Ma2D2c 1npsdzcE5MtgPiHqgInCMYv4fRTmmvekwdjkzZMtm6hEaPv9j+MVVQkRhrk5FMxge6Gb fHPMlPziE9n8K5xXLJAndT8Z885tvn6VaNX5ExFxa9lbVyfkTPAKOBmxlIIICPd8R2ff fHzg== X-Gm-Message-State: AOAM531e6ApxPlxn3JTrqvqT7LsKp4LVtTchCjVf8amqJp7nYyVvEnyQ nEr9nx2Lzo/j5WmODyc+XsnYziuv2I1ddQ== X-Google-Smtp-Source: ABdhPJwmOPUxpRqhghCw//W8JY6K9dcWhXdraWXBrgPYjOvY50w2KbaRUYTnezDXVJoWRqPSqJ9dCg== X-Received: by 2002:a63:5304:: with SMTP id h4mr3408469pgb.199.1610049706878; Thu, 07 Jan 2021 12:01:46 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id v6sm6503473pfi.31.2021.01.07.12.01.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 12:01:46 -0800 (PST) Subject: Re: Forwarding Packets With Link Local Destination Addresses To: Ron Bonica , "6man@ietf.org" <6man@ietf.org> References: From: Brian E Carpenter Message-ID: <13fc3aa3-458f-42e8-0fac-f2448a5beab3@gmail.com> Date: Fri, 8 Jan 2021 09:01:43 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 20:02:39 -0000 Ron, On 08-Jan-21 06:53, Ron Bonica wrote: > Folks, > =20 > According to RFC 4291, =E2=80=9Crouters must not forward any packets wi= th Link-Local source or destination addresses to other links=E2=80=9D. > =20 > I interpret this statement to include packets that contain routing head= ers. For example, it forbids an SRv6 packet whose final segment has a loc= ator that begins with FE80. As the discussion shows, you really should write "a locator that matches = fe80::/10". With that fix: =20 > Does everyone share this interpretation? If so, do RFC 4291 or RFC 8200= make this sufficiently clear? Yes, and the ensuing discussion about the metaphysics of scope is irrelev= ant. Brian From nobody Thu Jan 7 12:24:04 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688353A0DFF; Thu, 7 Jan 2021 12:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WD1aekJoXSz; Thu, 7 Jan 2021 12:23:57 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0343A0DFC; Thu, 7 Jan 2021 12:23:57 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id a188so4566596pfa.11; Thu, 07 Jan 2021 12:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FpewZUbjm+wz7zAp0M8DPi5D6AOxjcwSMl9eiDAMKqs=; b=BifO5rTA+Q4qO55UshAzWWFQ9Q3geCdoUyfGmSEvHCjweGaPr+NGXrkDoUh1eZu6xg JzSPMhmLAMKh5XDYFWh/D09OHIl/iYTtu7fk+T5+Y5v3tK+s9IxyaLii5NBNXuOV6/S7 ZybwVPNGdusmxxvjR0SHsWc+Q0bOMoBxl/Uvn/mVxKWpNb0l0rBkhq7SusDb1Fzst+bm DOjuIS6F1HY91qnxxKltWS6i1zGamGZx2AfJhEHlPqMgVk7Wv5/a7uX9F8/mm4rEDgRl uBC2fdvVSmJ/cuZEwrlc+lCiVEMDzgJ7FY+sHiJm9o5B4KUNtjuSUKcLNdssTGNqYRhx PJ0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FpewZUbjm+wz7zAp0M8DPi5D6AOxjcwSMl9eiDAMKqs=; b=Pu5EHKGMCr/bghO375oGL6eoDeeZZ3/3CGI0/wZxM4W87BqqsvtVzPs9R+9n3jK14Y 1ZY7CZA0iTC2NDw1diGvpVJNJNqlYPr214eLkOeft3MNBJkXak36oLMlugVEfldMqq97 DcHXiM9LN4pp0d7p+US/8z+XsSciM9RRjGBHHX3j07v4GCvqWHnK+sm7eEA73ncOGysF kDU9U7UUUteYKmLc79SZoThRlm0oqYn+bcvDPJPfRoV1b53YZHR+dHjOmho6RfdibSMq 1CIOZxdsO/a1OWoF7dFF+ZnazvvSreAK2DcbtGa72jpUI+0E/jwrGbwPcYio+cmWK23N YZDw== X-Gm-Message-State: AOAM5302IrhP04YlZrJPed7l7xbymGwU2vSfyrzuPDYoNITwT9NrJ+Lf OdmYcCer3TgIhdnFffcluKG1bjQ0gu7hxg== X-Google-Smtp-Source: ABdhPJxr3FyH4yPJyNDHDQnGoFg2HcodvJZcrkjja+r1+xwES7Oiblh8wYn0GndFHMd2ZuWK9qGPqg== X-Received: by 2002:a63:804a:: with SMTP id j71mr3507284pgd.307.1610051036219; Thu, 07 Jan 2021 12:23:56 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id d4sm2857337pjz.28.2021.01.07.12.23.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 12:23:55 -0800 (PST) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Philip Homburg , ipv6@ietf.org Cc: IPv6 Operations References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> From: Brian E Carpenter Message-ID: <7a61fb44-b5f1-9601-4fab-5b676f0cad83@gmail.com> Date: Fri, 8 Jan 2021 09:23:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 20:23:58 -0000 On 08-Jan-21 00:41, Philip Homburg wrote: >>> No, rewrite RFC 4007 and get rid of zone IDs. And the introduce interface I >> Ds >>> to select the interface of an outgoing packet, whether link-local or global >> . >> >> Effectively that's what RFC3879 did. RFC4007 was a bit behind the >> curve. As far as I know, zone IDs and interface IDs are exactly >> equivalent (at least in POSIX and WinSock environments). IMHO this >> is *only* a terminology question. >> >>> It doesn't change anything in practice, because that is what existing code >>> does. >> >> Really? Using the interface ID for non-link-local addresses? > > It works on Linux and MacOS. On freebsd I get > '2001:67c:2e8:3::c100:a4%re0: Name does not resolve' > which suggests that they do an extra check in a library. I didn't check > if the kernel handles it. Thanks. It doesn't work on Winsock (Windows 10 version) either. It assigns interface index 0 to all global addresses (including ULAs) regardless of which physical interface they are on. There is no interface 0 on Windows; it amounts to being the "default zone" defined by RFC4007. There's nothing in RFC4007 suggesting that a non-default zone applies to global addresses. Rather the opposite: "And, when supported, the index value zero at each scope SHOULD be reserved to mean "use the default zone"... Those default indices can also be used as the zone qualifier for an address for which the node is attached to only one zone; e.g., when using global addresses." So I'd say that Linux and MacOS have got it wrong, and FreeBSD and Windows are right. Portable code certainly can't assume that the interface ID can be used for global unicast. Brian From nobody Thu Jan 7 12:32:01 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5060E3A0E21; Thu, 7 Jan 2021 12:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CR-0on6eDR1; Thu, 7 Jan 2021 12:31:53 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CAF3A0E1C; Thu, 7 Jan 2021 12:31:53 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id y8so4205560plp.8; Thu, 07 Jan 2021 12:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4JvQYBclq92wXI+R9T0jU8fYttpS6UVDl3e04m2bbdw=; b=PI208p0nSHZsqbqRETaOU4qHfrgzwurIQjocAO8EwfPc4yfNPDvgIZvW8xp5i0ydYn LuIQI+SqfIabbzHGTZ60Z+jBPI/DN72s1OORTENhI16qzW0kLOawvI0vMYdNILrzHvHj X/g5CcRVss1NcnKqcu1yolmXjEXRe0WKx2Oep/90PUsafRBwckcJPMNgfXHmaFJQhrQQ 6PQ7bnAJKbLeyKJUuDPgaJdNg4xfZohYLDVgKkEn16UxM9cjjL4kkbC5tjMZV3r4AOvM /YVkLM0NPYYiFKsaO4HVbTtqSmwQUlPAF9Rb0YjXOdR6tqSH88iZ6VpB3q405cI97P5t JmcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4JvQYBclq92wXI+R9T0jU8fYttpS6UVDl3e04m2bbdw=; b=h2z1s+eeqVGv+qp+7nCT/ZXKpBEvTapy7WOEjOAZdo4JWyai6AWDmIaAdJy/1PieLY W3qpo4L4xFnqBS60AkaVDrAmZvpdArHMgmykNdxg6bbxYd2lNLopFBYemw23Su76TVAa s1Mi6Esl4/D0qT7UuS+DIFeNzSGRDxHlFe1m3MK3vN/2DD2dP6NMDMvOYdLmqu38nZIQ yyoXU3288png5pzAAQlF8cUfL3BOUuWJFktevk3aaPF9YawI0zC7CJFeZ0OnEDD3Nbap m9IQY/xCxOFYAx868pNBfv3pMCQYs7DVbJimZqFulACfFLhN9qjqnC6e/GSjo4A/F3ax eh4A== X-Gm-Message-State: AOAM532YPUQjy4mzKexrIoETGYc14OGKj2/s/mZLYMPiwIsjHlvWIGm2 1V3onGaMg6jj26sfIySqUtaqD/UWppjioQ== X-Google-Smtp-Source: ABdhPJy75w4Eap5cmN73xCOEBjneJZapYDVO5aNLGgy7DHAk1D37H4VNAQtXFLKXHdMFkv1r1EnGyg== X-Received: by 2002:a17:90a:474c:: with SMTP id y12mr220156pjg.175.1610051512675; Thu, 07 Jan 2021 12:31:52 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id t135sm6347436pfc.39.2021.01.07.12.31.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 12:31:51 -0800 (PST) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Philip Homburg , ipv6@ietf.org Cc: IPv6 Operations , David Farmer References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> From: Brian E Carpenter Message-ID: <2faf76fd-1393-5bc5-52bf-9ee4ba3167a8@gmail.com> Date: Fri, 8 Jan 2021 09:31:48 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 20:31:54 -0000 On 08-Jan-21 00:52, Philip Homburg wrote: >> I have an idea for what to call ULA's scope without redefining global scope >> in RFC4007, how about we call ULA's scope "pseudo-global" scope. > >> What do other people think? > > In my opinion we need to kill the RFC 4007 scope concept. > > We can define for example 'address types' that have no scope, but as a way > to label different types of addresses. This. Link-local needs an interface ID or interface index, which is meaningless outside the host. All other unicast addresses are routeable, and do not require an associated interface ID. The range of reachability is always administratively defined, with default behaviours (ULA = limited domain reachability, GUA = global reachability). We could have a greatly simplified RFC4007bis in that case. Brian From nobody Thu Jan 7 13:23:08 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAD83A0F00; Thu, 7 Jan 2021 13:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkjxExMW65yJ; Thu, 7 Jan 2021 13:23:05 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0973A0F02; Thu, 7 Jan 2021 13:23:05 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id c22so6001275pgg.13; Thu, 07 Jan 2021 13:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yLHL/6r2ceLElJ3/aMhrKLKEDWKfvWlsget+FmAVz3o=; b=YHSEGI1Yca9TPA4zardYUNxyJaC3bqLELwSDYYBgovEGUiL8h41k007NmB6VVOYDgP AVi8rySv7ziUdcGKSmSbGoaZJobfEXT4zzYjHGKr5CMJmsWRUj8ei+YHflmQYkPSz4Fr 1AdKMMmZnCfPumsa1B8w6RI86lEDmIyD7HP3/rfeOq24BfUzasEU7ZIuTFL0zGv0IOl9 M8fGr3VzCV264tKi4qzCL9tPRbYYKc2gIZ4Be9EZNB2b0k7dMmIMu6B8Hb1/NEih8prd 8JHJfNvWL7riSR0cATbVZbMy6GpFQWS3PBvcaP/Ax8GHBmzHDGRDsNK/XYxGtJqifcWa Fz2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yLHL/6r2ceLElJ3/aMhrKLKEDWKfvWlsget+FmAVz3o=; b=Ek+kvowIFE00xMLOR1NL4f7d8wp+UPBOJTNI4u91dc1NsGyip+R0Idd14rFsHb7iA3 GW6c0Xjun/GLp3FjVAInDbr/zp8eRAtVmdmeWpTJvbZAxapASAIwZ1vkOqqOF/Bv9UCU 78x+sdksFODkJ/zBvq3VoWOshTOF8pgAJXwSFXIPYYIcUAyczkYy42+IgtbEb1hbLnB/ ubrvvAguVeIKyBTxdvQZb8jPcAJ37qYILfdc2FigPvEpKD/yUemu3F9MW+jGJa3ikzuh KNGwl8Q6CXOJjA8vDYH9hy0Z00uvSPjk/mEbeHUBDhQrjln50htMNGDbtRFZRnCwg6HV eKRg== X-Gm-Message-State: AOAM531MSn8y9M6aEVnJGycDMqDAJCo9OWyOAzzytvodT9oitizS9At0 TxZrsv2Nd213tbYSReaWsqYmtEGzdT4N9e1sTa0= X-Google-Smtp-Source: ABdhPJxTHRfwmwXEOqUhU44yD0uaKzlsXUp83PZ26ISxFAyUUOOKXdEuxgFojr3fsRK3gEXmh86fiAnjGSo5IsANuXA= X-Received: by 2002:a63:574c:: with SMTP id h12mr3683393pgm.79.1610054584947; Thu, 07 Jan 2021 13:23:04 -0800 (PST) MIME-Version: 1.0 References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> <2faf76fd-1393-5bc5-52bf-9ee4ba3167a8@gmail.com> In-Reply-To: <2faf76fd-1393-5bc5-52bf-9ee4ba3167a8@gmail.com> From: Mark Smith Date: Fri, 8 Jan 2021 08:22:38 +1100 Message-ID: Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Brian E Carpenter Cc: Philip Homburg , 6man WG , IPv6 Operations , David Farmer Content-Type: multipart/alternative; boundary="0000000000009ad5f305b8560b9e" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 21:23:07 -0000 --0000000000009ad5f305b8560b9e Content-Type: text/plain; charset="UTF-8" Hi Brian, On Fri, 8 Jan 2021, 07:32 Brian E Carpenter, wrote: > On 08-Jan-21 00:52, Philip Homburg wrote: > >> I have an idea for what to call ULA's scope without redefining global > scope > >> in RFC4007, how about we call ULA's scope "pseudo-global" scope. > > > >> What do other people think? > > > > In my opinion we need to kill the RFC 4007 scope concept. > > > > We can define for example 'address types' that have no scope, but as a > way > > to label different types of addresses. > > This. > > Link-local needs an interface ID or interface index, which is meaningless > outside the host. > While I do agree that interface ID is much more closer to the truth, it seems that one reason for zone rather than interface ID for link-locals in RFC 4007 was to inform a multi-interface node that it had multiple interfaces attached to the same link, informing it that the corresponding interface link-local addresses are attached to the same link. I don't know what the use case for that is or was expected to be (layer 3 inbound/outbound load balancing or redundancy?), however it sounds like it would be useful for a host to continue to have the knowledge. It would be lost with pure IPv6 interface enabled IDs. I don't think shared GUA/ULA prefixes across interfaces could be entirely relied on to determine that, as it is theoretically possible for multiple interfaces on the same host attached to the same link to have different GUA and/or ULA prefixes (perhaps by manual configuration because the received RAs don't PIOs with the A bit enabled, or any PIOs). Perhaps preserve the idea of a zone, that in most but not all cases would also be the same as interface ID, but only for the link-local unicast prefix (and for all scopes of multicast addresses). Regards, Mark. > All other unicast addresses are routeable, and do not require an > associated interface ID. The range of reachability is always > administratively defined, with default behaviours (ULA = limited domain > reachability, GUA = global reachability). > > We could have a greatly simplified RFC4007bis in that case. > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000009ad5f305b8560b9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian,

On Fri, 8 Jan 2021, 07:32 Br= ian E Carpenter, <brian.e.carpenter@gmail.com> wrote:
On 08-Jan-21 00:52, Philip Homburg wrote:
>> I have an idea for what to call ULA's scope without redefining= global scope
>> in RFC4007, how about we call ULA's scope "pseudo-global&= quot; scope.
>
>> What do other people think?
>
> In my opinion we need to kill the RFC 4007 scope concept.
>
> We can define for example 'address types' that have no scope, = but as a way
> to label different types of addresses.

This.

Link-local needs an interface ID or interface index, which is meaningless o= utside the host.

While I do agree that interface ID is much more closer to t= he truth, it seems that one reason for zone rather than interface ID for li= nk-locals in RFC 4007 was to inform a multi-interface node that it had mult= iple interfaces attached to the same link, informing it that the correspond= ing interface link-local addresses are attached to the same link.

I don't know what the use case for that is= or was expected to be (layer 3 inbound/outbound load balancing or redundan= cy?), however it sounds like it would be useful for a host to continue to h= ave the knowledge. It would be lost with pure IPv6 interface enabled IDs. I= don't think shared GUA/ULA prefixes across interfaces could be entirel= y relied on to determine that, as it is theoretically possible for multiple= interfaces on the same host attached to the same link to have different GU= A and/or ULA prefixes (perhaps by manual configuration because the received= RAs don't PIOs with the A bit enabled, or any PIOs).

Perhaps preserve the idea of a zone, that in most but not all cases= would also be the same as interface ID, but only for the link-local unicas= t prefix (and for all scopes of multicast addresses).

<= div>Regards,
Mark.


All other unicast addresses are routeable, and do not require an associated= interface ID. The range of reachability is always administratively defined= , with default behaviours (ULA =3D limited domain reachability, GUA =3D glo= bal reachability).

We could have a greatly simplified RFC4007bis in that case.

=C2=A0 =C2=A0 Brian

_______________________________________________
v6ops mailing list
v6op= s@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--0000000000009ad5f305b8560b9e-- From nobody Thu Jan 7 13:36:09 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEBE3A00C9; Thu, 7 Jan 2021 13:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uub-ntZFgPcf; Thu, 7 Jan 2021 13:36:03 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC943A0062; Thu, 7 Jan 2021 13:36:01 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7CEDA2845B1; Thu, 7 Jan 2021 21:35:53 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: David Farmer Cc: Brian E Carpenter , Lorenzo Colitti , Mark Smith , IPv6 Operations , 6MAN <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> From: Fernando Gont Message-ID: Date: Thu, 7 Jan 2021 18:35:28 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 21:36:07 -0000 On 7/1/21 08:08, David Farmer wrote: > Sorry for the top post. > > Fernando, you are correct that by the definition of global scope in > RFC4007, ULA is not global scope. > > However, Brian and RFC4139 are also correct, given the intended > reachability domain for ULA, it has a uniqueness that is many many > orders of magnitude greater than is necessary for the task. So, while > not technically global scope as defined in RFC4007 it is effectively > global scope in any way that matters. BUt this is like a circular definition. Because it's kind of saying something like "ULAs are globally unique as long as the have local scope". In order for them to have "global scope", they need to be globally unique. And you note that "they are essentially unique, gven an appropriate scope". > I have an idea for what to call ULA's scope without redefining global > scope in RFC4007, how about we call ULA's scope "pseudo-global" scope. > > This gives us; > > Link-Local > Site-Local >>>>>> Pseudo-Global > Global I don't think the site-local scope, in terms of network span, is necessarily larger than that of ULAs. > Calling ULA pseudo-global scope I believe conveys RFC4139's > original intent without conflicting with the definition of global scope > in RFC4007, while still allowing it to be treated effectively as if it > is global scope. > > What do other people think? IMO, that'd keep the confusion. At the end of the day, if your nor going to call them "global scope", the specific name for the scope doesn't really matter... as long as it is properly defined, and used consistently. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 7 13:38:42 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1B33A0062; Thu, 7 Jan 2021 13:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzoG7NR3V0pb; Thu, 7 Jan 2021 13:38:38 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1953A005D; Thu, 7 Jan 2021 13:38:37 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kxczK-0000EYC; Thu, 7 Jan 2021 22:38:34 +0100 Message-Id: To: ipv6@ietf.org Cc: Brian E Carpenter , IPv6 Operations Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> <7a61fb44-b5f1-9601-4fab-5b676f0cad83@gmail.com> In-reply-to: Your message of "Fri, 8 Jan 2021 09:23:51 +1300 ." <7a61fb44-b5f1-9601-4fab-5b676f0cad83@gmail.com> Date: Thu, 07 Jan 2021 22:38:34 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 21:38:40 -0000 >There's nothing in RFC4007 suggesting that a non-default zone applies >to global addresses. Rather the opposite: > >"And, when supported, the index value zero at each >scope SHOULD be reserved to mean "use the default zone"... >Those default indices can also be used >as the zone qualifier for an address for which the node is attached >to only one zone; e.g., when using global addresses." > >So I'd say that Linux and MacOS have got it wrong, and FreeBSD >and Windows are right. Portable code certainly can't assume that >the interface ID can be used for global unicast. I don't see any text that disallows accepting an interface ID on a GUA. 0 is the default zone. But that does not rule out other zones. In my opinion this is a useful feature, that could be added to a bis document as a MAY. From nobody Thu Jan 7 13:40:54 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE98E3A00E5; Thu, 7 Jan 2021 13:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dPDieXJZfGz; Thu, 7 Jan 2021 13:40:52 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159883A00E0; Thu, 7 Jan 2021 13:40:52 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kxd1U-0000EhC; Thu, 7 Jan 2021 22:40:48 +0100 Message-Id: To: ipv6@ietf.org Cc: Mark Smith , IPv6 Operations Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> <2faf76fd-1393-5bc5-52bf-9ee4ba3167a8@gmail.com> In-reply-to: Your message of "Fri, 8 Jan 2021 08:22:38 +1100 ." Date: Thu, 07 Jan 2021 22:40:48 +0100 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 21:40:54 -0000 >While I do agree that interface ID is much more closer to the truth, it >seems that one reason for zone rather than interface ID for link-locals in >RFC 4007 was to inform a multi-interface node that it had multiple >interfaces attached to the same link, informing it that the corresponding >interface link-local addresses are attached to the same link. Are there any implementation that do this? And in particular how does that work with the socket interface? I.e., with if_nametoindex and if_indextoname. From nobody Thu Jan 7 13:41:07 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFF03A03EF for ; Thu, 7 Jan 2021 13:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5nc-t-KLgFW for ; Thu, 7 Jan 2021 13:40:58 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF643A099F for <6man@ietf.org>; Thu, 7 Jan 2021 13:40:58 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 95DF42846ED; Thu, 7 Jan 2021 21:40:55 +0000 (UTC) Subject: Re: Forwarding Packets With Link Local Destination Addresses To: Ron Bonica , "6man@ietf.org" <6man@ietf.org> References: From: Fernando Gont Message-ID: Date: Thu, 7 Jan 2021 18:40:18 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 21:41:07 -0000 Hi, Ron, On 7/1/21 14:53, Ron Bonica wrote: > Folks, > > According to RFC 4291, routers must not forward any packets with > Link-Local source or destination addresses to other links. > > I interpret this statement to include packets that contain routing > headers. For example, it forbids an SRv6 packet whose final segment has > a locator that begins with FE80. > > Does everyone share this interpretation? If so, do RFC 4291 or RFC 8200 > make this sufficiently clear? Let me ask a different question: Why should this be any different for a routing header? The specs still apply. I'd say that the case of link-locals is probably even "worse", because it would mean a link-local address was included in a routing header, to be processed by some router elsewhere in the networks. Something that doesn't seem to make any sense to me. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 7 13:52:05 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BC43A0365 for ; Thu, 7 Jan 2021 13:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vaEDmqOnFSr for ; Thu, 7 Jan 2021 13:52:01 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5123A0332 for <6man@ietf.org>; Thu, 7 Jan 2021 13:52:01 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id z9so5350769qtn.4 for <6man@ietf.org>; Thu, 07 Jan 2021 13:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=Yah5BKzrZcY59QVoRtmh+zi4NMojLGjFgjlFn82oQ3A=; b=Q87eaywU9xqrQNb+UqMw+36lgQV2bBCxCmejCrHhFZXnk9O70TSJ8pETJFFQb9+xAO SNIxrx91IJbo6YTtmmdFkrwjddUX1EuGY+mx9t2Ksc/QFkaorgRAVoSBbG8YffoZFCIe /VM5uMZNK+IogMO6qOxowDNSqsaF1H5ORZQAoLHK+E/f8vlB6w2sTK9vUAr/Gc8DFujx fsuUGkZFB4nNUdzCqDPIMkpfRJQrheNW8n+hd5IfDMNp6Qoh7NBME2rbL5LAeRcCMjoa lI7NqAd0WYd+6YedvZIqOzbgzD2zbD9I1ugZV7rXAhdDg31C0qqYU2VG5wz+YS/AbiLF 281g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=Yah5BKzrZcY59QVoRtmh+zi4NMojLGjFgjlFn82oQ3A=; b=dDBVXyBvPg7JERq3EIyaDkkQeL/h1h8Wgfl1fieuCM+3xyaVAuqSJBTMB4+tOo9Llh bF5bFpVEiq4JblE1EtqbuJ3tITuoHmE0T0yD02mcH07te3WpcOze4kttwCCQ2BXQ60VM CwufopR8HQSJvlXxgGRa9x1Yk27enm2+RLI5X2OMqAmm+VOxviUEWUAe9y9IY8o+dDcC wvgPqy5PNFbJtNUspL2TFikRiO8904ND6fCS/iw/qA0d6i1I3qu85mBocsw0BoBmR82y fCCcfO4PWtFl3/uINa4PkOnC5gAluT9gtxTx7Kys+q9LSEEuQer5aPSRjzDnnOZwc1Qu QuSQ== X-Gm-Message-State: AOAM532fwcVOrbdF0tenieCW69AAuAY2wifWXhNy4uw+RDcRZWh0/wPs 0f6R9UTBD6FgoGX/3XUF3sPe5YMlS7sq7w== X-Google-Smtp-Source: ABdhPJyIOnqRjl/Wc8VgHCyPO5OHpGatbxNOvAV3koFEiN+JuAa4u9mQnBvghDcdnzBULiGccZUwmg== X-Received: by 2002:a05:622a:195:: with SMTP id s21mr682575qtw.53.1610056320340; Thu, 07 Jan 2021 13:52:00 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id h22sm1076805qth.55.2021.01.07.13.51.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 13:51:59 -0800 (PST) From: Ted Lemon Content-Type: multipart/alternative; boundary="Apple-Mail=_9B9E229B-E3CB-421A-BD3B-D84608B26E86" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Thu, 7 Jan 2021 16:51:57 -0500 References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> To: IPv6 Operations , 6MAN <6man@ietf.org> In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.60.0.2.2) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 21:52:04 -0000 --Apple-Mail=_9B9E229B-E3CB-421A-BD3B-D84608B26E86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 7, 2021, at 4:35 PM, Fernando Gont wrote: > In order for them to have "global scope", they need to be globally = unique. And you note that "they are essentially unique, gven an = appropriate scope=E2=80=9D. I think the disconnect here is that RFC 4007=E2=80=99s definition of = =E2=80=9Cglobal scope=E2=80=9D clearly contradicts the sense in which = ULAs are =E2=80=9Cglobal.=E2=80=9D So that=E2=80=99s a real problem. At the same time, the next question to ask is in what sense =E2=80=9Cgloba= l scope=E2=80=9D is actionable. People have been talking about zone = identifiers as a way to determine scope, but in practice the way we do = this is with routing table entries. The reason you have to specify a = zone ID for a link-local address is that the route to the link-local = prefix is present on all interfaces, but the address is valid on only = one interface. So you specify that interface with the zone ID. I use the term interface = loosely here=E2=80=94in principle you could have two interfaces = connected to the same link, and that would notionally mean that they = both have the same zone ID, but there=E2=80=99s no safe way to make this = determination in practice, so in practice the =E2=80=9Czone IDs=E2=80=9D = will always be different. The same situation does not apply for ULAs. You can (almost) just use = routing table entries to deliver ULAs. I say (almost) because of course = if you don=E2=80=99t have an explicit route to the ULA prefix, you = can=E2=80=99t send the packet. So there=E2=80=99s a tendency to want to = send the packet to the default route, but that doesn=E2=80=99t work if = you have two interfaces and two default routers. This is why it=E2=80=99s = tempting to then use the =E2=80=9Czone ID=E2=80=9D to resolve this = problem. But that doesn=E2=80=99t work, because the host has no way to = know which zone ID to use. So it=E2=80=99s the network=E2=80=99s responsibility to provide enough = information that the ULA can be correctly routed. There are two ways to = do this that spring to mind: 1. Make assumptions 2. Only send to a ULA if you have a specific non-global route that = points to it. 3. Use provisioning domains (https://tools.ietf.org/html/rfc6418) Option 2 is probably the safest solution. If the route is present on two = interfaces, and you have a collision, and not just two valid ways of = reaching the same destination, then you will have a problem. This is why = ULAs aren=E2=80=99t as fabulous as we might wish. But in practice, = it=E2=80=99s entirely safe to do this. Option 1 could work pretty well, e.g. on a cell phone. Not so well on a = host with two network interfaces. It=E2=80=99s unlikely that a ULA is = going to work on the global internet, so you never send it on the = cellular interface. Problem solved. This is the sense in which I think = it=E2=80=99s tempting to say that the scope of a ULA is not global, = because here you can make a purely mechanical decision. Option 3 would work quite well. Presumably if the name server for a = provisioning domain gives you a ULA, then you can use the default router = for that provisioning domain to reach that ULA (if it=E2=80=99s not = on-link). So here you have effectively an explicit scope, which really = doesn=E2=80=99t play well with the meaning of =E2=80=9Cscope=E2=80=9D in = RFC 4007. --Apple-Mail=_9B9E229B-E3CB-421A-BD3B-D84608B26E86 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 7, 2021, at 4:35 PM, Fernando Gont <fgont@si6networks.com> wrote:
In order for them to have "global scope", they need to be = globally unique. And you note that "they are essentially unique, gven an = appropriate scope=E2=80=9D.

I think the disconnect here is that RFC 4007=E2=80=99= s definition of =E2=80=9Cglobal scope=E2=80=9D clearly contradicts the = sense in which ULAs are =E2=80=9Cglobal.=E2=80=9D So that=E2=80=99s a = real problem.

At the same time, the = next question to ask is in what sense =E2=80=9Cglobal scope=E2=80=9D is = actionable. People have been talking about zone identifiers as a way to = determine scope, but in practice the way we do this is with routing = table entries. The reason you have to specify a zone ID for a link-local = address is that the route to the link-local prefix is present on all = interfaces, but the address is valid on only one = interface.

So you specify that = interface with the zone ID. I use the term interface loosely here=E2=80=94= in principle you could have two interfaces connected to the same link, = and that would notionally mean that they both have the same zone ID, but = there=E2=80=99s no safe way to make this determination in practice, so = in practice the =E2=80=9Czone IDs=E2=80=9D will always be = different.

The same situation does = not apply for ULAs. You can (almost) just use routing table entries to = deliver ULAs. I say (almost) because of course if you don=E2=80=99t have = an explicit route to the ULA prefix, you can=E2=80=99t send the packet. = So there=E2=80=99s a tendency to want to send the packet to the default = route, but that doesn=E2=80=99t work if you have two interfaces and two = default routers. This is why it=E2=80=99s tempting to then use the = =E2=80=9Czone ID=E2=80=9D to resolve this problem. But that doesn=E2=80=99= t work, because the host has no way to know which zone ID to = use.

So it=E2=80=99s the network=E2=80= =99s responsibility to provide enough information that the ULA can be = correctly routed. There are two ways to do this that spring to = mind:
1. Make assumptions
2. Only send to a ULA if = you have a specific non-global route that points to it.
3. Use = provisioning domains (https://tools.ietf.org/html/rfc6418)

Option 2 is probably the safest solution. If the = route is present on two interfaces, and you have a collision, and not = just two valid ways of reaching the same destination, then you will have = a problem. This is why ULAs aren=E2=80=99t as fabulous as we might wish. = But in practice, it=E2=80=99s entirely safe to do this.

Option 1 could work pretty well, e.g. on a cell = phone. Not so well on a host with two network interfaces. It=E2=80=99s = unlikely that a ULA is going to work on the global internet, so you = never send it on the cellular interface. Problem solved. This is the = sense in which I think it=E2=80=99s tempting to say that the scope of a = ULA is not global, because here you can make a purely mechanical = decision.

Option 3 would work quite = well. Presumably if the name server for a provisioning domain gives you = a ULA, then you can use the default router for that provisioning domain = to reach that ULA (if it=E2=80=99s not on-link). So here you have = effectively an explicit scope, which really doesn=E2=80=99t play well = with the meaning of =E2=80=9Cscope=E2=80=9D in RFC 4007.

= --Apple-Mail=_9B9E229B-E3CB-421A-BD3B-D84608B26E86-- From nobody Thu Jan 7 13:56:18 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24423A0163; Thu, 7 Jan 2021 13:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSKI2qgSig7j; Thu, 7 Jan 2021 13:56:14 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9813C3A03C9; Thu, 7 Jan 2021 13:56:14 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 259702846ED; Thu, 7 Jan 2021 21:56:10 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Brian E Carpenter , Philip Homburg , ipv6@ietf.org Cc: IPv6 Operations , David Farmer References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> <2faf76fd-1393-5bc5-52bf-9ee4ba3167a8@gmail.com> From: Fernando Gont Message-ID: <13bdd3ca-9b3d-8ce9-404d-12d508404fbd@si6networks.com> Date: Thu, 7 Jan 2021 18:55:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <2faf76fd-1393-5bc5-52bf-9ee4ba3167a8@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 21:56:18 -0000 On 7/1/21 17:31, Brian E Carpenter wrote: > On 08-Jan-21 00:52, Philip Homburg wrote: >>> I have an idea for what to call ULA's scope without redefining global scope >>> in RFC4007, how about we call ULA's scope "pseudo-global" scope. >> >>> What do other people think? >> >> In my opinion we need to kill the RFC 4007 scope concept. >> >> We can define for example 'address types' that have no scope, but as a way >> to label different types of addresses. > > This. Me, as long as the outcome is clear, I'm fine. ("scope", as a conceptual property of addresses doesn't seem bad. You can talk about the scope of IPv5 addresses (link-local, private/local, global) in IPv4, too). That said, removing the concept of "scope" would probably need more things to be re-worked -- not necessarily bad, though. > Link-local needs an interface ID or interface index, which is meaningless outside the host. > > All other unicast addresses are routeable, and do not require an associated interface ID. The range of reachability is always administratively defined, with default behaviours (ULA = limited domain reachability, GUA = global reachability). Me thinking out loud: What about the case where you have a host with two interfaces, each with one different ULA prefix, and you need to send packets to a destination ULA prefix, that is totally different from the two you're using? Another similar case would be a host with two interfaces, global addresses on each, that has to send packets to a ULA prefix. It would seem to me that in wuch cases, you'd need a way to specify an interface. (Not sure if, conceuptually speaking, not having an address configured for the ULA prefix you're trying to communicate with, means that you're not part of the "zone", and hence, that you're on your own) -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 7 14:14:09 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5B73A093D; Thu, 7 Jan 2021 14:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi3WhQZVexFp; Thu, 7 Jan 2021 14:13:59 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43AAB3A0902; Thu, 7 Jan 2021 14:13:59 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 46FAD283C00; Thu, 7 Jan 2021 22:13:56 +0000 (UTC) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Ted Lemon , IPv6 Operations , 6MAN <6man@ietf.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> From: Fernando Gont Message-ID: Date: Thu, 7 Jan 2021 19:13:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 22:14:03 -0000 On 7/1/21 18:51, Ted Lemon wrote: > On Jan 7, 2021, at 4:35 PM, Fernando Gont > wrote: >> In order for them to have "global scope", they need to be globally >> unique. And you note that "they are essentially unique, gven an >> appropriate scope”. > > I think the disconnect here is that RFC 4007’s definition of “global > scope” clearly contradicts the sense in which ULAs are “global.” So > that’s a real problem. Indeed! > At the same time, the next question to ask is in what sense “global > scope” is actionable. People have been talking about zone identifiers as > a way to determine scope, but in practice the way we do this is with > routing table entries. The reason you have to specify a zone ID for a > link-local address is that the route to the link-local prefix is present > on all interfaces, but the address is valid on only one interface. Agreed. Or: the address is not globally-unique. So the same address is actually valid on all interfaces, most-likely corresponding to different nodes .. and thus you need to specify which of all those possible instances of address FE80::X you are referring to. > The same situation does not apply for ULAs. You can (almost) just use > routing table entries to deliver ULAs. I say (almost) because of course > if you don’t have an explicit route to the ULA prefix, you can’t send > the packet. As noted to Brian, the case that might need a zone-id is that where you have a host with two interfaces, each with one different ULA prefix, and you need to send packets to a destination ULA that belongs to a whole different prefix than the ones for which you have configured addresses for your two interfaces. Another similar case would be a host with two interfaces, global addresses on each, that has to send packets to a ULA prefix. Relying on your default route might not get your to where you want. (Not sure if, conceptually speaking, not having an address configured for the ULA prefix you're trying to communicate with, means that you're not part of the "zone", and hence, that you're on your own) > So there’s a tendency to want to send the packet to the > default route, but that doesn’t work if you have two interfaces and two > default routers. This is why it’s tempting to then use the “zone ID” to > resolve this problem. But that doesn’t work, because the host has no way > to know which zone ID to use. That seems to be a similar case than the one I was noting above. I gues it could also be more complicate: even if you had a single interface, you might have multiple default routers. So rather than specifying an interface, you might actually need to specify "which next hope" to use. Of course one cannot expect that. > So it’s the network’s responsibility to provide enough information that > the ULA can be correctly routed. There are two ways to do this that > spring to mind: > 1. Make assumptions > 2. Only send to a ULA if you have a specific non-global route that > points to it. #2 would probably make cases that are currently supported, unsupported. e.g.: think of a case where your local router advertises a /64 ULA prefix on the local link, and you want to send a packet to an address of a different subnet of the same Global-ID. -- most likely your router is not sending RIOs for the ULA prefix you're employing.... > Option 1 could work pretty well, e.g. on a cell phone. Not so well on a > host with two network interfaces. It’s unlikely that a ULA is going to > work on the global internet, so you never send it on the cellular > interface. Problem solved. This is the sense in which I think it’s > tempting to say that the scope of a ULA is not global, because here you > can make a purely mechanical decision. Agreed on this one. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 7 14:40:32 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49B03A0B60; Thu, 7 Jan 2021 14:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcMtVuIdNxpV; Thu, 7 Jan 2021 14:40:29 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0A33A0B58; Thu, 7 Jan 2021 14:40:29 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id c79so4968114pfc.2; Thu, 07 Jan 2021 14:40:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=isJhehR/Lx5KryYWUyXiXdsKsDPxDqgzvGIQPqTi3a0=; b=TCnLCuj6XypXny9QhAp4KG7uxXxq2LKUHWkpBXUuJrBFpz623SeTF+7tuYqmhCIdYl cXRB+965PomLn4F+guY10jMpBK566tXDjE9QGHL8y580WWelfv7aWwaOwAghGiPI3fKl Rfm6fmDqQPoR31hBbbEX8sjjBn6moDIwyiWyGTUNErlH2obtfBjGCLZrYydo4lidS5c6 wWmtmMqMYDx0YLKon5MyLS0mxJ9+YEJ+qY4EAbVyf6i+bqHvMznRVL/mCk/zFWm67rHA ZgctE5sfUlZRH+PL369t1/vyW+fcB9rOxVIrvutHJrSKC5hQPsizNcd0DXV35WopGaJT dRZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=isJhehR/Lx5KryYWUyXiXdsKsDPxDqgzvGIQPqTi3a0=; b=mtGvG49fV6uyW2poL7+2Rlgd01sXBHEtfmDnyZa5wgRZ5Jn9L1lfQR6nIe5LkvxDmI SuHxH+2jSNm4iJjcIFIpFEFK34M/7p6078eaTQzntOUazh3MIDnJ0GqVsDwR0DN28RO4 M4CHpJUfYtfQgx/MmjiMPSaE+yQy36AB9nbHGblrBVPjczVq6T3pdBL8vuUBxlHspCD/ orZVDL7puyO4/+fjkdzvTftN6cBUdEi5gTaE99+G7lJSfO19AFPaBTgjet8LDRGG+By3 pdx5Rv61X75az3Or0DWrsTdeUy8Igzo2Dsg/Rsqol1JKUhy8JJwKWu1ppPuRNwPV47ua 9MLA== X-Gm-Message-State: AOAM530OOgietRIo00/0qxTEoZm2XPEf8085zyasftLW5im87g++/WiZ YaOOayrquTVkfl11vgDJVefnQaOCBKu7Gg== X-Google-Smtp-Source: ABdhPJyNV+n1dSlQDEBGCociFAQcqvS9f7dBhDRiI7burF6fKVV8kHGrORBX5d5Nkq8ODyfnsdEqJw== X-Received: by 2002:a63:5023:: with SMTP id e35mr4007909pgb.56.1610059228561; Thu, 07 Jan 2021 14:40:28 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id q35sm2924495pjh.38.2021.01.07.14.40.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 14:40:27 -0800 (PST) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) To: Philip Homburg , ipv6@ietf.org Cc: IPv6 Operations References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <44e7ac61-523a-d35e-9024-7e6df81e4226@gmail.com> <2faf76fd-1393-5bc5-52bf-9ee4ba3167a8@gmail.com> From: Brian E Carpenter Message-ID: <9677fd8c-a61c-3292-a21a-2f7a31072a74@gmail.com> Date: Fri, 8 Jan 2021 11:40:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 22:40:31 -0000 On 08-Jan-21 10:40, Philip Homburg wrote: >> While I do agree that interface ID is much more closer to the truth, it >> seems that one reason for zone rather than interface ID for link-locals in >> RFC 4007 was to inform a multi-interface node that it had multiple >> interfaces attached to the same link, informing it that the corresponding >> interface link-local addresses are attached to the same link. > > Are there any implementation that do this? And in particular how does > that work with the socket interface? I.e., with if_nametoindex and > if_indextoname. The machine on which I am typing has interface 6 and interface 22 both up and running. On interface 6, the default router is fe80::2e3a:fdff:fea4:dde7%6 On interface 22, the default router is fe80::2e3a:fdff:fea4:dde7%22 Yes, they are the same thing because the default router is also a transparent Ethernet-to-WiFi bridge. Interface 6 and interface 22 both connect to the same LAN, but the IP stack has no way to know it. The zone index as described in RFC4007 is a hallucination. Brian From nobody Thu Jan 7 15:45:57 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580CE3A0E04 for ; Thu, 7 Jan 2021 15:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1dKiphXpozF for ; Thu, 7 Jan 2021 15:45:53 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF4A3A0DFF for <6man@ietf.org>; Thu, 7 Jan 2021 15:45:53 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id p18so6405739pgm.11 for <6man@ietf.org>; Thu, 07 Jan 2021 15:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3ukSr5FbiGVH1/ncbPKK/n2cjQzVTytnqLT7pW5vDhU=; b=sN7LimYbVcjEuiFZw+PChoKfsIpVVS/21EeumRlCKgFkXelJus3Zo+geM2/47TS8ec QMjfuG8fPoSLvatFrodMQhy6nhXjGto7t/67eZA6ausawT3FGaojPw3eFR0oqFRoG7ih k9WcGkzfY4h7Vmbf0LD7q1b9HPQeItW98rHkRepYpgBLD1yzQHQmaCO5ojtX/rYd+sxF fRYD9zbuT42upVn6I2+GDz6VmGR/2g4YBLNZVmA55QQsScTqJcmPmt7xYZF6+Y73oG28 uWevoXok0KiAAz+z8hMpzPyAOB3EO4JOwTOXFEaIk1u16Sc0YLKkmMnNG2cRlbl2PkvW E21A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3ukSr5FbiGVH1/ncbPKK/n2cjQzVTytnqLT7pW5vDhU=; b=hhcrJi5XDeTzHKfIKa0q2he3Jbtc3N00RTyrVTQ7M5MTYFVVHTIf/lkN4P+2y43b5O rPtnm+A7uwRXTloN7i6RoqpTOTK07e4rNKAXd2zZKFvVvZVPmSiBEgQA8lMjq/YhVP/S Phsb4AWbF3ef3ZNU/A7J6ttmHKCdpHDiygnoPumbcSLZS9Yq6CUbPnqKbFBOfLz7E2bj g+C7jR+aZ2/Ye/UUhzKxRMApr6mA2DObG/Al3lmJb3u3QXvOP4WEjevaQ+g3u2Ndd9uE SKrrbtcyT1SCXd8vGhFGrV6FzVWbfgiLHojLBh79WBCizXXEvbY9v/eKHkdWxeb+7QZl SmTg== X-Gm-Message-State: AOAM533+Jtfoj1Ix9v54ttS9PFr5IDsyURVdxvaDuuvih76XPUxoDOWU P/tarR3jde9tHc4lOlGhEDUP2qhQgUhJsjGLkaq7ORflE9xhVA== X-Google-Smtp-Source: ABdhPJxfjDeIoq1ZaMBdgIPwRsI4iDlWGu/uayyJKZoWm9hSy7haxCsiiaVRsaAyU/JGCHaMin4vy9FTQsP7WA6vN58= X-Received: by 2002:a62:e408:0:b029:19e:2c4b:6a8e with SMTP id r8-20020a62e4080000b029019e2c4b6a8emr4412265pfh.30.1610063152229; Thu, 07 Jan 2021 15:45:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Thu, 7 Jan 2021 18:45:41 -0500 Message-ID: Subject: Re: Forwarding Packets With Link Local Destination Addresses To: Ron Bonica Cc: "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="00000000000041302005b8580a17" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 23:45:55 -0000 --00000000000041302005b8580a17 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ron In-line I agree that RFC 4291 although could have been written better. On Thu, Jan 7, 2021 at 12:54 PM Ron Bonica wrote: > Folks, > > > > According to RFC 4291, =E2=80=9Crouters must not forward any packets with > Link-Local source or destination addresses to other links=E2=80=9D. > Gyan>=E2=80=9C Link local source or destination to any other link=E2=80= =9D it is trying to > imply =E2=80=9Coff link=E2=80=9D. Link local cannot be used in an off lin= k scenario. > I agree the verbiage includes an SRv6 SRH inclusive that the final SID > cannot be a link local address. As the final SID is copied to the > destination address of the IPv6 header during processing that would be > construed as explicit forwarding of a packet which is forbidden. Link > local due to =E2=80=9Clocal scope=E2=80=9D on link non routable scope, so= therefore the > packet cannot be forwarded using destination link local. Since this is a= n > SRV6 SRH steered transitive path and not packets that are transmitted > locally between two adjacent nodes such as ND or OSPF for example, this i= s > clearly forbidden. I think the transitive nature even though it=E2=80= =99s hop by > hop steering, makes it off link routed thus link local destination is no= t > in scope for final SID. > > I interpret this statement to include packets that contain routing > headers. For example, it forbids an SRv6 packet whose final segment has a > locator that begins with FE80. > > > > Does everyone share this interpretation? If so, do RFC 4291 or RFC 8200 > make this sufficiently clear? > > Agreed. I think it could be much clearer per my note above. > > > Ron > > Juniper Business Use Only > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000041302005b8580a17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Ron

In-line=C2=A0

I agree that RFC 4291 although could have been written better.

On Th= u, Jan 7, 2021 at 12:54 PM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:

Folks,

=C2=A0

According to RFC 4291, =E2=80=9Crouters must not for= ward any packets with Link-Local source or destination addresses to other l= inks=E2=80=9D.

Gyan>=E2=80=9C Link local source or destination to any other link=E2=80= =9D it is trying to imply =E2=80=9Coff link=E2=80=9D. Link local cannot be = used in an off link scenario.
=C2=A0I agree the verbiage includes an= SRv6 SRH inclusive that the final SID cannot be a link local address.=C2= =A0 As the final SID is copied to the destination address of the IPv6 heade= r during processing that would be construed as explicit forwarding of a pac= ket which is forbidden.=C2=A0 Link local due to =E2=80=9Clocal scope=E2=80= =9D on link non routable scope, so therefore the packet cannot be forwarded= using destination link local.=C2=A0 Since this is an SRV6 SRH steered tran= sitive path and not packets that are transmitted locally between two adjace= nt nodes such as ND or OSPF for example, this is clearly forbidden.=C2=A0 I= think the =C2=A0transitive nature even though it=E2=80=99s hop by hop stee= ring, makes it off link routed thus link local destination =C2=A0is not in = scope for final SID.
=

I interpret this statement to include packets that c= ontain routing headers. For example, it forbids an SRv6 packet whose final = segment has a locator that begins with FE80.

=C2=A0

Does everyone share this interpretation? If so, do R= FC 4291 or RFC 8200 make this sufficiently clear?

=C2=A0Agreed.=C2=A0 I think it c= ould be much clearer per my note above.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Ron


Juniper Business Use Only

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--
--00000000000041302005b8580a17-- From nobody Thu Jan 7 16:57:01 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06823A0F47 for ; Thu, 7 Jan 2021 16:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyXX36YUAh_a for ; Thu, 7 Jan 2021 16:56:58 -0800 (PST) Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C543A0F48 for <6man@ietf.org>; Thu, 7 Jan 2021 16:56:57 -0800 (PST) Received: by mail-ua1-f50.google.com with SMTP id a31so2898658uae.11 for <6man@ietf.org>; Thu, 07 Jan 2021 16:56:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hzVirpCvNs27IF0R9/iPWRj4Jpp54oWly7KLMuy2I24=; b=D1oyGOXPilr6P9hWYBSB4PMWWvWSOHANx5zpKHahf4lfSNsbTPvMFMp1NSQ80q5LtU koAsbfzEjy1QP2E0g6gLfcf3Npv5krOB86B8PYeUwlW7S7Og5pfDDN0x4IB2F8jGvfZN 98aAATwYe0jkHkzZKPxkiQ+FzB1zq5zKaCcTprGjp2Lk5ZA334C4vA8muq7tcEURiW2S fDPLGF9GhuF8kNoOCa2B/P3ySsLnULMdLwGVzgpjT/sT+WETSEYfONFnbtnx+K3Fw08Y YruHRQ8ShOQD3Hoh3YK27aw98LRxw/qBy4hyBqU4RKgYL0Qxu78wJKz0uJAajFT8VNy0 4aCA== X-Gm-Message-State: AOAM532i02Jlo/s0sl7Uv1UPstuXCgAqt+lYklJKRxYVi1cBLMJYYqd7 Ki1lJFftPg/AP6C7Sa0oEjHGL5f8qPqngGjp4ykSamLlbBlKVQ== X-Google-Smtp-Source: ABdhPJzc+NBpXj2238vCUSZZmoSggKPPhwKzQyFVyza9jc14SGfAkv6jhdsLD6IwgAnY6NR73MN2jgdvQmd1NsOzUmw= X-Received: by 2002:ab0:6206:: with SMTP id m6mr1107692uao.123.1610067416860; Thu, 07 Jan 2021 16:56:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 7 Jan 2021 16:56:45 -0800 Message-ID: Subject: Re: Forwarding Packets With Link Local Destination Addresses To: Fernando Gont Cc: Ron Bonica , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 00:57:00 -0000 At Thu, 7 Jan 2021 18:40:18 -0300, Fernando Gont wrote: > > According to RFC 4291, =E2=80=9Crouters must not forward any packets wi= th > > Link-Local source or destination addresses to other links=E2=80=9D. > > > > I interpret this statement to include packets that contain routing > > headers. For example, it forbids an SRv6 packet whose final segment has > > a locator that begins with FE80. > > > > Does everyone share this interpretation? If so, do RFC 4291 or RFC 8200 > > make this sufficiently clear? > > Let me ask a different question: > Why should this be any different for a routing header? The specs still > apply. The RFC 4291 spec still applies, but if it were only with RFC 4291, we could allow the following: - A node sends a packet with a routing header that would route the packet to a global address (D1) and then to a link-local (final) destination (D2). - The packet leaves the source link and is delivered to the interface corresponding to the global address D1. - The receiving node now sets D2 as the destination address of the IPv6 header and forwards the packet to the link where the packet is delivered to D2 (so it does not forward the packet to "other link"). RFC 4007 makes it clearer that this scenario is forbidden. > I'd say that the case of link-locals is probably even "worse", because > it would mean a link-local address was included in a routing header, to > be processed by some router elsewhere in the networks. Something that > doesn't seem to make any sense to me. Actually, I can imagine a source routing usage where all intermediate and final destination addresses are link-local, and the packet is forwarded through nodes within the same link. It may still be an imaginary scenario, but it still makes some sense to me (I don't intend to champion that usage though). -- JINMEI, Tatuya From nobody Thu Jan 7 17:18:58 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275EF3A0FD5; Thu, 7 Jan 2021 17:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFRrgdCN9rEz; Thu, 7 Jan 2021 17:18:51 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A443A0FD3; Thu, 7 Jan 2021 17:18:51 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id D98123AB0CD; Fri, 8 Jan 2021 01:18:50 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C897F160051; Fri, 8 Jan 2021 01:18:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AEA24160056; Fri, 8 Jan 2021 01:18:50 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XKNsoYu0oYah; Fri, 8 Jan 2021 01:18:50 +0000 (UTC) Received: from [172.30.42.68] (n114-75-149-106.bla4.nsw.optusnet.com.au [114.75.149.106]) by zmx1.isc.org (Postfix) with ESMTPSA id 92548160051; Fri, 8 Jan 2021 01:18:49 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) From: Mark Andrews In-Reply-To: Date: Fri, 8 Jan 2021 12:18:46 +1100 Cc: Philip Homburg , IPv6 Operations , IPv6 List Content-Transfer-Encoding: quoted-printable Message-Id: <78D0D84C-53DB-4661-BA43-CFEB1F377BB4@isc.org> References: <160989494094.6024.7402128068704112703@ietfa.amsl.com> <6fe3a45e-de65-9f88-808d-ea7e2abdcd16@si6networks.com> <91424EEE-EF12-4B5B-ADE4-38230E049290@isc.org> <6F3726EE-F089-4F26-BB30-F22686617C03@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.7) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 01:18:53 -0000 > On 8 Jan 2021, at 02:08, Ted Lemon wrote: >=20 > On Jan 7, 2021, at 9:55 AM, Philip Homburg = wrote: >> I can see a few benefits of Mark's proposal. One is that it is good = to >> have a standard representation of information. In particular, >> Mark's proposal would make it possible to have a master zone file = that has >> both public and private DNS entries. Then a split-DNS server could = serve >> only the public data to the outside world.=20 >=20 > That=E2=80=99s a good point, although it would still be a good point = if this were just a feature of the zone file and not of the wire format. >=20 >> At the same time, I think it would be great if we can put link-local = addresses >> in DNS.=20 >=20 > That sounds like a really heavy lift. >=20 >> It may tie in nicely with scope IDs in socket addresses. If a DNS >> record specifies that is valid only on a VPN link, then maybe we can = already >> tie the address to that link. No need to change applications, it can = be >> hidden in the stub resolver. >=20 > Now we need to standardize a way to identify links. This is a Hard = Problem. I say this based on experience, not supposition. HNCP tried to = do this, not as successfully as I=E2=80=99d hoped. I=E2=80=99ve been = working on it for the Thread Border Router work, and haven=E2=80=99t = come up with a general solution. Sure, if you have a data center and a = managed multi-subnet LAN, and you can just type in configurations, this = works, but most networks aren=E2=80=99t like that. I think the VPN case = is probably tractable, but it=E2=80=99s really hard to see a path to = broad adoption for this idea. My idea would be that there would also be a RA option(s) which = advertised the names in the SA records that where applicable to the = link. Implicit to that is that there would be a API that allows = getaddrinfo() to retrieve the RA options for individual links and for all links on the node. = getaddrinfo() would use the later. The former would be used to = construct UPDATE requests for the DNS etc. LLSANAME (link-local SA = name), ULASANAM (ULA SA name), and perhaps others. > If there is a path to broad adoption, it probably involves bottom-up = work, not top-down design. Most of the ideas I=E2=80=99ve had about this = that I think are practicable are very context-dependent. E.g., you can = identify that you are on the same link because you received a = link-scoped multicast. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jan 7 17:34:41 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A9B3A1002 for ; Thu, 7 Jan 2021 17:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycqUyxnyoRL0 for ; Thu, 7 Jan 2021 17:34:38 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFF83A1001 for ; Thu, 7 Jan 2021 17:34:38 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id 19so7266605qkm.8 for ; Thu, 07 Jan 2021 17:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=AMyEWtzigHn5DH/OEg4WW/3Gg5Y/Rx9UsHjzLrrv4fc=; b=huU7fCSroM9LWm4FVRyJu0jMlrlouOsKSKyeIqVxwpi2lamQC8ToZNbT3llTtifGg4 34tUYv6Ldq283ZdpCb//T6rXVDw6eMJ8fsvRmobhu9OmMUcKnrlS6QlHvLOv1Ff59ZIH r36wM6ndfqaFxsOmzVWofjK6acOt7Wr5x4qb1xj0aUoISVpy7No5Hr+OduU8av+yhxv4 nrkLVVzqLLWIREgjSjRKPB58QRyRcSq5qOP05YbXqN+zu/c5sF08KhOCWkpRMe6+Pg6n oGiG0tgzlB3cailOps+OUo9p0c+FMFm90n0jcp83fd1YDApYkvEUV4lJLbxLQ+e9uUvq XHiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AMyEWtzigHn5DH/OEg4WW/3Gg5Y/Rx9UsHjzLrrv4fc=; b=N0jAlDUl6d8TH2C8T6XAf28nGXY/+c3Q7PLeEBSrlsD5/c8kXvssUmzCyreAXBk4E7 ASS7zTRjgTkmQxiCBsPd5oAdzllqnaEav25EB6GCh6HEpWc9U5VSMck3B8nirFBEbfNA qTEiWJ4Y+JAz1f7yhxmjlxzVe5hzEchqqSNzulPxQVEjBkO4DeYDA9z/+lNAA/yWKQXc I3rVTN1mq4J60Yp0uS6A4zRXVQ2sxQOpt+bfu7/6EIjqi9XHKvKbklgfygp8QYptlvEt EgxQBSUDUJr1KyAnC0QQQUBHHBOut9T/kaZP+NqdsBX2QcXF1CDgIADeFtRKn/oAQ2AD FjFg== X-Gm-Message-State: AOAM531eZ84dGo0tmX7yf8v8NvB81GIkUNi7IqSStQewD4Q4PJb0Ypbj 81HNLhb+5IBy7XgEpKbJWpQ= X-Google-Smtp-Source: ABdhPJx81+ExOAnluqr/SyKvgsx8KZDteV+nQHUzoBVw1+vrVtJ+e+y0pohJG37QSvCcxdBcwe23Gg== X-Received: by 2002:a05:620a:410a:: with SMTP id j10mr1791009qko.171.1610069677320; Thu, 07 Jan 2021 17:34:37 -0800 (PST) Received: from Windows10AnyBody.local ([2001:470:5:516:1512:c713:e7a7:3f18]) by smtp.gmail.com with ESMTPSA id m190sm4135929qkb.42.2021.01.07.17.34.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jan 2021 17:34:36 -0800 (PST) Subject: Re: Forwarding Packets With Link Local Destination Addresses To: ipv6@ietf.org References: From: Alejandro Acosta Message-ID: <561e3133-73c9-6ded-0311-838d5939dcd2@gmail.com> Date: Thu, 7 Jan 2021 21:34:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------568B4572396AC9A3EC6BD6A6" Content-Language: en-US Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 01:34:40 -0000 This is a multi-part message in MIME format. --------------568B4572396AC9A3EC6BD6A6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello, My apologies for using this thread, I have a valid point. My comment inline: On 7/1/21 1:53 PM, Ron Bonica wrote: > > Folks, > > According to RFC 4291, routers must not forward any packets with > Link-Local source or destination addresses to other links. > > I interpret this statement to include packets that contain routing > headers. For example, it forbids an SRv6 packet whose final segment > has a locator that begins with FE80. > In LACNIC we ran a project called Natmeter [1] for about 2 years, we obtained a lot of interesting data during this period [2]. The case is the following, we detected some end-user devices with only Link Local addresses (exactly, no GUA nor ULA) that were successfully natted and using the web. Is it ok?, do you consider it as a forwarding of a packet? was it a crazy result? (we saw few samples of this) Thanks, [1] https://prensa.lacnic.net/news/en/research/lacnic-project-detects-massive-presence-of-nat-boxes-in-the-region [2] Well, actually it still available with much less successful measurement > Does everyone share this interpretation? If so, do RFC 4291 or RFC > 8200 make this sufficiently clear? > > Ron > > > Juniper Business Use Only > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --------------568B4572396AC9A3EC6BD6A6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hello,

My apologies for using this thread, I have a valid point. My comment inline:


On 7/1/21 1:53 PM, Ron Bonica wrote:

Folks,

According to RFC 4291, routers must not forward any packets with Link-Local source or destination addresses to other links.

I interpret this statement to include packets that contain routing headers. For example, it forbids an SRv6 packet whose final segment has a locator that begins with FE80.

In LACNIC we ran a project called Natmeter [1] for about 2 years, we obtained a lot of interesting data during this period [2].

The case is the following, we detected some end-user devices with only Link Local addresses (exactly, no GUA nor ULA) that were successfully natted and using the web.

Is it ok?, do you consider it as a forwarding of a packet? was it a crazy result? (we saw few samples of this)


Thanks,


[2] Well, actually it still available with much less successful measurement


Does everyone share this interpretation? If so, do RFC 4291 or RFC 8200 make this sufficiently clear?

Ron


Juniper Business Use Only


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------568B4572396AC9A3EC6BD6A6-- From nobody Thu Jan 7 17:43:32 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AAE3A100A for ; Thu, 7 Jan 2021 17:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNLC-dK3rJoo for ; Thu, 7 Jan 2021 17:43:29 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4543A1003 for ; Thu, 7 Jan 2021 17:43:28 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id v3so8768446ilo.5 for ; Thu, 07 Jan 2021 17:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=8J5gFQ2761GivqJ2GMSAh8u54jZpfCOfPDNj0hNvxgs=; b=WsJnKYY0DrYgSvmaE+MGr20HwxywcxRHtOw/V7Xw69IsUgYvYp8AXAVfLE2KLNVhs0 no8R0ezHOy1CQvjzxySp3SkY9T4c+Zv3z9zsuQeT9mISj3QxDOWvZgpKefwUa2UaS3DY ifKxMY06QxxIUQwgv5tBQ5q4kAYuE+hwl8dPYWlf5P/1dyh1tmLtU3bwf9FNITiNGA8L ka7zQ5RlDrwFgmco366x59imGtr3PRENSzt+VqRa0951AChIELbsgPz/UOE+sF/lZTio /MGeg5TQlpONUOryTeFHbDc3ASY1SL7GM8kUu56ZI7Nr+sk8tzPt/J1ZXlOGDLsdsIkm qVLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=8J5gFQ2761GivqJ2GMSAh8u54jZpfCOfPDNj0hNvxgs=; b=rQzijXMqyRt65R4o23peHclSyjwwOzj4xdGibqoJptZUtbln+EIHZb9zLSsiR86USj 20W4FDWtsIDXvDA4QKVbSdhKkCgEN3NeG2vCb8k0Hx6JvOYTwhn9aiMUWYhRSq5MSUE2 d/tiGeVGO22CmsGziwpWRBetXbiXBY7Hgdhk2fjKfsq062g4jruiufjDO5Ew3Gd2lLR7 m1M8xM8aThLAGY/7HX+ioaW845BAsTadveNOkuaZDNACE7KZEJS7mF0O9O4CbBOo+kib 7tSzchKlve7LT6KL/zBXncrvEojbDHI2dpz+fM/Qo0+dPDLSxkLbT5l8KwY3mRXANlEN NK4w== X-Gm-Message-State: AOAM533TuYvGzjNWko11duf3wfXuhCHKqaqrIzvI2XCrWvtoMyPvZ6/W E455+ZHHs+QRihdyr8tdF82abg== X-Google-Smtp-Source: ABdhPJzPWzyTJgRE06yUBRz34bDK2tuahTAywlkfExpzpIxdEpp7oQqYlIaA4oncSpqjXV4b2qoZGA== X-Received: by 2002:a92:9a42:: with SMTP id t63mr1713230ili.176.1610070208041; Thu, 07 Jan 2021 17:43:28 -0800 (PST) Received: from [192.168.4.114] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id v3sm5655977ilj.28.2021.01.07.17.43.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jan 2021 17:43:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) Date: Thu, 7 Jan 2021 20:43:25 -0500 Message-Id: References: <78D0D84C-53DB-4661-BA43-CFEB1F377BB4@isc.org> Cc: Philip Homburg , IPv6 Operations , IPv6 List In-Reply-To: <78D0D84C-53DB-4661-BA43-CFEB1F377BB4@isc.org> To: Mark Andrews X-Mailer: iPhone Mail (18E118) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 01:43:31 -0000 Who determines what names to use? What is the scope of the names? How is un= iqueness guaranteed in that scope? > On Jan 7, 2021, at 20:18, Mark Andrews wrote: >=20 > =EF=BB=BF >=20 >> On 8 Jan 2021, at 02:08, Ted Lemon wrote: >>=20 >>> On Jan 7, 2021, at 9:55 AM, Philip Homburg wrote: >>> I can see a few benefits of Mark's proposal. One is that it is good to >>> have a standard representation of information. In particular, >>> Mark's proposal would make it possible to have a master zone file that h= as >>> both public and private DNS entries. Then a split-DNS server could serve= >>> only the public data to the outside world.=20 >>=20 >> That=E2=80=99s a good point, although it would still be a good point if t= his were just a feature of the zone file and not of the wire format. >>=20 >>> At the same time, I think it would be great if we can put link-local add= resses >>> in DNS.=20 >>=20 >> That sounds like a really heavy lift. >>=20 >>> It may tie in nicely with scope IDs in socket addresses. If a DNS >>> record specifies that is valid only on a VPN link, then maybe we can alr= eady >>> tie the address to that link. No need to change applications, it can be >>> hidden in the stub resolver. >>=20 >> Now we need to standardize a way to identify links. This is a Hard Proble= m. I say this based on experience, not supposition. HNCP tried to do this, n= ot as successfully as I=E2=80=99d hoped. I=E2=80=99ve been working on it for= the Thread Border Router work, and haven=E2=80=99t come up with a general s= olution. Sure, if you have a data center and a managed multi-subnet LAN, and= you can just type in configurations, this works, but most networks aren=E2=80= =99t like that. I think the VPN case is probably tractable, but it=E2=80=99= s really hard to see a path to broad adoption for this idea. >=20 >=20 > My idea would be that there would also be a RA option(s) which advertised t= he names in the SA records that where applicable to the link. Implicit to t= hat is that there would be a API that allows getaddrinfo() to retrieve the > RA options for individual links and for all links on the node. getaddrinf= o() would use the later. The former would be used to construct UPDATE reque= sts for the DNS etc. LLSANAME (link-local SA name), ULASANAM (ULA SA name),= and perhaps others. >=20 >> If there is a path to broad adoption, it probably involves bottom-up work= , not top-down design. Most of the ideas I=E2=80=99ve had about this that I t= hink are practicable are very context-dependent. E.g., you can identify that= you are on the same link because you received a link-scoped multicast. >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 From nobody Thu Jan 7 18:03:02 2021 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2A83A1027; Thu, 7 Jan 2021 18:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8moXa2OxbWJo; Thu, 7 Jan 2021 18:02:59 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D753A1026; Thu, 7 Jan 2021 18:02:59 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 6C7B23AB0C8; Fri, 8 Jan 2021 02:02:59 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5A633160051; Fri, 8 Jan 2021 02:02:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 46B65160056; Fri, 8 Jan 2021 02:02:59 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q7PVha7OvWtH; Fri, 8 Jan 2021 02:02:59 +0000 (UTC) Received: from [172.30.42.68] (n114-75-149-106.bla4.nsw.optusnet.com.au [114.75.149.106]) by zmx1.isc.org (Postfix) with ESMTPSA id 4CD9C160051; Fri, 8 Jan 2021 02:02:58 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt) From: Mark Andrews In-Reply-To: Date: Fri, 8 Jan 2021 13:02:54 +1100 Cc: Philip Homburg , IPv6 Operations , IPv6 List Content-Transfer-Encoding: quoted-printable Message-Id: <37D4E745-95A0-4B57-8FC7-D9DF0882FECF@isc.org> References: <78D0D84C-53DB-4661-BA43-CFEB1F377BB4@isc.org> To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.7) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 02:03:01 -0000 > On 8 Jan 2021, at 12:43, Ted Lemon wrote: >=20 > Who determines what names to use? What is the scope of the names? How = is uniqueness guaranteed in that scope? One would recommend using suffix names that are already registered to = the organisation, individual in the DNS. The example names I used where using the individuals suffix (id.au) but = the idea is to leverage the existing global DNS to provide uniqueness. = If you don=E2=80=99t have a domain name generate a random 160 bit number = and base32 encode it (like NSEC3) or similar and append .home.arpa to = it. If you are publishing into the global DNS you have a registered = name to use as a suffix. If you aren=E2=80=99t publishing into the = global DNS you need to ensure the names don=E2=80=99t clash with any in = the global DNS,

[1] https://prensa.lacnic.net/news/en/research/lacnic-project-detects-massive-presence-of-nat-boxes-in-the-region