FAQ
Reviewers: rsc, iant,

Message:
Hello rsc@golang.org, iant@golang.org (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go


Description:
net: support IPv6 scoped addressing zone identifier

This CL provides IPv6 scoped addressing zone identifier
support as defined in RFC 4007.

Literal IPv6 address with IPv6 scoped addressing zone identifier
format in Dial, Listen, ListenPacket, ParseCIDR, SplitHostPort,
ResolveIPAddr, ResolveUPDAddr and ResolveTCPAddr would be
fe80::1%en0 or [fe80::1%en0]:12345.

Fixes issue 4234.

This CL is required for go.net/ipv6 package.

Please review this at http://codereview.appspot.com/6816116/

Affected files:
M src/pkg/net/dial.go
M src/pkg/net/interface_test.go
M src/pkg/net/ip.go
M src/pkg/net/ip_test.go
M src/pkg/net/ipraw_test.go
M src/pkg/net/iprawsock.go
M src/pkg/net/iprawsock_plan9.go
M src/pkg/net/iprawsock_posix.go
M src/pkg/net/ipsock.go
M src/pkg/net/ipsock_plan9.go
M src/pkg/net/ipsock_posix.go
M src/pkg/net/multicast_posix_test.go
M src/pkg/net/tcp_test.go
M src/pkg/net/tcpsock.go
M src/pkg/net/tcpsock_posix.go
M src/pkg/net/udp_test.go
M src/pkg/net/udpsock.go
M src/pkg/net/udpsock_plan9.go
M src/pkg/net/udpsock_posix.go

Search Discussions

  • Ingo Oeser at Nov 12, 2012 at 8:19 pm
    Maybe add a comment, that these scope ids are OS specific? And add an example for each supported OS?
  • Mikio Hara at Nov 13, 2012 at 12:38 am

    On Tue, Nov 13, 2012 at 5:19 AM, Ingo Oeser wrote:

    Maybe add a comment, that these scope ids are OS specific?
    Yes. Like a network interface name or index is different btw BSD and Linux,
    btw Ubuntu and CentOS, btw Unix variants and Windows.
    And add an example for each supported OS?
    Well, no, perhaps.
  • Rsc at Nov 12, 2012 at 9:02 pm
    I understand that we probably have to do this, but I'm not thrilled
    about it. It just seems to infect everything.

    This is a lot to digest. Could you please split this into two CLs, one
    that does whatever code refactoring is necessary but does not introduce
    the %foo syntax, and then a second small CL that does introduce the
    %foo?

    The IPAddr struct has until now been pure data and also purely just an
    IP address. Does it really need to have an unexported zoneID stuffed
    into it? If so it should probably be xported. But why is it an int and
    not a string? All the examples use strings like "en0". Is it just a
    quick hack to avoid larger internal changes? Better to make the internal
    changes than to add a new unexported field to an exported struct.

    Why should ParseCIDR throw away the scope identifier?


    https://codereview.appspot.com/6816116/
  • Mikio Hara at Nov 13, 2012 at 12:32 am

    On Tue, Nov 13, 2012 at 6:02 AM, wrote:

    This is a lot to digest. Could you please split this into two CLs, one
    that does whatever code refactoring is necessary but does not introduce
    the %foo syntax, and then a second small CL that does introduce the
    %foo?
    Sure, will do.
    The IPAddr struct has until now been pure data and also purely just an
    IP address. Does it really need to have an unexported zoneID stuffed
    into it? If so it should probably be xported.
    Well, the kernel, BSD or Linux, I mean KAME and USAGI IPv6 stack inside,
    doesn't notice that which IPv6 address in sockets belong to which zone. For
    example, getsockname returns sockaddr_in6 but it doesn't contain zone id.
    If we never mind what Addr/LocalAddr on Conn returns socket address without
    zone id, I will export that field.
    But why is it an int and not a string? All the examples use strings like "en0".
    It might be numeric or interface name for now. Hm, will change to string type.
    Why should ParseCIDR throw away the scope identifier?
    Can we make an API change to IPNet struct? why not? sure, will do. ;)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedNov 12, '12 at 3:38p
activeNov 13, '12 at 12:38a
posts5
users3
websitegolang.org

3 users in discussion

Mikio Hara: 3 posts Rsc: 1 post Ingo Oeser: 1 post

People

Translate

site design / logo © 2022 Grokbase