From: Dave Taht <dave.taht@gmail.com>
To: Fred Baker <fred@cisco.com>
Cc: bismark-devel@lists.bufferbloat.net, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] ipv6 fe80:: addresses, vlans and bridges... borked?
Date: Mon, 9 May 2011 10:14:41 -0600 [thread overview]
Message-ID: <BANLkTikCqA1-ypKWx43QHMDdgNh_XEux1w@mail.gmail.com> (raw)
In-Reply-To: <6C99CF5C-88E9-4F38-9C11-CF75DD83E965@cisco.com>
[-- Attachment #1: Type: text/plain, Size: 6519 bytes --]
Fred/all
See
http://www.bufferbloat.net/issues/126
which has a ip -6 addr and ifconfig dump
and see if that "seems right" to you.
On Mon, May 9, 2011 at 9:57 AM, Fred Baker <fred@cisco.com> wrote:
>
> On May 9, 2011, at 7:59 AM, Dave Taht wrote:
> > On Mon, May 9, 2011 at 2:14 AM, Fred Baker <fred@cisco.com> wrote:
> >
> > On May 8, 2011, at 8:26 PM, Dave Taht wrote:
> >> > Is there a standard for renaming fe80:: addresses to represent they
> are interfacing with different vlans?
> >>
> >> well, yes. Link-local addresses (FE80::/10) areas you say interpreted
> only in the LAN in question. The usual approach is to give the LAN a subnet
> prefix. The standard is RFC 4291.
> >>
> >> http://www.ietf.org/rfc/rfc4291.txt
> >>
> > So, there isn't a standard for using vlans and ipv6.
>
> There is one for IPv6. How you use it in your addressing plan is your call.
> You could map subnet numbers to vlan numbers of that made sense for you, but
> I'd be surprised if folks generally wanted to do that; believe it or not,
> not all networks are built around vlans. Many are built around MPLS, and
> many use neither - they simply use IP subnets.
>
> > aformentioned RFC:
> >
> > 2.5.1. Interface Identifiers
> >
> > Interface identifiers in IPv6 unicast addresses are used to identify
> > interfaces on a link. They are required to be unique within a subnet
> > prefix. It is recommended that the same interface identifier not be
> > assigned to different nodes on a link. They may also be unique over
> > a broader scope. In some cases, an interface's identifier will be
> > derived directly from that interface's link-layer address. The same
> > interface identifier may be used on multiple interfaces on a single
> > node, as long as they are attached to different subnets.
> >
> > "It is recomended that the same interface identifier not be assigned to
> different nodes on a link"
>
> There is a stronger statement than the one in 2.5.1; the text above says
> that "They are required to be unique within a subnet prefix."
>
> > vs
> >
> > "The same interface identifier may be used on multiple interfaces on a
> single
> > node, as long as they are attached to different subnets."
> >
> >
> > Linux - or at least the defaults inside of openwrt - take the latter
> approach. This strikes me as error prone - and further does not discuss the
> effects of what a bridge should look like.
> >
> > For error prone-ness - it is possible in my case, the vlans are not
> vlans! although their naming scheme (ethX.Y) suggests they are. And a
> typical user might plug two different lans together on one cable anyway.
>
> So you're concerned that two interfaces might have the same interface
> identifier but different supporting MAC addresses within the same subnet?
> Yes, in this model that is possible. I personally would suggest that one
> uses duplicate address detection to detect and avoid the situation. Does
> Linux do that? From a requirements perspective, "may" is a lot weaker than
> "required".
>
> > Also:
> >
> > Should the bridge itself have a unique link local over the underlying
> interfaces?
>
> I'm not sure what "bridge" you're talking about. If by "bridge" you're
> referring to a linux system using the same IID on multiple interfaces, IIDs
> "are required to be unique within a subnet prefix" per the text you quoted
> above.
>
> > Given that we have a profusion of numbers available for link-local
> addresses, I can see no harm and much gain in *always* constructing a
> verify-ably unique fe80::XX:VLAN:EUI-64/64 prefix on a per-interface and
> per-virtual-interface basis on a given router.
>
> That's certainly your choice; it doesn't map to any address format in the
> spec; 2.5.6 very specifically sets those bits to zero in a link-local
> address (I would argue it should therefore specify the prefix as FE80::/64,
> not FE80::/10). How do the hosts know what VLAN they are on? That's
> generally either information known by the switch and used on trunk ports, or
> configured data. The host generally has no idea what VLAN it's on. Recall
> that link-local addresses are what the device develops before it has any
> knowledge of the world around it.
>
> > ensuring unique FE80s from a given host would be enormously less
> confusing when looking at and comparing wireshark traces of the babel
> protocol, for example. ( http://tools.ietf.org/html/rfc6126 )
> >
> > What's not clear to me after reading RFC4291 twice this morning is that
> although a fe80:: is a /10, is if the bits above the interface id (as per
> the above "XX:VLAN:") truly are legit to be used, or a modified unique
> EUI-64 should be used.
>
> What you're describing is essentially a site-local address, although the
> format uses FEC0::/10. Did you read the part about site-local addresses
> (2.5.7)?
>
> | 10 |
> | bits | 54 bits | 64 bits |
> +----------+-------------------------+----------------------------+
> |1111111011| subnet ID | interface ID |
> +----------+-------------------------+----------------------------+
>
> You have tried to specify the "Subnet ID" and use it as a link-local.
>
> I'll suggest you read:
>
> http://www.ietf.org/rfc/rfc3879.txt
> 3879 Deprecating Site Local Addresses. C. Huitema, B. Carpenter.
> September 2004. (Format: TXT=24142 bytes) (Status: PROPOSED STANDARD)
> and
> http://www.ietf.org/rfc/rfc4193.txt
> 4193 Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman.
> October 2005. (Format: TXT=35908 bytes) (Status: PROPOSED STANDARD)
>
> > A VLAN identifier is 12 bits in length, so the "V" portion of the above
> proposal could be dropped. (Not that I know how to extract the vlan
> identifier from the interface anyway) XX would be used to distinguish
> between interfaces that had no corresponding info but conflicted with
> addresses already on the router.
> >
> > I realize this is somewhat off topic for the bloat list, but I was trying
> to get where I could actually test the IPv6 ECN patches I'd folded in across
> the routers(s) and running into trouble.
>
> I actually think you would do well to join
> https://www.ietf.org/mailman/listinfo/ipv6 and discuss it on ipv6@ietf.org
> .
>
>
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
[-- Attachment #2: Type: text/html, Size: 7890 bytes --]
next prev parent reply other threads:[~2011-05-09 16:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-09 3:26 Dave Taht
2011-05-09 8:14 ` Fred Baker
2011-05-09 14:59 ` Dave Taht
2011-05-09 15:57 ` Fred Baker
2011-05-09 16:14 ` Dave Taht [this message]
2011-05-09 16:44 ` Fred Baker
2011-05-09 18:56 ` Dave Taht
2011-05-09 14:49 ` Roland Bless
2011-05-10 14:30 ` Jeremy Visser
2011-05-11 3:32 ` Dave Taht
2011-05-11 4:40 ` Roland Bless
2011-05-11 13:46 ` Dave Taht
2011-05-11 16:37 ` Rick Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BANLkTikCqA1-ypKWx43QHMDdgNh_XEux1w@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bismark-devel@lists.bufferbloat.net \
--cc=bloat@lists.bufferbloat.net \
--cc=fred@cisco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox